It's OK if your code is just good enough • Hacker News Board

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

#31

Post by javaunsafe2019 » Sat, Nov 11, 2023, 10:21 PM UTC

pil0u wrote: 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.

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

#32

Post by andirk » Sat, Nov 11, 2023, 10:22 PM UTC

There are often 2 consumers of your code: users and developers.

If a developer can write error-free binary code that improves performance (as seen by the user) by 0.1%, BUT the next developer (or even the same dev months later) can't adjust the code without all hell breaking loose, then that code is basically awful.

Side note: add your newline at the end of your files before commit! Ugh

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

#33

Post by sublinear » Sat, Nov 11, 2023, 10:23 PM UTC

> Good enough code is a nice middle ground between implementing a feature fast and maintaining the code quality.

For something to be "good enough" it still has to be good. This feels like evil propaganda aimed at the poor souls who work for cash-strapped and inexperienced entrepreneurs.

Implementing a feature fast is no excuse for writing crappy code.

There are many sets of constraints to satisfy when you're writing code. I agree chasing "perfection" is pointless, but too often you see inexperienced people rationalizing their shoddy work. If you're excusing yourself from bothering with crazy optimizations that have little to no business impact, fine it's good enough. If you're excusing spaghetti, you're the inexperienced person I'm talking about. The "good enough" example from the article sounds like spaghetti.

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

#34

Post by gary_bernhardt » Sat, Nov 11, 2023, 10:23 PM UTC

This is a great excuse to repeat one of my favorite quips, from the late Jim Weirich (from memory, but this is at least very close): "half-assed is OK as long as it's the right half of the ass."

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

#35

Post by thdc » Sat, Nov 11, 2023, 10:25 PM UTC

dataflow wrote: post #27

thdc wrote: post #19

Earlier quoted context omitted.

I like to say that users includes the people working with (using) your code in the future. It changes the definition of user compared to the normal usage, but I think it's a good point.

You can change the definition but you change the fact that those "users" aren't paying you.

You are correct that good code does not translate directly into revenue, but it affects it indirectly e.g. through ease of future development, maintenance, and fixes.

If the thing being written is not going to be updated at all, then, sure, quality is not important.

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

#36

Post by manicennui » Sat, Nov 11, 2023, 10:28 PM UTC

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.

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

#37

Post by mattgreenrocks » Sat, Nov 11, 2023, 10:29 PM UTC

Okay advice for day-to-day, but, horrible advice to take over the long term. Just Good Enough isn't going to improve your skill, it's going to keep you exactly where you are.

Your code is a distillation of how well you understand the problem and how it's being solved. Confusion usually means either the requirements are not well-understood, you still have unknowns, or you simply don't understand the problem/solution well enough to express it to both humans and the computer fluently. All of those involve thinking more and getting more information.

Really, I write the best code I can given the circumstances so I don't have to keep coming back to the same section of code over and over. I want to solve it as well as necessary and move onto something new.

Also, why is the tech industry so weird in how it continually feels the need to degrade the importance of technical skills? Is it seen as taboo that there are still large differences in individual programmer skill?

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

#38

Post by kevlened » Sat, Nov 11, 2023, 10:30 PM UTC

coffeefirst wrote: post #22

mupuff1234 wrote: post #2

I wonder what's the median life expectancy of a piece of code.

At least for my own code, I'm pretty sure its an inverse relationship to quality. The masterpiece I fretted over for endless hours is guaranteed to be obsolete within 1 year. The crappy hack with the comment that says "@TODO make not be garbage sorry" is cursed to live on for eternity.

https://xkcd.com/2730/

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

#39

Post by Kinrany » Sat, Nov 11, 2023, 10:35 PM UTC

PartiallyTyped wrote: post #3

Unless the code is running on critical systems that put human lives at risk, good enough is the perfect amount of good. Getting things done is more important. Excluding above scenario, either you will make mistakes, or you are not tackling meaningful tasks. And that's okay. Allocate time for clean up when there's less ambiguity. The more you explore the problem, the better the issues become. First implementation will…

Code quality is for developers, not end users. It's fine for code to be atrociously structured if literally no one is ever going to read it, even in medical devices, as long as it works.

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

#40

Post by andrewstuart » Sat, Nov 11, 2023, 10:37 PM UTC

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 obviated ages ago. It is unstructured, disorganised, uses different approaches to solving the same problem all over the place - there are ZERO tests, no CI/CD, the code is uploaded directly to production. 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 secong 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.

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. This informs every about how the code is written from that point. It means few lines of code, alot more eyes on the code, must more rigorous quality control and much lower overall output.

If however I was working in an ordinary business making a CRM system then the stated priority I imagine would be something like "we want a balance between productivity, reliability, maintainability" etc. This explicit definition of the context and priority sets the scene for how the code will be written.

I've never worked anywhere that is was explicitly stated across a range of parameters what the code should prioritise in terms of security/reliability/performance/maintainability/time to market/quality etc.