The problem is that our industry doesn’t know how to draw the line between the person dabbling in programming and someone who does it for a serious living. The kid who builds the bird house above would never be hired to build an actual house. Not true in Software Development.The .com era was the perfect example of this. Anyone and everyone was a programmer once they knew HTML. This dillutes how our industry is viewed by the outside world. It keeps us in the ‘geeks w/ keyboard’ box.
Memoirs of a Bystander – I’m not anit-newbie
A couple of thoughts about Griffin’s post (and his prior post):
I am absolutely in favor of providing the basic logic of programming to non-programmers. It can only help them understand why the requirements they produce need to be carefully written.
The “Geeks with keyboards” worldview is a problem of both sides – you won’t find anybody under 30 who has never touched a computer keyboard (and very few people under 25 who never had to fix a configuration problem on a computer, even if it was just to run Doom), so that view simply no longer applies.
On the other hand, we “geeks” shouldn’t think we’ll never need our people skills because we’ll always be coding and therefore everyone who can’t write kernel drivers or run a windows device driver under the debugger must be a dumb jock. This is an endemic problem in our industry as well.
In my opinion, books like this help blend that line in precisely the right fashion.
As far as the problems of the industry, hiring poor performers (note that I didn’t say “people who don’t know language X”) is definitely a problem, but it’s not solved by adding a “line” past which you’re considered a “programmer”. It can be better solved by proper technology management.
The reason the dot com era had so many clueless people was not because these people were hired (everyone makes a bad hiring decision once or twice, especially in a tight market), but because they were allowed to stay. That requires a management that didn’t understand how to measure these people’s contributions to the team, or didn’t want to go through the trouble of getting rid of the poor performers, or didn’t want to show upper management that their hiring skills are, let’s just say not that great.
So poor management shares a lot of the blame. On the one hand, you have the manager who doesn’t care about the technology or doesn’t understand it, so they can’t know what is involved in writing software, which means that they can’t tell when progress is not happening. On the other hand, you have techie managers that aren’t good at setting or enforcing goals (or following up, or standing up for the team, or many of the things good managers do well), so they just let anything slide. A tight labor force and slow ramp-up times help contribute to
managers slacking off on feedback.
So you need to solve both problems. First, teach management skills to your promoted techies. Behind Closed Doors by Rothman is a great example of this. Second, teach a bit of technical skills and proper requirement definition to anybody who may remotely come in contact with a software development project.
A good technology manager will understand the technology involved and the people interactions. He or she will work to remove roadblocks for the overall team, and this includes getting rid of people who “just picked up the guitar yesterday” (or putting them in their proper place in the team).
technorati tags: management