Hiring programmers

Part of my job as CTO is to hire programmers and hiring good people can be quite a challenge these days. Plenty of jobs everywhere and it seems that everybody has a job (or two) already. But anyway when I'm interviewing a programmer I always search for three things (inspired by Joel Spolsky ). Smart, get things done and fits into the team. As Joel says:

First of all, the #1 cardinal criteria for getting hired at Fog Creek:

    Smart, and
    Gets Things Done.

That's it. That's all we're looking for. Memorize that. Recite it to yourself before you go to bed every night. Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute.

I added the "fits into the team" from my own experience. We are in need of team players. Programmers who are able to educate and help other programmers. If you hava a small team that must work the best part of the day together they'd better get along. So when I talk to people I always place them in the team and try to figure out how it will match. Also I won't hire anyone unless the candidate had a succesfull interview with a future team member and I get the thumbs up from them.

For smart and gets things done I already have a standard set of questions to ask. For "fits in the team" i'm really on tin ice. It's judgemental and therefor I'll never hire or dismiss anybody on my opinion alone and I'll make sure candidates that fit into the smart and gets things done but not in the  "Fits in the team" catagory will speak to others as well. Maybe not perfect but still better than nothing.

Innovation: stop talking, start walking

A lot can be said about innovation. But no bridge has been build just by talking. We have to start walking. But how? And in which direction? At work we have the classical problem: the only time we are able to innovate is when something new is sold within a project. But new things are rarely sold because the sales people don't know what the techies are capable of.

As CTO I'm also responsible for technical innovation and this problem was a hard one for me to address. On one side I hear a lot of programmers with great ideas but no time. On the other side I hear the non-technical projectleaders and sales people that we can't keep up with the competition.

So how do we innovate? We have adopted the idea of technical innovation days. On these days we will have brainstorm sessions where programmers will present some great stuff they've been working on. This can range from just some basic idea on a whiteboard to a working prototype. These presentations will last 15 minutes max and then there is time for brainstorming and discussion.

The second thing we are doing is building an internal brainstorm site (like http://www.dellideastorm.com/) where everybody can post their ideas and comment on and "Buzz" other people's idea's. Those are just some basic steps, but like every journey innovation starts with the first step. Giving room and platform for ideas and creating a brainstorm buzz!

Every day is a surprise

It's been a strange week. No single day has been the same. I'm still trying to get a grip at my new job. What should I do, what not and how should I do stuff. This week I have been visiting customers, meeting potential partners and doing quality assurance work. Every day new plans arise about great stuff I should do. So many new plans that I hardly have time to finish my old ones. This is a familiar story for me: to many plans for only 24 hours in a day. Slowly I'm getting the control back of my day to day job. It takes a lot of planning and keeping lists of "what to do today". But it get's the job done and that's the start!

Things I didn't learn at school: sourcecontrol

I graduated in 2003 as Bachelor of Information Technology from school for professional education in Holland. I did learn a lot to be a software engineer. Coding, requirements analysis, UML modeling, database design etc. But still I'd lacked a lot of "working" knowledge or maybe it's just a lack of experience. But one thing I really learnt the hard way is sourcecontrol. The basic stuff I already experienced at school. The usefull parts I did not. And while I know the theory by now, I'm still struggling with taking it into practice. But still I think that good sourcecontrol is essential for delivering quality software with as less problems and hurdles as possible. I learned a lot of valueable lessons about sourcecontrol during work but still it would really have helped if I learned this stuff at college.

At my company we work with visual SourceSafe end vary basic sourcecontrol mechannis as check-in and check-out. And that was sufficient until some months ago. We now have multiple locations around the world and we had a lot of issues dealing with maintance and developing simultaneausly on projects. Thats when SourceSafe started to hurt. We need to abilitity to easy share projects with people around the globe and we need sharing and branching. But I still can't figure out how it works in SourceSafe.

So we are on the hunt for a new Source Control system to help us overcome this problems. Team Foundation server looks promising, as well as SourceGear vault and subversion. The next weeks we will decide between those systems.

prologue

Some time ago I was just a coder, then I became a developer. I developer with a passion for coding. I really love being a programmer and creating great software. Technical solutions for people. As a developer or a programmer my job was clear.

A few months ago I became CTO of the company I work for: a Dutch internet company employing 25 programmers in 3 different countries. And by that my job was not so clear anymore. As it appears there is no common job description for CTO's of any kind. So I will blog about my experiences for learning and amusement, I hope...