Professional incompetence

There were a few interesting threads on the Joel on Software discussion forum last week. They proved to be interesting reading on just how wrong a developer can go, with or without realizing it.

The short version is that poster Brice Richard took issue with the recommendations of other posters that applications should be written as, in his words, "all mini-functions." He then went on to describe his coding methods and argue that his way was right; if not for everyone, than at least for his circumstances.

Now, the title of that second thread was actually a little misleading. I actually read that one first, and I initially thought he was referring to the arbitrary guidelines on subroutine size that you often hear thrown about without any real supporting evidence. For example, some people say that a function should never be longer than a dozen lines, or that all functions should fit on one screen in you editor. That last one always sounds nice - unless you have poor eyesight and a small monitor.

But that's not what Mr. Richard was talking about. He only believes in writing separate functions when:

1) there is a bona-fide reason to believe that the code will be re-usable in other apps
2) when you have duplicative functionality within your application that results in the need to create a function that defines that functionality through either value or referential arguments allowing your code to execute variably when used.

And apparently he doesn't view 300+ line functions as a cause of concern. And all this from someone who has been in the consulting business for 8 years.

Part of the reason for this is probably that Mr. Richard is, in his words, a self-taught programmer who always works alone. Of course, there's nothing wrong with being self-taught. In this business, we're all self-taught to various extents. To quote Dr. Kelso from an episode of Scrubs, "If you've been out of college for more than five years, half of what you know is obsolete." There are always new technologies to learn and most schools don't even come close to covering all of what you need to be a professional developer.

However, as Jeff Atwood pointed out today, working alone can be dangerous. And it's not just the project management issues described in the essay he cites. When you don't have other people to learn from, you end up having to work harder to educate yourself. You need to read more, experiment by yourself, and try to validate your results based on just your research rather than peer input. You have no one to practice with or bounce ideas off.

It's important to remember that this is 2007. Software development is still a young field, but it's no longer in its infancy. Translation: you don't need to go about rediscovering how to do things. When people talk about "doing things your own way" and the like, that's usually what they mean. It's much better to study the recommendations of the experts and use or adapt them as appropriate.

When you're working alone and aren't vigilant in your studies, it's easy to fall into bad habits. It's also easy to get stuck in your ways and not learn new techniques or technologies. The forum threads I mentioned above are a good example of this. Working alone isn't necessarily detrimental to your skills, but it's much better to have smart people around to give you an occasional reality check.

Of course, you can still end up working with other developers who have no concern for modern practices or procedures, and hence don't help much. But that's a different story....

You can reply to this entry by leaving a comment below. This entry accepts Pingbacks from other blogs. You can follow comments on this entry by subscribing to the RSS feed.

Add your comments #

A comment body is required. No HTML code allowed. URLs starting with http:// or ftp:// will be automatically converted to hyperlinks.