Hacker News new | comments | show | ask | jobs | submit login
I am a terrible programmer (danshipper.com)
245 points by ScotterC on Nov 8, 2012 | hide | past | web | favorite | 140 comments



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.


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

Up until the codebase is such unbelievably appalling shit that you can no longer add new features, solve problems or reliably hit deadlines. I have worked on too many of these projects to be able to easily count them.

Typically, I'll be the one fixing up something after the previous developer has run away or has been sacked. There's often a culture shock when the manager/customer/project manager who is used to calling the shots suddenly finds that their latest idea needs to take a back seat while deeper (often 'invisible') problems get fixed.

Perhaps another take is that a "good programmer" is one who is still around and still adding features after a couple of years.


In the real world (or at least the world of garage sales and Antiques Roadshow), one man's junk is another man's treasure.

In the programming world, one man's treasure is inevitably another man's unreadable spaghetti dependency-ridden junk.


Yeah, the code you're working on is really treasure in disguise. Whatever gets you through the day...


If you are doing it for an employer it is at least worth what they are paying you for it. I would argue that qualifies as treasure.


No, in the programming world there are projects that met the revolving door of mediocre programmers that no one is proud of, no one understands how it works or wants to, everyone just finds a place they think will have the effect their being driven to make and takes a shot.


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.


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


So, he gets to comment on other people who publish their work, but he is forever safe from the same sort of feedback? That sounds more like fear than pragmatism.


http://edweissman.com/53640595 -- or check his profile.


sorry, you asked for code and i sent you to the ebook. :P


Do you want to see Scott Adams's project status reports too? Just enjoy the stories.


I agree with you here. That project manager you mentioned is a lot of things to a lot of people. But I think as programmers we might want to agree on a set of standards that identify the good and the bad. I am one year or so older than Dan, and it would help my career to know that more experienced programs could identify who is the best among them.


This again depends on the domain and programming language you will be working on. But almost always the following line holds good.

Make your code readable.


I've had the fortune / misfortune of working with some very smart programmers, who could quickly come up with amazing and correct algorithms to solve difficult problems... but I found much of their code very hard to read; it wasn't "horror code" by any means, but it was often terse and tricky, and pretty comment-light.

My theory was that because these guys were so smart, in many cases they overestimated the ability of others to comprehend what was clear to them, and as a result simply made their code too clever and omitted comments that might help clarify it.

It was a definitely a valuable experience, though; besides the natural pleasure of working with very smart people, it really drove home the importance of actively pursuing clear and well-commented code! :]


Those algorithms should be left as is. They are good.

However, they should be encapsulated in an easy to understand API.

That way, you (the usual programmers) can call the code, and they (the very smart programmers) can write smart and efficient code. You are not supposed to tweak that smart code, just call it.

The solution is not to dumb down everything. That way leads to madness. Or Java.


Fast forward a few years...

None of the original developers are still at the company and one of your customers has discovered a bug in their implementation because of some obscure edge case and now you get to spend the next month understanding the complex code and writing a patch.

Writing maintainable code is not the same as dumbing everything down.


Just the same as if someone finds a bug in Boost.

It is hard to understand. It is efficient. It probably requires computer science knowledge to solve the issue. And yet it is as maintainable and well documented as they possibly can make it.

Not everything can be 'business logic' in the sense of 'something a manager can understand but not code'.

Some algorithms are just hard. And they are worth it.

What would be Google without PageRank? What would be Skype without their LAN piercing modules? What would be iD without their game engines? What would be CryTek without their game engines?

Worthless, that's the answer.


Make no mistake. Clever code is not necessarily good code.

I'm not in favour of littering the code with a pile of comments which will most likely become obsolete in three months, but it's very important to do whenever you are: - implementing a non-trivial algorithm - doing something surprising (maybe to fix something on a specific architecture or whatever) - implementing a complex business rule


But their code could also be hard to understand because you don't understand the problem good enough.


To a maintainer programmer, the programmer who makes the simplest code.


To an HR person, the programmer with the most number of years of experience.

Here's to the technical interviewers out there who know all too well that there is no correlation between number of years of employment as a "software engineer" and the quality of the engineer.


> To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer.

Obviously not true, unless your project manager is a complete idiot.


Not sure how you define idiot, but more often than not pm's have no formal programming experience which makes it difficult (though not impossible) to understand the value of well-engineered code. The only language they speak is dates, which unfortunately is usually accompanied by loads of unnecessary documentation.


Presumably, though, a competent programmer would include the effort required to produce well-engineered code within his original estimate.


Code that was well-engineered 3 months ago may suddenly become lacking in light of a client having a brilliant new idea/requirement.

And a programmer is not always in charge of his estimates. He may have to arrive at it together with his team lead who is under pressure from 2-3 project managers, thus only the minimal reasonable time will be allocated, without concern for architecture changes or refactoring.


Yeah, but in my experience, the PM's response to that will be "can we get it done sooner?"

If the estimated time aligns with what they want, then you're fine. But that's rarely the case and when things slip the code cleanup is pushed to the back burner.


The average manager is dumber than you think.


Thank you for so enlightening comment.


You're making the point that being competent at programming is in some way relative to the perspective of the asker, but that's just not the case. Competence is absolute. There are traits of a good programmer that are immediately evident to any experienced programmer.


Replace the word programmer with writer.

What is absolute competence in writing novels? Writing magazine articles. Publishers want good writers that sell lots of books, young writers want good writers that critique their books.

There is a base level of competence, but even that is often local culture


Even tho IMHO coding is an art, like writing, you cannot compare those two in this case.

You write code that will almost for sure, live on for 10+ years and will be changed by a lot of people.

Good code will be maintainable and easy to extend/change. Bad code is just... every programmer's nightmare.

Bad code will still be bad even if it made the product go live, and good code will still be good even if it took a few more days/weeks to produce it. The balance between quality and speed is completely product dependent. But sooner or later bad/fast code will claim it's price.


I agree with your parent, and think you're trying to read it in an over-specific way, it's like saying "You can't compare writing and programming, because writing doesn't have comments."

The parent was making the point that, like writing, good and bad coding style is entirely subjective - necessarily so because many parts of it are simply conventional.

There are some specific constructions in programming that can be shown to be better than others through complexity theory, but even the guidelines we have for these aren't global optimums.


This is spot on.

And to go further, where the OP argued that product quality and development time are mutually exclusive; I submit that they are not.

In the right hands, good code can be written quickly and efficiently, just as good novels can be written as quickly as bad ones are, or good music can be written as quickly as bad music is.


But most companies aren't going to have "the right hands". Many wouldn't want them even if they could get them because they want programmers they can replace easily.


That's just like, your opinion, man.


Competence is in the eyes of the beholder.

If I need someone to crank out a report by afternoon which will never be used again and he was able to do it, he's very competent. If I need someone to crank out a car control system and he took one year to do it but has very low defects afterward, he's very competent.


Then why is there such variety of style, brevity, documentation, and technique among good, experienced programmers?


Even tho it's not a tangible thing, it still exists.

You can't measure it with a ruler or some lines of code formulae, but good programmers are easily recognizable by other good/experienced programmers.


>There are traits of a good programmer that are immediately evident to any experienced programmer.

Replace the word 'programmer' with 'coder' and you might have a point. Whenever I hear the word 'coder', all I can think of is shelf-stacker. A coder writes lines of code, a programmer builds products or 'things'. All the rules and standards regarding code belong to coders - they have nothing to do with finished, shipped, or successful products.

But what do I know? I've only been building products for 13 years. And I'm drunk.


If competence is absolute, then there should be some way that you can objectively measure it (otherwise how do you know its absolute?).

What are the ways to objectively measure the competence of a programmer?

If that was the case, then it would be much, much easier to hire and fairly compensate programmers than it is in reality.


In my opinion programmer competence is not absolute, but a little bit more absolute than what ed's post suggest. :)

A very rough measurement of programmer competence:

The programmer is given a product specification. He creates the program in T time using S size of code.

1/(T * S * S)

is a very good approximation of how good the developer is. (small size is more important than the taken time, that's why I've taken S square. We can tweak the formula of course. Maybe 1/(T * S * S * S) is even better in some cases.)

TL;DR: the most common thing amongst good programmers in my opinion is that they are masters of the DRY principle, but they do not overabstract; in essence they write smaller code to problems (usually even faster) than not so good programmers. The bigger the system is, the more and more architectural/design skill is needed to keep the code base small.


I have to disagree sorry.

If a piece of software is needed by the date of a major launch, and a programmer doesn't ship, all because he wants to reduce the amount of code involved, then he's an awful programmer as far as the business is concerned.

Running over time can cost millions of $ of investment in other areas of the business:

- Press organised

- Advertising purchased

- 1000s of hours of staff training underway

- Suppliers informed of increased demand / new supplies purchased

- Customers told to expect delivery by date

Any one of these areas can cost 10x or more of the cost of developing the code.

If you're not writing code which would be affected by that kind of criteria then cool, go for whatever metric you want to define.

Time taken is almost always the number one criteria of any business requirement, or to put it another way, small size of code means almost nothing to anyone except the original developers.


I said that it is a rough estimate, and we can tweak the formula. My opinion is that programmer competence is not absolute, but also not terribly relative. I mean John Carmack is kind of absolutely a better developer than let's say junior average Joe.

>small size of code means almost nothing to anyone except the original developers.

No. Small size reflects the quality of the code: It reduces the time of future developments (non DRY code keeps growing agreessively and becomes even more non DRY and very time consuming to develop new features into). It is an investment in the future. Now you are right: sometimes it is not worth it to invest into the future, because maybe the code will be thrown away because it will turn out that the startup/product is not viable. Somtimes you know that product has a stable growing market and you will have to develop tons of features into it in the future. Then investing in the future is very important.


> Small size reflects the quality of the code.

Not always. Case in point: a week or two ago, I refactored some C# code. It was an installer generator, which was coded entirely in the controller. Yeh who want to add unit tests, abandon all hopes.

So the code is now split into different pieces, according to responsibilities, with dependency injection, and I/O in its own layer. The result, in terms of lines of code, is a net increase. But according to your metric, I have decreased the quality of the code.

I agree that generally speaking, less code is better than more code, but more code can mean reusable, more readable code.


Ok, I accept this. I have experience in refactoring really bad code. Refactoring these always led to smaller code: yes sometimes some of the refactorings increased the code size, but there was enough redundancy because of the bad (or no) abstractions and design mistakes in the original code which compenstated for it.

The bigger the system is, the more probable it is that you can make it better while decreasing the code size. Above 10.000 lines a bad code usually is not DRY enough so much, that it is very easy to decrease its size while increasing its modularity.

Yes, code size is not a perfect indicator of quality. But reducing code size is a very central part of my design philosophy. When you very conciously refactor to smaller code size (using good design patterns) the code and the abstractions in your head can become incredibily clear.

For example I write a software which deals a lot with rectangles. In the beginning my rectangles had four properties: left, right, top, bottom. After a while I've found out that my code gets more and more redundant; I have to find an abstraction which relies on the symmetries in the problems. So now my rectangle has this interface to get and set the 4 sides:

void setSide(bool vert, bool isEnd, int value)

int getSide(bool vert, bool isEnd)

Not only my code size reduced dramatically, but because of this new abstraction I've understood the problem much better!


I think I understand where you are coming from, but DRY tends to, at least initially, increase the size of codebases and development time. The programmer who hacks something together that works now, but is a nightmare to maintain later will score better in your formula. As you say, it is an investment in the future, which implies that you are giving something up now for something more later.


I don't see why an objective ordering of programmers by competence would have to be a total ordering.


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.


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.


This is why peer reviews are so important. Simply running code through JSLint and then making sure its formatted correctly is only step one.


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


Any tool can crap out code that serves a business need. That's a "product", fine. But it takes someone with a bit finer sense of competence to produce code that can work over a longer term and doesn't drag down the business in years to come.


Yes. The term "quick and dirty" and "bang something out real quick" make me want to throw up in my hat. It's not like it's not necessary to lower standards a bit sometimes, but because people who use that phrase a lot tend to, in my experience, use it as an excuse for churning out a lot of garbage.


I generally agree with you, but it really depends on the context. You can never abstract the development side from the business needs, and those trump everything.

In a fast business with a very small team and a very short runway you often have to sacrifice quality in exchange for putting something out there. If something doesn't come out of the oven, there's no "long term". At that point, the choice makes itself. That's probably why a lot of people will, likely rightfully, claim that startups don't need to be highly technical unless it's where their competitive advantage will come from (and in the words of Mark Suster, 90% of startups do NOT fail because their tech wasn't good enough).

On the other hand, in long-term projects that have enough budget to survive for a while, you can shift priorities and focus on quality as appropriate.

The release process is also really important here. In web/saas you can fix things very fast behind the scenes without the customer being aware of it (Etsy claim to make what.. somewher around 100 checkins into production a day?). In mobile / boxed you have to be a lot more careful. Nobody wants to wait 2 weeks for Apple to approve your patch when a major scenario is broken in your app.

Of course, if you can have both wonderfully clean and extensible code and get that done exactly as fast as poorly written code, that's the preference.


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.


I am young in the Industry and I already see examples of such people. They go through a recursive cycle of "visible productivity" in terms of fancy features which break three months later. Then, they are on a "fire fight" trying to fix this "broken feature". The worst thing you could do is try to look at their code and attempt to reuse components for anything you want. I however don't completely blame such people, I think it is the nature of the startup world we are living in where the idea is to ship as fast as possible and technical debt be damned.


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.


>You can ship all the code you want, but even if it's lots of mediocre code, it's still mediocre.

The code might be mediocre, but that doesn't mean that the product is mediocre. Pristine, beautiful code, that forms part of a bad product, is like a soprano singing the most god-awful piece of bilge anyone has ever heard. Doesn't matter how good her voice is if the song is rubbish and makes everyone cringe.


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


My point is that quality is an objective measure which does not depend on situation, or reality, or getting things done, or time constraints, or personal issues, or whether you do it in a weekend. Better code is still better regardless of all that.

You have to have an objective notion of quality before you go trying to apply it to reality. And if you do, you might have a chance at improving it.


Well, you're simply incorrect. I mean, we can agree what a perfect programmer is. But comparing the qualities of two imperfect programmers is absolutely situational, just like any skill. Who's the better athlete, Michael Jordan or Michael Phelps * ? They're both great athletes, but who's better? I guess you could have them perform in every olympic event, but that wouldn't really tell you much.

Ah, but I just noticed a small syntax difference in your argument. You're arguing about better CODE not better CODERS. Still arguable, but more objective. You can easily gather a lot of metrics about code. Still, if I'm programming something for my graphic designer sister to work on later, I'm going to program differently than if I was writing a compact and efficient internal piece of code.

*Using two of the only athletes I really know.


You're absolutely right, there are differences between situations. I absolutely, positively know that.

But I'm saying, when you're measuring quality objectively, it just doesn't matter. What matters is the thing itself. The created object. The outcome.

I'm not simply incorrect—I'm simply correct. My argument has the constraint of simplicity. It is defining the basic existence of a thing which we know exists, namely Quality. When you add complexity, yes, the definition is no longer sufficient to describe the entire process; but I'm not claiming that perfect code and perfect coders are possible in reality. I'm saying: start with simple and true definitions so you understand what quality is by itself, so that once you add situations and reality to it you can still try to achieve something close to "good." It is a matter of scope.

This isn't an argument. Quality exists. Defining it is hard, yes, but it's not impossible to understand that one thing can be better than another by many measures, and we say that thing has higher Quality.

Read "Zen and the art of Motorcycle Maintenance," it'll twist your brain up some more.

What you're going to say next is of course that you're right and that devolving into silly philosophical arguments doesn't mean anything to real-world work, so yes, I guess I'll agree with that.


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


And then as soon as they are done fixing it the requirements change and the fancy decoupled codebase (while very flexible in serving the needs of the old requirements) is basically non-workable for the new requirements.



But registering a domain and setting up LAMP servers are not programming tasks. I think there can be a name for that (maybe "product builder"?), but it doesn't make sense to co-opt "programmer" for it.


I think quality to some degree is subjective in programming though. A lot of coders these days focus on beauty or fancy data structures instead of writing clear, straight forward, efficient code.


Most of the discussions of beautiful code that I've read are about how clear and straight forward are perquisites to beauty. Code that's difficult to understand or reason through is almost always described as ugly. Efficiency is normally impossible without using the right data structures.

I'm not clear who you're complaining about here. It's possible you're complaining about yourself.


I was 100% with you until the needless personal attack in your last sentence.


I certainly didn't mean it as a personal attack, and am sorry it came off that way.

I was trying to say that it if the parent writes clean, clear, and efficient code, it might qualify as the sort of beautiful code that people are striving for.


A good programmer who consistently ships great, high quality code regardless of the situation is still a better programmer.

I think you just shifted the problem of defining a "good" programmer to defining "high quality" code. Some people might argue that the code that gets the job done most efficiently has the highest "quality".


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.


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.


I do the same. All my personal gh repos are public. And I push as I work, I don't wipe commit history.

I'm no one special, and I seriously doubt anyone looks at my code, but, if someone ever did, they'd see work in progress.

Just like the code base at work. Nothing's brilliant the first time out.


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.


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.


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.


I'm still trying to figure out why so many Dan Shipper articles get submitted here, and why they always end up near the top.

They always come across as nothing but self-promotion thinly veiled under buzzwords related to software development, rarely with any real substance.

From what I can tell, he hasn't really done anything notable. He's a college student who has apparently been involved with some relatively unknown startups, and otherwise does some pretty typical and unremarkable software development.

It just seems like he's usually trying to make a big deal out of stuff that's pretty inconsequential, while continually dropping his name or that of some startup he's involved with.


Hey PommeDeTerre, I think it's because of two things primarily:

1) Dan is beyond his years in terms of articulating his thoughts on startups and software development, and reminds some people of a young Jason Fried (co-founder of 37Signals, author of "Rework", etc.)

2) Dan is (much like Jason Fried) a bit of a contrarian. He has shipped almost two dozen apps/sites in the past couple years and is working night and day on growing his current startup, but he isn't dropping out of university. He also isn't out raising venture capital and trying to scale scale scale -- instead focusing on building a business that makes revenue and is profitable from (almost) day one. And lastly, because he is not chasing the "sexy", popular consumer app space -- instead focusing his efforts on the 'less glamorous' SaaS and B2B space.

*

The combination of these factors make a lot of us in HN interested in where Dan's career is headed, and thus interested in reading his posts and watching him progress as a founder while still in school.

That's why so many Dan Shipper articles get submitted here, and why they always end up near the top. He is the real deal.


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?


If he's a good enough programmer to do so full time, then he's wasting his time worrying about such broad, imprecise labels as "good" and "bad". I'm saying he should blog about something else.


Fair enough, but maybe he is not blogging it for himself. Sometimes this kind of thing is good to hear and motivating for those making their way up the ranks (so to speak).

We can't all be brilliant programmers. Heck I'm not, but I've been in the industry a long time, and know the difference between when to write good code at the expense of time and when something is unlikely to see the light of day/prototype/one-off.


Get off your high horse! Lots of successful people have inner debates about how they deserve such success. It's called the imposter syndrome.


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.


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.


Oh, hush now.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


But if a startup wants to become a successful larger business (rather than just get acqui-hired by Google), then the code quality does matter. Once they've gotten paying customers, they can't afford to drop everything and build a reliable and scalable system from scratch - it would be cheaper and less risky to build on top of their original code.

Also, depending on the business, the MVP may end up being a large and complex code base that can't just be hacked together haphazardly. Not all startups build iPhone apps; some build on-line retail businesses or investment banks.


Your theory directly contradicts the actual history of Google, Amazon, Facebook, etc.

Larry and Sergey's first hires were for people to replace the crumbling hacks they wrote to launch Google.


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.


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.


So very damn true. I'm trying to unclusterf*ck this in our codebase.


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


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.


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?


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


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.


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.


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.


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.


Ah yes, the second system. To great effect. See the Netscape 5 rewrite, a great example.


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


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.


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.


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


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


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.


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.


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


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.


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.


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.


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.


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 :\


There's the field of empirical computer science (for example 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...


Thanks, it's a start.


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


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.


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


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'".


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


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


As the saying goes, bad code falls apart in 3 months. Google code falls apart in 6 months.


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


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


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.


Not just writing bad code, but learning from the bad code so you can solve a similar problem in the future with better code.


You and me together.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: