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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] edw519|13 years ago|reply
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.
[+] [-] anthonyb|13 years ago|reply
> 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.
[+] [-] batgaijin|13 years ago|reply
[+] [-] why-el|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] Ubiquite|13 years ago|reply
[+] [-] gadders|13 years ago|reply
Obviously not true, unless your project manager is a complete idiot.
[+] [-] crncosta|13 years ago|reply
[+] [-] hnriot|13 years ago|reply
[+] [-] jbail|13 years ago|reply
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|13 years ago|reply
[+] [-] huhtenberg|13 years ago|reply
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".
[+] [-] pnathan|13 years ago|reply
[+] [-] akurilin|13 years ago|reply
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.
[+] [-] benihana|13 years ago|reply
>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.
[+] [-] calinet6|13 years ago|reply
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.
[+] [-] john_flintstone|13 years ago|reply
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.
[+] [-] xauronx|13 years ago|reply
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.
[+] [-] ry0ohki|13 years ago|reply
[+] [-] crntaylor|13 years ago|reply
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".
[+] [-] grandalf|13 years ago|reply
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.
[+] [-] jetti|13 years ago|reply
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.
[+] [-] ScotterC|13 years ago|reply
[+] [-] stephengillie|13 years ago|reply
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.
[+] [-] PommeDeTerre|13 years ago|reply
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.
[+] [-] kamjam|13 years ago|reply
Surely that's what YouTube is for, people with no talent to post some random rubbish about something that nobody actually cares about?
[+] [-] xutopia|13 years ago|reply
[+] [-] charlesju|13 years ago|reply
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.
[+] [-] mgkimsal|13 years ago|reply
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.
[+] [-] greenyoda|13 years ago|reply
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.
[+] [-] tluyben2|13 years ago|reply
[+] [-] debacle|13 years ago|reply
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).
[+] [-] gutnor|13 years ago|reply
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.
[+] [-] pyrotechnick|13 years ago|reply
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.
[+] [-] ScotterC|13 years ago|reply
[+] [-] ssebro|13 years ago|reply
[+] [-] jbattle|13 years ago|reply
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.
[+] [-] greenyoda|13 years ago|reply
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.
[+] [-] tluyben2|13 years ago|reply
[+] [-] S4M|13 years ago|reply
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.
[+] [-] pharrington|13 years ago|reply
[+] [-] Evbn|13 years ago|reply
[+] [-] heelhook|13 years ago|reply
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.
[+] [-] dpiers|13 years ago|reply
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.
[+] [-] albumedia|13 years ago|reply
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|13 years ago|reply
[+] [-] paupino_masano|13 years ago|reply
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...
[+] [-] dkoehler|13 years ago|reply
-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.
[+] [-] JonnieCache|13 years ago|reply
[+] [-] matwood|13 years ago|reply
[1] http://www.folklore.org/StoryView.py?story=Real_Artists_Ship...