Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's OK if your code is just good enough

shiftmag.dev

Post reply on HN
Print view View original

111–120 of 149 posts

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

#111

Post by windmark »

icedchai wrote: post #63
manicennui wrote: post #36

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.

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…

In addition to what the others have said, make sure you have a CI and don’t review the PR until that’s showing green. The CI should ideally include tests, linting according to a common code standard and other “grunt tasks” that are unnecessary in a PR review.

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

#112

Post by a_e_k »

jcul wrote: post #53
manicennui wrote: post #36

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.

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.

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

#113

Post by beezlewax »

icedchai wrote: post #63
manicennui wrote: post #36

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.

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…

Wouldn't a linter catch most of this?

You can also block commits with listing errors

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

#114

Post by nly »

icedchai wrote: post #63
manicennui wrote: post #36

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.

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…

Isn't this what draft PRs, CI/CD and automated integration tests are for?

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

#115

Post by darkerside »

Spivak wrote: post #105
diarrhea wrote: post #91

Earlier quoted context omitted.

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…

I've never understood this mentality, the magic of local reasoning is completely and utterly destroyed by abstractions. If I'm looking at your code it's not because I'm doing literary analysis, it's because there's something wrong or because I need to change something. The abstraction only increases the number of locations I need to look to fully understand what's really happening. There is no clever naming of functi…

I think this is the right mindset. As programmed, we need to be aware and able to distinguish between when two things look the same, and when two things are the same. Only one of those benefits from an abstraction.

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

#116

Post by biorach »

hinkley wrote: post #60
mattgreenrocks wrote: post #42

Earlier quoted context omitted.

> 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…

> 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

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

#117

Post by ra0x3 »

soulofmischief wrote: post #106
icedchai wrote: post #63

Earlier 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…

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.

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

#118

Post by imtringued »

savanaly wrote: post #13
stathibus wrote: post #9

Somehow code quality has become a topic completely divorced from product quality. Your users don't care how clean your source code is, but they definitely care if it's slow and buggy.

> Your users don't care how clean your source code is They do care about bugs and new features though, and bad code quality will lead you to more bugs and slower shipping of features in the medium/long run. At least, that's how I define good code.

I have seen people strive for cleanliness from the get go, but that has resulted in garbage outcomes and overabstraction.

The customers are unhappy. I am unhappy. Everyone is unhappy.

I prefer "messy" simple code that works and is easy to understand. Yeah sure I put too much logic into the controller. I could put it into a dozen different files. Fight me.

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

#119

Post by darkerside »

Two beefs with this article. One, it creates a linear scale for what are probably multiple orthogonal concepts. Accounting for even one more axis would make the article much more interesting and useful.

Two, I don't think 4 is necessarily more effort than 3 (for some values of 4 and 3). What does take a lot of time is if different engineers have different ideas of what 3 and 4 are but lack the perspective to understand each other and choose a common standard. Everyone will choose faster if everybody follows static typing because you can rely on assumptions you otherwise couldn't. And, everyone can move faster if we don't worry about any of that static typing crap. If engineers take different approaches, everybody will move slower and probably hate their jobs as well.

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

#120

Post by tharkun__ »

Spivak wrote: post #105
diarrhea wrote: post #91

Earlier quoted context omitted.

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…

I've never understood this mentality, the magic of local reasoning is completely and utterly destroyed by abstractions. If I'm looking at your code it's not because I'm doing literary analysis, it's because there's something wrong or because I need to change something. The abstraction only increases the number of locations I need to look to fully understand what's really happening. There is no clever naming of functi…

I agree with you in that DRY for "just not repeating yourself" is not good. But your local approach is flawed.

You still have to do the global analysis. You have to do that because the local code you are fixing might be a piece of business logic that has been dripped all over the code by a WET programmer. Now you fixed the logic in one place but all other places are still wrong.

The correct way to do it is to stay DRY when the reasons for changing a piece of code are going to be the same. An example would be this hypothetical business logic. If the code doesn't just look the same but is for something like business logic that needs to be the same in all 15 places it's getting applied then stay DRY. Other obvious examples are things like sorting algorithms. We banned those and put them in libraries for a reason.

Post reply on HN