6 ms·

I've tried this approach in the past and and it has made me very bitter. Eventually I realized that the company I worked for enforced no accountability for bad

I've tried this approach in the past and and it has made me very bitter. Eventually I realized that the company I worked for enforced no accountability for bad code, so I would often open the solution later and found a pile of ugly hacks or other mess. Code reviews? Refactoring? "We don't have time and no one is going to pay for it". Eventually you come to a conclusion that if no one cares then why should you? If any effort on your part is going to be negated by your coworkers anyway then why bother? How do you push back against a corporate culture that has been there for years and no one seemed to have a problem until you came along? Maybe it's possible when you're a senior dev that has control over a project, but as a mid level developer I've never been successful at enforcing any standard - people usually don't care because it would mean additional work and effort on their part and they still get paid the same regardless of the quality of the code.

Terr_ 9y ago
I'm in a similar situation right now: The company thinks that any feature-wanter who's loud enough is automatically "one of the product owners" (always plural, always ambiguous) with the ability to tap an outsourced development house for "additional capacity." I regularly come across months-old new code that the main team wasn't even consulted about. Reinvented caching layers, eval'ed code in database tables, file-download endpoints that accept any path from the browser, and code with so many immediate red marks that the writer can't possibly have been using an IDE. It hurts my pride that I've been here for years and can't seem to change the pattern, but perhaps at some level it's basically codependence [0] and I have to leave the sick corporate-entity until they really "want to change." [0] https://en.wikipedia.org/wiki/Codependency https://en.wikipedia.org/wiki/Codependency
- SIRHAMY 9y ago
  At that point, you could probably bring in Legal. Not only are these just poor coding practices, but some of these things are very serious security vulnerabilities. If you've got contracts with clients, or even if you're licensed straight to individuals, it's a good bet that you're breaching some data security/privacy rules. Legal would definitely want to know and take steps to correct.
  - user5994461 9y ago
    This is terrible advice. Do not go to legal for this, ever. This is putting yourself and the company in a very bad position. Fix the vulnerability if you can. Help junior developers understand common issues if you can. Then move on to the next job with better practices.
  - dragonwriter 9y ago
    > but some of these things are very serious security vulnerabilities. That's a very good reason to bring in your Security Officer or a similar compliance officer; its probably not a good reason to go straight from dev to Legal.
ThrustVectoring 9y ago
This is why you want to do some work in the interviewing steps to see if the company you're considering has a culture of code quality and mature engineering processes. "What do you need to do to release code?" "Do you do code reviews?" "How do you set aside time for refactoring?" and so forth
reaperducer 9y ago
It can be very frustrating, but ultimately it's a reflection on you. Whether you're a coder, or a librarian, or a janitor, take pride in your work. Do the best job you can. If everyone else's code looks like crap, that's on them. When new people come on, they'll see your work compared to the slackers, and start emulating you, not them. Like anything in life: Do the right thing, even when you're surrounded by villains.
- Balgair 9y ago
  Put another way: "If it's just a stepping stone, then be fascinated by the shape of the stone" -Ze Frank
- nightski 9y ago
  A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful. I'm not saying code quality doesn't matter, of course it does. But there is a bigger picture and if you don't take the time to become a part of that you will not be very relevant.
  - zoul 9y ago
    I agree, but it seems to me that being dragged down by technical debt is massively more common in our industry than missing important deals because of excessive emphasis on clean code?
    - ravenstine 9y ago
      Our industry is pretty hilarious in this sense. In school, it's expected that you go through multiple drafts to complete an essay, and usually those who skipped that process paid a penalty. Publishing is a high speed industry, but time is still set aside for revisions and editing. These same standards seem to rarely be applied in programming, I guess because our work isn't seen as writing communication. We make computers "go". Because of that, we are too often writing and reading each others' rough drafts.
Retric 9y ago
Don't stress about code quality. Quality code is it's own reward. Yes, clean code is more fun to write and work with. But, just think of it as a different kind of optimization problem. If the investment is not going to pay off in the future, then it's not worth doing in the first place. PS: This is not giving up, it's about getting even better by becoming ever more flexible.
- mike986 9y ago
  this is very selfish, unless you're the only developer in your shop. whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU
  - drdeadringer 9y ago
    Not just your coworkers today, "future you" as well. I've known of or read the situation where someone opens some old code, thinks "Who wrote this hot garbage?", and then realizes it was them.
    - Retric 9y ago
      If it worked for a year without bugs, then it's not garbage. Did it work? Can you read and understand it? Then it has value.
      - user5994461 9y ago
        Unless it had no users or it was so much garbage that nobody reported any bug.
        Retric 9y ago
        That would mean it did not work.
        Retric 9y ago
skookumchuck 9y ago
I've seen a lot of well-intentioned code refactoring that made the code objectively worse. Refactoring well takes a pretty seasoned programmer to do it.
akud 9y ago
It's not a tradeoff. The reason we like quality code is it saves time in the long run by being clear, easy to change, less error-prone, etc. If you expect to be employed in 6 months, you should be refactoring and putting care into the quality of your code. It's hard at first, but I'm at a point where I'm the most productive engineer and I work the least amount of hours - because my code is there to help me, not hurt me.

Terr_ 9y ago

I'm in a similar situation right now: The company thinks that any feature-wanter who's loud enough is automatically "one of the product owners" (always plural, always ambiguous) with the ability to tap an outsourced development house for "additional capacity." I regularly come across months-old new code that the main team wasn't even consulted about. Reinvented caching layers, eval'ed code in database tables, file-download endpoints that accept any path from the browser, and code with so many immediate red marks that the writer can't possibly have been using an IDE. It hurts my pride that I've been here for years and can't seem to change the pattern, but perhaps at some level it's basically codependence [0] and I have to leave the sick corporate-entity until they really "want to change." [0] https://en.wikipedia.org/wiki/Codependency https://en.wikipedia.org/wiki/Codependency

SIRHAMY 9y ago
At that point, you could probably bring in Legal. Not only are these just poor coding practices, but some of these things are very serious security vulnerabilities. If you've got contracts with clients, or even if you're licensed straight to individuals, it's a good bet that you're breaching some data security/privacy rules. Legal would definitely want to know and take steps to correct.
- user5994461 9y ago
  This is terrible advice. Do not go to legal for this, ever. This is putting yourself and the company in a very bad position. Fix the vulnerability if you can. Help junior developers understand common issues if you can. Then move on to the next job with better practices.
- dragonwriter 9y ago
  > but some of these things are very serious security vulnerabilities. That's a very good reason to bring in your Security Officer or a similar compliance officer; its probably not a good reason to go straight from dev to Legal.

ThrustVectoring 9y ago

This is why you want to do some work in the interviewing steps to see if the company you're considering has a culture of code quality and mature engineering processes. "What do you need to do to release code?" "Do you do code reviews?" "How do you set aside time for refactoring?" and so forth

reaperducer 9y ago

It can be very frustrating, but ultimately it's a reflection on you. Whether you're a coder, or a librarian, or a janitor, take pride in your work. Do the best job you can. If everyone else's code looks like crap, that's on them. When new people come on, they'll see your work compared to the slackers, and start emulating you, not them. Like anything in life: Do the right thing, even when you're surrounded by villains.

Balgair 9y ago
Put another way: "If it's just a stepping stone, then be fascinated by the shape of the stone" -Ze Frank
nightski 9y ago
A contrary opinion based on experience - instead of focusing so much on how bad the code is take the time to get to know your coworkers better. Talk with your manager and the business leaders about the business. Learn more about the business you are in and how your code makes an impact to that business. At the end of the day the goal is not to produce clean code. It's to make your company successful. I'm not saying code quality doesn't matter, of course it does. But there is a bigger picture and if you don't take the time to become a part of that you will not be very relevant.
- zoul 9y ago
  I agree, but it seems to me that being dragged down by technical debt is massively more common in our industry than missing important deals because of excessive emphasis on clean code?
  - ravenstine 9y ago
    Our industry is pretty hilarious in this sense. In school, it's expected that you go through multiple drafts to complete an essay, and usually those who skipped that process paid a penalty. Publishing is a high speed industry, but time is still set aside for revisions and editing. These same standards seem to rarely be applied in programming, I guess because our work isn't seen as writing communication. We make computers "go". Because of that, we are too often writing and reading each others' rough drafts.

Retric 9y ago

Don't stress about code quality. Quality code is it's own reward. Yes, clean code is more fun to write and work with. But, just think of it as a different kind of optimization problem. If the investment is not going to pay off in the future, then it's not worth doing in the first place. PS: This is not giving up, it's about getting even better by becoming ever more flexible.

mike986 9y ago
this is very selfish, unless you're the only developer in your shop. whoever works with you will have to bear the burden that you left behind because you think its a low ROI for YOU
- drdeadringer 9y ago
  Not just your coworkers today, "future you" as well. I've known of or read the situation where someone opens some old code, thinks "Who wrote this hot garbage?", and then realizes it was them.
  - Retric 9y ago
    If it worked for a year without bugs, then it's not garbage. Did it work? Can you read and understand it? Then it has value.
    - user5994461 9y ago
      Unless it had no users or it was so much garbage that nobody reported any bug.
      - Retric 9y ago
        That would mean it did not work.
        Retric 9y ago

skookumchuck 9y ago

I've seen a lot of well-intentioned code refactoring that made the code objectively worse. Refactoring well takes a pretty seasoned programmer to do it.

akud 9y ago

It's not a tradeoff. The reason we like quality code is it saves time in the long run by being clear, easy to change, less error-prone, etc. If you expect to be employed in 6 months, you should be refactoring and putting care into the quality of your code. It's hard at first, but I'm at a point where I'm the most productive engineer and I work the least amount of hours - because my code is there to help me, not hurt me.