Monday, March 29, 2010

Secrets of the Rock Star Programmers

In keeping with my quest to learn I picked up Ed Burns' book Secrets of the Rock Star Programmers. The questions in the introduction piqued my interest:

How in the world can I keep up with all this information coming at me every day?

What can I do to ensure that I keep bringing value to my employer or client and to help ensure continued career success?

What will the practice of software development look like in ten year's time?

How do I know where to invest time and effort in stewarding my skillset?


The claim on the back cover, "Find out what it takes to push your programming chops to the next level and design killer software by getting inside the minds of today's rock star programmers", is a bit over the top but it was great to get a little insight into the thoughts of some of the industry "suns" that I follow.

After finishing the book I'm struck by a couple of things: the programmers interviewed in the book, the rockstars, are mostly (much) younger than me and mostly less "experienced" than me. Damn! - I'm older, I have more years in the industry but I'm just another coder.

I don't need to be a rockstar but it would be great to be recognized as someone who can deliver well designed, high quality applications. Or as Rod Johnson (one of the Rockstar programmers) said, quoting E.M. Forster, "...earn the respect of people that I respect."

Some other quotes that stood out for me:

Rod Johnson:
I think if you consistently find that the right thing is hard to do, there's something wrong. The right thing should be the right thing partly because it's easy and natural to do. If the right thing is unnatural, that is kind of an environment smell. It's beyond a code smell. It's telling you something.

...about 90 percent of the work that I've seen where people are optimizing code in a business application is a complete waste of time, and they're simply making the application more bug-prone...prove to me that it's a problem before you spend any time making it faster.

Hani Suleiman:
Be skeptical...There's too much eagerness: "let's follow this new approach," "let's do this new thing," and so on...Everyone looks at the upsides; no one looks at the downsides.

Floyd Marinescu:
Ultimately, we're solving business problems - I think a lot of developers need to remember that the purpose of the job is to build applications [that are] useful to users. The software is only as good as how it serves the functional and non-functional requirements of the application.

Dave Thomas:
Many IT professional don't have the concept of "component" or "system." It's just not how they think about the world. This is one reason why enterprise business objects and business architectures often run into difficulty. These organizations are frequently driven by a project culture versus a product culture; hence, components, reuse, and other long-terms investments have little value. Trying to do component engineering in a project culture is very, very difficult because the driver is "How does this help me get my application done faster?" This is always in conflict with any kind of object architecture, business objects, etc.

No comments: