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

Mistakes engineers make in large established codebases

seangoedecke.com

Post reply on HN
Print view View original

321–330 of 384 posts

Re: Mistakes engineers make in large established codebases

#321

Post by veverkap »

codingdave wrote: post #227
Animats wrote: post #169

> Single-digit million lines of code (~5M, let’s say) > Somewhere between 100 and 1000 engineers working on the same codebase > The first working version of the codebase is at least ten years old That's 5,000 to 50,000 lines of code per engineer. Not understaffed. A worse problem is when you have that much code, but fewer people. Too few people for there to be someone who understands each part, and the original autho…

Being able to navigate and reverse engineer undocumented legacy code in a non-modern stack is a skill set in and of itself. Most people don't enjoy it in the slightest, so being one of the few devs who does means that I have been able to take on the gnarly legacy problems nobody else will touch. It might not build buzzwords on my resume, which does limit using this particular aspect of dev work to get an initial call…

This. So much this.

> Being able to navigate and reverse engineer undocumented legacy code in a non-modern stack is a skill set in and of itself.

And I find that it's a pretty rare skill to find.

Re: Mistakes engineers make in large established codebases

#322

Post by veverkap »

edanm wrote: post #274
lmm wrote: post #266

Earlier quoted context omitted.

> Any OS is probably more than 5M lines (Linux - 27.8 lines according to a random Google Search). Linux is notoriously fragmented/duplicative, and an OS isn't the solution to anyone's actual business problem. A well-factored solution to a specific problem would be much smaller, compare e.g. QNX. > Facebook is probably more lines of code. IIRC Facebook is the last non-monorepo holdout among the giants, they genuinely…

I'm fairly sure Word, Excel, Google Sheets, Youtube, Photoshop, etc. all have fairly high counts. As do many tens of thousands of applications that are the backbone of services we all rely on. The systems that run banks, that run power plants, the routers that make up the backbone of the internet, etc. Again, I agree with some of the spirit of what you're saying... but there's also a tendency of many developers (like…

Everyone wants to be a greenfield developer - even if they don't realize they are in a brown field.

Re: Mistakes engineers make in large established codebases

#323

Post by fixprix »

zzbzq wrote: post #308

Wrong, wrong. Opposite of everything he said. All his examples are backwards. The article is basically inversing the Single Responsibility Principle. First of all, consistency does not matter at all, ever. THat's his main thesis so it's already wrong. Furthermore, all his examples are backwards. If you didn't know the existence of "bot" users, you probably don't want your new auth mechanism to support them. Otherwise…

Wrong. If code is written consistently everywhere, that allows any dev to dive in anywhere to get work done. Which is what you often have to do in large code bases to make cross functional updates.

Code bases where devs pick a different framework or library for every little thing are a nightmare to maintain. Agreed on standards is what gets your team out of the weeds to work on a higher and more productive level.

Re: Mistakes engineers make in large established codebases

#324

Post by DaiPlusPlus »

rusk wrote: post #309
tomohawk wrote: post #296

Earlier quoted context omitted.

It's why Scotty was always giving longer estimates that Kirk wanted, but Kirk was also able to require an emergency fix to save the ship. The estimate was building in the time to get it done without breaking too much other stuff. For emergency things, Scotty would be dealing with that after the emergency. If your captain is always requiring everything be done as an emergency with no recovery time, you've got bigger p…

Scotty manages his tech debt

Scotty is a fictional character.

Re: Mistakes engineers make in large established codebases

#325

Post by [deleted] »

liontwist wrote: post #288
digging wrote: post #279

Earlier quoted context omitted.

Did you reply to the wrong comment? I think asking questions is ideal. Even when I'm 99% sure a line is blatantly wrong, I will ask something like, "What is this for?". Maybe I missed something - wouldn't be the first time.

Darepublic originally posted his coworker’s code to make fun of above.

[deleted]

Re: Mistakes engineers make in large established codebases

#326

Post by darepublic »

liontwist wrote: post #252
darepublic wrote: post #178

Earlier quoted context omitted.

Why the while loop

You came in so confident it was wrong, but it turns out you don’t really know what it does. Please take a lesson from this. Good code is not the one that follows all the rules you read online. Your coworker you dismissed understood the problem.

I didn't know that JSON.stringify could be called multiple times on the same object and then unpacked via repeated calls to JSON.parse. So I was wrong on that. I think definitely this warrants a comment in the code, at the least explaining why this was taking place. The likely reason for the nesting was I think calling an LLM for a valid json object and somewhere in that workflow the json object was getting stringified more than once. I suspect this is the fault of the codebase and not the LLM itself, but it was typical of these devs to not ever investigate the api to understand what it was returning and rather just apply bandaid after bandaid.

I reserve my general opinion on the quality of this coder's work, as evidenced by the quality of the app itself among other things. But I guess you'd have to just trust (or not trust) me on that.

Re: Mistakes engineers make in large established codebases

#327

Post by peterarmstrong »

cwalv wrote: post #287
zwnow wrote: post #180

Earlier quoted context omitted.

Thats not how software engineering works in a business setting though? Not a single company I have been in has the time to first fix the existing codebase before adding a new feature. The new feature is verbally guaranteed to the customers by project managers and then its on the dev to deliver within the deadline or you'll have much greater issues than a inconsistent codebase. I'd love to work in a fantasy company th…

> I'd love to work in a fantasy company that allows for fixing legacy code You're not supposed to ask. It's like a structural engineer asking if it's okay to spend time doing a geological survey; it's not optional. Or a CFO asking if it's okay to pay down high interest debt. If you're the 'engineer', you decide the extent it's necessary

No. You discuss it with your manager, and you do it at the appropriate time. Having both created, refactored and deleted lots of technical debt over the past 25 years, trust me: you just don't get to go rogue because "you're the engineer". If you do that, it might turn into "you were the engineer".

What if you spend a week or month refactoring something that needs a quick fix now and is being deleted in 1-2 years? That's waste, and if you went rogue, it's your fault. Besides, you always create added QA burden with large refactoring (yes even if you have tests), and you should not do that without a discussion first--even if you're the founder.

Communicate with your manager and (if they agree) VP if needed, and do the right thing at the right time.

Re: Mistakes engineers make in large established codebases

#328

Post by danielovichdk »

zwnow wrote: post #315
cwalv wrote: post #287

Earlier quoted context omitted.

> I'd love to work in a fantasy company that allows for fixing legacy code You're not supposed to ask. It's like a structural engineer asking if it's okay to spend time doing a geological survey; it's not optional. Or a CFO asking if it's okay to pay down high interest debt. If you're the 'engineer', you decide the extent it's necessary

Thats also not applicable in a business setting. If you have multi million line codebase, you simply cant refactor within reasonable time. Also refactoring can cause issues wich then need further fixing and refactoring. If I touch code that I am not supposed to touch or that does not relate to my direct task I will have HR talks. I'd be lucky to not get laid off for working on things that do not relate to my current…

What field in software are you working in ?

Re: Mistakes engineers make in large established codebases

#329

Post by zwnow »

danielovichdk wrote: post #328
zwnow wrote: post #315

Earlier quoted context omitted.

Thats also not applicable in a business setting. If you have multi million line codebase, you simply cant refactor within reasonable time. Also refactoring can cause issues wich then need further fixing and refactoring. If I touch code that I am not supposed to touch or that does not relate to my direct task I will have HR talks. I'd be lucky to not get laid off for working on things that do not relate to my current…

What field in software are you working in ?

Came from ERP development and now I am in webdev.

Re: Mistakes engineers make in large established codebases

#330

Post by hinkley »

staunton wrote: post #302
hinkley wrote: post #300

Earlier quoted context omitted.

Companies die because nobody is willing to work on the code anymore. If VCs ever came to expect less than 90% of their investments to essentially go to zero, maybe that would change. But they make enough money off of dumb luck not leading to fatal irreversible decisions often enough to keep them fat and happy.

That doesn't sound nearly as bad or serious as people dying.

One: Have you ever tried to take a narcissists' money or power away from them? You would think you were committing murder (and some of them will do so to 'defend' themselves)

Two: All the stuff we aren't working on because we're working on stupid shit in painful ways is substantial.

Post reply on HN