Tag: basics

The Surprising Number Of Programmers Who Can’t Program

Dear new developer,

This came up in a Hacker News comment thread recently:

I’ve been working since the 90s and I never attempted to do FizzBuzz. Is it really relevant? Maybe to screen junior developers out of college?

And the response

So, as someone who spends maybe 20% of their time hiring, it’s still a very effective screen. You wouldn’t believe how many people can’t do it. People at big companies, respected places. It’s surprising.

I find it truly surprising. Here’s a post from 2007 about the same issue, so it’s been around a while. From that post:

…I’m starting to get a little worried. I’m more than willing to cut freshly minted software developers slack at the beginning of their career. Everybody has to start somewhere. But I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs.

As a new developer, realize that

  1. You are going to stand out among other applicants if you can program.
  2. If you can’t program, you need to fix that asap.
  3. There are some folks that are just not effective programmers who somehow are in the profession (or seeking employment). You may end up working with and for some of these people.

So, make sure you practice programming. My letters have been about some of the other aspects of software development, but if you can’t do the basic work, you’re going to have a tough time. That’s like a baseball player who can’t run. Doesn’t matter how good someone is at catching a ball or hitting, if you can’t run, you’re going to be fundamentally disadvantaged at baseball.

Sincerely,

Dan

Learn to use a debugger

Dear new developer,

When you are fixing a bug in a program you are working on, a key thing to do is to get an understanding of the state of the system. This can include user input, stored values from a persistent data store, and non recurring information like the current time. But the most important piece of state is that of the program in memory. What function or procedure is executing when the bug appears, and what did all the variables look like at that moment?

Reproducing a problem with a test or sequence of steps is crucial for being able to solve it. You should take every step you can to make sure that your debugging environment is the same as the environment that the problem is appearing in. I remember one program I was debugging that worked fine in development, but failed miserably in production. It used Google Web Toolkit, which compiled java down to javascript. In development, even when I compiled it, the obfuscated variable names were different. That ended up being the issue–there was a variable name collision between the compiled javascript and another javascript that wasn’t namespaced correctly. I tore my hair out and was reduced to putting in console.log statements on production.

And that’s how a lot of debugging happens–printing out log statements to a file. You can solve many problems that way, it’s extremely portable and customizable, and it gives you some insight into program state.

However, a far better solution is to use a real debugger. They’ve been around since the 80s, at least, and give you far more insight into a program’s state than log statements. You can see the state of any variable. You can run commands interactively. You can stop anywhere, and restart the program. If you pair an interactive debugger with an automated test, you can have an extremely tight feedback loop that will help you zero in on the issue at hand.

Most of the major languages have such interactive debuggers (in fact, that’s one way to decide to avoid a language; a development language without a real debugger is likely to have other language level issues, like a poor dependency management story). Some languages even have standard protocols where you can connect to remote servers with a debugger. If you ever have to debug a production issue and can enable that, it’s going to be super helpful.

Debuggers are often integrated with an IDE, but some are runnable on the command line. Whatever your language, just google for “<language> debugger” and find out more about this valuable resource.

Sincerely,

Dan