9 ms·

This is straight from the cowboy coder's mouth. This is Philistinism, plain and simple. > "...deliver something, anything...", no need to make it good, "teams

This is straight from the cowboy coder's mouth. This is Philistinism, plain and simple. > "...deliver something, anything...", no need to make it good, "teams make things better," anyway. No, no, and no. If you want to scale a team you have to deliver quality code. The cowboy coder spews out code, screams "see it works!", and then moves on to produce more diarrhea for "the team" behind him to clean up, "make better"... When one realizes they do not yet have a skill (such as producing quality code), it is tempting to scream "quality/perfection is a heresy" because this is much, much easier to say than the labor it takes to develop the skill. > It’s hard to see more than a week out because anything that takes more than a week to build involves R&D. Wrong, wrong, and wrong. MOST of what we do as practitioners (for those that have been doing it for at least some time) is NOT novel. Estimation is a skill. Estimates can be extremely accurate for those of us that have developed that skill. It is much easier to say "estimation is worthless" when it is a skill that you have not yet developed. Because it is only developed through (often frustrating) practice. Record the time it takes to do your work. Notice the patterns of problems that you face and how often they repeat themselves. --- Perfection per se has its hazards but in no way should that truth get us off the hook from developing ourselves and doing our work well. This post is nothing but dangerous to the nascent programmer-practitioner as it attempts to lull them away from what is possible and the work it takes to get there. Perfection is not attainable, but if we chase perfection we can catch excellence. -- Vince Lombardi

mjw1007 9y ago
Some new programmers need the advice to spend longer improving their code before sharing it; some need the opposite advice. Unfortunately, some people who dispense advice pick one of those "directions" and argue strongly for it, rather than trying to describe how to recognise when you've got the balance right.
- hashmal 9y ago
  Sadly a lot of people have a hard time understanding nuance and middle-grounds. In programming or in anything else. If your code is to be thrown away in one week, why make it perfect? If you have to maintain it for years, why make it a pile of shit? Funnily enough you can't often predict the lifetime of code.
- jrochkind1 9y ago
  This applies to _so much_ programming/architecture advice. Well said.
- Symmetry 9y ago
  An excellent essay exploring the implications of the point you made: http://slatestarcodex.com/2013/06/09/all-debates-are-bravery-debates/ http://slatestarcodex.com/2013/06/09/all-debates-are-bravery...
  - mmirate 9y ago
    > way more libertarian than can possibly be healthy How is such a condition even possible? This seems to be equivalent to describing, say, a libc, as "way more bug-free than can possibly be healthy". EDIT: there is no way that someone could be combing through days-old posts just to downvote something within an hour of being posted. >:|
jogjayr 9y ago
Trying to attain perfection is good advice in a professional environment. OTOH for side-projects, especially for people who have trouble finishing things without external motivation, it can be more useful to just get something done. Without the get-it-done mentality it's possible to obsess over the architecture, libraries, tech stack, deployment, test automation ad infinitum until you've lost enthusiasm for the project. It's great that you learned a lot of new tech but also slightly sad that the world will never see the idea you were so excited about 3 weeks ago.
- madiathomas 9y ago
  > Just get something done This is the strategy that I prefer. I aim to deliver version 1 of my side projects within 3-4 weeks. After working on it for too long without delivering, I lose interest. I fix the time and budget of the version, not the scope. Unfinished features are cut out of the version 1. I focus on the core features. There will always be time to add extra features in the future. Most people are afraid of launching because they don't want to be judged. That's why they delay the launch. I prefer giving my software to a handful of real users as soon as possible. So that they can test and give me feedback. There will always be bugs in software. Show me a popular software product and I will give you a list of over 10,000 bugs which were reported in its lifetime. What matters is the speed in which you fix them. If you created version 1 of the product, you wouldn't waste more than a day fixing all bugs reported on first day. 'Great artists ship' - Steve Jobs.
tetha 9y ago
> The cowboy coder spews out code, screams "see it works!", and then moves on to produce more diarrhea for "the team" behind him to clean up, "make better"... This resonates with me, and I hope I'm better than that. I don't know if I am. Some metrics might suggest so, but who knows. Over the last couple of years, I've been working with a repeating pattern. Teammates have a problem, but the problem can be split into 20% - 40% hard / algorithmic / architectural issues, and something between 60% and 120% other detail-work once the hard parts and a couple of easy parts as examples are done. So, I've grown to tackle and solve the hard parts, and give people a small chunk of software so they can solve their problem on their own, as long as I help them a little along the way. This is powerful if you have a strong understanding of the problem to solve, and a couple of open-minded team-mates. And it helps everyone to grow on a technical level, making further problems easy. However, this requires care, communication, a strong understanding of the issue, support for the solution... By now, people ask me for to handle the hard parts, and I can just dump them a repository with a README and a rough solution. But that was a long way, and giving less support, less care to do the right thing, and doing less to build trust with the team will lead to a catastrophe. And interestingly enough - oversupporting would also lead to problems.
- ludston 9y ago
  This sounds like the inverse of cowboy coding. The classic cowboy move is to tackle all of the easy parts incohesively, so the end program does may three quarters of what it is supposed to. Unfortunately implementing the last quarter will usually require re-writing large parts of the original code over years. Sometimes the cowboy will linger around to try keep the unshippable code as-is. :( I do not understand why.
- dsfyu404ed 9y ago
  If $( cat $your_code | grep '//' ) results in something that does a good job describing the code then you're doing a good job. If you think you're documenting way too much then it's about right. The people picking up your source years after you've left the company will need that much documentation. Documentation also breeds more documentation. When someone goes in and changes something they're far more likely to document it if their change makes existing documentation/comments incorrect.
hashkb 9y ago
I think this post is aimed more generally than just at programmers. In my experience, I've found more perfectionism everywhere else in the business. Bias: I'm a programmer and I believe I take the time to do the job the best I can; most of my time is spent re-doing features that users have never used.
0xFACEFEED 9y ago
This is a difficult topic to discuss because the "right" answer is very dependent on context. Sometimes it makes sense to rapidly spew out brittle code. Other times it makes sense to delay until you get it right. What's important is being in control of the situation. Know what you're doing and why. Know the tradeoffs and commit to them.

mjw1007 9y ago

Some new programmers need the advice to spend longer improving their code before sharing it; some need the opposite advice. Unfortunately, some people who dispense advice pick one of those "directions" and argue strongly for it, rather than trying to describe how to recognise when you've got the balance right.

hashmal 9y ago
Sadly a lot of people have a hard time understanding nuance and middle-grounds. In programming or in anything else. If your code is to be thrown away in one week, why make it perfect? If you have to maintain it for years, why make it a pile of shit? Funnily enough you can't often predict the lifetime of code.
jrochkind1 9y ago
This applies to _so much_ programming/architecture advice. Well said.
Symmetry 9y ago
An excellent essay exploring the implications of the point you made: http://slatestarcodex.com/2013/06/09/all-debates-are-bravery-debates/ http://slatestarcodex.com/2013/06/09/all-debates-are-bravery...
- mmirate 9y ago
  > way more libertarian than can possibly be healthy How is such a condition even possible? This seems to be equivalent to describing, say, a libc, as "way more bug-free than can possibly be healthy". EDIT: there is no way that someone could be combing through days-old posts just to downvote something within an hour of being posted. >:|

jogjayr 9y ago

Trying to attain perfection is good advice in a professional environment. OTOH for side-projects, especially for people who have trouble finishing things without external motivation, it can be more useful to just get something done. Without the get-it-done mentality it's possible to obsess over the architecture, libraries, tech stack, deployment, test automation ad infinitum until you've lost enthusiasm for the project. It's great that you learned a lot of new tech but also slightly sad that the world will never see the idea you were so excited about 3 weeks ago.

madiathomas 9y ago
> Just get something done This is the strategy that I prefer. I aim to deliver version 1 of my side projects within 3-4 weeks. After working on it for too long without delivering, I lose interest. I fix the time and budget of the version, not the scope. Unfinished features are cut out of the version 1. I focus on the core features. There will always be time to add extra features in the future. Most people are afraid of launching because they don't want to be judged. That's why they delay the launch. I prefer giving my software to a handful of real users as soon as possible. So that they can test and give me feedback. There will always be bugs in software. Show me a popular software product and I will give you a list of over 10,000 bugs which were reported in its lifetime. What matters is the speed in which you fix them. If you created version 1 of the product, you wouldn't waste more than a day fixing all bugs reported on first day. 'Great artists ship' - Steve Jobs.

tetha 9y ago

> The cowboy coder spews out code, screams "see it works!", and then moves on to produce more diarrhea for "the team" behind him to clean up, "make better"... This resonates with me, and I hope I'm better than that. I don't know if I am. Some metrics might suggest so, but who knows. Over the last couple of years, I've been working with a repeating pattern. Teammates have a problem, but the problem can be split into 20% - 40% hard / algorithmic / architectural issues, and something between 60% and 120% other detail-work once the hard parts and a couple of easy parts as examples are done. So, I've grown to tackle and solve the hard parts, and give people a small chunk of software so they can solve their problem on their own, as long as I help them a little along the way. This is powerful if you have a strong understanding of the problem to solve, and a couple of open-minded team-mates. And it helps everyone to grow on a technical level, making further problems easy. However, this requires care, communication, a strong understanding of the issue, support for the solution... By now, people ask me for to handle the hard parts, and I can just dump them a repository with a README and a rough solution. But that was a long way, and giving less support, less care to do the right thing, and doing less to build trust with the team will lead to a catastrophe. And interestingly enough - oversupporting would also lead to problems.

ludston 9y ago
This sounds like the inverse of cowboy coding. The classic cowboy move is to tackle all of the easy parts incohesively, so the end program does may three quarters of what it is supposed to. Unfortunately implementing the last quarter will usually require re-writing large parts of the original code over years. Sometimes the cowboy will linger around to try keep the unshippable code as-is. :( I do not understand why.
dsfyu404ed 9y ago
If $( cat $your_code | grep '//' ) results in something that does a good job describing the code then you're doing a good job. If you think you're documenting way too much then it's about right. The people picking up your source years after you've left the company will need that much documentation. Documentation also breeds more documentation. When someone goes in and changes something they're far more likely to document it if their change makes existing documentation/comments incorrect.

hashkb 9y ago

I think this post is aimed more generally than just at programmers. In my experience, I've found more perfectionism everywhere else in the business. Bias: I'm a programmer and I believe I take the time to do the job the best I can; most of my time is spent re-doing features that users have never used.

0xFACEFEED 9y ago

This is a difficult topic to discuss because the "right" answer is very dependent on context. Sometimes it makes sense to rapidly spew out brittle code. Other times it makes sense to delay until you get it right. What's important is being in control of the situation. Know what you're doing and why. Know the tradeoffs and commit to them.