The big money question is: How have you managed to stay passionate about your job?
I just posted a comment in another thread about burnout. It's very common in our industry. I believe it's due to the Coolidge Effect. Aka, the brains inherent search for novelty. It's a struggle to not look at almost all programming tasks as just some variation of the same problem, if you've been doing this long enough. How do you keep it interesting enough, to stay passionate?
I had a bit of a burnout around 2006 -- I had worked my ass off on a fantastically complex framework, the pinacle of years of experience, and it was a joy. It was SO cool. There was an application on top, which was also pretty cool.
And the marketing bods/management and so on more or less dragged the project off track, up to the point I didn't want to work on it at all, I quit, I left my 'baby' and had a hard 6 months where I didn't really want to do anything... Good thing is that I became a pretty competent landscape photographer along the way...
Nowadays, I work a LOT more like a mercenary. I don't mind working on projects that leads straight to the wall -- NOBODY will listen to you, or trust you've seen that 12 times before.
So as far as I'm concerned, I enjoy the work, the architecture, the TECH challenges, and everything which gives me a quick, and I completely ignore the outcome in the end. Sure, if it's a success, whoohoo whoohoo but I no longer put the same amount of 'care' and 'ownership' in what I do. I just let it go, and do something else just as efficiently.
It might sound cruel, but for the like of us who REALLY get a kick from designing/building/implementing stuff, it's actually quite liberating.
I just smile benignly on at the idiots in the room sometimes, it's quite relaxing :-)
There's a certain point where you've been abused so much, you've GOT to let go. The reality is, we don't work on these projects in a vacuum. Rarely do we have full control and responsibility for the outcome. If you can't control something, you can't hold yourself accountable for its success or failure. I still do my best work but if I'm put in an impossible situation, my outlook is similar to yours.
Heh, respectfully, I think we're talking about two different kinds of burnout.
The form I am referring to, builds steadily over time. It's not the result of some bad interaction with management, rather, it's the result of doing the "same" thing for 30 years.
I recognize that the problem is in seeing it as the "same" thing. Yet, given our job as programmers is often to see the forest through the trees, to identify patterns, it becomes hard not to see yourself as solving the same set of problems over, and over, and over, and over.
That's the type of burnout I'm referring to. I'm guessing you don't struggle with that at all ;)
Well to be fair I went from doing well over 20 years of Mac programming with a lot of UNIX/Linux alongside to a semi-hardware developer with linux low level stuff, pure embedded and FPGA development...
There's LOADS of fields that you haven't done. I remember my first time trying to get my head around some VHDL code and I felt I was 12 years all over again looking at 6502 assembly code.
It's quite strange and yet makes sense, that embedded salaries are lower than easier higher level development. On the one hand, embedded is NOT the kind of thing some random 14 year old kid can do, whereas iOS/Android/Web is. But unfortunately, there's just not the plethora of jobs demanding embedded folks.
Yeah, as someone who generally winds up rewriting the mess that you wrote for everyone in the room, I really wish you'd pay more attention to the outcome in the end.
Not as old as op but approaching 40 fairly shortly.
Most programming tasks are a variation of the same problem, you realise it, accept it and then realise that the way to write good software is to get decent at the building bit and then work on getting decent at all the other bits around it.
Requirements gathering (aka talking to people and writing down/recoding what they say), testing (hitting things until bits fall off), reliability (making sure things don't break the same way twice), documentation (making sure the poor sod in after you has more to go on than you inherited).
There is a tonne of variation in what the average dev has to do day to day (unless you are a "Here are the requirements, you can change nothing, implement this spec, never question it" dev - in which case I pity you) so the trick is to keep learning in multiple domains when one gets stale rotate to another, variety is as they say the spice of life.
Not the OP, but I'm 51 ;-) This week I'm writing some logging code for about the 1 millionth time. Logging is fascinating. What's the best way to do it? Global variable? Send a parameter to basically every function? And then when you log something, you need a time stamp. Where do you get it from? Do you insert side effects into virtually every function? Do you have any choice? It's amazing. I can write it a hundred different ways and I have no idea which way is best. How do I get past that?
Every day is the same. If you want to search for novelty, it's the fact that it is the same problem and it's been broken from the beginning of time. So do something else! But what? That's what drives me.
You can't dally, either. It would be easy to just spend a year logging (and probably get nowhere). But you can't do it in a job. They won't stand for it. So what can you do in your few minutes of leeway? What difference can you make? You aren't going to fix it, so how can you extract just a tiny bit more information so that maybe someday it will all click?
I think most people don't care about this stuff. Programming is inherently boring. You need to care about insignificant details to really get deep into programming, I think. I mean, it doesn't really matter. Global variable, passed parameters. It sucks one way or it sucks the other way. Who cares? Only crazy people, probably. But in my opinion, that's where the fun is.
I know a guy who I think, without exaggeration, is one of the best software engineers on the planet (in the top 10%, anyway). He burnt out big time a decade or so ago.
His solution: he became a long-haul truck driver (he asserts that the skill overlap between software engineering and long-haul truck driving is far larger than you'd think). After a couple of years doing that, he reentered the software engineering world, completely revitalized.
"I believe it's due to the Coolidge Effect. Aka, the brains inherent search for novelty."
But I can't think of a better industry than software development to satisfy the search for novelty. There's always something new and interesting to learn.
I just posted a comment in another thread about burnout. It's very common in our industry. I believe it's due to the Coolidge Effect. Aka, the brains inherent search for novelty. It's a struggle to not look at almost all programming tasks as just some variation of the same problem, if you've been doing this long enough. How do you keep it interesting enough, to stay passionate?