Questions? Feedback? powered by Olark live chat software

I am a terrible programmer

I recently got this from the co-founder of Artsicle, a startup I interned for over the summer after my freshman year:

From: Scott Carleton
Subject: just refactored your find_art.js that you did over a year ago
Part of me is thinking: in some ways, you were a terrible programmer
Other part is, well shit, it’s worked perfectly for the last 20 months and I’ve never had to touch it. :)

Scott is absolutely right: I am a terrible programmer. I don’t comment my code very well. Sometimes I ignore the DRY principle. I tend not to use fancy ternary statements, or worry too much about whitespace. My data structures can get ugly sometimes.

But in other ways, I (dare I say it) am a pretty good programmer. For example, Artsicle is a Rails shop and prior to working for them I had only had very limited experience in Rails or any true MVC framework. After a few weeks, I had mostly picked up the codebase and was building features without inordinate trouble.

I also ship stuff. A lot of stuff. I’ve probably built and released 20 apps over the past two years in a variety of languages and frameworks from Python to Rails to Node to Backbone.

42 Floors even publicly offered me a job to become a programmer for them. You can argue that it may have be undeserved, but either way given my ability to produce products with code, it seems that we have a dilemma on our hands.

Am I a terrible coder, or a good one?

I think it’s clear that we have definitional problem: what makes a good programmer?

In general, my priority since I started coding 10 years ago has been speed. How do I get this built as quickly as possible?

And there’s a very specific reason for that: when you’re working for yourself (and you’re young) it’s very unlikely that any one particular project that you build will be around for very long. So for me, it was more worthwhile to spend less time creating beautiful code so that I could spend more time testing out my minimal products. I always approached programming from a very practical perspective.

For me, the beauty in programming was the fact that it allowed me to build businesses where the only cost was my time.

I always coded with a product in mind; never just for the hell of it.

But when I got to college something interesting happened. Even though I’m a philosophy major, I began to take computer science courses. And approaching programming from a theoretical instead of a practical perspective really opened my eyes. Not only was programming a way for me to build businesses, it also became engrossing as something to study.

Real theoretical computer science (things dealing with complexity theory) actual becomes a lot like philosophy. And what’s funny is that a lot of the supposedly theoretical things that I was learning, actually made me better at building products.

It turns out there are problems that you face every day building an app like Firefly that having a grounding in the principles of computer science can help you with (who’d a thunk it?). If you understand algorithms and data structures you’ll be much better prepared to face a lot of the challenges that crop up building more complex web apps.

So a good coder is someone who has a theoretical understanding of the tenets of computer science, right?

Wrong.

Just because you graduated with a degree in computer science from Penn does not make you the next Jason Cohen or Patrick McKenzie.  You have to do more than just finish your homework to become a good coder.

Like most things in life, the answer to what a good coder is, is somewhere in between the guy who wants to get it out fast and the guy who wants to make it beautiful.

The answer is: a good coder knows when something should be quick and dirty, and when something should be thorough and clean. You learn to ask: is this really necessary? And sometimes taking a extra few hours to plan out how you’re going to build something is necessary. As time goes on that’s certainly becoming true for me.

The stuff I build today is much more likely to used than the stuff I built 5 years ago was. Which means that I have to shift my thinking a little bit. Instead of focusing purely on speed, I’m starting to look for elegance as well (if I didn’t my exasperated co-founders would probably kill me).

So next time you’re working on a project, give some thought to what’s most important: speed or elegance. Learning to answer that question correctly is half the battle.

P.S. In my defense, the find_art.js file that Scott was referencing was supposed to be a prototype. They weren’t sure if people would actually use the feature and wanted to test it. It ended up being so popular that they left it in!

I  write shitty code for my startup called Firefly. If you’re interested in doing better customer support and you have a SaaS business – we can help you.


8 Nov 2012, 7:46pm | 103 comments

  • Pingback: I am a terrible programmer | My Daily Feeds

  • pyro

    Thank you for your words Dan. I agree with your sentiments and it all correlates well with a long-running discussion I had over IRC early this morning.

    Just a heads-up: Something is inhibiting the triple-touch gesture on OSX which is the default shortcut to dictionary/thesaurus/wikipedia. It’s most likely deep in the bowels of WordPress; God’s speed should you choose to accept this mission. Nevertheless, take the fact I had to lookup some of your words as a compliment :)

    • http://danshipper.com danshipper

      No problem, glad you liked it :)
      I’ll look into it but I can’t promise anything. Have no idea what that might be. Thanks for reading!

  • http://@HockeyBias.com Charlie@HockeyBias.com

    Scott email makes him sound like an *ss… Not sure I’d want to work with him. You sound great to work with!

    • http://danshipper.com danshipper

      Scott’s a great guy, we just have that type of relationship where you can say stuff like that :)

    • http://www.leftbraintorightbrain.com Scott Carleton

      Thankfully shipper and I have a great relationship where I get to enjoy being an ass to him and he takes it well in stride.

      • http://www.xethron.co.za Bernhard

        And Scott replies! OWND!

        Don’t talk behind someone’s back unless you are 100% sure they won’t read it. :)

  • Greg Guida

    “I also ship stuff. A lot of stuff.”

    Is this why they call you “Shipper”??

    • http://www.hypedsound.com Jonathan Jaeger

      I rofl’ed.

    • http://danshipper.com danshipper

      lol

    • http://beauty-mantra.com Vikram

      Good one…

  • pete

    Dan, this post is awesome. I picked up programming coming out of grad school in a totally unrelated field because i just enjoyed it. i started developing websites for people but was always terrified that someone was going to jump out of the bushes and say something like scott, calling me out for being a fraud (it happened once about a year in and got me pretty rattled, also took down all my video tutorials from my site). it was pretty refreshing to read about you being called out but just rolling with it. and congrats on the job offer btw.

    -pete

    • http://danshipper.com danshipper

      Really glad you liked it! Keep rocking

  • pete

    *sorry, meant almost took down my tutorials… not also

  • ok

    discrediting education is ridiculous.

    • http://danshipper.com danshipper

      Hi there, I honestly wasn’t intending to discredit education. To the contrary it’s been super valuable to my coding skills. I was just saying that when it comes to programming, just getting a degree is not enough.

    • Jamey Cribbs

      Saying that the author “discredited education” IS ridiculous. Try reading the article again.

  • Kit Plummer

    Well, it totally depends where you are in the stack, and the operational environment. If you’re responsible for writing UI components (and the like) I’ll give in to your perspective. If you’re responsible for accurately finding a needle in a haystack in exactly 20ns then you’re fired.

    I see this “problem” all too often – and it’s a growing problem brewed by frameworks, middleware, and goofy patterns and mantras like “convention over configuration”. There’s a keen difference between being a programmer/developer and an engineer. I also see the “prototype” problem a lot. If you write code, write it right, as if it is responsible for your life…because as you know, you never know (where it might end up). Not doing so does indeed make you a terrible programmer, and a bad human being. ;)

    • http://danshipper.com danshipper

      I agree that it depends. Context is key, and it’s something that I tried to get across in the article. Maybe not very well :(

    • asdf

      Wrong wrong wrong, and wrong.

      If you can bang out something dirty quickly that works, pass QA, fulfill the requirement, provide value. No one seriously above the little techies gives a crap about “clean code”.

      You need to wake up.

      Software is used to make money. That’s the only fact set in stone.

  • Brad Newman

    Nice post Dan, I believe that many others would classify their programming style in the same manner. When it comes down to it, who is going to get working product out the door quickly? Its certainly is not the guy who holds the white board down while others are at the keyboard.

  • in general disagreement

    You say you ship stuff but given that what you’re “shipping” is a bunch of webapps built on absurdly easy to use frameworks, I don’t actually think you’re qualified to even know what a good programmer is vs a bad one.

    A lot of this post seems like an excuse to allow poorly thought out, untested, undocumented, and unmaintainable code into a codebase.

    Well, mr. junior in U Penn, as a graduate from another ivy myself with a degree in math (not CS), I will tell you that what you are doing now might seem great, but it won’t suffice for more significant problems.

    • Matt

      Even your e-penis is tiny. Give us a link to your GitHub account so we can see how awesome you are at coding and solving significant problems. If it’s not all written in Assembly and C, you lose.

      Mentioning you go to an Ivy League school in an anonymous comment is also the most pretentious thing I’ve ever seen. No one cares.

      • http://danshipper.com danshipper

        Thanks for the comment Matt :)

      • Patrik

        (This is the first time ever that I have done this)

        +1!

    • http://danshipper.com danshipper

      Try building Javascript based screensharing that work with 0 downloads on any website on the web in every browser including Internet Explorer like we’ve done with Firefly and let me know if it’s an *easy* web app built on a simple framework.

      I generally only respond positively, even to very negative comments, but I think that this particular comment is unnecessarily dismissive and condescending.

    • j5c

      Anyone who does not consider himself / herself as a bad programmer is not learning. Programming is a life long skill. If you cannot reread your code from 6 months ago without groaning and thinking “Why on earth did I do it like that?”, you have stopped developing.

      New ideas are always coming out (that is why I read blogs like this) – you don’t have to agree with all of them, but you should store them away in case they turn out to be the right tool for a job later.

      If you need to do a ‘hack job’ to ship out code fast, you know that it might come back to bite you; but that is a factor of the ‘Time-Quality-Features: Select any two’ dilemma.

      For the record: I have been programming for over 40 years (graduated with a degree in CS 32 years ago and have been programming professionally ever since). I am regarded by my peers as a good programmer but still regard myself as a bad programmer and I approach every project as though it was my swan-song and will be the winner of the Noble Prize for software; hoping that I won’t stagnate and that in 6 months time it will make me groan.

      So, Dan, keep looking back at the bad programmer you used to be and keep looking forward to the good programmer that you aspire to be.

  • http://iambateman.com Stephen Bateman

    Yup, this is great.

    I graduated with a business major last year, and people always ask: “so, how’d you learn this?” And I am also a terrible programmer. ;)

    • http://danshipper.com danshipper

      glad you liked it!

  • http://noahcampbell.info Noah Campbell

    Don’t get hung up on being a good or bad programmer…focus on being a professional programmer…start by writing tests. That way, the programmer who has to maintain your code (good or bad) won’t be cursing your name as she tries to refactor it.

    • http://danshipper.com danshipper

      good point, that’s definitely something that I want to get in the habit of doing more often.

  • http://eranmedan.com Eran

    Very important subject (speed vs. elegance, working software vs pretty software)
    I had a similar question (“what is a good programmer”) or in my words “what is bad code vs good code” and I wonder what you think of this the article I wrote trying to answer it (shameless plug) http://eranmedan.com/post/31388713349/the-good-the-bad-and-the-beautiful-code

    please excuse my English, not a native language, and this was also written very late at night…

    • http://danshipper.com danshipper

      thanks for commenting, I’ll check it out!

  • http://codetemplar.com Pierre Goldstein

    I can totally agree with you and I also must be a terrible programmer, in fact, I don’t even like calling myself a programmer. All I know is I love to write code and create things. Keep up the great work!

    • http://danshipper.com danshipper

      Same to you!

  • http://basus.me Shrutarshi Basu

    Some things:

    1. Could you explain more why you think theoretical Computer Science is like Philosophy?

    2. Why do you hold up Jason Cohen or Patrick McKenize instead of people like Linus Torvalds, Russ Cox, Rob Pike or John Carmack? Neither of the people you mentioned seem to have built anything that would make me go ‘wow’.

    3. Speed and elegance are not only the two axes on which to judge how good code is. There’s correctness, security, fault tolerance, extensibility, scalability and other such properties that you do not seem to be taking into account. Additionally, I’m not sure what you mean by “elegance”.

    All that being said, it’s good that you are thinking about these matters and trying to improve. I suggest you look at the work of programmers who have a history of building large, high quality systems. You’ll probably learn a lot just from their interviews and their writings. I know I did (and still do, regularly). Good luck.

    • http://danshipper.com danshipper

      1. If you look at complexity theory it has a lot to do with problems like “What can a computer compute in a reasonable amount of time?” To me, that sounds like a philosophy question. The difference is, that it’s a philosophy question that we can actually empirically answer!

      2. I like Jason Cohen and Patrick McKenzie as coders but also really as entrepreneurs. They’re people who have married technical skill with business savvy in a way that I’d like to emulate.

      3. Sure, there are lots of different ways to measure code quality. I chose to simplify it as a dichotomy between those two, but I agree there’s more to the equation than just speed and elegance. Although you can argue that an elegant program will have a lot of the features you mention like extensibility, scalibility, fault tolerance etc. It’s a matter of definition

      Thanks for the comment!

    • Alex R

      In response to 1, something both you and Dan might enjoy:

      http://arxiv.org/abs/1108.1791 and http://www.scottaaronson.com/democritus/lec9.html

      The former is a paper titled “Why Philosophers Should Care About Computational Complexity” and is a fun read even if you’re not too well versed in either field; the latter is very non-standard introduction to quantum physics as part of a quantum computing course with a philosophical bent.

      Scott Aaronson is researcher who writes on topics related to both fields.

  • http://codercofounder.com Ilya

    Dan,

    I think the question of whether someone is a terrible programmer comes down to who do they feel is their audience. There are brilliant programmers who essentially code for themselves or someone like themselves. To them the greatest virtue is having elegant, highly-readable, and highly-maintainable code that other programmers can understand, extend, and improve upon. There is another category of programmers, who are generally mediocre at writing that type of code. Instead, they tend to optimize for customer value, shippability and user-facing functionality. I realize these categories are not mutually exclusive, but I think we tend to overestimate the overlap between them.

    From your resume, it’s clear that you are firmly in the second category. And I think that even if you choose to admit that you are a terrible programmer, you are truly terrible in a very narrow sense.

    • http://danshipper.com danshipper

      Absolutely agree with you there, nice distinction. Although I think these categories definitely are not mutually exclusive. A lot of people live on a continuum between those two. Thanks for the comment, really appreciate it :)

  • http://www.codetactics.com Glenn

    You make very good points, however, when forced to write ‘quick and dirty’ to get something out the door, there is added skill in doing it in such a way as to not ‘contaminate’ the existing code base. i.e modular chaos. This is mainly required for codebases that need to exist for a few more years though, rather than ‘throw-away’ code.

  • Lee

    I have been doing this a long time and am one of those pedantic over-engineering types. In my younger years I lacked appreciation for the likes of you but over time I have garnered a huge amount of respect because without you, nothing would EVER ship.

  • aefxx

    Related: The Kid by Clay Allsopp

    http://clayallsopp.com/posts/give-a-damn/

  • http://joel.inpointform.net Joel

    “my priority since I started coding 10 years ago has been speed”

    This is very important in any mildly demanding environment. Any tips on how to you increased your coding speed? things that I’ve been doing lately

    *Improving typing speed (that includes symbols)
    *Learn key short cuts of my IDE (generally, nav, refactoring, and editing short cuts)
    *Get key plugins (vim plugins for eclipse,chrome are nice)
    *Ship mediocre code fast and iterate faster/Make good decisions on what to implement

    • Rene

      My best course: blind typing with 10 fingers, my speed is over 400 keys per minute and I don’t use shortcuts as typing is faster.

      Compared to collegues I can code many times faster with good code quality.

      It takes a few weeks to learn, then some time to improve you speed but you have it for live.

      • Paul

        according to Wikipedia:

        http://en.wikipedia.org/wiki/Words_per_minute

        “The fastest typing speed ever, 216 words in one minute, was achieved by Stella Pajunas in 1946 on an IBM electric”

        • miguell

          “keys” “words”,

          what’s the point?

          • miguell

            okay, let me repeat since ‘unequal’ sign was left out:

            “keys” IS NOT “words”

          • miguell

            “unequal sign” left out …. must be that “quick an’ dirty” programming, hahaha :)

  • rjs

    Settling for mediocre code and thinking that it’s justified by the fact that you ‘ship’ pretty much ensures that you will never be great.

    Yes, shipping is important. But so is skill development. If you never spend any time trying to write elegant, concise, readable code, how will you ever?

    You hint at this near the end of your post, so there is hope for you.

    • FB

      Shipping IS what makes you great. I have no doubt that many of the biggest apps out there started with inelegant, ugly code bases. Doesn’t matter. They shipped, they worked, and they were the first to do it right from the customer’s perspective.

  • http://www.codeproject.com/script/Membership/View.aspx?mid=3402606 Rahul Rajat Singh

    This is a very good post. Many people get too finicky about the quality of code but they fail to understand that delivery is just as important as quality of code.

    Don’t get me wrong, I am in no way suggesting that we should write crappy code. I am just saying that we should keep our focus on the work and find some time daily to acquire knowledge about best practices and efficient ways to write code. And subconsciously we will find those practices getting inculcated in our coding style.

    Its always better to code and keep learning standards so that whenever I look back at my old code i feel “Man, I was a horrible programmer”.

    P.S. I really am a horrible programmer :(

  • http://waltschlender.com walta

    Interesting read Dan. You know I was a Econ major in college and then afterwards got into consulting. I found that consulting projects demanded simple solutions where speed was most important.

    Later on I went on to do more long term stuff and recently had a *gasp* full time job for the past year. I keep on finding that it’s almost like different styles apply to different jobs. I’m definitely finding that when you’re discovering a business model or doing a first pass at a project, “simplest thing that could possibly work” is a good rule of thumb and that it can be messy because you often don’t know what you don’t know.

    Still… I think that on longer projects I find that I’m really coding for the guy whose going to come along after me and is going to have to actually maintain this crazy thing I built so yeah I think it takes both approaches — in different cases.

    Again, really enjoyed reading your 2c and appreciate being able to pitch in mine as well.

  • hacks destroyed hn

    Why would you want to be the next Patrick McKenzie? He’s self-promoting SEO monkey and talentless programmer. I guess he’s an inspiration for those of low intelligence (a very portion of HN these days), showing them that you can internet fame without any real achievement.

  • Aaron

    “Sometimes I ignore the DRY principle. I tend not to use fancy ternary statements, or worry too much about whitespace. My data structures can get ugly sometimes.”

    The biggest issue you have there is whitespace.

    Ternary’s can shorten code so have their place but you don’t need them.
    DRY is a bit fascist. I say repeating yourself once is ok,
    Data structures, whemn do they not get ugly eh.

    You need more whitespace if that’s an issue!

  • http://www.philliphaydon.com Phillip Haydon

    Brilliant post. Made my day reading it.

  • http://www.coreyballou.com Corey Ballou

    When you’ve got a last name like Shipper, you’re bound to deliver code fast and on time. It’s in your brand! All kidding aside, speed is a huge factor in code, especially when working on client based projects where deadlines take priority over [insert design pattern/principle].

    Great programmers know the trade-offs of quality, speed, and cost. The manner in which they code is dependent upon the expected outcome. Do you want low cost and fast delivery? Well, you’re going to have to sacrifice code quality. Agency work tends to fall under this blanket if you have a misappropriated project estimate or a client demands a certain tight deadline. Great programmers understand this, and have to learn it the hard way via trial and error.

  • Sara

    I think I am a terrible programmer now,and I learnd what I should do after reading your aticle.I always cant’t use data structure algorithm and correctly.

  • Vincent

    Doesn’t matter what you try to show (or imagine) about yourself. The one rule is your conscience. If you feel “I did it perfect” even after 1 year, you’re good programmer.

    • Titus

      ‘If you feel “I did it perfect” even after 1 year, you’re good programmer.’

      Better to be an honest programmer than that definition of a good programmer. All programming involves trade-offs, making “goodness” very dependent on the measures you use.

  • Chris

    Everyone is a terrible programmer at some level; the difference is that some people recognize this fact and are always trying to improve their coding and others do not. The truly great programmers are those who learn from their mistakes.

  • Richard J Foster

    That sort of thing sounds familiar. I too am a terrible programmer… I prove it to myself on a semi-regular basis when I find myself playing around in a source file that I wrote several years ago, and has “just worked” since then. (I don’t have a Scott who sends me email like you received… although many of my co-workers would probably be justified if they did so!)

    A pragmatic approach is certainly important. If you need some code for a web application with a hard deadline (e.g. being able to process Black Friday or Christmas sales) the best written code in the world is useless if it’s delivered too late.

    As far as your comments about education… I agree 100%. While structured education is helpful, it will never take you where you really need to go. Sooner or later you have to take steps to educate yourself independently, or you will never grow beyond “average” (or worse). It sounds as if you’ve already discovered that… unlike some of those who commented before me. :-)

  • mtcoder

    I too am a horrible programmer, but guess what 10 years of the same application that supports an entire company for 500 people, and no issues or problems. So guess I’m not that horrible after all. Look at my code from a professional level, and you would scream witch, burn him at the stake.

    I know all about refactoring, I know all about proper code documention, I know all about building tests, etc. I also know that the CEO will be in my office every other week wanting some off the wall obscured change to the system. I don’t have time to go back and do all the cute stuff this is the real world. Business’s care that it 1.) works without problems, 2.) is cost effective (aka doesn’t need 10 servers for one web app) 3.) can change and bend to their every whim. Meet those 3 things and you are the worlds best programmer in the eyes of your employer. Which goes a much longer way than a degree.

    Friend of mine went got his masters in computer science, I went and got a job programming and self teaching. Also had problems with “instruction” lead learning. Just give me the damn information and let me go. After his 6 years in college we both ended up going after the same job. I got it and at about $15k more than what they stated was the range, he while did get an in person interview. The main difference was I had business experience. He had all of these planning ideas, wanted to setup the team with scrum, all that lovely theory. I walked in asked what they needed done, asked when they wanted it, and said give me 3 months. “Hired”
    That program while still ugly is my 3rd 10+year running application, that supports a business.

    Now I know there is a difference between building custom programs for business needs versus building commercial grade applications. But the 3 rules apply, 1) does it work without problems, 2.) is it cost effective, 3.) is it flexible to meet changing needs. Regardless of how the program works, how the code runs, how refactored it is. as long as those 3 rules work and work for prolonged period, you are a good programmer.

    Funny side note: after I left the first job to take the one I beat my friend to, my old boss had to find a new coder. He found some smarty pants, that came in and spent crap tons of time complaining that my code was horrible and why was I allowed to write such bad code. I even had him call me to complain. The CEO one day in a meeting basically said look, if you aren’t good enough to figure out how he ran this company for 10 years, maybe you are the one that’s not a good programmer.

    It’s all about perspective, almost like Einstein’s theory of relativity. My first boss thinks I’m a super programmer, cause my crap worked, was built as quickly as the company was, and didn’t cost much.

    Before people pass judgement that I haven’t done any “real” programming, I have and I refactor my passion code almost nightly. I call my passion code my game I am working on. I was told by someone that if you want to become a great programmer go program a full RPG game. I said um ok, whatever. After having actually started doing that, holly hell. People take for granted how many smaller systems are built into the larger game system, and it never stops. Quick example I built my sun, moon, and a simple rotator. Ok but then I refactored it to move them based on system time, ok then I refactored it and added ability to turn lights on and off in houses based on the time of day, then I added the ability to alter the characters spells based on time of day, and for some butt whipping added ability for spells to alter the system time. So what started as a simple class that took an orb and rotated in in a 360 orbit, suddenly turned into about 50 classes to handle day of time, and how it affects the entire game world, and how players can affect it. Needless to say I had to refactor and refactor and refactor it to make it work well and to do so in an understandable way for my co-programmers that I have started bringing on board to help. They are terrible programmers by the way, but I still love them cause hey I’m a terrible programmer too.

  • Darryl

    Actually, it’s just a matter getting caught in the trap, we all get into, wanting to say ‘Yes I can,’ do it show it, but no one ever wants to do the work part of the work, the dreaded documentation. Might as well learn now, nothing is complete without the paper work, and there is no escaping it.

  • Visitor

    I don’t know whether you’re a terrible programmer or not, but I’m sure that the guy who sent you that e-mail is a terrible person. What was his point? Why send an e-mail to a former employee and only to insult him?! I’ve seen awfully bad code from my co-workers throughout my career, but I never let an offensive remark slip in my conversations or e-mails. What that guy did is nonsense!

  • Gaurav

    I Kind of disagree with you. I think code should always be absolutely perfect and beautiful with comments and everything.

    I have been at it for 10 + years and what I have learnt is that writing good code doesn’t take longer. It may be difficult on day 0 when you build in the plumbing but from day 2-3 you recover the time you spent on doing things the right way.

    I think even if you are doing a POC, do a solid job.

  • http://www.movingonquote.org Yasin

    Nice said dan. Like it. As i think some how i am also a terrible and stupid coder.. : P

  • Nikos Baxevanis

    I can’t agree so much with writing quick/messy code even if its an exceptional case.. When you ship the code, new features are going to be requested and you will have to ship again, and so on. However, when you choose the quick and dirty approach eventually you will have to deal with software rot.. I wonder how many times its possible to rewrite everything from the beginning :)

  • Bill The Terrible Progammer

    Dan
    Another “Terrible programmer” here…I wrestle with same self-accusation!
    If location, location, location is everything to real estate, then context, context, context is everything to programming.
    I live in an enterprise where we produce physical products, not software; hence I am the renegade ex -manufacturing engineer who has morphed into a hack creating C# ‘Utility’ apps in a secluded corner. These utility apps are direct answers to fixing everyday enterprise problems.
    I have learned that for any app to live, it must have excited and engaged users. So when coworkers come with a problem, they need an app fast. So I deliver a simple app fast. This in turn gets them excited and engaged. After the first simple version is released and the users can understand it…because it is simple …the phone is on fire with upgrade requests….critical app life is achieved… I have excited and engaged users. Push out an update within two hours of an upgrade meeting with them… hero status is achieved.
    So in my context, there is no time for a long drawn out architect summit…shipping is an absolute must early feature. If the user waits too long for the app, they find a different way to solve their problem and the app I have labored so meticulously over dies.
    Of course the code is terrible and I am very reluctant to show it other programmers. But it does work when it most needs to work, Sure I go back later and do some refactoring and add more notes. Many times though…because the app is living with excited users and management…my boss comes to me with ‘substantial’ upgrade requests. At that time I may rewrite the entire code base, because now I have the political capital to justify the time.
    Sure I study software design patterns and I do want to use some methodologies. Also I want to take some computer science classes someday. But there is this boundary called ‘Time’ which is so annoying!
    Cheers for Terrible programmers

  • Roland

    After 30 years of programming (from firmware to assembly code to C, C++, to Java, to the scripting and database languages, finally to the visual component assemblers), I can in no time hack code together with the best of them. No architecture, no design, no code review, it comes stright from my head and stays there. It’s easy, fun, but woe to the person trying to maintain or fix it. No comments, adhoc bandages, no structure, lots of spaghetti. It’s all quite evident in the fly-by-night startup sites that freeze when simply the wrong input is keyed into a field and the server hangs.

    It not about being a terrible or good (elegant) programmer. Its about writing code (and design) that works 99.9999 % of the time and those that have to maintain it can do so in the fastest possible time.

  • http://blog.asmartbear.com Jason Cohen

    Thanks for the kind mention.

    You’ve drawn a scale between “git ‘er done” and “beautiful,” but in business perhaps the better dimension is “git ‘er done” vs “maintainable,” where the latter means things like (a) a new hire can’t break things, (b) there’s a process for rolling out changes which catches mistakes, (c) it’s possible for a new hire to learn the codebase without being a hero, etc..

    It is of course the wrong trade-off to worry about such things at the beginning; as you say, speed to market and speed to change is the valuable behavior. And that’s how all of my company’s codebases started out as well — even I hated my own code when seen with hindsight.

    But also at every one of my companies we had to transition to a mature codebase, mature coding style, real unit tests, real integration tests, real QA, processes around deployment and communicating with the other departments of the company, and so forth. This is a bittersweet time because you lose some of the fun of cowboy coding, but it’s only because thousands of customers will be fukked if you don’t, and opens new challenges, where the question isn’t “how do I whip out the simplest single website in a weekend” but rather “how do I build something sustainable?”

  • http://www.xethron.co.za Bernhard

    Thanks for the post! Was very inspirational. I think I am now ready to tackle this next project!

  • Art Grant

    When ever someone claims someone is a “bad” programmer, I throw an non-maskable interrupt and branch immediately to a service routine. What makes someone think the code is bad? Rationally (an Ayn Rand word), if the code has been working, it is good.

    PERIOD.

    So if the code is good, and yet is declared bad, then something is amiss.

    It is my observation that managers, not knowing how to code, have developed a means of analysis of that which they cannot comprehend. They use buzzwords and acronyms, degrees, and certifications. They probably heard these words from salesmen selling them something, something that was supposed to be “good” because of these buzzwords. So now these buzzwords remain in their consciousness of the decision-maker to determine qualifications of code, and of people. They would never understand what they are looking at, but if it has acronyms they have seen before, it must be good. If it’s indented and pretty, they think good.

    Who cares if it’s the worst performing piece of crap code in the world.

    It’s like the commercials on TV. I think to myself, “What dimwitted slobbering moron would buy insurance based on a talking duck?” But you see, you and I as programmers, think the world is like us. We naturally want to see, to project ourself on to the world, to see others based on our own perceptions and intellect. We have to realize they are drooling simian stroke victims, who think they are at the pinnacle of human development. Those who make the decisions, those who determine, those who critique, are narcissistic, convinced that they are knowledgeable by virtue of being in charge.

    “The Emperor has no clothes,” my IRA friend at the biker bar told me.

    • Roland

      Art,

      Be careful, a “non-maskable interrupt and branch immediately to a service routine” is probably something unknown in today’s world of front-end web browser and middleware container programming (the machine disappears). There was a time when most programmers knew what was going on from the CPU level all the way to the high level code statement. But that may soon become a knowledge that is known to a very select few.

  • dude

    sounds like you aren’t terrible, but you are sloppy. you should fix that. there’s no reason to be sloppy

  • http://www.opwernby.com Dan Sutton

    You touched on the truth when regarding computer science as a philosophy — that’s nearly it. Actually, programming is an art form – but an art form with very few right answers and a lot of very wrong ones. The interesting thing is that – as you noticed with your philosophy statement – it’s an art form which can be proven good or bad, right or wrong, or whatever you like.

    The interesting part comes in when you start to evaluate the right answers: some of those will be wrong, too — the fact that a program works doesn’t make it a right answer. There’s also the question of elegance and efficiency — the two go hand in hand… and they’re a function of lateral thinking as a natural act: if you’re a good programmer, then the lateral method always occurs to you first.

    If programming ever becomes problem solving for you (as an end in itself, I mean) then you’re not a good programmer: the problem solving should happen as a function of the art you’re creating – your mind should live at a higher altitude than simply the problems at hand. Programming is a philosophy in a sense: it changes the way your mind works… at times, you can actually dream in code, and when that happens to you, you know you’re there — personally, I remember when, back in 1984 or something, I had a dream entirely in Pascal, and when I woke up I knew I’d made it as a programmer.

    Of course, the other thing a programmer, like a good racing driver, has to relinquish is fear — most of the beauty in anything is squashed flat by the paralyzing fear felt by the protagonist in terms of doing anything that’s not in the manual — but that’s what computer science is about: any manual is by definition out of date before it’s even published, and it’s our function to make that true.

    • Roland

      Dan,

      In reference to your comment:

      “the fact that a program works doesn’t make it a right answer”

      Godel proved that within a computing/mathematical/algorithmic environment, we simply can’t ever determine that a software process is “correct” or the “right answer”. We can only accept that “it works”.

      Of course this is learned in those pesky “theoretical, unpracticle” advanced computer science courses (Analysis of Alogirithms, Computability, etc.) which give us insight on the philosophy of what we are doing.

      • http://www.opwernby.com Dan Sutton

        Agreed — good point.

        However, it’s possible to show that any given algorithm is a “wrong” answer, by producing a more efficient one. There are, by now in computer science, various known problems to which there are any number of “wrong” answers, these having been determined by experience over the years… for previously-unencountered problems, there are, as you say, only solutions, their efficacy being a theory which the programmer should attempt to disprove at least once by attempting a more elegant solution.

        My conjecture, therefore, is that if you can show a more efficient algorithm for a process, then that algorithm becomes the provisionally “correct” one, subject to later discovery of an even better one, and the old, inefficient one becomes “wrong”…

  • tonys

    A bad programmer is a bad programmer. The sad part is one can make a living being a bad programmer. Usually it ends up that you made someone else’s live a living nightmare, while you, having already collected the money for the initial work, are long gone.

    When and if you ever have to work with someone else’s bad code and think “what the !@#$$ is this?”, karma will catch up to you.

    • http://www.mdrsesco.biz Coldan

      My employer believes any code that can be licensed is golden.

    • JackD

      It’ll happen and happen often.

      There’s no ‘if’.

      I’ve learned not to complain (much), I simply begin refactoring the mess over time.

      Often this practice alone, will expose the bad logic and bugs.

  • JackD

    The myth that that in order to write fast code, it has to be ugly and hard for other people to maintain, seems to be well entrenched. I’ve had more than one employer make that claim.

    But this is a matter of habit rather than a reflection of how good a programmer you might be.

    I’ve known too many programmers who write clean easy to maintain code, quickly, and ships often, to believe that it’s a choice between fast ugly or slow and maintainable.

    If you’re writing code that’s ugly and you take pride in shipping, that’s well and good. If you’re that good, it shouldn’t impact your output to start implementing over time, habits and practices that make it possible for others to understand and maintain your code.

    I’ve seen this worship of fast dirty code, cost companies a lot of money over the years. They trade low cost up front development, for expensive maintenance costs in developers, and support staff over time. This drives costs higher and makes it difficult for them to compete in the market over time.

    Good examples are posted here in this forum of developers who wrote code they could maintain, but became a costly burden to the company after they left. If you write code like this, you’re creating time bombs and hurting your clients.

    • http://agaffeaday.tumblr.com Gates VP

      Just posting to echo your very comment.

      I have personally seen a lot of code that was “needlessly bad”. Code that could have been easier to maintain, less error prone and delivered in the same amount of time.

      People ship “fast and dirty” all of the time, but I think this is really a reflection of the fact that people don’t necessarily understand what it means to be “fast and clean”.

      I think it’s also tied to a failure to understand the premise of “working”. It’s easy to ship code that does “something”. It’s far more challenging to ship code that can demonstrate it is doing “the right thing”.

      To me, the key to making this happen is tooling. A lot of practices that make code dirty are easy to identify and correct with simple tools.

    • KelvinA

      I agree Jack. Almost all of the examples above here are of people who throw products out the door as fast as possible without any thought for how they may be maintained in the future.

      You will probably find that no one will be able to come back to the code in 9+ months and remember what on earth they were thinking. 1. Because they couldn’t spend 2 seconds to write a little comment (not huge documentation, just a snippet), and 2. Because the code is probably badly named and not very well thought out.

      So when the next poor sucker (and I use the term sucker, because it usually gets passed on to another team for continued support), they have absolutely no idea what the process is, and spend a month just trying to figure out what you where thinking when you wrote it, before they spend another month refactoring everything so that it can be maintained.

  • Dusko Koscica

    One thing I have learned about programming,

    You are not bad programmer if you are learning….

    That is my piece of wisdom, if that statement could be called wise….

    Are you having problems with this sentence, if yes you should consider some other options….

    Well, once I caved in that was my big mistake, now I am back

  • Thorsten Henninger

    Hello,

    I am working as SW QA for Volkswagen.
    From my experience, a good programmer
    is able to start for an arbitrary large project
    to code from a white and empty sheet of
    paper.
    He his able to write the first working SW
    while the SW architecture survives many
    releases.
    Bad programmers are only able to make
    adaptions or small extensions to the
    given SW architecture.

  • http://go.hodspot.com Hod

    Hi Dan,
    Great to read you again.

    As a QA Manager for many years now, i can see and learn who is a good programmer and who is not.
    From my experiences the first rule is- do not harm things which already work (regression). a programmer who hurts a already-working-code is hurting the entire application and the sad thing is that sometimes no one will find it until it gets to the customer which is BAD BAD BAD.
    Got the point?

  • Harald M.

    It’s not “speed or elegance”. If you want to compress the choice to a short phrase, it’s rather speed or maintainability.

    I can program quite elegantly (I’m a theoretically-inclined programmer and software archtiect). However, elegance is not a value in itself (in programming; maybe it is in mathematics). Elegance is a muddy term that encompasses things like DRY, concise-but-not-too-conciseness, clear abstractions and hence clear testability: But it is better to spell out these (and other) different aspects explicitly.

    And with this in mind it is, at times, possible to be both fast and yet create maintainable designs and code.

  • https://sites.google.com/site/mydreamchurch/ Anil

    I wasted 10 minutes of my life reading and replying here – I was hoping there would be insightful stuff here.

  • Julian

    You know I’ve been programming since I was seven years old now Im 34 and I think that I really suck just because my production rate.. I try to write code as elegant as is possible…. as good as it gets, my production has fallen to the realm of hades.

    So my advice : Only if you are not working on embedded systems design, linux kernel, RT OS design, aka low level stuff, do not be elegant, be whatever you want to be, be productive, the non comment type. The drawback of being productive in such a way? Well, the day that you would need your code to be changed will come, however, with the rythm code tech is changin (not growing, just changing) chances are your code is going to be replaced without reason… simply something new would be implemented….

  • Pingback: Software, Technology, Business & Life » Blog Archive » “I am a terrible programmer”

  • Pingback: Issue 26 – Startup Anthropology – What’s Your Tribe? — TLN

  • turbosqel

    I think it depends who You asking … Because for client good coders is fast and reliable guy , even if he made a mess in code . As long as app works fine , You are good programmer for client . But if someone will continue upgrading/changing/fixing app after You , he will judge by coding style and readability .

    Simply says – best is guy that work fast and think about code like someone else would have to finish it .

  • AustinCoder

    Thanks for the great post. I also code things fast when they are needed that way and at times felt I was doing a dis-service by not leaning towards elegance. Now I feel encouraged that I have been a practical programmer.

    I like that you named your company Firefly. I hope it is in reference to the best Sci Fi show and movie ever. Browncoats unite!!

  • Pingback: Tom Medhurst – Design Weekly #43

  • Michael

    You might be a terrible programmer indeed ;-) since you’re getting one key thing wrong:

    It’s not about beauty vs. speed, but it’s all about maintainability and solid architecture to build upon.
    And maintainable code is *never ever* ugly or hacked together.

  • Pingback: 我是一个混蛋程序员 | PHP程序猿

  • Pingback: 我是一个混蛋程序员 | HTML5工作室

  • Pingback: 【技术新闻】我是一个混蛋程序员 « Jhonse – 技术博客

  • A fish

    sounds intresting

  • Pingback: Why Founders Shouldn't Be Developers - Zemanta Blog

  • Pingback: Akademická technologická masturbácia | Cifro Nix

  • Pingback: g33ktalk Weekly Nov 15

 
x

Never miss a new post