Was employed, but searching for a new job. Interviewed a few places that required coding on whiteboards (ugh). Then interviewed at a place where they asked me only a few technical questions, but mainly about what I did at my previous position. Then one of the technical questions was what did HTML5 change about using <b> tags and such. And I said, uh, just use CSS. No, "HTML5 introduced <strong> for better semantics". Didn't disagree at the time, just said, "Interesting.", and looked it up later. Yeah, the strong tag has been there since at least HTML3.2
Whatever, they offered me nearly doubly what I was earning before, plus a sizable bonus. I figured it couldn't be that bad.
Well, it's bad. 4 people quit in my first week (out of, say, 20-25 devs). One was one of the persons who interviewed me. Months later, about 5 more people have left and been replaced. We've also added new members. My project isn't a trainwreck, but the main headache is the main project with a 30 year old codebase.
It's a mess. They are trying to revamp it in situ, but it's ASP and SQL and most of the business logic is in SQL stored procedures. They've really done some nice code* in the revamp but all it does is add layers on top of an eventual SP call.
So my project is humming along nicely, it's scheduled for a few years and I'm only going to be here a couple years anyway, so it's a nice step in my career to me. I just got lucky. I'd hate to work on the main product. Evidently everyone else does to because they keep churning through people.
*They don't believe in comments. The methods and stuff are clearly written, eg. CreateUserAndReturnUserRef and verbose stuff like that, but for some reason they don't have comments. Guess what other code doesn't have comments? The classic ASP and store procedures. Great habit to keep! Even my new project lacks comments. I add them, but no one else does. It's very odd. I've brought it up and gotten various excuses ("Comments rot, so we don't use them," "I just don't have time for comments" "Yeah I should add those")
Can someone explain to me why this would be considered a bad thing?
And they constantly have timeouts, table locking issues, errors, CPU usage problems, etc. I receive, literally, 10,000+ emails a month from automated error reporting from the DB servers.
Luckily it's not my project so I just have a rule to delete all of them.
And to validate the article even more I am currently searching for better opportunities where I can work with better and more modern technologies.
Coding in PHP has become a lot better over they years but if you have the misfortune of having to maintain legacy code it' s pretty much guaranteed to be a bad time.
No MVC, no templates, no PDO hell it's one step removed from the early days when everything was in 1 big file and nobody seems to be bothered by it or willing to budget time to rewrite it and eliminate the technical debt incurred every time you need to modify it.
That said, if I had to work with awful code and I wasn't allowed to touch it or make it better, I would definitely leave in a heartbeat.
But when the stakes are higher, the risk/reward ratio just isn't there. You can refactor the code to make it more sensible or pleasing to your eye. Two problems with this: 1) Someone else may disagree and refactor it again. 2) When it blows up or has unintended consequences, and you are now on the hot seat, you find yourself working on Saturday asking yourself if it was worth it at all. Thus the fear sets in.
I think it's also implied that, in a situation where technical debt isn't appreciated, it's unlikely that resources would be given to pay it down. Instead, it sits there making all work more frustrating, whereas a shop with minimal technical debt spends more time creating new, more robust, code.