Live data from Hacker News

It's OK if your code is just good enough

shiftmag.dev

131–140 of 149 posts

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

#131
post #60

Earlier quoted context omitted.

> You can pretty much get to a point where you build things reasonably well by default without even thinking too hard about it. That's mastery. There are probably about as many master programmers as there were master... let's say blacksmiths. The problem is there are 10, 20, maybe 50 times as many programmers as we ever had journeymen blacksmiths. And they all seem to think that tenure equals mastery. If we had 10, 2…

> that's mastery Sounds more like competence

Nah, competence means that with some effort you can make things that work well enough, if you don't need to put in such effort it's mastery.

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

#132

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.

If I had a dollar for everytime I heard “we had a tight deadline” as an answer to a question “why is this code so shi*y” I’d have more money than Musk. There is no good code vs. bad code, there are just good programmers and bad ones. And given how many programmers there are in total, roughly 98.76% of them are the bad ones :) I am in my 26th year of this career and I can count on one had situations where a bad progra…

I’d consider myself a good coder, and though I have the standard number of digits, I do not have enough to count the number of times I’ve written bad code. But I’ve written a lot of code, and over the decades I’ve learned a lot. I think that process requires some bad code along the way.

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

#133

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.

If I had a dollar for everytime I heard “we had a tight deadline” as an answer to a question “why is this code so shi*y” I’d have more money than Musk. There is no good code vs. bad code, there are just good programmers and bad ones. And given how many programmers there are in total, roughly 98.76% of them are the bad ones :) I am in my 26th year of this career and I can count on one had situations where a bad progra…

And this is not a total narcissistic opinion at all. Just say all programmers are bad except you.

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

#134

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.

If I had a dollar for everytime I heard “we had a tight deadline” as an answer to a question “why is this code so shi*y” I’d have more money than Musk. There is no good code vs. bad code, there are just good programmers and bad ones. And given how many programmers there are in total, roughly 98.76% of them are the bad ones :) I am in my 26th year of this career and I can count on one had situations where a bad progra…

I would love to see an example of your code, please!

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

#135
post #133

Earlier quoted context omitted.

If I had a dollar for everytime I heard “we had a tight deadline” as an answer to a question “why is this code so shi*y” I’d have more money than Musk. There is no good code vs. bad code, there are just good programmers and bad ones. And given how many programmers there are in total, roughly 98.76% of them are the bad ones :) I am in my 26th year of this career and I can count on one had situations where a bad progra…

And this is not a total narcissistic opinion at all. Just say all programmers are bad except you.

If you actually read my comment I never said I was the good one mate ;)

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

#136

Earlier quoted context omitted.

If I had a dollar for everytime I heard “we had a tight deadline” as an answer to a question “why is this code so shi*y” I’d have more money than Musk. There is no good code vs. bad code, there are just good programmers and bad ones. And given how many programmers there are in total, roughly 98.76% of them are the bad ones :) I am in my 26th year of this career and I can count on one had situations where a bad progra…

I would love to see an example of your code, please!

$450/hr - nothing comes free

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

#137
post #126
post #69

These are the wrong yard sticks. Here's another person making a dangerous analogy between code and a goal with a fixed end date. A paper that has been graded is done. A book that has been published is 99.9% done. Code that is no longer being touched is not done; it's dead. I have a five year plan for every tree in my yard. You can't rewrite trees, and there's a maximum rate at which you can refactor them. So there's…

> Code that is no longer being touched is not done; it's dead. The goal should be to write code not needing maintenance. Four weeks ago I contacted a coworker to ask about some routines he wrote 5 years ago. He said he hadn't touched them in 5 years. The code has been tested continuously in the interim. His old code worked perfectly for me the first time and it saved me hours.

Code that hasn’t been touched gets forgotten. Even if it’s not accumulating new known security holes, and new performance or correctness deficits from not leveraging newer APIs.

It’s basically abandonware that is waiting for one major problem to render it obsolete. I don’t entirely agree with npm and GitHub ranking projects by recent activity, but they’re not entirely wrong either.

You can always be clarifying variable names or shoring up docs. Updating dependencies and keeping track of APIs without necessarily changing the fundamentals of the project.

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

#138
post #126

Earlier quoted context omitted.

> Code that is no longer being touched is not done; it's dead. The goal should be to write code not needing maintenance. Four weeks ago I contacted a coworker to ask about some routines he wrote 5 years ago. He said he hadn't touched them in 5 years. The code has been tested continuously in the interim. His old code worked perfectly for me the first time and it saved me hours.

Code that hasn’t been touched gets forgotten. Even if it’s not accumulating new known security holes, and new performance or correctness deficits from not leveraging newer APIs. It’s basically abandonware that is waiting for one major problem to render it obsolete. I don’t entirely agree with npm and GitHub ranking projects by recent activity, but they’re not entirely wrong either. You can always be clarifying variab…

[deleted]

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

#139

Yes let's happily dive & swim in the sewer of mediocrity that is the modern software industry. Our hardware keeps getting better and better and our devices become slower and slower, while the apps keep glitching and crashing at an ever increasing rate. It's like the fat acceptance movement "it's OK if you're plus sized, or plus plus plus sized, or I guess multiply exponent factorial sized". But it's really not OK. No…

If you haven't seen Jonathan Blow his talk about preventing the collapse of civilisation, you are probably his soulmate.

Checked it out and that's about right. I wish he had more concrete ideas about how to start on this journey. Zig is nice, but it seems to be of modest aspirations.

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

#140

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.

I have to admit: I am terrified of WET code. I do stop short of introducing abstraction monstrosities, but I usually do create what others would call unnecessary abstractions, to stay DRY. Why? Because I tend to write all my code such that a complete stranger should be able to drop in and understand it. I constantly imagine that stranger looking over my shoulder while coding. I imagine the code should be maintainable…

> Because I tend to write all my code such that a complete stranger should be able to drop in and understand it

This isn't an achievable goal for most complex systems. Even very well written and documented code bases (for e.g. tcmalloc, bigtable) require a good deal of background reading to develop a baseline understanding of what is going on.

Post reply on HN