14 ms·

A Million Lines of Bad Code

175 points by var_explained 11y ago

woliveirajr 11y ago
Thought his was talking about win95 or win98...
- kenrikm 11y ago
  Windows ME? In all seriousness I've witnessed people shame over bad code, yet later when other people looked at their code was just was bad. We all write bad code, hopefully we're able to make it less bad the more we write it.
  - woliveirajr 11y ago
    :) think you're the only one that could find the irony out of it!
ianstallings 11y ago
You have to have thick skin in the programming industry. Because you're surrounded by what might be the world's worst communicators, programmers. We can tell the machine exactly what to do, but our social IQs tend to suffer on the whole.
- Zelphyr 11y ago
  Not to mention we're told from a very early age how smart we are so inevitably we begin to not only believe it but also believe we're smarter than everyone else. Here's a hard-earned lesson for any newly-minted developers out there: Yeah, you're smart. But not as smart as you think you are. And regardless, it doesn't give you license to treat anyone poorly.
- serve_yay 11y ago
  Worth remembering that there are two ends to every communication, and either end can screw up.
- CMCDragonkai 11y ago
  Not very smart if you can't communicate.
stuff4ben 11y ago
I'd hate to see my old VB4 code I wrote back in the day. I'm sure I did worse, except at the time I thought I was a rock-star. Of course it was the late 90's and everyone who had a compsci degree was a bad-ass developer no matter what language you used or how many bad lines of code you wrote.
ExpiredLink 11y ago
> Building a string with a series of concatenations like this is extremely inefficient No. Not in Java since 1999 or so.
- hmottestad 11y ago
  I built a string this way in java just 5 years ago. Still made it 100x times faster by using a StringBuilder.
  - reinhardt 11y ago
    So like 1ms down from 100ms? Either way a rounding error in the episode-of-LOST-average-duration timescale ;)
    - hmottestad 11y ago
      Why don't you give it a try yourself. Create a file with a high ratio of lines to length, and read it in using a loop and string concat, or builder. Do it with a builder first, when you get up to 1 minute, switch over to concat and see how long it takes.
- Tossrock 11y ago
  Factually incorrect. Creating new strings by concatenation requires reallocation because Strings are immutable in java. Using a Builder is over 700x faster: Concat code: http://pastebin.com/CcezmJbf http://pastebin.com/CcezmJbf Builder code: http://pastebin.com/Dd6kzcKa http://pastebin.com/Dd6kzcKa Results, using JRE 7: > time java concat data.blk Finished. java foo data.blk 170.08s user 1.52s system 102% cpu 2:48.12 total > time java builder data.blk Finished. java builder data.blk 0.30s user 0.05s system 151% cpu 0.230 total
  - Sevzinn 11y ago
    What about the time to write the program?
swalsh 11y ago
I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school. But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enough if you follow it with a "but". "Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work" will get better results then this "Hey pretty cool program, but you're reading in files wrong" which even that is better than this "You're reading in files completely wrong, try googling for a better solution" which unfortunately among engineers seems to be the most common reply.
- cperciva 11y ago
  "Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work" I usually hear this referred to as a "criticism sandwich": Criticism surrounded on either side with compliments.
  - bstamour 11y ago
    In the martial arts community we call this "praise, correct, praise."
    - gagege 11y ago
      What's weird is that even though I know this is a "trick" I still want people to talk to me that way unless I specifically ask them for the hard truth.
    - artursapek 11y ago
      Programmers tend to incline towards efficiency. I think that's why we often skip the bread and deliver only the filling. IMO there's a big difference between a criticism sandwich and tactful criticism.
tanglesome 11y ago
That's all true, but the cartoon is still funny!
Zelphyr 11y ago
Code is art and every artist wants to go back and redo their bad works[1]. But the best thing to do is learn and move on to create better art. 1: https://www.yahoo.com/movies/bp/steven-spielberg-finally-admits-walkie-talkies-were-mistake-142746809.html https://www.yahoo.com/movies/bp/steven-spielberg-finally-adm...
kstenerud 11y ago
I kept some of my original bad C, asm, and REXX code back from my high school days after I finally moved on from BASIC in 1991. I pull it out from time to time for a quick chuckle.
JoeAltmaier 11y ago
Not quite right. All the code I wrote last year looks bad to me; naieve, clumsy, artless. Because I have learned so much since then. It never gets any better. Not because I don't get better; because I DO get better. I've been writing code since 1976.
- losvedir 11y ago
  I hear this sentiment a lot (and notice it in myself, though I have a lot less experience so it hasn't been as long running), and it worries me. Are you sure it's better? Are you keenly aware that there are no, say, cycles in your coding approach? I know this year I look back at last year's code and go, "oh boy, why'd I do it that way?" And I feel like it's better, but I'm always a little afraid I'm just chasing novelty. Not sure how to objectively know if it's better.
  - aidenn0 11y ago
    Don't forget also that familiarity makes things seem more clear. Code you wrote yesterday needs to be particularly atrocious for you to find it hard to understand. Code you wrote a year or two ago might as well have been written by a stranger (really memorable hacks aside). Perhaps look at code from 2 years ago and 3 years ago, and if possible blind yourself as to which is older, and rate each one.
    - JoeAltmaier 11y ago
      I'm pretty sure I remember my code. I agonize over it, put all my effort into it. I remember code I wrote in the '80. I remember the code I wrote 7 years ago, and refactored last year. Code is my life. I've had that sneaking suspicion that maybe I'm not really getting any better, yes. But I have independent corroboration - I've worked with another guy for most of that time, and we've got one anothers' code to look at. What one of us learns, the other learns too. He's not cycling, or just writing bad code. And he says the same about me.
angersock 11y ago
I think this is reasonable, but at the same time, please get those million lines out of your system on somebody else's project. If that can't be done, if you can't spend your free time honing your abilities, then accept helpful feedback from other more experienced developers. Don't just accept feedback--assume your code is garbage, and ask how you can make it better. If the answer eventually becomes "it's good enough for business purposes", then find out why that is, and learn from that. Communication is hard, and explaining why a codebase is just wrong can be as difficult as explaining to somebody why you find them abrasive. At the same time, it's the job of senior engineers to make the effort and try. Sadly, in a startup environment, it's usually smarter business-wise in the short-term just to sack the inexperienced developers or railroad them into simpler work that they can't screw up, and kick the can down the line.
naiyt 11y ago
I remember reading some advice like this around the time I started programming. It was something along the lines of "every dev has XXXXX lines of bad code in them, so write a lot of code to get them done with!". (I think it was from Joel Spolsky, IIRC.) It helped motivate me to just write a ton of code, even early on when I didn't really know what I was doing. Just writing a bunch of code without worrying too much about if it's "right" or not is really important, at least early on. I think I write better code now because I spent so much time just writing stuff early on, and learning from my mistakes. That, along with some good mentors helped me so much more than the people that merely criticize you because of your code. I definitely agree with this article.
kctess5 11y ago
1000000 lines of bad code is a bit of an exaggeration. Many (most?) programmers never write that much code in their entire careers. I've heard 10000 LOC as a milestone for REALLY learning a language (once you're familiar with programming in general), I'd say it's on that order of magnitude for writing non-terrible code in general.
- var_explained 11y ago
  It's just a figure of speech, and catchier than 10K.
- StillBored 11y ago
  The problem is that a lot depends on what kind of problem your solving, and whether it varies a lot. I've written ~10k lines of python (single small project). But, I'm still at the point where it seems every other line requires me to google something, and i'm sure normal python people would snicker at the result. OTOH, I've probably written close to 750 (maybe a million, aren't small companies cool!) lines of C/C++ over the last 20 years and that is probably not enough either. Although I rarely even have to think about the code, rather i'm totally working at the algorithm/interaction level and the text pops out of my fingers. I would say 10k is enough that you can put it on your resume... But, even that is probably way less than the average comp-sci graduate writes. So, I would still consider it a starting point. Especially, since reading other peoples code is just as important a skill, and that isn't something generally picked up in school, or on little weekend projects using a new language. But again, it depends on the breadth of the problems being solved. We hired a web developer a couple years ago, who in the space of about a year wrote ~150k lines of PHP and javascript, and got a _LOT_ better at it, but he solved most of the problems the same way and there was a metric ton of duplicate code, and imprecise problem solving (AKA problems solved in the most roundabout way). Over the last 2 years I've probably only written about 50k lines of PHP/Javascript but I've added about 20x the functionality he added. So, I would say that i'm better now than he was when he left, but i'm still not really that good.
eonw 11y ago
good read, thanks for posting.
jackreichert 11y ago
More important than good code is shipped code. I'd say about half my bad code is due to inexperience, what the post is referring to. As time goes on it DOES get better, especially since -- like most of you -- I'm constantly reading and trying to improve my skills. The other half of my bad code is due to time constraint. This is either because a quick hack is needed, or the proper planning time is not allocated to do a proper job. This leads me back to my initial statement. Sometimes you just need to get the job done. If you're not good enough to do it right, but you hack it and it works, that's good enough for now. This is how systems get built poorly and bloat up, but there are deadlines and requirements that need to be met, and if you never ship, you'll never get the budget to rebuild that old system you allowed to get unwieldy. It's a constant struggle to balance quality, functionality, and deadlines.
- kgabis 11y ago
  https://i.imgflip.com/kc24o.jpg https://i.imgflip.com/kc24o.jpg (Sorry for commenting in a form of a meme, but it really was asking for it)
  - jackreichert 11y ago
    Very valid point. But not every product, as much as the stakeholder would like to believe, is a space shuttle.
cubano 11y ago
If only my clients and recent bosses would consider refactoring a valid billing line item... I can only imagine sending an invoice today to my three top clients with "5 Hours Refactoring Bad Code That is Working But Could Be Better Looking....$400". There is just no way I would get paid. Unfortunately, I have interests outside of working on code that mostly preclude me from sitting for hours happily breaking-and-then-refixing code that is currently working ok and that I cannot bill on. Hell, just keeping up to date with the unreal pace of change that is occurring in software right now is almost a full-time job in itself, much less fixing old stuff that is going to go away soon anyway.
- gknoy 11y ago
  Would it work to say, "Added test coverage, refactored code to increase future maintainability"?
  - therealwill 11y ago
    Client: "Send us some screen shots of the new features." You: "Err..."
- aidenn0 11y ago
  Solution A is obviously to educate them: $400 as time spent to make adding the next 10 features cheaper. Solution B is to refactor some fraction of the code you interface with when adding a new feature. So it's "X+2 hours adding new feature" when you spent 2 hours refactoring code that feature X needed to deal with. As far as the ethics of Solution B, then if your refactoring is actually improving your net productivity, then you truely are doing necessary work towards adding the feature (just as you would bill tests or build scripts needed for the feature along with it). If it isn't improving your net productivity, then why are you doing it?
- Cthulhu_ 11y ago
  How about "I did my job, and if you ask me to specify how much time I spent on testing and refactoring, you're a micromanager and you're redundant because you obviously have nothing better to do"? As a developer, you need to take your own responsibility for the code and product you create, and be proud of it. Besides, it's a fallacy that time not spent on code quality would lead to more features / a better product.
steakejjs 11y ago
What if you are an experienced engineer talking to another experienced engineer ? Seems to me if someone writes bad code when they SHOULD be writing good code, code-shaming might be in order. I'm all for being nice and understanding. Everyone programs at a different level and I may not write code that is as good as I think, but some code is just obviously bad...and constructive criticism (if willing to be accepted) might help
serve_yay 11y ago
Yeah, you shouldn't shame people because their code is bad. But the other side of that is when someone says your code is bad you don't take it personally. There is more than one way to not be a nice person. Just think, if everything is pretty good and isn't that bad and doesn't need that much improvement, why should anything ever get any better, ever?
dap 11y ago
There are some useful ideas here, and public shaming per se probably isn't the answer. But publicly talking about bad code, and the properties of code that makes it bad, is an important way to socialize what makes good code, plus the meta fact that code quality is important. To the extent that the aphorism about writing bad code is true, I think it's just another way of saying that people's code improves with their coding experience. I really don't think you need to write bad code _in order_ to learn to write good code. It's hard to know for sure, but I think the most positive influence on my code quality was _reading_ lots of very good code, not having written bad code. (It's the same with my writing, too.) [Edited for clarity, ironically.]
dvirsky 11y ago
I have here some 10 year old C++ code I've written lying around. It's pretty terrible style-wise, but not as bad as I imagine it to be without looking at it. But the main point is that it worked in production for years. I would have written it much better today, and it will probably work faster and be easier to maintain. But it would also probably take longer to develop (though less time to debug and stabilize) - and ultimately, it would do the same work in production. I'm not saying that improving your coding style and skills is not important. Just that we need to keep our eye on the ball - which is delivering working software, not code.
alarge 11y ago
I'm not a real fan of assigning a context-independent global value label like "good" or "bad" to code. While there probably are examples of truly "bad in all respects, in any context" code, the vast majority of code that I've seen tends to fit more into "<this attribute> of the code could/should probably be improved when using it in <this context>". I find that viewing (and discussing) code this way has a lot of benefits: * It is really hard for a single global negative value judgement made about code to not be taken personally by the person who wrote it (e.g., "your code sucks" == "you suck"). This is much easier to avoid when talking about attributes of a thing, since (a) it comes across as more objective than subjective, (b) gives plenty of opportunities for acknowledging aspects of the code that _don't_ suck, and (c) lends itself to much more of a "give and take" discussion. * It gives you the opportunity to talk about "figures of merit" and trade-offs that are the reality of engineering, but rarely taught in schools (e.g., readability/development cost/flexibility vs. performance, etc.) * It gives you a framework for explaining why things like idiomatic style, "principle of least astonishment", and general elegance actually contribute to code quality (and aren't just excuses for subjective attacks).
michaelochurch 11y ago
Bad code is a great wedge for business people to get programmers obsessed with individual relative ranking and prevent any sort of collective action. I certainly had jobs in the past where I got angry over bad code when, in fact, I should have been bad at the businessmen making me use the bad code (instead of putting time on the calendar to write things properly) and setting the deadlines that caused the bad code. For sure, there are some sloppy, borderline-unethical engineers who write shitty fast code to get promoted away from the maintenance messes they generate... and there are definitely some incompetent engineers. For the most part, though, bad code is a symptom of bad leadership rather than bad programmers. Under a tight enough deadline, everyone's code will be shit. And, of course, it goes without saying that the proper response to bad code isn't to flip out on the person, but to teach him how to do it better. One of the reasons why I like using high-productivity languages like Haskell rather than Java is that it selects for people who genuinely want to improve.
autoreleasepool 11y ago
I don't see anything wrong with the "mean-spirited" humor in the XKCD comic. The cartoon is funny. It's supposed to be a joke. Anyways, it's not like those remarks are directed at anyone in particular -- just a fictional stick figure. I don't have any ethical qualms about laughing at his expense.
- chasing 11y ago
  You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-) That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are shitty at it. In fact, I'm almost always very impressed with people who are not professional coders but who have taught themselves a few coding skills in order to solve some problem or to actualize some idea -- even if the code itself is horrific from a professional standpoint. That's awesome! And if they want help, I won't mock -- I'll help! It's a rare opportunity to really show someone why I find the act of programming to be so fascinating and satisfying.
  - autoreleasepool 11y ago
    > You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-) Not sure what you're trying to say here? Its a cartoon about a stick figure who can't code. Funniest part was "it's like someone took a transcript of a couple arguing at ikea and made random edits until it compiled without errors" lol > That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are shitty at it. I understand that you feel passionately about this, and I agree wholeheartedly that non professionals should not be mocked. That said, I dont think that's what's going on here. What we have here, is a cartoon that's poking fun at an exaggerated circumstance. No individual or group is being (sincerely) called out or told they shouln't try to learn to code. It's all just a joke, for amusement. Its like saying Peanuts is mean spirited for mocking people with poor hygiene with the character Pig Pen: It discourages those people from leaving their homes and interacting with people. I should instead encourage those with poor hygiene to pick up that bar of soap and go outside! ... But that's silly, right?
ereyes01 11y ago
I agree that mean-spirited feedback is not helpful/constructive. I can see how that would discourage someone who is new to programming. In fact, "feedback" is probably not even the correct name for that... maybe "bullying". However, I have to disagree with the notion of having to write a lot of shitty code to learn to write good code. Granted, that is one way to learn, but not nearly the most effective way to learn. For years, when I started my career, I wrote lots of shitty code. I feel badly about having done this because I unwittingly caused quite a bit of havoc in the products I was working on, and even pissed off a few customers along the way. Writing shitty code can have really bad effects on a team and on a product. Fortunately for me, I eventually ended up working in an extremely talented team. They were not only talented at programming, but also highly skilled at teaching others good programming. Their method was simple- they accepted nothing that failed to meet their high (and documented) standards of readability and testing, but were extremely thorough in spending time showing you what you did wrong. They were never demeaning and always constructive- they always had a high level optimism in every new-comer's potential. Given enough time, it was clear that some new team members weren't going to work out, but those who had it in them to patiently improve their skills flourished and enjoyed very successful stints with this team. After a rough first few days on the team, I heeded their warnings and agreed to check my misplaced ego at the door. Then, and after a couple of months of embarrassing ineffectiveness, I gradually became a better programmer and went on to become a great team member. I'm really grateful for the patience these guys had with me and the other noobs. They really made a difference in my career and in the career of my peers!
- FLUX-YOU 11y ago
  This kind of thing can really have an effect on your career in the immediate future. There are a lot of expectations that people come up with regarding what you should know by X years into your career and people judge you pretty strongly on this. I personally don't get any feedback on my code and I don't really have time to police myself on it. I end up blending in with the conventions I see in whatever current document I'm working on (e.g. presence of type prefixes, casing style, underscore usage). I always thought this was bad practice in the general population but I guess I get paid for it. We aren't going to raise the industry-wide skill level if we let people figure it out on their own the hard way. That's valuable up until a point but eventually they should start wanting to know what the effective way of doing X is (if it exists). Individuals take a long time to arrive at an optimal point with that stuff, and may never even reach it. I'm fairly sure NASA doesn't let staff (astronauts especially) in training learn everything the hard way. Imagine if your workplace maintained something like this: http://llis.nasa.gov/ http://llis.nasa.gov/
moron4hire 11y ago
This is why my handle is "moron4hire". It's supposed to be a daily reminder to myself that I'm not that hot.
killertypo 11y ago
one of my first projects as a consultant fresh out of college was HORRIBLY coded by my standards today. Sometimes I still fire it up and it still works (which fills me with pride); however, perusing the code hurts my eyes and I often wonder what was going through my mind.
tatterdemalion 11y ago
> So I wrote a Perl script that read in the file, combined it, and printed it out as a single line. Then I had my Java program call the Perl script through the command line, capture the printed output, and save that as the string. When I first started (in Python), I didn't understand what a function was, but I wanted my program to react differently depending on user input, and had some conception that I should be breaking my program up into files by purpose. So what I did to get it working was this: I named each file "$cmd.py", then I concatted the user's input with ".py", opened & read the file with the associated name, and ran the resulting string through exec() !! I came to this result incrementally by googling different aspects of the problem that I didn't know how to describe properly. If someone had been a jerk to me about it then, I probably would've been really self-conscious about it. But no one was a jerk, so I'm not ashamed: what I did is ridiculous and funny & I'm glad to be able to laugh about it now.
- aw3c2 11y ago
  The result was still great though, wasn't it? You made the computer do what you wanted and it was probably better than doing it by hand.
everyone 11y ago
The xkcd thing is just one webcomic, I reckon it is just a joke and probably Randall Munroe did not consider its implications or think it would be taken seriously. Though xkcd is really popular and probably is relatively influential (especially in programming circles) That being said, I totally agree with this article. Also 'read a style guide' is one of the worst possible suggestions I could think of. Style is just style. Its one of the least important things I could think of. It depends on your work situation but in many cases why not just go with whatever style you are happy with personally and makes sense to you.
halosghost 11y ago
This times a million. I love helping people to learn C, for example. And the thing I do most other than basic instruction is helping to keep their spirits up and reminding them that refactoring is the most important part of coding.
hnal943 11y ago
There's a difference between practice and mere repetition. You wouldn't get any better at speaking Russian if you just spoke gibberish, even if you did it for 10 years. You need to know what improvement looks like.
eduadecastro 11y ago
Shouldn't the compiler recognize this as an append instead of copying every time?
- TheLoneWolfling 11y ago
  It should. But the Java compiler punts everything to runtime, and the JVM doesn't optimize it either.
based2 11y ago
Why not use Findbugs[1] by default, it is now well integrated in major IDEs? [1] http://findbugs.sourceforge.net/ http://findbugs.sourceforge.net/ [2] http://softwarerecs.stackexchange.com/questions/2902/static-code-analysis-integrated-with-github http://softwarerecs.stackexchange.com/questions/2902/static-... [3] https://github.com/LMAX-Exchange/freud https://github.com/LMAX-Exchange/freud [4] http://spoon.gforge.inria.fr/ http://spoon.gforge.inria.fr/

175 points by var_explained 11y ago

woliveirajr 11y ago

Thought his was talking about win95 or win98...

kenrikm 11y ago
Windows ME? In all seriousness I've witnessed people shame over bad code, yet later when other people looked at their code was just was bad. We all write bad code, hopefully we're able to make it less bad the more we write it.
- woliveirajr 11y ago
  :) think you're the only one that could find the irony out of it!

ianstallings 11y ago

You have to have thick skin in the programming industry. Because you're surrounded by what might be the world's worst communicators, programmers. We can tell the machine exactly what to do, but our social IQs tend to suffer on the whole.

Zelphyr 11y ago
Not to mention we're told from a very early age how smart we are so inevitably we begin to not only believe it but also believe we're smarter than everyone else. Here's a hard-earned lesson for any newly-minted developers out there: Yeah, you're smart. But not as smart as you think you are. And regardless, it doesn't give you license to treat anyone poorly.
serve_yay 11y ago
Worth remembering that there are two ends to every communication, and either end can screw up.
CMCDragonkai 11y ago
Not very smart if you can't communicate.

stuff4ben 11y ago

I'd hate to see my old VB4 code I wrote back in the day. I'm sure I did worse, except at the time I thought I was a rock-star. Of course it was the late 90's and everyone who had a compsci degree was a bad-ass developer no matter what language you used or how many bad lines of code you wrote.

ExpiredLink 11y ago

> Building a string with a series of concatenations like this is extremely inefficient No. Not in Java since 1999 or so.

hmottestad 11y ago
I built a string this way in java just 5 years ago. Still made it 100x times faster by using a StringBuilder.
- reinhardt 11y ago
  So like 1ms down from 100ms? Either way a rounding error in the episode-of-LOST-average-duration timescale ;)
  - hmottestad 11y ago
    Why don't you give it a try yourself. Create a file with a high ratio of lines to length, and read it in using a loop and string concat, or builder. Do it with a builder first, when you get up to 1 minute, switch over to concat and see how long it takes.
Tossrock 11y ago
Factually incorrect. Creating new strings by concatenation requires reallocation because Strings are immutable in java. Using a Builder is over 700x faster: Concat code: http://pastebin.com/CcezmJbf http://pastebin.com/CcezmJbf Builder code: http://pastebin.com/Dd6kzcKa http://pastebin.com/Dd6kzcKa Results, using JRE 7: > time java concat data.blk Finished. java foo data.blk 170.08s user 1.52s system 102% cpu 2:48.12 total > time java builder data.blk Finished. java builder data.blk 0.30s user 0.05s system 151% cpu 0.230 total
- Sevzinn 11y ago
  What about the time to write the program?

swalsh 11y ago

I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school. But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enough if you follow it with a "but". "Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work" will get better results then this "Hey pretty cool program, but you're reading in files wrong" which even that is better than this "You're reading in files completely wrong, try googling for a better solution" which unfortunately among engineers seems to be the most common reply.

cperciva 11y ago
"Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work" I usually hear this referred to as a "criticism sandwich": Criticism surrounded on either side with compliments.
- bstamour 11y ago
  In the martial arts community we call this "praise, correct, praise."
  - gagege 11y ago
    What's weird is that even though I know this is a "trick" I still want people to talk to me that way unless I specifically ask them for the hard truth.
  - artursapek 11y ago
    Programmers tend to incline towards efficiency. I think that's why we often skip the bread and deliver only the filling. IMO there's a big difference between a criticism sandwich and tactful criticism.

tanglesome 11y ago

That's all true, but the cartoon is still funny!

Zelphyr 11y ago

Code is art and every artist wants to go back and redo their bad works[1]. But the best thing to do is learn and move on to create better art. 1: https://www.yahoo.com/movies/bp/steven-spielberg-finally-admits-walkie-talkies-were-mistake-142746809.html https://www.yahoo.com/movies/bp/steven-spielberg-finally-adm...

kstenerud 11y ago

I kept some of my original bad C, asm, and REXX code back from my high school days after I finally moved on from BASIC in 1991. I pull it out from time to time for a quick chuckle.

JoeAltmaier 11y ago

Not quite right. All the code I wrote last year looks bad to me; naieve, clumsy, artless. Because I have learned so much since then. It never gets any better. Not because I don't get better; because I DO get better. I've been writing code since 1976.

losvedir 11y ago
I hear this sentiment a lot (and notice it in myself, though I have a lot less experience so it hasn't been as long running), and it worries me. Are you sure it's better? Are you keenly aware that there are no, say, cycles in your coding approach? I know this year I look back at last year's code and go, "oh boy, why'd I do it that way?" And I feel like it's better, but I'm always a little afraid I'm just chasing novelty. Not sure how to objectively know if it's better.
- aidenn0 11y ago
  Don't forget also that familiarity makes things seem more clear. Code you wrote yesterday needs to be particularly atrocious for you to find it hard to understand. Code you wrote a year or two ago might as well have been written by a stranger (really memorable hacks aside). Perhaps look at code from 2 years ago and 3 years ago, and if possible blind yourself as to which is older, and rate each one.
  - JoeAltmaier 11y ago
    I'm pretty sure I remember my code. I agonize over it, put all my effort into it. I remember code I wrote in the '80. I remember the code I wrote 7 years ago, and refactored last year. Code is my life. I've had that sneaking suspicion that maybe I'm not really getting any better, yes. But I have independent corroboration - I've worked with another guy for most of that time, and we've got one anothers' code to look at. What one of us learns, the other learns too. He's not cycling, or just writing bad code. And he says the same about me.

angersock 11y ago

I think this is reasonable, but at the same time, please get those million lines out of your system on somebody else's project. If that can't be done, if you can't spend your free time honing your abilities, then accept helpful feedback from other more experienced developers. Don't just accept feedback--assume your code is garbage, and ask how you can make it better. If the answer eventually becomes "it's good enough for business purposes", then find out why that is, and learn from that. Communication is hard, and explaining why a codebase is just wrong can be as difficult as explaining to somebody why you find them abrasive. At the same time, it's the job of senior engineers to make the effort and try. Sadly, in a startup environment, it's usually smarter business-wise in the short-term just to sack the inexperienced developers or railroad them into simpler work that they can't screw up, and kick the can down the line.

naiyt 11y ago

I remember reading some advice like this around the time I started programming. It was something along the lines of "every dev has XXXXX lines of bad code in them, so write a lot of code to get them done with!". (I think it was from Joel Spolsky, IIRC.) It helped motivate me to just write a ton of code, even early on when I didn't really know what I was doing. Just writing a bunch of code without worrying too much about if it's "right" or not is really important, at least early on. I think I write better code now because I spent so much time just writing stuff early on, and learning from my mistakes. That, along with some good mentors helped me so much more than the people that merely criticize you because of your code. I definitely agree with this article.

kctess5 11y ago

1000000 lines of bad code is a bit of an exaggeration. Many (most?) programmers never write that much code in their entire careers. I've heard 10000 LOC as a milestone for REALLY learning a language (once you're familiar with programming in general), I'd say it's on that order of magnitude for writing non-terrible code in general.

var_explained 11y ago
It's just a figure of speech, and catchier than 10K.
StillBored 11y ago
The problem is that a lot depends on what kind of problem your solving, and whether it varies a lot. I've written ~10k lines of python (single small project). But, I'm still at the point where it seems every other line requires me to google something, and i'm sure normal python people would snicker at the result. OTOH, I've probably written close to 750 (maybe a million, aren't small companies cool!) lines of C/C++ over the last 20 years and that is probably not enough either. Although I rarely even have to think about the code, rather i'm totally working at the algorithm/interaction level and the text pops out of my fingers. I would say 10k is enough that you can put it on your resume... But, even that is probably way less than the average comp-sci graduate writes. So, I would still consider it a starting point. Especially, since reading other peoples code is just as important a skill, and that isn't something generally picked up in school, or on little weekend projects using a new language. But again, it depends on the breadth of the problems being solved. We hired a web developer a couple years ago, who in the space of about a year wrote ~150k lines of PHP and javascript, and got a _LOT_ better at it, but he solved most of the problems the same way and there was a metric ton of duplicate code, and imprecise problem solving (AKA problems solved in the most roundabout way). Over the last 2 years I've probably only written about 50k lines of PHP/Javascript but I've added about 20x the functionality he added. So, I would say that i'm better now than he was when he left, but i'm still not really that good.

eonw 11y ago

good read, thanks for posting.

jackreichert 11y ago

More important than good code is shipped code. I'd say about half my bad code is due to inexperience, what the post is referring to. As time goes on it DOES get better, especially since -- like most of you -- I'm constantly reading and trying to improve my skills. The other half of my bad code is due to time constraint. This is either because a quick hack is needed, or the proper planning time is not allocated to do a proper job. This leads me back to my initial statement. Sometimes you just need to get the job done. If you're not good enough to do it right, but you hack it and it works, that's good enough for now. This is how systems get built poorly and bloat up, but there are deadlines and requirements that need to be met, and if you never ship, you'll never get the budget to rebuild that old system you allowed to get unwieldy. It's a constant struggle to balance quality, functionality, and deadlines.

kgabis 11y ago
https://i.imgflip.com/kc24o.jpg https://i.imgflip.com/kc24o.jpg (Sorry for commenting in a form of a meme, but it really was asking for it)
- jackreichert 11y ago
  Very valid point. But not every product, as much as the stakeholder would like to believe, is a space shuttle.

cubano 11y ago

If only my clients and recent bosses would consider refactoring a valid billing line item... I can only imagine sending an invoice today to my three top clients with "5 Hours Refactoring Bad Code That is Working But Could Be Better Looking....$400". There is just no way I would get paid. Unfortunately, I have interests outside of working on code that mostly preclude me from sitting for hours happily breaking-and-then-refixing code that is currently working ok and that I cannot bill on. Hell, just keeping up to date with the unreal pace of change that is occurring in software right now is almost a full-time job in itself, much less fixing old stuff that is going to go away soon anyway.

gknoy 11y ago
Would it work to say, "Added test coverage, refactored code to increase future maintainability"?
- therealwill 11y ago
  Client: "Send us some screen shots of the new features." You: "Err..."
aidenn0 11y ago
Solution A is obviously to educate them: $400 as time spent to make adding the next 10 features cheaper. Solution B is to refactor some fraction of the code you interface with when adding a new feature. So it's "X+2 hours adding new feature" when you spent 2 hours refactoring code that feature X needed to deal with. As far as the ethics of Solution B, then if your refactoring is actually improving your net productivity, then you truely are doing necessary work towards adding the feature (just as you would bill tests or build scripts needed for the feature along with it). If it isn't improving your net productivity, then why are you doing it?
Cthulhu_ 11y ago
How about "I did my job, and if you ask me to specify how much time I spent on testing and refactoring, you're a micromanager and you're redundant because you obviously have nothing better to do"? As a developer, you need to take your own responsibility for the code and product you create, and be proud of it. Besides, it's a fallacy that time not spent on code quality would lead to more features / a better product.

steakejjs 11y ago

What if you are an experienced engineer talking to another experienced engineer ? Seems to me if someone writes bad code when they SHOULD be writing good code, code-shaming might be in order. I'm all for being nice and understanding. Everyone programs at a different level and I may not write code that is as good as I think, but some code is just obviously bad...and constructive criticism (if willing to be accepted) might help

serve_yay 11y ago

Yeah, you shouldn't shame people because their code is bad. But the other side of that is when someone says your code is bad you don't take it personally. There is more than one way to not be a nice person. Just think, if everything is pretty good and isn't that bad and doesn't need that much improvement, why should anything ever get any better, ever?

dap 11y ago

There are some useful ideas here, and public shaming per se probably isn't the answer. But publicly talking about bad code, and the properties of code that makes it bad, is an important way to socialize what makes good code, plus the meta fact that code quality is important. To the extent that the aphorism about writing bad code is true, I think it's just another way of saying that people's code improves with their coding experience. I really don't think you need to write bad code _in order_ to learn to write good code. It's hard to know for sure, but I think the most positive influence on my code quality was _reading_ lots of very good code, not having written bad code. (It's the same with my writing, too.) [Edited for clarity, ironically.]

dvirsky 11y ago

I have here some 10 year old C++ code I've written lying around. It's pretty terrible style-wise, but not as bad as I imagine it to be without looking at it. But the main point is that it worked in production for years. I would have written it much better today, and it will probably work faster and be easier to maintain. But it would also probably take longer to develop (though less time to debug and stabilize) - and ultimately, it would do the same work in production. I'm not saying that improving your coding style and skills is not important. Just that we need to keep our eye on the ball - which is delivering working software, not code.

alarge 11y ago

I'm not a real fan of assigning a context-independent global value label like "good" or "bad" to code. While there probably are examples of truly "bad in all respects, in any context" code, the vast majority of code that I've seen tends to fit more into "<this attribute> of the code could/should probably be improved when using it in <this context>". I find that viewing (and discussing) code this way has a lot of benefits: * It is really hard for a single global negative value judgement made about code to not be taken personally by the person who wrote it (e.g., "your code sucks" == "you suck"). This is much easier to avoid when talking about attributes of a thing, since (a) it comes across as more objective than subjective, (b) gives plenty of opportunities for acknowledging aspects of the code that _don't_ suck, and (c) lends itself to much more of a "give and take" discussion. * It gives you the opportunity to talk about "figures of merit" and trade-offs that are the reality of engineering, but rarely taught in schools (e.g., readability/development cost/flexibility vs. performance, etc.) * It gives you a framework for explaining why things like idiomatic style, "principle of least astonishment", and general elegance actually contribute to code quality (and aren't just excuses for subjective attacks).

michaelochurch 11y ago

Bad code is a great wedge for business people to get programmers obsessed with individual relative ranking and prevent any sort of collective action. I certainly had jobs in the past where I got angry over bad code when, in fact, I should have been bad at the businessmen making me use the bad code (instead of putting time on the calendar to write things properly) and setting the deadlines that caused the bad code. For sure, there are some sloppy, borderline-unethical engineers who write shitty fast code to get promoted away from the maintenance messes they generate... and there are definitely some incompetent engineers. For the most part, though, bad code is a symptom of bad leadership rather than bad programmers. Under a tight enough deadline, everyone's code will be shit. And, of course, it goes without saying that the proper response to bad code isn't to flip out on the person, but to teach him how to do it better. One of the reasons why I like using high-productivity languages like Haskell rather than Java is that it selects for people who genuinely want to improve.

autoreleasepool 11y ago

I don't see anything wrong with the "mean-spirited" humor in the XKCD comic. The cartoon is funny. It's supposed to be a joke. Anyways, it's not like those remarks are directed at anyone in particular -- just a fictional stick figure. I don't have any ethical qualms about laughing at his expense.

chasing 11y ago
You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-) That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are shitty at it. In fact, I'm almost always very impressed with people who are not professional coders but who have taught themselves a few coding skills in order to solve some problem or to actualize some idea -- even if the code itself is horrific from a professional standpoint. That's awesome! And if they want help, I won't mock -- I'll help! It's a rare opportunity to really show someone why I find the act of programming to be so fascinating and satisfying.
- autoreleasepool 11y ago
  > You're right to not have qualms about laughing at something that's literally just black and white pixels (and some in-between grays) that are arranged in some configuration on your screen. ;-) Not sure what you're trying to say here? Its a cartoon about a stick figure who can't code. Funniest part was "it's like someone took a transcript of a couple arguing at ikea and made random edits until it compiled without errors" lol > That said, this XKCD comic is one of Randall's rare misses. It's about mocking something which I -- as a developer -- would actually like to promote: People taking initiative and teaching themselves to code. Even people who are shitty at it. I understand that you feel passionately about this, and I agree wholeheartedly that non professionals should not be mocked. That said, I dont think that's what's going on here. What we have here, is a cartoon that's poking fun at an exaggerated circumstance. No individual or group is being (sincerely) called out or told they shouln't try to learn to code. It's all just a joke, for amusement. Its like saying Peanuts is mean spirited for mocking people with poor hygiene with the character Pig Pen: It discourages those people from leaving their homes and interacting with people. I should instead encourage those with poor hygiene to pick up that bar of soap and go outside! ... But that's silly, right?

ereyes01 11y ago

I agree that mean-spirited feedback is not helpful/constructive. I can see how that would discourage someone who is new to programming. In fact, "feedback" is probably not even the correct name for that... maybe "bullying". However, I have to disagree with the notion of having to write a lot of shitty code to learn to write good code. Granted, that is one way to learn, but not nearly the most effective way to learn. For years, when I started my career, I wrote lots of shitty code. I feel badly about having done this because I unwittingly caused quite a bit of havoc in the products I was working on, and even pissed off a few customers along the way. Writing shitty code can have really bad effects on a team and on a product. Fortunately for me, I eventually ended up working in an extremely talented team. They were not only talented at programming, but also highly skilled at teaching others good programming. Their method was simple- they accepted nothing that failed to meet their high (and documented) standards of readability and testing, but were extremely thorough in spending time showing you what you did wrong. They were never demeaning and always constructive- they always had a high level optimism in every new-comer's potential. Given enough time, it was clear that some new team members weren't going to work out, but those who had it in them to patiently improve their skills flourished and enjoyed very successful stints with this team. After a rough first few days on the team, I heeded their warnings and agreed to check my misplaced ego at the door. Then, and after a couple of months of embarrassing ineffectiveness, I gradually became a better programmer and went on to become a great team member. I'm really grateful for the patience these guys had with me and the other noobs. They really made a difference in my career and in the career of my peers!

FLUX-YOU 11y ago
This kind of thing can really have an effect on your career in the immediate future. There are a lot of expectations that people come up with regarding what you should know by X years into your career and people judge you pretty strongly on this. I personally don't get any feedback on my code and I don't really have time to police myself on it. I end up blending in with the conventions I see in whatever current document I'm working on (e.g. presence of type prefixes, casing style, underscore usage). I always thought this was bad practice in the general population but I guess I get paid for it. We aren't going to raise the industry-wide skill level if we let people figure it out on their own the hard way. That's valuable up until a point but eventually they should start wanting to know what the effective way of doing X is (if it exists). Individuals take a long time to arrive at an optimal point with that stuff, and may never even reach it. I'm fairly sure NASA doesn't let staff (astronauts especially) in training learn everything the hard way. Imagine if your workplace maintained something like this: http://llis.nasa.gov/ http://llis.nasa.gov/

moron4hire 11y ago

This is why my handle is "moron4hire". It's supposed to be a daily reminder to myself that I'm not that hot.

killertypo 11y ago

one of my first projects as a consultant fresh out of college was HORRIBLY coded by my standards today. Sometimes I still fire it up and it still works (which fills me with pride); however, perusing the code hurts my eyes and I often wonder what was going through my mind.

tatterdemalion 11y ago

> So I wrote a Perl script that read in the file, combined it, and printed it out as a single line. Then I had my Java program call the Perl script through the command line, capture the printed output, and save that as the string. When I first started (in Python), I didn't understand what a function was, but I wanted my program to react differently depending on user input, and had some conception that I should be breaking my program up into files by purpose. So what I did to get it working was this: I named each file "$cmd.py", then I concatted the user's input with ".py", opened & read the file with the associated name, and ran the resulting string through exec() !! I came to this result incrementally by googling different aspects of the problem that I didn't know how to describe properly. If someone had been a jerk to me about it then, I probably would've been really self-conscious about it. But no one was a jerk, so I'm not ashamed: what I did is ridiculous and funny & I'm glad to be able to laugh about it now.

aw3c2 11y ago
The result was still great though, wasn't it? You made the computer do what you wanted and it was probably better than doing it by hand.

everyone 11y ago

The xkcd thing is just one webcomic, I reckon it is just a joke and probably Randall Munroe did not consider its implications or think it would be taken seriously. Though xkcd is really popular and probably is relatively influential (especially in programming circles) That being said, I totally agree with this article. Also 'read a style guide' is one of the worst possible suggestions I could think of. Style is just style. Its one of the least important things I could think of. It depends on your work situation but in many cases why not just go with whatever style you are happy with personally and makes sense to you.

halosghost 11y ago

This times a million. I love helping people to learn C, for example. And the thing I do most other than basic instruction is helping to keep their spirits up and reminding them that refactoring is the most important part of coding.

hnal943 11y ago

There's a difference between practice and mere repetition. You wouldn't get any better at speaking Russian if you just spoke gibberish, even if you did it for 10 years. You need to know what improvement looks like.

eduadecastro 11y ago

Shouldn't the compiler recognize this as an append instead of copying every time?

TheLoneWolfling 11y ago
It should. But the Java compiler punts everything to runtime, and the JVM doesn't optimize it either.

based2 11y ago

Why not use Findbugs[1] by default, it is now well integrated in major IDEs? [1] http://findbugs.sourceforge.net/ http://findbugs.sourceforge.net/ [2] http://softwarerecs.stackexchange.com/questions/2902/static-code-analysis-integrated-with-github http://softwarerecs.stackexchange.com/questions/2902/static-... [3] https://github.com/LMAX-Exchange/freud https://github.com/LMAX-Exchange/freud [4] http://spoon.gforge.inria.fr/ http://spoon.gforge.inria.fr/