8 ms·

I am a terrible programmer

245 points by ScotterC 14y ago

ScotterC 14y ago
This is what I loved about working with Dan in those early days of Artsicle. He cared about shipping more then anything else. He was a rabid hacker who pushed out code even if it was crappy but it got us to the understanding we needed so we could move on to the next milestone.
mgkimsal 14y ago
The 'definition' aspect is key, but also the context or project. For startup/rev1 web products, no doubt Dan's abilities are paramount. Would I want that same "ship it now" hacker ethic at work on a flight system? Or a heart monitor? Hell no. Context matters.
- tluyben2 14y ago
  Any critical (real time) system, no. Most other systems; with lack of other means, sure. At least he ships and it runs; my last experience with the 'outsourcing team' of HP was that the (> 1 million loc) system did not only not work (after shipping), it contained numerous sections which cannot work and will never work. I wish it would be different, but it's not unfortunately.
- greenyoda 14y ago
  It's not just life-critical systems that require good code. Any large code base that has multiple developers and a long lifetime will quickly degrade into chaos unless the developers take the time to write understandable and maintainable code and refactor it when necessary. And after a few years, all the original developers may have moved on, but people still depend on being able to evolve the code to handle new business needs. It sounds like the author of the article has never had to deal with any of these issues. That doesn't make him a bad person, but it does mean that his advice shouldn't carry a lot of weight.
  - mgkimsal 14y ago
    The 'life-critical' was just an extreme example. I agree with your point, but also agree with the OP, sort of. What needs to happen is that everyone involved understands the tradeoffs inherent in 'ship it now' approaches. Yes, no one can predict the future entirely, but sometimes you can be pretty sure that the 'fast and dirty' approach is actually OK to take.
    - Draiken 14y ago
      This only applies to this new wave of "ship it" these days. From what I've seen, it's pretty much just in web/mobile development. I doubt Torvalds produces (or produced) quick dirty code to "make stuff happen", and I also bet he's a hell of a programmer. As stated by someone before, shipping stuff fast makes you a good "product builder", not a good programmer.
ssebro 14y ago
Context is what matters here. You're a terrible programmer for established businesses building products they know people want (so it has to be rock solid and easy to maintain/upgrade). But you're great at churning out MVPs, which is really all startups need. The second a startup moves from an MVP, it no longer is a startup - they've proven their business and are building things like betas, where they know exactly what users want and are delivering on that.
- tluyben2 14y ago
  Having seen millions of lines of code for 'established business building products' I don't see that at all. I understand it, but hardly ever see it in practice. Code is generally 'bad' unless it has been refactored a lot (!) of times. Which most systems don't undergo as it's not a business concern (agile) for management.
  - greenyoda 14y ago
    It's not a concern for management until the code becomes so hard to maintain that adding the simplest feature takes months and introduces dozens of bugs.
    - mattdeboard 14y ago
      So very damn true. I'm trying to unclusterf*ck this in our codebase.
      - tluyben2 14y ago
        Yep. That's why I think people are slightly naive thinking that 'code in bigger companies' (vs MVP/startups) is generally good. I believe, from experience and anecdotal evidence, that it's generally not and that OP should just rather deliver than worry about 'bad programming'.
- jbattle 14y ago
  It's harder than that, because it can take years of trying out new features & products before a company really matures and/or ossifies. So you can be in that awkward middle zone for a relatively long time where you don't have the time or resources to build things exactly right, but you might just find something taking off and becoming a core part of the company's technology stack. Takes a lot of wisdom, discipline, and not a little luck to know where to invest deeply in building robust software and where to get something done quickly so you can start testing it in the marketplace.
calinet6 14y ago
I think there is some confusion over quality vs. quantity. You can ship all the code you want, but even if it's lots of mediocre code, it's still mediocre. Quality is independent of quantity or productivity. You may choose to lower your quality in favor of a higher rate of productivity, but you've still lowered your quality. So you may be a productive programmer. But that doesn't necessarily make you a good one. There's also the matter of the quality of code that your'e capable of, versus the quality you actually produce. So you may be a very good programmer forced into producing shitty code (time constraints often do this). But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer.
- xauronx 14y ago
  >But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer. So, the perfect programmer is a better programmer? That goes without saying. I think his post is more an issue of people who build things vs. people who can code algorithms. Personally, I'm the former and as such naturally think it's superior. Let's face it, we can't all be perfect programmers. There's the developer who can register a domain, set up a LAMP server, get a web application up, create a good database schema and make it look nice and do it all in a weekend. Then there's the programmer who will come in and look at one portion of a less-used paged and call you a shitty programmer because you did it in O(n^2) when using THIS clever algorithm you could do it in O(n). It depends on what your focus is I suppose. The question is whether or not I (or the author of the article) would be able to optimize that chunk of code if the user experienced slowness.
  - JonnieCache 14y ago
    >call you a shitty programmer because you did it in O(n^2) when using THIS clever algorithm you could do it in O(n). Nope, they'll call you a shitty programmer because every function in your codebase depends on the interface of every other function. Then they'll charge you a fortune to fix it.
    - 14y ago
edw519 14y ago
My default response to any "good programmer, bad programmer" post: A smart accountant once told me that the answer to "How much money did you make?" is always, "Who wants to know?" If it's an investor, the answer is "A lot." If it's a customer, the answer is "A little." If it's the IRS, the answer is "None." Same thing here. The answer to "Who is a good programmer?" is always, "Who wants to know?" To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. To a customer, the programmer who solves their problem quickest is a good programmer. To a business owner, the programmer who makes them the most money is a good programmer. To a PHB, the programmer who makes them look the best is a good programmer. To a journalist, the programmer who tells the best stories is a good programmer. To a junior programmer, the best mentor is the good programmer. To another programmer, the programmer they are most likely to want to go into battle with is a good programmer. To a blogger, the programmer who best fits the profile of the point he is trying to make is a good programmer.
- batgaijin 14y ago
  Hey edw519, I've read a lot of your posts and I was wondering if you could point me at a repo of some of your code; I'd love to read it.
  - mcknz 14y ago
    http://edweissman.com/53640595 http://edweissman.com/53640595 -- or check his profile.
    - mcknz 14y ago
      sorry, you asked for code and i sent you to the ebook. :P
  - Evbn 14y ago
    Do you want to see Scott Adams's project status reports too? Just enjoy the stories.
  - swah 14y ago
    "I never publish my code. Ever. Users get to give me feedback, but I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. I learn from the code of others and apply those lessons to my own work" (from here: http://news.ycombinator.com/item?id=2096007 http://news.ycombinator.com/item?id=2096007)
sgdesign 14y ago
As a designer, I can certainly say there are tons of designers who ship ugly designs. Do those designs convert well? Sure. Is the client happy? Yep. Does that make them good designers? No, definitely not.
- kylec 14y ago
  I think programming's a bit different - with an ugly design, the customers see it and know it's ugly. If a software application works fast and flawlessly, the customer sees that it just works, and it doesn't matter if the code has been neatly organized and arranged underneath.
deleted 14y ago
[deleted]
grandalf 14y ago
I wish more programmers/hackers had the courage to show off their ugly code and admit to the early stages of the creative process. The Ruby community has a great emphasis on beautiful, elegant code, but how many first commit trees on github are actually after hundreds of hours were spent, a good percentage of which involved beautifying and organizing. I definitely prefer to read clean, well organized code, but I'd also like to read the first attempts and the discarded approaches used by the hackers I admire.
- ScotterC 14y ago
  Even the people I don't admire - I'd like to see it. The struggle of course is that your afraid that people will judge you for it. There's a lot of code I haven't pushed openly because of that reason. It's like publishing a blog post or submitting a paper in school. We have a base level of personal standards. I've been trying to get over it and publish because no matter what it leads to good discussion if it is looked at.
  - Evbn 14y ago
    No way anyone cares about you enough to judge for the ugliness of your free code. Unless you are Obama or Trump or Ferris or something.
- jetti 14y ago
  I agree. For the longest time my github had little in it except school projects. I finally decided to use it for personal stuff, or more like got used to the idea that my code would be public. I put up a few projects and even then, I didn't do anything to even try to show them off. This is because of the fear of being judged and because in my mind I'm not nearly as good as the people here or the people who post on /r/programming. Eventually, I posted my projects to a few sites and while the feedback wasn't "oh this is great", it was feedback nonetheless and I was able to take it and improve my project and myself. I guess where I'm going with this is that for those who are beginning or come from a non-CS background, seeing all this polished code, even in initial commits, being posted to sites like HN or reddit is very intimidating and could be a drawback from people sharing their code.
stephengillie 14y ago
This blog post reveals more about its authors insecurities than it provides in insight to the rest of us. If you're good enough at what you do that you have time to blog your inner debates about how good you are, you're good enough to need more important things to do.
- pyrotechnick 14y ago
  This comment reveals more about its authors comments than it provides in commentary to the rest of the comments. If you're commentative enough at what you comment that you have time to comment on your inner comments about how good you comment, you're commentative enough to need more commenty comments to comment.
  - jonsterling 14y ago
    Oh, hush now.
- xutopia 14y ago
  Get off your high horse! Lots of successful people have inner debates about how they deserve such success. It's called the imposter syndrome.
  - stephengillie 14y ago
    I know! I do too! This is my way of helping myself stop, and hopefully helping others stop too. All of that insecurity and worry is very unproductive.
- kamjam 14y ago
  So you're saying only people who are rubbish at what they do should be blogging? Surely that's what YouTube is for, people with no talent to post some random rubbish about something that nobody actually cares about?
  - stephengillie 14y ago
debacle 14y ago
I'm of the strong opinion that if your code is encapsulated, it's pretty okay for it to be entirely shite as long as it works. If someone needs to maintain it, and that someone isn't you, it's very likely they're going to understand your shite stream-of-consciousness code much more easily than your beautiful, elegant code that has had all of the thought process refactored out of it (but refactoring is a very important tool).
- pyrotechnick 14y ago
  I'll happily accept code that's a product of this mentality (+ tests) over jargon-ladened "zen" code. We too often forget our code sits atop a stack of compounding encapsulations we'd all find horrifically disgusting whose only true merit is that it actually functions.
- gutnor 14y ago
  If your code is less clear after refactoring than before, you have gone a step too far in refactoring. Your goals when refactoring is removing useless bit of code, make the code understandable without comment and remove duplication. That is the last step that generally requires introducing additional abstractions layers and where stuff go wrong. Too often refactoring books or articles give examples of how to use refactoring technique, but for the sake of being readable, the examples rarely really require such refactoring in the first place. But yeah, at the end of the day I also prefer a hackish piece of code that solves the problem than the same "refactored" into conceptual art.
desireco42 14y ago
You and me together.
JonnieCache 14y ago
All this talk of beauty and elegance is missing one key point: it's not just an aesthetic matter. Beautiful code is beautiful because it implements some theoretical design concept that makes it easier to maintain and more performant. The fact that it happens to look nice when you do that is down to the design of the language itself.
- Evbn 14y ago
  Beautiful performant code does not exist in a large system. The languages just don't exist to express it.
heelhook 14y ago
I believe the mistake here is attempting to assert your skills in a single continuum, bad or good. Like you say, and others comment, bad-good are relative terms that vary widely depending on context. I would like someone like you, with a quick turnaround on features for early products and prototypes but such personæ wouldn't be my first pick for a stable or mature product where quality is paramount to speed. Its all relative. FWIW, I believe you are too quick to dismiss sound theoretical background, and I say that as a college drop out who had to fire PhD students from his team in the past. Theory is important and, given the right context, I'll go with the academic type, with slower turnaround that will take months to deliver a single feature. > The answer is: a good coder knows when something should be quick and dirty, and when > something should be thorough and clean. From my experience, people tend to be better at one than the other, its not a simple switch in your brain that you turn on and say "ok, now this part is important so I'm going to be much more careful here". From what I've seen, a prototyper is, at the same level of competence, worse at being thorough with documentation/well thought-out data models/corner case handling/etc.
alexkearns 14y ago
I think some programmers focus on the code, while others focus on the end product. It is a philosophical difference. The first make great employees. The latter make great start-up founders.
- kamjam 14y ago
  Not necessarily. The first may cause you to miss deadlines, piss of clients and ultimately lose the company money because you focused on code... I think it is important to balance both. But I get (and agree) with your point.
- Firehed 14y ago
  I don't think it's nearly that cut-and-dry. The most elegant code in the world is pointless if it doesn't solve a real problem (the end product), and the an unmaintainable and unscalable mess of crap that actually shipped on time is equally pointless if it's so broken that user's can't use the product or developers can't improve upon it. Great people need to find a balance, and I don't think leaning towards one side or another shows whether someone would be a great employee and/or founder. This "ship early/ship often" and "move fast and break stuff" attitude is ok for immature products, but there's still a minimum level of quality you need to reach, and as your userbase grows and your product matures, it's almost certainly going to be important to raise the bar on quality. Shipping prototypes is fine, but you have to keep in mind that if it catches on, your plan to rebuild a non-crap version (invariably you had this plan) will fall through because something else came up. My rule of thumb for prototypes is to get the data models close to right, and untangle the rest later. Pulling apart spaghetti code isn't too bad as long as there's reasonably sane intent behind it. I can fix systems where people are updating state from the views and writing to the db in all sorts of unimaginable, horrible ways; however, if you're not storing the right info, you're pretty screwed and have a hell of a migration process in your future.
  - alexkearns 14y ago
    Just because you focus on the product does not mean you ship bad code. Nor does a focus on the code mean you ignore the product. I see it more of a philosophical thing - what excites you most? Writing a highly efficient, perfectly formed piece of code; or creating a product that others use.
richardlblair 14y ago
I agree with the author here. A huge part of being a good programmer is knowing when to just solve a problem quick and dirty, and when to really plan it out and implement a beautiful design. Either way, if the programmer is making the right decision most of the time they should feel good about the work they are doing. At the end of the day we provide value. Provide value to the right people at the right time and you will have a good career.
S4M 14y ago
http://www.lambdassociates.org/blog/hackers.htm http://www.lambdassociates.org/blog/hackers.htm Mark Tarver compares "street programmers" (people like the OP before he started to take some CS courses) and people who focus in Computer Science without practical (industrial) coding.
hcarvalhoalves 14y ago
Truth be told, horrible JS tends to be the norm because people more often than not just need to wing something in it.
albumedia 14y ago
In Engineering we learn about a "black box" - a device that accepts an input and return an output. We couldn't careless about the parts/components inside that black box. Sometimes we have to treat programming like a black box. All we care about is getting the desired output. There will always be time to make the code efficient later. The end user and manager only care about the output.
- splicer 14y ago
  If there's a bug, and you have to wade through 10K+ lines of utter shit to fix it, WITHOUT causing a regression, you're screwed. The "black box" mentality works fine for prototyping, but once you've got a working prototype, you should throw out the prototype and write a clean, MAINTAINABLE system from scratch.
  - Evbn 14y ago
    Ah yes, the second system. To great effect. See the Netscape 5 rewrite, a great example.
pharrington 14y ago
A bit off topic, but this got me wondering: is there any field of study dedicated to quantifying multidimensional, fairly subjective measures (like one's quality as a programmer)? Just intuitively it seems like there's some process in general to map out a subject's traits across multiple dimensions, assess those in a variety of multidimensional contexts, and convey the results in a natural-language way, but I've never seen this talked about in articles like the OP's :\
- mogrim 14y ago
  There's the field of empirical computer science (for example http://www.cs.jhu.edu/~nasmith/erm/ http://www.cs.jhu.edu/~nasmith/erm/) - and I've seen a couple of articles recently pushing for a more evidence-based approach to methodology. No links, I'm afraid - can't find any - but it is out there. Edit: the link I included is more to do with algorithms and the like, mea culpa, but there are also studies cited in books like Code Complete that cover what you mention. How recent, or how good the research is, is another matter...
  - pharrington 14y ago
    Thanks, it's a start.
Void_ 14y ago
Part of being a good programmer is writing bad code sometimes.
- jonnycoder 14y ago
  Not just writing bad code, but learning from the bad code so you can solve a similar problem in the future with better code.
- lttlrck 14y ago
  Part of being a good programmer is knowing when you are writing bad code. In my mind its subtlety different, I never plan to write bad code, but sometimes it just turns out that way because of a tiny initial bad decision. That is what sets good and bad programmers apart. Bad programmer have no clue that they are writing terrible code.
lutusp 14y ago
> In general, my priority since I started coding 10 years ago has been speed. Which meaning of speed? You can write fast programs, and you can write programs fast, but you can't write fast programs fast.
marcamillion 14y ago
Thank you for this Dan. You are very right. The subtitle for this should be: "An ode to everyone that has gotten flamed on Stack Overflow or IRC for 'bad code'".
huhtenberg 14y ago
Right, right, right. Sorry, bud, I worked with a couple of guys like you before - very bright, smart, self-confident, young, yet started coding before they started drinking, but with not a lot of mileage in the industry - and the problem was that this style of work is not compatible with other people. It's great for prototyping. It's great when you work alone, but it's a nightmare in a true team environment and the resulting code is nothing but a headache in a long term. I'm sure you can ship, but that's hardly an achievement. Everyone one can, but shipped out shit in a working condition is akin to all that Made in China crap from Walmart. Nothing to be proud of to put it mildly. > So next time you’re working on a project, give some thought to what’s most important: speed or elegance. It's "Fast, cheap, good - pick two" and "You get what you paid for".
- benihana 14y ago
  This post just completely rubbed me the wrong way. It came off as an arrogant boast by an immature developer framed as an admission of shortcomings. But it was only an admission of shortcomings in title. He spends the majority of the post tooting his own horn about how people want to hire him, and how he's actually a good programmer because he ships code, and because he's worked at startups. He keeps posing these meatball questions and then answers them in a way that makes him look as good as possible but doesn't really provide an answer to the question "what makes a good programmer" (probably because it's a loaded question and depends on context). He's just setting himself up to say "a good programmer is like me because in this example I did a certain thing that made sense at the time." He also mentions that he's a college junior at least three times on that page and makes sure that we all know that all this insight and maturity is coming from someone still in college who's not even studying computer science! >Sorry, bud, I worked with a couple of guys like you before - very bright, smart, self-confident, young, yet started coding before they started drinking, but with not a lot of mileage in the industry - and the problem was that this style of work is not compatible with other people. Me too. And it's not just the code they write that's a headache - they're usually a pain in the ass to work with because they always know way more than everyone about everything. They know more about algorithms, they know more about software engineering, they know more about software design, they know more about human nature and the industry. They even know more about things they know nothing about. Meh.
ukapu 14y ago
Reminds me of the quote by one author (I think it was Stephen King but I'm not sure). "I don't get paid to write books. I get paid to finish them."
jbail 14y ago
This article presents a false dichotomy. There is no reason why you need to sacrifice code quality for the sake of speed of development. "Getting things done" is a hugely valuable skill, but don't conflate having that skill with meaning you are too busy to code clean. Productivity and beautiful code are not mutually exclusive. I write very nice, commented JavaScript that employs consistent whitespace and indentation and validates in JSLint all day long. That's just how I do it and I'm way faster than the coworkers of mine who code things quick and dirty. You reach a certain level of expertise and your code will just naturally have these qualities. It will be both beautiful and will be developed quickly. Senior talent gets this. Junior talent doesn't. This was a thought provoking article though. The main takeaway is that "getting things done" is the most important skill a programmer can have which I completely agree with. For the sake of other developer's sanity, clean code is so important too. Ugly, sloppy code takes longer to read, more effort to maintain and is frankly demoralizing and tiresome to work with. Clean code for me is probably right underneath getting things done on a skills ranking. Ideally, good developers would have both...and my experience shows that good developers do.
- Evbn 14y ago
  If I had a nickel for every lint-clean properly indented file of spaghetti code I saw, I would have.... to be at my job, where we have tools and rules for surface appearance, but no accounting for quality in depth.
  - jbail 14y ago
    This is why peer reviews are so important. Simply running code through JSLint and then making sure its formatted correctly is only step one.
SwearWord 14y ago
Why do these posts get up voted. It's all just masturbation.
pharrington 14y ago
Can someone point me to some examples of software that's non-trivial, stable, performant and fairly bug-free, yet coded like trash because it was rushed out the door as quickly as possible?
- Evbn 14y ago
  Verything written in the language of DNA. It has some bugs, but generally not system-fatal showstoppers.
charlesju 14y ago
http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html http://www.codinghorror.com/blog/2009/02/paying-down-your-te... I am surprised that no one has talked about technical debt yet. This is a classic case of taking technical debt for productivity. Like all forms of debt, some of it is good, it's leverage on your time (ie. you spend less time making it perfect, and more go to market faster), but you need to pay it back at some point in the future. The key difference between what the author espouses and a good programmer, is that the good programmer makes the conscious choice to accrue the debt in favor of speed and creates an action plan to pay off the debt at a later time. I do not believe that you can become an a good programmer until you can understand the distinction, make the proper trade-offs necessary to hit project objectives and create an action plan along the way to pay off the debt in the future.
matwood 14y ago
When it comes to entrepreneurship, programming ability is secondary to shipping a product. Real Artists Ship. [1] [1] http://www.folklore.org/StoryView.py?story=Real_Artists_Ship.txt http://www.folklore.org/StoryView.py?story=Real_Artists_Ship...
deleted 14y ago
[deleted]
joewee 14y ago
Even terrible code written by terrible programmers can earn wonderful profits.
paupino_masano 14y ago
Having been in a startup before: I'm not sure how I feel about this... In regards to getting features out quickly: that's a great programmer. Though inevitably there comes a time when the code needs to be maintained - and if it is unmaintainable then I'd put you in the bad programmer category. Now-a-days: I prefer clean code to a specific coding standard over the quick, dirty features being implemented. But, only because it usually causes more pain in the long run. I understand the "getting a feature out quickly to test it even works" mentality, and to some degree I agree with it. However, if it DOES work then a clean code base is always better. Inevitably it will need to be maintained... After writing this (sorry: could rewrite my comment but decided not to) I've now realized that I'm now AGAINST the feature push mentality. I'd much prefer well written code and eat up the cost then rather than later on. Worst case scenario, it can then be reused...
Cieplak 14y ago
The answer is: a good coder knows when something should be quick and dirty, and when something should be thorough and clean.
hobb0001 14y ago
Having your code still work 20 months after you wrote it really isn't much to boast about.
- Evbn 14y ago
  As the saying goes, bad code falls apart in 3 months. Google code falls apart in 6 months.
dpiers 14y ago
I made games while I was in school. Lots of games. PC games, iOS/Android games, and even some homebrew 360/PS3 games. All of those games helped me get the attention of technical directors at a couple of studios and got me my first two internships and eventually a job as an engine programmer on a multi-platform game engine. But the code in those games was crap. Looking back on the early stuff, I am amazed it even compiled. It wasn't until I had to work on a +500k LOC codebase with 30 other programmers for a year and a half that I learned the importance of writing code that can be easily read, understood, and modified by other programmers (or even myself) six months after it was written. Writing maintainable code is a skill that comes naturally to every good developer after they have to work on the same code base for an extended period of time. Dan hasn't had time to do that because he's shipped 20 different apps in the last 2 years, but now that he's working on his own startup (and will be for the foreseeable future) it sounds like he's learning the value of elegant code.
dkoehler 14y ago
I've seen quite a lot of debate with hard lines of what defines "good" code. In my admittedly limited experience, I've found that the definition of "good" varies with the situation in which the code is written. "Good" in my opinion is not something that has a concrete definition. It's entirely dependent on the requirements of the project, and how the developer meets them. -Sometimes this means a programmer can drop into the style already in use on a project, even if it's not the 'best' approach. That way his changes are low-impact and can be easily understood by the people who have worked in the system for years. -Sometimes this means the programmer needs to architect a complex solution to a hard problem. (Though I think this is an assumption we make far too frequently.) -Sometimes this means the programmer should spend some time understanding the constraints on the project, and express them in code. If a constraint is acceptable at least until the next major version of a piece of software, then why not focus on making it simple to alter the assumption, rather than adding complexity to avoid the assumption completely? -And sometimes, this really does just mean "Ship that mess by next Friday", regardless of the cost. Sometimes it's just more important to get a poorly architected version in the hands of users that just does what it says on the tin, especially if their input could drastically change your requirements.

245 points by ScotterC 14y ago

This is what I loved about working with Dan in those early days of Artsicle. He cared about shipping more then anything else. He was a rabid hacker who pushed out code even if it was crappy but it got us to the understanding we needed so we could move on to the next milestone.

mgkimsal 14y ago

The 'definition' aspect is key, but also the context or project. For startup/rev1 web products, no doubt Dan's abilities are paramount. Would I want that same "ship it now" hacker ethic at work on a flight system? Or a heart monitor? Hell no. Context matters.

tluyben2 14y ago
Any critical (real time) system, no. Most other systems; with lack of other means, sure. At least he ships and it runs; my last experience with the 'outsourcing team' of HP was that the (> 1 million loc) system did not only not work (after shipping), it contained numerous sections which cannot work and will never work. I wish it would be different, but it's not unfortunately.
greenyoda 14y ago
It's not just life-critical systems that require good code. Any large code base that has multiple developers and a long lifetime will quickly degrade into chaos unless the developers take the time to write understandable and maintainable code and refactor it when necessary. And after a few years, all the original developers may have moved on, but people still depend on being able to evolve the code to handle new business needs. It sounds like the author of the article has never had to deal with any of these issues. That doesn't make him a bad person, but it does mean that his advice shouldn't carry a lot of weight.
- mgkimsal 14y ago
  The 'life-critical' was just an extreme example. I agree with your point, but also agree with the OP, sort of. What needs to happen is that everyone involved understands the tradeoffs inherent in 'ship it now' approaches. Yes, no one can predict the future entirely, but sometimes you can be pretty sure that the 'fast and dirty' approach is actually OK to take.
  - Draiken 14y ago
    This only applies to this new wave of "ship it" these days. From what I've seen, it's pretty much just in web/mobile development. I doubt Torvalds produces (or produced) quick dirty code to "make stuff happen", and I also bet he's a hell of a programmer. As stated by someone before, shipping stuff fast makes you a good "product builder", not a good programmer.

ssebro 14y ago

Context is what matters here. You're a terrible programmer for established businesses building products they know people want (so it has to be rock solid and easy to maintain/upgrade). But you're great at churning out MVPs, which is really all startups need. The second a startup moves from an MVP, it no longer is a startup - they've proven their business and are building things like betas, where they know exactly what users want and are delivering on that.

tluyben2 14y ago
Having seen millions of lines of code for 'established business building products' I don't see that at all. I understand it, but hardly ever see it in practice. Code is generally 'bad' unless it has been refactored a lot (!) of times. Which most systems don't undergo as it's not a business concern (agile) for management.
- greenyoda 14y ago
  It's not a concern for management until the code becomes so hard to maintain that adding the simplest feature takes months and introduces dozens of bugs.
  - mattdeboard 14y ago
    So very damn true. I'm trying to unclusterf*ck this in our codebase.
    - tluyben2 14y ago
      Yep. That's why I think people are slightly naive thinking that 'code in bigger companies' (vs MVP/startups) is generally good. I believe, from experience and anecdotal evidence, that it's generally not and that OP should just rather deliver than worry about 'bad programming'.
jbattle 14y ago
It's harder than that, because it can take years of trying out new features & products before a company really matures and/or ossifies. So you can be in that awkward middle zone for a relatively long time where you don't have the time or resources to build things exactly right, but you might just find something taking off and becoming a core part of the company's technology stack. Takes a lot of wisdom, discipline, and not a little luck to know where to invest deeply in building robust software and where to get something done quickly so you can start testing it in the marketplace.

calinet6 14y ago

I think there is some confusion over quality vs. quantity. You can ship all the code you want, but even if it's lots of mediocre code, it's still mediocre. Quality is independent of quantity or productivity. You may choose to lower your quality in favor of a higher rate of productivity, but you've still lowered your quality. So you may be a productive programmer. But that doesn't necessarily make you a good one. There's also the matter of the quality of code that your'e capable of, versus the quality you actually produce. So you may be a very good programmer forced into producing shitty code (time constraints often do this). But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer.

xauronx 14y ago
>But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer. So, the perfect programmer is a better programmer? That goes without saying. I think his post is more an issue of people who build things vs. people who can code algorithms. Personally, I'm the former and as such naturally think it's superior. Let's face it, we can't all be perfect programmers. There's the developer who can register a domain, set up a LAMP server, get a web application up, create a good database schema and make it look nice and do it all in a weekend. Then there's the programmer who will come in and look at one portion of a less-used paged and call you a shitty programmer because you did it in O(n^2) when using THIS clever algorithm you could do it in O(n). It depends on what your focus is I suppose. The question is whether or not I (or the author of the article) would be able to optimize that chunk of code if the user experienced slowness.
- JonnieCache 14y ago
  >call you a shitty programmer because you did it in O(n^2) when using THIS clever algorithm you could do it in O(n). Nope, they'll call you a shitty programmer because every function in your codebase depends on the interface of every other function. Then they'll charge you a fortune to fix it.
  - 14y ago

edw519 14y ago

My default response to any "good programmer, bad programmer" post: A smart accountant once told me that the answer to "How much money did you make?" is always, "Who wants to know?" If it's an investor, the answer is "A lot." If it's a customer, the answer is "A little." If it's the IRS, the answer is "None." Same thing here. The answer to "Who is a good programmer?" is always, "Who wants to know?" To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. To a customer, the programmer who solves their problem quickest is a good programmer. To a business owner, the programmer who makes them the most money is a good programmer. To a PHB, the programmer who makes them look the best is a good programmer. To a journalist, the programmer who tells the best stories is a good programmer. To a junior programmer, the best mentor is the good programmer. To another programmer, the programmer they are most likely to want to go into battle with is a good programmer. To a blogger, the programmer who best fits the profile of the point he is trying to make is a good programmer.

batgaijin 14y ago
Hey edw519, I've read a lot of your posts and I was wondering if you could point me at a repo of some of your code; I'd love to read it.
- mcknz 14y ago
  http://edweissman.com/53640595 http://edweissman.com/53640595 -- or check his profile.
  - mcknz 14y ago
    sorry, you asked for code and i sent you to the ebook. :P
- Evbn 14y ago
  Do you want to see Scott Adams's project status reports too? Just enjoy the stories.
- swah 14y ago
  "I never publish my code. Ever. Users get to give me feedback, but I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. I learn from the code of others and apply those lessons to my own work" (from here: http://news.ycombinator.com/item?id=2096007 http://news.ycombinator.com/item?id=2096007)

sgdesign 14y ago

As a designer, I can certainly say there are tons of designers who ship ugly designs. Do those designs convert well? Sure. Is the client happy? Yep. Does that make them good designers? No, definitely not.

kylec 14y ago
I think programming's a bit different - with an ugly design, the customers see it and know it's ugly. If a software application works fast and flawlessly, the customer sees that it just works, and it doesn't matter if the code has been neatly organized and arranged underneath.

deleted 14y ago

[deleted]

grandalf 14y ago

I wish more programmers/hackers had the courage to show off their ugly code and admit to the early stages of the creative process. The Ruby community has a great emphasis on beautiful, elegant code, but how many first commit trees on github are actually after hundreds of hours were spent, a good percentage of which involved beautifying and organizing. I definitely prefer to read clean, well organized code, but I'd also like to read the first attempts and the discarded approaches used by the hackers I admire.

ScotterC 14y ago
Even the people I don't admire - I'd like to see it. The struggle of course is that your afraid that people will judge you for it. There's a lot of code I haven't pushed openly because of that reason. It's like publishing a blog post or submitting a paper in school. We have a base level of personal standards. I've been trying to get over it and publish because no matter what it leads to good discussion if it is looked at.
- Evbn 14y ago
  No way anyone cares about you enough to judge for the ugliness of your free code. Unless you are Obama or Trump or Ferris or something.
jetti 14y ago
I agree. For the longest time my github had little in it except school projects. I finally decided to use it for personal stuff, or more like got used to the idea that my code would be public. I put up a few projects and even then, I didn't do anything to even try to show them off. This is because of the fear of being judged and because in my mind I'm not nearly as good as the people here or the people who post on /r/programming. Eventually, I posted my projects to a few sites and while the feedback wasn't "oh this is great", it was feedback nonetheless and I was able to take it and improve my project and myself. I guess where I'm going with this is that for those who are beginning or come from a non-CS background, seeing all this polished code, even in initial commits, being posted to sites like HN or reddit is very intimidating and could be a drawback from people sharing their code.

stephengillie 14y ago

This blog post reveals more about its authors insecurities than it provides in insight to the rest of us. If you're good enough at what you do that you have time to blog your inner debates about how good you are, you're good enough to need more important things to do.

pyrotechnick 14y ago
This comment reveals more about its authors comments than it provides in commentary to the rest of the comments. If you're commentative enough at what you comment that you have time to comment on your inner comments about how good you comment, you're commentative enough to need more commenty comments to comment.
- jonsterling 14y ago
  Oh, hush now.
xutopia 14y ago
Get off your high horse! Lots of successful people have inner debates about how they deserve such success. It's called the imposter syndrome.
- stephengillie 14y ago
  I know! I do too! This is my way of helping myself stop, and hopefully helping others stop too. All of that insecurity and worry is very unproductive.
kamjam 14y ago
So you're saying only people who are rubbish at what they do should be blogging? Surely that's what YouTube is for, people with no talent to post some random rubbish about something that nobody actually cares about?
- stephengillie 14y ago

debacle 14y ago

I'm of the strong opinion that if your code is encapsulated, it's pretty okay for it to be entirely shite as long as it works. If someone needs to maintain it, and that someone isn't you, it's very likely they're going to understand your shite stream-of-consciousness code much more easily than your beautiful, elegant code that has had all of the thought process refactored out of it (but refactoring is a very important tool).

pyrotechnick 14y ago
I'll happily accept code that's a product of this mentality (+ tests) over jargon-ladened "zen" code. We too often forget our code sits atop a stack of compounding encapsulations we'd all find horrifically disgusting whose only true merit is that it actually functions.
gutnor 14y ago
If your code is less clear after refactoring than before, you have gone a step too far in refactoring. Your goals when refactoring is removing useless bit of code, make the code understandable without comment and remove duplication. That is the last step that generally requires introducing additional abstractions layers and where stuff go wrong. Too often refactoring books or articles give examples of how to use refactoring technique, but for the sake of being readable, the examples rarely really require such refactoring in the first place. But yeah, at the end of the day I also prefer a hackish piece of code that solves the problem than the same "refactored" into conceptual art.

desireco42 14y ago

You and me together.

JonnieCache 14y ago

All this talk of beauty and elegance is missing one key point: it's not just an aesthetic matter. Beautiful code is beautiful because it implements some theoretical design concept that makes it easier to maintain and more performant. The fact that it happens to look nice when you do that is down to the design of the language itself.

Evbn 14y ago
Beautiful performant code does not exist in a large system. The languages just don't exist to express it.

heelhook 14y ago

I believe the mistake here is attempting to assert your skills in a single continuum, bad or good. Like you say, and others comment, bad-good are relative terms that vary widely depending on context. I would like someone like you, with a quick turnaround on features for early products and prototypes but such personæ wouldn't be my first pick for a stable or mature product where quality is paramount to speed. Its all relative. FWIW, I believe you are too quick to dismiss sound theoretical background, and I say that as a college drop out who had to fire PhD students from his team in the past. Theory is important and, given the right context, I'll go with the academic type, with slower turnaround that will take months to deliver a single feature. > The answer is: a good coder knows when something should be quick and dirty, and when > something should be thorough and clean. From my experience, people tend to be better at one than the other, its not a simple switch in your brain that you turn on and say "ok, now this part is important so I'm going to be much more careful here". From what I've seen, a prototyper is, at the same level of competence, worse at being thorough with documentation/well thought-out data models/corner case handling/etc.

alexkearns 14y ago

I think some programmers focus on the code, while others focus on the end product. It is a philosophical difference. The first make great employees. The latter make great start-up founders.

kamjam 14y ago
Not necessarily. The first may cause you to miss deadlines, piss of clients and ultimately lose the company money because you focused on code... I think it is important to balance both. But I get (and agree) with your point.
Firehed 14y ago
I don't think it's nearly that cut-and-dry. The most elegant code in the world is pointless if it doesn't solve a real problem (the end product), and the an unmaintainable and unscalable mess of crap that actually shipped on time is equally pointless if it's so broken that user's can't use the product or developers can't improve upon it. Great people need to find a balance, and I don't think leaning towards one side or another shows whether someone would be a great employee and/or founder. This "ship early/ship often" and "move fast and break stuff" attitude is ok for immature products, but there's still a minimum level of quality you need to reach, and as your userbase grows and your product matures, it's almost certainly going to be important to raise the bar on quality. Shipping prototypes is fine, but you have to keep in mind that if it catches on, your plan to rebuild a non-crap version (invariably you had this plan) will fall through because something else came up. My rule of thumb for prototypes is to get the data models close to right, and untangle the rest later. Pulling apart spaghetti code isn't too bad as long as there's reasonably sane intent behind it. I can fix systems where people are updating state from the views and writing to the db in all sorts of unimaginable, horrible ways; however, if you're not storing the right info, you're pretty screwed and have a hell of a migration process in your future.
- alexkearns 14y ago
  Just because you focus on the product does not mean you ship bad code. Nor does a focus on the code mean you ignore the product. I see it more of a philosophical thing - what excites you most? Writing a highly efficient, perfectly formed piece of code; or creating a product that others use.

richardlblair 14y ago

I agree with the author here. A huge part of being a good programmer is knowing when to just solve a problem quick and dirty, and when to really plan it out and implement a beautiful design. Either way, if the programmer is making the right decision most of the time they should feel good about the work they are doing. At the end of the day we provide value. Provide value to the right people at the right time and you will have a good career.

S4M 14y ago

http://www.lambdassociates.org/blog/hackers.htm http://www.lambdassociates.org/blog/hackers.htm Mark Tarver compares "street programmers" (people like the OP before he started to take some CS courses) and people who focus in Computer Science without practical (industrial) coding.

hcarvalhoalves 14y ago

Truth be told, horrible JS tends to be the norm because people more often than not just need to wing something in it.

albumedia 14y ago

In Engineering we learn about a "black box" - a device that accepts an input and return an output. We couldn't careless about the parts/components inside that black box. Sometimes we have to treat programming like a black box. All we care about is getting the desired output. There will always be time to make the code efficient later. The end user and manager only care about the output.

splicer 14y ago
If there's a bug, and you have to wade through 10K+ lines of utter shit to fix it, WITHOUT causing a regression, you're screwed. The "black box" mentality works fine for prototyping, but once you've got a working prototype, you should throw out the prototype and write a clean, MAINTAINABLE system from scratch.
- Evbn 14y ago
  Ah yes, the second system. To great effect. See the Netscape 5 rewrite, a great example.

pharrington 14y ago

A bit off topic, but this got me wondering: is there any field of study dedicated to quantifying multidimensional, fairly subjective measures (like one's quality as a programmer)? Just intuitively it seems like there's some process in general to map out a subject's traits across multiple dimensions, assess those in a variety of multidimensional contexts, and convey the results in a natural-language way, but I've never seen this talked about in articles like the OP's :\

mogrim 14y ago
There's the field of empirical computer science (for example http://www.cs.jhu.edu/~nasmith/erm/ http://www.cs.jhu.edu/~nasmith/erm/) - and I've seen a couple of articles recently pushing for a more evidence-based approach to methodology. No links, I'm afraid - can't find any - but it is out there. Edit: the link I included is more to do with algorithms and the like, mea culpa, but there are also studies cited in books like Code Complete that cover what you mention. How recent, or how good the research is, is another matter...
- pharrington 14y ago
  Thanks, it's a start.

Void_ 14y ago

Part of being a good programmer is writing bad code sometimes.

jonnycoder 14y ago
Not just writing bad code, but learning from the bad code so you can solve a similar problem in the future with better code.
lttlrck 14y ago
Part of being a good programmer is knowing when you are writing bad code. In my mind its subtlety different, I never plan to write bad code, but sometimes it just turns out that way because of a tiny initial bad decision. That is what sets good and bad programmers apart. Bad programmer have no clue that they are writing terrible code.

lutusp 14y ago

> In general, my priority since I started coding 10 years ago has been speed. Which meaning of speed? You can write fast programs, and you can write programs fast, but you can't write fast programs fast.

marcamillion 14y ago

Thank you for this Dan. You are very right. The subtitle for this should be: "An ode to everyone that has gotten flamed on Stack Overflow or IRC for 'bad code'".

huhtenberg 14y ago

Right, right, right. Sorry, bud, I worked with a couple of guys like you before - very bright, smart, self-confident, young, yet started coding before they started drinking, but with not a lot of mileage in the industry - and the problem was that this style of work is not compatible with other people. It's great for prototyping. It's great when you work alone, but it's a nightmare in a true team environment and the resulting code is nothing but a headache in a long term. I'm sure you can ship, but that's hardly an achievement. Everyone one can, but shipped out shit in a working condition is akin to all that Made in China crap from Walmart. Nothing to be proud of to put it mildly. > So next time you’re working on a project, give some thought to what’s most important: speed or elegance. It's "Fast, cheap, good - pick two" and "You get what you paid for".

benihana 14y ago
This post just completely rubbed me the wrong way. It came off as an arrogant boast by an immature developer framed as an admission of shortcomings. But it was only an admission of shortcomings in title. He spends the majority of the post tooting his own horn about how people want to hire him, and how he's actually a good programmer because he ships code, and because he's worked at startups. He keeps posing these meatball questions and then answers them in a way that makes him look as good as possible but doesn't really provide an answer to the question "what makes a good programmer" (probably because it's a loaded question and depends on context). He's just setting himself up to say "a good programmer is like me because in this example I did a certain thing that made sense at the time." He also mentions that he's a college junior at least three times on that page and makes sure that we all know that all this insight and maturity is coming from someone still in college who's not even studying computer science! >Sorry, bud, I worked with a couple of guys like you before - very bright, smart, self-confident, young, yet started coding before they started drinking, but with not a lot of mileage in the industry - and the problem was that this style of work is not compatible with other people. Me too. And it's not just the code they write that's a headache - they're usually a pain in the ass to work with because they always know way more than everyone about everything. They know more about algorithms, they know more about software engineering, they know more about software design, they know more about human nature and the industry. They even know more about things they know nothing about. Meh.

ukapu 14y ago

Reminds me of the quote by one author (I think it was Stephen King but I'm not sure). "I don't get paid to write books. I get paid to finish them."

jbail 14y ago

This article presents a false dichotomy. There is no reason why you need to sacrifice code quality for the sake of speed of development. "Getting things done" is a hugely valuable skill, but don't conflate having that skill with meaning you are too busy to code clean. Productivity and beautiful code are not mutually exclusive. I write very nice, commented JavaScript that employs consistent whitespace and indentation and validates in JSLint all day long. That's just how I do it and I'm way faster than the coworkers of mine who code things quick and dirty. You reach a certain level of expertise and your code will just naturally have these qualities. It will be both beautiful and will be developed quickly. Senior talent gets this. Junior talent doesn't. This was a thought provoking article though. The main takeaway is that "getting things done" is the most important skill a programmer can have which I completely agree with. For the sake of other developer's sanity, clean code is so important too. Ugly, sloppy code takes longer to read, more effort to maintain and is frankly demoralizing and tiresome to work with. Clean code for me is probably right underneath getting things done on a skills ranking. Ideally, good developers would have both...and my experience shows that good developers do.

Evbn 14y ago
If I had a nickel for every lint-clean properly indented file of spaghetti code I saw, I would have.... to be at my job, where we have tools and rules for surface appearance, but no accounting for quality in depth.
- jbail 14y ago
  This is why peer reviews are so important. Simply running code through JSLint and then making sure its formatted correctly is only step one.

SwearWord 14y ago

Why do these posts get up voted. It's all just masturbation.

pharrington 14y ago

Can someone point me to some examples of software that's non-trivial, stable, performant and fairly bug-free, yet coded like trash because it was rushed out the door as quickly as possible?

Evbn 14y ago
Verything written in the language of DNA. It has some bugs, but generally not system-fatal showstoppers.

charlesju 14y ago

http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html http://www.codinghorror.com/blog/2009/02/paying-down-your-te... I am surprised that no one has talked about technical debt yet. This is a classic case of taking technical debt for productivity. Like all forms of debt, some of it is good, it's leverage on your time (ie. you spend less time making it perfect, and more go to market faster), but you need to pay it back at some point in the future. The key difference between what the author espouses and a good programmer, is that the good programmer makes the conscious choice to accrue the debt in favor of speed and creates an action plan to pay off the debt at a later time. I do not believe that you can become an a good programmer until you can understand the distinction, make the proper trade-offs necessary to hit project objectives and create an action plan along the way to pay off the debt in the future.

matwood 14y ago

When it comes to entrepreneurship, programming ability is secondary to shipping a product. Real Artists Ship. [1] [1] http://www.folklore.org/StoryView.py?story=Real_Artists_Ship.txt http://www.folklore.org/StoryView.py?story=Real_Artists_Ship...

deleted 14y ago

[deleted]

joewee 14y ago

Even terrible code written by terrible programmers can earn wonderful profits.

paupino_masano 14y ago

Having been in a startup before: I'm not sure how I feel about this... In regards to getting features out quickly: that's a great programmer. Though inevitably there comes a time when the code needs to be maintained - and if it is unmaintainable then I'd put you in the bad programmer category. Now-a-days: I prefer clean code to a specific coding standard over the quick, dirty features being implemented. But, only because it usually causes more pain in the long run. I understand the "getting a feature out quickly to test it even works" mentality, and to some degree I agree with it. However, if it DOES work then a clean code base is always better. Inevitably it will need to be maintained... After writing this (sorry: could rewrite my comment but decided not to) I've now realized that I'm now AGAINST the feature push mentality. I'd much prefer well written code and eat up the cost then rather than later on. Worst case scenario, it can then be reused...

Cieplak 14y ago

The answer is: a good coder knows when something should be quick and dirty, and when something should be thorough and clean.

hobb0001 14y ago

Having your code still work 20 months after you wrote it really isn't much to boast about.

Evbn 14y ago
As the saying goes, bad code falls apart in 3 months. Google code falls apart in 6 months.

dpiers 14y ago

I made games while I was in school. Lots of games. PC games, iOS/Android games, and even some homebrew 360/PS3 games. All of those games helped me get the attention of technical directors at a couple of studios and got me my first two internships and eventually a job as an engine programmer on a multi-platform game engine. But the code in those games was crap. Looking back on the early stuff, I am amazed it even compiled. It wasn't until I had to work on a +500k LOC codebase with 30 other programmers for a year and a half that I learned the importance of writing code that can be easily read, understood, and modified by other programmers (or even myself) six months after it was written. Writing maintainable code is a skill that comes naturally to every good developer after they have to work on the same code base for an extended period of time. Dan hasn't had time to do that because he's shipped 20 different apps in the last 2 years, but now that he's working on his own startup (and will be for the foreseeable future) it sounds like he's learning the value of elegant code.

dkoehler 14y ago

I've seen quite a lot of debate with hard lines of what defines "good" code. In my admittedly limited experience, I've found that the definition of "good" varies with the situation in which the code is written. "Good" in my opinion is not something that has a concrete definition. It's entirely dependent on the requirements of the project, and how the developer meets them. -Sometimes this means a programmer can drop into the style already in use on a project, even if it's not the 'best' approach. That way his changes are low-impact and can be easily understood by the people who have worked in the system for years. -Sometimes this means the programmer needs to architect a complex solution to a hard problem. (Though I think this is an assumption we make far too frequently.) -Sometimes this means the programmer should spend some time understanding the constraints on the project, and express them in code. If a constraint is acceptable at least until the next major version of a piece of software, then why not focus on making it simple to alter the assumption, rather than adding complexity to avoid the assumption completely? -And sometimes, this really does just mean "Ship that mess by next Friday", regardless of the cost. Sometimes it's just more important to get a poorly architected version in the hands of users that just does what it says on the tin, especially if their input could drastically change your requirements.