How did I get so unhappy working in tech?

Sleep until about 15 minutes before the first meeting. There's no sense bothering getting into work only to be interrupted by a meeting.

If it's a meeting-heavy day just resign yourself to the fact that you're not going to get anything done that day. So basically, you have to plan your sprints to be two days shorter than they actually are (or whatever, depending on your company's meeting schedule).

Adjust all your estimates accordingly. A 3 hour task will take all day when you factor in interruptions, meetings, and meeting fatigue, so estimate 8 hours for it.

Sigh heavily, and remind yourself that you couldn't possibly get more than 3 days work done in two weeks, under the circumstances. So what little you did is actually pretty good.

One of the best things I ever did in my career was to quit. I had gone a route I thought was “the” route for a career in tech. First developer, then architect/developer then project manager/developer then into actual management leaving development more and more behind without being fully able to because no one could do what I did at the organisation.

It all went very well, I got involved with national task forces and was part of defining the national enterprise architecture for public software in Denmark. A long the road I also started doing conference/network/whatever talks and felt hugely important. Then I had a daughter, went down with stress that turned into depression and eventually found myself with an ADHD diagnosis at almost 40. Turned out my parents hadn’t wanted me to get one when I was a kid and had to see doctors because, well, I had ADHD. Not because my parents sucked or anything, but at the time it wasn’t called ADHD but DAMP (Danish word for steam, as in a thundering steam engine), and they believed such a diagnosis would be a bad stigma. I don’t blame them, but they probably “saved” me into changing my university major 9 times and eventually having to get a lower academy degree while working two jobs (not common in Denmark where we are paid to study for 6 years and have free (as in beer) access to most education).

Anyway, there I was with not enough energy to do the two full time jobs I now had, parenting and work. My former places of work was amazing in all of this, not only did they send and pay for a lot of the help they also let me work part time while being part time sick (in Denmark this gives you full pay, but the sick part of it is paid for by the government). Despite this, and despite being lucky enough to get appointed to one my countries leading psychiatrists for adults with a late ADHD diagnosis, I found myself wondering if I would ever work full time again.

Then I quit, and I don’t be back to developing software at a company that lets you actually build cool things. I started at 30 hours a week, but here half a year later, I’m going back to full time.

If you have the ability to pick and chose, as many of us in tech are fortunate enough to have, then I can only encourage that you use it if your current job makes you unhappy. Of course you’ll probably need it o do some work to figure out what makes you happy, or even if you are currently unhappy or happy.

There's a place for meetings, but if you're efficient, they should be rare, small and short.

No, you don't need a weekly project update meeting. I can send you something out of Jira and if there is an issue, you can post a reply to it, or email me. And I can spend time thinking about what you've written and write a careful reply. Only when that still doesn't work, do we do a synchronous meeting, at which point we cover only the points of contention, and with as few people as necessary.

The other beauty of tools like Jira is that the conversation is preserved. Why did we approach the problem that way? Well, go look at it. You'll have someone asking why we can't do a thing and a reply pointing out the problems of that and hence why we have to do it this way. You don't get all of that from the email of the meeting.

Being in meetings means you get to be in the room when decisions are made. Even if you aren't an active participant, you get to at least listen in.

Almost all problems are really people problems, and people problems can only be solved by communicating with other people.

Some engineers seem to want to work for long stretches uninterrupted, like monks copying sacred texts. That is not the way to succeed. To succeed you need to make sure what you are building is actually what you should be building. I've never seen a way to figure that out without having meetings with other people.

Think of it this way -- a software engineer is not just a programmer, just as a fireman is not just a "hose operator." You are ultimately someone who gets things done and solves problems for other people, and that requires regular communication with those other people.