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

It's OK if your code is just good enough

shiftmag.dev

Post reply on HN
Print view View original

81–90 of 149 posts

Re: It's OK if your code is just good enough

#81

Post by zeroonetwothree »

bdw5204 wrote: post #55

"Quality code", in my experience, often means "code that looks like how I would have done it". In other words, it's usually pointless nitpicking and you're better off not engaging in it. Of course, there's some convergence on this topic because certain programming influencers successfully pushed their opinions onto many people who choose not to have opinions of their own which is something that happens in every field…

Ironically I don’t really agree with your list of things that “genuinely matter”. I would pick entirely different things.

Re: It's OK if your code is just good enough

#82

Post by nathants »

the issue is collaboration on software implementation. this is extremely hard to do well, think lkml.

the typical collaborative implementation environment is a disaster. we are baking a cake, slowly over weeks and months. we aren’t sure why or who’s at fault, but we are absolutely sure it looks awful and tastes worse.

the only silver lining is that the solution to this disaster is hiring more collaborators. jobs and ubi all around.

microservices obviously didn’t quite work, but were an idea in the right direction. we need to collaborate at a higher level than code. we need to work in a bakery together, but each bake alone.

then we can easily evaluate the quality and pace of each other. there is no ambiguity of individual responsibility.

when my cake is bad, i should feel bad. i should look around the kitchen for better cakes, and ask their baker what they do that i don’t.

when my cake is bad and i don’t care, my boss should move me to less important cakes, or out of baking all together.

Re: It's OK if your code is just good enough

#83

Post by hinkley »

aethr wrote: post #15

Different levels of code quality are important for different teams / projects. Teams that are still discovering the domain and defining patterns should aim for a lower quality so they can iterate more easily. In this mode, knowing that code was written quickly and is fine to throw away / reshape is critical. Aiming for Very Good is likely to be a waste of time here. In other projects, the domain is clearer, or the sy…

The problem for the last 4 decades has been getting people to admit that we were 'building one to throw away'. In the last 2 we've tried a couple of different tricks to get things done anyway, with varying degrees of success. But that's all external-facing problems

The internal facing problem is getting a team to agree to differing quality gates for different parts of the system - the absolutely knowable and the arguably unknowable parts should not be written with the same mindset if you want to maintain velocity. If you get lucky with the org chart you can fake some of that quality diversity via code ownership, but that's a rough approximation at best. People seem to prefer picking something static and not thinking about it too much, rather than having to reason about every feature. I'm curious to see what we try next to deal with this.

Re: It's OK if your code is just good enough

#84

Post by zeroonetwothree »

renewedrebecca wrote: post #41

I've never seen a PoC that was allowed to have the time to be cleaned up properly to make it to the Good Enough phase. Management types tend to want to take the PoC and move it directly to production and assume you're incompetent if you push back.

That’s why I try to make my POCs at least 80% as good as production in terms of code quality. Much easier to fix that last 20% later than if you had started at 20% and have to fix 80%. And usually it doesn’t take longer, you just have to have more intentionality with the changes you are making.

Re: It's OK if your code is just good enough

#85

Post by icedchai »

nathants wrote: post #73
icedchai wrote: post #68

Earlier quoted context omitted.

I have raised it in the past and will do so again. One of the problems is the manager has no software engineering experience and his view of "working norms" often go against mine. Some of my complaints are fairly basic: test/review your own work before asking someone else to review it. This should be applicable regardless of industry.

time to go next?

I've been thinking about that for a while, for a variety of reasons. This is one of the smaller ones. Probably after the holidays.

Re: It's OK if your code is just good enough

#86

Post by zeroonetwothree »

gavinhoward wrote: post #6

Upfront, I mostly agree with the post. However, I may be a tad famous about striving for perfection in my code. [1] [2] Why? If "good enough" is good enough, why do I go further? For a few reasons: 1. I want the industry to be more professional [3] where it matters, and I need to set an example. 2. The kind of software I write already has alternatives, so mine needs to be far better to get adopted. And it does. [4] 3…

The first file I looked at in that codebase has a “goto” (as well as some IMO hacky-ish logic). Now I’m not going to say this is never right (but it probably isn’t), but it takes a lot of hubris to claim you are “striving for perfection” and I just don’t see perfect code using goto, sorry.

Re: It's OK if your code is just good enough

#87

Post by zeroonetwothree »

yen223 wrote: post #64
realusername wrote: post #8

Earlier quoted context omitted.

That's also what I thought as well. This is the kind of overabstracted code Java gets a bad reputation for and I would not want to maintain that.

One of the biggest problems when discussing code quality is that there are almost no objective standards. What looks like "good well-named" variables to one person is "overcomplicated garbage" to another, and there's nothing to inform us on which person is correct. The closest thing we have is "does this code do what the user wants it to do". To me, this is the only question that really matters.

It’s true that it’s fairly subjective but that doesn’t mean we should abandon all judgment. Food is subjective as well but still you will get most (not all!) people agreeing that Nobu is better than McDonald’s.

Re: It's OK if your code is just good enough

#88

Post by zeroonetwothree »

sneak wrote: post #59

I once saw a 5000 line file of shit-tier code making a business something like a million bucks cash per day. It was a single huge function, called from cron every 5 minutes. No locking to prevent concurrent runs if it took longer than five minutes to execute. No exception handling. One giant nearly incomprehensible everything-function. Global variables. Bugs everywhere. Easily hundreds of thousands of dollars of net…

It’s great until there’s some new regulation or costumer requirement and it can’t possibly be added to the monstrosity and so you lose those millions until you can rewrite, which takes months.

Re: It's OK if your code is just good enough

#89

Post by Osiris »

The TLDR for me: be pragmatic.

don’t get caught up in dogma and ideology in search of the “right” answer. Don’t be a “fanboy”. There is no such thing as the “right” or “best” solution because every engineering decision has tradeoffs.

You have to make rational, pragmatic, decisions based on the facts on the facts on the ground.

Re: It's OK if your code is just good enough

#90

Post by sneak »

zeroonetwothree wrote: post #88
sneak wrote: post #59

I once saw a 5000 line file of shit-tier code making a business something like a million bucks cash per day. It was a single huge function, called from cron every 5 minutes. No locking to prevent concurrent runs if it took longer than five minutes to execute. No exception handling. One giant nearly incomprehensible everything-function. Global variables. Bugs everywhere. Easily hundreds of thousands of dollars of net…

It’s great until there’s some new regulation or costumer requirement and it can’t possibly be added to the monstrosity and so you lose those millions until you can rewrite, which takes months.

Rewriting 5000 lines doesn’t take months. I actually ended up refactoring it in under 24 hours to make it about 10x more reliable and performant (after I put out the immediate fires that had me looking at it in the first place).

In general, I agree. I don’t write code that bad, even for prototypes. That said, I worry a lot less about being super meticulous DRY and best practices in my prototypes that in 90% of cases will never touch millions in value. Done is better than perfect.

Post reply on HN