The Joy of Programming

I’ve seen many tech companies where people on the business side have a complete lack of understanding of what motivates software developers or makes them do the work they do. This results in dissatisfied and demotivated developers that are eventually going to quit and move on to work on something more exciting somewhere else.

While it’s usually hard to put the joy we get out of programming into words, The Mythical Man-Month by Fred Brooks does a very good job with that.

Here is a quote from the book’s first chapter:

Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and find it helpful. in this respect, the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of the principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another, the problem is always new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

I believe that there’s a balance that can be struck between work that engaging, challenging and fulfilling, and work that is financially rewarding. Focusing on either side and ignoring the other results in dysfunctional companies that are bound to drive employees away.

Side Projects

At any given moment I’m always working on a little side project. Some times they ship, usually they don’t (I only have TracKit and Photos Cleaner on the App Store, and one more app in review as of this writing).

Usually when I start telling people about the side projects that I’m working on, they wonder why am I wasting my time on projects that I have no interest in monetizing or that might not even ship. I have a very good reason.

Stupid side projects are always a healthy thing to do. You don’t expect any of your side projects to be the next Facebook or Twitter, or to change the world, but you keep on building them anyway. You build them because they are things you personally need. You build them for education, either about a certain technology or a certain aspect of business.

Since I’m usually not expecting to make money out of my side projects, I skip the market validation part and jump right into building them. That sometimes means sketching it on a piece of paper to make it clearer for myself, or on other occasions it means starting to code right away.

In side projects I get to be as meticulous as I want. I have no deadlines so I get to do things the way I see best, which occasionally means completely scrapping some parts and rebuilding them, and that is always great for learning. I also get to try whatever new crazy technology or language that looks cool but is too crazy to use in my full-time job.

It would be great if a side project turned into something that makes a decent amount of money, but that’s never the intention when I’m working on them, and that’s what makes them very special. I’ve learned a lot working on side projects, and I’ll continue to do it for as long as I have the time.

What stupid (or not so stupid) side project have you recently worked on?

Migrating SVN Repositories to Git

I’ve recently had to migrate a few SVN repositories to Git (can you believe there are people out there still using SVN in 2014?). This is a quick guide that walks you through all the steps you’ll need to migrate your repositories including all the history, branches and tags.

The steps below will perform a one-way migration, which is what you want to do when moving permanently off SVN to use Git. There are ways to keep both the SVN and Git repositories synchronized with each other, which I won’t be discussing here.

This short guide is based on Atlassian’s excellent 6-page guide, which you should refer to if you want a more in-depth explanation.

I’ve performed the migration using Git version 1.9.3 (Apple Git) and SVN version 1.7.17. Commands may vary slightly with different versions.

1. Download Tools

The migration can mostly be performed using the Git’s build-in tools, but for convenience, Atlassian has created a set of tools that would make the migration easier.

Download Atlassian migration tools from their BitBucket repository.

2. Mount a Case-Sensitive Disk Image

Skip this steps if you are not doing the migration on OS X.

Migration needs to be performed on a case-sensitive file system. Since OS X isn’t case-sensitive, we will need to mount a case-sensitive disk image to use for the migration.

$ java -jar ~/svn-migration-scripts.jar create-disk-image 5 GitMigration
$ cd ~/GitMigration

This will create a 5 GB disk image called GitMigration.

3. Create Authors File

Next, we need to extract all the usernames that made commits to the SVN repository and convert them to Git’s format of a full name and an email address.

$ java -jar ~/svn-migration-scripts.jar authors http://svnserver/path/to/repository > authors.txt

Open the newly created authors.txt file and modify the generated placeholder names and email addresses to match their actual values.

4. Clone Repository

This will do a svn checkout and convert the repository locally to a Git repository. We are also passing in the authors file we’ve just created to use while converting the repository commits history.

This assumes that your SVN repository uses the standard layout of trunk, branches and tags.

$ git svn clone --stdlayout --authors-file=authors.txt http://svnserver/path/to/repository <git-repo-name>

$ cd ~/GitMigration/<git-repo-name>

5. Clean Repository, Branches and Tags

This will convert SVN branches and tags into standard Git branches and tags.

$ java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git --force

6. Add Remote and Push

Add a new remote to the local Git repository.

$ git remote add origin https://username@github.com/team/<git-repo-name>.git

Now push all branches to the newly added remote.

$ git push -u origin --all

And finally, push all tags.

$ git push --tags

Your repository has now been completely migrated to Git. The final step is to forget SVN ever existed and enjoy using Git.

More on Hiring Software Developers

I wrote a blog post a few months ago about hiring software developers. After which I decided I no longer want to do programming puzzles interviews. I believe the best way to show my skills to a potential employer is to either do a task related to what I would be working on and submit for evaluation, or to work with them for a few days on a actual project.

I’ve recently done an interview that involved a task, and it proved to me that even tasks can be screwed up in a way that shows nothing about the potential hire and does not evaluate their skills in any way.

My task was to request a feed, parse it, and display 3 pieces of information and an image in a list. This task was way too simple to prove anything. Any beginner iOS developer can do this and I thought I would finish it in a maximum of 15 to 20 minutes.

That particular company’s APIs use JSON but they can’t give me access to the APIs, which I do understand. So instead I was given a URL to an RSS feed to work with. While that makes the task a bit harder for me since I never had to parse RSS feeds before, it also makes it even more pointless.

To me it was like going for a driving test, and being told that all I need to do to pass the test is to start the car. That doesn’t prove in any way that I can or cannot drive. To make it even worse, instead of giving me a car, they would give me a truck. Now I need to figure out how to start a truck, to prove that I can drive a car.

I took me 2 hours to figure out how to parse the RSS feed, extract the data I need using regex (since it was all inside a single tag) and present it in a table view.

I ended up being rejected. When I enquired more about the reason I got rejected I was told that it was because of my speed. Again, that is totally pointless. Does completing the task in one hour instead of two prove I’m a better engineer? I would have taken far less time if I worked with RSS before. So was the task’s main goal to test whether I can work with RSS or not? Also pointless, since they don’t need that particular skill (which anyone can learn in a very short time anyway).

I thought that programming puzzles interviews make companies miss out on good engineers because they don’t show their real skills, and that tasks were much better. Turns out you can make tasks dumb enough to do the exact same thing.

Join the discussion below or on Hacker News.

Software Estimates Suck

People suck at estimating how long a task will take. We are often off by a factor of two or more when estimating seemingly simple everyday tasks, like running errands, so imagine how bad we are at estimating complicated tasks like building a new software feature.

Now imagine estimating a set of features instead of just one, or even a whole project upfront. Time estimates in such cases quickly become pointless. The biggest challenge in my opinion about estimating a whole project upfront is that you don’t know the complexity of the problems you are trying to solve until you actually start solving them. Moreover, those problems you are trying to solve never stays the same. Requirements change, problems get more complex and projects often suffer from feature creep.

You’ll be inclined to think that if a task is very similar or identical to a task you have done before, then it’s going to take exactly the same time. You’re wrong. It’s very unlikely that 2 tasks are identical. Chances are the requirements are going to be slightly different, design will change a bit, you’ll be working with different people, etc. These are all things that will increase (or decrease) the time required to finish the task.

One more thing that always make time estimates highly inaccurate is the time needed to fix bugs. You can’t leave that time out, but you also can’t estimate how long it will take to fix bugs you don’t have yet, and there’s no one-size-fits-all time frame that you could assign to bug fixing that would work for all tasks. Sometimes you spend days debugging a single nasty bugs, how could you estimate that kind of stuff?

Moreover, people always ignore the time needed for daily communication. A lot of friction may happen in human interaction, especially if it’s across teams. There is usually misunderstanding and confusion that leads to a lot of delays.

So estimates suck, but they are a necessary evil,  so now what? I like to take Jason Fried’s and David Heinemeier Hansson’s advice from Rework. Never estimate a bulk of tasks. It’s much easier to divide into smaller tasks and put estimates separately. So break the project into many small projects. Your estimates will still be wrong but you’ll be a lot less wrong.

Also, if you’re working in a large development team, you’ll often be surprised at how different estimates from multiple people for the same task could be. My favorite way of dealing with those situations is to play a game, a Planning Poker game. In my opinion, it’s the most efficient way to get people to agree on a reasonable estimate for a single task.

One last thing, never give in to your Pointy-haired Boss‘s request to do the same task in half the time because “you’re a smart engineer, you can do it”. It just doesn’t work that way. While your estimates are probably wrong, they are still your guess of how long it would take to finish that task. No one can simply jump in and ask you to finish in less time, unless they have a very good reason, and of course an arbitrary deadline is never a good reason.

How do you deal with estimates in your team? Let me know in the comment below.

Hiring Software Developers

I’ve been reflecting recently on my past few years working as a software developer. During those years I’ve had a lot of job interviews. I got many rejections, a few job offers and never heard back from some companies.

This is a review, from my own perspective, of what works and what doesn’t work when it comes to interviews and hiring processes for software developers.

The Programming Quizzes Interview

In this kind of interview you have to solve ACM kind of problems, brain-teasers, or general Computer Science quizzes. Things like finding the shortest path to traversing a graph. Any good Computer Science fresh graduate will probably be able to go through such interviews with ease. A few years later though you’ll struggle with answering most questions, simply because they have absolutely nothing to do with what you actually do in practice. Can you even remember when was the last time you had to write an algorithm to traverse a graph? Those interviews are the worst as they give absolutely no indication about how good or bad someone is going to be when they get hired.

You Seem Nice, Here’s a Job Offer

No technical interview, no tasks, absolutely nothing. This has actually happened a couple of times with me and they just left me baffled. If that’s how you have picked the rest of the team I will be working with, then thanks, but no thanks, I can’t work for you.

I’m not really sure how some companies decide to hire people entirely based on how nice their CVs look, or based on a short conversation they had. You’d be surprised by how often people make things up in their CVs.

Go Do a Task and Get Back to Us

I have encountered 2 different kinds of tasks that fall under this category. Some companies give you a generic task that they give to all candidates. Those tasks are usually designed to test your understanding about specific parts of the technologies they are using, your coding style, and how scalable and maintainable your code is. I like those kind of tasks as they show my skills in a much better way than answering some stupid questions on the spot.

What’s even better is the second kind. Your task is actual work on one of the company’s projects and your code might be used in production at some point. This not only shows your technical skills more accurately, but also shows how you communicate with the rest of the team, how you approach the problem and understand the logic business behind it. Most companies that do this kind of tasks pay you for it, whether you get accepted or not.

Come Work With Us for a Few Days

Some companies invite you to come work with them for a few days. You don’t have to be at their office 8 hours a day, but you have to show up at least a few hours everyday for 2 to 4 days. I believe this is the best way for a company to get to know candidates and see how they fit with the rest of the team, it’s also great for candidates to know the people they will be working with and see if they are comfortable working together and also get to experience everything about the work environment of the company. The only problem with this is that it’s often hard to do for candidates already working full-time at another company.

Finally…

If you’re hiring a developer, specially in a startup, I urge you to ditch CVs and traditional interviews. Ask people for their Github accounts. Ask them to tell you about a personal project they have been working on recently. Invite them to come work with you for a few days. Whatever you do just make sure it gives you a meaningful indication about their skills, not how good they are with word processors or solving Computer Science quizzes.

Update: Thanks for the tree vs. graph heads up.

There have been some nice discussion about the article over at Hacker News. Make sure you check it out.

Update 2: Sunil Sadasivan has recently published a very interesting article about the hiring process at Buffer. Check it out on Medium.