21–30 of 47 posts
I subscribe to the Build Stuff school of programmer evaluation. Why do you hire a programmer? So you can have him build stuff. Has he built stuff? Then he can probably build stuff. If he hasn't build stuff, he might be able to build stuff, but it is a better idea to have somebody else pay to figure out whether he can build stuff or not.
So, if everyone follows your philosophy, how do people get started building stuff?
You could write a "How to recognize a good [X]" article about almost any profession if that's your thesis.
Let's face it, the vast majority of work programming isn't that hard. A lot of programmers, perhaps especially the good and smart ones, might rationally realize that having a life outside of work--in other words, working a 9-5--often makes more rational sense than putting all of one's considerable intellectual energy into writing yet another CRUD (or whatever application du jour one normally writes) remix.
Earlier quoted context omitted.
Hint: You do not have to be employed by a company in order to build stuff.
When I say "if everyone follows this philosophy," I include both VCs and college acceptance boards in that antecedent. Then, presuming you don't have a trust fund, the only way to get your start building stuff is to do it on the side while being underemployed; this is a net efficiency loss for the economy.
I feel guilty even typing this much, because I don't think you're being intellectually honest at all. The vast array of open-source and free projects in the world speaks plainly about the ability of people to build useful things outside of work.
The only reason I ask is that I consider myself a late-bloomer, and after reading Coders at Work (which I highly recommend) I was kind of bummed out that I squandered my opportunity in college by not hanging out with CS crowd. It seemed like so many of Seibel's interview subjects accomplished so much in this period and were more or less born to be programmers. . .it sounds trite when I read it aloud but I can no longer ignore this unspoken caste system amongst programmers.
I subscribe to the Build Stuff school of programmer evaluation. Why do you hire a programmer? So you can have him build stuff. Has he built stuff? Then he can probably build stuff. If he hasn't build stuff, he might be able to build stuff, but it is a better idea to have somebody else pay to figure out whether he can build stuff or not.
Hiring a programmer who has built stuff is like hiring a contractor who has shown an ability to do carpentry work. It's swell when all you need is the carpenter equivalent of a programmer; but often there is more involved than just nailing lines of code, classes and modules together from someone else's specification.
So, having a criterion of having built stuff is not sufficient, although I think it is reasonable. What qualifies as "stuff" is pretty subjective, though, and probably can't be anything but subjective. As I mentioned above: biases abound.
You also need to make sure they are able to figure out what to build and how, and sometimes what not to build -- whether that means they buy it, or it is a superfluous component.
You need to make sure they can think about what they are doing, rather than just being able to do things. The couple of outside projects I've become involved in so far, and some of the code I've read for other projects I'm not actively working on, suggest that some people don't do enough thinking. They've built plenty, but they didn't appear to build it with any goal but to build version 1 and be done. Think the software equivalent of a contractor coming in to fix what the first carpenter screwed up, because the first carpenter didn't care once the house passed inspection.
The code I've dealt with inside of organizations I've worked for is, if anything, worse than the code outside. But just looking at the end product wouldn't indicate anything is particularly wrong, excepting that maybe improvements to the site tend to occur only once every geologic era. Sometimes this can be indicative of quality of the developers; sometimes it is indicative of the quality of the management. Either way, it may not reflect on the developer you are talking to.
Depending, the developer may be able to think at many levels, and might be able to think lucidly about their work from a business strategy perspective. And depending on the organizational culture, this can either be a wonderful thing, or the most undesirable thing imaginable.
But this is all based on some amount of personal bias based on the kind of work I would want to be doing. I know there are places where programmers are expected to be nothing more than carpenters given specifications by the system analysts to turn into code. In these cases, I can see showing just an aptitude for building things to be enough. But I don't think these cases are common enough to warrant a single best practice.
I know OP means well, but this post provides far more data about his own experience than anything that can be reliably used by the reader. What he calls "indicators", I call "co-factors". They may or may not accompany a given programmer, and they predict nothing. Generally speaking, good programmers are intelligent and do care about their work, but his positive indicators are much more a matter of personal preference…
Unless you are presuming a team of only a couple of developers doing their own thing, there is a real challenge in determining the extent of the programmer's responsibility for something that is exposed for all to see.
There are a number of other causes that might make a site a developer helped work on look or run like complete garbage. Organizational inertia might have forced the site into sucking, regardless of how good the programmers developing it were. The organization may have one or more bad programmers who were assigned to work on some critical component, screwing the whole site and all the good programmers.
We can wax on eternally about how the good programmers in this situation should've seen the writing on the wall and gotten out as soon as possible, but that's very easy to say seated in armchairs gazing from afar. Maybe they thought things were going better than they really were; maybe they saw things going bad, and thought they could motivate others to turn things around before things become a disaster -- and maybe they failed trying to do that[1]; maybe they have been trying to get out, but they are already tainted by the bad work of the organization that has become part of their image as well.
They could do work outside of their employer, for instance on an open source project, but these can succumb to the same sort of pressures that push profit-seeking organizations toward mediocrity. A single developer, even a really willful one, will have a hard time overcoming this inertia.
[1] At one of my prior employers, I was in this boat; I both tried and failed to get things turned around. I did quit, but probably not soon enough to convince people that the site was not a reflection of me and my standards. The site was absolutely shameful, and I'm sure anyone who used that site to infer things about my skill level would've sworn I had no skill or experience outside of a weekend PHP crash course. Granted, it would vet one organization I would probably not want to work at; but it would represent wasted potential based on presumption, which is a shame.
I really think the details matter, because they are a chance to determine if the work you are using to assess the programmer is spurious input, and reflect an influence largely made up of things other than that programmer.
In practice, how much of this article is about informing business folk and how much is about patting ourselves on the back?
Just something I noticed: "If your potential programmer didn’t do any programming before university, and all his experience starts when she got her first job, she’s probably not a good programmer." This is the only time he uses the female pronoun anywhere in his post, and he uses it to describe a programmer that started in college and isn't any good. Conscious or not, it's somewhat accurate; female cs majors are less…