7 ms·
Give up on “good code”. Its pursuit is how junior devs pesters senior devs based on a delusion that such a thing is possible. Good code is working code, code
by Zetice 3y ago
Give up on “good code”. Its pursuit is how junior devs pesters senior devs based on a delusion that such a thing is possible.
Good code is working code, code that pays the bills. Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours.
- bentice 3y agoGood code "is isolated enough that rewriting it won’t cost absurd hours." This is the hard part.
- HumblyTossed 3y agoYes, and it also is the point I think most people here are missing.
- happytoexplain 3y agoThis is uncharitable. The GP's comment is short. What people have an opinion about is, "Give up on 'good code'" and, "working code, code that pays the bills ... code you can throw away easily, code that you are wholly unattached to".
- johnnyanmac 3y agobig claims require big justifications. I can't just go out and say "C++ is better than Javascript" and expect people to not scrutinize me because "well it was a short comment". But hey, they do justify it in responses. So maybe they are indeed playing to their philosophy of "work fast"
- iamflimflam1 3y agoSo much this. Good code is code that delivers business value.
- rmnclmnt 3y agoAlso, good code is code that respect constraints and objectives from test suites
- chrnola 3y agoI would amend this just to “delivers value”.
- happytoexplain 3y agoWhere business value has a time dimension.
- Zetice 3y agoSeparately, if you won’t be dissuaded from this pursuit, check out redis.
- happytoexplain 3y agoTaken at face value, this advice is probably just as bad as the opposite ("write perfect extensible modular code with 100% documentation and test coverage"). There is a lot of room in between where the enlightened developer can find happiness.
- Zetice 3y agoYou misunderstand; nothing about what I suggest says you shouldn’t write, “perfect extensible modular code with dull documentation and tests.” If that’s what you need to do to solve the problem, do that. The point is to stop focusing on the code as the work product, and instead focus on the solution as the work product, of which code is one part.
- weatherlight 3y agoThese are the same thing. Good code should always solve the solution, to be considered good code. Bad code might solve the solution, it might not.
- gwbas1c 3y agoI disagree. The problem with believing that "good code" is good enough to deliver business value is short-sighted. Good code is highly maintainable so that you can continue to meet business objectives in a timely manner without regressions. Often this means (ironically) taking a little bit of extra time early on to think about how to make your code readable and "simple enough" for someone else to be able to jump in and maintain it.
- nailer 3y ago> Focus instead on writing code you can throw away easily, code that you are wholly unattached to and is isolated enough that rewriting it won’t cost absurd hours. > Good code is highly maintainable so that you can continue to meet business objectives in a timely manner without regressions. I think you essentially agree on what people should do, regardless of whether you call this 'good code' or just maintainable code. Write tests. Give things good names. Use comments to explain why you're doing something, not how to program. Don't copy and paste the same implementation x times because that way there's only one place to fix it.
- nkjnlknlk 3y ago> Don't copy and paste the same implementation x times because that way there's only one place to fix it. But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) I think the purpose of questions like the ones by OP is not to figure out "rules" (which are useful only for beginners) but to figure out where and why rules were broken. Sometimes (often) the answer is time, but that in and of itself is a useful example. Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward.
- johnnyanmac 3y ago>But also sometimes it makes more sense to copy and paste over trying to fit an abstraction where it shouldn't be. :) depends on goals. diverging modules should be copy-pasted, two modules that rely on the same functionality should be consolidated (not necessarily abstracted, but synchronized somehow). Those are both two common cases, so there's no general advice on which is better. >Good intermediate (I suppose Sr. in our industry) level code is notoriously difficult to find examples of and mentor toward. so much industry code and knowledge is proprietary, so I imagine that is by design. even intermediate code has a bunch of value to a company, even if the company lets go of that engineer to make their earnings report 0.1% higher.
- bandyaboot 3y agoIn general agree with the sentiment not to obsess over perfection, but not sure it’s great advice for someone looking for code to read and understand.
- eddieroger 3y agoI would say a take on this is good code is code that is worse than the next code you write. Don't pursue perfection, pursue improvement over time. Make things work but learn new stuff that makes your old stuff look foolish. Improvement is more important than perfection.
- alserio 3y ago"write code that is easy to throw away" is generally a good piece of advice
- bluefirebrand 3y agoWith the caveat that "easy to throw away" means "easy to understand the implementation front to back so you can know the full impact of throwing it away without crossing your fingers"
- alserio 3y agoI don't know about front to back, a good module should be explicit on what it affects and _ideally_ abstract its implementation. We were talking about what a module should aim to be, and that aim is a good proxy for a lot of properties of well architected applications, even when not perfected. And even when you don't plan to ever throw the module out.
- farresito 3y agoThis mentality is how you end up inheriting terrible codebases.
- Zetice 3y agoI would rather write “bad” code that lasts long enough to be inherited than write perfect code that sits idle in a repo because I missed the market.
- farresito 3y agoWriting good code doesn't necessarily take more effort than writing bad code; in fact, my experience tells me otherwise. Teams that write good code iterate faster.
- Zetice 3y agoThe point I'm trying to make is that the pursuit of "good" code is futile, as it does take more effort to achieve than writing functioning code. But in a way you're right; if there is no to ensuring your code follows more conventions, go for it. That's exceedingly rare, however, as a situation to be in.
- bluefirebrand 3y agoWhat property of the "good code" allows them to iterate faster? Is it because it's perfectly abstracted and encapsulated and SOLID and DRY? Or is it because it's written in a manner, easy to understand, easy to extend, and easy to throw away and rewrite if necessary?
- nurettin 3y agoIt's abstracted a little bit, but every abstraction is designed to lift a roadblock and reused multiple times like an old tool. And special effort has been spent on avoiding technical debt (hard coded stuff, untested stuff, overloaded or missing properties) to the point of doing things with less effort.
- 3y ago
- roenxi 3y agoComes down to semantics, really. Is "good" equivalent to "acceptable" or does it mean "to be strives for"? Code that works is, usually, acceptable. But code that is acceptable while making no unnecessary maintenance trade-offs is much better. Good code is code that uses standard techniques in standard ways to achieve a result without being verbose or inefficient. But that is a much higher bar than code that is literally good enough.
- Draiken 3y agoIf you're at the start of a company writing an MVP, then you're spot on. If the code isn't being written for a startup in the early stages, this doesn't make sense. Writing bad code that just "gets it done" is the proverbial broken window. It's how you end up with shitty code-bases that get shittier with every change, until it all collapses under its own issues. Doing this on established code-bases is basically what the classical duct tape programmer does. Sure, you deliver "business value" in the short term (normally to claim credit and gain favor) but at the expense of everything and everyone else.
- deleted 3y ago[deleted]
- talldatethrow 3y agoI am a self taught LAMP guy that wrote a mini saas that 34 companies pay for and use. It pays the bills, and works surprisingly fast compared to most CRMs, but I can assure you, it is not good code. Even I'm pissed how shitty I let it get.
- talldrinkofwhat 3y agoevery journey starts with a single jira. -C#onfucius
- zulban 3y agoPlease send me your juniors, I'd like to hire them.
- gorenb 3y agoI’m not sure if this is an insult or compliment…
- johnnyanmac 3y agoI took it as a compliment. Some value "productive" engineers, while others value "curious" ones. curious ones are probably for companies that want to retain talent and invest a lot into R&D. productive ones are for when you need to get a product out fast before anything else. Not saying one is better than the other. Sometimes being first across the line is make or break for a company. But I wish companies could be more honest about what they want.
- zer8k 3y agoThis is what "top down" coding looks like. In "top down" coding you're told what to do by the boss, given too short a timeline, and forced to push something out the door. Congratulations on figuring out how to create a massive churn rate among your actual good engineers.
- Zetice 3y agoGive me engineers who value solving problems, sometimes with code, over “good” engineers every single day of the week.
- happytoexplain 3y agoI understand you're characterizing the word "good" as some bad definition of "good" used by some subset of others, but your quotation marks are doing a Herculean amount of lifting (i.e. it's hard to tell what you're saying). I think most people would consider "engineers who value solving problems" as "good" and vice versa.
- Zetice 3y agoI'm just using "good" here as defined by the parent comment I replied to, to make the point that I believe the engineers as he described wouldn't value solving problems as much as they value "good" code.
- johnnyanmac 3y agoIt goes hand in hand. We're still talking about engineers here, not pure computer scientists. And if we want to call them "engineers" they should understand short and long term ramifications of any decision they make, something reflected in the code they are responsible for. Few other engineers would ever accept a paradigm of "make fast, re-implement fast", but since that's a luxury a software engineer has, it comes more down to understanding what the business needs and using the right tools.
- johnnyanmac 3y ago>isolated enough that rewriting it won’t cost absurd hours. I mean, juniors can do this. Once you're a senior, there will inevitably be come coupling you need to make in order to "pay the bills". Or you may make the first part of a system that will be a pain to re-write, even if it's the most elegant, readable code ever. Nothing wrong with preparation.
- barrysteve 3y agoGood is a direction. A painter might study and practice enough to be as good as Michealangelo, but the attempt to be 'more good' or 'better than Michaelangelo' stops as soon he starts a serious painting. He has to finish the painting with the skill he has at that point. I agree code should be unattached and you can throw it away. As soon as you start coding a program for a client, your attempts to become 'more good' as a coder and to write more ideal code, have stopped and it's time to make some code you can throw away or sell to the client. But all the 'training' paintings you made on the journey to becoming 'good' have to be kept, because you trashed thousands of attempts along the way in pursuit of an ideal painting. The good painting is framed and hung on my wall. The commercial painting is sold to the client or trashed. Yes, give up on 'good code' at work. Keep the ideal of good code as a direction to improve towards, not an end result in commercial works. As soon as 'good' became explictly defined/bike-shedded it died anyway..... it's an infinite direction, not a limited thing that can be defined and boxed up.
- mattkenefick 3y agoSounds like you've been surrounded with bad code all your life. This isn't true.