I've been programming for 53 years and have never been burnt out from the act of actually building software. In fact it's been the opposite for me. Every time I've ever had a significant challenge, alone or in a small competent team, to get something built quickly and right, I've savored that challenge. The times I've sat up all night long coding are some of my fondest memories. I remember with startling accuracy every time we struggled getting something to work, got it figured out, and danced. I remember every white board, direct message, even every slice of pizza in the trenches.
I've even commented here on HN many times that I've never been burnt out coding and never will be. I'd be the last one out of here to turn off the lights when everyone else was burnt out.
But now I am most certainly burnt out, not from building software, but from being incarcerated in dysfunctional I.T. hell.
For OP and the posers who think they understand the mindset of serious software developers, here's what really burns us out:
- the same stupid meeting every morning where nothing is raised or closed and no non-programmer has a clue
- taking direction from the same clueless bosses who have never accomplished anything but treat us like their children
- the new technology or philosophy du jour that does everything but address the root of any problem
- management that absolutely cannot grok fundamentals like cause/effect, critical path, detail/issue, urgent/important, diminishing returns, etc.
- continuous leadership bombardment of idiocy and stuff we know can't work
- management's complete failure to solicit or accept feedback from those of us who actually know
- nothing written down and no one remembering anything
- confusion by almost everyone about the difference between activity and achievement
- no written business requirements, technical specs, or test plans, but instead, some new untested methodology
- leaders who don't understand the difference between steak and sizzle
- continuous business failures because of poor leadership, not technology (and they keep doing it!)
- I could go on and on, but I wouldn't get anything done today and be just like my boss.
I'd love to see an OP that addresses any of all of these things I've been suffering from for years, instead of a headline with a precise metric on a misunderstood premise.
I'll suffer all day today and then to get rid of the corporate stink, build something cool for myself later tonight. That's not personal burn out, it's industry burn down.
I largely agree but I would like to add that much software we developers work on today works against developer satisfaction.
Bizarre architecture choices based on trends, tedious build steps, complex development setups with hours spent on configuration, etc.
Software development has become a time sink into things that has nothing to do with the actual task at hand.
This annoys me somewhat more than a clueless manager, who can be forgiven for not understanding software development, because these software architectural problems is something we developers created, willingly.
All these programmers agreeing to IMO the worst culprit to programmer burnout. I still struggle understanding who these people are and why they support this cult. Every excellent programmer I've ever worked with just laughs at this.
My homegrown conspiracy theory is that Agile was invented by project managers that wanted to constantly change project goals.
Broken pleb developer - Why are why yet again changing project goals? We already changed them last week after a long meeting.
Carefree Manager - It is Agile to adapt!
Core of Agile makes sort of sense, that you continuously involve the client and iterate thru the project to create a product that meet client demands. However that also assumes that you are working with clients that are competent, in the real world most clients are clueless. Now you have a clueless client and a clueless manager running the project to the torment of the developers.
In my own experience after working at different management positions (team lead, scrum master, senior developer, project manager, technical project lead, architect etc) is that the vast majority of developers, me included, are uninterested in project management, they just want to code. Thus when I run projects I run it as a dictatorship instead of a democracy (scrum) and give the developers the tasks that fit them based on their skill level. This requires some skill in understanding your developers needs, 1) that they feel that they make a difference, 2) that they have some freedom on how to solve each task, but within the constraints of the architecture and project. It usually works best for everyone involved.
If there are some developers that do enjoy project management (often they are knee deep into scrum theory and such) I handle them separately from the rest of the team and do some project management with them only. No reason to involve the entire team just because a single developer enjoy retrospect meetings. If there any valuable conclusions (rarely) you can introduce it to the rest of the team afterwards anyway.
Scrum and such theories assumes that every developer are equally engaged in the project, in reality that never happens because we have different personalities, different skill level and different priorities, thus making a developer to "freely" pick a task from a board of tasks is just nonsense. We all know in advance who will do what, it is just a charade. Same goes for planning tasks, if you have no idea how to implement a task you can't really help with planning it either.
The common timeboxed two week scrum iteration is probably one of the most common reasons why developers feel stress.
Morning meetings must have an agenda, a chairman and be timeboxed, otherwise it is a waste of time. Personally I find that asking what everyone is doing is a bit unnecessary, most people don't care and wont listen anyways. It tends to be better to use that meeting to inform what is happening next in the project.
Common among developers is that they are a bit socially inept, however many of the scrum ideas force them to into socially awkward situations, I view that as bad company policy.
Clients needs to be handled individually on case by case basis, you can't run an entire project management style based on the assumption that clients know what they are doing. Most clients will accept your decisions if you present them confidently, they view it as they pay a professional so solve their problem, similar how you would hire a carpenter.
I really wanna hear more from people like you about how to survive and thrive for so long in tech.
What kind of work do you do?
What are your tips for a good and long tech career?
I mostly write applications for large enterprises and SMBs. Stuff most people think is boring but is really cool and runs the world: order processing, supply chain, operations, ecommerce, etc. I try to stick to relatively simple and effective technologies, but that's becoming harder and increasingly complex.
What had worked best for me (in descending importance):
1. LOVE building. If you're not getting satisfaction at work, build something for yourself at night. It's my rush.
2. Become excellent at what you do. Think Steve Martin, "Be so good they can't ignore you."
3. Volume. Build. Build. Build. I still think this is the best way to learn and get good.
4. Keep learning. The best way: building something, then learning what you need to build it, not the other way around (class, book -> then build).
5. Understand the people side and the tech side are very different. Embrace both, but differently.
6. Build something that builds something. The nested learning is magnitudes more effective.
7. At some point do a startup. Even if it fails, you will be much better.
8. If it stops being fun, do something else. (I've always stayed a programmer, but if I couldn't keep it fun, I would have become a bartender, or a writer, or something).
[5] is super key. That's what gets you to Staff+ and what gets you paid a lot of money (in real dollars, and especially in equity).
[7] assists you in getting to [5], but if you want something quicker, try consulting or pre-sales. You'll definitely need to build, but 60-80% of the work is driving people that you don't manage towards an outcome or selling people on an outcome (that, ideally, your stuff helps them achieve).
I've even commented here on HN many times that I've never been burnt out coding and never will be. I'd be the last one out of here to turn off the lights when everyone else was burnt out.
But now I am most certainly burnt out, not from building software, but from being incarcerated in dysfunctional I.T. hell.
For OP and the posers who think they understand the mindset of serious software developers, here's what really burns us out:
I'd love to see an OP that addresses any of all of these things I've been suffering from for years, instead of a headline with a precise metric on a misunderstood premise.I'll suffer all day today and then to get rid of the corporate stink, build something cool for myself later tonight. That's not personal burn out, it's industry burn down.