How I Got My Silver Programmer Certificate

OK, I didn't. It doesn't exist. It won't exist.

There's more than one way to look at the ongoing kerfuffle over whether schools are falling down on the job or not. You can play the hyper-cynical devil's advocate and point out that in a sense, undergraduate computer science degrees are right up there with vo-tech degrees (not that there's anything wrong with that).

a degree is only as meaningful as its scarcity

Which brings us to another way to look at it - we can quit the ball-aching already because the knowledge that colleges are teaching Java instead of Lisp means pretty much fuck-all for us. Seriously. If I'm staffing for a company, I'm not pinning my hopes and dreams for future success on the fact that I've got a few recent computer science graduates working for me, even if they're from an ostensibly top-tier school. I'm hiring the guys with track records for delivering software that can talk the business domain talk (and it's a really awesome bonus if they can talk radix tries too).

College degrees don't prove that you're ready to develop in the real world. Holy shit.

Wait. This is news?

Certificates, whether they're diplomas, training certificates, passing the bar, getting your doctor stethoscope, being a certified engineer, whatever - I read them as signifying one thing only - "this person's certified to prevent me from doing anything immediately catastrophic." The lawyer may be grossly incompetent at what they do, but they'll be able to advise you enough to not land you on death row for your parking tickets. The doctor's not going to prescribe dioxin for that headache. The engineer's not going to say "what the hell, it might work" to your grand plan to replace the steel girder wire on the bridge with Silly Putty. That comp sci grad will probably be able to put something together that compiles.

You're looking for a piece of paper that certifies that the holder is an all-world programmer who's going to fix all your code problems? Sorry, doesn't exist.

Still another takeaway from this - enough already with whatever feedback loop there may be. Businesses think that they need more computer people, so they drive up demand for comp sci graduates, so colleges lower the bar for what it means to be a comp sci graduate so you can get churned out to go work at a conglomerate. I'm a schlub who went this route (or this route found me, your call), so who am I to turn my nose up at it?

This seems to presuppose the notion that there's a supply-side fix to be made here - get businesses to understand just how meaningless the comp sci degrees are and academia will disentangle itself from business and we'll find ourselves in some sort of OK-well-maybe-it-never-existed nirvana where every computer science graduate can knock out a generational garbage collector blindfolded and works on their own system kernel just for kicks; that academia's gotten too caught up in what business needs rather than keeping their heads in the clouds and looking decades down the road.

I don't buy it. I became a programmer because I've got a terrible craving for learning. I think that's the thread that underscores all at least mediocre programmers - we're auto-didacts. It's why I giggle to myself when I see the "how can I teach my son to program" question thrown out there. If they really want to, they'll find a way. If they have to be dragged there, I'm sure they'll find a 9-5 in the cube next to mine some day.

It's why I'm left scratching my head about people bemoaning the death of the comp sci degree. Saying silly things like "you go to school to learn how to learn." Bullshit. You're born knowing how to learn. Some people will learn no matter what, others are content with what they've learned and will figure out how to apply it in new, interesting and sometimes inappropriate ways and still others make me wonder just how fictional Idiocracy was (kidding! (maybe)).

Management Conundrums - The Cowboy

I read an article refuting the value of crunch time and got to wondering about it.
I've been the cowboy before, working 100+ hour weeks. Dreaming in code, pulling 24 hour days, a real Team Player. I don't want to ever go back there again. I'd like to prevent people I work with from going there too.
I found crunch time to be a vicious cycle. Rather than sit back and think my way through the problem, I dove in head-first and bumped my head on the bottom. Hard. Repeatedly.
I found myself working long hours, making mistakes along the way, and then working longer hours because I told myself "I'll just fix this later." And then working longer days because I couldn't remember the fix that I had in my head earlier but it all seemed so clear to me and in retrospect, fuck embracing death march values.

To push my street cred through the roof, I'll just quote Bun B who puts it better than I do.

Start with your head, homie, then use your hands / If you try it in reverse, you don't even stand a chance.

I don't know if it's confirmation bias on my part - I'm a pretty lazy guy (note to anyone daydreaming of hiring me: I'm totally joking about that). Am I just buying into what these people and their so-called "studies" are saying because I'm (*cough* not) lazy and want to believe anyone that's telling me that working a square 40 hours a week is really OK and even preferable?

The thing is, not everyone believes it - and this is not just managers that I'm talking about, either. As the comments on the article over on programming.reddit show (and as my anecdotes reinforce), some developers have an almost bloodthirsty need to believe in the power of crunch time. There were a couple of chaps in there extolling the virtues of brutal hours of work, stating that without doing months of crunch mode, their projects wouldn't have finished. I prodded, trying to lead them down a path to questioning whether the projects might have finished in the same amount of time without crunching for it, but it was rejected out-of-hand.

The Mythical Man-Month gave us the should-be-more-famous truism that "you can’t get a baby in one month from 9 women" - some tasks really are going to take a set amount time no matter how many resources you throw at them. The mother can start pushing on day one or wait until month nine to start pushing; the baby's not coming out any faster no matter how many months she's been pushing. I think that believing that you can accelerate nature (I'm talking development projects now not babies; work with me, people) is equal parts foolhardy and arrogant, but I also think that a good developer needs a healthy dose of both of these qualities.

When it's a team gelling and putting in the overtime because they want and need to, you let it go. That's a no-brainer. Of course, you can't go on auto-pilot. You need to figure out when they're sprinting to a dead end, when they've started sprinting too soon and have been sprinting so hard that it's counter-productive and maybe you should kick them the fuck out of the office at 5 PM on Friday so they can see their families and come back ready to do good work on Monday. You need to reel them in at some point. Like any design pattern, "crunch time" has its use. Just take care to not treat it like a golden hammer and you'll be fine.

It's the lone cowboy that I'm concerned about, and I'm concerned about what to do with them. When it's a team working to a goal, they're building together. When it's the lone person banging away at all hours, they're using their back more than their brain and will miss simple, obvious solutions to their problems and get aggravated at everyone else who isn't putting in the same brutal hours they are.

Part of me wants to save them, but then again I'm not sure that anything can be done with or for them. Reason, logic and studies seem to bounce off of them (it did off of me) like bullets off of Superman's skin.

At my current job, we had a cowboy developer. Good developer, smart guy, put in long-ass hours. Went on vacation, came back in with a custom XML business rules engine (like Drools) that used .Net Reflection and all that good stuff to drive it. It's pretty good code, just that in retrospect... we didn't really need it. I never had the heart to tell him that outright and thousands of lines of code nobody wants to refactor out of the application remain today.

When he eventually left, another of our developers quietly became the new "hard worker" to pick up the imaginary slack left behind. I don't know that I'd even have noticed this quiet change if I hadn't read The Lucifer Principle by Howard Bloom (this and The 48 Laws of Power are Dave Solomon picks for bizarroland must-read management books).

In The Lucifer Principle, Bloom relates an anecdote about a researcher's study at a summer camp. The researcher had identified four major archetypes for kids in group behavior - the "alpha male", the "bully", the "joker" and the "nerd" and conducted an experiment with them (nothing on the level of Milgram or the Stanford Prison Experiment).

The scientist assembled a cabin composed entirely of "leaders," boys who had been dominant, "alpha males" in their old groups. Very quickly, the new cluster sorted itself out according to the familiar pattern. One of the leaders took charge. Another became the bully. A third became the group joker. And one of the formerly commanding lads even became the new group's nerd.

- The Lucifer Principle, Howard Bloom, pg. 92

I know I'm doing a terrible job explaining this, but what it comes down to is that I've seen the shift in my co-worker and I don't think it's a conscious one. He may think that he "needs" to work longer hours (I've certainly danced around it trying to get him to feather the brake pedal on it, so to speak) to get things to work, but could he explain why?

Of course, self-interest on my part demands that I don't push them too hard to not kill themselves. I'm not the boss and if he's not doing the long hours, I'm sort of afraid that someone else is going to give me the stink eye because I'm not checking in code after midnight just before I leave on vacation to show that I'm a team player, never mind that the code's invariably broken in some hideous ways and people are going to have to quickly find and fix all the mistakes I've made because I was tired and rushing.

Moreover, like I said, I suspect that there's some subconscious understanding about the archetypes (for developers, read: "design pattern") of a team, and that the "overachiever" is one of them. I know just how loaded the word archetype is which is why I think it's probably an aft metaphor - if our work habits are indeed an unconscious manifestation of our identity, then there's no clean way to divorce one from the other - the cowboy's going to keep drawing for that six-shooter no matter what you do and resent you for telling him to keep it on safety before he blows his foot off. They may not be able to do it any more than you could conquer someone's fear of snakes just by bringing to their attention the fact that they are, in fact, terrified of snakes (I suspect this is an easier one to break though). Moreover, you get rid of one and another will rise to the occasion.

Unless you do what you can to make them and everyone else on the team aware of your distaste for their overwork and unless your boss (and bosses all the way up) are on board with holding people to a square forty, I doubt it will happen.

Sadly, getting everyone to throw fallacious common sense overboard and accept the fact that working smarter and working harder are just about always mutually exclusive and working smarter beats working harder just about every time isn't an easy task. If it was easy and if these work archetypes didn't exist, then everyone wouldn't be positive that today's Dilbert (for pretty much any value of Dilbert) just had to have been sent in by one of their co-workers.

But I'm no manager, so I keep on doing what I can to make things better, forty hours a week.

Meaningful Certification is Hard

When I read Raganwald's post on certification a while back, I was impressed by what laid underneath the surface. What he's looking to certify out of the gate is a first-pass cut to weed out the scrubs and find people with a shared set of values that is not up for discussion - no matter what you're doing or how you're doing it, if you can't prove that you're doing it correctly and safely, it hasn't been done. I like the idea because it implicitly weeds out the people who can't program all that well in the first place; if getting it to compile is a chore, tacking on unit tests and being able to talk coherently about why injection attacks are rendered irrelevant is certainly going to be beyond your means. If it's a certification done on a small scale, you're going to be finding an exclusive group of developers and you're going to have a high degree of confidence in any of them and as such, you've pretty much rendered the cover letter+resume then let's small talk thing moot - you're hired.Of course, this ignores a harsh reality. If there's an economic incentive to having that certification, there will invariably be ways to game the certification. I've interviewed (and worked with) enough incompetent but acronym-accredited developers (IBAADs, copyright MEEEEEEEE) to pay certifications little mind at all. They're not bad, but all that's being certified is that the person's achieved some encylopediac familiarity with the terms of the field rather than a true understanding of how and when to apply them... more on that later.

More recently, Joel's posted about just how lame undergraduate programming courses are. Did you know that people come out of school patently unprepared to do development work? This is, frankly, SHOCKING. That last sentence was, frankly, sarcastic.But don't despair people - software is hardly the only profession where this sort of thing is endemic.

I'm friends with some lawyers and I generally hear the same thing - going to law school and passing the bar is tough, but all it does is certify that you've achieved a base level of competence; they come out of the process thinking that they're ready to take on the world and are pretty immediately humbled when they realize just how unfit they are to do any lawyering. It takes 18-24 months for a freshly bar'd lawyer to be able to do much of anything beyond researching case law, being mentored by more experienced lawyers most of the time. Doesn't this sound familiar?

I can't help but see the similarity with getting my degree in information systems - I graduated with good grades (cum laude, what!) and was sure that there wasn't anything I couldn't do. I look back on my first few jobs/years of professional work and shudder at how awful of a developer I was. I look back on code I wrote a year ago and shudder at that too. At this point I don't think that any amount of education could fulfill all values of "rigorous and practical", let alone most of them. This isn't to give JavaSchools a free pass or whatever, because I've interviewed people from them and their abject lack of passion for the craft is a ferocious turn-off for me.

In that regard, I'm with Joel. I don't expect that people are going to step out of school ready to do it all (not gonna happen) but I do hope that they'll have been exposed to more than one way of doing things. In my time, I brushed up (and a few hours a week for a couple of months is about all that I got in most cases) against x86 assembly, C, C++, COBOL and, yes, Java in my four years of college. I'd like to think that I took a little something away from each of these languages about how you can make software work and the lack of LISP or some other functional language is the reason I'm learning Haskell and going through The Structure and Interpretation of Computer Programs these days.

Lawyers go through as much college as I did and then 3 more years on top of that and then a certification on top of THAT and at that point, they're still so green that they require a year or two of more or less intensive mentoring to become productive. Word on the street has it that doctors do all that, except that they're putting in hundred hour weeks while they're mentoring to boot.

I understand Joel and Raganwald - I wish that there was some way to certify that the developers have a shared set of values, a shared passion and a capability to rise to the task that's put in front of them, but looking for this to come from schooling or certification is, or so it would seem to me, praying for a magic bullet.

And even those JavaSchools that churn out mediocre developers serve their purpose - we can't all be superstars. A great certification or four years of a great school won't turn mediocrity into a hacker god, and not every piddly project needs a superstar developer. Certifications and education are both fine signifiers, but it'll take something more rigorous than either to signify what we're all after.