Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How good engineers write bad code at big companies

seangoedecke.com

Post reply on HN
Print view View original

271–280 of 333 posts

Re: How good engineers write bad code at big companies

#271

Post by godelski »

Ygg2 wrote: post #221
godelski wrote: post #198

Earlier quoted context omitted.

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…

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

Re: How good engineers write bad code at big companies

#273

Post by ClayShentrup »

jagged-chisel wrote: post #139
sfpotter wrote: post #93

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

> Why does bad code bother engineers so much? I’ll take a stab. Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review. “You’re a senior engineer - why did fixing this take so long?” Because of the gar…

have you ever worked with pivotal Labs? One of my biggest faults I guess is that I worked with femme and they have such an incredibly high bar for understanding, design patterns and cyclomatic complexity and solid and test driven development principles and so forth that once you've worked with them, anywhere else you go is going to feel like a dumpster fire. so then you'll just pull your hair out thinking everyone's an idiot, even if it's really just a lot of bad incentives.

Re: How good engineers write bad code at big companies

#274

Post by bdangubic »

vlovich123 wrote: post #270
bdangubic wrote: post #264

Earlier quoted context omitted.

“mastery of the craft” is a myth… whatever codebase you see (and I’ve seen more than I can count) you will go “wtf is this?!” over and over again. furthermore, whatever codebase someone was lucky enough to initially start with, after X amount of time you asked those same masters (if they are still around) and they will inevitably tell you “oh boy, if I can start this over, I would have…” there just is no mastery, the…

I think you are conflating mastery with some kind of beautiful codebase that is completely obvious to everyone else. Einstein had mastery over physics and yet his ideas required a lot of studying to understand and explore. Engineering is the intersection of science and economics. You build the thing as best you can with the knowledge you have and you often discover things you didn’t even know once you start building.…

I agree with literally every word you wrote. But what is this “mastery” or “craft” then? if we agree (rightfully so) that some special people exist, eventually (or immediately) other people get involved, we as industry accept “we had a deadline so it was cool to ‘cut corners’ etc…” - where is mastery or craft in this process?

I have and I am sure you have worked with some amazing people over the years but to me our entire industry is so far removed from anything resembling mastery or craft that even mentioning it at this point in my life makes me chuckle (and at times literally laugh out loud)

Re: How good engineers write bad code at big companies

#275

Post by bdangubic »

pdimitar wrote: post #268
bdangubic wrote: post #251

Earlier quoted context omitted.

Few things that I would tell my kid of she was starting out in this industry today - never work FAANG or any bullshit company like that - look for companies that are small (up to 100 SWEs max, preferably 1/2 that) that have solid business (20+ years, profitable) - when you get hired volunteer to fix every problem everyone else is running away from (there will be plenty). you will work hard in the beginning to underst…

Excuse me but this mostly sounds like a recipe to be burned out extremely quickly, and also blamed for everything. I think your ideas are sound but they very generously assume competent and somewhat benevolent leadership. Something I have very rarely seen.

quite the opposite on the burn out part… if you are curious (this in my experience is in the top-5 traits of exceptional SWEs) you will instinctively want to learn everything there is to know about what you are building. and do it at your own pace, to use a cliche, this isn’t a sprint, it is a marathon.

the leadership also does not have to be competent, you actually want slight incompetency because competent leaders would not allow project to heavily rely on one or handful of people.

Re: How good engineers write bad code at big companies

#276

Post by zingar »

bdangubic wrote: post #264
neko-kai wrote: post #256

Earlier quoted context omitted.

I don't think it's possible to write a flawless codebase. That doesn't mean SWEs don't seek mastery of their craft. Moreover, achieving mastery doesn't mean you would actually want to write an 'ideal codebase', that seems like an art project disconnected from the purpose of the craft.

“mastery of the craft” is a myth… whatever codebase you see (and I’ve seen more than I can count) you will go “wtf is this?!” over and over again. furthermore, whatever codebase someone was lucky enough to initially start with, after X amount of time you asked those same masters (if they are still around) and they will inevitably tell you “oh boy, if I can start this over, I would have…” there just is no mastery, the…

I’m shocked to hear how different your experience is from mine. I very often see good code and bad code and the difference is very clear, even years into a project.

Re: How good engineers write bad code at big companies

#277

Post by godelski »

sethammons wrote: post #230
godelski wrote: post #198

Earlier quoted context omitted.

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…

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?

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.

Re: How good engineers write bad code at big companies

#278

Post by godelski »

Ygg2 wrote: post #249
sethammons wrote: post #230

Earlier quoted context omitted.

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.

Re: How good engineers write bad code at big companies

#279

Post by zingar »

jagged-chisel wrote: post #139
sfpotter wrote: post #93

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

> Why does bad code bother engineers so much? I’ll take a stab. Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review. “You’re a senior engineer - why did fixing this take so long?” Because of the gar…

There’s another side to this I see - and have been guilty of committing - where “it took so long because I found some code that felt wrong and while trying to fix that I found something else that felt wrong and while trying to fix that…” at some point you just have to settle for making one thing better and then getting the job done while leaving some other ugliness still in place.

The complaints in this thread seem to ignore cases like that and I’m not getting the sense that it’s because everyone is spectacular at avoiding rabbit holes.

Re: How good engineers write bad code at big companies

#280

Post by ralphc »

I worked at a perfectly reasonable company that was acquired by Oracle. This was in the 2000s. We were working on a big Java project and were using ADF, the "Oracle Application Developer Framework". It was a piece of crap. One time I asked my manager why we were using it and he said that the project would probably fail and if we used something else the higher ups would blame it on not using ADF and fire him, so...
Post reply on HN