12 ms·

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that

> the code is usually not particularly shit I'm sorry, but yes, it usually is. I've been in this business for over 25 years, and I'm one of the few people that actually enjoys the challenge of dealing with legacy code. But most of the code I've seen is shit. The answer to the question "could it have been done better" is usually "yes, if it had been done by someone who understood the basic principles of the paradigm they were developing in and the tools they were using to do it, and actually gave crap". The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear. I completely agree with the point the author is trying to make about the attitude problem, especially amongst coworkers, but let's not gloss over the fact that halfway decent code written by competent developers is still very, very rare. Most code out there is shit code. Denying it is not going to help either.

babarock 13y ago
You're probably right, what do I know I've only been programming professionally for 3 years. However, I find that it's more helpful to have a positive attitude when reading code I didn't write. "Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with". I'm not denying that I found seriously bad code running in production. And I'm not denying that it's more common that I would've believed. But the moment I start treating every piece of foreign code as shit, I'll miss out on interesting insightful techniques. The point of this article is a reminder that it's easy to get sucked in the "this is shit" culture.
- drtse4 13y ago
  Exactly, that "Why did he write it this weird way?" helps you understand the programmer who wrote it (his level of expertise) and gives the opportunity to analyse the tradeoffs he made. This helps discern between real shit and unpleasant code that had to be written/structured that way.
- mgkimsal 13y ago
  "Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with". --------------------- You're 3 years in. In another 3-5 years (maybe more), this 'positive attitude' will (and should) go away. You'll have a much better understanding of the 'weird' ways, and will be able to tell 'quick hacks' from 'crap code' as the OP was referring to. You will have learned most of what you need to know by investigating the 'weird way', and you'll see the patterns, and you'll be at this for 15 years, and you'll be seeing the majority of stuff coming out being crap code by younger developers. It's the way of the world.
  - acjohnson55 13y ago
    I'd much prefer to have GP on my team than you, frankly. I think companies are much more productive when they have people willing to learn from and teach one another rather than bringing negativity.
    - mgkimsal 13y ago
      The last few years, I've primarily been working freelance going in to companies and dealing with crap cleanup left by people who were "positive" about their own abilities, gave a pass to everyone else on the team who could get something to run without too many obvious errors, then left. So... you can call it negative, I call it realistic. I'm pleasantly surprised when I discover good, well-written code, and it means my estimates can be revised downward - something everyone enjoys. Hoping for the best and getting the worst is horrible - expecting "meh" and getting a positive shock is great, but doesn't happen all that often. I'd have loved to be at a company where people learned from each other and taught one another - imo, it's extremely rare. I've seen it a couple times in the past 15 years, but more often than not, politics and/or ineptitude takes over, and the 'learning/teaching' thing goes out the window. As a developer, I had a technical manager over me who'd never coded. I've had a colleague who was hired to 'fix bugs', and has to watch the people who wrote the bugs go rewrite everything in to a 'version 2', rewriting exactly the same problems, because "they've been here longer". So... yeah, companies that foster teaching/learning environments might be nice, but it takes a LOT of work to get right.
corresation 13y ago
Most code out there is shit code. Denying it is not going to help either. So you do it "right" then, I assume. What do you think the next guy is going to say about your code? Do you really think they're going to praise the excellent code quality? Or will they declare to all around that it all needs to be rewritten because it doesn't conform to the newest flavor of the month? I absolutely and unequivocally agree with the author: People declare everything around them as shit to prop themselves up, and the explain their own inadequacies in advance. There is shit code, granted, but by some measure of shit all code is shit. A viewer can destroy code as over or under engineered, over or under built, over or under abstracted, over or under object-oriented, over or under functional, and on forever, and anyone who thinks there is an actual right way in any reasonably complex system is demonstrating profound naivety. The one thing that I will disagree with in the submission is the notion that this is a new or increasing pattern. It isn't, and has been the norm for decades. This is what developers do, especially those who are weak at reading code: Declare it shit in advance and just write your own.
- bowlofpetunias 13y ago
  Maybe I haven't been entirely clear. I'm not talking about a mismatch between approach (over- or under- whatever) and goal. I'm not talking about quick hacks that were never refactored (because of course, there never is time). I'm not talking about code that has gone through many cycles of unpredicted change and has acquired many layers of cruft. I'm not talking about code made by inexperienced developers who still have a lot to learn. I've seen all that. I've written all that. I've left code behind I would be embarrassed to show in public. I'm shocked some of it is still in use, and I'm sure people who have to maintain it will curse my name. That is part of the job. What I'm talking about is pure, unadulterated shit code. No structure, no logic, no consistency and barely functioning only under very limited conditions. Utterly incomprehensible unless you immerse yourself deep into the mind of the author like an FBI profiler and a serial killer. No, there is no one "right" way of writing code, but boy there are an awful lot of "wrong" ways.
  - kabouseng 13y ago
    I would suspect that such practices are more prevalent in the web development world. Enterprise software and embedded development (my focus area) suffers far less from the pure unadulterated "shit" code pattern. Mostly I suspect that is because the software development practices such as code reviews and coding standards are actually enforced.
nyrina 13y ago
I'm just going to ask the question... What do you think makes your code good? I bet the next guy that comes around in 15 years and reads your legacy code (Grats on having code actually runs for 15 years!) will think it's the worst piece of shit ever created and are sure to think you are one of the worst developers in the world.
- loup-vaillant 13y ago
  > What do you think makes your code good? Answering for myself: (1) it's short. Often significantly shorter than my colleagues'. (2) it has few bugs, if our bug tracker is to be believed (I reckon I'm not very confident about that one). On the other hand, I tend to be slower, especially when I have to write against less than optimal APIs.
  - solistice 13y ago
    But short code isn't necessarily a garrant for good code. I went through a teenage phase where I would strive to write the shortest code possible. It's cringe worthy, and working my back into it seems scarce impossible. If you drew out the program logic, it'd look like an Eldridge terror. It just isn't good code. But yes, if you're writing War and Peace in order to parse XML, it's unlikely you're writing good code.
    - loup-vaillant 13y ago
      I try to write the simplest code possible. It always end up being shorter than if I didn't. Also, of two okay-looking pieces of code, I noticed that the shortest is almost always the simplest. Which makes size a pretty good metric.
- RogerL 13y ago
  Why would you bet that? We have a broad understanding of how to structure and write software. These ideas have been collected together in books. I refer to books like Code Complete, Debugging the Development Process, Clean Code, Refactoring, Programming Pearls, Beautiful Code, and so on. Then there are the language specific books. I don't believe you can craft well written C++ without reading Scott Meyers' books (or having absorbed the same knowledge from others), for example. Even the much maligned Design Patterns, which has been turned into the truly dreadful design by pattern, helps us to think about how to structure code. I can't type it all in a post. But we are talking about modularity and extensibility. Decoupled code, so you can make changes here that don't break something over there, and so you can easily move code from one project to another. Well commented code - where 'well' means the author takes the use of the code into account - some deeply internal function named ComputeAverageSalary probably doesn't need much in the way of extra comments, anda top level api call to a framework being used by thousands needs a lot of documentation. Well structured code. The if statements make sense. They are not deeply nested. logic is not duplicated, or contradicted when it is nested, because that always leaves you scratching your head as to the purpose of the author(s), and clueless as to how to add code. So, back to the question, why would you bet that? I've opened plenty of 15 year old code that is good to beautiful. This is not an arbitrary judgement of "oh, OO good/bad", nor an reactionary "it wasn't written by me, so it must be bad". I do consider myself a pretty clean programmer, but I learned it by observing the code of others, reading a lot of books, and relentlessly applying a critical eye on everything I write and others write. All borne not on some arbitrary judgement, but from recognition of how quickly/slowly I can grok a piece of code, how easy it is to find and fix bugs, how easy to add features, and so on. In some code bases that is all fairly straightforward, and in others it is impossible - any fix or change has so many side effects that you need to add 50 if statements strewn about 50 files, in code already filled with if statements, and your if statement break about 15 undocumented assumptions about the behavior of the tightly coupled code.... that, my friends, is shit.
anExcitedBeast 13y ago
Shit is useless, destructive and smelly. Unrefined code by an unrefined developer often works, but not as well as it can and is usually difficult to work with. Big difference. Just like most of the stuff reddit calls "epic" or "mind blowing" is often simply 'neat', most of the code you call "shit" often simply 'could be better'. The tendency to call unrefined code "shit" intimidates new coders and disincentivizes people from contributing to community projects.
nilkn 13y ago
If the majority of code is shit, then it's not really a very useful observation to make repeatedly. So I think this goes back to the author's point that this is really a cultural or attitude issue. It's like the friend who complains about everything all the time: constantly complaining about traffic, about the weather, about how the city is losing its charm, about his job, about his classes, about his parents, about his car, about his apartment, about politics, about how stupid people are, etc. etc., with nothing positive to say. Maybe it's all correct from some perspective, but it's not a very useful perspective and it's definitely an annoying one to be around.
- Jach 13y ago
  There is at least one useful implication to the observation, and that's that most (or all) software is shit. Yet people still use and buy it. The implication is a nice three-edged sword. You're guarded against crippling perfectionism, you're striving to get out of the shit as much as you can, and for developers you will always prefer having the source if you want to fix some shit. This article made me remember this from my quotes file: "All software sucks, be it open-source [or] proprietary. The only question is what can be done with particular instance of suckage, and that's where having the source matters." --viro
  - RogerL 13y ago
    That is not my experience. There is a ton of good to extremely good code out there. I'm rather dismayed by the amount of "well, what can you do" hands-thrown-up attitude here. I've always found clean code to be faster to develop. I find that developers that produce lower quality code tend to spend their days debugging, fighting their code, reading and trying to figure out what they wrote 5 months ago, and so on. They are just not very productive. There are the outliers - people that have instant recall of all their code and elaborate mental models of really poorly structured code - but by and large I find that people that generate low quality code are quite slow performers. I've worked in very good code bases, and very bad ones. In the good ones you can easily figure out what is going on, quickly make changes, confident that you aren't breaking 5 things because things are decoupled. You can produce new code quickly because you aren't fiddling with code nested 6 if statements deep, which is just about impossible to model correctly in your head. You aren't in endless compile/run/debug (or REPL/run/debug) cycles because your first try is usually just about right, because you can understand the surrounding code. I recently requested a simple feature, and was told it would take a week. I was dubious. Then I looked at the code, and decided that they were being conservative, if anything... for something I thought would reasonably take a few hours. This is just an impassioned plea, not to Jach, but to the profession, to cast a critical eye on code. You can produce high quality code quickly. Not "nuclear reactor" quality, but pretty close. Bad code always costs you. Always. Don't write that way, don't allow it in your code base, or in your teammates.
zeteo 13y ago
>I've been in this business for over 25 years [...] The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear. [...] Most code out there is shit code. Denying it is not going to help either. I'm sorry, I respect your experience but this post is completely uninformative. It's much more specific on how awesome you are than on how to distinguish between "shit code written by shit coders" and "less than optimal code written by good coders"; not to mention dealing with and improving either. It's possible to spend a long time in an industry and accumulate much unfounded prejudice along with solid knowledge. As long as the appreciation of "shit code" and "shit coders" remains subjective, it's virtually certain you'll also be considered one someday, when the prevailing paradigms and fashions change again.
- solistice 13y ago
  I think it's a bad case of "dislike due to knowledge". It's stark in the arts, but it applies to almost every human endeavor. As an example in the arts, I dance, and I'm good at it according to almost everyone who sees me dance. But I see myself as a terrible dancer. If I make a video of me dancing, others see every part that's well executed. I'm accustomed to them, and I tend to ignore those parts in favor of every part that's sloppy, every part that just doesn't look right. And it's no different for code. You know what one of the marks for good code is? If the guy writing it is tearing it apart in the comments. Where do you see /* This is a dirty hack I'm ashamed of */? Usually right next to stuff that's a stroke of genius, or at the very least really good code. It's strange that the more you know about something, the less comfortable you get with your knowledge, but it seems almost universal that "Ignorance is bliss", or rather the corollary "The more you know, the less you think you know".
  - deleted 13y ago
    [deleted]
  - Djehngo 13y ago
    I do like code which has comments which describe the level of confidence the author has in some sections (I feel a happier refactoring code which is marked as being suboptimal). But in my experience those comments are usually found above cases where it's possible to make a fix in one line rather than one hundred. (sleeping a thread for 0ms rather than re-architecting a gigantic callback structure).
weavie 13y ago
It depends on what you mean by shit code. Is code that was written on time and on budget - but has a few hacks in it shit? Is code that is beautiful and easily maintainable, but was £1m and six months over budget not shit?
- chriswarbo 13y ago
  Shit code is the third option: Code which was late, over budget and completely unfit for purpose, requiring an army of temp workers to process everything manually while another team come in and spend months on a death march trying to fix it, while the business is hemorrhaging money via lawsuits from pissed off clients with violated contracts.
username42 13y ago
My job is "first level support". I have to analyse problems reported by users and often to read source code to find bugs. I have seen a lot of shitty code and a lot of very clean code, but most of the problems come from shitty specifications. When the requirements reflect a poor understanding of the users need (or a poor sense of logic), whatever the qualities of the developer, the resulting code will always be a maintenance nightmare.
- mgkimsal 13y ago
  The developers should be able to push back on some of that - and at least document in the code that certain logical inconsistencies were raised but glossed over. Simply understanding that something will be a maintenance nightmare should inform a developer enough so that they, at the very least, leave useful info/docs about what corners were cut and why. Until you've had to deal with mountains of various legacy projects completely undocumented, you won't even know this is something you should be doing.
- sitkack 13y ago
  I always thought 80% of coding (solving anything really) is understanding the problem. The other 50% is implementation.
AznHisoka 13y ago
You're assuming all code is written in a vacuum. Sometimes developers are forced to write code under unrealistic time constraints, or they were told to prototype it quickly b/c we'll replace it later (but they never get the time to), and so on.
lnanek2 13y ago
Agreed. Hell, most of my code lately has unit tests and UI automation tests and goes through code review and adaptions for a week after writing and it is still pretty shitty and needs to be tweaked later and will always be a crappy code by committee result by the end. Just getting it into production is a grueling battle that sucks out the most idealistic souls and makes most into code monkeys just trying to hack something out. But hey, if I was coding for a startup lately all of my code would be shit because of long hours and no tests since most of the time we're just writing experiments we'll throw out later so why test?
kyllo 13y ago
There's also the issue that most enterprise code is shitty by design. Tight deadlines and budgets, no time to write tests, project scope too large, too many features, too many developers on the same project, too many meetings and standups, poorly described requirements from Product, UML written by business analysts, overuse of patterns, Spring and other overkill frameworks, etc. To err is human; to really screw up takes a committee.
riggins 13y ago
"Most code out there is shit code." semantic point. if you're saying 'most code' is shit, aren't you saying average code is shit? Kind of like saying a 6 min mile is shit because it's not a 4 min mile.
- sitkack 13y ago
  No, a 6 min mile is not average. And yes the average of most things is shit. Shit isn't bad (unless it is), it is the output of useful work usually. It just needs to be covered up and stayed away from.
  - riggins 13y ago
    This reminds me of how pretty much everyone believes they're a better than average driver. Everyone also thinks other drivers are terrible. Both claims cannot be true. I'd say its appropriate to call 'most/typical code' average code, not shit.
    - corresation 13y ago
      Exactly the analogy I went with. "Everyone is a shit driver" claims almost universally come from terrible drivers: When you have no situational awareness and aren't actively predicting the behaviors of drivers around you, and you don't have confident control of the tools at your disposal, every move that other drivers make seems dangerous and scary, needing panicked reactionary responses. Every trip is a perilous journey with tales of imminent death. I honestly feel the same about people who walk around declaring all code shit. People who aren't competent with their development tools, can't naturally trace code and truly understand functionality, and can't adapt to different styles and era of code tend to be the ones, in my experience, that declare all code shit.
  - dragonwriter 13y ago
    > Shit isn't bad I would suggest that this indicates that your figurative use of "shit" is not the common figurative use of the term in the phrase "shit code", which is impairing communication.
DominikR 13y ago
So what exactly is the point you are trying to make here other than that you are the smartest guy? The article is not about the existence of shit code, the amout of shit code produced per year or how much shit code the average developer will see in his career. It is about teamwork, and what kind of culture poisons the atmosphere in a company. Not about shit code, which by the way everyone here has produced at some point or to be more realistic about it (since usually developers look at their old code and think it is bad) - is still producing on a daily basis.
- jasonlotito 13y ago
  > So what exactly is the point you are trying to make here other than that you are the smartest guy? He took the one thing he could make an easy, pedantic point about and posted it. It's easier to do that and get free karma that actually be mindful. It's low hanging fruit. Just like I could find errors in his comment that would serve no purpose. At issue is, while his point might be technically correct, it serves nothing other than to encourage "Me too" replies. This happens frequently on HN. I encourage you to down vote such posts.
- chriswarbo 13y ago
  The first step to solving a problem is admitting that there is one. I remember debugging some AJAX code once which was racing with itself. It took a lot of mental effort to work out what the existing code was meant to be doing and what it was actually doing, both of which were wrong. At it's core was a simple jQuery AJAX call with a success callback (no error callback, of course), but interleaved through it was a mess of global variables ("finished_yet", "time_last_checked", etc.), busy-loops, manual timeouts, state-rollback functions, etc. What I would call shit code. Once I finally understood what it was doing enough to refactor it I managed to delete most of the file and replace it with a "latest_id" counter which incremented on each call, with the success handler skipping if its ID wasn't the latest. Simple. I approached the developer responsible for the original, to show him what I'd done and explain how Javascript's scope let each call have its own ID. His response was that I'm using obscure language hacks which nobody is going to understand when they have to maintain it, that I should stop trying to force everything into a few lines and that he doesn't need to learn about Javascript's scope because he can already program so learning anything else is a waste of time that could be spent coding. I got told a similar thing during a code review as well, since I'd used map on an array. Needless to say, I didn't stay there long. Now that is a cultural problem, which can only be solved by pointing out shit code (although in a more polite way). Some people are so stuck in their ways that they don't care about improvement because they see their stuff as 'good enough'. In those cases, they need to be shown that no, it's not good enough, because XYZ. I wasn't trying to gain points on anyone; I was just frustrated at the utter lack of care about the codebase we all had to work on. Whenever I spotted anything particularly WTF I'd send out a "Code of the day" email. My favourite is still this one: <td> blah blah blah </td style="....." id="foo" class="bar baz">
moron4hire 13y ago
For me, the tell-tale sign is a demonstrated lack of understanding of type theory. Like calling toString on string objects. Or even worse, calling parseInt on a string that was created by calling toString on an integer! Also, comments-used-as-source-control. If I see one more gigantic block of code commented out with a set of initials and a date "this was removed by/on". Use the source control to do that, dammit.
slewis 13y ago
Sure, there is some really bad code out there. But even pretty good code looks really bad to a lot of developers, because of the "This is shit" mentality the article describes.
mcv 13y ago
In my experience, shit code tends to start with a competent developer solving a problem in a way that seemed reasonable at the time, and then requirements changing, new features getting added, and everything is in a hurry so it never gets refactored. Well, sometimes I do see code that's really very bad and I can't imagine how someone was ever able to type something like that, but that's rare. Usually it's competent people with the best of intentions but as lack of ability to predict the future.

babarock 13y ago

You're probably right, what do I know I've only been programming professionally for 3 years. However, I find that it's more helpful to have a positive attitude when reading code I didn't write. "Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with". I'm not denying that I found seriously bad code running in production. And I'm not denying that it's more common that I would've believed. But the moment I start treating every piece of foreign code as shit, I'll miss out on interesting insightful techniques. The point of this article is a reminder that it's easy to get sucked in the "this is shit" culture.

drtse4 13y ago
Exactly, that "Why did he write it this weird way?" helps you understand the programmer who wrote it (his level of expertise) and gives the opportunity to analyse the tradeoffs he made. This helps discern between real shit and unpleasant code that had to be written/structured that way.
mgkimsal 13y ago
"Why did he write it this weird way?" taught me so much more than "this is shit, let me rewrite it the way I'm familiar with". --------------------- You're 3 years in. In another 3-5 years (maybe more), this 'positive attitude' will (and should) go away. You'll have a much better understanding of the 'weird' ways, and will be able to tell 'quick hacks' from 'crap code' as the OP was referring to. You will have learned most of what you need to know by investigating the 'weird way', and you'll see the patterns, and you'll be at this for 15 years, and you'll be seeing the majority of stuff coming out being crap code by younger developers. It's the way of the world.
- acjohnson55 13y ago
  I'd much prefer to have GP on my team than you, frankly. I think companies are much more productive when they have people willing to learn from and teach one another rather than bringing negativity.
  - mgkimsal 13y ago
    The last few years, I've primarily been working freelance going in to companies and dealing with crap cleanup left by people who were "positive" about their own abilities, gave a pass to everyone else on the team who could get something to run without too many obvious errors, then left. So... you can call it negative, I call it realistic. I'm pleasantly surprised when I discover good, well-written code, and it means my estimates can be revised downward - something everyone enjoys. Hoping for the best and getting the worst is horrible - expecting "meh" and getting a positive shock is great, but doesn't happen all that often. I'd have loved to be at a company where people learned from each other and taught one another - imo, it's extremely rare. I've seen it a couple times in the past 15 years, but more often than not, politics and/or ineptitude takes over, and the 'learning/teaching' thing goes out the window. As a developer, I had a technical manager over me who'd never coded. I've had a colleague who was hired to 'fix bugs', and has to watch the people who wrote the bugs go rewrite everything in to a 'version 2', rewriting exactly the same problems, because "they've been here longer". So... yeah, companies that foster teaching/learning environments might be nice, but it takes a LOT of work to get right.

corresation 13y ago

Most code out there is shit code. Denying it is not going to help either. So you do it "right" then, I assume. What do you think the next guy is going to say about your code? Do you really think they're going to praise the excellent code quality? Or will they declare to all around that it all needs to be rewritten because it doesn't conform to the newest flavor of the month? I absolutely and unequivocally agree with the author: People declare everything around them as shit to prop themselves up, and the explain their own inadequacies in advance. There is shit code, granted, but by some measure of shit all code is shit. A viewer can destroy code as over or under engineered, over or under built, over or under abstracted, over or under object-oriented, over or under functional, and on forever, and anyone who thinks there is an actual right way in any reasonably complex system is demonstrating profound naivety. The one thing that I will disagree with in the submission is the notion that this is a new or increasing pattern. It isn't, and has been the norm for decades. This is what developers do, especially those who are weak at reading code: Declare it shit in advance and just write your own.

bowlofpetunias 13y ago
Maybe I haven't been entirely clear. I'm not talking about a mismatch between approach (over- or under- whatever) and goal. I'm not talking about quick hacks that were never refactored (because of course, there never is time). I'm not talking about code that has gone through many cycles of unpredicted change and has acquired many layers of cruft. I'm not talking about code made by inexperienced developers who still have a lot to learn. I've seen all that. I've written all that. I've left code behind I would be embarrassed to show in public. I'm shocked some of it is still in use, and I'm sure people who have to maintain it will curse my name. That is part of the job. What I'm talking about is pure, unadulterated shit code. No structure, no logic, no consistency and barely functioning only under very limited conditions. Utterly incomprehensible unless you immerse yourself deep into the mind of the author like an FBI profiler and a serial killer. No, there is no one "right" way of writing code, but boy there are an awful lot of "wrong" ways.
- kabouseng 13y ago
  I would suspect that such practices are more prevalent in the web development world. Enterprise software and embedded development (my focus area) suffers far less from the pure unadulterated "shit" code pattern. Mostly I suspect that is because the software development practices such as code reviews and coding standards are actually enforced.

nyrina 13y ago

I'm just going to ask the question... What do you think makes your code good? I bet the next guy that comes around in 15 years and reads your legacy code (Grats on having code actually runs for 15 years!) will think it's the worst piece of shit ever created and are sure to think you are one of the worst developers in the world.

loup-vaillant 13y ago
> What do you think makes your code good? Answering for myself: (1) it's short. Often significantly shorter than my colleagues'. (2) it has few bugs, if our bug tracker is to be believed (I reckon I'm not very confident about that one). On the other hand, I tend to be slower, especially when I have to write against less than optimal APIs.
- solistice 13y ago
  But short code isn't necessarily a garrant for good code. I went through a teenage phase where I would strive to write the shortest code possible. It's cringe worthy, and working my back into it seems scarce impossible. If you drew out the program logic, it'd look like an Eldridge terror. It just isn't good code. But yes, if you're writing War and Peace in order to parse XML, it's unlikely you're writing good code.
  - loup-vaillant 13y ago
    I try to write the simplest code possible. It always end up being shorter than if I didn't. Also, of two okay-looking pieces of code, I noticed that the shortest is almost always the simplest. Which makes size a pretty good metric.
RogerL 13y ago
Why would you bet that? We have a broad understanding of how to structure and write software. These ideas have been collected together in books. I refer to books like Code Complete, Debugging the Development Process, Clean Code, Refactoring, Programming Pearls, Beautiful Code, and so on. Then there are the language specific books. I don't believe you can craft well written C++ without reading Scott Meyers' books (or having absorbed the same knowledge from others), for example. Even the much maligned Design Patterns, which has been turned into the truly dreadful design by pattern, helps us to think about how to structure code. I can't type it all in a post. But we are talking about modularity and extensibility. Decoupled code, so you can make changes here that don't break something over there, and so you can easily move code from one project to another. Well commented code - where 'well' means the author takes the use of the code into account - some deeply internal function named ComputeAverageSalary probably doesn't need much in the way of extra comments, anda top level api call to a framework being used by thousands needs a lot of documentation. Well structured code. The if statements make sense. They are not deeply nested. logic is not duplicated, or contradicted when it is nested, because that always leaves you scratching your head as to the purpose of the author(s), and clueless as to how to add code. So, back to the question, why would you bet that? I've opened plenty of 15 year old code that is good to beautiful. This is not an arbitrary judgement of "oh, OO good/bad", nor an reactionary "it wasn't written by me, so it must be bad". I do consider myself a pretty clean programmer, but I learned it by observing the code of others, reading a lot of books, and relentlessly applying a critical eye on everything I write and others write. All borne not on some arbitrary judgement, but from recognition of how quickly/slowly I can grok a piece of code, how easy it is to find and fix bugs, how easy to add features, and so on. In some code bases that is all fairly straightforward, and in others it is impossible - any fix or change has so many side effects that you need to add 50 if statements strewn about 50 files, in code already filled with if statements, and your if statement break about 15 undocumented assumptions about the behavior of the tightly coupled code.... that, my friends, is shit.

anExcitedBeast 13y ago

Shit is useless, destructive and smelly. Unrefined code by an unrefined developer often works, but not as well as it can and is usually difficult to work with. Big difference. Just like most of the stuff reddit calls "epic" or "mind blowing" is often simply 'neat', most of the code you call "shit" often simply 'could be better'. The tendency to call unrefined code "shit" intimidates new coders and disincentivizes people from contributing to community projects.

nilkn 13y ago

If the majority of code is shit, then it's not really a very useful observation to make repeatedly. So I think this goes back to the author's point that this is really a cultural or attitude issue. It's like the friend who complains about everything all the time: constantly complaining about traffic, about the weather, about how the city is losing its charm, about his job, about his classes, about his parents, about his car, about his apartment, about politics, about how stupid people are, etc. etc., with nothing positive to say. Maybe it's all correct from some perspective, but it's not a very useful perspective and it's definitely an annoying one to be around.

Jach 13y ago
There is at least one useful implication to the observation, and that's that most (or all) software is shit. Yet people still use and buy it. The implication is a nice three-edged sword. You're guarded against crippling perfectionism, you're striving to get out of the shit as much as you can, and for developers you will always prefer having the source if you want to fix some shit. This article made me remember this from my quotes file: "All software sucks, be it open-source [or] proprietary. The only question is what can be done with particular instance of suckage, and that's where having the source matters." --viro
- RogerL 13y ago
  That is not my experience. There is a ton of good to extremely good code out there. I'm rather dismayed by the amount of "well, what can you do" hands-thrown-up attitude here. I've always found clean code to be faster to develop. I find that developers that produce lower quality code tend to spend their days debugging, fighting their code, reading and trying to figure out what they wrote 5 months ago, and so on. They are just not very productive. There are the outliers - people that have instant recall of all their code and elaborate mental models of really poorly structured code - but by and large I find that people that generate low quality code are quite slow performers. I've worked in very good code bases, and very bad ones. In the good ones you can easily figure out what is going on, quickly make changes, confident that you aren't breaking 5 things because things are decoupled. You can produce new code quickly because you aren't fiddling with code nested 6 if statements deep, which is just about impossible to model correctly in your head. You aren't in endless compile/run/debug (or REPL/run/debug) cycles because your first try is usually just about right, because you can understand the surrounding code. I recently requested a simple feature, and was told it would take a week. I was dubious. Then I looked at the code, and decided that they were being conservative, if anything... for something I thought would reasonably take a few hours. This is just an impassioned plea, not to Jach, but to the profession, to cast a critical eye on code. You can produce high quality code quickly. Not "nuclear reactor" quality, but pretty close. Bad code always costs you. Always. Don't write that way, don't allow it in your code base, or in your teammates.

zeteo 13y ago

>I've been in this business for over 25 years [...] The difference between shit code written by shit coders and less than optimal code written by good coders dealing with constraints is quite clear. [...] Most code out there is shit code. Denying it is not going to help either. I'm sorry, I respect your experience but this post is completely uninformative. It's much more specific on how awesome you are than on how to distinguish between "shit code written by shit coders" and "less than optimal code written by good coders"; not to mention dealing with and improving either. It's possible to spend a long time in an industry and accumulate much unfounded prejudice along with solid knowledge. As long as the appreciation of "shit code" and "shit coders" remains subjective, it's virtually certain you'll also be considered one someday, when the prevailing paradigms and fashions change again.

solistice 13y ago
I think it's a bad case of "dislike due to knowledge". It's stark in the arts, but it applies to almost every human endeavor. As an example in the arts, I dance, and I'm good at it according to almost everyone who sees me dance. But I see myself as a terrible dancer. If I make a video of me dancing, others see every part that's well executed. I'm accustomed to them, and I tend to ignore those parts in favor of every part that's sloppy, every part that just doesn't look right. And it's no different for code. You know what one of the marks for good code is? If the guy writing it is tearing it apart in the comments. Where do you see /* This is a dirty hack I'm ashamed of */? Usually right next to stuff that's a stroke of genius, or at the very least really good code. It's strange that the more you know about something, the less comfortable you get with your knowledge, but it seems almost universal that "Ignorance is bliss", or rather the corollary "The more you know, the less you think you know".
- deleted 13y ago
  [deleted]
- Djehngo 13y ago
  I do like code which has comments which describe the level of confidence the author has in some sections (I feel a happier refactoring code which is marked as being suboptimal). But in my experience those comments are usually found above cases where it's possible to make a fix in one line rather than one hundred. (sleeping a thread for 0ms rather than re-architecting a gigantic callback structure).

weavie 13y ago

It depends on what you mean by shit code. Is code that was written on time and on budget - but has a few hacks in it shit? Is code that is beautiful and easily maintainable, but was £1m and six months over budget not shit?

chriswarbo 13y ago
Shit code is the third option: Code which was late, over budget and completely unfit for purpose, requiring an army of temp workers to process everything manually while another team come in and spend months on a death march trying to fix it, while the business is hemorrhaging money via lawsuits from pissed off clients with violated contracts.

username42 13y ago

My job is "first level support". I have to analyse problems reported by users and often to read source code to find bugs. I have seen a lot of shitty code and a lot of very clean code, but most of the problems come from shitty specifications. When the requirements reflect a poor understanding of the users need (or a poor sense of logic), whatever the qualities of the developer, the resulting code will always be a maintenance nightmare.

mgkimsal 13y ago
The developers should be able to push back on some of that - and at least document in the code that certain logical inconsistencies were raised but glossed over. Simply understanding that something will be a maintenance nightmare should inform a developer enough so that they, at the very least, leave useful info/docs about what corners were cut and why. Until you've had to deal with mountains of various legacy projects completely undocumented, you won't even know this is something you should be doing.
sitkack 13y ago
I always thought 80% of coding (solving anything really) is understanding the problem. The other 50% is implementation.

AznHisoka 13y ago

You're assuming all code is written in a vacuum. Sometimes developers are forced to write code under unrealistic time constraints, or they were told to prototype it quickly b/c we'll replace it later (but they never get the time to), and so on.

lnanek2 13y ago

Agreed. Hell, most of my code lately has unit tests and UI automation tests and goes through code review and adaptions for a week after writing and it is still pretty shitty and needs to be tweaked later and will always be a crappy code by committee result by the end. Just getting it into production is a grueling battle that sucks out the most idealistic souls and makes most into code monkeys just trying to hack something out. But hey, if I was coding for a startup lately all of my code would be shit because of long hours and no tests since most of the time we're just writing experiments we'll throw out later so why test?

kyllo 13y ago

There's also the issue that most enterprise code is shitty by design. Tight deadlines and budgets, no time to write tests, project scope too large, too many features, too many developers on the same project, too many meetings and standups, poorly described requirements from Product, UML written by business analysts, overuse of patterns, Spring and other overkill frameworks, etc. To err is human; to really screw up takes a committee.

riggins 13y ago

"Most code out there is shit code." semantic point. if you're saying 'most code' is shit, aren't you saying average code is shit? Kind of like saying a 6 min mile is shit because it's not a 4 min mile.

sitkack 13y ago
No, a 6 min mile is not average. And yes the average of most things is shit. Shit isn't bad (unless it is), it is the output of useful work usually. It just needs to be covered up and stayed away from.
- riggins 13y ago
  This reminds me of how pretty much everyone believes they're a better than average driver. Everyone also thinks other drivers are terrible. Both claims cannot be true. I'd say its appropriate to call 'most/typical code' average code, not shit.
  - corresation 13y ago
    Exactly the analogy I went with. "Everyone is a shit driver" claims almost universally come from terrible drivers: When you have no situational awareness and aren't actively predicting the behaviors of drivers around you, and you don't have confident control of the tools at your disposal, every move that other drivers make seems dangerous and scary, needing panicked reactionary responses. Every trip is a perilous journey with tales of imminent death. I honestly feel the same about people who walk around declaring all code shit. People who aren't competent with their development tools, can't naturally trace code and truly understand functionality, and can't adapt to different styles and era of code tend to be the ones, in my experience, that declare all code shit.
- dragonwriter 13y ago
  > Shit isn't bad I would suggest that this indicates that your figurative use of "shit" is not the common figurative use of the term in the phrase "shit code", which is impairing communication.

DominikR 13y ago

So what exactly is the point you are trying to make here other than that you are the smartest guy? The article is not about the existence of shit code, the amout of shit code produced per year or how much shit code the average developer will see in his career. It is about teamwork, and what kind of culture poisons the atmosphere in a company. Not about shit code, which by the way everyone here has produced at some point or to be more realistic about it (since usually developers look at their old code and think it is bad) - is still producing on a daily basis.

jasonlotito 13y ago
> So what exactly is the point you are trying to make here other than that you are the smartest guy? He took the one thing he could make an easy, pedantic point about and posted it. It's easier to do that and get free karma that actually be mindful. It's low hanging fruit. Just like I could find errors in his comment that would serve no purpose. At issue is, while his point might be technically correct, it serves nothing other than to encourage "Me too" replies. This happens frequently on HN. I encourage you to down vote such posts.
chriswarbo 13y ago
The first step to solving a problem is admitting that there is one. I remember debugging some AJAX code once which was racing with itself. It took a lot of mental effort to work out what the existing code was meant to be doing and what it was actually doing, both of which were wrong. At it's core was a simple jQuery AJAX call with a success callback (no error callback, of course), but interleaved through it was a mess of global variables ("finished_yet", "time_last_checked", etc.), busy-loops, manual timeouts, state-rollback functions, etc. What I would call shit code. Once I finally understood what it was doing enough to refactor it I managed to delete most of the file and replace it with a "latest_id" counter which incremented on each call, with the success handler skipping if its ID wasn't the latest. Simple. I approached the developer responsible for the original, to show him what I'd done and explain how Javascript's scope let each call have its own ID. His response was that I'm using obscure language hacks which nobody is going to understand when they have to maintain it, that I should stop trying to force everything into a few lines and that he doesn't need to learn about Javascript's scope because he can already program so learning anything else is a waste of time that could be spent coding. I got told a similar thing during a code review as well, since I'd used map on an array. Needless to say, I didn't stay there long. Now that is a cultural problem, which can only be solved by pointing out shit code (although in a more polite way). Some people are so stuck in their ways that they don't care about improvement because they see their stuff as 'good enough'. In those cases, they need to be shown that no, it's not good enough, because XYZ. I wasn't trying to gain points on anyone; I was just frustrated at the utter lack of care about the codebase we all had to work on. Whenever I spotted anything particularly WTF I'd send out a "Code of the day" email. My favourite is still this one: <td> blah blah blah </td style="....." id="foo" class="bar baz">

moron4hire 13y ago

For me, the tell-tale sign is a demonstrated lack of understanding of type theory. Like calling toString on string objects. Or even worse, calling parseInt on a string that was created by calling toString on an integer! Also, comments-used-as-source-control. If I see one more gigantic block of code commented out with a set of initials and a date "this was removed by/on". Use the source control to do that, dammit.

slewis 13y ago

Sure, there is some really bad code out there. But even pretty good code looks really bad to a lot of developers, because of the "This is shit" mentality the article describes.

mcv 13y ago

In my experience, shit code tends to start with a competent developer solving a problem in a way that seemed reasonable at the time, and then requirements changing, new features getting added, and everything is in a hurry so it never gets refactored. Well, sometimes I do see code that's really very bad and I can't imagine how someone was ever able to type something like that, but that's rare. Usually it's competent people with the best of intentions but as lack of ability to predict the future.