How and Why Developers Must Always Evolve

     This post originally appeared on ONTRAPORT’s engineering blog. I’ve cross-posted it here for posterity.

Back in college, my friends and I would always talk about the latest tech news. We would debate the latest and greatest ideas like which Pentium 4 processor was better. It became a competition of who ‘knew’ the most ‘stuff.’ During one of these pre-class chats, one of the guys said, “I want to know more about tech than anyone.” Upon hearing this I thought to myself, why would you want to spend that much time consuming all that information? It seemed like a lot of wasted time. But that harmless statement shaped how and why I think developers must always be reading and learning:

  1. So that we can find targeted answers to involved problems.
  2. So that we can find general knowledge via weekly newsletters or from aggregators such as /r/programming to always be evolving.


This is the most common way to learn. Say I want to learn to play the guitar. I would research guitar tabs and watch youtube videos of people playing my favorite songs. Eventually I’d be able to play a few chords and maybe Steve Miller Band’s “Joker.” But outside of that you’re unable to do much more.

This can be dangerous; this is the path to stagnation. It can get pretty comfy knowing just “Joker” and living with those three chords. This is the same as looking through posts and copying/pasting in a rush just to get your task at hand finished. Or using “xyz” plugin to fix a problem without understanding how it works.

Although it can lead to stagnation, targeted learning can have the biggest influence on changing your perspective on a problem. Finding the “right” solution might hinge on your ability to google the right term. Once you find that right term — find el dorado — it can lead to your eureka moment, granting you the key to solve a greater problem!


Think of general learning as an investment, much like your 401k. If you plan to retire someday, you have to keep making daily/weekly/monthly contributions. It’s akin to running — you can’t run a mile once and then successfully run a marathon the next day. You have to train for it.

It’s easy to say “Why am I reading this?” or “When am I ever going to use this?” I feel like a lot of learning to develop is feeling out the boundaries of what’s possible. To make sure that I’m spending my time wisely and consistently pushing the boundaries, I keep this mental checklist while reading **general **knowledge articles:

  • Have I read something like this before?
  • This is interesting, but when will I use this information:
    • Today?
    • Three months?
    • A year?
  • What “category” does this fall under?
    • Opinion
    • Spec documentation
    • Code / plugin demo
    • History / post mortem
  • How does it line up with my job responsibilities?
  • Does it fit with the company culture?

In the world of Front End Engineering there are quite a few articles that start out with “X is better than Y.” Many of these posts are quite persuasive, which might spark your insecurity — this is what those authors want, but it might be a false trigger. The checklist helps keep the following things in check: what I currently know, how the project or product I’m working on works, and if I agree with the article in question.

Tips for Keeping General Learning in Context

  • Keep a whiteboard in the office where everyone can document their newest discoveries.
  • Create a POC (proof of concept) for every idea.
  • Present your newly discovered ideas in a collaborative show-and-tell once a week.
  • Read about other topics outside of your expertise or immediate interest. I find that applying and practicing development principles in a different environment helps me refine my skills.

Further Reading on the Subject:

JavaScript Weekly

HTML5 Weekly

CSS Weekly

The Modern Web Observer

Web Design Weekly

Status Code


css tricks

david walsh

reddit / programming


a list apart

Mozilla Developer network

CSS Wizardry

Interaction Design Foundation

It’s a combination of both **targeted **and **general **learning that makes for success. It’s important that you and your team carve out time to learn and discuss new things. It will lead to better conversations during product/project meetings, since not everyone will agree that X is a better way of doing Y. You and your team will build a more collaborative rapport allowing for healthier discussions, which lead to a better product/project outcome.

I don’t think anyone faulted Socrates for knowing too much. And if you’re unconvinced about the importance of reading to evolve, just remember that there’s a reason why people often consider the most read person in a room to be the most intelligent.