Often, cowboy coding is looked down upon as a form of egotistical manic programmer that doesn't work well in the team environment. This can be very true, but it is an over simplistic view that is depressing for smart people who tend to cowboy up more often than not.
For a cowboy coder, the right thing to do is to do a start-up and then cowboy up so hard core that the product is awesome. Get the product into the market. Get it sellable. If it sells (which is way harder than making the product), then jobs have been created to support the product since the cowboy coder probably made a lot of mistakes that need human intervention.
I have a theory that this is one reason that most commercial software kinda sucks, but it is also why the job market for coders will always be strong.
I have to agree with this, although you did not identify your understanding of what a "cowboy coder" is in this post. Many people identify a "cowboy coder" as someone who just jumps in and does the job while ignoring procedures. In a team where procedures exist in order to reconcile issues with actions, this can cause quite a stir. However, as one who is unrepentantly naturally cowboyish, I strongly believe that the more competent you are at your job, the better it is to be a cowboy coder. Jumping in and fixing a problem without seeking permission first is the best way to stablize it; on the other hand, jumping in and *trying* to fix a problem but then just making it worse is everyone else's fear.
ReplyDeleteSo personally I feel that the role of a cowboy coder is one that must be earned. You become more like an "elite coder" (a l33t coder? lol), who can break the rules to get stuff done but is almost always successful in doing so.