My default response to any "good programmer, bad programmer" post:<p>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."<p>Same thing here. The answer to "Who is a good programmer?" is always, "Who wants to know?"<p>To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer.<p>To a customer, the programmer who solves their problem quickest is a good programmer.<p>To a business owner, the programmer who makes them the most money is a good programmer.<p>To a PHB, the programmer who makes them look the best is a good programmer.<p>To a journalist, the programmer who tells the best stories is a good programmer.<p>To a junior programmer, the best mentor is the good programmer.<p>To another programmer, the programmer they are most likely to want to go into battle with is a good programmer.<p>To a blogger, the programmer who best fits the profile of the point he is trying to make is a good programmer.
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.<p>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.<p>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.<p>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.
Right, right, right.<p>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 <i>nightmare</i> in a true team environment and the resulting code is nothing but a headache in a long term.<p>I'm sure you can ship, but that's hardly an achievement. Everyone one can, but shipped out <i>shit</i> in a working condition is akin to all that Made in China crap from Walmart. Nothing to be proud of to put it mildly.<p>> <i>So next time you’re working on a project, give some thought to what’s most important: speed or elegance.</i><p>It's "Fast, cheap, good - pick two" and "You get what you paid for".
I think there is some confusion over quality vs. quantity.<p>You can ship all the code you want, but even if it's <i>lots</i> of mediocre code, it's still mediocre.<p>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.<p>So you may be a productive programmer. But that doesn't necessarily make you a good one.<p>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).<p>But let me say this: a good programmer who consistently ships great, high quality code regardless of the situation is still a <i>better</i> programmer.
I wish more programmers/hackers had the courage to show off their ugly code and admit to the early stages of the creative process.<p>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.<p>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.
This blog post reveals more about its authors insecurities than it provides in insight to the rest of us.<p>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.
<a href="http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html" rel="nofollow">http://www.codinghorror.com/blog/2009/02/paying-down-your-te...</a><p>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.<p>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.<p>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.
The 'definition' aspect is key, but also the context or project.<p>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.<p>Context matters.
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.<p>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).
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.
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.
<a href="http://www.lambdassociates.org/blog/hackers.htm" rel="nofollow">http://www.lambdassociates.org/blog/hackers.htm</a><p>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.
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?
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.<p>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.<p>Its all relative.<p>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 <i>is</i> 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.<p>> The answer is: a good coder knows when something should be quick and dirty, and when
> something should be thorough and clean.<p>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.
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.<p>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.<p>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.
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.<p>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.<p>The end user and manager only care about the output.
Having been in a startup before: I'm not sure how I feel about this...<p>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.<p>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...<p>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...
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.<p>-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.<p>-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.)<p>-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?<p>-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.
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.
When it comes to entrepreneurship, programming ability is secondary to shipping a product. Real Artists Ship. [1]<p>[1] <a href="http://www.folklore.org/StoryView.py?story=Real_Artists_Ship.txt" rel="nofollow">http://www.folklore.org/StoryView.py?story=Real_Artists_Ship...</a>
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.
> In general, my priority since I started coding 10 years ago has been speed.<p>Which meaning of speed? You can write fast programs, and you can write programs fast, but you can't write fast programs fast.
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.
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 <i>seems</i> 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 :\
I agree with the author here.<p>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.<p>Either way, if the programmer is making the right decision most of the time they should feel good about the work they are doing.<p>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.
Thank you for this Dan. You are very right.<p>The subtitle for this should be:<p>"An ode to everyone that has gotten flamed on Stack Overflow or IRC for 'bad code'".