How To Go From Beginner To Intermediate Web Developer

Posted November 4, 2016 by Jeremy Raines

A developer bootcamp grad who is a little more than six months into their first developer job recently asked me how they can go from a beginner to an intermediate level.

It’s a great question, one that I’m sure all junior developers ask themselves in their first year on the job, especially when feeling overwhelmed by all the advice and ambient pressure to both strengthen their fundamentals and learn new skills and technologies.

The first thing that jumped to mind was John Allspaw’s excellent blog post On Being a Senior Engineer. However, while it is not too early to read that post and come back to it as you grow in your career, it’s not quite the advice that was being sought by the developer.

This post is my attempt to provide that advice.

Get Comfortable With Being Uncomfortable

When I was a competitive swimmer in college, I was basically sore about 95% of the time. Just like your body, your mind must be challenged to adapt to the specific stresses you’re going to put on it. As a developer, for at least the first half decade of your career and probably longer, you will live at the boundary of your ability to grasp all the concepts needed for your work and your ability to put those into action in the form of code.

This is what programming is really like. pic.twitter.com/jNgPZjpqmy

— ☢️Brendan McAdams☢️ (@rit) December 30, 2014

Code Every Day

You won’t fall behind if you don’t code on weekends, but you’ll benefit if you do, even if it’s for 10-20 minutes. This could be any number of things, or ideally a balance of many, such as:

cool to be a nerd: just wrote a script to rename pics to their sha1 sum so that they’d be shown randomly during my wedding :)

— Shilo Ayalon (@shiloa) June 16, 2010

“If you hear a voice within you say ‘you cannot paint,’ then by all means paint and that voice will be silenced.” ~Vincent Van Gogh

— Brian Clark (@brianclark) July 10, 2008

If you have a particularly limited amound of free time and need that time to refresh, don’t worry about it. Recovery time is important for growth and adaptation, so if the choice really is between coding time or family time (and otherwise keeping yourself sane and healthy), then definitely choose the latter.

“Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.” – Kent Beck

— Bozhidar Batsov (@bbatsov) March 7, 2015

Read and Watch Lots of Learning Material

Don’t put too much emphasis on crafting the perfect curriculum for yourself. Just be curious and follow threads that interest you. Do not let this advice conflict with the previous bit about writing code: don’t watch 20 YouTube tutorials on Machine Learning or React or whatever without putting down some code. That will help you retain what you’ve learned; but retention – at least conscious, confident retention – is not the primary goal here. The primary goal is building a base of dots – you’ll connect them later at unexpected times.

Another valuable skill you’ll eventually develop from this (over time, in concert with your working experience) is the ability to listen to someone who sounds authoritative talk about an idea or practice and say to yourself, “You know what? This is bullshit.”

Write Things Down

Take notes or keep a blog, this will help with both retention and dot-connecting later. Use pinboard or similar to organize bookmarks.

“The true purpose of note-taking is transporting states of mind (not just information) through time.”

— Alexis Gallagher (@alexisgallagher) January 31, 2016

“My pencil and I are more clever than I.” - Albert Einstein

— Aycan Gulez (@aycangulez) September 13, 2016

Did they have highlighters in Einstein’s time? Because another thing I’d recommend is buying physical copies of your programming books and liberally highlighting/dog-earing the parts you find useful.

Use StackOverflow Correctly

Upvote every question and answer that you find useful. This is both good developer citizenship and will help you find it again two years later when you hit the same problem and have forgotten the solution.

Never copy and paste code unless/until you understand every line of what it does.

You haven’t fixed it if you can’t explain it.

— Sam Stephenson (@sstephenson) June 8, 2013

When you do crib some code, or even write your own based on an answer, include a link to the relevant question/answer in your git commit message.

When you ask a question, put some thought and effort into it and follow their guidelines on how to ask a good question.

More often than you think, simply taking this effort to formulate and communicate your problem will lead you to a solution before you even post the question.

Get Better At git

There is much to say here, so I’ll try to keep it to a bare minimum.

Make a conscious effort, all the time, to keep your commits small and conceptually unitary. Big chunks of work that are related in a high-level sense are why we have branches. If your branch about adding, say, a login page has 10 commits on it, and you think that’s too granular or you have commits like “Fixes file name to match Rails convention”, you can always squash those down with a rebase before the merge. You’ll get the added benefits of more granular ability to revert parts of a larger changeset and a more precise git bisect when tracking down the commit that introduced some bug.

Also,

Get Better at Your Text Editor

I won’t weigh in on which editor to choose, but whichever it is, become a power user. Just do it: beyond the initial pain, it’s pretty fun in and of itself aside, from making you more productive. The combination of those two properties is why you see so many (overly) passionate arguments about text editors.

Embrace Testing

Again, understand that you will not feel comfortable at first. But start today. I’m going to quote at length from Russ Olsen’s excellent Eloquent Ruby:

Although the ideal set of unit tests will cover all of the significant features of your code, sometimes you can’t get anywhere near it: The bug fix needs to go out, or the release is late, or your coworkers are just not that into the whole testing thing. What to do? Well, write whatever tests you can. As an absolute minimum, just write a unit test that exercises the code a little, with no asserts at all. For example, look at this seemingly worthless spec:

require 'document'
describe Document do
  it 'should not catch fire when you create an instance' do
    Document.new('title', 'author', 'stuff').should_not == nil
  end
end

While far, far from ideal, this spec actually does more than you might think. If it runs successfully, you will know:

In addition to making you more confident about your code and more secure against introducing regressions, embracing testing can help you build the habit of good git practices, particularly the small commits as mentioned above. In a Test Driven Development style, that would mean:

You don’t have to write tests first. Personally, I think you should try, but don’t let that or any bold claims about the superiority of tests-first (which can be valid!) stop you from writing any tests if you happen to write the implementation first.

Want to know how to stop writing tests that are a mess of mocks? Stop writing classes that are a mess of dependencies!

— Ryan Bergman (@ryber) October 12, 2011

If you *ever* see an exception in the browser while developing a Rails app, stop and write a failing test for it.

— Ryan Bates (@rbates) April 16, 2011

Learn To Use The Browser’s Developer Tools

The developer tools that ship with modern browsers are incredibly powerful. In addition to the typical inspection and tweaking of HTML and CSS, you can do things like:

Learn To Use A Debugger

Because puts and console.log only take you so far. In the Ruby world, I highly recommend Pry and encourage you to check out this video of how much you can do with it.

Learn Some SQL and Understand Database Normalization

Learning SQL gives you the power to explore your data and get a better “feel” for it in addition to answering questions about it or providing novel insights about patterns or structure therein. Personally, I find it fun because the problem space contains many small but useful problems through the solving of which you can learn new techniques very quickly. The important parts of the grammar can be learned in a couple afternoons.

I also think you should understand how to model your domain in a relational database. Understanding the First, Second, and Third Normal Forms will help you with this. In many cases, you will deviate from these in the service of speed optimzation, but with this base knowledge you will understand the tradeoffs you’re making.

If you’re a Rails developer, make an effort to sharpen your understanding of the database table and foreign key conventions for the various Active Record relationship types and why they are that way with respect to the methods that each relationship type adds to the involved models.

Understand Promises

I promise this article is almost over.

But the promises I’m talking about are data structures that represent the eventual result of an asynchronous operation. They are heavily used in modern JavaScript, especially as a representation of an HTTP request.

Learn Flexbox

Flexbox is a new-ish part of CSS that allows you to lay out elements of a web page using a pretty different model from what came before. In my opinion it’s more intuitive and more flexible (natch), and incidentally is the model behind laying out screens in React Native, if that’s something you want to get into.

Here’s a nice visual guide (warning - very heavy page).

This recommendation feels a little too specific, but my rationale is that if you do any front-end work you’re going to be sinking a lot of time into learning CSS, and I think Flexbox pays some nice dividends.

Learning flexbox is fun!

🏰💣 https://t.co/ANAdTFlIfT 🆕

🐸🍀 https://t.co/KHIxQstp0q

🕑5⃣ https://t.co/xk1BWg74Lr

— Una Kravets (@Una) March 8, 2016

Be aware, though, while browser support for flexbox is over 95%, your company may require you to support browser versions that do not support flexbox.

Resist The Urge To Be Clever

As you learn exciting new tools, abstractions, and techniques, you’ll be tempted to use them liberally and as soon as possible. I don’t want to totally discourage that, but trust me on this: if it took 100% of your brainpower to write it, it will take more than that to debug it later. Ask yourself, “Am I doing this to make the code simpler? If not, how is it better?” If this answer is “because it uses technique X, and technique X is all the rage right now”, then it’s the wrong answer.

“Any technique, however worthy and desirable, becomes a disease when the mind is obsessed with it.” - Bruce Lee

— Eric Farkas (@ericfarkas) January 30, 2015

My favorite trait in a software engineer is an unwillingness to suffer complexity.

— Brandon Bloom (@BrandonBloom) June 22, 2016

Get Inspired

Here’s just a few videos, talks, books and posts that have inspired me over the years:

Master your craft - From “Jiro Dreams of Sushi” pic.twitter.com/66Tpb5fNtk

— Athletic Performance (@BU_Iron_Bear) March 23, 2014