On Learning and Development

I want to write about the topic of learning, and how it pertains to my every day life in the workplace. I
spent 18 months at my previous position, first by myself, and very quickly surrounded by a small team. We were working
for a company that took great pride in being different, focused, and innovative. A company that made every effort to
solve the needs of the client when noone else could or wanted to.

Learning as a necessity

I don’t think it’s disputed by anyone that learning is necessary to become adept at whatever your position is. It
certainly was in mine. But it cannot stop there.

Learning is as necessary to development as water is to life.

It’s not enough to solve different problems in software development using the same patterns. It’s not enough to
tickle the boundaries of your “programming comfort zone”. One of the demands of the position I was in at that time was
to meet constant deadlines, and often overlapping ones. I’m quite proud to say I met all of them, and that the only
thing that made that possible was continuous learning.

Continuous Learning

This is the kind of learning that means when you find a new technology that looks like it solves a problem that you
have, you try it. You dive right in and find out if it’s going to do what it says it does. And then you do it again.
You jump ship on frameworks. You jump ship on technology stacks, because each one has something different to offer.

Just as a problem can be solved in any language, so can a project be solved in any stack. It doesn’t matter what the
stack is. What matters is that you learn it, because that makes you better.

Today it doesn’t matter that you know a language, or a framework. If you’re not good at learning, then you’re
already losing the game.

Developer rot

There is such a thing in the software field as software rot, meaning if
the environment is changing, and your software is not being updated to suit the environment, it starts to become a
liability, and eventually rots and dies.

Similarly, a developer that has not taken the opportunity to be up-to-date with the current environment and culture
(and I mean “software culture”) of the internet is suffering what I am coining today as “Developer Rot”.

A developer who is suffering developer rot is one who is trying to solve new problems using the same old tools. The
tools work, but the environment is not the same. 12-month objectives are no longer feasible, 6 months is no longer an
acceptible amount of time to put into a software project. Because we are learning creatures, and we do improve over
time, we want to think we can write it faster and better this time around, and we really can! But the timeline for
development within a given framework or toolchain is going to be fairly fixed. Boilerplate exists, component
integration needs design, there are shiny new requirements for the project, and now your timeline is shorter. This is
the reality of the entire evolution of my software career.

The real problem

“What problem does <insert new thing here> solve that I can do in <insert my language/framework here>?”

The problem of time.

If you spend (to pick a number) 20 hours to build a project using your current tools, and the new tool
promises to cut your time in half, you have 10 hours now to learn that new tool. The gain beyond that becomes several-
fold:

  • you’re learning new things
  • you’re becoming a better developer
  • you’re saving time
  • you’re giving more value to your clients
  • you’re supporting new technologies
  • you’re becoming a future advocate for these tools
  • you’re showing others how to do the same

You are also going to save that much time again on your next project, and you’re going to have fun. Excitement is a
huge motivator, in fact, I would argue it’s the only real motivator.

The time is now

If you are saying, “those tools look nice, but I don’t have the time to learn them…” then you are already suffering
from this condition. You will need to adopt and learn the tools as you encounter them, when they promise to solve your
problems faster and better. And you need to continue to adopt. If you can solve a problem well in one language, you
can solve it well in any language. If you can properly implement a project in one stack, you can implement it in any
stack.

“But I’ll have 50 projects in 50 different software stacks…” Look at the internet: is it all written in Java? Can you
even tell most of the time? Use good conventions to guide you and then dive in.

Netucation

“Real school” is starting to not mean much anymore. The new school is the internet. And the internet is changing. Every.
Single. Day. Knowing a couple languages isn’t going to get you very far any more. Your best friend in the new web is
the ability to learn. Don’t fight change, embrace it…

Here are a few suggested exit points…

Good luck

Aaron

Edit: I just ran across this blog post by Jeff Atwood
that validated my entire train of thought, link.