If 80% is spent in progress meetings, scrum point estimation, and other acts of performative taylorism, yes.
If 80% is spent understanding reading about the domain in which you are working, talking to your users and domain experts, documenting your work, and mentoring juniors or being mentored by seniors, there should be nothing depressing about that.
I probably spend around 80% of my time coding in a senior role with around 12 years experience. I think it depends highly on where and what you work on.
If you have 8-10 engineers you’re supervising and are the person interfacing with management, I don’t think it’s unreasonable to spend half your time coordinating, teaching, and planning.
So scale down the expected SDE 1 quotas (~50% coding), and you get around 25-30% coding time.
I think a lot of people confuse being an experienced career engineer with being a technical lead; that’s the real jump from SDE 2 to SDE 3.
I think I'd get a lot less than 25-30% coding time while managing 8-10 people (and also depending on what you're doing while "supervising", if there's a dedicated project/product manager in addition to you, how senior are the other engineers, etc)! In fact at that point I think I'd be managing too many people ("ideally" 1 lead/manager isn't managing more than 5 ICs).
My experience of Big Co is that you have both a manager (HR and business sense) and a supervising/lead engineer (SDE 3) for a product.
I don’t think I explained that well — but a 3:3:1 to 5:5:1 SDE 1:2:3 mix is fairly standard across industry. (Again, with an SDM doing the managing.)
I used the word “supervising” because I wanted to distinguish that technical leadership from managing, but didn’t explain enough. Sorry for the confusion.
If you considering code reading part of coding, coding 20% of the time is certainly not enough.
The article is meant for a neurotypical ideal average employee.
There are many effective programmers that have different workflows.
A trait of a good manager is allow different people to be effective in the collaboration of writing software together.
The article paints an unreal rosy picture where "everything runs smoothly and has forward momentum".
Working with a live system is messy. There is always compromise because there is never enough time to keep everything smooth.
It is very common to be stuck at some problem. That moment you let a problem clunk around your brain and you randomly think of a solution in the shower or at the grocery store is way too common.
And honestly fun.
A great software developer doesn't have a computer. He lives alone in a cabin in the woods. He knows it is better that way as it minimizes harm to others and allows him to skip all of the meetings forever, until the end of time...
It depends heavily on the company and the team you're on. If you are a more seasoned professional, you probably get the luxury of filtering on this criterion. And a lot of people also really enjoy the other eighty percent.
Not all engineering is coding. If I'm debugging a couple of hard to find problems this week I won't write lots of code but I'll certainly be doing valuable engineering.
Maybe, but you also have to consider how much preexisting code has been prewritten in frameworks and libraries. Consider how much of “coding” is spent integrating that code instead of typing out new lines of code.
Yes, pretty sad. Even worse, these 20% coding can be fixing bugs in different projects your team work on, and on which you have only a basic understanding.
The percentage of coding on a project that I get to design is even lower.
If 80% is spent understanding reading about the domain in which you are working, talking to your users and domain experts, documenting your work, and mentoring juniors or being mentored by seniors, there should be nothing depressing about that.