After watching the documentary I decided I wanted to do the same thing. How cool would it be to drive a vehicle that painted with its tires? What kind of artwork could I come up with?

Not wanting to take forever on the project, I moved quickly to create a gameplay prototype. The first problem I ran into, though, was that to reuse my existing 3D codebase would require more work than I wanted to spend on a prototype, particularly since I needed to integrate a physics engine to get the effect I wanted for the vehicle dynamics.

So, I took a look at Flash, noticed that there were a few 3D render engines and a few physics engines, and figured "why not?" Granted, I've never used Flash before, but I went to Adobe's site, downloaded the Flash 30-day trial, and went to town.

A few days later, and I have a prototype of CarPaint: http://www.gamesunplugged.net/CarPaint3D.html. If you check it out, be sure to click the Help button to see the controls and instructions.

It turns out that BMW also created an iPhone App off this idea – something I just found that out as I searched for the name of that documentary for this post. I'm going to download it and check it out. In the meantime, I'm going to let the Flash version cook for a little bit as I look at porting it over to a Windows-based application using my engine – and of course consider I'll consider the iPhone App route.

Everyone wants to be successful. Entrepreneurs want successful businesses. Athletes want to win. Engineers want to build perfect solutions.

The problem is that most of us try to be successful through grand strategies and big plays. Entrepreneurs hold off on starting a business until they have that "killer app" idea. Baseball players try to hit the home run. Engineers try to design a solution that will address any possible situation. Meanwhile, another company comes out with a better "killer app", the baseball player strikes out trying to "swing for the fence", and the engineer ends up with an over-complicated solution that has to be scrapped because it doesn't work.

As JD Meier reminds us, the key to winning isn't the big play. The key to winning is to build momentum off a series of small wins. By focusing on small goals, small tasks, and small features, we allow ourselves to adapt to change, to measure tangible progress, and to celebrate successes early and often.

Avoiding the reinvention of the proverbial wheel is a standard bit of received wisdom in software development circles. There's certainly truth there, but I think it's a bit dangerous if taken too literally — if you categorically deny all attempts to solve a problem with code once any existing library is in place.

I don't think anyone is saying that you should avoid reinventing the wheel at all costs. The reality is that there are times when rolling your own is desirable. As Joel Spolsky said:

And that's where I learned a key lesson in software architecture: for your most important, mission critical stuff, you have to use a tool that is one level lower in abstraction than ideal. For example, if you're writing a cool 3D shoot-em-up game (like Quake, around the same time period) and your key number 1 differentiator is to have the coolest 3D graphics, you do not use whatever 3D library you can find. You write your own, because it's fundamental to what you do. The people who use 3D libraries like DirectX are using them because they are trying to differentiate their games on something other than 3D performance. (Maybe the story line.)

Bottom line: the issue of reuse is not nearly as black and white polarizing as the Coding Horror blog wants to make it.

There are times to reuse and times to reinvent the wheel – knowing the difference is one of the keys to being a good software developer. Even beyond that, it really goes back to basic engineering tradeoffs.

In most cases, however, the software developer who embraces reuse as much as possible will be in a better position and have better opportunity than the software developer who likes to reinvent wheels. It's often a missed fact that invention and innovation occurs only through an iterative process of work built on top of prior work, which quite frankly is pretty much the definition of reuse.

Besides, as Jesse, a commenter in the Coding Horror blog post said, "Doing something that you know can be done is not invention."

Granted, reusing software is not always the best solution, but more often than not it is a very strong candidate. I believe that if an engineer or organization is not going to reuse software then the onus is on them to provide a strong enough rationale why not. And if the engineer or organization can't defend their rationale with good reasoning? Then the argument against reuse is not strong enough.

Unfortunately, not everyone thinks this way. That's not surprising. Engineers like to do fun stuff and reusing software or technology takes away some of that fun stuff. I get it. I like to do fun stuff too. I used to write my own rendering engines and XML parsers and Winsock code, but then one day I woke up from this comatose state.

My world changed when I stopped looking at software development at the technology level and started looking at the product end state where adding value to the product became my number one priority. The how and technology used were still important, but they were driven by adding value.

Now, there are times when reuse shouldn't be used: new technology research, education opportunities, and so on. But most of us live in a world run by businesses that build products for customers and minimizing cost and schedule are important to the business, and reuse is a way to ensure cost and schedule are minimized.

So, when in this world of business I hear something against reuse I just shake my head. Some developers just need to go away. Really. They make the world a less productive place.

To cap this off, here are some actual excuses I have heard against reuse – along with my own thoughts on the excuses.

Mr. No Reuse: Software ABC doesn't provide every feature we need and won't be just a drop-in for us, so we can't use it.
Me: I hope you're joking. Not every piece of software can be written to your liking.

Mr. No Reuse: Our product has special needs.
Me: Special needs? Such as, minimizing cost and schedule so we can make money? No problem or product is so special that we should limit our reuse. We should maximize it.

Mr. No Reuse: I want to learn about XYZ technology and this is the best opportunity for me to do that.
Me: Good for you. I support continuing education. Now go start your own business and you can do that all you want.

Mr. No Reuse: In Software ABC, I don't like the API or how they do things.
Me: I'm sorry they didn't ask for your opinion when they designed it; however, it does the job and thousands of other developers use it already without complaint.

Unfortunately, people like this really exist. Don't be one of them.

Software Development is one such topic, and I often deal with trying to communicate the challenges of software with those who have little or no experience in it, so finding good analogies is always helpful for me.

Bernie Thompson took one such shot at an analogy in a post entitled "Software Development is like golf…". His premise is that your chosen path to the pin is always the problem, and to succeed you have to weigh your capabilities (people), the course (technology), and the conditions (the market).

As a (very) amateur golfer, I can agree with this analogy and it's one I may even use myself. The only disagreement I have with it is that this analogy can be applied to most engineering disciplines. That is what engineering is about anyway: balancing factors and making tradeoffs.

Still, it's a good analogy. In engineering you can't always "go big, or go home" as I like to call it on the golf course, and to be successful you have to be willing to adapt to changing conditions in your design, market, and customers.

In fact, in most sports the most successful teams and individuals are the ones that can adapt to the evolving situation of the game, and the way to adapt to the situation is to constantly assess tradeoffs like the ones Thompson chose to address in the game of golf.

The last time I took a typing test like that was 15 years ago, and I was typing around 50 wpm. Back then, my keyboarding experience was only about 2 years. Before that, I only had keyboard access if I was lucky.

When I was 23 years old, I was drafted by the Cleveland Indians to play professional baseball. 19 years prior, I had my first at-bat in T-ball and was tagged out after reaching first because I didn't know the rules – you know, the one that says you have to stay on the base.

Besides bragging rights, I do have a point: persistence, practice, and repetition are a few of the key ingredients to successful skill improvement.

There are other ingredients of course, but I don't know anything that refines our skills as much as those three. Genetics and talent play a role, of course, but without repetition and practice we get what's called "rough around the edges". This means your talent is only good if you polish it.

Of course this applies to software skills as well. Coding, designing, managing – they all require repetition to get better. Or put another, probably more relative way, they all require iteration to get better.

  If we think back to when we first started programming,
perhaps in BASIC, most of us created some "Hello, world" variation as our first foray into the software development world. We had one line:

10 print "Hello, world"

And that was it. So when we ran our program, we saw "Hello, world" printed to the screen, and our program exited.

Of course, that wasn't enough. We wanted to make a game. (Isn't that how most of us start?) But we quickly
realized there wasn't a rungame command, which meant we had to learn more about the language and its programming constructs.

To do so we started adding loops to print more "Hello, world"'s to the screen. Then we added random number generation with if-then-else blocks to vary how many "Hello, world"'s were printed. After that we played with receiving input from the user by asking for a name, which would then turn into "Hello, John". And then, we became bold: we made a function called rungame that would do all of it for us.

At this point we felt ready. We went through iterations of our basic "Hello, world" program and through the process we had acquired enough skills that we were confident we could build our first game: "Heads or Tails?"

Of course, this took a few iterations, but eventually we had it: our first game. And we showed it to our family, and maybe friends, and nobody understood the big deal.

Through the process, through the iterations, we acquired a new skillset while also having that sense of accomplishment for completing our first game. Without even knowing it we had persistence, we practiced, and we had repetition.

We were now better at coding and design than when we typed that first "Hello, world" program. We understood the big deal because we knew that going through those iterations was not an easy thing to do.

Back to today, we can take this a step further. Ever see a system that was designed perfect the first time? Me neither, but that system that has been through several design iterations? Now that was a good system. How many times have you redesigned (or wanted to redesign) that application you're working on?

See -  repetition, persistence, practice – they all lead to improvement, whether it's our personal skill sets or that complex software system we're trying to design. We just have to be willing to be persistent, make time for practice, and go through the repetitions. It's not easy, but if it was, then everyone would understand the big deal.

The Snippet Designer was started as an intern project of mine during the Summer of 2006.  The idea was to make snippet files (which were introduced to Visual Studio in 2005) a first class entity.  Following this idea I created a Visual Studio plug-in which included an editor for snippet files and a search tool window to find snippets.  The plan then was to release it on Codeplex but when my internship ended the project was forgotten about.

Now after two year of sitting there I found the code, cleaned it up a bit and am releasing it on Codeplex as an open source project at http://www.codeplex.com/SnippetDesigner.  My goal in releasing it on Codeplex is two fold.  First I would like people to try it out, give me feedback and see if we can make it better (it still has plenty of rough edges).  Second I would love to turn this into a community developed project where we all can collaborate on it.

Bob C. Martin (Uncle Bob to you and me) suggested, in his “quintessence” keynote at the Agile2008 conference that he had the perfect metric for code quality. Cyclomatic complexity and others were interesting mostly to those who invented them, etc. His answer was brilliant, and was easily measured during code reviews:

WTFs per minute

It seems like a joke, but you know, it's too true. The worst, or perhaps best, code and design reviews I've participated in have involved a lot of "WTF?!?". You know you found a problem with quality when that happens.

Perhaps someone can start a WTF trend analysis to see if there's a direct correlation between quality and WTF count. I bet there is.

I go there to get away from the hectic for a few days, sometimes even unplugging from the world completely by disconnecting from Internet, TV, and phone. It gives me a chance to unwind, think, and ultimately reflect on where I am and where I want to go.

Anyway, at one point during the last few days I was thinking about the whole topic of "What makes a better software engineer?" and remembered an old article series by Chris Hargrove that we have on GameDev.net called Code on the Cob (CoTC).

CoTC was originally written by Hargrove for a site called loonygames, run by loonyboi, who has since moved on to bigger and better things. When loonygames shutdown, I contacted Chris to see if he would be willing to let us host the series, especially since he was pretty active in the GameDev.net community at the time.

CoTC is one of my favorite series of articles, not because there was any particular insight or because I necessarily learned a lot, but because Hargrove outlined best practices and principles for software development in an easy-to-understand way. Some of his ideas still resonate with me today.

In fact, there's one article in particular in CoTC that I've always remembered and it's the one that I thought of while away this past weekend: CoTC 11: The Next Stage, in which Hargrove outlines his thoughts on the development stages of a programmer. While it's hardly a science, I think he did a pretty good job of outlining the different growth stages a software engineer might go through.

At this point you may be wondering why I thought of this article when thinking about the topic of "What makes a better software engineer?" (Or better yet, you may be wondering why I was thinking about any of this while in the Florida Keys, but that's another topic.)

Well, while discipline is an important attribute to becoming a better software engineer (or as mentioned before, a better anything), another equally important attribute is a desire to reinvent yourself.

Reinventing yourself means to have an insatiable appetite for knowledge and recognizing how to apply that knowledge. It is our ability to change our habits and world views in order to become the person we are trying to be. Continuous improvement is another popular phrase that means the same thing. Essentially, "good enough never is."

I thought of Hargrove's article because his stages of programming are essentially about reinventing ourselves. As we progress through the stages we have to change our habits and perspectives on software development. If we fail to change, or reinvent ourselves, then we fail to progress and become better software engineers.

I know Stage 1 programmers with years of experience. I also know Stage 6 and 7 programmers (whatever 7 is, they are there) with years of experience. Besides their technical skill, the only real difference between the two is that the Stage 6+ programmers were willing to adapt, change, or reinvent themselves as they progressed in their careers. The Stage 1 programmers just went along with the daily grind.

This concept of the "better software engineer" is a very gray area, so nothing should be viewed as mutually exclusive. For instance, a person with good discipline may find it easier to reinvent herself than a person with little self-control, but then maybe not if the person uses discipline in such a way that it prevents themselves from changing.

At the same time, there are certain attributes that successful people have, and if we want to be successful, then it is in our best interest to learn how they do it, regardless of the field or discipline we are in.

This is a question I've asked myself often over the years, primarily because I'm constantly asked to teach others how I "do things". The problem is that I don't know how I do things – I just do it, like Nike. No really, I once said that during a radio interview.

But regardless, I've still thought about the question. As a result I'll probably post more about this because I've come to realize a number of factors contribute to the "betterness" of a software engineer (or anything for that matter), but one aspect I've thought about more seriously is discipline. Better software engineers, better artists, better management, better athletes, better anything all have one thing in common: they have discipline.

Do a blog search for "discipline and business" and check out the types of articles using the word. They all revolve around a central theme of success. It's not a huge secret, but millions appear to miss the fact that discipline does several things for you:

1. It keeps you focused. If you can't focus, then you're more likely to be distracted, which means you'll get less done.
2. It helps you "nail the details" while also seeing the big picture. This is critical in leadership, but also in engineering. The better engineers are very detail-oriented, but not to the point where it's crippling as they also recognize the big picture. The details they nail are things like processes, configuration management, quality, and good algorithm design.
3. It says, "I am in control" and provides leadership. Human nature trends away from chaos and toward organization. If you are disciplined, then you are perceived as being in control and organized, and people are more likely to drift your direction. You have your sh%t together, so to speak, and people want to have their sh%t together, too.

Maintaining discipline isn't easy. It requires constant improvement. Although, one of the best things I learned while playing baseball was the concept of WIN: What's Important Now.

The concept is simple: If you find yourself adrift or losing focus, then ask yourself, "What's Important Now?" If you answer the question honestly, then you'll know what you need to do, and you'll stay focused on achieving your goals. That's the first step to discipline.