Learning Strategies for Engineers - Part 1

In my last weeks at Wayfair I gave a series of talks titled "Learning Strategies for Engineers" that were designed to kick off a peer to peer training program within the engineering group.  They were targeted at both new and experienced engineers, with the goal of giving people another another perspective on how to stay current in our field.  People seemed to enjoy these sessions, so I am reproducing the key points here.  Part 1 will cover technical skills and possible ways to grow them, while part 2 will focus on "soft skills" and interpersonal relationships.  I'm sure that many of these points will seem obvious, but hopefully some of it is useful.


I subscribe to around 100 blogs in Feedly, most of which are technical.  You can download the list with the non-technical blogs removed and import it directly into the RSS reader of your choice here.  I try to read everything that comes in, although I just scan some of the feeds (Slashdot in particular) for interesting items and then mark the rest as read.  My goal is to keep the unread count at zero, and though that is rarely the case I have found that I can stabilize it at under 100 unread items with a modest time investment (maybe an hour a day).  One important thing to note here is that I have made a rule with myself that when I add a feed I have to drop one - I don't want to fall into the trap where I spend all of my time reading technical literature and not enough time actually doing things.

In addition to RSS feeds I also try to get through a couple of technical books a month.  I just finished The Pragmatic Programmer and The Art of Scalability, and next on my list is PHP: Objects, Patterns, and Practice (full disclosure, Amazon links are affiliate links).  I think it's important to read books about technologies you use, even if you already know them fairly well.  I've personally found that books can give you a better foundation to stand on, and fill in knowledge gaps that you might not even know that you have.  I've also considered shifting my focus more towards reading books about things I use every day instead of reading blog posts about topics that may or may not be valuable.  The latter has more potential for big wins, but the former has a much higher signal to noise ratio.  It's a tough balance to strike, but I think spending 5-10 hours a week reading technical literature of some sort is essential.

Write Code:

If you are a software/systems engineer then you probably spend the majority of your time at work writing code or configuration.  This is great, but I believe that writing more code on the side (ideally in other languages) can pay huge dividends.  This could mean contributing to open source projects, starting a personal project, taking online classes, or something else.  Seeing how other languages solve problems will make you a better engineer, and exposing yourself to a different codebase will open you up to patterns that you might not otherwise see.  Personally I've done a little bit of work on the HTTP Archive project, started to take classes on Coursera, and I'm hoping to begin work on a side project with a friend in the next couple of weeks.  This is actually an area where I feel like I'm lacking a bit, and I'm hoping to spend more time doing this kind of thing going forward instead of simply reading blogs and books.

Throw Code Away:

Once you have written all of that code, don't be afraid to throw it away and start over.  Refactoring is something that everyone should get comfortable with - it's pretty much impossible to write something perfectly the first time.  Use the act of writing code as a learning experience about what works and what doesn't, and if at the end you see a better way to structure your program, then do it.

Configure Your Work Environment:

If you find yourself saying things like "I should upgrade that app so the nag goes away" or "I should really install that plugin, it would save me so much time" then you have some cleanup to do.  Having a distraction free work environment with good tools that you know well is essential to getting into a state of flow and avoiding decision fatigue (I'll write more about those topics in part 2).  Pick an editor and learn your way around it, pick a browser and learn to use the developer tools.  This stuff should be second nature, and your mechanics need to be strong.  Think of it like an RTS - to be a great developer you need to have a reasonably high APM.

Work in Chunks (Maker's vs. Manager's Schedule):

Read this post.  If you are a maker, get on the maker's schedule.  The tl;dr version is that context switching is bad, and if you want to do hard things and do them well, then you need to block off large chunks of time to work without interruption (3-4 hours).  There have been numerous studies that show the downsides of multi-tasking, and I feel like I read a new one every few weeks.  Even though parallelizing projects might make you feel like you are getting a lot done, it is far more productive to work on one task at a time instead of jumping around.

Be a T-Shaped Employee:

In the Valve Employee Handbook they talk about valuing "T-shaped" people (page 46).  To quote Valve directly: "That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T)."  I think this is applicable to a lot of different fields, but for engineers it really rings true.  Figure out what you want the leg of your T to be, and work to become an expert in that area.

Mind the Dip:

Seth Godin wrote a short book called The Dip about when to quit something.  The image below explains the basic premise:

When you are learning something new, you should either quit early after the initial large reward, or you should push through to the far end of the curve where you become a true expert.  Quitting in the middle is the least optimal point, since that is the point where you are getting the lowest reward for the time and energy that you put in.


There is obviously a ton more I could write here, but these are some of the overarching principles that I personally use to continue learning and staying relevant.  If you have read this far then drop me a line in the comments with some of your favorite ways to learn.

In our industry if you aren't learning something new every day then you are rapidly falling behind, and it takes a lot of work to maintain your effectiveness over time.  I'm currently experiencing this first hand - my first few weeks at Etsy have been filled with trying to grok new tools and technologies as fast as possible so I can start contributing in a meaningful way.  Every day I feel more and more happy with my decision to join the Etsy team; the people I work with are outstanding engineers and the potential to learn and grow seems limitless.  It's a humbling and scary experience, but that's exactly what I was looking for when I first started thinking about moving to a different company.  We are lucky enough to work in a field that is changing and improving on a daily basis, with way more job openings than people to fill them.  Taking advantage of this requires hard work and perseverance, but hey, if it was easy then everyone would do it :-).


  1. Great article - thank you! One technique I would add to your list is teach -- which you're doing here already. Teaching someone else is a good way to help reinforce mastery of complex material. It ensures you have a real working knowledge as opposed to rote or conceptual knowledge. You can also gain new insights by seeing how someone else synthesizes that material.

    And, it's cool to pay it forward.


    1. Thats a great point, and there are a lot of people who promote the "Feynman Technique" as a way to learn more quickly, which essentially involves pretending to teach a subject to someone else. You can read more about this approach here:


      Thanks Jennifer!

  2. regarding configuring your work environment, it's generally useful to write a script that pulls in everything you need. If you're on linux, using apt, if you're on OSX using ports. Also, if you keep your dotfiles in git, it should be easy to pull them in as well.


Post a Comment

Popular posts from this blog

14 Day Challenge - Information Diet

Trust, but verify

Business Books for Technical Leaders