Programming Is Terrible, So Learn To Enjoy It

Dear new developer,

I appreciated this post which talks to people who are interested in being a developer, rather than someone who is newly a developer. I still think a lot of things apply.

This especially resonated:

…programming is terrible, so learn to enjoy it. If you are “on the net” learning about what programming is like, listening to the voices that get the most attention, you are probably getting the “Hollywood version” of what it means to work with software day in and day out. Now don’t get me wrong, I love programming. My best days are when I can take off the many other hats I wear and just focus on a development project and writing tests to go with it. But, it’s not all roses, and you should be prepared for that.

Here are some things that are terrible about programming (and counterpoint).

  • The tool set is always changing. What you learned two years ago may or may not be useful to you now. But some technologies age better than others, and you always have a chance to learn something new.
  • There are two modes of development that are radically different (deep thinking and communication), and you have to switch between them constantly. But you get to do deep thinking!
  • Error messages don’t make sense. But Google can help with that. And so can you, by blogging about the error after you figure it out.
  • With modern applications, there’s a ton of complexity and you can’t possibly understand everything. But you can put together an amazing application that would have taken a team of developers by yourself or with a small team.
  • Sometimes, you may be the expert in your problem, which can make it hard to find help. I remember writhing on the floor trying to figure out one of the most difficult problems I’ve ever solved (figuring out an editing interface and rules for recurring events on a calendar with child events that needed to have different durations than the parent event) and realizing that I could ask no one about it. But, you get the chance to be an expert!

Of course, every job has its warts. And development is no different. But programming and development are in a rapid state of flux. This means that you must (and get to) learn every day.

Sincerely,

Dan

Egoless programming

Dear new developer,

This post is worth reading in full, but is advice that holds for all developers, not just folks starting out.

I especially liked

Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.

and

You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

But all of them are good. Go on, go read it.

Note that these principles (though not the post) are from a book published in 1971. Technology changes yet people remain the same.

Sincerely,

Dan

Learn your standard library

Dear new developer,

If you want to be good at interviews, learn your algorithms. Loads of companies treat algorithm knowledge as a proxy for general problem solving ability. It makes a certain sort of sense–you have to break down a problem into pieces, turn it into something software can digest, and implement it in code. You can practice these at places like HackerRank. Like any proxy, they can be gamed, which is why tech interviewing feels like a fundamentally broken process. (See this great post about humility in interviewers for another piece of the puzzle.)

But if you want to be good at your job, learn your standard library. This is the piece of software that surrounds you, in which your software will execute.

I remember the time when I was a contractor and started at a new place in the early 2000s. Someone there had written their own connection pooling library. This seemed like madness because it’s a complicated piece of work and there were several free implementations available for the language (though, to be fair, none were part of the standard library). This code, which provided very little business value, would have to be maintained and bugfixed and upgraded.

Every modern language has a definition (this includes syntax and keywords) and a set of associated, standardized classes. These classes allow developers to “stand on the shoulders of giants” and should be used whenever possible. Why? These libraries evolve over time as the language is released and have a number of beneficial properties.

  • Using the standard library lets you accelerate development. You don’t have to roll your own hash or tree, you can just use the one that ships with your library.
  • It is far more likely to be correct. This can matter a little, if incorrectness introduces a bug. Or it can matter a lot, if incorrectness causes your system to be fundamentally insecure. Standard libraries have a lot of eyes on them, including specialists.
  • As a corollary, standard libraries handle edge cases. They are well used code, in the sense of this post (source code doesn’t rust). If the language is used by any number of people, it’s going to be more bullet proof and handle weird edge cases that your self rolled code won’t handle (until a bug is discovered and fixed).
  • It will be more performant. Again, this is because the effort to make operations faster is amortized across all of the users, so specialists and experts are more likely to be involved.
  • The standard library for any popular language will be maintained over years, likely by developers you won’t have to directly pay.

All of these benefits stem from the fact that more people work on standard libraries than work on code in your company.

But, you have to know the standard library to gain all of these advantages. Unlike the syntax of a language, you don’t need to know the standard library to get things done. While you can’t roll up your sleeves and start coding until you know the syntax of ruby, php, java, clojure, haskell, javascript, etc, you can code for quite some time without knowing all the ins and outs of the standard library.

This is because standard libraries can be large: Java has thousands of classes in their standard library, and even a language with a small library like Javascript has about seventy objects, many with tens of properties or methods. It takes a while to learn. Plus, new developer, it can feel like you’re not doing much when you are reading docs. Certainly such reading  isn’t as fun as banging out code. But, it will have two benefits for the codebase:

  • you will save time in developing because of all the benefits above. You may have to invest some time up front, but once you do, you’ll be faster for the rest of your career.
  • you will write idiomatic code. Other developers who are familiar with the standard library will know the characteristics and behavior of the code you write.

and one for you:

  • you will gain a transferable skillset. Learning how to write the particular kind of ruby that your company uses is not nearly so valuable to other companies as learning the standard library.

How can you learn the standard library? I’d recommend taking a high level overflight. Google for ‘<language> standard library overview’ and read whatever articles or listen to whatever presentations are available. I’d also recommend just scanning the docs and seeing what piques your interest.

After you have that, the best way to learn the standard library is to use it. When you are about to tackle a problem, make it a standard part of your process to ask “is there a standard library function for that”. It can be difficult, but as it becomes a habit your code will become better and you will learn to trust the authors of the standard library.

If you have time and inclination, you can also search for ‘<language> koans’ which are small exercises in languages. These will often exercise the standard library. See Ruby Koans for an example.

When there is more than one way to do it using the standard library, which happens more in some languages (like PHP) than in others (like golang), think about the options and then try to be consistent.

So, learn the standard library. Make the time.

Sincerely,

Dan