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.
It's OK if your code is just good enough
41–50 of 149 posts
Re: It's OK if your code is just good enough
#42In 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.
> In the vast majority of cases, writing good, maintainable code does not require more time
Yep. Especially with practice. You can pretty much get to a point where you build things reasonably well by default without even thinking too hard about it. You have to want to attain it, and be willing to ruthlessly evaluate and file down your design repeatedly.
I believe there's a compounding effect at play here, which accounts for super-linear gains in ability, given enough focus, time, maturity, and number of projects.
Re: It's OK if your code is just good enough
#43In 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.
This.
And it's often simple techniques like preferring pure functions or using immutable data structures that enable a huge improvement in maintainability, yet few seem to be employing them.
Occasionally the difference comes purely from the fact that someone looked into the library docs and chose the appropriate API method.
Re: It's OK if your code is just good enough
#44I wonder what's the median life expectancy of a piece of code.
It varies pretty wildly but in my career a lot of code has lasted over 10 years and in some cases over 20. Also because code is sort infinitely copyable some code just keeps moving from product to product. Or some design moves from product to product. The longer you work in programming the more you have a set of tools that you can reach for over and over even if you're effectively writing it from scratch each time.
I think good code is vital to the software development process. It doesn't have to start out good but it should end good. Because you're going to be back at this code over and over. A little bit of effort up front can save you a lot of time in the long term.
Re: It's OK if your code is just good enough
#45In 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.
> In the vast majority of cases, writing good, maintainable code does not require more time Yep. Especially with practice. You can pretty much get to a point where you build things reasonably well by default without even thinking too hard about it. You have to want to attain it, and be willing to ruthlessly evaluate and file down your design repeatedly. I believe there's a compounding effect at play here, which accou…
I equate it a lot to writing an essay. Once you’ve gotten enough practice, you know the general structure. You’ll write a draft and then do some edits with some red ink. Then, if you have people willing to reas it, you get their eyes on it.
Re: It's OK if your code is just good enough
#46How 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 possible even individuals in the most negligent cases, be held liable for damages that come to customers when security breaches happen.
We wouldn't build a bridge with that attitude: "Just scribble whatever on those plans! We need to get this thing built right now! None of this matters if the bridge doesn't exist and people aren't drive across it!" For the same reasons we wouldn't do this with a bridge, we shouldn't do this with software, although to a lesser extent.
Re: It's OK if your code is just good enough
#47At the time of initial integration, sure.
But if it's only good enough when you write it, it's on a rapid path to becoming technical debt - and that's just not good enough.
Re: It's OK if your code is just good enough
#48Earlier 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.
Every coworker I’ve had who thinks this way has left a minefield of gotchas and inscrutable interdependencies for the unfortunate developers who come after.
Yeah they “got it done” but we spend 80% of our time fighting fires and the 20% left on new development takes ten times longer than it ought to because zero thought or care was put into anything other than “it works for me”.
This to me is the difference between engineers and programmers. Programmers can get something done and out the door, but engineers can build something that is easy to iterate on and easy to reason about.
Re: It's OK if your code is just good enough
#49Things 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.
Re: It's OK if your code is just good enough
#50Okay 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 w…
no, but until recently, programmers were not known for their social skills, and as such, differences in individual skill levels was not handled in an emotionally mature way, resulting in unhealthy,
bordering on toxic, environments. it's not taboo, but it's maybe unsavoury to some