13 ms·

Write shitty code

154 points by seekayel 5y ago

rvieira 5y ago
Perhaps I don't subscribe writing "shitty code" on purpose, but there is something to be said about having a code playground where you can explore ideas, API and languages with little care about practices, design or having concrete goals.
Ingaz 5y ago
The valid point is: "Reconnect with the joy of creation" Attempts to do everything absolutely correct are not productive on early stages. So it's OK to write dirty during search for solution. Anyway it's my personal code on this stage. But then comes time to publish code. I respect my colleagues, I can't make them read dirty code.
raxxorrax 5y ago
Anyone that did not write shitty code didn't do a lot of programming. The author picked a great example here. You should feel good when you know what mistakes you did because that means you know better now. This process should be iterated a few times.
flohofwoe 5y ago
That's not "shitty code", just "simple code". Also regarding the last paragraph, IME the more senior you get the more you realize that writing code for hypothetical future requirements doesn't make much sense. I've seen this sort of enthusiastic overengineering much more often with junior peeps fresh out of university (including my younger self). PS: It also seems the author is still early in the learning process, my advice: what you describe are all good programming practices, they're not just useful for the "learning phase", keep them!
kkirsche 5y ago
My interpretation of the actual post is less, write “bad” code, but more don’t let code quality prevent you from trying something. The former presentation of it though I can’t agree with while the latter I do. I feel code quality is important, not because of future state and optimization but a strong architecture will facilitate other engineers learning, which is critical. For example, not all engineers have learned design patterns like the strategy design pattern or observer, etc (see https://refactoring.guru/design-patterns/catalog https://refactoring.guru/design-patterns/catalog for great examples) where a little guidance can save them a lot of pain. With that said, I understand we all bring different skills to the table. Some people love making every linter pass while others could care less and some actively hate it. This is fine, we just need to respect each other enough to try to build on each other’s strengths and support each other where we’re weaker. TLDR: Rather than saying it’s fine to write “bad” code, say don’t let code quality intimidate you, and be willing to try. You can always refactor later and you’ll learn as you go.
- xLaszlo 5y ago
  If in 2022 you still don't know about design patterns (not using them, just knowing about them) I feel sorry for you.
  - kkirsche 5y ago
    I don’t disagree, but I encounter a fair number of individuals, especially self-taught developers, without exposure to them. While it’s fine to feel sorry that they weren’t exposed to it, I wouldn’t personally say I feel sorry as I find it hinders people’s willingness to ask for help. Invite questions don’t make people feel bad for not knowing something you or I may think is obvious. We all were beginners at some point.
  - dagw 5y ago
    Are people still talking about design patterns in 2022? When I learned to code 'properly' 20ish years ago design patterns where all the rage and we studied them at university and dozens of books where published on the topic. Now I don't think I've heard anybody even use the phrase "design pattern" in connection to programming for several years.
    - bennyelv 5y ago
      But is that because everybody knows them well enough to just be inherent in the way that they break problems down and build systems to solve them or because they've actually been abandoned as a concept? I.e. we don't need to talk about it because we all just do it vs not talking about it and not doing it.
xLaszlo 5y ago
This is one of those posts that exclusively caters for reassuring the audience regardless of whether they are doing right or not just to make them feel better. Refactoring is part of a cycle and you do it before you publish your code to others. If you don't clean it up, you are wasting someone's time.
korostelevm 5y ago
For me some top qualities of good code is - Readable Maintainable Fault tolerant If it works, there are no plans to extend it and there is no one to read it - then it doesn't matter what it is. I know its good code without having to look
laserlight 5y ago
> I know how to write good code. > Usually it means spending more time now to make the code better for some future state of the world. No. That is called premature optimization/abstraction/development and should be avoided. Shitty code is shitty today. Poorly chosen names, copy-pasted pieces, implementation doesn't reveal intent, mismatch in code and comments, etc. Doing these right should be habitual and shouldn't be a function of cycle time. Otherwise, they tend to creep easily.
- laci37 5y ago
  Naming things is hard, copy-pasting is fast compared to extracting shared logic if you need small changes. Implementation will not reveal your intent, if you are not sure what you intend to do. I'm working in ML research so I kind of write shitty code for a living. All these problems are small things, that are okay if you just try something new. If it sticks, you'll build on your previous code so the junk just piles up. The challenge is spotting the time when the shit just starts o bog you down.
  - xandkar 5y ago
    That is all fine if you're the only one that needs to understand that code. Otherwise you're wasting other people's time and sanity. Unless, of course, it all works for everyone, in which case carry on. At least until a new-enough team member arrives and starts pulling their hair out :)
    - jean_valje4n 5y ago
      Data Science is all about writing shitty code. Most of the time you're just digging for data in a notebook, and then you can write things out proper once you've got something that could work.
      - laserlight 5y ago
        I guess we can distinguish between programming and prototyping. Prototyping is more forgiving because it has narrower scope and spans shorter time. Even then, bad habits tend to carry on to the programming part. So better be deliberate about it.
yakshaving_jgt 5y ago
I have some shitty code that runs an important part of one of my SaaS businesses. I'd love to refactor it. I'd love to swap out the HTTP library that it uses with the better one that the rest of the project uses. I'd love to remove all the nesting and complexity. I'd love to make it not an eyesore. But here's the problem: - In the past five years, it has never failed. - In the past five years, it has not needed to adapt. - If I change it successfully, it will make exactly zero difference to my paying customers. - If I change it unsuccessfully, it will break a core part of the system that people are paying for. If I were to refactor it at this point, it's really only to pander to my own ego, which probably isn't a sensible business goal.
- ejb999 5y ago
  I'd take 'shitty code' than runs flawlessly for years on end, over non-shitty code that doesn't. I've worked with too many 'architecture astronauts' over the years who over-design everything based on the latest-and-greatest thing they just read online someplace, and make it so complex no one understands how it works, or how to maintain it, and often doesn't do what it was intended.
  - okl 5y ago
    I worked with both, 'architecture astronauts' (lol!) and shit-coders. I'd prefer there to be a balance. Code has quality can be measured in more than just one dimension. It's fine if code works, but it's even better if you know how. (No obvious errors vs. obviously no errors)
    - bussierem 5y ago
      In case you haven't heard of it before, that term comes from this blog post, quite a good read! https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
    - marcosdumay 5y ago
      > Code has quality can be measured in more than just one dimension. Well, if you don't need to change it (like the GP), most dimensions are moot. We used to call that "maturity", but the entire concept is out of fashion nowadays. What leads to a correct architecture being probably the most relevant one by a long shot. Because a good architecture is a hard requirement for parts of your code to stop changing (the other being requirements maturity, that is not a dimension of code quality). But yes, before reaching maturity, there are many dimensions of quality you may want to optimize for, and they conflict between themselves. Also, architecture astronauts get this name because they don't create good architectures, so you don't want them designing it anyway.
deleted 5y ago
[deleted]
egeozcan 5y ago
Better: Learn to write non-over-engineered code that is obviously written by a professional without thinking. Even better: Learn to write boring code, fast. There will be exceptions, but those are rare and better resist the urge for abstraction until the very last moment!
- ejb999 5y ago
  >>Even better: Learn to write boring code, fast. Under-rated comment of the day.
- akprasad 5y ago
  Two quotes from my favorite go (board game) player that seem appropriate: For writing without thinking: > You have to soak up the fundamentals as you practice on your own, studying them until they become a part of your very being. If the fundamentals do not operate subconciously when you sit down to play, you have not mastered them yet. For fast boring code: > Go is the kind of game in which you are an expert if you can just keep on making ordinary moves. You need not play any especially brilliant moves at all. Amateurs' moves, however, are frequently far from ordinary; in fact, I see them making the most nonsensical moves imaginable[.] More here: https://arunkprasad.com/log/kageyama-7-dan-on-amateurs-and-professionals/ https://arunkprasad.com/log/kageyama-7-dan-on-amateurs-and-p...
deleted 5y ago
[deleted]
eternityforest 5y ago
Coding is an important skill to develop. But I'd rather develop my ability to NOT write code. To choose libraries I won't have to mess with. To DRY up the architecture so I'm not implementing the same thing 5 times in a higher layer that would be trivial in the lower layer. To not encourage sprawling piles of code by making sure there's one obvious way to to the things that need doing. Shitty code will just teach me to code. But I already know how to code. I've been coding for a while now. I don't need to be any better at writing average crappy code. I need to be better at writing bulletproof code that is as close to bug free as it can get, and architecting to prevent the need for shitty code. Should musicians be lazy in their practice? Everyone outside of tech says you will play how you practice. So if they encourage shitty code... you wonder if they really are all that committed to making bug free apps, or if they are dragging the old WorseIsBetter anchor.
indymike 5y ago
Great code takes a while. I've learned to take this approach: Works -> Like -> Love First I write code that works, pretty much by whatever means I can. Sometimes it's great, but most often, shitty is the right word for it. But it works (sometimes, well, sometimes... um...). Then I try to refactor to something that is likable. It's often not perfect at this point because maybe it's not as performant, there are side effects or the api isn't as well designed as it should be. The final step is to really go for something that is lovable, which usually means will not have to be re-written for a while, and often becomes quite re-usable. The nice thing about this approach is that I'm able to get things working quickly (and make customers happy) and it differs optimization until enough is actually understood to optimize.
- bennyp101 5y ago
  I've always thought of it as a kind of image rendering! First pass gets me something that works, then every subsequent pass makes it a little better, like, outlines first, then some colours, then some shading, then some fine details etc
sktrdie 5y ago
Meh, not convinced. Sure you can craft a shitty built bike with cheap parts so to learn more quickly about how the bike fails, and sure you can probably make some money selling these shitty bikes. But I’m in it for the craft. I want to build and sell super high quality bicycles that ride and look beautiful and will ride for a lifetime. And for that, every little detail of the bike has to be crafted in a high quality manner.
- maccard 5y ago
  In your analogy, what about the parts of the work that aren't building the bike, like the printer you use for shipping labels. Sure you could buy a $1500 xerox, but you could also buy a $99 laserjet. Across the N items you buy, a handful will fail or need replacement. they're the things you buy quality versions of.
andy_ppp 5y ago
There is a huge difference between planning for the future (which you should not do, agreed, unless that future is < 3-4 tasks time, say) and writing shitty code. I class shitty code as not what he's said but things like works by accident, no tests, naming is misleading, 3000 line files, spaghetti code etc. etc. Doing these things does not make you faster or produce more software. My opinion is "do the thing that another developer can understand quickly" is the minimum requirement. Even if the code doesn't work (or has a bug!) at least it has some chance that it can be fixed. I think the author is conflating two issues, 1) planning for the unknown is impossible and time consuming (true!) and 2) all software engineering practices also make coding slow (false!).
nesarkvechnep 5y ago
I believe most shitty code is not a result of unfamiliar tech stack, tools or environment but not enough time spent on thinking about the problem at hand and how the solution can be open to modification. In that vein, the author encourages shitty code.
zqna 5y ago
Shitty code writers typically justify that it's some(thing/body) else that doesn't allow them to write OK code. They trade the imaginary speed gains (my estimate it's 10-20% of effort difference between shitty and OK work) for problems that start manifesting immediately or are ticking bug/maintenance bombs. The problem is that a lot of engineers try to go the shortest way possible, instead of investing extra effort to think little about the future. They see it either black or white, either shitty or perfect - there is no middle ground. I just noticed that every type of copy/pasting is now ok if your application is using "microservices" architecture. Nobody knows why "microservices" were chosen (as there is no demand for it, nor the implementation of that "architecture" allows them to easily scale), but hell, now we don't need to isolate the common stuff into a single place. And then, when they see some crap, then they keep adding more crap for a sake of consistency.
skrebbel 5y ago
I love the code in the screenshot on top of the article.
ineedasername 5y ago
I think there's a balance to be had. I used to write shitty(er) code, and often when I have to revisit it to mod for a slightly different purposes my thought is something like "that lazy ass, I'm going to have to nearly start from scratch to make it work for what I need now" So now, unless time crunch is so bad I have no option (and even then I push back against it to try & get more time to do it right) those are the time I'll cut corners on robustness, readability, etc. I also put a comment in at the top with a deep apology to the angry version of my future self with a reminder if the circumstances at the time. It helps me not pound the keyboard so much in frustration.
pdinny 5y ago
This present a false dichotomy of extremes: shitty code and hopelessly overly complicated intended to address all manner of eventualities that never materialize. Both extremes are awful choices IMO. If the code you are writing is truly unlikely to be extended and adapted then it may be fair to relax your requirements for code quality. As for most things I'd say that applying some discretion to your actual context is more valuable than blanket approaches of embracing bad code. Code can be good without taking forever and without being over-designed. On the other hand the accumulated effects of shitty code upon more shitty code is unlikely to be a net positive. Well-designed code can be simple.
aahortwwy 5y ago
Nope. The startup I work at has been compartmentalizing and chipping away at our shitty code for the past eighteen months. We're not doing this because it offends our aesthetic sensibilities. The shitty part of our codebase is truly shitty. It fails to do its job regularly, causing significant toil in various parts of the business. Junior engineers can't make simple changes to it without causing serious regressions in seemingly unrelated parts of the system. It's slow as fuck. New engineers have to spend weeks reading the codebase if they hope to understand it, and some just give up. There's a big, measurable, drop in velocity whenever we have to work with the shitty codebase. So now we're effectively forced to do an incremental rewrite in order to build new features, which is terrible because rewrites suck and bring their own drop in velocity with them. In practice, writing shitty code is not all that much faster than writing good code if you know how to write good code quickly - but I guess some people don't bother to learn. I read somewhere once that at a growing company the next person who works on the code you wrote is highly likely to be new to the company and have less industry experience than you. When you write code, you should write so that that person can work on it productively.
- scottious 5y ago
  I feel like the author is really saying "don't over-engineer". At no point does he say create code that does not work. The closest he says is that ALL systems will fail and that he'd rather fail with throw away code than some overly abstracted, lovingly hand crafted pile of code. The point the author is trying to make is that trying to build a perfectly designed cathedral of code can often be counter productive.
- ryandvm 5y ago
  I believe you, but would the startup even exist if they had spent 2 or 3 times as long developing the MVP? The reality is that good engineering has higher upfront costs than quick-and-dirty. Sure, it's usually cheaper in the long run, but initially it either takes longer to plan or it takes more expensive engineers to execute. And for a lot of startups, getting that cheap MVP out the door is the only path to additional investment. I'm all in favor of quality engineering, but I'm also pragmatic enough to realize that sometimes you have to sling a little shit in order to gain the luxury of doing it the right way.
flavius29663 5y ago
This is a false dichotomy that I see in a lot of developers(including myself a while ago): fast+ugly vs slow+futureproof. In a big codebase futureproof is more important, but let's put that aside and talk about quick and dirty standalone programs. Even when talking about the needs of now, ugly code can slow you down significantly. Ugly code takes you longer to debug, longer to see errors, longer to modify, longer to built upon even in the next hour. So for me it's a matter of writing code that is at least good enough for me NOW, and then I start thinking about futureproof and other maintainers as I get closer to a commit and during pull requests.
pron 5y ago
I think developers, especially those with, say, under 15 years of experience, place far too much emphasis on code. No doubt, very shitty code can have a big adverse effect on long-term maintainability, but correctness is much more influenced by algorithm design, which is often better and more quickly explored in something like TLA+ or Alloy than in code. A bad algorithm design costs much more than ugly code. Focusing on code aesthetics also takes time away from other, more important, activities, such as profiling.
d--b 5y ago
Ok. there's shitty, and there's _shitty_. I hope that screenshot is a joke, cause holy crap! That doesn't look good. I seriously wish the author is not defending that kind of shittiness. I am all good with the if(process.env.env !== 'notProd') part, but indentation, come on? I think this can't be a real piece of code anyways, cause the author would have done console.log('here1'), console.log('here2'), and console.log('here3').
medwards666 5y ago
Most of the previous comments seem to be firmly in the 'nope' camp when it comes to code quality. What most of the appear to be missing though is that they're looking at their production codebases, and in that instance, I would wholeheartedly agree - Production code (or code destined for Production) should be of high quality, developed to standards and over-engineered where applicable. Where I think the OP is referring to writing shitty code is when coding either purely for the fun of it ... to learn a new technique, or a new language for instance, or when prototyping something - sending out the feelers to see if something you can hack together in a short space of time could be developed into a viable solution (at which point, you'd then start to either refactor it into decent, production ready code, or toss it aside and begin again). Shitty code definitely does have its place, but anywhere near a production codebase isn't it.
kretaceous 5y ago
Slightly tangent but one thing that these code practices languages often miss is using the language to its fullest. Most beginner developers who are not very used to the language reinvent the wheel for a lot of in-built functions. For example, I've seen stuff like: ` const arr = []; for (let i = 0; i < anotherArray.length; i++){ arr.push(someOperationOnEachElement(anotherArray[i])) } ` instead of `const arr = anotherArray.map(someOperationOnEachElement)` Not knowing what your tool/PL can do can lead to hard-to-maintain code. One should really leverage the expressiveness and syntactic sugar wherever relevant.
- deleted 5y ago
  [deleted]
- kretaceous 5y ago
  EDIT: code practices languages -> clean code practices articles* can do can lead -> can lead (There's no edit option for me, so replying:)
_benj 5y ago
I think intentionally writing shitty code is not a good advice, but it does help with taking us out of the rut of perfectionism and over-engineering stuff! For me I try to follow two principles: First, write boring code, and I mean boring, long variable names, no syntax sugar, no clever combination of boolean chains... code that I would use to teach a beginner in the language (or more aptly, future me) how to start coding! The second is plan to write things twice. This one is a double-edged sword inasmuch as it can help to further clarify or make even more boring the code, or be the place to start adding "optimization" and "cleverness" in the code... I try to stick to the former. Some of the most valuable code I've written I would call either "hacks" or "scripts", not code, but nonetheless, it solved a real problem instead of being beautiful/elegant or whatever
jvanderbot 5y ago
That code snippet is like one of those Lovecraftian paintings where it looks normal, but the more you look at it, the more weird and horrifying it gets. Bravo.
usr1106 5y ago
Not convinced. Unmaintainable code is the big problem. He is right that the future is unforseeable. That's why code needs to he maintained. A weird non-local bug is detected. The developer who wrote it found greener meadows. Sales has sold a feature we don't have yet. We notice that we do business with some different functionality that we originally envisioned. There will always be reasons why code needs to be maintained, whether it has worked for 3 days or 3 years. Now if the code is unmaintainable and every change takes 5 times as long as soon it should and introduces 3 new bugs we are in trouble. Shitty code is almost always unmaintainable. (Unless the shittyness is local inside small functions, but I doubt that's acommon case.) Of course over-engineering and needless optimizations also lead to unmaintainable code. If the company policy were "Write shitty code" I would run away. I am sure it would lead to absolutely horrible results. At my work we stress the value of good code. Still we end up with shitty code regularly. We just didn't know better when we did it. And we do not rewrite everything once we believe to know better. It's hard enough to struggle with that level of shittyness, I don't want to have it increased fully intentionally. I do that for scripts I will never use again, but not for anything I merge to the code base.
- Jtsummers 5y ago
  > Shitty code is almost always unmaintainable. (Unless the shittyness is local inside small functions, but I doubt that's acommon case.) Of course over-engineering and needless optimizations also lead to unmaintainable code. I was going to write something similar, so piggybacking. The shittiest code I've seen has always suffered from this. Sometimes it was shitty (in this sense) because of an assumption that it was "throwaway" code, but it was never thrown away. Gross copy/paste throughout, highly redundant code (same variable, or variable with the same intent, created in many local blocks), mostly existing in mega functions (thousands of lines long) with complex conditional logic to navigate to specific desired sections from the entry point at the top. If it was really throwaway code, then this can be tolerated. But it doesn't require much thinking into the future to replace a 10-line block that's repeated 50 times with one change at each location into a single function. If, in the future, some of those 50 uses of the function need a different function, change it then. Better that than having to keep 50 locations in sync with each other because "making a function now is premature optimization" or "YAGNI!!!". Well, programmer time and delivering quickly has value too. When what would have been a 5-minute task (read function, change function, rebuild, rerun) becomes a 5-hour, 5-day, or 5-week task then everyone is losing out because of the shittyness that was trivially observable and correctable early on. The other big example of shitty code that is unmaintainable (or becomes unmaintainable) is tight integration between IO and business logic. Without a clean separation, you typically end up with similar repetition to what I described above, or something where a "small" change ends up having massive knock-on effects. This brings maintenance to a crawl as you have to tease out the consequences of that small change, which is non-trivial. That's what makes the code shitty. Corrections and clean separation are often forestalled for the same reason that the previous example often ends up with a mega function instead of a nice, often small, set of utility functions: YAGNI. If your project is going to last more than a few months and has even a modest level of complexity, you will need that clean separation. Otherwise, you end up with increasingly complex (but unnecessarily) code that works around the initial self-inflected hamstringing, or you waste weeks or months cleaning it up and delivering nothing to customers, who become impatient so the cleanup gets cut short and you now have a hybrid mess: half-good code (that will decay rapidly) and half-shitty code (that still can't be maintained).
altgans 5y ago
I recently made a similar observation: Write shitty! Background: I am writing a novel. In the beginning I sat down and obsessed with every little detail, spending multiple days figuring out the perfect formulation and text flow. And then I would maybe change a little thing in the story-line and have to start over again. This really sucked the whole fun out of the writing process. Then I changed my approach: I just write whatever comes to my mind, independent of whatever I just wrote before. Doesn't matter if the previous scene had character A as sidekick, if I like character B more, then I simply switch them. Some scene is way over the top and doesn't make sense? Doesn't matter, I write it. Writing is fun again. I sit down, get into deep-work-mode and just write. No constraints, no thinking. Granted, this is only draft #0 and I will probably have a rude awakening when I have to merge all my writings for the next iteration of drafs drafts, but so far I am rolling!
drcongo 5y ago
Ironically, for an article titled "Write Shitty Code", the entire article is blank for me because they wrote shitty CSS. https://imgur.com/a/41eXasz https://imgur.com/a/41eXasz
beardyw 5y ago
“If a thing is worth doing, it's worth doing badly.” G. K. Chesterton
allenu 5y ago
I agree with the author. Learning to write good code, and well designed systems, requires writing lots of code. The best way to do that is just pump it out. It’s harder to write a lot of code if you try to make it perfect and cover a lot of future scenarios. The more code you write, the more you start to see larger patterns that hinder or improve your system design. You don’t see those things as easily if you are writing bits and pieces slowly. As an aside, writing code in a professional setting can be limiting as well since you may not be able to write code quickly (or shitty) enough to get to a place where you see the effects of your decisions. You’ll write less code and end up focusing on making safe decisions, which means less experimentation in techniques.
Clubber 5y ago
DRY, KISS, YAGNI
Prometheus_Lodi 5y ago
The software priests who taught the MSCS courses I took did not teach these insights. No harm comes from studying the beautiful code of the ancients. But, indeed, less work gets done when you complicate your task with goals of beauty and future-proofing.
hypfer 5y ago
Shitty code such as a website that shows 0 text with third party js being disabled?
Prometheus_Lodi 5y ago
beardedetim 5y ago
This is expressing something I've been trying to express for _years_. I've come to call it "throw away code" instead of "shitty code" because of what's happening in the comments: people always came back to me and said "Shitty code doesn't work!" and we get into an argument about what I mean by shitty code. I find that throw-away code gets my point across much more cleanly without people's objections being raised immediately. Most engineers understand that when I say "throw-away code" it doesn't mean the code doesn't work. It just means that I can _throw it away_ when I need to later. It is "shitty code" because it's _supposed_ to be replaced.
- zachwill 5y ago
  I do this too — and feel like “throw-away code” is a great moniker for it!
- AnIdiotOnTheNet 5y ago
  I believe it was Casey Muratori said "first: write the stupidest thing that will work". Meaning, it's code that is obvious and simple and does what you think you want to do. It doesn't have to be efficient, or flexible, it just has to do the job. Later you can change and/or improve it if need be.
  - ramesh31 5y ago
    > It doesn't have to be efficient, or flexible, it just has to do the job. Later you can change and/or improve it if need be. I think the reality, though, is that that day never comes. Usually if something works, it will never be replaced. So the real trick is writing something that finds a perfect balance between "just works" and "elegant/aesthetic/maintainable/readable".
kretaceous 5y ago
Slightly tangent but one thing that these code practices articles often miss is using the language to its fullest. Most beginner developers who are not very used to the language reinvent the wheel for a lot of in-built functions. For example, I've seen stuff like: ` const arr = []; for (let i = 0; i < anotherArray.length; i++){ arr.push(someOperationOnEachElement(anotherArray[i])) } ` instead of ` const arr = anotherArray.map(someOperationOnEachElement) ` Not knowing what your tool/language can lead to hard-to-maintain code. One should always try to leverage the expressiveness and syntactic sugar wherever relevant.
0xbadcafebee 5y ago
Well that's one way to get me not to use your SaaS
scottious 5y ago
> A lot of senior experienced people will talk about all the “shoulds” your code should be like. They are usually describing some far distance promised land that they have never visited either. Oh how I can relate do this. I've seen so much guilt and inaction from developers who are paralyzed by "should". They so badly don't want to be a "bad engineer" that they'll over-engineer just about everything and end up causing a lot of problems.
luckyorlame 5y ago
Why not just post an article on how to generate flame bait?
allo37 5y ago
My usual approach is a bit like how I wrote essays on loose-leaf paper back in school: Start with a rough draft, and then once all your edits are done, produce a "clean" copy. I think a lot of code that is described as shitty comes from doing the first step, but due to time constraints the second step is skipped.
lacrosse_tannin 5y ago
Can do!
whoomp12342 5y ago
I get it, but as a senior member of the team you have to be careful. Yes it is fun to get shit done really fast, yes it creates short term value but you have to be aware of the downstream effects. When you build new stuff, set patterns, create infra, you are setting the example that junior members will learn from at best, and copy/paste at worst. Do you want a ball of mud because its all too easy to get one
- wreath 5y ago
  I think what you're talking about is not only shitty code but also poor design which is far more dangerous. Writing shitty code behind good design is a different story, and to my understanding, this is what the author describes.
jarek83 5y ago
If you work on your own, that's probably not a disaster to write shitty code. BUt in a team it's a big no for me. And it's not really about the future extension of code, although modular approach generally helps here too. The biggest benefit of non-shitty code is that others can get through it quicker. In 99% of cases code is written to be read by others in the first place (including yourself after some time), then goes the bug-less priority and then anything else. 1% is where you really need something to be performant - the ease of reading is then not important at all as such code has to be messy.
deleted 5y ago
[deleted]
Kiro 5y ago
I love when a project transitions from clean to shitty code (which eventually happens as quick fixes and shortcuts pile up). At that point I can start iterating much faster since I no longer care about making everything as clean and smart as possible. The battle is already lost so I can just embrace it.
ramesh31 5y ago
I've learned to embrace the jank. Architecture matters, but implementation rarely does. You can sit around all day dreaming up a perfect parsing library with full test coverage and a pure functional API to do some string manipulation, or you can smash out a 20 line function that works for your case and move on with your life to things that matter.
sebastianconcpt 5y ago
So instead of prototype often, go production early and iterate frequently is now spelled: Write shitty code? Oh boy... If masters and geniuses of the past would read the "common-sensical" advice we hear today and how it is being expressed, they would not be surprised by the general shitty state of the world (all civilisations around the world) but to find it plain miraculous that we're still in a semi-funcional way or alive at all. If you know how to write good code, write good code for the state of the world right now then. Care about the future in the future. Kent Beck taught us this already in a very detailed way two decades ago. Invented Unit Tests in Smalltalk to have fast feedback on regressions frequently and granularly. All languages have that today. Then why in the world do, instead, these software engineer self-serving rationalizations that will accumulate tech debt you're carefully not talking about? How in the world an unexperienced developer would receive this advice as a propaganda in any way other than a push of self-indulgence for incompetence? How this advice makes you an A player?
- cryptica 5y ago
  I was thinking the exact same thing but I've read so many of these utter nonsense articles recently that I rarely even bother to comment on them anymore. Who knows. Maybe they're written by a bot with a job-creation agenda. It's just cringe. I think your intuition is right, the world economy seems to have been hollowed out. Look at medicine, the media, big tech... They all suck. It seems as though they've been promoting idiots intentionally and now idiots are calling the shots.
iamwil 5y ago
The problem is, future programmers only get to look at the artifact--your shitty code--rather than all the learnings you got, since I bet you never wrote it down. Oh right, I'd have to ask you about it. And chances are, you're not even working here anymore. https://news.ycombinator.com/item?id=29919428 https://news.ycombinator.com/item?id=29919428 That said, there are definitely people that swing too far the other way. Some people create abstractions where there doesn't need to be. And they're usually not well thought out ones either. I wish there was a way for code work like pen/pencil and paper, where if you're doing exploratory work, you can sketch. And it'll look like a sketch for other people reading your code, however that can be indicated. But once you learned enough of the domain, you can firm things up, like you do with a pen to add safety and other constraints.
polycaster 5y ago
My impression is a lot of the best practices spread today are suited best for FAANGs or at least high tier SaaS businesses (which often contribute to the frameworks used). One thing I hear repeated over and over is: Code is going to change frequently. Well that's not universally true. I don't even think that's true for the vast majority of code in production globally. If you build an app with one specific, well-defined purpose that iself is not going to change a lot (eq. supporting the workflow of a specific business, managing inventory, etc.) that might easily run for a decade with <10% LOCs ever being touched. I've build dozens of those in my career and I'm certain I'm not the only one. If you're on the quest for the most beautiful code in this scenario you're wasting your client's time and money for your own vanity.
larryfreeman 5y ago
Totally agree with everything in the article. Unclear how this is different from prototyping code before you start on the industrial-strength version. https://en.wikipedia.org/wiki/Software_prototyping https://en.wikipedia.org/wiki/Software_prototyping
jackjeff 5y ago
There’s a time and space for shitty code. Something you write once, as quickly as possible and throw away. Anything else, that ships to any kind of production environment, needs to be reliable and maintainable. Shitty code is a false economy. Time savings often fail to materialize if not out right end up costing more in maintenance. Good code is not something extravagant nor expensive. It’s something simple that just works and looks obvious to anyone who looks at it. Good code is not over designed code. The difference between shitty code and good code is often the difference between a prototype and something production ready. Take the prototype code you wrote, careful think of all the edge cases, maybe test them, rename anything confusing, comment non obvious things if any, and refactor, throw away as much as you can until every line matters. Good code does not trouble your sleep because you know you did everything you could to ensure it is reliable and even if there is a bug, there’ll be enough info logged and the code is so clear, that fixing the issue will be obvious. If you’re in the habit of writing good code, you will become better at it with practice and be extremely efficient. If you’re in the habit of writing shitty code, you’ll have to write more shitty code to work around shitty bugs and spend endless time chasing mysterious problems in production.
Koshkin 5y ago
> shitty code Still, I have never understood why anyone would want to write if (success == true) instead of if (success)
- yakshaving_jgt 5y ago
  Maybe both of those examples aren't great? Maybe you want something like this? case result of Error e -> -- some error handling code Ok a -> -- the happy path
tau5210 5y ago
> A lot of senior experienced people will talk about all the “shoulds” your code should be like. And the article itself is another "should".
unobatbayar 5y ago
Valid arguments but this is a terrible advice. Good or bad code is a learned ascept of an engineer, or experience rather. If you care enough then eventually you will write great code unconsciously with high velocity. Someone's shitty code might be fucking beautiful if they practiced for many years. My advice is, work in a place with good code review, code quality culture because it really does make the difference. We're unconsciously shaped by our peers.
macinjosh 5y ago
I think this is OK in some situations and not OK in others. To me it is a lot like writing in a human language. When I am texting someone I am close with there is no reason to avoid slang or to use the best grammar and punctuation. When I am writing my CV it would be advisable to be more formal. The author of a dime-store novel will write at a different standard than the Encyclopedia Britannica. My point is that you should write the code that is necessary for the situation and if you are part of an engineering organization the leadership or team as a whole should decide when to use what level of quality and should understand what the trade offs are. There are legit business reasons to write throwaway code when time is of the essence and there are times when you need to take the time to risk over-engineering/over-building something just to be as certain as possible that it won't fail.
elmolino89 5y ago
The shitty code/do it supposedly once is quite widespread in academia, and from what I have heard also in at least some biotech companies. The problem: irreproducible results. Once you chain dozens of command lines, unversioned shitty scripts, no md5 checksum-ed inputs/intermediate results etc. you are in a smelly swamp full of monsters. Even you one week later will not be able to do it again. Markdown docs/jupyter notebooks are minimum even if one does quick and dirty proof of concept thingy IMHO.
tpoacher 5y ago
This article makes some very good points, all of which are ultimately false. To make a medical analogy, I don't know that I would trust a surgeon with a billion operations record and a 50% complication rate more than one with a 1000 operation record and 1% complication rate. And I certainly would hate to be the colleague inheriting their patient.
Zoadian 5y ago
the best way to write code is: write code that you can delete without any effects on the rest of the program. and keep all related code as close as possible together in the source code. Also keep mutations as far up the call stack as possible. use pure functions whereever possible.

154 points by seekayel 5y ago

Perhaps I don't subscribe writing "shitty code" on purpose, but there is something to be said about having a code playground where you can explore ideas, API and languages with little care about practices, design or having concrete goals.

Ingaz 5y ago

The valid point is: "Reconnect with the joy of creation" Attempts to do everything absolutely correct are not productive on early stages. So it's OK to write dirty during search for solution. Anyway it's my personal code on this stage. But then comes time to publish code. I respect my colleagues, I can't make them read dirty code.

raxxorrax 5y ago

Anyone that did not write shitty code didn't do a lot of programming. The author picked a great example here. You should feel good when you know what mistakes you did because that means you know better now. This process should be iterated a few times.

flohofwoe 5y ago

That's not "shitty code", just "simple code". Also regarding the last paragraph, IME the more senior you get the more you realize that writing code for hypothetical future requirements doesn't make much sense. I've seen this sort of enthusiastic overengineering much more often with junior peeps fresh out of university (including my younger self). PS: It also seems the author is still early in the learning process, my advice: what you describe are all good programming practices, they're not just useful for the "learning phase", keep them!

kkirsche 5y ago

My interpretation of the actual post is less, write “bad” code, but more don’t let code quality prevent you from trying something. The former presentation of it though I can’t agree with while the latter I do. I feel code quality is important, not because of future state and optimization but a strong architecture will facilitate other engineers learning, which is critical. For example, not all engineers have learned design patterns like the strategy design pattern or observer, etc (see https://refactoring.guru/design-patterns/catalog https://refactoring.guru/design-patterns/catalog for great examples) where a little guidance can save them a lot of pain. With that said, I understand we all bring different skills to the table. Some people love making every linter pass while others could care less and some actively hate it. This is fine, we just need to respect each other enough to try to build on each other’s strengths and support each other where we’re weaker. TLDR: Rather than saying it’s fine to write “bad” code, say don’t let code quality intimidate you, and be willing to try. You can always refactor later and you’ll learn as you go.

xLaszlo 5y ago
If in 2022 you still don't know about design patterns (not using them, just knowing about them) I feel sorry for you.
- kkirsche 5y ago
  I don’t disagree, but I encounter a fair number of individuals, especially self-taught developers, without exposure to them. While it’s fine to feel sorry that they weren’t exposed to it, I wouldn’t personally say I feel sorry as I find it hinders people’s willingness to ask for help. Invite questions don’t make people feel bad for not knowing something you or I may think is obvious. We all were beginners at some point.
- dagw 5y ago
  Are people still talking about design patterns in 2022? When I learned to code 'properly' 20ish years ago design patterns where all the rage and we studied them at university and dozens of books where published on the topic. Now I don't think I've heard anybody even use the phrase "design pattern" in connection to programming for several years.
  - bennyelv 5y ago
    But is that because everybody knows them well enough to just be inherent in the way that they break problems down and build systems to solve them or because they've actually been abandoned as a concept? I.e. we don't need to talk about it because we all just do it vs not talking about it and not doing it.

xLaszlo 5y ago

This is one of those posts that exclusively caters for reassuring the audience regardless of whether they are doing right or not just to make them feel better. Refactoring is part of a cycle and you do it before you publish your code to others. If you don't clean it up, you are wasting someone's time.

korostelevm 5y ago

For me some top qualities of good code is - Readable Maintainable Fault tolerant If it works, there are no plans to extend it and there is no one to read it - then it doesn't matter what it is. I know its good code without having to look

laserlight 5y ago

> I know how to write good code. > Usually it means spending more time now to make the code better for some future state of the world. No. That is called premature optimization/abstraction/development and should be avoided. Shitty code is shitty today. Poorly chosen names, copy-pasted pieces, implementation doesn't reveal intent, mismatch in code and comments, etc. Doing these right should be habitual and shouldn't be a function of cycle time. Otherwise, they tend to creep easily.

laci37 5y ago
Naming things is hard, copy-pasting is fast compared to extracting shared logic if you need small changes. Implementation will not reveal your intent, if you are not sure what you intend to do. I'm working in ML research so I kind of write shitty code for a living. All these problems are small things, that are okay if you just try something new. If it sticks, you'll build on your previous code so the junk just piles up. The challenge is spotting the time when the shit just starts o bog you down.
- xandkar 5y ago
  That is all fine if you're the only one that needs to understand that code. Otherwise you're wasting other people's time and sanity. Unless, of course, it all works for everyone, in which case carry on. At least until a new-enough team member arrives and starts pulling their hair out :)
  - jean_valje4n 5y ago
    Data Science is all about writing shitty code. Most of the time you're just digging for data in a notebook, and then you can write things out proper once you've got something that could work.
    - laserlight 5y ago
      I guess we can distinguish between programming and prototyping. Prototyping is more forgiving because it has narrower scope and spans shorter time. Even then, bad habits tend to carry on to the programming part. So better be deliberate about it.

yakshaving_jgt 5y ago

I have some shitty code that runs an important part of one of my SaaS businesses. I'd love to refactor it. I'd love to swap out the HTTP library that it uses with the better one that the rest of the project uses. I'd love to remove all the nesting and complexity. I'd love to make it not an eyesore. But here's the problem: - In the past five years, it has never failed. - In the past five years, it has not needed to adapt. - If I change it successfully, it will make exactly zero difference to my paying customers. - If I change it unsuccessfully, it will break a core part of the system that people are paying for. If I were to refactor it at this point, it's really only to pander to my own ego, which probably isn't a sensible business goal.

ejb999 5y ago
I'd take 'shitty code' than runs flawlessly for years on end, over non-shitty code that doesn't. I've worked with too many 'architecture astronauts' over the years who over-design everything based on the latest-and-greatest thing they just read online someplace, and make it so complex no one understands how it works, or how to maintain it, and often doesn't do what it was intended.
- okl 5y ago
  I worked with both, 'architecture astronauts' (lol!) and shit-coders. I'd prefer there to be a balance. Code has quality can be measured in more than just one dimension. It's fine if code works, but it's even better if you know how. (No obvious errors vs. obviously no errors)
  - bussierem 5y ago
    In case you haven't heard of it before, that term comes from this blog post, quite a good read! https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
  - marcosdumay 5y ago
    > Code has quality can be measured in more than just one dimension. Well, if you don't need to change it (like the GP), most dimensions are moot. We used to call that "maturity", but the entire concept is out of fashion nowadays. What leads to a correct architecture being probably the most relevant one by a long shot. Because a good architecture is a hard requirement for parts of your code to stop changing (the other being requirements maturity, that is not a dimension of code quality). But yes, before reaching maturity, there are many dimensions of quality you may want to optimize for, and they conflict between themselves. Also, architecture astronauts get this name because they don't create good architectures, so you don't want them designing it anyway.

deleted 5y ago

[deleted]

egeozcan 5y ago

Better: Learn to write non-over-engineered code that is obviously written by a professional without thinking. Even better: Learn to write boring code, fast. There will be exceptions, but those are rare and better resist the urge for abstraction until the very last moment!

ejb999 5y ago
>>Even better: Learn to write boring code, fast. Under-rated comment of the day.
akprasad 5y ago
Two quotes from my favorite go (board game) player that seem appropriate: For writing without thinking: > You have to soak up the fundamentals as you practice on your own, studying them until they become a part of your very being. If the fundamentals do not operate subconciously when you sit down to play, you have not mastered them yet. For fast boring code: > Go is the kind of game in which you are an expert if you can just keep on making ordinary moves. You need not play any especially brilliant moves at all. Amateurs' moves, however, are frequently far from ordinary; in fact, I see them making the most nonsensical moves imaginable[.] More here: https://arunkprasad.com/log/kageyama-7-dan-on-amateurs-and-professionals/ https://arunkprasad.com/log/kageyama-7-dan-on-amateurs-and-p...

deleted 5y ago

[deleted]

eternityforest 5y ago

Coding is an important skill to develop. But I'd rather develop my ability to NOT write code. To choose libraries I won't have to mess with. To DRY up the architecture so I'm not implementing the same thing 5 times in a higher layer that would be trivial in the lower layer. To not encourage sprawling piles of code by making sure there's one obvious way to to the things that need doing. Shitty code will just teach me to code. But I already know how to code. I've been coding for a while now. I don't need to be any better at writing average crappy code. I need to be better at writing bulletproof code that is as close to bug free as it can get, and architecting to prevent the need for shitty code. Should musicians be lazy in their practice? Everyone outside of tech says you will play how you practice. So if they encourage shitty code... you wonder if they really are all that committed to making bug free apps, or if they are dragging the old WorseIsBetter anchor.

indymike 5y ago

Great code takes a while. I've learned to take this approach: Works -> Like -> Love First I write code that works, pretty much by whatever means I can. Sometimes it's great, but most often, shitty is the right word for it. But it works (sometimes, well, sometimes... um...). Then I try to refactor to something that is likable. It's often not perfect at this point because maybe it's not as performant, there are side effects or the api isn't as well designed as it should be. The final step is to really go for something that is lovable, which usually means will not have to be re-written for a while, and often becomes quite re-usable. The nice thing about this approach is that I'm able to get things working quickly (and make customers happy) and it differs optimization until enough is actually understood to optimize.

bennyp101 5y ago
I've always thought of it as a kind of image rendering! First pass gets me something that works, then every subsequent pass makes it a little better, like, outlines first, then some colours, then some shading, then some fine details etc

sktrdie 5y ago

Meh, not convinced. Sure you can craft a shitty built bike with cheap parts so to learn more quickly about how the bike fails, and sure you can probably make some money selling these shitty bikes. But I’m in it for the craft. I want to build and sell super high quality bicycles that ride and look beautiful and will ride for a lifetime. And for that, every little detail of the bike has to be crafted in a high quality manner.

maccard 5y ago
In your analogy, what about the parts of the work that aren't building the bike, like the printer you use for shipping labels. Sure you could buy a $1500 xerox, but you could also buy a $99 laserjet. Across the N items you buy, a handful will fail or need replacement. they're the things you buy quality versions of.

andy_ppp 5y ago

There is a huge difference between planning for the future (which you should not do, agreed, unless that future is < 3-4 tasks time, say) and writing shitty code. I class shitty code as not what he's said but things like works by accident, no tests, naming is misleading, 3000 line files, spaghetti code etc. etc. Doing these things does not make you faster or produce more software. My opinion is "do the thing that another developer can understand quickly" is the minimum requirement. Even if the code doesn't work (or has a bug!) at least it has some chance that it can be fixed. I think the author is conflating two issues, 1) planning for the unknown is impossible and time consuming (true!) and 2) all software engineering practices also make coding slow (false!).

nesarkvechnep 5y ago

I believe most shitty code is not a result of unfamiliar tech stack, tools or environment but not enough time spent on thinking about the problem at hand and how the solution can be open to modification. In that vein, the author encourages shitty code.

zqna 5y ago

Shitty code writers typically justify that it's some(thing/body) else that doesn't allow them to write OK code. They trade the imaginary speed gains (my estimate it's 10-20% of effort difference between shitty and OK work) for problems that start manifesting immediately or are ticking bug/maintenance bombs. The problem is that a lot of engineers try to go the shortest way possible, instead of investing extra effort to think little about the future. They see it either black or white, either shitty or perfect - there is no middle ground. I just noticed that every type of copy/pasting is now ok if your application is using "microservices" architecture. Nobody knows why "microservices" were chosen (as there is no demand for it, nor the implementation of that "architecture" allows them to easily scale), but hell, now we don't need to isolate the common stuff into a single place. And then, when they see some crap, then they keep adding more crap for a sake of consistency.

skrebbel 5y ago

I love the code in the screenshot on top of the article.

ineedasername 5y ago

I think there's a balance to be had. I used to write shitty(er) code, and often when I have to revisit it to mod for a slightly different purposes my thought is something like "that lazy ass, I'm going to have to nearly start from scratch to make it work for what I need now" So now, unless time crunch is so bad I have no option (and even then I push back against it to try & get more time to do it right) those are the time I'll cut corners on robustness, readability, etc. I also put a comment in at the top with a deep apology to the angry version of my future self with a reminder if the circumstances at the time. It helps me not pound the keyboard so much in frustration.

pdinny 5y ago

This present a false dichotomy of extremes: shitty code and hopelessly overly complicated intended to address all manner of eventualities that never materialize. Both extremes are awful choices IMO. If the code you are writing is truly unlikely to be extended and adapted then it may be fair to relax your requirements for code quality. As for most things I'd say that applying some discretion to your actual context is more valuable than blanket approaches of embracing bad code. Code can be good without taking forever and without being over-designed. On the other hand the accumulated effects of shitty code upon more shitty code is unlikely to be a net positive. Well-designed code can be simple.

aahortwwy 5y ago

Nope. The startup I work at has been compartmentalizing and chipping away at our shitty code for the past eighteen months. We're not doing this because it offends our aesthetic sensibilities. The shitty part of our codebase is truly shitty. It fails to do its job regularly, causing significant toil in various parts of the business. Junior engineers can't make simple changes to it without causing serious regressions in seemingly unrelated parts of the system. It's slow as fuck. New engineers have to spend weeks reading the codebase if they hope to understand it, and some just give up. There's a big, measurable, drop in velocity whenever we have to work with the shitty codebase. So now we're effectively forced to do an incremental rewrite in order to build new features, which is terrible because rewrites suck and bring their own drop in velocity with them. In practice, writing shitty code is not all that much faster than writing good code if you know how to write good code quickly - but I guess some people don't bother to learn. I read somewhere once that at a growing company the next person who works on the code you wrote is highly likely to be new to the company and have less industry experience than you. When you write code, you should write so that that person can work on it productively.

scottious 5y ago
I feel like the author is really saying "don't over-engineer". At no point does he say create code that does not work. The closest he says is that ALL systems will fail and that he'd rather fail with throw away code than some overly abstracted, lovingly hand crafted pile of code. The point the author is trying to make is that trying to build a perfectly designed cathedral of code can often be counter productive.
ryandvm 5y ago
I believe you, but would the startup even exist if they had spent 2 or 3 times as long developing the MVP? The reality is that good engineering has higher upfront costs than quick-and-dirty. Sure, it's usually cheaper in the long run, but initially it either takes longer to plan or it takes more expensive engineers to execute. And for a lot of startups, getting that cheap MVP out the door is the only path to additional investment. I'm all in favor of quality engineering, but I'm also pragmatic enough to realize that sometimes you have to sling a little shit in order to gain the luxury of doing it the right way.

flavius29663 5y ago

This is a false dichotomy that I see in a lot of developers(including myself a while ago): fast+ugly vs slow+futureproof. In a big codebase futureproof is more important, but let's put that aside and talk about quick and dirty standalone programs. Even when talking about the needs of now, ugly code can slow you down significantly. Ugly code takes you longer to debug, longer to see errors, longer to modify, longer to built upon even in the next hour. So for me it's a matter of writing code that is at least good enough for me NOW, and then I start thinking about futureproof and other maintainers as I get closer to a commit and during pull requests.

pron 5y ago

I think developers, especially those with, say, under 15 years of experience, place far too much emphasis on code. No doubt, very shitty code can have a big adverse effect on long-term maintainability, but correctness is much more influenced by algorithm design, which is often better and more quickly explored in something like TLA+ or Alloy than in code. A bad algorithm design costs much more than ugly code. Focusing on code aesthetics also takes time away from other, more important, activities, such as profiling.

d--b 5y ago

Ok. there's shitty, and there's _shitty_. I hope that screenshot is a joke, cause holy crap! That doesn't look good. I seriously wish the author is not defending that kind of shittiness. I am all good with the if(process.env.env !== 'notProd') part, but indentation, come on? I think this can't be a real piece of code anyways, cause the author would have done console.log('here1'), console.log('here2'), and console.log('here3').

medwards666 5y ago

Most of the previous comments seem to be firmly in the 'nope' camp when it comes to code quality. What most of the appear to be missing though is that they're looking at their production codebases, and in that instance, I would wholeheartedly agree - Production code (or code destined for Production) should be of high quality, developed to standards and over-engineered where applicable. Where I think the OP is referring to writing shitty code is when coding either purely for the fun of it ... to learn a new technique, or a new language for instance, or when prototyping something - sending out the feelers to see if something you can hack together in a short space of time could be developed into a viable solution (at which point, you'd then start to either refactor it into decent, production ready code, or toss it aside and begin again). Shitty code definitely does have its place, but anywhere near a production codebase isn't it.

kretaceous 5y ago

Slightly tangent but one thing that these code practices languages often miss is using the language to its fullest. Most beginner developers who are not very used to the language reinvent the wheel for a lot of in-built functions. For example, I've seen stuff like: ` const arr = []; for (let i = 0; i < anotherArray.length; i++){ arr.push(someOperationOnEachElement(anotherArray[i])) } ` instead of `const arr = anotherArray.map(someOperationOnEachElement)` Not knowing what your tool/PL can do can lead to hard-to-maintain code. One should really leverage the expressiveness and syntactic sugar wherever relevant.

deleted 5y ago
[deleted]
kretaceous 5y ago
EDIT: code practices languages -> clean code practices articles* can do can lead -> can lead (There's no edit option for me, so replying:)

_benj 5y ago

I think intentionally writing shitty code is not a good advice, but it does help with taking us out of the rut of perfectionism and over-engineering stuff! For me I try to follow two principles: First, write boring code, and I mean boring, long variable names, no syntax sugar, no clever combination of boolean chains... code that I would use to teach a beginner in the language (or more aptly, future me) how to start coding! The second is plan to write things twice. This one is a double-edged sword inasmuch as it can help to further clarify or make even more boring the code, or be the place to start adding "optimization" and "cleverness" in the code... I try to stick to the former. Some of the most valuable code I've written I would call either "hacks" or "scripts", not code, but nonetheless, it solved a real problem instead of being beautiful/elegant or whatever

jvanderbot 5y ago

That code snippet is like one of those Lovecraftian paintings where it looks normal, but the more you look at it, the more weird and horrifying it gets. Bravo.

usr1106 5y ago

Not convinced. Unmaintainable code is the big problem. He is right that the future is unforseeable. That's why code needs to he maintained. A weird non-local bug is detected. The developer who wrote it found greener meadows. Sales has sold a feature we don't have yet. We notice that we do business with some different functionality that we originally envisioned. There will always be reasons why code needs to be maintained, whether it has worked for 3 days or 3 years. Now if the code is unmaintainable and every change takes 5 times as long as soon it should and introduces 3 new bugs we are in trouble. Shitty code is almost always unmaintainable. (Unless the shittyness is local inside small functions, but I doubt that's acommon case.) Of course over-engineering and needless optimizations also lead to unmaintainable code. If the company policy were "Write shitty code" I would run away. I am sure it would lead to absolutely horrible results. At my work we stress the value of good code. Still we end up with shitty code regularly. We just didn't know better when we did it. And we do not rewrite everything once we believe to know better. It's hard enough to struggle with that level of shittyness, I don't want to have it increased fully intentionally. I do that for scripts I will never use again, but not for anything I merge to the code base.

Jtsummers 5y ago
> Shitty code is almost always unmaintainable. (Unless the shittyness is local inside small functions, but I doubt that's acommon case.) Of course over-engineering and needless optimizations also lead to unmaintainable code. I was going to write something similar, so piggybacking. The shittiest code I've seen has always suffered from this. Sometimes it was shitty (in this sense) because of an assumption that it was "throwaway" code, but it was never thrown away. Gross copy/paste throughout, highly redundant code (same variable, or variable with the same intent, created in many local blocks), mostly existing in mega functions (thousands of lines long) with complex conditional logic to navigate to specific desired sections from the entry point at the top. If it was really throwaway code, then this can be tolerated. But it doesn't require much thinking into the future to replace a 10-line block that's repeated 50 times with one change at each location into a single function. If, in the future, some of those 50 uses of the function need a different function, change it then. Better that than having to keep 50 locations in sync with each other because "making a function now is premature optimization" or "YAGNI!!!". Well, programmer time and delivering quickly has value too. When what would have been a 5-minute task (read function, change function, rebuild, rerun) becomes a 5-hour, 5-day, or 5-week task then everyone is losing out because of the shittyness that was trivially observable and correctable early on. The other big example of shitty code that is unmaintainable (or becomes unmaintainable) is tight integration between IO and business logic. Without a clean separation, you typically end up with similar repetition to what I described above, or something where a "small" change ends up having massive knock-on effects. This brings maintenance to a crawl as you have to tease out the consequences of that small change, which is non-trivial. That's what makes the code shitty. Corrections and clean separation are often forestalled for the same reason that the previous example often ends up with a mega function instead of a nice, often small, set of utility functions: YAGNI. If your project is going to last more than a few months and has even a modest level of complexity, you will need that clean separation. Otherwise, you end up with increasingly complex (but unnecessarily) code that works around the initial self-inflected hamstringing, or you waste weeks or months cleaning it up and delivering nothing to customers, who become impatient so the cleanup gets cut short and you now have a hybrid mess: half-good code (that will decay rapidly) and half-shitty code (that still can't be maintained).

altgans 5y ago

I recently made a similar observation: Write shitty! Background: I am writing a novel. In the beginning I sat down and obsessed with every little detail, spending multiple days figuring out the perfect formulation and text flow. And then I would maybe change a little thing in the story-line and have to start over again. This really sucked the whole fun out of the writing process. Then I changed my approach: I just write whatever comes to my mind, independent of whatever I just wrote before. Doesn't matter if the previous scene had character A as sidekick, if I like character B more, then I simply switch them. Some scene is way over the top and doesn't make sense? Doesn't matter, I write it. Writing is fun again. I sit down, get into deep-work-mode and just write. No constraints, no thinking. Granted, this is only draft #0 and I will probably have a rude awakening when I have to merge all my writings for the next iteration of drafs drafts, but so far I am rolling!

drcongo 5y ago

Ironically, for an article titled "Write Shitty Code", the entire article is blank for me because they wrote shitty CSS. https://imgur.com/a/41eXasz https://imgur.com/a/41eXasz

beardyw 5y ago

“If a thing is worth doing, it's worth doing badly.” G. K. Chesterton

allenu 5y ago

I agree with the author. Learning to write good code, and well designed systems, requires writing lots of code. The best way to do that is just pump it out. It’s harder to write a lot of code if you try to make it perfect and cover a lot of future scenarios. The more code you write, the more you start to see larger patterns that hinder or improve your system design. You don’t see those things as easily if you are writing bits and pieces slowly. As an aside, writing code in a professional setting can be limiting as well since you may not be able to write code quickly (or shitty) enough to get to a place where you see the effects of your decisions. You’ll write less code and end up focusing on making safe decisions, which means less experimentation in techniques.

Clubber 5y ago

DRY, KISS, YAGNI

Prometheus_Lodi 5y ago

The software priests who taught the MSCS courses I took did not teach these insights. No harm comes from studying the beautiful code of the ancients. But, indeed, less work gets done when you complicate your task with goals of beauty and future-proofing.

hypfer 5y ago

Shitty code such as a website that shows 0 text with third party js being disabled?

Prometheus_Lodi 5y ago

beardedetim 5y ago

This is expressing something I've been trying to express for _years_. I've come to call it "throw away code" instead of "shitty code" because of what's happening in the comments: people always came back to me and said "Shitty code doesn't work!" and we get into an argument about what I mean by shitty code. I find that throw-away code gets my point across much more cleanly without people's objections being raised immediately. Most engineers understand that when I say "throw-away code" it doesn't mean the code doesn't work. It just means that I can _throw it away_ when I need to later. It is "shitty code" because it's _supposed_ to be replaced.

zachwill 5y ago
I do this too — and feel like “throw-away code” is a great moniker for it!
AnIdiotOnTheNet 5y ago
I believe it was Casey Muratori said "first: write the stupidest thing that will work". Meaning, it's code that is obvious and simple and does what you think you want to do. It doesn't have to be efficient, or flexible, it just has to do the job. Later you can change and/or improve it if need be.
- ramesh31 5y ago
  > It doesn't have to be efficient, or flexible, it just has to do the job. Later you can change and/or improve it if need be. I think the reality, though, is that that day never comes. Usually if something works, it will never be replaced. So the real trick is writing something that finds a perfect balance between "just works" and "elegant/aesthetic/maintainable/readable".

kretaceous 5y ago

Slightly tangent but one thing that these code practices articles often miss is using the language to its fullest. Most beginner developers who are not very used to the language reinvent the wheel for a lot of in-built functions. For example, I've seen stuff like: ` const arr = []; for (let i = 0; i < anotherArray.length; i++){ arr.push(someOperationOnEachElement(anotherArray[i])) } ` instead of ` const arr = anotherArray.map(someOperationOnEachElement) ` Not knowing what your tool/language can lead to hard-to-maintain code. One should always try to leverage the expressiveness and syntactic sugar wherever relevant.

0xbadcafebee 5y ago

Well that's one way to get me not to use your SaaS

scottious 5y ago

> A lot of senior experienced people will talk about all the “shoulds” your code should be like. They are usually describing some far distance promised land that they have never visited either. Oh how I can relate do this. I've seen so much guilt and inaction from developers who are paralyzed by "should". They so badly don't want to be a "bad engineer" that they'll over-engineer just about everything and end up causing a lot of problems.

luckyorlame 5y ago

Why not just post an article on how to generate flame bait?

allo37 5y ago

My usual approach is a bit like how I wrote essays on loose-leaf paper back in school: Start with a rough draft, and then once all your edits are done, produce a "clean" copy. I think a lot of code that is described as shitty comes from doing the first step, but due to time constraints the second step is skipped.

lacrosse_tannin 5y ago

Can do!

whoomp12342 5y ago

I get it, but as a senior member of the team you have to be careful. Yes it is fun to get shit done really fast, yes it creates short term value but you have to be aware of the downstream effects. When you build new stuff, set patterns, create infra, you are setting the example that junior members will learn from at best, and copy/paste at worst. Do you want a ball of mud because its all too easy to get one

wreath 5y ago
I think what you're talking about is not only shitty code but also poor design which is far more dangerous. Writing shitty code behind good design is a different story, and to my understanding, this is what the author describes.

jarek83 5y ago

If you work on your own, that's probably not a disaster to write shitty code. BUt in a team it's a big no for me. And it's not really about the future extension of code, although modular approach generally helps here too. The biggest benefit of non-shitty code is that others can get through it quicker. In 99% of cases code is written to be read by others in the first place (including yourself after some time), then goes the bug-less priority and then anything else. 1% is where you really need something to be performant - the ease of reading is then not important at all as such code has to be messy.

deleted 5y ago

[deleted]

Kiro 5y ago

I love when a project transitions from clean to shitty code (which eventually happens as quick fixes and shortcuts pile up). At that point I can start iterating much faster since I no longer care about making everything as clean and smart as possible. The battle is already lost so I can just embrace it.

ramesh31 5y ago

I've learned to embrace the jank. Architecture matters, but implementation rarely does. You can sit around all day dreaming up a perfect parsing library with full test coverage and a pure functional API to do some string manipulation, or you can smash out a 20 line function that works for your case and move on with your life to things that matter.

sebastianconcpt 5y ago

So instead of prototype often, go production early and iterate frequently is now spelled: Write shitty code? Oh boy... If masters and geniuses of the past would read the "common-sensical" advice we hear today and how it is being expressed, they would not be surprised by the general shitty state of the world (all civilisations around the world) but to find it plain miraculous that we're still in a semi-funcional way or alive at all. If you know how to write good code, write good code for the state of the world right now then. Care about the future in the future. Kent Beck taught us this already in a very detailed way two decades ago. Invented Unit Tests in Smalltalk to have fast feedback on regressions frequently and granularly. All languages have that today. Then why in the world do, instead, these software engineer self-serving rationalizations that will accumulate tech debt you're carefully not talking about? How in the world an unexperienced developer would receive this advice as a propaganda in any way other than a push of self-indulgence for incompetence? How this advice makes you an A player?

cryptica 5y ago
I was thinking the exact same thing but I've read so many of these utter nonsense articles recently that I rarely even bother to comment on them anymore. Who knows. Maybe they're written by a bot with a job-creation agenda. It's just cringe. I think your intuition is right, the world economy seems to have been hollowed out. Look at medicine, the media, big tech... They all suck. It seems as though they've been promoting idiots intentionally and now idiots are calling the shots.

iamwil 5y ago

The problem is, future programmers only get to look at the artifact--your shitty code--rather than all the learnings you got, since I bet you never wrote it down. Oh right, I'd have to ask you about it. And chances are, you're not even working here anymore. https://news.ycombinator.com/item?id=29919428 https://news.ycombinator.com/item?id=29919428 That said, there are definitely people that swing too far the other way. Some people create abstractions where there doesn't need to be. And they're usually not well thought out ones either. I wish there was a way for code work like pen/pencil and paper, where if you're doing exploratory work, you can sketch. And it'll look like a sketch for other people reading your code, however that can be indicated. But once you learned enough of the domain, you can firm things up, like you do with a pen to add safety and other constraints.

polycaster 5y ago

My impression is a lot of the best practices spread today are suited best for FAANGs or at least high tier SaaS businesses (which often contribute to the frameworks used). One thing I hear repeated over and over is: Code is going to change frequently. Well that's not universally true. I don't even think that's true for the vast majority of code in production globally. If you build an app with one specific, well-defined purpose that iself is not going to change a lot (eq. supporting the workflow of a specific business, managing inventory, etc.) that might easily run for a decade with <10% LOCs ever being touched. I've build dozens of those in my career and I'm certain I'm not the only one. If you're on the quest for the most beautiful code in this scenario you're wasting your client's time and money for your own vanity.

larryfreeman 5y ago

Totally agree with everything in the article. Unclear how this is different from prototyping code before you start on the industrial-strength version. https://en.wikipedia.org/wiki/Software_prototyping https://en.wikipedia.org/wiki/Software_prototyping

jackjeff 5y ago

There’s a time and space for shitty code. Something you write once, as quickly as possible and throw away. Anything else, that ships to any kind of production environment, needs to be reliable and maintainable. Shitty code is a false economy. Time savings often fail to materialize if not out right end up costing more in maintenance. Good code is not something extravagant nor expensive. It’s something simple that just works and looks obvious to anyone who looks at it. Good code is not over designed code. The difference between shitty code and good code is often the difference between a prototype and something production ready. Take the prototype code you wrote, careful think of all the edge cases, maybe test them, rename anything confusing, comment non obvious things if any, and refactor, throw away as much as you can until every line matters. Good code does not trouble your sleep because you know you did everything you could to ensure it is reliable and even if there is a bug, there’ll be enough info logged and the code is so clear, that fixing the issue will be obvious. If you’re in the habit of writing good code, you will become better at it with practice and be extremely efficient. If you’re in the habit of writing shitty code, you’ll have to write more shitty code to work around shitty bugs and spend endless time chasing mysterious problems in production.

Koshkin 5y ago

> shitty code Still, I have never understood why anyone would want to write if (success == true) instead of if (success)

yakshaving_jgt 5y ago
Maybe both of those examples aren't great? Maybe you want something like this? case result of Error e -> -- some error handling code Ok a -> -- the happy path

tau5210 5y ago

> A lot of senior experienced people will talk about all the “shoulds” your code should be like. And the article itself is another "should".

unobatbayar 5y ago

Valid arguments but this is a terrible advice. Good or bad code is a learned ascept of an engineer, or experience rather. If you care enough then eventually you will write great code unconsciously with high velocity. Someone's shitty code might be fucking beautiful if they practiced for many years. My advice is, work in a place with good code review, code quality culture because it really does make the difference. We're unconsciously shaped by our peers.

macinjosh 5y ago

I think this is OK in some situations and not OK in others. To me it is a lot like writing in a human language. When I am texting someone I am close with there is no reason to avoid slang or to use the best grammar and punctuation. When I am writing my CV it would be advisable to be more formal. The author of a dime-store novel will write at a different standard than the Encyclopedia Britannica. My point is that you should write the code that is necessary for the situation and if you are part of an engineering organization the leadership or team as a whole should decide when to use what level of quality and should understand what the trade offs are. There are legit business reasons to write throwaway code when time is of the essence and there are times when you need to take the time to risk over-engineering/over-building something just to be as certain as possible that it won't fail.

elmolino89 5y ago

The shitty code/do it supposedly once is quite widespread in academia, and from what I have heard also in at least some biotech companies. The problem: irreproducible results. Once you chain dozens of command lines, unversioned shitty scripts, no md5 checksum-ed inputs/intermediate results etc. you are in a smelly swamp full of monsters. Even you one week later will not be able to do it again. Markdown docs/jupyter notebooks are minimum even if one does quick and dirty proof of concept thingy IMHO.

tpoacher 5y ago

This article makes some very good points, all of which are ultimately false. To make a medical analogy, I don't know that I would trust a surgeon with a billion operations record and a 50% complication rate more than one with a 1000 operation record and 1% complication rate. And I certainly would hate to be the colleague inheriting their patient.

Zoadian 5y ago

the best way to write code is: write code that you can delete without any effects on the rest of the program. and keep all related code as close as possible together in the source code. Also keep mutations as far up the call stack as possible. use pure functions whereever possible.