The Best Engineers Write Less Code | Hacker News Reader

The Best Engineers Write Less Code

shvetsm.github.io

66 pointsfunnyenough30 comments

One big difference I see in how minds work is their ability to model. A few people I know focus on end-to-end model thinking — trying to maximize against some functions.

The rest of them seem to avoid thinking outside a small info bubble/closed system, not sure why, but it looks like it creates anxiety when they start feeding too much info. Instead of trying to extract abstractions that make it possible to model the complexity and fuzz the non-important parts.

The same people, when they come up with a product implementation idea, avoid thinking about all the things required to be in place for the product to actually satisfy some real need/want. The product ends up detached from user need. The tech doesn't work.

And it doesn't matter if they can code or if Claude can work, because the directions required to define what needs to be there are not present.

I realized I need to take the thinking of these people as their ideas and advice — as inputs that need to be sanitized. The easy way I found is to remodel why they think the way they think — it's like having a safe VM running their code (thinking) through my computer (my brain).

These same people, usually years later, realize you were telling them things they were not able to comprehend at the time, but they realized those things were so important and would have saved them from suffering so much. They start to treat your voice with reverence instead of thinking through with their own minds and stress-testing against reality.

I would love to read some research about this and how to take advantage of it, or at least avoid the toxic influence such minds can have against one's own well-being and success.

When I was reasonably experienced, and about 6 months into a new job, one of my co-workers, Fred, had been there for a very long time.

Fred was very knowledgeable, and Fred could think. But Fred had deeply held preconceived notions that interfered with the utility of his thoughts.

Fred also had something else, though -- he could set aside those deeply preconceived notions. Not for himself, mind you, but for someone else.

I could, and did on a very regular basis, go to Fred and say "Fred! Assume X, Y, and Z. What happens if A and B?" Now even though Fred was completely sure that I was wrong about at least Y and Z, he could set aside those prejudices, and (correctly!) reason through what would happen.

Fred reminds me of the people you describe, except that instead of having Fred's code running through my brain, I was able to insert my code into Fred's brain.

There has to be some language for what you're describing, because I've experienced similar perceptions of people. I've been on both sides of the "you don't actually understand what is being said until years later" discussions as well.

One thing I'd posit is that it might not be the people, but rather an ability or skill people can improve. It takes difficulty and focus and time, but it can be honed. I know this to be true; otherwise I would not be able to understand that which I dismissed years ago!

The problem with this, if it is an active ability rather than a person's inherent traits, is that it becomes impossible to recognize by any identifiable markers. I've often found that some of the most intelligent and "look at the problem from all angles" kind of minds often have very glaring blind spots (look no further than political subjects, for example). These blind spots manifest even in the most generally intelligent thinkers, that's what makes people human after all. So it can be said that good thinking is a very delicate thing, and it can be difficult to recognize against noise no matter who is speaking or what they are discussing.

Unfortunately you're indexed on and promoted based on how much code you write, not how little. There's a very real reason the meme of "promotion driven development" exists. You'll never get favorable review making sound choices that minimize the amount of new code that is needed. Believe me, I tried.

You're indexed on, and promoted based on how much value you provide. LOC is not the same as value.

If I can close 100 tickets with less code than someone else, I've still closed 100 tickets.

Gee wouldn't it be nice to live in your perfect little fantasy world where all managers are perfect and capable people and have more than two brain cells to tell the difference.

I've been a professional developer for going on 30 years now. I have never once seen anyone measured by lines of code. That died out before my time.

I've seen a host of other imperfect measuring sticks, including the "tickets" metric I cited. But the post to which I was replying said that people are judged on how much code they write.

Not quite lines of code.

The person who takes a business problem and proposes an expansive solution that requires a big team that they lead to victory, that person climbs the ranks.

The person that takes the same business problem and carefully simplifies both the problem and the solution, and delivers it themselves, is rewarded but not at all like the team leader.

I prefer an alternate measure - great developers write code with a long half life relative to the rest of the product. (An idea I learned from a hiring reference check ... of all places.)

This is in all likelihood an improvement on just measuring lines of code output, but not at all a silver bullet. I'd imagine this skews heavily towards developers who were around first in large projects. Also skews towards developers who pick certain tasks over others - there's always circumstances where the library you are building on passes breaking changes, etc. but that I feel might be more minor in comparison to the first concern.

I didn't mean to imply there's a single all-encompassing metric or silver bullet, but re-reading, I did kinda write it that way. When you find someone whose code persists a long time, that's often a strong signal of quality contributions. There are of course myriad other ways to contribute critically - ops, culture, finding and fixing hard defects, unusually good understanding of the customer, industry expertise, mentorship, ...

Many people try to design a perfect system on the first attempt. And for the original requirements, it often works beautifully.

But as new requirements appear, the clean design slowly turns into layers of patches and exceptions.

you discover a deeper pattern that absorbs the complexity back into the core, and you do a rewrite.

Then the cycle repeats.

I don't worry about writing a perfect system anymore, i realize there is more to a system i do not currently know about, many things will surface once the foundation is laid.

As a counterargument. Making the wrong architectural decision can lock you in a design that's horrible. And once people start building on top of it you are forever stuck with it (or at least it will require a monumental effort to change it)

The "go delete some code" link goes to a 404 page, which is quite fitting :D

wonder if it was on purpose...

Links are broken--proper ones below. They all have a similar tone/structure, like it had a few seeds of originality but then got 'produced'. More style than substance/depth for my liking.

[0] https://shvetsm.github.io/posts/who-looks-at-the-code/

[1] https://shvetsm.github.io/posts/keep-the-kitchen-clean/

links have been fixed, thx

There's also the sunk cost fallacy. Instead of removing code/features that it's becoming more and more obvious were a bad idea to begin with they get kept in the code base causing even more problems and delays because of "we cannot just remove it after spending so much time and money creating it".

The issues with bad code/architecture/complexity often gets "solved" by creating even more of it.

"We are living in an age of mass denial. Some very smart people are telling us that we no longer need to write good software because LLMs can generate code now. But terrible software is still terrible software, whether it was written by Claude Code or by a human who did not know what they were doing."

Less code helps, but fewer unclear decisions probably helps more.

>The Best Engineers Write Less Code

That's because they are designing circuits. EE FTW!

I actually think we have it pretty backwards in terms of what we need now. We as humans no longer need complex front-ends. We need data. I would rather have data access to all my spending and say things like, did I go over my restaurant budget last month? And the LLM can figure out how to do it.

It makes no sense for me to use the limited UIs that companies present anymore. Let alone signup processes - it should all be LLM friendly. Simple APIs that are called by your agent.

My company uses Teams and it's ecosystem. And for email I get a lot of crappy system updates, etc.... And around the UI there are little "AI" buttons or "Ask a question" boxes. No. This. Is. Wrong. Instead I need to be able to ask my OWN agent to check my email and archive anything dumb and inform me of anything important. In fact, don't even make it a one-off prompt- make it a permanently running long-haul agent that interacts with my "personal assistant" agent that is in charge of getting my attention if it's absolutely necessary, which knows if I'm watching a movie.

"One of my most productive days was throwing away 1000 lines of code" - Ken Thompson

Coding used to be bottlenecked by typing speed; now, it’s bottlenecked by our ability to comprehend and maintain.

I highly doubt it was ever really bottlenecked by typing speed. If _that_ is your bottleneck then you either don’t care about what you write or you have a perfect plan laid out and just need to type it in.

If it's well trodden ground like writing enough Vulkan to display a triangle? It's probably bottlenecked by code writing speed.

In fact, writing a video game engine is probably the most common project on the planet to the point there is hardly anything novel about it. That's how engine writing nerd snipes people. They get to feel secure due to the guaranteed possibility of success. Making and designing an actual game that people want to play is much more risky and it is much less dependent on programming skill.

Why you aren't entirely incorrect, I would argue you also aren't entirely correct.

With Vulkan the hard part isn't the typing, it's the understanding and figuring out an abstraction that suits you/your project that is the hard part. And kinda the same with writing a game engine. There is basically infinite resources and libraries to make it easier, but what you actually are spending your time on is figuring out an abstraction that makes sense for the user of the engine. There is a reason why almost no 2 engines end up with even close APIs.

Exactly. And when writing your own engine, you _should_ type these lines to render a triangle definitely by hand, to understand what is being done and then use that input to build the right abstraction so one doesn't have to type it over and over again.

Very rarely you're bottlenecked by typing speed. If you truly are, and you are already typing at like 200 wpm, then you are probably doing something at the wrong abstraction level. E.g. for a very simple example when making a CRUD admin, but implementing everything from the first principles for each entity, not making helper functions to render generic forms, handle add/update/remove operations uniformly, etc. Of course LLMs can help you generate such code faster, but if you then need to change something systematically in the future it'll take longer and will definitely be less consistent / more buggy.

Not my experience at all (30+ years of getting paid to deliver software).

Thinking hard (and discussing with experienced colleagues) before writing any code can dramatically speed up your overall delivery time and completely remove whole classes of potential errors.

If you skip the "thinking hard" bit to "go fast" you will probably end up being 10x slower overall.

Weird that "engineer" came to mean "software engineer". Can't until AI is good enough that we never have to deal with code again.

Reply on news.ycombinator.com