Earlier quoted context omitted.
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
Yeah even better!
It's OK if your code is just good enough
121–130 of 149 posts
Re: It's OK if your code is just good enough
#122I'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.
In my experience it's often the _developer of the PoC_ that goes "oh, this will just need a little bit of cleanup" rather than clearly communicating "this PoC has validated risks X and Y, but we still need to mitigate risks A and B and the current implementation has taken shortcuts which introduces risks D and E".
Re: It's OK if your code is just good enough
#123These 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.
Scripting code I wrote in 1998 worked in 2005 and still works today. Javascript I wrote 5 years ago, works today. Language choice matters as much as how it's executed. I assume VMware running a vm from 2008 is still running somewhere.
If it's not being executed, it's dead. There's a big difference from the "always needs to be maintained" assumption.
Re: It's OK if your code is just good enough
#124Earlier quoted context omitted.
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.
As another poster has said, code you no longer touch is dead. Usually, software needs to be maintained and modifying a badly written code is a nightmare scenario. That means that requested features are piling up in the backlog and the resulting mess is growing slower and buggier overtime.
> As another poster has said, code you no longer touch is dead
This is a poorly considered sentiment.
Re: It's OK if your code is just good enough
#125Earlier quoted context omitted.
I think one of the exceptions is heavily optimized code, though the surrounding code can still be maintainable and clear, with the weird stuff to tickle the compiler or inline assembly being heavily commented.
For those kinds of cases, I love having as-simple-as-possible reference code checked in alongside it, even if it's just #ifdef'd out for common builds. Having a baseline makes it sooo much easier to understand and debug the optimized code.
Ideally, the slow code is available alongside the fast code and the unit tests confirm they are sufficiently equivalent. If that's not possible, the go-fast bits need to be refactored until it is possible. Don't forget that error handling is part of the equivalency testing.
Re: It's OK if your code is just good enough
#126These 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.
Re: It's OK if your code is just good enough
#127Earlier quoted context omitted.
If you are in charge of the review process, simply start closing their PRs, list the reasons why, or better yet create a document you can reference establishing your guidelines. Don't back and forth; if they can't meet a simple set of guidelines, the PR is not ready for review. Let their manager take issue with it. Fight it, bring it to their manager's manager, whatever. A company like that is not worth working for,…
> better yet create a document you can reference establishing your guidelines. This. Remove as much ambiguity and grey area as possible.
> better yet create a document you can reference establishing your guidelines.
How about working on a document that establishes the companies guidelines?
I can not imagine having to meet everyone's personal quality bar.
Re: It's OK if your code is just good enough
#128In 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 programmer wrote good code and good programmer wrote bad code.
Re: It's OK if your code is just good enough
#129Earlier 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…
I'm 100% fine with opening a PR for "I just typed it" code... with two caveats: - a HUGE disclaimer at the top saying "DO NOT MERGE: not tested" - also, you'll probably want to politely ask someone for a review, and be specific about what you're looking for "Draft PRs" are fine for discussing topics or code or goals with a team mate. It's all about getting feedback!
Looping back to TFA: I've been trying to use this workflow more to get quality code written more quickly. I definitely have a habit of spending too much time polishing code - getting a draft/do-not-merge PR up with the core of my proposed changes up for review helps me avoid that, plus getting an earlier review helps with finding issues.
Re: It's OK if your code is just good enough
#130Earlier quoted context omitted.
For those kinds of cases, I love having as-simple-as-possible reference code checked in alongside it, even if it's just #ifdef'd out for common builds. Having a baseline makes it sooo much easier to understand and debug the optimized code.
Ideally, the slow code is available alongside the fast code and the unit tests confirm they are sufficiently equivalent. If that's not possible, the go-fast bits need to be refactored until it is possible. Don't forget that error handling is part of the equivalency testing.
Beyond unit tests, this seems like a great opportunity to leverage property-based testing, at least for pure functions; checking that both versions return the same results is an easy property to think of.