Hacker News Reader

Comment by jeltz | Hacker News Reader

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.

View on HN

Then how do you work with this: 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.

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.

Rewriting from scratch is also included in "take a few hours to ponder architecture" contained in your parent comment.

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.

But you gotta finish it by Thursday. Good luck.

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.

Saying no is a privilege.

It's easy to say if you have other options.

It's extremely hard to say if others depend on you saying yes.

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

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.

Again, you need to reasonably interpret what I'm saying. Picking out an edge case and acting as if it is some mic drop is disingenuous. We can't communicate if you hyper fixate on one tree when our discussion is about the forest. Language isn't precise enough to do that without getting extremely verbose. So either I can write a novel in response (I'm not going to) to explain what I said above or you can work with me here. If you're really not getting it I'm sure an LLM could help you out if you also fed it the responses.

  > As a senior I've been tasked with impossible tasks

Sure. Even juniors get this. But an impossible task is an impossible task.

  > Sure, saying NO is an option

Saying no is always an option. When given an impossible task it's the only option. There's many ways to say no. Not delivering is one of them

  > being the NO guy is surefire way to getting fired.

You do not get fired for saying no, you get fired for how you say no. You get fired because the project fails. You get fired because you push back against an egotistical manager who doesn't understand the problem and none of the other engineers back you up.

It's all about how you say no. You don't have to use the word to do so. Instead lead them down the right path and make them understand. You don't lecture them. Managers are like cats, you have to make them think it's their idea. So you have to ask clarifying questions and when doing so you can introduce explanations that let them know that it's not possible. The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.

You are not a mindless automata directed by your manager. That's not the role of a senior. Your job is to get things done. A senior knows that "the customer" (in this case your manner) doesn't know what they want and doesn't know how to say what they do. The job is to figure that out as best as possible

> We can't communicate if you hyper fixate on one tree when our discussion is about the forest.

All I'm saying is you can't expect perfect code in impure systems.

> You are not a mindless automata directed by your manager.

I never said I was, but I also can't turn a ship on a dime. I'm asked to perform a task; I'm going to perform to the best of my abilities, but in impure systems the best you can do is patch the leaking part with code and do some basic refactoring. Any moment spent trying to simplify and fix the software will be rightfully considered a waste.

Because a feature sold is better than performance gained (unless it's utterly abysmal).

> The goal is to put all the puzzle pieces on the table, put the right ones next to each other and let them put the final pieces together. If they don't then they don't feel like they did anything.

Again, in impure systems half the puzzle pieces have left, some other parts of other puzzles have been mixed, and it's the clock is running.

The more you focus on cleaning code, the more you are falling behind feature wise. Up until a point that you can present to managers "Shit is very bad, we need to refactor."

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."

How do you say no in that situation? Just quit?

> How do you say no in that situation? Just quit?

Apparently so. It seems GP never had to pay for their siblings to get through college, while paying rent.

Just say no, quit, and ruin life of your loved ones, and become homeless. Ez.

The GP has been homeless and lived off of discarded food.

You're right that saying "no" is a privilege. But also there's nothing as empowering as knowing that it's not going to be as bad as it was before.

Stop making assumptions about me and start trying to communicate with me. We can't talk if you want me to be wrong and just reinforce your position.

And sorry, I'm not as good as doing the cat wrangling in social settings as I am in technical ones. It's a different set of tools to work with and much harder to do in an online setting.

I did talk to you. Seniors don't matter, neither do junior, janitors, and to large part execs and CTO.

Processes, and the whole structure of company, and past events determines the outcome not individuals. And on top of that broad economic movements.

A good carrot in a rotten soup, is just a rotting carrot to be.

You're right that it is the whole structure, but the whole structure is made of people, individuals. Collective action can't happen without individual action. You don't just magically go from no people doing something to everybody doing something. You start with one person doing something, then more, and more, and it spreads like a virus. Both good and bad behavior spread this way, not instantly.

Look, our literal job is to take hard problems and break them down into small and more manageable problems, right? Addressing the whole company is too big of a problem, you have to break it down. You, you are an addressable problem that you can change. The people close to you? Harder, but easier than those far away. They're also easier to convince when you make the change yourself.

Or you can just give up and rot in the soup. Would you rather try to remove the rot from the soup or bathe in it?

I think bosses are like cats, when training them you have to make it think it is their idea. As I said in a sister comment the best way to do this is to not say the word "no" but to ask clarifying questions[0] so that all the puzzle pieces get placed on the table. Together you can assemble most of the puzzle, taking the lead but not lecturing them. But the final pieces have to be put together by them. Management is egotistical and if you just tell them then they get upset.

Your loyalty should be to the company, not the person. So by just "falling in line" you are failing the company.

Remember, if the project fails (and it will fail if it is impossible) people get fired anyways. Sure, getting fired later is better than sooner but it is still gonna happen.

[0] In your exact case, find out what they are actually after. Sounds like it might be a budgeting problem and they only know how to pull a few levers. They're business people, not technical people and they're working in a world that is highly technical. They're really a fish out of water and they don't know it[1]. It might be greed or panic too, which are harder to deal with and in those cases yeah, you should start looking for new work.

[1] I'm not saying a techie as a CEO or in a management position wouldn't be a fish out of water either. That'd be similarly as naive. But a well functioning workplace has to understand that these are different skillsets and we have to intermingle. You can't know everything so we have to work together to leverage our niche expertise.

I get the feeling you didn't work in a dysfunctional company.

Here is some anecdata. I came onto a team, that had team lead, product owner fight tooth and nail to not use boolean special flags for some case.

Instead the Product Lead went to CTO and overruled them. A product lead that ain't a programmer told programmer's to shove it, and do how he wants it.

This flag along with many, many such cases has been caused problems ever since.

Actually I worked for a failed startup where everyone left because they disliked management. In that startup I was the lowest paid engineer and the only non "staff" level one who had a contract bringing in money to the company. My last employee review with the company was terrible even though they admitted in the meeting that I had achieved all the goals and gone above and beyond what they had requested I do to get a promotion[0]. It was pretty clear it was about money, I asked if this was actually a performance issue or a money issue. The conversation changed though still ended up being very political...

This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences.

Management makes or breaks a company. As an employee it is your job to help ensure the culture works. But you can only do so much too. I'm not saying change the world. As a standard employee if things are going south, it is time to brush up your resume and start shopping around. You can interview without taking a job. You're not stuck where you are, so stop acting like that. The problem with your point of view is that you act like you have no options. It is either work for where you work now or have no job. Don't quit until you have something else lined up. But also don't be afraid to quit. It's not worth being miserable. Interviewing to find a better fit is infinitely better than hating yourself day in and day out, more and more as time goes on.

I'm not saying it is easy either btw. It definitely takes work! But neither are you stuck.

[0] I came with receipts. I had them give me a comprehensive goal list in my previous year's performance evaluation because I had already recognized some of these issues. So I wanted something in writing. It helps. (And btw, I even had a meeting with my direct manager 6mo in and 3mo before the yearly review to make sure I was on track)

> This is part of why I'm insisting you need to work with me to be able to communicate. You are reaching for assumptions that justify your position. My opinions are shaped by these TERRIBLE experiences.

Not really. I'm reaching my conclusion after several experiences in various domains (fintech, ad tech, logistics software, and government-adjacent firms). Each company is terrible in its own little way. The reasons aren't always the same, but they can vary from colleagues to bizarre pipelines, to management to CEOs.

I have communicated this to management, to PO, to scrum masters, to a point. I don't want to get fired of course.

And I can see the outlines of what caused these issues and why management is doing what it is, but that's again tied to a larger economy at play.

> You're not stuck where you are, so stop acting like that.

Again, you're assuming you understand my condition.

It's a different pickle. I'm waiting for an external thing to happen (it has been continuously delayed for nearly 12 months) to be able to change jobs. Not that it's easy in the current market.

Just because your experiences don't match mine does not mean mine are invalid.

  > Again, you're assuming you understand my condition.

I have not, but you've pretty explicitly made assumptions about me.

You'll notice I've made no such explicit claims about you. So maybe there's a difference between what I've assumed about you and what you assume I've assumed about you. Given the inaccurate explicit assumptions you've made about me, I think it is pretty reasonable to question your assumptions. To be explicit, question doesn't mean reject. Suspect doesn't mean invalidate.

> You'll notice I've made no such explicit claims about you

That's not quite true. You assumed I'm in a similar position as you:

> You're not stuck where you are, so stop acting like that.

I explained that our circumstances aren't the same. I'm without wasting huge amounts of resources stuck where I am.

> Just because your experiences don't match mine does not mean mine are invalid.

It's true, but for a total statement, you need a total consensus; it's how logic works.

If I say "All seniors are immortal", you're can invalidate the statements by saying "Djikstra was a senior developer, and he is mortal."

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.

> 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.

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.

It depends a lot on the circumstance.

Profitable over what time horizon?

Any really. Rushing the team is more about looking good so you get promoted than about profit in any form.

> 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’.

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.

> 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.

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

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...

Reply on news.ycombinator.com