Learn an IDE

Dear new developer,

Just like you should learn a text editor, you should learn an integrated development environment (aka IDE). This is typically a standalone program focused on one or more programming languages. They range from free to a couple of hundred bucks in pricing.

Using an IDE will give you the following benefits:

  • It will be easier to navigate a project. Typically IDEs have a tree view of the entire project. Especially if you are not familiar with the command line, having this may make it easier for you to see how pieces of the project fit together. If the language supports it, an IDE can provide powerful searching capabilities, allowing you to see where a function, method or class is used.
  • Often these have refactoring support. Refactoring allows you to easily rename variables, functions/methods and files. If the language or IDE support it, references to the renamed entity can be updated as well. This will help make the code more fluid.
  • Debugging and code inspecting capabilities can be very useful. You can walk through code that is running locally and see the state of variables and make function calls. This is especially helpful if you have a test that can drive the code and replicate a bug. You can also, if the language supports it, connect to remote servers. (Many languages have command line debuggers as well, but it’s usually easier for a new developer to use an IDE.)
  • The IDE can provide text manipulation functionality. For instance, if you want to add documentation comments to every method, or an easy way to generate boilerplate methods, IDEs can provide this. It’s often easy to customize to your needs as well.
  • Easier learning the language or framework. If you are not sure of the exact name or syntax of a library call, an IDE can suggest it (often based on you typing a few letters). The documentation is often integrated as well, so you can, for example, see the javadoc by mousing over a method call (in a Java friendly IDE).

Obviously, as you see above, an IDE is very powerful. It’s also very tied to a language and the language’s features. If you are using a dynamic language (PHP, ruby) your IDE will have different capabilities than if you are using a statically typed language (C#, Java). But in either case, mastering your IDE will make it easier to write and debug code on your development computer.

Sincerely,

Dan

Software is about people, not code

Dear new developer,

When I was starting out, I thought that software development was all about code. After all, that was the main thing I was working on. Well, maybe not the main thing, as I needed to know what code to write, how to interface with other code, what was the problem being solved, how to deliver it, the correctness of the code, and how it could be maintained.

But, the writing the code felt like the most important part of the job. It was certainly the most tangible and fundamental. After all, if the code doesn’t work, all those other things won’t matter, right?

This led me to focus on how to write code. I wrote up a style guide for the company. Researched new technologies. Read and commented in online forums. Learned how to decompile java bytecode to reverse engineer proprietary software. Argued about code formatting. Joined a design patterns discussion group. Attended meetups and blogged.

I undertook all of these activities to be better at writing code.

However, I eventually learned that people were far more important for the success of a software project than code. This crystallized for me after I saw a few very interesting (to me!) codebases abandoned for lack of a market or other business flaws.

This was a surprise to me, insofar as I’d assumed the code was the most important part of software development. But really:

  • Software and code is created for people and their purposes. It doesn’t exist on its own, isolated from human needs.
  • People will use the tools or applications built with code (or, worse, they won’t). This means that they have to be bought in to what is being built and consulted about functionality.
  • Most people don’t know or care about the code. (If they did, they’d likely be a developer.) They’re just trying to get something done. The most beautiful, well tested, flexible, configurable, documented, future proofed codebase that does the wrong thing is useless.

At the end of the day, code is a general purpose tool, just like accounting or research and development. Code must solve real world problems of real people.

Sincerely,

Dan

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

Learning to read code is more important than learning to write it

Dear new developer,

Coding is fun! You get to take a few words on a page, breathe life into it through your understanding, type rapidly into a text editor, and display it to our colleagues. It’s an amazing profession that is changing the world.

However.

The vast majority of code is read far more often than it is written. This is true for a few reasons:

  • Companies pay for code. Code is expensive. They want to amortize the costs of writing it across as many years as they can.
  • Business requirements change. That means that the code that supports those business actions needs to change. But before that software can change, the modifier needs to understand what is currently happening. Even if the requirements dictate a whole new feature is implemented, the developer still needs to understand how the new feature fits into the existing codebase.
  • Bugs occur, where the software is almost correct, but not quite. Again, anyone fixing the bug needs to understand what the existing code is doing.

And over the years, there will be many changes and bug fixes.

There is, to be true, the occasional piece of software that is just “set and forget” where changes are minimal over the years. I once was responsible for a piece of software that ran for five years with no changes. That’s rare enough that it sticks in my mind.

So this means, that of the time you actually spend coding, it’s likely that more of it will be spent trying to understand existing code in order to make changes to it than it will be writing new code. And of the applications you support, more of them will be already written than not. Of course, depending on what company you work for, things might be different. A startup with no existing systems will need more new code than a running business. (I wish I had numbers to support these statements, but all I have is my experience.)

What does that mean for you, new developer?

It means that spending time learning to read code is a good idea.

When I approach an existing project that is new to me and need to have an understanding of it in order to make changes, there are a few different aspects I consider.

  • Scanning. This is the high level overview. What problem does this code try to solve? What language and/or framework is it using? Is it using them in an idiomatic manner, or in a unique way? What are the big pieces of the application, and how do they fit together? This information is perfect for a document, but sometimes needs to be pulled from someone’s head or from the code (you should write down what you learn).
  • Diving down. This is where you focus on the problem at hand, and try to identify where the changes should be made. This will probably involve having multiple files open and moving between them, and trying to understand all the logic of this part of the system. You can also look for more granular patterns in the code, including different levels of abstraction, homegrown libraries or frameworks used, and coding idioms. Consistency matters, so you want to write in the style of the current codebase (which doesn’t prohibit you from noting where the current style is flawed and should be changed).
  • Use the scientific method. Write a hypothesis, make small changes and see what happens. If you can make changes in a staging system or on your local machine, that’s great.. A debugger is super helpful here, as are unit tests (or any kind of automated test). If you can’t make a local copy of the entire, you can typically still set up the language runtime locally and run various chunks of code to get a better understanding of what the system is doing.

Beware of the temptation to try to understand the entire system before making any changes. Whether you need to do so is based on how entwined the system is, how well the system is tested, and how critical the system is. Only discussions with the business and other members of your team can determine the best course forward, but an understanding of the entire system will likely only come with time.

Also, beware of the temptation to just throw away the old code and rewrite it. Especially if you don’t understand all that the code is doing. Old code is reified knowledge, and you ignore that at your peril. See obligatory link to the classic post “Things You Should Never Do, Part I”.

Reading code is more important than writing code because software systems spend the majority of their lifetimes after launch, and change happens.

Sincerely,

Dan