4 ms·

I wonder if it is also the case that if the code quality is high, people are happy and they stay. This means fewer openings are available in those teams. Theref

I wonder if it is also the case that if the code quality is high, people are happy and they stay. This means fewer openings are available in those teams. Therefore, if you take a new job, it is more probable that the code is bad and there is a revolving door of developers who have tried to make it better, failed, left and created an opening for you. The vicious cycle of bad jobs.

Fuxy 10y ago
As I currently work at a company in this exact situation I can confirm it is very true. And to validate the article even more I am currently searching for better opportunities where I can work with better and more modern technologies.
- pc86 10y ago
  There's a big difference between "better and more modern technologies" and a fragile, brittle code-base that is difficult to change. They are not necessarily related to each other, either.
  - Fuxy 10y ago
    Not if it's written PHP and went through the hand of multiple developers in its early days when standards were less well defined. 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.
whack 10y ago
Honestly, I would get bored working at a place where everything is "easy". I actually enjoy the challenge of working on awful code-bases, and trying to improve upon it, while still preserving the functionality and not breaking anything. 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.
- OpenDrapery 10y ago
  I used to enjoy the thrill of the refactor, especially on applications where there weren't a lot of users or the product didn't generate much revenue. Or better yet, refactoring before the product has even been released. When the stakes are low, you can be much more fearless, and it is fun to rearchitect and introduce new patterns, etc. 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.
- collyw 10y ago
  I took that attitude with my new job, but the more I get to know the codebase, the more I dislike it, and there just isn't the time to rewrite everything.
- Obi_Juan_Kenobi 10y ago
  Is it really that different to put that energy into new features? I guess you lack the 'archaeological' aspect of deciphering old code, but there are still plenty of challenges. 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.
0xfeba 10y ago
Personal Anecdote: 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")
- Pamar 10y ago
  but it's ASP and SQL and most of the business logic is in SQL stored procedures. Can someone explain to me why this would be considered a bad thing?
  - 0xfeba 10y ago
    Let me be more clear: The entire application is written in SPs. They have a 3 tiered arch, but the FE and MT see 5% usage and the DB sees 95% usage. 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.

Fuxy 10y ago

As I currently work at a company in this exact situation I can confirm it is very true. And to validate the article even more I am currently searching for better opportunities where I can work with better and more modern technologies.

pc86 10y ago
There's a big difference between "better and more modern technologies" and a fragile, brittle code-base that is difficult to change. They are not necessarily related to each other, either.
- Fuxy 10y ago
  Not if it's written PHP and went through the hand of multiple developers in its early days when standards were less well defined. 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.

whack 10y ago

Honestly, I would get bored working at a place where everything is "easy". I actually enjoy the challenge of working on awful code-bases, and trying to improve upon it, while still preserving the functionality and not breaking anything. 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.

OpenDrapery 10y ago
I used to enjoy the thrill of the refactor, especially on applications where there weren't a lot of users or the product didn't generate much revenue. Or better yet, refactoring before the product has even been released. When the stakes are low, you can be much more fearless, and it is fun to rearchitect and introduce new patterns, etc. 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.
collyw 10y ago
I took that attitude with my new job, but the more I get to know the codebase, the more I dislike it, and there just isn't the time to rewrite everything.
Obi_Juan_Kenobi 10y ago
Is it really that different to put that energy into new features? I guess you lack the 'archaeological' aspect of deciphering old code, but there are still plenty of challenges. 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.

0xfeba 10y ago

Personal Anecdote: 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")

Pamar 10y ago
but it's ASP and SQL and most of the business logic is in SQL stored procedures. Can someone explain to me why this would be considered a bad thing?
- 0xfeba 10y ago
  Let me be more clear: The entire application is written in SPs. They have a 3 tiered arch, but the FE and MT see 5% usage and the DB sees 95% usage. 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.