Conjuntion junction meets Certification Specification

A post over here at Raganwald got me thinking the other day. The post was about certifications for programmers and got started by posing the situation where he posted his resume with a recruiter and got back a request asking him where he attended college. The post itself goes on to discuss certifications (ala getting a degree) as a means to attempt to discover if someone is capable of doing the job at hand or the job that they are being requested to do.

This same post goes on to point out that in some respects certifications may be of use, but that the certifications might be working on the wrong things in order to pick out a good programmer. This post was also picked up over at Enfranchised Mind where the writer attempts to point out how Raganwald may have missed the boat when he stated that his programmer certification test would consist mostly of understanding the different ways in which you can be measured as a programmer.

Personally I think they both gloss over the nits/grits of the issue. Raganwald is correct, IMHO, in saying that he thinks that in order to be a good programmer you need to understand what you are being measured with. If the objective measure is a ruler, then anyone can be a good programmer. If the objective measure is how many lines of code you write, then a bunch of monkeys can be good programmers. IF however your measure is how much code did you write that:

1) Solved the problem that you were presented with
2) Solved it in as few a number of lines of code as possible
3) While simultaneously not producing any (or at least as few as possible) bugs

Then the pool of people that you are talking about being able to do the job suddenly gets quite a bit smaller. The understanding of this is important and I believe that he is attempting to point out the importance of knowing what your measured with is one of the important points of being a programmer. More Specifically that his certification (at least a first level certification) would have the programmers he certifies understanding this point in depth and completely before he would let them loose on the world.

The other blog article seems to wander off into the weeds a little and points out some things in the Raganwald article the he takes deference to. Then wanders into a diatribe about Ocaml and static typing (possibly as a dig or as an attempt to point out that he is not a Blub programmer). I think the thing this second article gets right however is that learning what makes a good programmer is an ongoing process. That in general people are still trying to get a good handle on what a good programmer is, and how they work. Which begs the question again of what individuals are using to measure against.

The point that I think they both miss is the thing that it is hard to discern in an interview "What has your experience brought you above and beyond the basics that make you a good programmer for BigCo?" I think the question says it all - a good programmer for a given place. Each programmer will bring a different eye and a different experience to what they do. An older more seasoned programmer might be what you are looking for, but seasoned in what way? It is difficult at best to, in a 30 minute interview, understand what a singular person brings to the table - so does the certification help? Is it about what language you write in/know?

I would argue that it isn't about those things - its about what information you bring to the table, its about the "Learning" you have done over time. Its about the intangibles - the things that are DAMN near impossible to 'test' for that make you a good programmer. There are certainly some things that you aught to know (like how you are measured) - but there isn't anything that can test for your experience and certainly nothing that can test how your experience applies to how you program/solve problems. Your experience (like the second post points out with commentary about solving problems and how you solve them, buy vs. build decisions etc.) is what makes you a truly 'good' programmer. Book smarts and understanding need to be there, but beyond that is what counts.

Is it good to be perfect?

So over on raganwald there was an interesting quote pulled from an article by Steve Yegge that I believe attempts to point out just how much he loves working at Google. The article goes on to essentially point out that Google seems to do everything right in terms of software development. The appropriate levels of documentation are always available, the correct unit testing and other information is always completed and as blasphemous as it may sound developers are given a bit of free choice and input into what it is that they are actually doing/developing. THIS sounds a little bit like a Utopian society of developers but is it really? Steve attempts to point out that the way Google has done it is part of a discipline he states:

"I don't think you can get that kind of software-engineering discipline without doing it right from the start, and creating a culture that enforces and reinforces that discipline as the organization grows."

While this may be true is it the reality? This statement would seem to exclude all those companies that didn't start out in the way prescribed. Does that make sense?

I think what the quote is missing is that most companies are in the software business because they have to be, not because that is their main focus or even their main business driver. Take for instance BigCo. BigCo has a range of products that it offers to people. The products that BigCo. offers are what drives its business. Now it just so happens that the products that BigCo. offers are sold through the web and that BigCo. also has a fairly large IT department managing all the systems that deal with the product that it sells. The process that BigCo. follows grew out of the product process not out of a software development process. Does that fact make what BigCo. does for software development inherently flawed - or better yet would it make the avg. software developer mad? I am going to guess that like most things some portion of the way software is developed would and some would not. In the end however I would argue that it is still possible for BigCo. to come to a similar nirvana as Steve has found in working for Google.

Companies grow and they change a great deal in their life times. Alot like humans grow from children into adults hopefully learning along the way. This learning process can be long and it can be arduous but it can be done. What I would argue that the change from child to adult software development requires is good people that are willing to help BigCo. move towards a vision of nirvana. I would argue that being the 'Perfect' development shop from the start may leave no room to grow, to change, to expand the horizons and most importantly it will lack the people with a questioning eye for how the process runs. Without the questions the process, no matter how good it is, may stagnate and start to blemish or tarnish and when it does - those developers living in nirvana won't know how to fix it because they have been too happy for too long.

Personal Hell (Working Fire)

So I was bouncing around the blog sphere this morning and located the following post on creating a personal hell and I have to say that I liked it quite a bit. Not only did it have a nice listing of classic development process mistakes but it went on to describe how he [the blogger] managed to get himself into a small circle of hell all its own by making some of the mistakes (OK making most of them) listed in the second post. Well worth a read if you do any sort of software development.