Hacker News Reader

I used to work with a guy who took "gets shit done" to a level I'd never seen before. It changed the way I look at programming. He was actually a pretty good engineer. Wrote good-enough code. But he wasn't precious about anything and he didn't care all that much about finding the 100%-guaranteed-socially-approved-correct way to do things. What he had was an incredible ability to diagnose and fix problems quickly, strong intuition about how to architect greenfield projects, and the complete confidence of his bosses, with whom he very quickly earned a reputation as the person to go to when something absolutely needed to get done. He knew what to prioritize. He knew which parts of the code to plow through and which to take his time on. He knew exactly where in the code to start looking when a bug came in. And he knew which things were important to management and which weren't.

I learned way more from him than I ever have from the kind of peers who have opinions about how to structure every line of code.

If I may, you should encourage your ex team-mate to share their side of things: https://staffeng.com/stories

In my experience it is useful to have such people on the team, but if they make up most of the team then the codebase becomes a gigantic mess over time, and it negatively impacts everyone else.

Perhaps but having "that programmer that management likes" is worth 10x more than whatever mess is generally being made.

Yep I tend to be more on the spectrum of focusing on code & architecture quality over raw productivity, and I find the "plow through it and get it done" engineer to be the perfect foil to have on my team.

Ultimately it gets done faster than it would if the whole team was my personality, but with higher quality than if the whole team was their personality.

If you're lucky enough to have someone buy into a centralized code/arch strategy then this is idea, the issues arrive when the code/arch strategy isn't a hard sell for the plow engineers.

I consider myself a plow engineer, and I definitely agree with you, a team full of people like me would descend a codebase too deep into chaos. A dance between balance of order and chaos is ideal, as too much of the other has significant negative side-effects.

He is almost certainly way above a pretty good engineer.

Nobody can quantify 'good-enough code' but everyone can quantify meeting a deadline.

How much engineering is anyone really doing anyhow - or are we calling using React to build yet another set of forms users fill out with some error handling engineering nowadays? :)

Fixing bad code is easier than fixing bad architecture. And if your architecture is modular and cleanly decoupled, then the bad code’s impact can be contained.

This is a good point. Modularity is the key to managing complexity. Unfortunately, I think writing a good architecture is harder than writing good code at the local level (because most developers have less experience at writing code in the large). And projects with a good initial architecture tend to diverge as developers add new features and introduce new dependencies. They often don't understand the original design and want/need to get things done quickly.

> Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design.

This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate.

However, this approach can be really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.

Are you sure that the discussion should be around code quality but not architecture? I think they are quite different...

In addition, I think it's the fault of management if it's all young engineers.

I've often said the difference between a senior and a junior isn't writing software successfully, it's writing software that's maintainable 5 years down the road. The only way to learn that skill is to deal with a project over years and learn the pain points that aren't immediately obvious w/i the first 18 months.

Make it work, then make it pretty.

Undelivered pretty code doesn't deliver any business value.

Same applies to 100% code coverage that isn't running on customers computers.

There are a ton of people at all levels that don't get this.

I think it was Judd Apatow who said “You have to give yourself permission for the first draft to be shit.”

The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.

Problem is the business will often never let you improve it.

So you better not tie your self worth to the quality of the things you produce.

It's not a universal thing.

You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them.

You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.

Surely, I have given up to the pretty tribe on a couple of pull requests, as I have better things to do with my time, and it is easier to make their wishes come true than endless arguing.

The counterpoint to this is "Rough Prototypes have a bad habit of being shipped out as End-Products". And technical debt 'does' kill products.

There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.

I would say technical debt is a better problem to deal with. At least the project is alive at that point and you are able to get feedback from actual users.

> an optimum somewhere in the middle

Reasonable code isn’t technical debt. The obvious tipping point is when spending X hours now likey saves people less than X hours in the future. Which unfortunately depends a great deal on the details of the actual project involved and therefore requires experience not some universal methodology.

Sure, in the other extreme they never got shipped in first place, and that marvelous piece of art ended up in a museum.

It is a balance that needs to be learnt, and a trait of seniority.

I don't care if it's pretty.

Make it work and make it as straightforward as possible.

If by "straightforward" you mean "readable" I agree. If I can read it easily, it's pretty enough.

It depends, if it has a bunch of nested loops and easily abstracted code but it works sure, who cares. If someone decides to store JSON as a string in the db that will work and deliver business value, but 8 months later when you want to query information in that JSON string you have a very difficult/dangerous migration due to someone just "making it work".

This philosophy less relevant in larger companies with more engineers also.

One of the traits of seniority is to understand what that "it depends" means in reality.

Do you know of any RDBMS's that can't take a text column and treat it as BSON?

I get your point, I just question the specific example.

> Undelivered pretty code doesn't deliver any business value.

See also: https://apenwarr.ca/log/20211024 (Wants, needs, and chasm crossing).

Depends on where you are.

In the company I used to work at, code quality was a huge deal. I think, destructively so.

Nevertheless, I exercise pretty extreme code quality in my work (see for yourself[0]). It's long reached the state of "muscle memory," and I work very quickly.

As I am the person that most frequently has to go back and fix the code I write (I eat my own dog food), I write code that is what I want to see, when revisiting, six months later.

On another note, this industry considers six years to be "senior." I find that interesting.

[0] https://github.com/ChrisMarshallNY#browse-away

> I exercise pretty extreme code quality in my work

I'd say maintain good code quality on your own project is much easier than within a team. It's like living in a house with different people: not everybody has the same standard regarding keeping the place tidy and clean, and compromises have to be made.

This was one of the biggest pain point for me, moving from my own personal projects to working with other people.

This is true. Many things suddenly become much more difficult, when even one other person is involved.

Managers often neglect to take team overhead seriously.

At some point your craft is good (or good enough) that progressing further on it is not moving you forward as an engineer. It is often a difficult thing to notice and a trap one can easily fall into of over-focusing on craft and not realizing you’re plateauing your overall career or skill set.

For benefit of a friend new to HN (and anyone else who might be new here): Yes, the comments and the articles are almost separate, parallel discussions. The articles can be interesting in themselves, but for purposes of reading the comments, the articles are often just kind of inspirations or writing prompts.

So, yeah, the OP doesn't even mention code quality. The comments do. That's ok. It's just how the site works.

Article start with variable names (which pertains to code quality)

> Variable names are important because they communicate to the reader what’s happening. That’s their only job in code, so it’s important to name them well. Long verbose names don't cost anything:

Except in JavaScript ;)

And legacy c/opengl, where the variables names tell you the return type...

HN maintainers should optimize page load time by just omitting the actual link to the article. The discussions would be pretty much the same.

It's certainly there, but it comes in different avenues: tech lead meetings (where is our technical debt?), early in projects (as everyone is building a consensus for the project), and code reviews (where they're talking about a facet to make code more understandable or testable or otherwise fulfilling non-functional requirements.)

The conversations aren't about code quality -- they're about a finer point of it and in concrete terms rather than in beginner terms.

> I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design.

I'll play devil's advocate and argue that this could just be the code equivalent of privatizing the benefits while socializing the costs. You mention that your team writes code without explicit discussion of its quality. The benefits of that choice are front-loaded, while the costs of that choice won't be apparent until later. Furthermore, the team members who have to pay those costs may not even be the current team members - it may actually be those on the team months or years from now, after the original code authors have left for greener pastures.

So it may be too early to declare that your choice was a successful one. As the article mentions, code is read much more often than it's written.

I'm not saying that my team writes unmaintainable code, but rather that because they're all strong and experienced, writing decent code is a given and the focus is on other, more challenging, problems. That being said, our code is definitely not as readable as it could be, but I understand it's a trade-off and there are more important things to do than refactoring code, unless it really gets in the way.

I used to feel this way until I started working with a very senior engineer (20+ years) who writes some of the worst code I have ever had to work with.

Functions are regularly 50+ lines with 10+ logical expressions. Most features are written as single classes with 3k-5k lines. Everything is written imperatively (that 50 line function declares a variable at the top and mutates it 10 times as it works through the control flow.) The same magic values are redeclared multiple times through the codebase instead of using a shared constant. His PRs are usually 3k-5k lines and take hours to work through. etc. etc

His code takes way more effort to understand and takes orders of magnitudes longer to change than it reasonably should.

Also his code works. It generally does what its supposed to do, covers edge cases, and is reliable. He also delivers with decent speed, but all that saved time is being pushed on the poor sap who has to work with the code next.

It depends what is understood as code quality. After a while, writing code that is not verbose, fairly maintainable, and readable, is a given. There is a minimum bar that each team set and it is gated by code reviews. The tradeoff start to happen after those minimums are reached.

I think quality in terms of correctness is always the target, and performance usually has a target SLA.

I wouldn't fully agree, because while senior engineers don't often discuss "code quality" syntax/aesthetic issues, it is quite common for people to discuss bugs/edge-cases that need fixes or to discuss simpler approaches to achieve business goals or getting rid of difficult to maintain logic/services.

This is touching on something I have been thinking a lot about as I progress in my career.

The thing good and bad code have in common is the fact that it needs to updated. Either for bugs or changing business need.

So focusing on the operational side becomes much more important. Code is the trivial part. Creating systems that can be modified reliably is the hard part.

I rather have ownership over a "poorly" coded service with proper ci/cd, integration tests, monitoring, and a team that reasons about and follows strong operational processes, rather than some beautiful code in a vacuum.

My experience is that “good” code enables all of that — CI/CD, meaningful testing, monitoring/logging, operational tooling, etc.

Making any of that work for spaghetti is rough, since it lacks the boundaries and entry points those things rely on. And even if you ostensibly have it for “bad” code, it tends to be fragile and unreliable. (As my many, many overnight pages have shown.)

Of course, that may be different perceptions of “good”.

yep.

A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer.

This is probably true for the first few years of a developers career, but there are only so many ways to build an authentication system (for example).

At some point your improvements are at the design and systems level. You start to develop a nose for what can be problematic and how to avoid it. Linus Torvalds referred to it as 'taste'.

And as you said, often times there are organizational and procedural challenges that have a much larger effect on the success of a project than purely code concerns. Not that code concerns are irrelevant, but good enough is good enough, there's generally an expectation that developers can read code. In the same way there's an expectation that readers of a novel are at the literacy level to understand novels. No one would blame James Clavell if a 5th grader couldn't understand Shogun, even though it's true that Shogun could certainly be improved from a prose perspective.

For me, code quality boils down to two aspects: (1) current operation cost and (2) future maintenance / alteration cost.

You can cut a lot of corners, as long as you don't paint yourself into a corner. OTOH an extra hour not spent today on doing the right thing may and will result in extra weeks and extra thousands of dollars spent in a few months.

Sounds like a startup? Title inflation is pretty rampant at smaller newer companies. The expectation is definitely ship the product before all else. Obviously if you are an established company serving services to hundreds of thousands or millions of customers code quality and reliability becomes an order of magnitude more important.

IMO too many coders can't write high quality code even if they tried. So when they write code that they feel is good enough, it rarely is good enough objectively.

What even is high quality code? I was on a project with a seasoned grey beard once and all he bitched about was dumb stuff like insisting NOT to prepend variable names with is and forcing a python project to have dependency injection. Sure, those things can make a high quality project but often misplaced and strangely opinionated.

Depends on the seniority imo. If you don't make code quality a thing with early in their career devs, you might open up a door to some bad habits to take hold.

There are a few hard and fast rules around code quality (and every rule is meant to be broken), everything else is just preference.

Learning how to write good code is a topic for juniors. Any senior would already know how to that so we focus on other things.