4 ms·
Most 9-5 employees work a lot less than you think. Coders tends to think of productivity as all day long. Any task that isn’t coding is not productive. Look at
by demygale 6y ago
Most 9-5 employees work a lot less than you think. Coders tends to think of productivity as all day long. Any task that isn’t coding is not productive. Look at a day in the life of management or administrative roles and you’ll see why the burn out a lot less.
- giantg2 6y agoI'm a coder and I can say that I sit in about 3 hours of meetings per day. It's brutal.
- tmaly 6y agoI feel the worst kind of meetings are those without an agenda. The best kind of meetings have an agenda sent out well in advance.
- giantg2 6y agoThat is a big help for the meetings that are necessary. We could avoid 75% of our meetings if the business knew their processes. If only they could make a business process map...
- brutus1213 6y agoHmm .. I moved to management and have to disagree with you. It is a shit ton of work dealing with so many people, projects, technologies, etc. It feels not worth it from a dollar perspective or a sanity perspective. To summarize, burn-out is a very real danger for managers and founders. I know of some founders who made it big .. in their early days, we'd joke about back-up plans when it all crumbles. To give an example of someone I don't know directly .. even Elon Musk had a backup to move into his wife's parent's basement when his company collapsed (per my recollection, this is in the Ashley Vance book). Speaking of Elon again, it seemed he did burn out post paypal .. his send a rocket to Mars seemed like a crazy idea to get him motivated again.
- andor 6y agoI have to disagree. Coding can be quite satisfying. I make something, I can see it working, I know I contributed something useful. In management roles, both contributions and feedback are much more indirect. Often it's not clear whether the work is useful and what the work even is. If something is not right, as an engineer I can just fix it, while as a manager I need to convince other people to fix it for me. Also, managers generally stand between teams. While as an engineer in a team, interactions are generally positive if the team is working towards a shared goal. Managers on the other hand typically liaise between groups that have conflicting goals.
- me_smith 6y agoI completely agree with this. It isn't just managing the day to day or the current project, but it's managing the growth of the team for the future. Seeing the results of your work may take days, weeks, months or even years. Also, dealing with conflict (and there will be conflict) between team members, teams or other managers can drain a lot of energy out of me. Sometimes, at the end of the day, I just want to do absolutely nothing.
- Spartan-S63 6y agoI think part of the burnout is the fetishization of "coding." This concept that you have to be cranking out code to be productive is frankly untrue and unhealthy. The thing that software engineers do is solve problems and a lot of their day can be spent thinking about solving the problem and that's perfectly productive. I'd rather spend six hours thinking about a problem and an hour implementing it, than blindly write code for hours because I haven't spent time considering how to approach the problem. Management and administration, though, can be just as taxing. It's a lot of people interaction, which can be draining. It's also a job where you have to keep a bunch of balls in the air without dropping them. I've done a little of both as anchor/lead in previous roles and it's draining to do either and especially draining to do both (but extremely rewarding).
- tmaly 6y agoI agree that a lot of non-coders see a coder not typing on the keyboard as not being productive. Thinking is one of the most underrated skills in the world.
- Spartan-S63 6y agoGoing from a culture where I pair programmed all day and mostly just pulled stories from the backlog, working from home in an org where pairing is less prevalent (but not non-existent), it's taken me time to retrain my personal expectations that it's okay to count work time as time spent thinking about how to solve the problem.