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

101–110 of 149 posts

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

#101

Post by moonshinefe »

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…

You are not alone. It is not fun.

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

#102

Post by icedchai »

john-tells-all wrote: post #98
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…

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!

That's fine. What I'm talking about isn't that at all. This was a "this feature is done, here you go" PR.

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

#103

Post by josephg »

icedchai wrote: post #68
josephg wrote: post #66

Earlier quoted context omitted.

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.

It is applicable regardless of industry. If your manager isn’t technical, drag the nearest senior engineer into the conversation too.

As for the PR, don’t bother. “Hey this code you’ve submitted for code review doesn’t even compile. I’m your colleague, not a human compiler. Please don’t waste my time with this again” -> Close issue.

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

#104

Post by axiosgunnar »

sneak wrote: post #59

I once saw a 5000 line file of shit-tier code making a business something like a million bucks cash per day. It was a single huge function, called from cron every 5 minutes. No locking to prevent concurrent runs if it took longer than five minutes to execute. No exception handling. One giant nearly incomprehensible everything-function. Global variables. Bugs everywhere. Easily hundreds of thousands of dollars of net…

[dead]

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

#105

Post by Spivak »

diarrhea wrote: post #91
zenbowman wrote: post #49

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…

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 functions and methods that explains to me the reader better what's really happening than the code that's actually doing the real work. And worse it bites you in the ass when you realize that 5 layers down the call-stack you need to change the behavior of something only to realize that doing that breaks a bunch of unrelated places in the code that need the current behavior. So much for locality.

If your code isn't abstracted and WET I actually only have to look at the code currently in front of me on my screen to know fully what's happening and I can be absolutely sure that changing it won't affect anything else. True locality of thinking. Needing to use :vimgrep to update code in multiple places is smooth brain completely mechanical compared to the hell that's having to re-WET the code to split off and isolate the (potentially long) codepath that needs to change. And devs rarely put in the effort for that, more likely is they'll plumb down a flag all the way through the call stack to spooky action at a distance change the behavior of an unrelated function. Good luck figuring out that dependency later when you're starting from the lower function.

My motto has always been software is like pottery, once is DRYs it's much harder to change.

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

#106

Post by soulofmischief »

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…

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, so try to make it a company that is, or leave, but do yourself a favor and find a team you love.

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

#107

Post by pixelfarmer »

3cats-in-a-coat wrote: post #7

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…

In terms of quality, hardware suffers also problems due to increasing complexity. Errata sheets of highend SoCs can be rather intimidating on their own already.

And it is this complexity which drags down performance as well. If a smartphone app is nothing else than a glorified web browser showing some heavy javascript riddled abonimation you don't need to wonder why the things are sluggish and memory hogs to boot. Not all apps are like that, but you get the idea.

But to lighten the mood a bit: https://www.youtube.com/watch?v=gWVmPtr9O0g (Titan 2 demo on SEGA Mega Drive / Genesis)

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

#108

Post by Nasrudith »

dataflow wrote: post #27
thdc wrote: post #19

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

It is worse than them not paying you. "You" (the company) are paying them. That means you want to minimize the amount of time they spend on the software without getting further returns of some sort.

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

#109

Post by realusername »

yen223 wrote: post #64
realusername wrote: post #8

Earlier quoted context omitted.

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.

My standard personally is "can I understand by just scrolling the code without working on it?" And here it's clearly not it.

There's a lot of factory code stuff which don't convey any information and very long chains of folders which does not help comprehension

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

#110

Post by dataflow »

Nasrudith wrote: post #108
dataflow wrote: post #27

Earlier quoted context omitted.

You can change the definition but you change the fact that those "users" aren't paying you.

It is worse than them not paying you. "You" (the company) are paying them. That means you want to minimize the amount of time they spend on the software without getting further returns of some sort.

The point I was making was that if your product is good, even if the source code is terrible, you can still keep selling it as-is and keep making money. You won't be able to improve it easily, but at least the current state is producing value. By contrast, if your product is bad, then you're going to miss out on revenue until you fix that, no matter how awesome your codebase is.
Post reply on HN