A Million Lines of Bad Code

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.

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.

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.

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!

I've been writing code since 1976.

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.

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.]

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.

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).

1: https://www.yahoo.com/movies/bp/steven-spielberg-finally-adm...

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.

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.

[1] http://findbugs.sourceforge.net/ [2] http://softwarerecs.stackexchange.com/questions/2902/static-... [3] https://github.com/LMAX-Exchange/freud [4] http://spoon.gforge.inria.fr/

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

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?

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.

No. Not in Java since 1999 or so.