Live data from Hacker News

It's OK if your code is just good enough

shiftmag.dev

71–80 of 149 posts

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

#71
post #29

My formatted-by-productivity-standards brain agrees, my heart disagrees. I enjoy the art of programming. I love to think that, for certain types of projects, I am allowed to aim for and reach perfection. My vision of perfection is not yours, so what. If your "good enough" is actually your perfection because of business impact, user happiness or optimal time management, good for you. Just don't tell me that my perfect…

The funny thing with this is, that often times someone’s perfect is someone else’s future headache.

I call that Tuesday.

Or this week, Saturday.

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

#72

Somehow code quality has become a topic completely divorced from product quality. Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.

Youtube has more than a couple people who pull apart tools and see how they tick, then they speculate on how what they found informs the users' likely experiences with this model over another one.

I wish we had someone doing that with code.

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

#73
post #66

Earlier quoted context omitted.

Sounds like something to raise with their manager. Or with this person, before even reading the PR, "Hey - just to check before I review this, does it work on your machine? Have you tested it?". If they say no, close the PR and tell them to do that before opening it. If they lie, call them on it. If they aren't learning, don't waste your time hiding this useless coworker's failures.

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?

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

#74

How good your code is depends entirely on context and priority. Context and priority should be defined for a project, not just left to the decision of each developer. I am building code for a startup right now. The context and priority is to "get the damn thing working". Thus code quality is largely irrelevant - this codebase is flat out garbage - it is full of commented out code, duplication, files that were obviate…

We're in full agreement.

I'd also add that in contexts where there are hard safety/quality/reliability requirements, having individuals or teams or project team leads responsible for a bunch of conflicting objectives and constraints often produces situations where there will be pressure to make visible short-term progress, at the expense of increasing longer-term risks of issues that are less visible and difficult to measure.

> If however I was working for Nasa on code that was running a rocket launch system, then hopefully it is stated to all programmers working on the system that reliability is priority one.

To avoid this, responsibilities should be structured so there's a different team responsible for QA whose review and approval is necessary to proceed for go / no-go decisions. The QA team responsible for the QA function should be independent from and isolated from the delivery team doing the work, and the pressures and influence of the delivery team's management chain.

In contexts where there's a lot of potential for harm, ideally the QA team shouldn't even be part of the same org (e.g. QA by an external public-sector industry regulator with the power to withhold or retract licenses to do business from companies that cannot demonstrate their products and services are safe), to make the QA team less susceptible to pressure.

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

#75

How good your code is depends entirely on context and priority. Context and priority should be defined for a project, not just left to the decision of each developer. I am building code for a startup right now. The context and priority is to "get the damn thing working". Thus code quality is largely irrelevant - this codebase is flat out garbage - it is full of commented out code, duplication, files that were obviate…

> This is exactly the right way to build this because none of those "terrible sins" matter when you have no customers and your only goal is to get something working as fast as possible and every second spent making things nice is a waste of time and money because if the business fails then every second spent making things nice was wasted. There's a lot of truth to this, but I would also like to see companies, and pos…

You would build a pontoon bridge with that attitude - that's a floating type of a temporary bridge that gets built when it's very important to quickly be able to cross a body of water.

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

#76
post #14

Somehow code quality has become a topic completely divorced from product quality. Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.

Your users won’t but your colleagues (and future you) definitely will

Your users definitely do, but the signal is usually so attenuated that people can pretend that they're mad about something else other than code quality.

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

#77
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…

I'd like to see us start measuring the quality of libraries by how difficult it is to trace through them from client code.

I've worked with a few too many instances of code golf where the resulting code requires too many brain cells to comprehend. If I wanted to dedicate 5% of my attention to 50 different libraries, I'd need 3 more brains to do it, but most libraries are written that way. Some seem to think they're entitled to 10%. More.

Show me a library that's a snoozefest to figure out why I put it 5 and got out false when I expected true. That's the one I want to use.

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

#78

In the vast majority of cases, writing good, maintainable code does not require more time. The real problem is that the majority of people working as software engineers barely know what they are doing, and use excuses like this because it makes some amount of sense to the incompetent managers in charge of them.

Agree completely. In fact it often takes less time to write code properly because you won’t have accidentally introduced a regression that you need to fix before shipping.

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

#79
post #12
post #5

I think there's a pretty wide range between 3 and 4 that is worth exploring. Maybe the real problem I have with this article is that once you peg 3 as "good enough" and 5 as unachievable, then there's a whole mess of interesting quality levels squeezed between the 3..5 range. If we peg 3 as "good enough to ship and stand behind it", then I'm immediately thinking about getting the code to somewhere in the 3.5 range. A…

Agree. I always try to remind my self: - make it - make it work - make it fast

Make it work

Make it right

Make it fast

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

#80

Things like large functions or code duplication are not necessarily bad in the first place. A far bigger problem that I encounter regularly is the invention of extreme layers of abstraction to avoid a small amount of copy-pasting + edit in the name of DRY. But an even bigger problem is lack of understanding of the problem domain and a lack of documentation on how you plan to fix the problem.

Yeah, it feels like we cargo culted too many “principles” like DRY without understanding what they actually mean. I see it all the time at my job (I review 5-10 PRs/day).
Post reply on HN