There’s nothing as universally controversial in this world as change. Change can be (in aggregate) for the better or for the worse, yet people will always be split down the middle. Some will believe that the change is a good thing, and others will see it as a bad thing. Often your view points will be dictated by your perspective and how the change will directly effect you. When it comes to software projects and change, what’s the right thing to do?

Last weekend I was at the True North PHP conference in Toronto, Canada. Aside from being an incredible experience (really, it was an incredible conference, huge props to Chris Hartjes (@grmpyprogrammer) and Peter Meth (@mrpmeth)), it was an inspiration. I was particularly inspired by both of the keynote speakers. They both really took really unique spins on programming and how the culture of open source inspires, enables and empowers programmers to do cool and important things. The problem with all of this is that I hate the term programmer. I think it unfairly paints a picture of what we do. Let me elaborate.

Or anyone else for that matter. Lately, I’ve been getting a lot of feedback about my posts that I’m suggesting things that are going to get less experienced developers into a lot of trouble. Or that people are going to use my posts as justification for bad practices. Or that people are going to cause major issues by putting experimental concepts into production. My initial response is “That’s their problem.”

“Don’t Reinvent The Wheel” is a phrase that we hear used all the time in software development. Usually it’s used in the context where a library exists to do what the user wants, but they are writing their own. While the sentiment is usually correct, I can’t stand the implication of the phrase. Therefore, I can’t stand it when people use that phrase without understanding what it really means. Let me explain:

One of the things that I see repeated over and over again is the simple question “What books should I read to become a better developer?“. Or “How did you learn about that?“. Or even “What does a coding standard matter?”… OK, so that last one was a bit of a sentinel question, but the point is clear. Where should you look if you want to read to improve your development abilities? Well, I figured I’d take a few pages out of my library and share which books worked for me, in order of significance. If you remember from a prior post, I indicated that you should choose concepts over implementations. This list should illustrate that.

The other day I had read an interesting post by 37 Signals entitled Why We Don’t Hire Programmers Based On Puzzles, API Quizzes, Math Riddles or Other Parlor Tricks (say that 10 times fast). Then I was pointed to another article by C for Coding entitled Interview Programming Problems Done Right. That got me thinking about the interview techniques that I’ve used at my current and prior jobs. It’s a different style than either of those two posts, so I figured it was worth talking about.

One of the most frequent questions that I get asked is “How can I become a better developer?” I think that it’s a very good question to ask that deserves a good response. But how can you respond to something like that? Becoming a better developer depends so heavily on past experience (where to grow), interests and rationale (why do you want to grow), that it’s really hard to answer without a fair bit of discussion. This post reflects my experiences from both my own growth and the growth that I’ve seen in others.

A tool is only as good as how it’s used. It seems like such a simple concept, yet it’s amazing to see how many people get caught into the trap of thinking that because a tool is there, they are safe. We see it all the time in almost any industry. Company X pays untold millions of dollars for a product, just to find out later that it didn’t do what they needed. It’s such common sense that it’s hard to think of someone logically arguing against it. Yet the same mistake is made over and over and over and over again. And on August 18th, we saw a really blatant example of this with PHP’s 5.3.7 release.

Today’s IDEs (Integrated Development Environments) provide a lot of features that make development significantly easier. From error checking and debugging to intelligent syntax highlighting and refactoring, there are a significant amount of time saving features available. One of these commonly loved features I have disabled, and found it has made my life easier as well as the code I write better. The feature I am speaking of is autocompletion…

Quite often we see people talking about the best way to approach a problem. Usually this involves taking a relatively simple concept and making it fairly complicated to make it as flexible and maintainable as possible. While I’m all for maintainability, I think that sometimes we miss the point that it all depends on context. It seems like most people don’t understand the difference between good and good enough.

Part of being a developer is making design decisions based on conflicting goals. Our job is to choose the line that’s appropriate based upon our experience and the needs of what we’re doing. But there-in lies the problem: How do we know where that line really is? How do we know when we’ve actually reached the point of good enough?