Happiness... Passion... these terms don't mean anything when it comes to maturity as a programmer.
Maturity as a programmer means being able to identify and do what it takes to get things done. Whether a developer is "happy", or "passionate" only begins to matter when they're doing what needs being done.
A true sign of maturity is when a programmer is faced with a workload that they are deeply unhappy about, but still get it done, because it needs to be done. The corresponding sign of mature leadership is acknowledging that developer's unhappiness and giving them extra money, work they enjoy, and/or time off after the crap work is done.
I guess we're just maturing in different ways. Your definition sounds like a big company doing less-rewarding work and middle management. For me, it was realizing you don't have to move towards management or dealing with lots of "crap work" (can't avoid it all of course). Also with maturity comes the realization that things that need to be done and being happy while doing it don't have to be mutually exclusive.
If you were tasked with maintaining a 10 year old codebase, your happiness really doesn't matter. If you don't find code maintenance enjoyable work, you're not going to enjoy the work. Sure, you might be able to make a game of it - to make it enjoyable - but that has no real bearing on your maturity as a programmer, just your personality.
That some programmers truly enjoy their work is a gift that they are lucky to have; not a sign of maturity.
> If you were tasked with maintaining a 10 year old codebase
Then I quit my job. As a quality senior you have the leverage to pick where and how you work. Otherwise, you may be thinking of just a tenured junior or someone who was given a title of "senior". This is why I said earlier "part of maturing into a senior dev is having the experience to know what makes you happy"...not just doing what someone tells you.
Heh. I actually enjoy maintaining old code, as long as that means I can improve it while adding new functionality.
If it means "no, we can't change that method with a 200+ cyclomatic complexity because the NY office wrote it and they would be upset about it" then yeah, that would suck. (Real story in a recent contract with a bank.)
> A true sign of maturity is when a programmer is faced with a workload that they are deeply unhappy about, but still get it done, because it needs to be done.
I’d like to pause the ruby discussion here to point out this is a deeply unhealthy viewpoint—it’s your own funeral if you knowingly go to a job that makes you “deeply unhappy” every day. That’s not maturity, that’s self harm. Maturity is responsibility, including to yourself.
Hence the directly following comment about mature management.
Leaving if management is not mature is a perfectly reasonable thing to do; but not doing the work you've been given before you leave is irresponsible at best, petulant at worst.
A personal anecdote: I've been pushed into QA for several, because we needed it to be done, and I had the prior experience. I hate doing QA work. After the crunch was done, I took a break, then went back to work I wanted to be doing. And yes, perhaps this denotes a lack of hubris, but I consider that to be mark of maturity as an employee in me, and in my manager.
Maturity as a programmer means being able to identify and do what it takes to get things done. Whether a developer is "happy", or "passionate" only begins to matter when they're doing what needs being done.
A true sign of maturity is when a programmer is faced with a workload that they are deeply unhappy about, but still get it done, because it needs to be done. The corresponding sign of mature leadership is acknowledging that developer's unhappiness and giving them extra money, work they enjoy, and/or time off after the crap work is done.