Reading the headline evoked the question: Good enough — but for what? Glad to see TFA (and the comments here) delve into that question, albeit without using those words.
It's OK if your code is just good enough
61–70 of 149 posts
Re: It's OK if your code is just good enough
#62In 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.
A large fraction of people doing woodworking videos are overtly or covertly pushing the fundamentals. If you don't have the fundamentals down what are you doing trying to do complicated stuff?
Re: It's OK if your code is just good enough
#63In 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.
I work with someone who regularly opens PRs for untested code. I'm talking stuff that hasn't even been run once: missing imports, undefined variables, etc... not bugs. I'm fine with bugs. I'm not fine with not testing your work in the most basic sense.
PR reviews don't mean throwing crap over the wall and hoping the reviewer figures it out. With this guy, there is so much back-and-forth hand holding, it would be simpler to close the PR and do it myself. But I don't...
Re: It's OK if your code is just good enough
#64> Take a look at the infobip-spring-data-querydsl library. That looks like an absolute nightmare and not an example of very good code.
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.
Re: It's OK if your code is just good enough
#65> Take a look at the infobip-spring-data-querydsl library. Although it sounds perfect, it’s not.
It sounds like a steaming pile of garbage to me.
Re: It's OK if your code is just good enough
#66In 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.
I work with someone who regularly opens PRs for untested code. I'm talking stuff that hasn't even been run once: missing imports, undefined variables, etc... not bugs. I'm fine with bugs. I'm not fine with not testing your work in the most basic sense. PR reviews don't mean throwing crap over the wall and hoping the reviewer figures it out. With this guy, there is so much back-and-forth hand holding, it would be simp…
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.
Re: It's OK if your code is just good enough
#67Earlier quoted context omitted.
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 e…
> 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.
I mean, then they weren't good engineers? Nobody said that approach is good.
But I've also seen enough for my share of engineers that knowingly write buggy code that eventually blows up in someone's face because that code was simpler and turned out elegant that way. Code simplicity and reality don't always go hand in hand. The startup graveyard is filled with businesses with otherwise great engineers that lost sight of the customer's actual experience.
Re: It's OK if your code is just good enough
#68Earlier quoted context omitted.
I work with someone who regularly opens PRs for untested code. I'm talking stuff that hasn't even been run once: missing imports, undefined variables, etc... not bugs. I'm fine with bugs. I'm not fine with not testing your work in the most basic sense. PR reviews don't mean throwing crap over the wall and hoping the reviewer figures it out. With this guy, there is so much back-and-forth hand holding, it would be simp…
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.
Re: It's OK if your code is just good enough
#69These 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 what you can do now, what you will do next, and everything beyond that is educated speculation. You can't control it. You can't control the elements or disease or accidents.
So I know what I want to do, and I know how much I will do in the spring, and how much I'll have to delay until next year. And next year, or the year after, I'll step back, look at the whole thing again, and make a new plan, that might not look too much like my current plan. It all depends on what the other forces acting on my projects get up to in the meantime.
Like the trees, you can't control your coworkers, you can only influence, steer and remove. If you try to exert more control, you end up with a tiny little tree. And the dirty little secret with those is that the tree still does largely what it wants, and the skill is in making what actually happened look like it was on purpose.
If you want a big happy tree, you have to focus on the irreversible decisions, and let a lot of the little shit go (for now), and sometimes try again later. If all goes well, the only person who thinks the end result is a mess will be you. A layperson will think it was all going according to your plan.
Re: It's OK if your code is just good enough
#70Earlier quoted context omitted.
The funny thing with this is, that often times someone’s perfect is someone else’s future headache.
It's more subtle that that. There is a great saying "Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live". I've seen countless bright minds wonder in the pursuit of instant pleasure by adding unnecessary complexity. I have seen others outright sacrificing projects that support people's life to achieve an instant goal of learning a particular library or…
A similar saying, which I like more: "code as if your (hypothetical) children will have to maintain it"