> Software development isn't a matter of sitting down and generating a fixed amount of code per hour. The rate of writing code is hugely variable... The time not spent typing (or being in meetings, doing admin, etc) isn't actually "unproductive" though.
All true statements, but that's not what we're talking about. OP recognizes that he works 5-10 hours a week, and effectively blows the rest of the day off.
Reminds me a bit of an engineer who reported to me a few years ago. He would describe every week in our 1:1s and during team meetings how he was solving this tough thread-synchronization problem. Because we trusted each other, we trusted that the problem was difficult. Then when he finally submitted his code, it was a single line. A single trivial line (as in, read the python `multiprocessing` docs for 5 minutes and the solution is right there). OK... sometimes it can take a long time to find that one-line fix, I get it. But then I looked into his commit history, and it turns out he was averaging a few lines of code a week -- on a good week, and sometimes even zero. When I confronted him, he said "You can't measure my productivity by lines of code!!!" OK, sure, but how far am I supposed to excuse an engineer who has committed 100 lines of code in 10 months? What a statistical oddity, that every single task he took on turned out to be a single-line-fix dragon!
I don't disagree, but I never said there was no such thing as slackers or that OP definitely isn't one. I provided a test to tell if they really are one or not.
The point I'm making is that some people in our profession think they are slacking when they're not, for the reasons I described. OP's description doesn't convince me that they necessarily are. In particular the comment at the end about having spent the years prior to the pandemic "pretending" to themselves that they were working hard sounds to me like somebody who's never really understood their own mental processes and has encountered a different perspective by doing the job in a different environment. I might be wrong, but that sounds more likely to me than that they have been getting away with minimal contributions throughout what they describe as a 20 year career. Your report didn't get away with it - the evidence is always there in the commit history, and the 2-5 year job length OP mentions is, contrary to their assessment, plenty of time to judge a developer's productivity.
Another hint is the fact that this person is seriously proposing the idea that everybody else is slacking off and lying too. This indicates that they don't think their actual output is less than other developers'.
As I say, I may be wrong. I don't know this developer - these are just some thoughts based on what they've posted. Unlike some here I'm not assuming I know the truth.
I am in a similar position as OP. I do 15-20 hours of work and watch Twitch or YouTube the rest of the time. I am a lead dev at a startup and developed one of their main products. I have always implemented every feature in a few days or less. Bug fixes usually take 30-45 minutes. Meanwhile another lead dev, who handles the development of another product, takes at least 2 days to fix a simple bug, and 1-2 weeks to implement a simple feature.
Personally I don't see why I should be overworked if I get all of my stuff done in a short amount of time. Plus because I feel guilty I am always available on Slack and answer or even code on demand if somebody really needs it.
I sense that higher ups look at me as a hard worker and a good employee, but if only they knew the thruth. But if I was forced to work a lot more I would probably quit.
Yeah, that's the common mindset. You feel that you're slacking off, and you feel "guilty" about it, but you have a successful career and describe the prospect of doing more than you do as being "overworked" to the extent that you may have to quit.
1) He was on another team the first 6-7 months of that. He was transferred to me on account of previous project being wrong area for him (it required domain knowledge he didn't have and didn't pick up). His former manager had worked with him before, so we gave him benefit of the doubt. After a few weeks of ramp-up on my team, he started giving me productive progress updates throughout every week. "I spent all week debugging such-and-such. I spent half the week helping Joe debug a problem", etc. He was very nice and external signs were fine. Then I saw his actual code was minimal, and sadly I learned that the engineers he kept telling me he was busy helping (which would be super valuable work) weren't actually getting that help -- he'd occasionally answer a question, or spend 15 minutes looking over someone's shoulder.
2) A guy on my team is repeatedly telling me he's on the verge of solving a tough problem, and then I take a look at his code and discover it was a trivial issue all along. No, the answer was not that I should have jumped in earlier and taken over the bug myself.
His story ended by being put on a performance plan, which he failed, and then we let him go. At the end of the day, though, he could very likely have stayed with us, if he just accepted my feedback that his productivity was far lower where it should be, and lower than all his peers. He refused to hear it. "You can't measure my performance based on LOC!" Correct, but the LOC was the first clue that he was delivering nearly zero value.
The reason I even told this story to begin with was because some developers somehow tell themselves that they're super productive despite barely checking in any code. By and large, that can't be true.
All true statements, but that's not what we're talking about. OP recognizes that he works 5-10 hours a week, and effectively blows the rest of the day off.
Reminds me a bit of an engineer who reported to me a few years ago. He would describe every week in our 1:1s and during team meetings how he was solving this tough thread-synchronization problem. Because we trusted each other, we trusted that the problem was difficult. Then when he finally submitted his code, it was a single line. A single trivial line (as in, read the python `multiprocessing` docs for 5 minutes and the solution is right there). OK... sometimes it can take a long time to find that one-line fix, I get it. But then I looked into his commit history, and it turns out he was averaging a few lines of code a week -- on a good week, and sometimes even zero. When I confronted him, he said "You can't measure my productivity by lines of code!!!" OK, sure, but how far am I supposed to excuse an engineer who has committed 100 lines of code in 10 months? What a statistical oddity, that every single task he took on turned out to be a single-line-fix dragon!