Ask HN: Are most of us developers lying about how much work we do?

Software engineering is one of the easiest jobs out there from an ability to track your output standpoint. I think a lot of the commenters implying "if you have 10 hours to cut down a tree, use the 9 to sharpen your ax" and using that to argue against code-line-output != productivity. Certainly in cases where you need to put a lot of thinking or research to come up with a very elegant solution in a few lines, no one can argue you have been productive. But more often than not, we work on simple CRUD or basic apps that were stretched among hours, flying under radar from one stand up to the next, like you mentioned.

It's a common problem so you are not the only one. Especially in large teams, or teams that are run by PM's who are not very savvy to open the hood and understand what had been going on. In most of the opposite cases, it's also awkward for some managers to challenge what you have produced in a day. It starts more on the foot of discovering: is there another mental block with the employee, are they having motivation issues (maybe you fall into this group), is there a training/onboarding issue? And I have seen first hand, most of the time - they give up and mediocre output continues.

Laziness/talent/ethics of it is not our place to comment for you - but it sounds like this would be a boring job to continue. Sure you can make good money and live a comfortable life, but I can't fathom if it would be fulfilling in the long run for me. Find what stirs your passion and try to apply to work. You have the luxury to do so.

Thanks for the post.

I think when I first started programming I figured this out at my first real coding job. After about 3 months, organized the code, streamlined systems, met the needs of the stakeholders, reduced interruptions, pushed more responsibility back to the account managers, and provide a sense of security and trust to the owners of the company. (oddly enough I was the only developer) After that was established, the company had a meeting on Monday morning that I initiated. Once that was done, there were times I wouldn’t get an email/phone call for the rest of the week.

Keep in mind, rolling into this job I was a combat vet, and for what it's worth an MBA as well. I just have an innate sense of how to cut to the chase and get the job so I can sit back and reap the rewards of the front-loading work. It’s when I get bored that I get in trouble. Even since 2014 I always seem to have some side works/side projects going because well I like to be challenged. It probably also helps that I don’t really want a career in software engineering, so lately I have been just working on contract work.

There's engineers like this, but at small companies your colleagues dislike you and lose respect for you each day. There was a guy like this at my last company, and then when they tried to fire him he threw accusations against colleagues and played the legal game. In a word, absolutely pathetic stuff.

I work very hard, and I don't expect others to, but I question why you would spend 40h a week every week just playing time-waster and obfuscator

processing for one or two days to prepare productive working that takes 30 minutes sounds a bit extreme. but I get the gist and second it. I hate developers you immediately jump at any task coding right away. they usually actually get the stuff done but the solution is ugly and contrived instead of elegant and simple. that's also what makes me skeptical of devs obsessing about typing (layouts, keyboards, editors, ...) to optimize it further. as a developer I never found speed of input to be even close to a bottle neck. the bottle neck usually lack of silence and peace in a large office which I need to think!

Reading this is making me sick. I am working on leaving my large company for a start up for this exact reason. Something as simple as changing a tag on a server requires submitting a request -> waiting for the reply that they are working on it -> getting someone contacting you 1-3 days later -> Confirming the changes you want -> finding the changes in place the next day -> telling them the ticket is closed.