4 ms·

I don't really buy that this is the main reason. A good senior engineer is for the most part able to not write bad code from day one, just at a very low speed a

by jeltz 11mo ago

I don't really buy that this is the main reason. A good senior engineer is for the most part able to not write bad code from day one, just at a very low speed and with the need to ask other people frequenyly. Even if you do not know the code base or domain yet there are a lot of things you can do to avoid writing bad code. Yes, as someone new you will make mistakes and misunderstand things but a lot of the bad code I have personally seen has not been caused by that. Most bad code I have seen has been caused by people rushing and not having their fundamentals in order. Like not actually doing reviews, not spending a few extra hours to think about architecture, etc. Also a big issue is that people just let the complexity of systems explode for the gain of short term projects. I think the issue is more that engineers face unreasonable pressure to deliver short term value and that there is no respect for the craft/engineering from many managers or even engineers.

morkalork 11mo ago
The worst code I've ever written is because of shifting or unforeseen requirements. It doesn't matter how good the architect is if the foundation is built on sand.
- jeltz 11mo ago
  100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I obviously will fail.
  - veverkap 11mo ago
    > If the foundation is built on sand then that needs to be fixed. Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.
    - jeltz 11mo ago
      It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
      - veverkap 11mo ago
        It depends a lot on the circumstance.
      - jimbokun 11mo ago
        Profitable over what time horizon?
        jeltz 11mo ago
        Any really. Rushing the team is more about looking good so you get promoted than about profit in any form.
      - Aeolun 11mo ago
        > This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term. Being delivered faster or cheaper isn’t the goal. The goal is to look good while doing it. Telling your bosses ‘Yes sir!’ Is apparently a lot more palatable than saying ‘No can do’.
  - toast0 11mo ago
    I've worked on projects where if you wait for the requirements to be firmed up, you'll never be able to do anything. Depends on what you're trying to build if that means you need to stop and figure out the requirements or if you need to just deal with the shifting sands. Aircraft built for moving requirements don't work so well; but lots of things are fine with moving requirements. It'd sure be nice to know how users are going to use your product before you build it, but sometimes you build what you think is wanted, and people only use part of it or use it for different things than what was intended, and it's better to adjust and refocus than to start a whole new development process with the found requirements.
    - jeltz 11mo ago
      Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirements is a fact you just have to live with in many industries.
      - Aeolun 11mo ago
        Changing requirements is fine. Changing requirements when it was eminently avoidable is very, very bad. If I asked you 6 months ago if you might ever consider something other than credit card payments, urged you to seriously consider this and you say no, you shouldn’t come to me now and say that bank transfers (bank transfers!) are absolutely indispensible.
veverkap 11mo ago
I think it's probably a bit of both. A good senior engineer may pick up a task and look at the system, seeing hacks duct taped together with kite string, and have the choice between "doing it right" (aka rewrite/refactor) and getting shit done.
- dave_sid 11mo ago
  They wouldn’t have to fix the entire codebase to be doing the right thing. That approach would be more likely taken by a junior who would soon find they are fighting a losing battle. The senior engineer would accept the state of the world and consider how to make small, deliverable, manageable improvements one PR at a time, to improve the code over a longer period of time without breaking the system.
godelski 11mo ago
> A good senior engineer is for the most part able to not write bad code from day one This seems unlikely. Self contained, I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior. But what is good code is in context of the codebase. It takes time to get the context of a reasonably sized codebase and no one is doing that in a single day or single week, even the wizards. I don't agree with everything the OP writes but I think they're correct in that many companies don't value institutional knowledge. To me that is lunacy. I'm not sure how any programmer could think a reasonably complex codebase could be learned quickly. The larger and more complex your codebase the more valuable institutional knowledge is. Adding new actors just accelerates complexity and redundancy. Pushing people to be quick only worsens this. The best thing to do with new employees is get them deep into the code. Have them write/update docs, do cleanup, or other tasks that force them to understand the code and how everything interacts
- Ygg2 11mo ago
  > I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior. You say that until you are tasked with doing impossible - three lines, all perpendicular, five green, two anti-green, seven in ten or more dimensions, any color; while customer only uses purple lines. Last guy that worked on it committed seppuku. Rest of team is in mental ward. Your only team member is guy that programmed his entire life in PHP, and doesn't know backend's language. Just teach him. Documentation, is spread between Jira, wiki, Markdown, ftp server and some napkins. CI stands for continuous Indians. You send code to India, where a team will assemble it. It may take anywhere between a few minutes or few hours. But it beats GitHub actions. Make sure to inspect artifacts, the Indian team has a habit to add some of their ""bug fixes"" covertly. But you gotta finish it by Thursday. Good luck.
  - Aeolun 11mo ago
    There is a magic word that adults sometimes use. It is a word you have to learn to master if you want to be any good at your job. No.
    - 11mo ago
nosianu 11mo ago
Then how do you work with this: https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 I did that job, just after university, but that is not my comment. I bookmarked it though because that person said it so well. You will write bad code, because what you already find there - and that one company is not alone! - is already so bad, there is no way to do a good job on top of literally millions of escalating hacks. And don't think that you could clean this up - not even with ten years of time is that possible. You can only rewrite from scratch. Trying to rewrite even a tiny part is like picking up one spaghetti and always ending up with the whole bowl on your fork.
- jeltz 11mo ago
  It is possible that some projects like Oracle are beyond hope but in general cleaning up a messy code base is done piece by piece and by refusing to merge most patches which make things worse. Better than you found it is the main principle.
- oceansweep 11mo ago
  Just wanted to comment on the fact that I remember seeing that comment, and it left such an impression I remember it 7 years later. Thanks for the reminder, going to bookmark it this time.
- pdimitar 11mo ago
  Rewriting from scratch is also included in "take a few hours to ponder architecture" contained in your parent comment.
tim1994 11mo ago
Another reason I can think of is the requirement not to introduce a breaking change. It is very frustrating if the codebase has a lot of hacky/bad code in it but a lot of it can't be changed...
alfalfasprout 11mo ago
> A good senior engineer is for the most part able to not write bad code from day one, just at a very low speed and with the need to ask other people frequenyly. Even if you do not know the code base or domain yet there are a lot of things you can do to avoid writing bad code. Yes, as someone new you will make mistakes and misunderstand things but a lot of the bad code I have personally seen has not been caused by that. Most bad code I have seen has been caused by people rushing and not having their fundamentals in order. Like not actually doing reviews, not spending a few extra hours to think about architecture, etc. Also a big issue is that people just let the complexity of systems explode for the gain of short term proje You have a very charitable view of the competency of the typical engineer at big tech nowadays. Ten years ago, sure. But with the advent of people purely studying for coding interviews that's changed.
- jeltz 11mo ago
  Maybe, but then they are not "good engineers". A blog post about bad engineers writing bad code is not very exciting.

by jeltz 11mo ago

morkalork 11mo ago

The worst code I've ever written is because of shifting or unforeseen requirements. It doesn't matter how good the architect is if the foundation is built on sand.

jeltz 11mo ago
100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I obviously will fail.
- veverkap 11mo ago
  > If the foundation is built on sand then that needs to be fixed. Except this is the system working as designed. Leadership 1000% wants to do things as fast and as cheap as possible.
  - jeltz 11mo ago
    It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.
    - veverkap 11mo ago
      It depends a lot on the circumstance.
    - jimbokun 11mo ago
      Profitable over what time horizon?
      - jeltz 11mo ago
        Any really. Rushing the team is more about looking good so you get promoted than about profit in any form.
    - Aeolun 11mo ago
      > This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term. Being delivered faster or cheaper isn’t the goal. The goal is to look good while doing it. Telling your bosses ‘Yes sir!’ Is apparently a lot more palatable than saying ‘No can do’.
- toast0 11mo ago
  I've worked on projects where if you wait for the requirements to be firmed up, you'll never be able to do anything. Depends on what you're trying to build if that means you need to stop and figure out the requirements or if you need to just deal with the shifting sands. Aircraft built for moving requirements don't work so well; but lots of things are fine with moving requirements. It'd sure be nice to know how users are going to use your product before you build it, but sometimes you build what you think is wanted, and people only use part of it or use it for different things than what was intended, and it's better to adjust and refocus than to start a whole new development process with the found requirements.
  - jeltz 11mo ago
    Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirements is a fact you just have to live with in many industries.
    - Aeolun 11mo ago
      Changing requirements is fine. Changing requirements when it was eminently avoidable is very, very bad. If I asked you 6 months ago if you might ever consider something other than credit card payments, urged you to seriously consider this and you say no, you shouldn’t come to me now and say that bank transfers (bank transfers!) are absolutely indispensible.

veverkap 11mo ago

I think it's probably a bit of both. A good senior engineer may pick up a task and look at the system, seeing hacks duct taped together with kite string, and have the choice between "doing it right" (aka rewrite/refactor) and getting shit done.

dave_sid 11mo ago
They wouldn’t have to fix the entire codebase to be doing the right thing. That approach would be more likely taken by a junior who would soon find they are fighting a losing battle. The senior engineer would accept the state of the world and consider how to make small, deliverable, manageable improvements one PR at a time, to improve the code over a longer period of time without breaking the system.

godelski 11mo ago

> A good senior engineer is for the most part able to not write bad code from day one This seems unlikely. Self contained, I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior. But what is good code is in context of the codebase. It takes time to get the context of a reasonably sized codebase and no one is doing that in a single day or single week, even the wizards. I don't agree with everything the OP writes but I think they're correct in that many companies don't value institutional knowledge. To me that is lunacy. I'm not sure how any programmer could think a reasonably complex codebase could be learned quickly. The larger and more complex your codebase the more valuable institutional knowledge is. Adding new actors just accelerates complexity and redundancy. Pushing people to be quick only worsens this. The best thing to do with new employees is get them deep into the code. Have them write/update docs, do cleanup, or other tasks that force them to understand the code and how everything interacts

Ygg2 11mo ago
> I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior. You say that until you are tasked with doing impossible - three lines, all perpendicular, five green, two anti-green, seven in ten or more dimensions, any color; while customer only uses purple lines. Last guy that worked on it committed seppuku. Rest of team is in mental ward. Your only team member is guy that programmed his entire life in PHP, and doesn't know backend's language. Just teach him. Documentation, is spread between Jira, wiki, Markdown, ftp server and some napkins. CI stands for continuous Indians. You send code to India, where a team will assemble it. It may take anywhere between a few minutes or few hours. But it beats GitHub actions. Make sure to inspect artifacts, the Indian team has a habit to add some of their ""bug fixes"" covertly. But you gotta finish it by Thursday. Good luck.
- Aeolun 11mo ago
  There is a magic word that adults sometimes use. It is a word you have to learn to master if you want to be any good at your job. No.
  - 11mo ago

nosianu 11mo ago

Then how do you work with this: https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 I did that job, just after university, but that is not my comment. I bookmarked it though because that person said it so well. You will write bad code, because what you already find there - and that one company is not alone! - is already so bad, there is no way to do a good job on top of literally millions of escalating hacks. And don't think that you could clean this up - not even with ten years of time is that possible. You can only rewrite from scratch. Trying to rewrite even a tiny part is like picking up one spaghetti and always ending up with the whole bowl on your fork.

jeltz 11mo ago
It is possible that some projects like Oracle are beyond hope but in general cleaning up a messy code base is done piece by piece and by refusing to merge most patches which make things worse. Better than you found it is the main principle.
oceansweep 11mo ago
Just wanted to comment on the fact that I remember seeing that comment, and it left such an impression I remember it 7 years later. Thanks for the reminder, going to bookmark it this time.
pdimitar 11mo ago
Rewriting from scratch is also included in "take a few hours to ponder architecture" contained in your parent comment.

tim1994 11mo ago

Another reason I can think of is the requirement not to introduce a breaking change. It is very frustrating if the codebase has a lot of hacky/bad code in it but a lot of it can't be changed...

alfalfasprout 11mo ago

> A good senior engineer is for the most part able to not write bad code from day one, just at a very low speed and with the need to ask other people frequenyly. Even if you do not know the code base or domain yet there are a lot of things you can do to avoid writing bad code. Yes, as someone new you will make mistakes and misunderstand things but a lot of the bad code I have personally seen has not been caused by that. Most bad code I have seen has been caused by people rushing and not having their fundamentals in order. Like not actually doing reviews, not spending a few extra hours to think about architecture, etc. Also a big issue is that people just let the complexity of systems explode for the gain of short term proje You have a very charitable view of the competency of the typical engineer at big tech nowadays. Ten years ago, sure. But with the advent of people purely studying for coding interviews that's changed.

jeltz 11mo ago
Maybe, but then they are not "good engineers". A blog post about bad engineers writing bad code is not very exciting.