Why my job sucks
My job sucks.
I’ve been moved to a different team again.
Evidently, I’m the shit-polishing guy.
Yes, the guy who loves taking large piles of crap and maintaining them.
Well, the co-workers, pay, benefits, etc., those are all fine. But it’s the work. It hasn’t always been that way, but lately I’ve been busy doing “technical evolution” (my boss’s words, not mine). What does this entail you ask? This is the work necessary to move very old applications off of unsupported hardware onto the currently supported and approved frameworks — read: not the latest and greatest; the stuff that has been approved for 5 years or so. And let me tell you, it isn’t fun. The technology is old. So old that I have to re-learn the stuff. (Throwback every-day-of-the-week anybody?) But that’s not the worst part. It’s the crappy code: poorly written monstrosities that I have to read.
I don’t think clean code was a thing back then.
What I see, and hopefully it is only at my job, let there be a god, is new programmers writing all of the code! New development must be the only way to lure new programmers. (I can’t think of any other reason at the moment.)
I see two reasons poor code is produced by inexperienced programmers. The first is they don’t realize the importance of maintainable code, or, the second reason, they think they are writing maintainable code.
Let’s discuss the second reason first.
New developers write code that is easy to understand for them. They are under the misconception that the code they are writing is very easy to understand. This is usually because they are the only one looking at their code and it was very recently written. They don’t have the experience of what to do and not do. They don’t know what it means to develop code for maintainability.
Seasoned developers have seen many different projects and learned what works and what doesn’t work. They are more realistic about designing a system. They have witnessed the pitfalls and are less likely to make them.
To address the importance of maintaining code, I suggest “allowing” new developers to support legacy apps. They gain the experience and appreciation of what “bad” (and good!) code can look like and not make the same mistakes. (And at the same time they might gain some business knowledge!)
The other reason I contest my job sucks is because all the new developers get to write code using cutting edge technologies and frameworks and tools. I, on the other hand, don’t get the opportunity to work with this stuff except at home. (Whereas a new developer might not have the same time commitments outside of work and have the time to learn new stuff.) What’s this mean? I am falling behind the times and becoming less relevant.
In conclusion, let the new developers gain the appreciation for and the knowledge how to create maintainable code by maintaining apps and let the experienced developers write new code that the noobies won’t mind maintaining.