Insurance:

For this “industry,” it varies wildly by department and position. The lower your are (entry level, etc.) the worse it’s going to be. People are always in accidents, so you’ll be working customer service on nightmare mode. No real meetings, maybe a “huddle,” and then back to work.

I’ve moved up slightly and it is night and day. I get work/claims, but I’m usually done by noon, and that’s with me fucking around (on my phone, messing with the cat, chores, etc.). The projects are PowerPoints and excel sheets in my area, which are simple. Since I’m at home, when I’m done, I usually just keep myself online and work on crafts. If I’m extra bold, I’ll take the laptop downstairs and play a game. The more specialized you get, the less work you have.

Software engineer.

Morning meeting that’s supposed to just be “what you did yesterday, what you’ll do today, and if you need help”. People fuck that up and go off on tangents. What should be a ten minute meeting takes 30.

Product owners at some point told you what the features to work on this month will be. For example, we need to add the ability for some reasons to bulk delete appointments.

Chat with product and other engineers about what that entails. Product probably won’t give complete, clear, requirements so you need to pull it out of them. (Hard delete or soft delete? Do you need an audit log? Are you sure with no take-backs you don’t need an undo? Do you want to notify anyone when it’s deleted? One email per request or per event? Do you have designs for that email? No? Of course not. And what do you want the UI to look like? If I “just put a button somewhere” we both know you won’t like it. Give me details or that blank check in writing.)

At some point sit down and make code changes to do the thing. Change the backend server code to accept your new request. Write automated tests. Change the frontend to make the request. Write more tests. Manually bang on it. Probably realize some requirements were missed (you guys know there’s a permissions system, right? I hooked this up to the existing can-delete permission. What do you mean CS doesn’t use permissions? You made them all superusers??)

Manually bang on it a little. Deploy it to dev or some non-production environment. Have product and other stakeholders look at it and sign off. Probably get feedback and either implement it, or convince them to do it “later” (or: never, because they’ll forget and it’s not actually important).

Get code approval from other engineers. Make changes as needed.

Merge and deploy. Verify in production.

Meanwhile, do code reviews for other people’s work. Context switch. Feels bad. Other guy is working on a progress report tool that’s in a whole other part of the code, so every time you look at it it’s a shifting of brain gears.

Also look at dependabot for libraries that need updating. Read release notes. Make changes if needed. Test. Pray.

Also periodic meetings to go over work in the backlog. A meeting to discuss how the team is doing that usually doesn’t produce results, but can be a vent session.

I imagine from the product owner it’s something like:

Get a mess of contradictory ideas from leadership. Try to figure out what they actually want and in what order. Manage their emotions because they have all the power and don’t like being told no or otherwise feeling bad.

Talk to customers and other users. Try to figure out what they want. They say things like “make it go faster” or “can you make the map bigger?”. There’s no map on the website.

Talk to engineering. They ask so many questions. Why can’t they just do the thing? They’re always going on about stuff that doesn’t seem important (like security and permissions and maintainability). This needs to go out Friday because the CEO wants it out.

Write tickets (a short document describing work to be done). People don’t read them. Or maybe don’t finish writing them, and leave a vague “as a user I want to be notified about changes to my project”, without specifying any details. (Notified how, Ryan??)

I don’t know what else they do.

Startups are a mess. Anyone who says they want to run the government like a startup should be banished from the land.

I’m actuarie, I work in the reporting department, that means we prepare reports and databases to be sent monthly to our regulatory agency. My day to day functions are writing python programs to prepare and validate the reports and bases, sometimes my boss is finding mismatchs beta bases (like the accounting base is saying we paid 10 on claims, but the actuarial base say we paid 9) and she ask me to find what base is the correct one and why it’s had an error.

Be engineer, draw pictures with numbers next to it that mean that your picture is important. Give picture to someone who agrees that your picture is important and presses on your picture with a stamp. Then give your picture to people that don’t work at desks to make a thing that looks like your important picture.

I just check email all day. Like that’s 80% of my job. My entire job could be done from anywhere. I don’t do as single thing that isn’t in my laptop. But I still sit at a stupid cubicle.

I work for a consulting firm, so a project is whatever our client has contracted us to do, for the objectives and timeline we’ve agreed to in the contract. We do workforce readiness, largely. So the client might be adopting a new software and wants us to create the employee training on it.

We contract with them for training to help their leaders deliver workshops, maybe some e-learning modules and assessments, and to have it done in a certain number of weeks. That’s an example of a project, and typically we’ll have a small team on the deliverables for it: the modules and the workshops. Meetings are to check in on progress, fix any issues, meet with the client or their subject matter experts. So that’s my office job, though luckily it’s been remote for me since covid.

Just look up the movie “Office Space” it pretty well summarizes it all.

I’ve never really had a “desk job” where my job was to sit at a desk 9 to 5. But a few of my past occupations included at least some desk time, such as:

• Flight instructor. Most of my day was spent either in the classroom briefing/instructing, or in the plane instructing/overseeing. I spent a significant portion at a desk creating lesson plans, updating logbooks, communicating with students, grading assignments, communicating with other instructors, communicating with our Designated Pilot Examiner, filling out FAA paperwork, that sort of thing.
• Aviation mechanic. This is more of an administrative job than the posters at your local trade school would lead you to believe. An owner/operator/pilot/plane haver guy brings you a plane for an annual inspection, now you have a research project. What exact make and model is this thing? What modifications has it had during the 50 years it’s existed? Under what authority were those modifications made? Is it still in original or correctly modified condition? Are there any manufacturer service bulletins or FAA airworthiness directives issued for this aircraft, and I mean THIS aircraft, or its components? Like, they’ll call out ranges of hull numbers in these things. Then there’s recording all the shit YOU did to the plane while it’s here.
• Project manager of a short-run job shop. First up: Meet with the customer and massage the idea they have out of their brain. 3 times out of 10 tell them which aisle in Wal-Mart they can find what they want, 1 time out of 10 explain why what they want isn’t physically or technologically possible. Once I’ve got a good idea of what the customer wants, it’s time to do some preliminary design work, research materials and prepare an estimate, deliver this to the customer. 7 in 10 times we hear back from that, get the okay to build, now it’s time to order materials, do any of the design work which may include CAD design, electrical design, computer programming, whatever. Scheduling and directing my team, contracting with any talent I don’t have in-house, the all important staring at a wall visualizing fourteen different variations on some little yet pivotal detail, and then I’d end up in the shop running laser cutters or lathes or table saws or whatever to get it built. Then the most important part: Invoicing the customer.

Here’s my office work:

Since 2005 I worked as a TV news producer. We started the day with a morning meeting where reporters pitched stories and it was decided what they covered that day. Then as a producer I organized the stories in the newscast and found other stories which I was responsible for. That ranges from finding a worthwhile press release to interviewing people myself (usually by phone, and someone’s video chat,) or just finding info by going through data. I would write those, then decide what visuals, audio elements, camera shots, graphics, and anchor reads went with it.

Then during the live newscast I timed it, and made adjustments on the fly when necessary. (Killing stories, finding ones to insert, and adding breaking news.)

I let my contract end almost two months ago, choosing not to stay in news. I’ve been applying to mostly other non-TV news office jobs. That’s including producing other video projects, but also technical writing and marketing positions.

As a manufacturing engineer, I’m mostly in an office when I’m not actively dicking about on the production floor or talking with my production operators. Most of my desk time is

1. Answering questions from people who aren’t me about my manufacturing lines: specifications, output, inputs, could I do experiment XYZ if they sent me info. Subject Matter Expert is the term the company uses. Debatable if it’s accurate, but it’s the expectation.
2. Answering stupid questions for people who could absolutely open an app or walk and look in person but would rather be handed the info.
3. Collaboration with other employees: be it Quality as to what hoops I need to jump through to do something, providing process data relevant to a manufacturing defect they were alerted to, pestering other engineers to see if they’ve done anything like what I’m up to because it’s a good shortcut, or trying to work out how to use a system I’m unfamiliar with.
4. Tracking output metrics: Management loves the same numbers tracked 5 different ways and having them reported to them constantly.
5. Meeting prep: either making a slideshow, crunching data to present, updating a project tracker (see above), or reading all the relevant emails associated with the meeting because earlier I super just skimmed them for anything I was required to do urgently. 7: Tinkering on things at my desk: familiarizing myself with new equipment/parts, testing an idea out of scraps/easily sourced parts before I ask our Tool and Die team to draw up a design for something sturdier/more expensive, or rooting through boxes for things I inherited relevant to that manufacturing line when I was assigned to it.
6. Messaging folks on teams: lunch plans, thoughts on recent events, or even just sending memes, gifs, ASCII middle fingers to people I like. General screwing around.

Getting emails faster than you can read and respond to them, and they are all urgent exceptions.

Meetings that could have been emails, wasting your time while the real emails continue to stack up.

Askng important questions (via email) and getting ignored, or only some of the questions addressed.

Visits from the newest suit talking about how great their new ideas will be, just like the last one who said the same thing and was replaced after 6 months.

It is a lot like the movie Office Space, except in current times instead of one job you’re doing the work of 2.5 people and making less than Peter did in 1999.

In my case, I work IT for a healthcare company. Current major projects of mine include trying to migrate servers from our data centers to the cloud and setting up Disaster Recovery options. These are 2 of my 22 current projects.

On the day to day, I’ll determine what it takes for an application to run and how does it communicate to find the most optimal way we can build it within vendor and enterprise specifications. An example might be…

• Application is a hosted Web Page
• It stores all of its data a SQL Database
• Is used by locations outside of our network, so this will require
  • A Public Endpoint to be accessible outside of our network
  • DMZ’d Network Security Group or Application Security Group to manage exactly what and be accessed from where
• Is a low-tier application that does not require low latencies

In this case, I can decide to use a PaaS Web Server and PaaS SQL Server, so that I don’t have to manage security and updates of the Operating System in the future. After deciding this, I might diagram how everything will connect and communicate, then build the infrastructure to fulfill this design. Lets say that means going to Azure (the cloud provider), building the Web Server and SQL Server, creating the DMZ rules (443 inbound from anywhere to WebServer and 1433 only from WebServer to SQLserver) I set up a backup system for both of these to take daily backups in case anything goes sour, then determine what steps are necessary to make sure that I can minimize the downtime for the migration, since it will take time to restore a backup from the data center’s version into the Azure version.

I’m trying to keep things simple-ish for this example because there’s a wide variety of tools, environments, and processes that come into play for any one of these builds. Most of the time is spent not in actively moving things, but in determining best courses of action and minimizing downtime, especially being a healthcare environment where an application could be actively impacting a patient’s care.

Of course there’s all the other stuff you might expect, like emails about a server not working right and meetings about how management wants to use more AI while needing to cut costs to the organization because we’re “not currently economically sustainable.”

While by no means a comprehensive view into the work, I hope it grants some insight into the role!

I’ll just give some examples.

We know that construction workers build things, but many office workers are behind them. When you hear “office worker,” think “information worker” as that will help.

What information?

Someone has to pay the construction workers. This involves accounting and payroll tasks best done at a computer.

Architects design the project being constructed and this is done in an office.

There are permits, inspections, regulations, taxes, real estate licensing etc to clear the project and this is done through computers and telephones.

Coordination of the different work crews must be planned - we don’t just ask concrete, civil engineers, plumbers, electrical, and landscaping to all show up on the same day and just figure things out. These things are scheduled out and arranged with many different companies / subcontractors and this is mapped out on a computer and agreed to over the phone.

The new apartments being constructed will need tenants to rent them. Billboard space is going to be rented near the building. A graphic designer is designing the billboard on a computer in an office. Someone else is calling the billboard company to arrange the large scale printing of it and to purchase the time it will be displayed.

I’ll stop. This is off the top of my head. If construction workers, with their obviously valuable and easy to understand work have this many office workers behind them, you can imagine how it’s even more complex for things like tech companies.

Most office workers move things from point A to B in the physical, digital, or financial world. Electricity, toys, real estate, insurance contracts, missiles, you name it. The office worker is a link in a chain of information that stretches from the beginning of causality to the final effects of human existence.

There’s a mine, somewhere in the world. In that mine is metal. A factory owner wants that metal. Office workers for that factory call or email the office for that mine, and asks for that metal. The two offices negotiate a deal.

This usually involves calls or emails to management, accounting, sales, legal - all different office workers doing different things - that ultimately boil down to:

1. a price per unit of metal +/- applicable taxes that can benefit both parties, and
2. logistics of when and how to deliver or pickup that metal, and how much those logistics cost.

From there, it’s pretty much the same deal. The factory isn’t making enough money. They want to sell a better product. Office workers negotiate a deal with other office workers at an engineering firm. Both parties make calls, send emails, design proof-of-concepts, and they negotiate a deal. Sometimes they logon to an hour-tracking software, so an office worker can bill the factory per hour a different office worker spent working for that factory.

A major importer wants the product that the factory made with that engineer’s designs and that mine’s metal. Office workers make calls, send emails, check tariff and tax regulations, contact representatives at the port or border, schedule times and dates, and negotiate a deal.

A major retailer wants the product that the importer purchased from the…

A consumer buys a product and dies. Their family hires a lawyer. That lawyer has his office workers make calls, send emails, logon to government websites, and schedule hearings and submit documents to prove that the product killed the consumer.

An insurance agency investigates the plaintiff that is suing the retailer. They google the person that died. They contact office workers that know about how people die or know about how products can kill, and they check the insurance company’s database for how often people die to that product, and they calculate the odds that the product will kill a person, and then insurance office workers renegotiate a contract with the retailer office workers for higher premiums.

An office worker in the government works for the court. They make and cancel appointments, make phone calls and send emails to other office workers, employees, lawyers, or plaintiffs, they send data from one lawyer to another, etc.

The whole system builds and builds until you have office workers talking to office workers talking to office workers about the movement of imaginary assets that never actually move, or the buying and selling of personal data for targetting ads that everyone hates, or software engineers building cryptocurrencies designed to fail or call centers that exist only to convince you to pay them money, or tax filing software companies that only exist because they pay the government to make tax filing hard…

And there you have the modern day office worker.

TL;DR: Reading emails. Sending emails. Checking data. Making phone calls. Signing contracts. Approving decisions. Buying, selling, loaning, stealing, hiring, firing, murdering, perjuring, harassing, gassing, lying, crying, building, destroying - all pixels on a screen and voices on a phone, text in an email and words in a voicemail, all the world’s wealth and all the world’s future moving piece by little intricate piece from one human to the next in an impossibly vast network of causality that nobody really understand or controls but nonetheless keeps rolling forward one dollar at a time.

Let me take a liberty to answer for everyone.

Most of human activities now generate a lot of data, or require a lot of data to happen.

It can be anything from construction blueprints and software, to more subtle things like goods distributions on the shelves or schedules or whatever.

Behind everything you see in the world there is a data management, and behind this data management there are layers of people making those decisions from top to bottom.

Some of those people managed to create spaces where all they have to do is to say “nothing on my side” during the meeting.

Others are the opposite, have to take the toll and process the massive amounts of this data.

This is what the office job is nowadays.