Learn to type quickly

Dear new developer,

Coding is so much more than typing into a computer. Other things that matter:

  • knowing who to talk to
  • what to build
  • when to discuss high and low level concepts
  • other processes like testing and documentation
  • communicating progress
  • course correcting when a project goes awry

These are all skills you need to be a great developer.

However, just like knowing the command line and a text editor, knowing how to touch type will make you more effective. Touch typing is the ability to type without looking at the keyboard with all 10 of your fingers (if you don’t have use of all your fingers or you use fewer, you can still type quickly).

Typing well is especially important because many forms of communication are text based (slack, email, ticketing systems). But even for plain old coding, being a touch typer will help you be more effective. This is because you’ll be able to implement things more quickly. You should learn your keyboard shortcuts for commonly used programs too.

You can Google “practice touch typing” and check out several sites (paid and free) to improve your speed. There are also competitions out there like typeracer. I was lucky enough to learn to touch type in school, so I haven’t had to try any of these out.

However, a big caveat. If I had the choice between being a fast typer who didn’t understand a problem space or a slow typer who did understand a domain, I’d pick the latter. Often, the best code is no code. So, focus on understanding and then solving the problem. Make sure you make your fast typing skills work in service of solving the correct problem, so you can be the fast typer who does understand the problem space.

Sincerely,

Dan

The perfect is the enemy of the good (and the done)

Dear new developer,

When you are facing a problem, it can be very tempting to try to solve it perfectly. Handle all the possible edge cases, make it extensible, have it be configurable without code changes.

As with everything in life, there’s an opportunity cost to this perfection. If you’re spending days perfecting a single page of a webapp, for example, you won’t be able to move on to the next feature.

There are times for perfectionism, without a doubt. When data could be lost or security could be compromised, you want to move slowly and carefully.

For the rest of the time, good and done is better than perfect and undone.

Of course, the definition of ‘good’ is the crux of the above statement. Unfortunately, this is a judgement call, depending on context, team and risk. One thing that is non-negotiable is that the code meets the requirements. If it doesn’t work, then nothing else matters.

Some things to think about when you are considering what ‘good’ is:

  • How often will this be used? Once a second? Once a year? Once?
    • The more often code is used, the more it should be polished.
    • Note that usage often changes over time, so it’s worth keeping an eye on this and spend some time cleaning up code if it moves from the once a year category to the once a week category.
  • Is this a relatively static part of the system, or is it in flux?
    • If you’re touching this once and don’t expect to touch it again for a while, taking some extra time makes sense. Niggling bugs may live for years.
    • On the other hand, if this area of the codebase is churning, polish could be wasted because the code may be trashed.
  • What are the risk factors if this fails? Will someone be killed? Will money be lost? Will someone be inconvenienced?
    • Obviously, the higher the risk, the more care you should take.
  • What is the next thing on the list?
    • If you have other high priority issues, you may want to avoid polish.
  • What is the team quality ethic?
    • You should meet and improve that standard. For example, in the context of testing: if no one writes tests, set things up to write tests. If everyone writes unit tests, think about integration tests. If everyone writes integration tests, think about performance regression tests.
    • This is a great topic of conversation at an interview or team meeting so that everyone can be on the same page.
  • How permanent is this code?
    • The more permanent the code, the more care should be taken.
    • Some code lives on servers and is easy to change. Other code is shipped to mobile apps and is harder to change. Yet more is distributed to IoT devices and really hard to modify (when is the last time you updated your router’s firmware? I thought so.). Some is burned to read only memory and can’t be changed short of great expense.

One question that I’d avoid asking is “how will I feel about this code in 12 months”. Because I know the answer–you’ll cringe. At least, in all my discussions of running code, I’ve never met someone who revisited old code and didn’t find at least one thing to improve.

Two examples, rating the above factors on a scale of 1-5 (where 1 indicates you should just get it done, and 5 indicates you should get as close to perfection as possible).

  • Your website portfolio:
    • Usage: 3. Used maybe once a year or two (if you are an employee) or maybe every month (if a contractor), when someone is checking you out.
    • Static or churning: 4-5. relatively static. You probably build out an example app once.
    • Risk factor: 3. You’re looking for a job, and your portfolio is a powerful signal, but not the only one.
    • Next thing on the list: ?
    • Team ethic: N/A
    • Permanence: 1. This is a website, so you can ship new code whenever you have time.
  • Billing software on your large public site:
    • Usage: 5. Used many times a day.
    • Static or churning?: 4-5. Should be relatively static as payment processing doesn’t change that often.
    • Risk factor: 4-5. Billing mistakes are expensive.
    • Next thing on the list: ? Depends on the company.
    • Team ethic: ?
    • Permanence: 2. You have the code on the server, but you have a lot of history and state to maintain.

When you are working on code and struggling to get to ‘done’, I encourage you to consider the above questions to guide your decision. Finally, don’t forget that (most) code can be revisited. If something is good and done now, ship it. You can typically improve it next week or next year if the code needs it.

Sincerely,

Dan

Don’t try to change the tabbing / bracing style

This is a guest post from Andrew Rondeau. Enjoy.

Dear New Developer,

Don’t show up an a new job and immediately try to change the tabbing and/or bracing style. This is especially important if the codebase you work on has a very consistent style that all of the other developers follow.

Why? Tabbing and bracing styles are really a matter of personal preference. What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more important than having your favorite style. Furthermore, because tabbing and bracing styles are really a matter of personal preference, arguing with the more senior developers about this topic is a waste of everyones’ time. The senior developers, or your manager, will probably assume that you have poor time management skills, or that you get obsessed with details that don’t matter.

And, yes: An interesting discussion can be had over the merits of tabs versus spaces, or the merits of braces before or after the newline. The problem is that some people really get irrationally attached to whichever style they are used to. These discussions don’t fix bugs or deliver features that the business needs to survive; thus, don’t waste time and stick with whatever tabbing and bracing style your codebase uses.

When is it important to discuss tabs versus spaces, or bracing styles, as a new developer? When a codebase has an inconsistent style, especially if it doesn’t match a team’s style guide! Politely point out to your manager, or lead, that there is a lot of inconsistent use of tabs and/or braces; and suggest a tool that will automatically reformat the code. Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple. At that point, it’s your manager or lead’s discretion if your team will adopt a new style.

If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. Why? Again, a consistent style is more important than being able to write code with your preferred tabbing or bracing style. Inconsistent code is harder to read, and confuses people about what the established style really is. It also tempts people to stick with their preferred style, instead of whatever the team agreed to. Instead, use an automated tool to reformat the code.

— Andrew

Andrew is the desktop client architect for Syncplicity, a file synchronization product. Here’s his LinkedIn profile.

Learn a little jq, awk and sed

Dear new developer,

You are probably going to be dealing with text files sometime during your development career. These could be plain text, csv, or json. They may have data you want to get out, or log files you want to examine. You may be transforming from one format to another.

Now, if this is a regular occurrence, you may want to build a script or a program around this problem (or use a third party service which aggregates everything together). But sometimes these files are one offs. Or you use them once in a blue moon. And it can take a little while to write a script, look at the libraries, and put it all together.

Another alternative is to learn some of the unix tools available on the command line. Here are three that I consider “table stakes”.

awk

This is a multi purpose line processing utility. I often want to grab lines of a log file and figure out what is going on. Here’s a few lines of a log file:

54.147.20.92 - - [26/Jul/2019:20:21:04 -0600] "GET /wordpress HTTP/1.1" 301 241 "-" "Slackbot 1.0 (+https://api.slack.com/robots)"
185.24.234.106 - - [26/Jul/2019:20:20:50 -0600] "GET /wordpress/archives/date/2004/02 HTTP/1.1" 200 87872 "http://www.mooreds.com" "DuckDuckBot/1.0; (+http://duckduckgo.com/duckduckbot.html)"
185.24.234.106 - - [26/Jul/2019:20:20:50 -0600] "GET /wordpress/archives/date/2004/08 HTTP/1.1" 200 81183 "http://www.mooreds.com" "DuckDuckBot/1.0; (+http://duckduckgo.com/duckduckbot.html)"

If I want to see only the ip addresses (assuming these are all in a file called logs.txt), I’d run something like:

$ awk '{print $1}' logs.txt
54.147.20.92
185.24.234.106
185.24.234.106

There’s lots more, but you can see that you’d be able to slice and dice delimited data pretty easily. Here’s a great article which dives in further.

sed

This is another line utility. You can use it for all kinds of things, but I primarily use it to do search and replace on a file. Suppose you had the same log file, but you wanted to anonymize the the ip address and the user agent. Perhaps you’re going to ship them off for long term storage or something. You can easily remove this with a couple of sed commands.

$ sed 's/^[^ ]*//' logs.txt |sed 's/"[^"]*"$//'
- - [26/Jul/2019:20:21:04 -0600] "GET /wordpress HTTP/1.1" 301 241 "-"
- - [26/Jul/2019:20:20:50 -0600] "GET /wordpress/archives/date/2004/02 HTTP/1.1" 200 87872 "http://www.mooreds.com"
- - [26/Jul/2019:20:20:50 -0600] "GET /wordpress/archives/date/2004/08 HTTP/1.1" 200 81183 "http://www.mooreds.com"

Yes, it looks like line noise, but this is the power of regular expressions. They’re in every language (though with slight variations) and worth learning. sed gives you the power of regular expressions at the command line for processing files. I don’t have a great sed tutorial I’ve found, but googling shows a number.

jq

If you work on the command line with modern software at all, you have encountered json. It’s used for configuration files and data transmission. Sometimes you get an array of json and you just want to pick out certain attributes of it. Tools like sed and awk fail at this, because they are used to newlines separating records, not curly braces and commas. Sure, you could use regular expressions to parse simple json, and there are times when I’ve done this. But a far better tool is jq. I’m not as savvy with this as with the others, but have used it whenever I’m dealing with an API that delivers json (which is most modern ones). I can pull the API down with curl (another great tool) and parse it out with jq. I can put these all in a script and have the exploration be repeatable.

I did this a few months  ago when I was doing some exploration of an elastic search system. I crafted the queries with curl and then used jq to parse out the results so that I could make some sense of this. Yes, I could have done this with a real programming language, but it would have taken longer. I could also have used a gui tool like postman, but then it would not have been replicable.

sed and awk should be on every system you run across; jq is non standard, but easy to install. It’s worth spending some time getting to know these tools. So next time you are processing a text file and need to extract just a bit of it, reach for sed and awk. Next time you get a hairy json file and you are peering at it, look at jq. I think you’ll be happy with the result.

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

Know when to not throw in the towel

Dear new developer,

I wrote previously about when to throw in the towel. Now I want to mention when you shouldn’t.

Anything worth doing is hard. That includes software development. There are times, sure, when it feels like you’re a superhero. When the code is flowing. When you can hold the entire system in your head.

Those times are great, and, in my experience, rare.

There are also times when it’s a grind. When you look up at the end of the day and wonder “what did I actually do all day?” When you are picking up a new technology or system and it feels like you are on the last move of a game of Jenga, with all the pieces about to fall over.

This is the time when you need to stop, take a deep breath, and then keep going. That doesn’t mean you can’t pop up and ask questions or take breaks, but sometimes the only way out is through.

There’s an art to knowing the difference between a grind that you have to get through and a wall that you can beat your head against without making progress. I don’t have a simple way to differentiate, other than to say that the grind often happens at the beginning of a project (when you don’t know what you don’t know) and at the end of a project, when that last 5% that you put off because it was hard balloons to 25% (or more).

I have told teams in the past that “if we aren’t learning and making mistakes and doing new things, we aren’t doing it right”. That’s because if a software engineer knows how to do something, they’ll likely automate it (and then they won’t have to do it again).

Sometimes that learning process is joyful. Sometimes it grinds. You have to push through.

Sincerely,

Dan

Laziness, impatience, hubris

Dear new developer,

Larry Wall has created foundational software (perl, patch). He coined the three virtues of a programmer:

  1. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it.
  2. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to.
  3. Hubris: The quality that makes you write (and maintain) programs that other people won’t want to say bad things about.

These may seem crazy. Who wants to be seen as lazy, impatient or full of hubris?

But if you think deeply about it, Larry is saying that laziness makes you work in the short term to save effort in the long term. That impatience makes you write better code because computer time is less valuable than your time. And that hubris makes you want to develop software that you can stand proudly behind.

Makes a bit more sense, no?

Sincerely,

Dan