GitHub

I recently created a sprite API library for TypeScript and decided that I wanted to make it open source. Maybe give myself some more programmer cred. Since GitHub seems to be the coolest place these days to put open source code I decided to try it out. Perhaps I was a bit naive, but I thought it would be pretty simple to do. I figured I would just go up to the website and upload a few files and voila, I'd have an open source repository. Boy was I wrong.

It was pretty easy to set up an account and create a new code repository. But then I couldn't find any way to add files to it. You can add new files, but you can't upload existing files from the web site. After much research I realized that you need to install Git (an open source version control system) on your computer and use that to manage the files.

GitHub actually has a GUI for Git that makes it easier to use. I installed it but it didn't work. The process would start but then die a few seconds later. So then I decided to go install Git directly and do it the old fashioned way. Git is primarily a command line tool, but it does have a simple GUI with it. That did work but it took a while to figure out how to fetch and commit and push files. It's a completely different process than I'm used to as we use Perforce where I work.

Finally, after many hours, I did get my code files up on GitHub and am getting the hang of it. But what I thought would take an hour at most turned into many hours and a lot of learning new things. I ended up putting up two repositories which you can find here: https://github.com/jodymgustafson?tab=repositories

Finding Good Programmers

Today I heard about a question that was asked at an interview for a programmer. It was something like if you had 25 horses and raced 5 at a time how many races would you have to run to find the order from best to worst. I don't know, but to me that sounds like the dumbest interview question ever. How does that tell you anything about the person's programming ability. It would tell you if they're good at solving esoteric riddles maybe. But tells you nothing about their programming skills.

It reminds me of an interview I had early in my career. They wanted me to take a 2 hour "quiz" where they gave me a couple dumb problems, like the one above, and I had to figure out how to program them. Not on a computer mind you, but with paper and pencil. I don't know about you, but I make a lot of changes as I program. Needless to say it didn't go so well.

Then there are the people who ask trick questions, usually about oddities in their programming language of choice. You know the ones I'm talking about. Maybe they give you a piece of code where you have to find the missing semicolon or something dumb like that.

So I started thinking: what is a good way then to tell if someone is a good programmer? Well, first you need to define what you mean by a good programmer. In the above cases they must think a good programmer is someone who can solve riddles very quickly. Or can program using the least number of  lines of code. Or is good at finding typos.

Now for my definition. Let's look at what a good programmer really does. I think most importantly they write code that is easy to read and understand. Their code is modular and efficient. Because they write code in this fashion it's relatively bug free and it's easy to modify. Good programmers are excellent at breaking down complex processes into simple, easy to understand chunks. They find a way to share common code rather than copy and paste it.

Now that you know my definition, how does one test for that? Here's my idea. Find the worst piece of code that you can. You know you have some. Maybe you didn't write it, but some guy that got fired 5 years ago did and no one will touch that code now. Or just go make up some bad code. I've seen enough bad code to know what it looks like. It's almost impossible to read; it's one huge method with 500 lines of code; it's verbose and inefficient; etc, etc.

Then sit the candidate down in front of a computer with the IDE you use and tell them to make it better. If they ask "better in what whay?" say "any way you want". Now see what they do. You can tell a lot just by watching someone work at programming. Some people do everything the slowest way possible (like copy and past using context menus). Unless they are applying for an entry level position this may indicate that they don't really care enough about getting things done quickly to learn some keyboard shortcuts. When I first started out I was absolutely amazed at how quickly the people that were my mentors could move code around. It didn't take me long to learn.

Watch what changes they make. Are they attempting to make the code more or less readable. Are they breaking things out into method calls to make the code easier to read and consolidating common code. Are they using variables to hold values that are computed multiple times. If you've been programming a while you get the drift of what I'm talking about.

Then when you're done with that, and they've done a good job, ask them to describe at a high level how they would implement something that you've implemented in the past. This will give you an idea of how good their architecting skills are. These are the kind of problems you should be asking someone to solve rather than a riddle that has nothing to do with the job.

These are the things that make someone a really good programmer. If you are interviewing people and you don't know how to assess these things then get one of your senior programmers to help you. There are a lot of people who are good BS-ers, but they can't BS their way through this.

What do you think? Am I completely whacked out or are these the kinds of things that programmers should be asked in an interview.