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.
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.
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.
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.
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.
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.
> 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
> 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.
Words aren't absolute. No reasonable interpretation of my comment suggests I'm saying you should do the impossible.
If someone asks you to do the impossible you have to say no. Better yet, you should figure out what they actually do want. They can't get the impossible, that's not on the table.
The worst thing an engineer can do is not learn how to say no.
I'll even say, if you don't know how to say no then you're not qualified to be a senior
My CTO, when told that adding scope, reducing headcount, and keeping the same timeline all while discovering new unknowns in the codebase was not possible, we were simply told to make the date and asked who's performance review will be impacted. The "no" was entirely ignored. "I don't accept that."
Your assumption that seniors will be able to output good code in any situation is what is the issue.
As a senior I've been tasked with impossible tasks, with insane deadlines, in ""enterprise"" code bases. Sure, saying NO is an option, but being the NO guy is surefire way to getting fired. And nothing looks better on resume than repeated firings.
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...
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.
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.
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.
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.
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.
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.
> 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’.
> 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.
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.