Avoid being an expert beginner

Dear new developer,

This post by Erik Dietrich covers the situation where a developer becomes an “expert beginner”. This is something to avoid as you build your career–don’t work in a place where you are isolated or unable to progress. He breaks progress in any area down into a number of components–Beginner, Advanced Beginner, Competent, etc.

As such, Advanced Beginners can break one of two ways: they can move to Competent and start to grasp the big picture and their place in it, or they can ‘graduate’ to Expert Beginner by assuming that they’ve graduated to Expert. This actually isn’t as immediately ridiculous as it sounds. Let’s go back to my erstwhile bowling career and consider what might have happened had I been the only or best bowler in the alley. I would have started out doing poorly and then quickly picked the low hanging fruit of skill acquisition to rapidly advance. Dunning-Kruger notwithstanding, I might have rationally concluded that I had a pretty good aptitude for bowling as my skill level grew quickly. And I might also have concluded somewhat rationally (if rather arrogantly) that me leveling off indicated that I had reached the pinnacle of bowling skill. After all, I don’t see anyone around me that’s better than me, and there must be some point of mastery, so I guess I’m there.

This post is worth reading in whole. It resonates with me because I’ve spent most of my career in small companies. I do that because it fits best with my desires and my life goals. But I’m acutely aware that as I become more experienced, I am typically one of the most experienced technical folks in the room. This is a problem, because I could believe that I had most or all of the answers based on my experience (what the Expert Beginner believes).

I strenuously combat that by engaging with my peers in person and online, and I think this is a great way to do so. It’s not as deep an engagement as working with them, of course, but affords me the ability to work at small companies.

Ways to engage with the larger software community include:

The work environment you are in is a great place to level up, but depending on your situation, you may end up with few people you can learn from. In that case, it is imperative that you improve yourself through engaging with the larger software community.

Sincerely,

Dan

Read the documentation

Dear new developer,

Reading the docs is so important. It is so easy, when you are confronted with a task, to just jump in and start doing. It feels right. It feels natural. It feels like progress.

The problem is that it may be motion, but it probably is not be progress. You may be spinning in circles rather than moving towards your goals.

So, the solution is to read the docs. Documents are key ways of transmitting knowledge and will let you reduce effort or reuse solutions. There are a couple of different kinds of documents that are worth reading:

Requirements/high level project docs: These are typically written specifically for the project, and will help give you a sense of direction. It will help you find how the work you are doing fits in. Depending on the size and maturity of your organization, you may find these documents in various levels of detail and completion.

If you don’t find any at all, take the time to write one, even if it is just a one page overview that answers “what are we trying to accomplish”. Send this to a senior member of your team (or of the business, if there aren’t senior technical team members) and ask “hey, did I document what we are trying to accomplish here?” If not, revise until everyone is on the same page.

Writing down these requirements can save tons of time, as they can bring new members of the team up to speed as well as bring the team into alignment. If you are working on a project with human interaction, clickable prototypes can also be useful in determining the functioning of what the team is building.

Try to keep these documents up to date, though that is always a struggle. Whenever I start a new project, these type of docs are the first thing I look for, and if I don’t exist, I start writing them. They can take many forms and can include things such as overarching goals and terms (especially if they are not common vernacular).

Even a paragraph in slack that is pinned to the channel is better than nothing, but I typically like to put them in a google doc (if the keeper of the doc is non technical) or a readme in git (if the keeper of the doc is technical). Having these kind of docs available will keep you from heading down errant pathways that aren’t moving toward the end goal. It reduces your effort.

Platform and library documents: These are the user manuals for the tools you are going to use. Oftentimes they’ll be provided by an outside source (an open source project or a company) and are general in nature. As a new developer, hopefully you’ll have some internal guidance on these tools (even if it is just a conversation on why language X was chosen). But no matter how you arrive at the platform/library/framework, it’s a good idea to learn as much as you can about the tools you are going to be using. I tend to bounce back and forth between experimentation and documentation, but find the learning style that works for you.

A thorough read of the docs will save you time. Recently I was using a snap in CMS for Ruby on Rails, a web framework. I wanted to customize the back end system and jumped immediately into prototyping code. Later I was reading through the docs and saw that there was official support for my customization. I burned a few hours of time figuring out the wrong way to do what I accomplished, then had to spend time doing it the right way.

One of the difficulties of reading these docs is sometimes you don’t know what you need to know, nor how to look for it. I can think of a few times where I was working in AWS. I scanned the documentation and proceeded to work. Later, running into an issue, I went back and re-read the documentation and lo and behold the solution to my issue was in the documentation, I just didn’t know enough to know that I needed that piece of knowledge. There’s no way to avoid such situations. But having scanned the documentation for the tools you are using to solve your problem will let you be aware of any prebuilt snap in solutions, and also may point out extension points that you’ll want to be aware of as you build out your solution. Reusing code and concepts will save you time or money.

However, you do want to be careful not to spend too much time reading docs and thinking about the problems. I’m often confronted with a problem that is newish, whether in a domain that I’m unfamiliar with or combining two or more existing pieces of software in a novel way. Sometimes there’s no way forward but to just start thinking and coding, and documentation is no guide.

But knowing the bounds of the problem and information about the tools you have to solve it will help you determine when you are at such a place, and when and where you’re on well trodden ground.

Sincerely,

Dan Moore

How to read code

Dear new developer,

Reading code is much more common than writing code. Some might even say, “don’t trust any documentation, read the code,” though I consider that to be a pretty radical position.

But how can you effectively read the code. This post from selftaughtcoders.com gives a good explanation:

Find one thing you know the code does, and trace those actions backward, starting at the end.

Rinse and repeat.

It’s a wonderfully self-perpetuating cycle: you read more code; you gain the ability to understand it quicker and more effectively; so you are able to consume even more code; and so on.

And it doesn’t stop there: you’ll also see huge positive gains in your own coding.

I know nothing about his courses, but his insight into reading code to build intuition about programming and development in general is spot on. I tend to do this through code reviews, reading blog posts and going to meetups rather than tracing code paths, but reading code can be a good way to level up. Github is your friend.

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

Opportunity Cost and the Internet

Dear new developer,

Seth Godin writes every single day on a variety of interesting topics. He’s been blogging for years and years. Definitely an interesting person to follow.

I saw this post on opportunity cost in my RSS reader (you should use one) and thought it was an interesting take on all the free content out there. Of course, the content is free in terms of money but not in terms of attention.

From the post:

And the internet has raised the opportunity cost of time spent.

Our access to the world of learning and online resources means that the alternatives are far more valuable than they used to be.

You’re about to spend 11 minutes perfecting an email to a customer. You could do a 90% ideal job in one minute, and the extra 10 minutes spent will increase the ‘quality’ of the email to 92%.

The alternative? Now, you could spend that ten minutes reading a chapter of an important new book. You could learn a few new functions in Javascript. You could dive deep into the underlying economics of your new project…

What are you doing with your free time? Are you conscious of how you are spending it? Are you aware of the opportunity cost of say, reinventing the wheel, learning a new technology, responding to a off base comment in an online forum?

Time is your most precious resource. Where you invest it when you are starting out will compound over the years.

I’m not saying “Don’t have fun.” I’m saying understand the consequences of your choices and accept them with your eyes wide open. Realize that the cost of learning a new skill has plummeted due to the Internet, which means the relative cost of anything else has increased.

Sincerely,

Dan

Join an online tech community

Dear new developer,

A big part of your job is keeping up to date with new technologies and happenings in the tech world. This can sometimes be a distraction, because there is all kinds of new stuff coming out all the time, whether from big companies releasing new tools or platforms, people publishing interesting code or articles on their experiences, or marketing from smaller companies. I avoid this distraction by relying on a community to do some filtering for me. Obviously that means that you need to find the right community, otherwise the filtering won’t be effective.

If you know the exact type of technology you want to focus on (say React Native or Haskell for web development), you can sign up for an email list(s) related to the projects. Or you can go to github and start to follow the issue lists. Or if you know people involved in the project, you can follow them on Twitter. Matt Raible, a prolific developer and blogger, once mentioned that he learns a new technology by unfollowing everyone he is following on Twitter, then following only people talking about the technology, so that his Twitter feed is rich with focused information.

However, if you aren’t sure exactly what to focus on, a more general community might be a better fit. These ebb and flow over the years but they also cross pollinate, so if you join one and a few years later it feels like it is not as active, be on the lookout for the up and coming community to jump to.

Slashdot was the first focused online web based community one I ever took part in. I enjoyed the discussions and linux focus. Recently I’ve moved on to Hacker News, which has a nice mix of technology, science business and politics that I enjoy. But there are other great options like Reddit (where you can find any subgenre you want, but you may want to stick with the big reddits like /r/programming), Stackoverflow (for programming q&a), and lobste.rs (which is less business and more technology focused).

Whatever community you join, whether it is a specific project or a general link sharing site like Hacker News, make sure you actually become a member of the community. Just like the value of a meetup is in who you meet time after time, visiting an online community just once is unlikely to be valuable. And be especially wary of self promotion (this Reddit page has some great guidelines about how to be an effective member of an online community, but seek out such guidance wherever you land).

Once you find and join a community, take part in it. Comment, submit links that you find interesting, and visit it. Be ready to be offended or hurt by some comments, especially if you say something dumb. I have definitely said dumb things or spoken on topics that I wasn’t fully informed about. I feel a flush of shame, leave the community alone for a few hours,and then come back and apologize or acknowledge my mistake. It’s unpleasant but part of the package.

The more pleasant part of the package is being exposed to new things. If it solves a problem you see, you may want to discuss bringing a new technology or piece of open source software into your work. Your work may have policies around new technology, but it never hurts to bring it up and discuss whether it may be applicable. You also may find interesting commentary and perspective on the technology you are already using at work, and sharing that can be a good way to help the team get better with it.

It’s also fun to occasionally submit something, whether an interesting open source project, an article on your blog, or something else you’ve seen. I’ve done that a few times and it’s nice when a submission blows up and becomes popular. It’s also a nice way to say “thank you” to someone who has written something interesting and help them out–I can think of multiple submissions that were interesting articles written by people I knew and when the submission got popular, the people were thankful I’d posted it.

In summation, find an online community, participate it in, and you will reap the rewards.

Sincerely,

Dan

Learn two languages

Dear new developer,

Learn two languages.

When you know just one language, you can go a long way, especially if the language is dominant. In web development, that language is javascript. In system programming it’s C. Both of these languages will be around forever, and you’ll always be able to get a job writing them.

You can also know one non dominant language and get pretty far, though if that is your choice, you will probably be happier at a big company with supporting infrastructure. Something like ruby for web development or go or rust for systems programming.

But, knowing just one language is like living in the same town all your life. You can be happy doing that, but just the exposure to life in a different city will shake you and show you that what seemed like a universal truth was actually just an assumption.

I cut my teeth on perl and wrote a lot of it for my first professional job. Then I had to write some java. The first java I wrote was not idiomatic. Rather than use small custom objects, I just leveraged hashmaps and lists for my data structures. I remember one of the other engineers going over some of my code and saying “that looks a lot like perl written in java!”.

Specifically, learning a new language will:

  • let you see the strengths and weaknesses of your first language
  • let you bring concepts from language number two back to your code in language number one
  • make it far easier to learn a third language, should you choose or need to do so
  • make you aware of different approaches to common problems
  • may make it easier to implement certain kinds of problems. In my experience this is often due to open source libraries that may be available for one language that aren’t for another
  • make you less passionate. This may seem like a strange benefit, but learning another way to do things often helps you realize that a programming language is just a tool, and that different tools are of course better for different things.
  • let you build a mental map to apply to the new language based on the old language. “I know that there’s a way to iterate over a list in perl, so there must be a way to do so in java.” This will also help you learn common software terms (like “iterate”) which will help you in your searching.

These truths apply not just to languages, but other pieces of the software development process. Learn two of everything. Databases, frameworks, development methodologies. The increase in perspective and the ability will be worth the extra effort.

Sincerely,

Dan