To Woods’ Maxim — “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” — I usually add the clause “and 90% of the time that maintainer will be future you!”
Haha I’ve been working at the same place for 9 years. Last year I came across some code and thought “who the fuck wrote this shit”. Looked at the history. I wrote it 7 years earlier. Always fun to dunk on old code but still appreciate it pays the bills.
If you hang around long enough you'll end up with code you once wrote that was maybe a quick fix, maybe you thought it was brilliant, but now appears to you as a steaming pile of crap.
Sometimes it may however still be the best solution but your future self was unable to figure out why because your former self was too lazy to properly document the code.
I once worked as a freelancer for a tiny company that at some point refused to pay me for one day of work. One of their reasons was that my code wasn't up to their standards. I could see in git that the code they complained about was actually written by their lead (and only) developer. They still didn't pay, though.
I loved those moments, the work was done, you moved on, and they came with all the ammunition they collected to wiggle out of payments.
The trick is to give them easily defuseable bad ammunition when they "sneak" around to collect. If you disassemble all their arguments and have emails were they were informed, you can trash them thoroughly.
Unpayed though. Cause even good arguments cant help broke little shops.
I talked to a lawyer, and it just wasn't worth going after them for this amount. I wrote it off as a valuable lesson and went to make more money elsewhere.
Unless you are a citizen of the same state the corporation is, you’ll need a lawyer when they file a removal petition to have the case moved to federal court on the basis of diversity jurisdiction.
And if you don't consult a lawyer to prepare for small claims court, you stand a decent chance to be blindsided by that or something else.
Do it anyway. For them to hire a lawyer to determine this, then they have to pay quite a bit of money. It is quite possible they might be bluffed and pay up, or decide it is cheaper to pay up, and then actually pay up.
If the initial action costs nothing, you have nothing to lose, but they will almost certainly lose something. If you do nothing it will cost you nothing also, but you have no chance of gaining anything at all.
They don't need to hire a lawyer to determine it, the junior paralegal in the in-house counsel’s office with a checklist will do just fine, since all the information needed to make the determination will be on the papers they are served with.
> If the initial action costs nothing, you have nothing to lose
Not at all true; one of the other standard techniques for getting things out of small claims court is for the defendant to find anything about the interaction in question that they could countersue for that would raise the amount in controversy above the small claims limit (since the requirement for linked counterclaims to be handled in the same case and the small claims limit interact to requiring moving the case when this happens), even if it is something that they wouldn't sue over otherwise.
I heard a saying once: "all developers should be embarrassed about code they wrote more than a year ago" as a (cheeky) measure of ongoing growth and development. :-)
Pretty funny, about 15 years ago I started looking back at myself a year ago and decided that until that dude from a year ago looks like an idiot then all is well with my life. Hasn't failed yet.
I've seriously considered removing some of the older semi-popular projects from my github solely because I would be embarrassed to show them to a prospective employer, or even other developers.
In the end I think it's actually kind of fun to look back through the code though, and think "surely I should have known about X back then... Why didn't I just do that instead."
As someone who looks at GitHub accounts as a resume, I can tell you that improvement over time is amazing to see. Assuming it’s clear what’s most interesting or recent.
Interestingly, I recently looked back at an old disk drive with my first "real" unfinished side-project which I started as a teen learning to code.
And, to my surprise, it was not _that_ bad.
Sure, it was full of naively implemented stuff that could have been implemented way better. But, even a decade and a half after, it was pretty clear to read, and it was decently organized.
And, in some ways, I preferred this code to the one I'm writing professionally. I was honestly prouder of myself as a teen than myself as a professional programmer.
The difference, I think, is that I had a clear idea of what I wanted to achieve for this project to be considered as definitely finished. Since I started working on code (for money) I've always been working on never ending projects. This industry (and me, as a professional) is obsessed in writing code for long term maintenance and evolution instead of effectively finishing products.
So, to get back on topic, I'm not sure you really write better code with time. I mean, yes, you totally do, but it's not as important as learning how to code for others to be able to understand and modify it with constraints you can't even imagine.
And I saw a lot of people writing super nice open source side project and then, when you work with them on some professional level, well, they still write the same shitty code as everyone else.
I think you progress mainly by learning the type of code not to write. There is a large permutation of valid program terms that can achieve your desired result, and it takes time to know what sorts of permutations are unnatural or express "awkward" programs with undesirable properties.
Like when you learn a natural language's vocabulary, but you still need to figure what conjunctions of words are not intelligible or natural phrases to fluent speakers. Phrases that have ambiguous meanings or otherwise generate confusion.
I think there's a comparable notion of fluency in programming that goes what most people mean they say they're fluent in a programming language.
I honestly find that kindof frustrating. I look at code I wrote a year ago and think - why didn't I do it this (better) way. And I also think - haven't I learned to write decent code by now? Why do I keep writing code like that when I should know how to write it better.
I don't mean this sarcastically, you're probably an better coder than this comment implies, but what you described is the mind's mental content that should motivate you to write "decent" code.
Do you only feel this motivation when you look back at old projects? Perhaps the improvement could be in organization (code-level or otherwise) such that you do not feel lost or confused looking at your old stuff.
The code you wrote a year ago should have good points and bad. If it is just bad, then you either started programming a year ago, or should perhaps start thinking about changing jobs.
If you are actually improving then there should be some good in there (you got better from two years ago right?). If you can't identify that good, then either you are just chasing fashion (that perfectly good construct from two years ago is now out of fashion so it is "bad"), or you haven't improved your ability to tell good code from bad and just calling it bad because you are unfamiliar with it.
If you want to actually get better at code then you should do a real review of the code you wrote a year ago. Where did bugs occur in the code you wrote? Is there something that you could have done to make it less error prone? Is there code you wrote that is easy to understand? What design choices can you make so that more code ends up in the good code camp? How were the bugs detected? Can I integrate that in to what I do for testing? Then actively practice moving your code in the good direction and away from the bad.
Anything less is chasing fashion and using familiarity as a good and unfamiliarity as bad. "As is" it is a pithy blog post for Coding Horror, but won't get you there. Pursuing greatness requires directed improvement
I've read that and think the saying is fundamentally wrong. If you're constantly embarrassed at code that is only a year old, I think it's much more likely that you are chasing fads rather than actually improving your code quality.
I would go as far as to say that it's a negative signal, because instead of improving code quality you are just changing things that don't really matter.
I'm not a solopreneur but instead a corporate drone, and every time I git-blame questionable code, it's mine. But like others have said, if you're not embarrassed of something you wrote a year ago, that's not good.
While I am not solo, I have still been around for longer than anyone and the primary maintainer of a few repos. I tend to skip straight to "WTF was I thinking", because if its weird it was definitely me.
After about 20 years of doing this (not particularly as a solopreneur), I understood the following: I sucked really bad yesterday compared to today and today I'm sucking so much more than I will tomorrow. And it makes me really happy that I can still say this. The moment I won't be able to say this anymore, is the moment I'm done and I can finally die.
Well, the fun thing is that at the moment you expire you can be sure that you sucked the least in your life but some young and inexperienced coder will still look at your code and ask “Who wrote that shit?” :-)
On the other end, it's fun when you encounter a bug and go search for an answer and end up reading an answer on Stack Overflow that _you wrote_ 5 years ago and totally forgot about it.
Equally fun is using a package or a part of it that you haven't used for a few years and going to read the docs for a certain feature... and realising you're the one that wrote those docs :)
Haha, this happened to me for the first time recently. Asked a question, didn’t get any answers, ended up updating my post with the answer I eventually found. Even had a couple of responses thanking me for the follow up. Five years later, ran into the same problem and forgot the answer, my answer was the top result on google.
I was once looking to see if there were any projects or discussions regarding <insert niche domain> via the google search "<niche domain> Hacker News". I clicked on the top link because, read the comment, and was annoyed that it didn't actually address the <niche> things I wanted it to.
Then I realized I wrote the comment. I didn't address the <niche> things because I was looking for it then and I'm stilling looking for it.
I am working on a fairly ambitious project. It is in the stages where we are nearing the end, and the tofu is getting firmer.
I had an issue, last week, where a bug was caused by an omission I left from an SDK that I wrote, maybe, eight years ago. It was a simple thing. I didn't add a "RefCon" to a server interaction, so I couldn't attach a reference context to a callback. This is a classic pattern, that I've used for decades, and I have no idea why the hell I didn't add it to this SDK. I suspect that it might be that the SDK was for a fairly wide audience, and I probably thought that they wouldn't understand it. So here I am, paying the price for underestimating my user base (which, so far, is Yours Truly).
Anyway, the "fix" was to implement a semaphore, and treat the call as blocking, which is awful. I really need to go back and change the SDK, but that's a fairly fundamental change, that I can't afford, right now (the SDK tofu is rock-hard).
That's another old saying - you should try to make code readable not only for the sake of other developers who will work on it in the future, but also for your own sake...
Haha, yeah. My reaction to the title was "my past self, usually." I've seen utterly horrible code written by people who I consider myself leagues beneath. Sometimes git blame is a lesson in humility.
Feel like there has been increasingly more cuss / inappropriate words showing up on top page of HN. I recommend HN to my kids. Not that they are not exposed to these words online but I would rather not come this from their parent. Not sure how to feel.
Edit: To add more to this, feeds train our brain to consume content which we don't even need. Search on other hand is inherently required when we are working on something cool.
Yeah, and sometimes you can lose meaning too. If I were implementing this, I would bleep out things like slurs, and words like 'shit' would be replaced with their (arbitrarily less crude) counterparts - 'crap' in this case.
There are existing software and methods to get around this problem of accidental censorship. Someone mentioned maintaining a professional vocabulary, and I am inclined to agree: The more you read people writing with crude language, the more likely you are to accidentally let it slip around your parents, or someone like a small child.
Anyway, on the subject of the actual post, comments are you and your future self's mutual friends.
Isn't there a minimum age requirement to be on HN? I mean I don't see anything obvious.
That said, we're all adults here, mostly liberal leaning, and we all grew up with the internet; a bit of potty mouth won't hurt anyone. I mean you can take the moral high ground and consider anyone using swear words as immature and move on, I guess.
I'd suggest that if you don't want kids to read the word "shit" you keep them off the Internet entirely for life rather than running around trying to impose your morality on everyone else.
I’m not worried about my kids seeing curse words. I am concerned about the downward pull normalizing unprofessional writing has on my profession.
Does it make our whole environment less professional? Does it influence us to be unprofessional in other parts of our craft? Do outside observers view us as less a profession because of it?
I don’t know the answers but I certainly worry about it. Though perhaps I’m just aging out of this audience.
I think there is something to worry about, but it's not 'unprofessional writing' or any kind of external downward pull, I'd say a lot of the problem is how much time professionals now spend in unprofessional contexts, even during working hours (he says, typing while clock-watching...).
This is a post on someone's personal blog with some reflections on something they saw at work. I'm not sure why we should expect him to write professionally (leaving aside the question of whether swearing is acceptable in professional writing or not).
I also wouldn't necessarily expect HN to only carry professional content - although some of what's shared here might be interesting from a professional viewpoint, it's not a portal for professionals (what even is 'hacker' as a profession? What percentage of the HN community are amateur hackers rather than professional hackers?).
Ultimately, it's a discussion forum on the internet, where self-proclaimed hackers share things they think are cool, and if others think it's cool too, then it gets shown to more and more 'hackers' until not enough new people think it's cool enough, at which point it gets shown to fewer and fewer people.
This audience is at a particular peak of glibness and superficiality this week. It's interesting to think about what kind of place it would be if there were a couple artificial norms of decorum, like "no swearing" (I'd find that difficult to adhere to, at least at first). It might be better; sometimes rules like that can subtly remind people that there's a minimum threshold of thoughtfulness required before chiming in.
I find it a refreshing experience to look at your own code from 10 years ago, or even 5 and think "Who wrote this shit?". If I ever look at some of my old code and feel good about it, that means I have failed to improve.
I find that half the time I'll wonder who wrote it, realize I wrote it, start to rework it, and then realize why I wrote it that way in the first time, add a comment and move on.
I prefer to add comments which contain some rational, like "Changing this causes race condition headaches in the frobulater." Or "Ugly... but it handles the edge case of XYZ in the foobar config"
If I don't then the comments either have the effect of a) scaring future me, or b) getting ignored because I think that I can do better now.
I've been annoyed by my own legacy code long enough to try really hard to make sure the features being asked for are REALLY needed, simplifying things as much as possible before going into code. That's usually where most of the code is removed - sometimes all of it.
I'm in a constant state of this in the codebase I inherited. The previous solo front-end developer was the manager of R&D so he couldn't be fired easily, he was the only person willing and sort of able to do front-end (PHP + JS/Dojo), he was super productive (most code was written in 2012/2013), but not a very competent or self-critical developer.
Think a back-end that concatenates XML into a big global string over the span of thousands of lines of code, then passes it to a function that parses it and outputs it again as JSON.
Think functions spanning a thousand lines with triple-nested switch/case and if/else blocks
Think a front-end where JS is used to concatenate HTML, CSS and more nested JS together into a string
Said front-end will save and reload the currently active page on change of any form field, and there's dozens of form fields across dozens of dialog screens.
When I joined I was given free rein to rewrite it in the technologies I thought would suit best. It's been two years, at a stretch I'm about 20% of the way there. It's a project that needs one or two fully staffed development teams, but we have the budget for two people because our management resists faster growth or investments.
>> Think a back-end that concatenates XML into a big global string over the span of thousands of lines of code, then passes it to a function that parses it and outputs it again as JSON.
I'm talking out of my ass here, but it doesn't sound like you are trying to rewrite it, but rather refactor it in place. This often takes much longer than a proper rewrite in my experience.
When I joined I was given free rein to rewrite it in the technologies I thought would suit best. It's been two years, at a stretch I'm about 20% of the way there.
This is the danger of rewrites (assuming this was not actually greenlit as a 10 year project)!
It was me ... several times I have found a bug or code smell and then been surprised that the I was the original author. For the last fifteen to twenty years, I've generally found looking at code I wrote six months ago equally distasteful. So now my default behavior is to assume the code met the business function at the time, acknowledge that I'm continuously improving in my craft and finally, gained a joy in spending part of my time doing maintenance programming.
I'm a strong believer in continuous refactoring. Improve existing code when you touch it. Defer architectural choices untill the moment you have enough info. And leave cleaning up to the moment that it starts becoming messy, not before.
That implies, code never is perfect. Not even good. But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand.
>But always just about 'good enough' to solve the issue at hand.
I think this is context dependent. I generally agree with this statement on relatively low-risk projects. The problem with "good enough" is that it often becomes a rationale for our cognitive biases to take the easier route. I don't want someone doing that on, say, safety-critical code. Maintaining high standards is a way of buffering against those cognitive biases.
I suppose, but by that same token standards would be the definition of pre-defined "good enough". In my experience, the nebulous nature of the term is usually a means of rationalizing a sub-standard effort. The benefit of defining that threshold upfront is that it's hopefully more objective, before you let cognitive biases influence your decision making.
It really comes down to understanding why the goalposts have moved. Is it because you have more information to reduce the uncertainty about the risks that standards are meant to be mitigate? If so, great! If not, it's a red flag you may be responding to something else that increases risk, like schedule or cost pressure.
The point is that there is no one predefined "good enough", but rather the level of quality that code needs to reach is context dependent. That is why you end up constantly refactoring a little each time you touch the code as that context has usually shifted.
I disagree. There are lots of examples of standards that define what is "good enough."
For example, NASA has different standards depending on risk categorization and the predefined threshold of quality gradually gets higher as the use gets riskier. A business application is held to a much lower level of quality than software for a robotic mission which is lower than a human rated development effort.
We are laying out an approach to software development, refactoring, and a model for how to view old code that you some acroas that seems bad.
You seem to be stuck on the term "good enough" and arguing semantics that don't make sense. Yes, sometimes there are standards. that you need to meet. Sometimes just meeting the offical standard is not "good enough", and you need to do more. "Good enough" is inherently contextual, and you seem to agree with this, but seem still be arguing against using that term?
Good enough is usually an excuse for vague and ill-defined practice. If you don't have a well-defined "good enough" you probably don't have a mature process. If you don't have a mature process, you probably shouldn't be writing critical code. Hence my original comment that it's not a good mindset for high-risk applications.
Well defined "good enough" often looks like a standard. Those standards should be risk based so that one person's biases don't result in a different level of risk mitigation than another person's. That risk is what contextualizes what is "good enough". I'm sure if you asked the Boeing managers, they felt their CST-100 software was "good enough", but the relevant safety standards say it wasn't "good enough". Since both sides can use the term, it makes the term somewhat useless. Like you say, there is no singular "good enough" so the question becomes: Good enough...for what? Good enough to meet schedule, or good enough to not risk crashing into the ISS? My main issue is that "good enough" often means "undefined". When people say "good enough", I've found it often means "we don't know what we need, but I'm sure we'll know it when we get there." I think that can be a bad approach to software development when the risks are high because it opens one up to cognitive biases that lead to subjective and poor decision making.
If you're saying "good enough" is precisely defined and based on risk, then I agree. But that is not how I've ever seen the term used in practice. It's almost always a nebulous term which means you've only vaguely defined the risk. Poorly defined, subjective judgement belongs more to art than engineering, especially not safety-critical engineering. "clunky, cobbled together, expermental or just plain stupid" as the OP said, just doesn't cut it on critical applications, even if the developer claims it's "good enough" and doesn't strike me as a professional mindset.
You have a highly specific definition of good enough that doesn't match my experience with it's usage. Every time I have discussed whether something is "good enough", the discussion centers on what the relevant risks, needs and priorities are. Indeed, adherence to relevant standards should be part of the "is it good enough" discussion, but following standards alone doesn't absolve you as a devolper from assessing the current contextual needs and risks.
Indeed, blind adherence to standards is bad as standards are not perfect and are designed to fit a general use case. You need your developers/engineers to think about the full context and asses whether their design will hold up under real life conditions and not just those that were prevalent when the standards were created.
I think you might be subjectively reading too much into it to make a point that doesn't need to be made.
Look at the actual wording of the post I originally responded to:
>"But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand."
Can you imagine a discussion about relevant risks and priorities that uses that definition of "good enough"? I can't, especially with safety-critical code.
I'll give another example: The NTSB report of the uber autonomous driving accident gives a good breakdown of events. Through that report you can see the developers programmed a delay (they call it an "action suppression") due to nuisance braking etc. It's hard for me to imagine a code engineer programming a delay on a static delay time-sensitive safety critical system if they understood the risks (even if the mitigation was the human driver, they didn't seem to have a good understanding of human factors engineering). Yet someone along the way thought the software was "good enough" for production. It's speculation on my part, but I doubt you'd find a good FMEA or hazard analysis on that system. This is my big worry as SV mindsets get into safety critical systems: the general "move fast and break things - because it's 'good enough'" doesn't translate well to systems where lives are at stake. That is what I was responding to: the over generalization that clunky code (in the OPs words, not mine) is 'good enough"
> Can you imagine a discussion about relevant risks and priorities that uses that definition of "good enough"? I can't, especially with safety-critical code.
That's not a definition, but a description. It was pretty clearly not an description of "safety-critical code".
You've inserted a context of safety-critical vehicle control systems into a comment responding to an anecdote about writing PHP4.
You say things like:
> Poorly defined, subjective judgement belongs more to art than engineering
That only seems true if you are extremely lucky and/or early in your career. It is extremely common for software engineers to face poorly defined, nebulous problems that you simply don't have the information to solve in an objective manner. The frequency with which this happens is why the approach described by the top comment is so effective. It is a process of continual improvememnt where you try to avoid making unnecessary decisions until you have better information to make them with.
What changes with safety critical code is how you gather that information (and what other processes to build to supplement developer judgment). You try to gather that information with as little risk as possible. Experimental clunky and cobbled together code has a place in this process, but not as a part of live, uncontrolled testing. You run it against models as you prototype solutions and then you refactor or rewrite that code to be good enough to test in riskier situations.
The quality of the assessment matters, but there is really no problem with people making an assessment of whether the code was "good enough" for it's context. In fact, I would refuse to work with a developer who refused to make such assessments. Standards and outside analysis are important, even in non-safety critical systems, but they ate no substitute for a developer making careful assements of if code is good enough.
This is part of the point the article and top comment are making. You can assume that the person who "wrote this shit" is an idiot and mock them, but you will learn more instead if you try to understand the context that drove that person to make the decision, how well that decision worked out, what it cost them and what it gained them. This is how you avoid cognitive biases, not by refusing to accept code that is truely "good enough" in some quixotic pursuit of impossible to achieve perfection.
> That is what I was responding to: the over generalization that clunky code (in the OPs words, not mine) is 'good enough"
I think you are tilting at windmills here. There is no such broad generalization. Clunkly code is often not good enough, which is why it needs to be refactored, "the moment that it starts becoming messy" (which is, I'm sorry to tell you, a context dependent subjective judement call.)
But clunky code can be fine or even great. I'll take a defect free clunky code base that solves a stable problem over an elegant rewrite that adheres to the latest coding standards any day.
Just out of curiosity, what do you think standards are meant to address?
In my experience they are meant to mitigate risk. Now maybe that risk is not credible on a particular project which means that standard doesn't apply. But in all other cases, not adhering to standards means you are incurring additional risk, by definition.
Now maybe you're just saying, "Yeah, but those are acceptable risks" in which case I don't really think we're saying anything different. My experience working on safety-critical code uses standards that explicitly state what risk is acceptable so there isn't much wiggle room for wishy-washy statements like "good enough". They aren't esoteric, abstract standards of practice (and maybe that's where our personal experience diverges). It becomes relatively clear, with a good testing plan to maps to said standards, whether that risk threshold was met.
It's easier to illustrate with hardware, but the same principles apply. Say there's a standard that states each critical component must have a specified reliability level. You could either install a single component that meets that reliability level or design redundancy so the overall reliability meets the standard requirement. What you can't do is install a lower-reliability component and claim it's "good enough" unless you change the definition of critical. And that's what sometimes happens in practice; people get through a design/build and realize they didn't meet the pre-defined/agreed upon standard and so they perform mental gymnastics to convince themselves and others that the component isn't reaaalllllly critical as originally defined. And that discussion shouldn't be based on subjective judgement. As the sign above my old quality manager's office said "In God we trust, but all others must bring data."
>I'll take a defect free clunky code base that solves a stable problem over an elegant rewrite that adheres to the latest coding standards any day.
This might be part of where our opinions diverge. My experience in hearing "good enough" seems different than yours. It sounds like you're using it as "it solves the problem, so it's good enough". My usual experience is more along the lines of "it doesn't meet the standard, but it's good enough." The issue in the latter case is that I think there's some hubris that one fully understands the problem. If you do, then you should have no problem bringing data to support that claim and we'd have no qualms. But if you can't, one thing standards are good at is helping to make you pause to consider all the aspects of the problem you didn't think of. Part of that hubris is the assumption that it's a stable problem. Standards capture the lessons learned when people realized it's not so stable. So clunky code may good enough to solve your conception of the problem, but that still may not be good enough if your conception of the problem diverges from reality (see: 737MAX MCAS, uber, CST-100, etc. as already brought up).
Like I said earlier, you got fixated on your own understanding of what "good enough" means and didn't actually pay attention to what people were actually talking about. Instead of learning something, you went on a diatribe and repeatedly misrepresented what people were actually saying.
I've seen people adhere blindy to standards and I've seen people ignore standards without a good reason. Both are failure modes that can increase risks.
I also think you are grossly simplifing what caused the engineering failures you mention. They have a lot more to do with systemic pressure and misplaced priorities than they do with engineers making contextual assements of risk beyond what is stipulated in the standards.
I don't think I was misrepresenting. I think it just boils down to we both read the OP differently. It's possible to have different takes without it being ascribed to malice or deliberate misrepresentation.
>I also think you are grossly simplifing what caused the engineering failures you mention.
I don't know how you arrived at this conclusion? I am in no way simplifying. I said those types of systems are complex to the point that subjective determination of good enough isn't adequate and how standards help fill those gaps of understanding. I've literally worked on some of those systems and have had listened to people at the highest levels of some of those organizations about the nature of those failures. I've withheld approving plans of one because I witnessed firsthand how the nature of external pressure corrupts what is meant by "good enough". If you know more intimate details on any of those examples, I'm all ears.
>They have a lot more to do with systemic pressure and misplaced priorities than they do with engineers making contextual assements of risk
This is the exact point I've been making but I think the two are interwined. Those competing pressures make fertile ground for rationalization and cognitive bias to influence decisions to change the definition of good enough more in-line with the verbiage of the OP (again, there was no discussion of risk in that post, you shoehorned that into your interpretation. There was only discussion of clunky, stupid code which was blessed as good enough). You seem to imply risk understanding occurs in an objective vacuum and I disagree. That's why I think subjective determination of good enough falls short in some scenarios. I'm not sure if you've been so focused on being right that you've ignored that central point, or if I'm just not communicating it effectively but it's not really worth belaboring further.
> It's possible to have different takes without it being ascribed to malice or deliberate misrepresentation.
Which I did not do. I don't think you are doing it deliberately or I would have ended the conversation long ago.
> You seem to imply risk understanding occurs in an objective vacuum and I disagree.
Not at all, where do I imply that? It is actually the opposite. I am arguing against your position that risk assements should happen in a vacuum and be based purely on standards with no need or room for subjective reasoning.
> again, there was no discussion of risk in that post, you shoehorned that into your interpretation
While the top comment did not explicitly mention "risk", the comment or did reply to you saying:
>> Isn't that by definition what good enough means? That on safety critical code "good enough" is a very different level than on a throwaway-script?
> That's why I think subjective determination of good enough falls short in some scenarios.
I've repeatedly said that subjective risk assessment is usually not enough:
>> Standards and outside analysis are important, even in non-safety critical systems, but they are no substitute for a developer making careful assements of if code is good enough.
>I'm not sure if you've been so focused on being right that you've ignored that central point, or if I'm just not communicating it effectively
I think your communication issues or on the listening side as you keep projecting a strawman onto people rather than actually listening to what people are saying.
But since we both appear to feel that the other one is not listening, that is probably a clue this conversation should end. I do encourage you to take some time carefully re-reading the thread to see if you can figure out why you seem to misinterpret so much of what people say.
What an odd and condescending take, even when try explaining to me the failure modes of a system I actually have firsthand experience with. Doesn't that seem like something that should give you pause to self-reflect?
I understand your point. What you seem to be missing is that we're talking about two different things. I agree that decisions should be made in the context of the risk of the engineering application. That's trivially apparent to the point where it's almost confusing that you would feel the need to bring up up (ad nauseum). It's also not particularly interesting because just about everybody will agree with that. What I'm talking about is when people fall prey to cognitive biases to the point where they can no longer make accurate risk assessments. That's a much more interesting problem because the engineering world is full of cases where otherwise smart engineers make terrible judgement calls, all the while telling themselves that they understand the risk. I literally brought up cognitive biases in my first post and instead of responding to what I'm actually discussing, you just keep underscoring a trivially simple point.
I think you're reading your own interpretation into what I'm trying to say and then somehow twisting it into being a miscommunication on my part. When I'm saying subjective judgement can lead to bad decisions, I am not saying "we take all the unique and contextual facts into consideration and arrive at a reasonable subjective risk assessment for this scenario". I'm saying people's cognitive biases can lead to them discounting risk without good evidence because it results in a decision they are emotionally attached to. E.g., "I don't want to miss schedule and look bad, so let's rationalize away this risk that really wasn't mitigated." That is not an objective risk-based decision, it's a biased emotional one. They may think it's "good enough" to get the job done, until it's not (as in the cases I specifically brought up).
While I already explained it but it didn't seem to sink in, I'll reiterate one last time:
You seem to say your definition of "good enough" is based on good, risk-based judgement. I already said if that's the case then we don't disagree. But I also said that is not the context that the term "good enough" is generally used in practice. In my experience, it's used to justify a sub-standard effort and I've given you concrete examples of that. That point of digression between what I'm saying and what you're interpreting seemed to fly right by you because you're more concerned with arguing, and there's some irony in you pointing out that someone else isn't listening.
> You seem to say your definition of "good enough" is based on good, risk-based judgement.
Not at all. I said that "good enough" is a contextual, subjective judgement and is a critical part of software engineering. The idiom "good enough" says nothing about quality of that subjective judgment, despite your insistence that it does.
> I'm saying people's cognitive biases can lead to them discounting risk without good evidence because it results in a decision they are emotionally attached to
Of course cognitive biases (and all sorts of other things) can degrade judgment. That doesn't mean that we should try to get by without it. We seem to be in agreement on this.
> that is not the context that the term "good enough" is generally used in practice.
Here you are simply wrong. "Good enough" means " adequate but not perfect, not "sub-standard". While it is possible you have been operating in a cultural bubble where that term is only used to mean "sub-standard", in this context the meaning of "good enough" that is being used has been clarified repeatedly but you insist that only your experience with the term matters and thus everyone must use your definition. Instead of working to understand what people are saying, you assume that they are using your definition. Perhaps this sort of assumption explains why you somehow missed out on noticing everyone who uses that term in the normal way. Seriously, go look as some definitions and try asking people what they mean when they use the term.
> That point of digression between what I'm saying and what you're interpreting seemed to fly right by you
Another example of you not really listening. I've repeatedly pointed out this exact divergence.
Note that you specific left out the contextual clue where I said "In my experience" that is not how it's used in practice as an immediate follow-up to that sentence about how it's used. I am not making a general case, but talking specifically about safety-critical code from the very start. I am not saying everyone must use my definition in the general case. I'm saying in the very specific subset of cases, there is an objective definition for good reason.
Let me try a different tack to see if we can get off this pedantic merry-go-round. You've agreed that cognitive biases affect decision-making. So let's say as a developer you are working on safety-critical code that is in danger of being over schedule and over budget. Their manager says if the project isn't successful, your company will lose future work to a competitor and that might leave you out of a job. But if it is delivered on time, you're company will get a massive windfall in terms of future contracts and profits, and likely lead you to a big promotion. What do you do to ensure those cognitive biases do not influence you to incorrectly discount risks and ship the software early before the risks are properly addressed?
(Btw, it's a really bad method of communicating to use absolute terms like 'everyone'. For one, it makes it look like you think you're smarter than you are and more importantly, it's easily falsifiable. That type of communication belongs more on r/iamverysmart than HN)
I just would add, that the urge to refactor things whenever possible, definitely introduced bugs for me, because also refactoring has to be done with consideration and some things were weird for a reason, you do not see at first glance.
And refactoring can also hurt you, or another person just used to that code in its old shape. And then missunderstanding things.
I'm an avid TDD developer. Red-green*refactor*. The latter, often overlooked, is IMO by far the most important part of TDD. But the refactor is only possible because of the tests you wrote, asserted, and tested (testing the tests) in the red-green phase.
It gets hairy when a refactor needs to also refactor the tests - often a sign that the tests were lacking in the first place (and the more reason to refactor them). In which case I try to refactor them not in lock-step but decoupled: first refactor the tests without touching the SUT. Then refactor SUT (and then, most likely, another round of this)
There is no fool-proof way. There will be bugs. There will be regressions. But that is a artifact of "change", not of refactoring. I'm also a believer in "never fix something that ain't broken". Which, unfortunately, only works for software that is not ever upgraded, has no dependencies, runs on hard- and software stacks that never change and has no changing business-needs ever. I.e.: non-existing software.
> always just about 'good enough' to solve the issue at hand
I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.
Me too. But that is typically a problem with how they define "good enough". And how that evolves over time. If "good enough" means "what we decided on 7 years ago" or "It works on my machine" then certainly that term is not covering what it seems to cover.
"Good enough" should, obviously, take future maintainability, security, new hires, evolving standards, moving business-cases and changing markets into consideration: i.e. overall complexity, reusability, consistency, maintainability etc.
Or, to put it differenty: if your "Definition of Done" is not evolving or changing over time you can be sure that the "quality" part in that DoD is sub-par in a few years and your project development will grind to halt somewhere in the next years surely. (edit: that, or it is so vague and up to intepretation that any new hire or insight can change it already. Which may be a good thing, IDK)
There's a bunch of little scripts I've had to write for my workflow. Time is short so I've taken parts and pieces from experiments, treated them as black boxes, and wrote interfaces to make them handle way more than I ever anticipated. It usually looks bad and has little useful documentation for the heavy math inside but it works and will work for years. I try to spend time on making the interface clear and friendly for anyone else that uses it after me but the internals are a nest of wires and obtuse mechanisms that I can barely remember how they work.
We had an excel spreadsheet that was used for at least a decade to process some measurements. There were a lot of magic numbers shoved in the equations to handle some issues with the equipment along with math that I'm surprised Excel can handle. The results would be correct but it was a total black box but the steps to get to them were nearly incomprehensible. A coworker decided to spend some time upgrading it to Matlab to allow for some better interfacing with new test equipment we were buying. She thought it would take a week, it took months. Talking to the original author was useless as he couldn't remember how he built any of it. Finally she got it working with both the old and new test equipment and now has properly documented everything so it explains the use of any magic numbers. I did not envy that job at all.
I was honestly surprised the author's answer was "my friend Torben" and not, "oh, it was me".
Part of the reason I like to write as little code as possible is that anything over a year old has some antipattern that I've come to loathe. I can't hate code that didn't get written in the first place.
In my first corporate job out of college (a NOC at an ISP) I was asked to update the documentation for troubleshooting quality of service issues. I checked our wiki for what was already there and it horrendous. I started to mentally thrash the person and was going to go confront them about it. When I checked the edit history I was greeted by a single edit and my username a week after I started the job.
I learned a great deal of humility and compassion in that moment.
Completely agree. My manager at the time thought it was a brilliant idea to have new people write the wiki when they started, because “they just learned the right way to do it from a senior person!”. This is not something I took with me into my own transition to management.
I experienced this same moment when I was ~24 years old and digging through a codebase I'd written a few years prior after returning to a former employer. Once you've hit rock-bottom there's no place to go but up :P.
I've subsequently noticed that those who are quickest to talk trash about nuanced engineering decisions and minor bugs are often the ones with the most fundamentally-indefensible coding practices (5000-line source files that throw innumerable compiler warnings, using deprecated frameworks, explicit silent failure modes, etc). Latent insecurity is a very real phenomenon.
My approach is to just do what I can to unfuck the code without wasting my life on it and then reflect on what went wrong so I can catch the pattern before it gets committed again. I just managed to stop a co-worker from making a mistake that cost my previous company an entire dev's full time attention for years.
More than once I've googled how to do something new and found the answer on Stackoverflow, written by me. I haven't even written that many answers on Stackoverflow.
It sometimes can be misleading. If I'm refactoring large parts of code (e.g. splitting a large file to smaller ones), then sometimes the original logic written by someone else will be left, but git blame will show me because I was the last to make changes
I had this happen _several times_ at an agency I used to work at. I stumbled across some really bad code in their main product, got irate and asked "who wrote this shit?". Ran git blame and discovered it was me. Ok, but this is still s#*t, I need to fix it. Spent a couple of hours and found no way of improving it, figured "well, it's ugly, but I guess it is what it is" and moved on.
A few months later I came across the same chunk of code... "Who wrote this shit?", and off we go again. I must have gone through this loop 4 or 5 times with the same piece of code.
Yeah a "why didn't I" thought occurred to me while I was writing the comment above. All I can say is that it was a long time ago now (15 years), and the notion of leaving notes in the code for future versions of myself (and others) is a much bigger part of my way of working these days.
Find incomprehensible code. Get email from blame. Search for them on Linkedin. If they are working as a developer in some senior capacity, then the code is probably a learning opportunity for me. If they are working as a scrum master code is probably as bad as it looks.
I dunno; I've known horrible senior devs who wrote solutions that were clearly resume driven development who ended up as tech leads elsewhere when there was a regime change and actual scrutiny began to be applied to them.
And sometimes the horrendous code really is written by someone else. I recently came across some horrendous code [1] that needlessly wrapped syslog(), and separated the format string from the point of use (the format string was a #define).
The thing is---I know the developer (he left our company over a year ago) and is a great guy (former jazz musician), but let's just say he had some questionable coding practices.
Technically, a define is the same as hard-coding the string. Practically, at the point of use a define looks like a variable which might suggest it's ok to use another variable. Now it could take something from untrusted user input and you wouldn't notice.
The only thing I could think of is a centralized location of all the format strings could make things easier to translate to another language. But as I stated in my post, it's an internal tool; we don't offer it to other customers as something to install, all our developers speak English, and there are other ways to mark strings for translation (at least on Linux, which this currently requires).
I once had a complicated codebase and had a extremely friendly and downright great person walking me through that. There was some things that bothered me (of course - entry level and dunning kruger). But I never uttered a word, the dev was so technically competent and overall personable guy, I tried my best not to be a jerk. He might have his reasons because we sometimes get lazy yet the contribution we make goes beyond that day and stays forever in the codebase.
That day I learned that, soft skills is the most important thing when it comes to interacting in a team. Suppress your feelings and think of the other guy. See beyond the code.
I always try to approach all code, even my own code as “lets improve this”.
I tell the junior developers to “Write code like you have to come back in a decade with no context”
When mentoring I also suggest the most important quality is a “think skin and an open mind”.
Your code always sucks. It’s a time -vs- constraint issue as the author mentions. As context changes, code must adapt. That’s why I’m not worried about AI any time soon.
299 comments
[ 0.28 ms ] story [ 309 ms ] threadI feel like a well paid janitor.
Sometimes it may however still be the best solution but your future self was unable to figure out why because your former self was too lazy to properly document the code.
The trick is to give them easily defuseable bad ammunition when they "sneak" around to collect. If you disassemble all their arguments and have emails were they were informed, you can trash them thoroughly.
Unpayed though. Cause even good arguments cant help broke little shops.
And if you don't consult a lawyer to prepare for small claims court, you stand a decent chance to be blindsided by that or something else.
If the initial action costs nothing, you have nothing to lose, but they will almost certainly lose something. If you do nothing it will cost you nothing also, but you have no chance of gaining anything at all.
They don't need to hire a lawyer to determine it, the junior paralegal in the in-house counsel’s office with a checklist will do just fine, since all the information needed to make the determination will be on the papers they are served with.
> If the initial action costs nothing, you have nothing to lose
Not at all true; one of the other standard techniques for getting things out of small claims court is for the defendant to find anything about the interaction in question that they could countersue for that would raise the amount in controversy above the small claims limit (since the requirement for linked counterclaims to be handled in the same case and the small claims limit interact to requiring moving the case when this happens), even if it is something that they wouldn't sue over otherwise.
In the end I think it's actually kind of fun to look back through the code though, and think "surely I should have known about X back then... Why didn't I just do that instead."
And, to my surprise, it was not _that_ bad.
Sure, it was full of naively implemented stuff that could have been implemented way better. But, even a decade and a half after, it was pretty clear to read, and it was decently organized.
And, in some ways, I preferred this code to the one I'm writing professionally. I was honestly prouder of myself as a teen than myself as a professional programmer.
The difference, I think, is that I had a clear idea of what I wanted to achieve for this project to be considered as definitely finished. Since I started working on code (for money) I've always been working on never ending projects. This industry (and me, as a professional) is obsessed in writing code for long term maintenance and evolution instead of effectively finishing products.
So, to get back on topic, I'm not sure you really write better code with time. I mean, yes, you totally do, but it's not as important as learning how to code for others to be able to understand and modify it with constraints you can't even imagine.
And I saw a lot of people writing super nice open source side project and then, when you work with them on some professional level, well, they still write the same shitty code as everyone else.
Like when you learn a natural language's vocabulary, but you still need to figure what conjunctions of words are not intelligible or natural phrases to fluent speakers. Phrases that have ambiguous meanings or otherwise generate confusion.
I think there's a comparable notion of fluency in programming that goes what most people mean they say they're fluent in a programming language.
Do you only feel this motivation when you look back at old projects? Perhaps the improvement could be in organization (code-level or otherwise) such that you do not feel lost or confused looking at your old stuff.
If you are actually improving then there should be some good in there (you got better from two years ago right?). If you can't identify that good, then either you are just chasing fashion (that perfectly good construct from two years ago is now out of fashion so it is "bad"), or you haven't improved your ability to tell good code from bad and just calling it bad because you are unfamiliar with it.
If you want to actually get better at code then you should do a real review of the code you wrote a year ago. Where did bugs occur in the code you wrote? Is there something that you could have done to make it less error prone? Is there code you wrote that is easy to understand? What design choices can you make so that more code ends up in the good code camp? How were the bugs detected? Can I integrate that in to what I do for testing? Then actively practice moving your code in the good direction and away from the bad.
Anything less is chasing fashion and using familiarity as a good and unfamiliarity as bad. "As is" it is a pithy blog post for Coding Horror, but won't get you there. Pursuing greatness requires directed improvement
EDIT: Actually I feel like an aging chess GM -- better than younger at strategy, worse than younger at tactics.
I would go as far as to say that it's a negative signal, because instead of improving code quality you are just changing things that don't really matter.
Then I realized I wrote the comment. I didn't address the <niche> things because I was looking for it then and I'm stilling looking for it.
Let's submit ideas! I'll start
He wanted to learn about using Machine Learning to predict how often his pet dog would need to go to the bathroom
(1) Niche book writing software (2) Dumbphone hacking
I had an issue, last week, where a bug was caused by an omission I left from an SDK that I wrote, maybe, eight years ago. It was a simple thing. I didn't add a "RefCon" to a server interaction, so I couldn't attach a reference context to a callback. This is a classic pattern, that I've used for decades, and I have no idea why the hell I didn't add it to this SDK. I suspect that it might be that the SDK was for a fairly wide audience, and I probably thought that they wouldn't understand it. So here I am, paying the price for underestimating my user base (which, so far, is Yours Truly).
Anyway, the "fix" was to implement a semaphore, and treat the call as blocking, which is awful. I really need to go back and change the SDK, but that's a fairly fundamental change, that I can't afford, right now (the SDK tofu is rock-hard).
Such is the life of a shipping developer...
https://github.com/bmlt-enabled/BMLTiOSLib
Edit: To add more to this, feeds train our brain to consume content which we don't even need. Search on other hand is inherently required when we are working on something cool.
Having said that, cussing is a rite of passage in our house. We all cuss like sailors.
There are existing software and methods to get around this problem of accidental censorship. Someone mentioned maintaining a professional vocabulary, and I am inclined to agree: The more you read people writing with crude language, the more likely you are to accidentally let it slip around your parents, or someone like a small child.
Anyway, on the subject of the actual post, comments are you and your future self's mutual friends.
That said, we're all adults here, mostly liberal leaning, and we all grew up with the internet; a bit of potty mouth won't hurt anyone. I mean you can take the moral high ground and consider anyone using swear words as immature and move on, I guess.
I'd suggest that if you don't want kids to read the word "shit" you keep them off the Internet entirely for life rather than running around trying to impose your morality on everyone else.
I wouldn't consider the word "shit" to be inappropriate for a reader that I felt mature enough to expose to HN content and conversations.
Does it make our whole environment less professional? Does it influence us to be unprofessional in other parts of our craft? Do outside observers view us as less a profession because of it?
I don’t know the answers but I certainly worry about it. Though perhaps I’m just aging out of this audience.
This is a post on someone's personal blog with some reflections on something they saw at work. I'm not sure why we should expect him to write professionally (leaving aside the question of whether swearing is acceptable in professional writing or not).
I also wouldn't necessarily expect HN to only carry professional content - although some of what's shared here might be interesting from a professional viewpoint, it's not a portal for professionals (what even is 'hacker' as a profession? What percentage of the HN community are amateur hackers rather than professional hackers?).
Ultimately, it's a discussion forum on the internet, where self-proclaimed hackers share things they think are cool, and if others think it's cool too, then it gets shown to more and more 'hackers' until not enough new people think it's cool enough, at which point it gets shown to fewer and fewer people.
Whether we spell "shit" or "s**t", you say the same word in your head.
There are objective good code that are timeless, implementations that does not need another look or left few/no space to improve.
Granted, it's a lot harder to do at larger scale.
"I did not."
If I don't then the comments either have the effect of a) scaring future me, or b) getting ignored because I think that I can do better now.
Think a back-end that concatenates XML into a big global string over the span of thousands of lines of code, then passes it to a function that parses it and outputs it again as JSON. Think functions spanning a thousand lines with triple-nested switch/case and if/else blocks Think a front-end where JS is used to concatenate HTML, CSS and more nested JS together into a string Said front-end will save and reload the currently active page on change of any form field, and there's dozens of form fields across dozens of dialog screens.
When I joined I was given free rein to rewrite it in the technologies I thought would suit best. It's been two years, at a stretch I'm about 20% of the way there. It's a project that needs one or two fully staffed development teams, but we have the budget for two people because our management resists faster growth or investments.
If you squint hard enough this is cgi-bin
This is the danger of rewrites (assuming this was not actually greenlit as a 10 year project)!
That implies, code never is perfect. Not even good. But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand.
I think this is context dependent. I generally agree with this statement on relatively low-risk projects. The problem with "good enough" is that it often becomes a rationale for our cognitive biases to take the easier route. I don't want someone doing that on, say, safety-critical code. Maintaining high standards is a way of buffering against those cognitive biases.
Isn't that by definition what good enough means? That on safety critical code "good enough" is a very different level than on a throwaway-script?
It really comes down to understanding why the goalposts have moved. Is it because you have more information to reduce the uncertainty about the risks that standards are meant to be mitigate? If so, great! If not, it's a red flag you may be responding to something else that increases risk, like schedule or cost pressure.
For example, NASA has different standards depending on risk categorization and the predefined threshold of quality gradually gets higher as the use gets riskier. A business application is held to a much lower level of quality than software for a robotic mission which is lower than a human rated development effort.
We are laying out an approach to software development, refactoring, and a model for how to view old code that you some acroas that seems bad.
You seem to be stuck on the term "good enough" and arguing semantics that don't make sense. Yes, sometimes there are standards. that you need to meet. Sometimes just meeting the offical standard is not "good enough", and you need to do more. "Good enough" is inherently contextual, and you seem to agree with this, but seem still be arguing against using that term?
Good enough is usually an excuse for vague and ill-defined practice. If you don't have a well-defined "good enough" you probably don't have a mature process. If you don't have a mature process, you probably shouldn't be writing critical code. Hence my original comment that it's not a good mindset for high-risk applications.
Well defined "good enough" often looks like a standard. Those standards should be risk based so that one person's biases don't result in a different level of risk mitigation than another person's. That risk is what contextualizes what is "good enough". I'm sure if you asked the Boeing managers, they felt their CST-100 software was "good enough", but the relevant safety standards say it wasn't "good enough". Since both sides can use the term, it makes the term somewhat useless. Like you say, there is no singular "good enough" so the question becomes: Good enough...for what? Good enough to meet schedule, or good enough to not risk crashing into the ISS? My main issue is that "good enough" often means "undefined". When people say "good enough", I've found it often means "we don't know what we need, but I'm sure we'll know it when we get there." I think that can be a bad approach to software development when the risks are high because it opens one up to cognitive biases that lead to subjective and poor decision making.
If you're saying "good enough" is precisely defined and based on risk, then I agree. But that is not how I've ever seen the term used in practice. It's almost always a nebulous term which means you've only vaguely defined the risk. Poorly defined, subjective judgement belongs more to art than engineering, especially not safety-critical engineering. "clunky, cobbled together, expermental or just plain stupid" as the OP said, just doesn't cut it on critical applications, even if the developer claims it's "good enough" and doesn't strike me as a professional mindset.
Indeed, blind adherence to standards is bad as standards are not perfect and are designed to fit a general use case. You need your developers/engineers to think about the full context and asses whether their design will hold up under real life conditions and not just those that were prevalent when the standards were created.
Look at the actual wording of the post I originally responded to:
>"But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand."
Can you imagine a discussion about relevant risks and priorities that uses that definition of "good enough"? I can't, especially with safety-critical code.
I'll give another example: The NTSB report of the uber autonomous driving accident gives a good breakdown of events. Through that report you can see the developers programmed a delay (they call it an "action suppression") due to nuisance braking etc. It's hard for me to imagine a code engineer programming a delay on a static delay time-sensitive safety critical system if they understood the risks (even if the mitigation was the human driver, they didn't seem to have a good understanding of human factors engineering). Yet someone along the way thought the software was "good enough" for production. It's speculation on my part, but I doubt you'd find a good FMEA or hazard analysis on that system. This is my big worry as SV mindsets get into safety critical systems: the general "move fast and break things - because it's 'good enough'" doesn't translate well to systems where lives are at stake. That is what I was responding to: the over generalization that clunky code (in the OPs words, not mine) is 'good enough"
That's not a definition, but a description. It was pretty clearly not an description of "safety-critical code".
You've inserted a context of safety-critical vehicle control systems into a comment responding to an anecdote about writing PHP4.
You say things like:
> Poorly defined, subjective judgement belongs more to art than engineering
That only seems true if you are extremely lucky and/or early in your career. It is extremely common for software engineers to face poorly defined, nebulous problems that you simply don't have the information to solve in an objective manner. The frequency with which this happens is why the approach described by the top comment is so effective. It is a process of continual improvememnt where you try to avoid making unnecessary decisions until you have better information to make them with.
What changes with safety critical code is how you gather that information (and what other processes to build to supplement developer judgment). You try to gather that information with as little risk as possible. Experimental clunky and cobbled together code has a place in this process, but not as a part of live, uncontrolled testing. You run it against models as you prototype solutions and then you refactor or rewrite that code to be good enough to test in riskier situations.
The quality of the assessment matters, but there is really no problem with people making an assessment of whether the code was "good enough" for it's context. In fact, I would refuse to work with a developer who refused to make such assessments. Standards and outside analysis are important, even in non-safety critical systems, but they ate no substitute for a developer making careful assements of if code is good enough.
This is part of the point the article and top comment are making. You can assume that the person who "wrote this shit" is an idiot and mock them, but you will learn more instead if you try to understand the context that drove that person to make the decision, how well that decision worked out, what it cost them and what it gained them. This is how you avoid cognitive biases, not by refusing to accept code that is truely "good enough" in some quixotic pursuit of impossible to achieve perfection.
> That is what I was responding to: the over generalization that clunky code (in the OPs words, not mine) is 'good enough"
I think you are tilting at windmills here. There is no such broad generalization. Clunkly code is often not good enough, which is why it needs to be refactored, "the moment that it starts becoming messy" (which is, I'm sorry to tell you, a context dependent subjective judement call.)
But clunky code can be fine or even great. I'll take a defect free clunky code base that solves a stable problem over an elegant rewrite that adheres to the latest coding standards any day.
In my experience they are meant to mitigate risk. Now maybe that risk is not credible on a particular project which means that standard doesn't apply. But in all other cases, not adhering to standards means you are incurring additional risk, by definition.
Now maybe you're just saying, "Yeah, but those are acceptable risks" in which case I don't really think we're saying anything different. My experience working on safety-critical code uses standards that explicitly state what risk is acceptable so there isn't much wiggle room for wishy-washy statements like "good enough". They aren't esoteric, abstract standards of practice (and maybe that's where our personal experience diverges). It becomes relatively clear, with a good testing plan to maps to said standards, whether that risk threshold was met.
It's easier to illustrate with hardware, but the same principles apply. Say there's a standard that states each critical component must have a specified reliability level. You could either install a single component that meets that reliability level or design redundancy so the overall reliability meets the standard requirement. What you can't do is install a lower-reliability component and claim it's "good enough" unless you change the definition of critical. And that's what sometimes happens in practice; people get through a design/build and realize they didn't meet the pre-defined/agreed upon standard and so they perform mental gymnastics to convince themselves and others that the component isn't reaaalllllly critical as originally defined. And that discussion shouldn't be based on subjective judgement. As the sign above my old quality manager's office said "In God we trust, but all others must bring data."
>I'll take a defect free clunky code base that solves a stable problem over an elegant rewrite that adheres to the latest coding standards any day.
This might be part of where our opinions diverge. My experience in hearing "good enough" seems different than yours. It sounds like you're using it as "it solves the problem, so it's good enough". My usual experience is more along the lines of "it doesn't meet the standard, but it's good enough." The issue in the latter case is that I think there's some hubris that one fully understands the problem. If you do, then you should have no problem bringing data to support that claim and we'd have no qualms. But if you can't, one thing standards are good at is helping to make you pause to consider all the aspects of the problem you didn't think of. Part of that hubris is the assumption that it's a stable problem. Standards capture the lessons learned when people realized it's not so stable. So clunky code may good enough to solve your conception of the problem, but that still may not be good enough if your conception of the problem diverges from reality (see: 737MAX MCAS, uber, CST-100, etc. as already brought up).
I've seen people adhere blindy to standards and I've seen people ignore standards without a good reason. Both are failure modes that can increase risks.
I also think you are grossly simplifing what caused the engineering failures you mention. They have a lot more to do with systemic pressure and misplaced priorities than they do with engineers making contextual assements of risk beyond what is stipulated in the standards.
>I also think you are grossly simplifing what caused the engineering failures you mention.
I don't know how you arrived at this conclusion? I am in no way simplifying. I said those types of systems are complex to the point that subjective determination of good enough isn't adequate and how standards help fill those gaps of understanding. I've literally worked on some of those systems and have had listened to people at the highest levels of some of those organizations about the nature of those failures. I've withheld approving plans of one because I witnessed firsthand how the nature of external pressure corrupts what is meant by "good enough". If you know more intimate details on any of those examples, I'm all ears.
>They have a lot more to do with systemic pressure and misplaced priorities than they do with engineers making contextual assements of risk
This is the exact point I've been making but I think the two are interwined. Those competing pressures make fertile ground for rationalization and cognitive bias to influence decisions to change the definition of good enough more in-line with the verbiage of the OP (again, there was no discussion of risk in that post, you shoehorned that into your interpretation. There was only discussion of clunky, stupid code which was blessed as good enough). You seem to imply risk understanding occurs in an objective vacuum and I disagree. That's why I think subjective determination of good enough falls short in some scenarios. I'm not sure if you've been so focused on being right that you've ignored that central point, or if I'm just not communicating it effectively but it's not really worth belaboring further.
Which I did not do. I don't think you are doing it deliberately or I would have ended the conversation long ago.
> You seem to imply risk understanding occurs in an objective vacuum and I disagree.
Not at all, where do I imply that? It is actually the opposite. I am arguing against your position that risk assements should happen in a vacuum and be based purely on standards with no need or room for subjective reasoning.
> again, there was no discussion of risk in that post, you shoehorned that into your interpretation
While the top comment did not explicitly mention "risk", the comment or did reply to you saying:
>> Isn't that by definition what good enough means? That on safety critical code "good enough" is a very different level than on a throwaway-script?
> That's why I think subjective determination of good enough falls short in some scenarios.
I've repeatedly said that subjective risk assessment is usually not enough:
>> Standards and outside analysis are important, even in non-safety critical systems, but they are no substitute for a developer making careful assements of if code is good enough.
>I'm not sure if you've been so focused on being right that you've ignored that central point, or if I'm just not communicating it effectively
I think your communication issues or on the listening side as you keep projecting a strawman onto people rather than actually listening to what people are saying.
But since we both appear to feel that the other one is not listening, that is probably a clue this conversation should end. I do encourage you to take some time carefully re-reading the thread to see if you can figure out why you seem to misinterpret so much of what people say.
I understand your point. What you seem to be missing is that we're talking about two different things. I agree that decisions should be made in the context of the risk of the engineering application. That's trivially apparent to the point where it's almost confusing that you would feel the need to bring up up (ad nauseum). It's also not particularly interesting because just about everybody will agree with that. What I'm talking about is when people fall prey to cognitive biases to the point where they can no longer make accurate risk assessments. That's a much more interesting problem because the engineering world is full of cases where otherwise smart engineers make terrible judgement calls, all the while telling themselves that they understand the risk. I literally brought up cognitive biases in my first post and instead of responding to what I'm actually discussing, you just keep underscoring a trivially simple point.
I think you're reading your own interpretation into what I'm trying to say and then somehow twisting it into being a miscommunication on my part. When I'm saying subjective judgement can lead to bad decisions, I am not saying "we take all the unique and contextual facts into consideration and arrive at a reasonable subjective risk assessment for this scenario". I'm saying people's cognitive biases can lead to them discounting risk without good evidence because it results in a decision they are emotionally attached to. E.g., "I don't want to miss schedule and look bad, so let's rationalize away this risk that really wasn't mitigated." That is not an objective risk-based decision, it's a biased emotional one. They may think it's "good enough" to get the job done, until it's not (as in the cases I specifically brought up).
While I already explained it but it didn't seem to sink in, I'll reiterate one last time:
You seem to say your definition of "good enough" is based on good, risk-based judgement. I already said if that's the case then we don't disagree. But I also said that is not the context that the term "good enough" is generally used in practice. In my experience, it's used to justify a sub-standard effort and I've given you concrete examples of that. That point of digression between what I'm saying and what you're interpreting seemed to fly right by you because you're more concerned with arguing, and there's some irony in you pointing out that someone else isn't listening.
Not at all. I said that "good enough" is a contextual, subjective judgement and is a critical part of software engineering. The idiom "good enough" says nothing about quality of that subjective judgment, despite your insistence that it does.
> I'm saying people's cognitive biases can lead to them discounting risk without good evidence because it results in a decision they are emotionally attached to
Of course cognitive biases (and all sorts of other things) can degrade judgment. That doesn't mean that we should try to get by without it. We seem to be in agreement on this.
> that is not the context that the term "good enough" is generally used in practice.
Here you are simply wrong. "Good enough" means " adequate but not perfect, not "sub-standard". While it is possible you have been operating in a cultural bubble where that term is only used to mean "sub-standard", in this context the meaning of "good enough" that is being used has been clarified repeatedly but you insist that only your experience with the term matters and thus everyone must use your definition. Instead of working to understand what people are saying, you assume that they are using your definition. Perhaps this sort of assumption explains why you somehow missed out on noticing everyone who uses that term in the normal way. Seriously, go look as some definitions and try asking people what they mean when they use the term.
> That point of digression between what I'm saying and what you're interpreting seemed to fly right by you
Another example of you not really listening. I've repeatedly pointed out this exact divergence.
Let me try a different tack to see if we can get off this pedantic merry-go-round. You've agreed that cognitive biases affect decision-making. So let's say as a developer you are working on safety-critical code that is in danger of being over schedule and over budget. Their manager says if the project isn't successful, your company will lose future work to a competitor and that might leave you out of a job. But if it is delivered on time, you're company will get a massive windfall in terms of future contracts and profits, and likely lead you to a big promotion. What do you do to ensure those cognitive biases do not influence you to incorrectly discount risks and ship the software early before the risks are properly addressed?
(Btw, it's a really bad method of communicating to use absolute terms like 'everyone'. For one, it makes it look like you think you're smarter than you are and more importantly, it's easily falsifiable. That type of communication belongs more on r/iamverysmart than HN)
I just would add, that the urge to refactor things whenever possible, definitely introduced bugs for me, because also refactoring has to be done with consideration and some things were weird for a reason, you do not see at first glance.
And refactoring can also hurt you, or another person just used to that code in its old shape. And then missunderstanding things.
I'm an avid TDD developer. Red-green*refactor*. The latter, often overlooked, is IMO by far the most important part of TDD. But the refactor is only possible because of the tests you wrote, asserted, and tested (testing the tests) in the red-green phase.
It gets hairy when a refactor needs to also refactor the tests - often a sign that the tests were lacking in the first place (and the more reason to refactor them). In which case I try to refactor them not in lock-step but decoupled: first refactor the tests without touching the SUT. Then refactor SUT (and then, most likely, another round of this)
There is no fool-proof way. There will be bugs. There will be regressions. But that is a artifact of "change", not of refactoring. I'm also a believer in "never fix something that ain't broken". Which, unfortunately, only works for software that is not ever upgraded, has no dependencies, runs on hard- and software stacks that never change and has no changing business-needs ever. I.e.: non-existing software.
I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.
Me too. But that is typically a problem with how they define "good enough". And how that evolves over time. If "good enough" means "what we decided on 7 years ago" or "It works on my machine" then certainly that term is not covering what it seems to cover.
"Good enough" should, obviously, take future maintainability, security, new hires, evolving standards, moving business-cases and changing markets into consideration: i.e. overall complexity, reusability, consistency, maintainability etc.
Or, to put it differenty: if your "Definition of Done" is not evolving or changing over time you can be sure that the "quality" part in that DoD is sub-par in a few years and your project development will grind to halt somewhere in the next years surely. (edit: that, or it is so vague and up to intepretation that any new hire or insight can change it already. Which may be a good thing, IDK)
We had an excel spreadsheet that was used for at least a decade to process some measurements. There were a lot of magic numbers shoved in the equations to handle some issues with the equipment along with math that I'm surprised Excel can handle. The results would be correct but it was a total black box but the steps to get to them were nearly incomprehensible. A coworker decided to spend some time upgrading it to Matlab to allow for some better interfacing with new test equipment we were buying. She thought it would take a week, it took months. Talking to the original author was useless as he couldn't remember how he built any of it. Finally she got it working with both the old and new test equipment and now has properly documented everything so it explains the use of any magic numbers. I did not envy that job at all.
Part of the reason I like to write as little code as possible is that anything over a year old has some antipattern that I've come to loathe. I can't hate code that didn't get written in the first place.
Or at least, it's a lot harder to do so.
if current you is always considering future you, then previous you will no longer be the bad guy when future you becomes current you.
tl;dr: pay it forward to your future self.
I learned a great deal of humility and compassion in that moment.
So much code to do pretty simple stuff… but it worked…
I've subsequently noticed that those who are quickest to talk trash about nuanced engineering decisions and minor bugs are often the ones with the most fundamentally-indefensible coding practices (5000-line source files that throw innumerable compiler warnings, using deprecated frameworks, explicit silent failure modes, etc). Latent insecurity is a very real phenomenon.
I mean... that could happen... hypothetically... to... someone.
A few months later I came across the same chunk of code... "Who wrote this shit?", and off we go again. I must have gone through this loop 4 or 5 times with the same piece of code.
I say this in jest, mostly...
The thing is---I know the developer (he left our company over a year ago) and is a great guy (former jazz musician), but let's just say he had some questionable coding practices.
[1] http://boston.conman.org/2022/01/04.1
I once had a complicated codebase and had a extremely friendly and downright great person walking me through that. There was some things that bothered me (of course - entry level and dunning kruger). But I never uttered a word, the dev was so technically competent and overall personable guy, I tried my best not to be a jerk. He might have his reasons because we sometimes get lazy yet the contribution we make goes beyond that day and stays forever in the codebase.
That day I learned that, soft skills is the most important thing when it comes to interacting in a team. Suppress your feelings and think of the other guy. See beyond the code.
I tell the junior developers to “Write code like you have to come back in a decade with no context”
When mentoring I also suggest the most important quality is a “think skin and an open mind”.
Your code always sucks. It’s a time -vs- constraint issue as the author mentions. As context changes, code must adapt. That’s why I’m not worried about AI any time soon.
Debugging is like a murder mystery where you're simultaneously the investigator, the victim, and the murderer.
Code as if the next guy is a violent psychopath who knows your address.