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…

• http://nodejs.org/
• http://www.mongodb.org/
• http://meteor.com/
• http://mojolicio.us/
• https://github.com/substack/dnode
• http://git-scm.com/
• http://djangoproject.com/
• http://flask.pocoo.org/
• http://nevir.github.com/groc/
• http://phantomjs.org/
• http://pivotal.github.com/jasmine/

Good luck

Aaron

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

I want to start off by saying that Perl has to be one of the most fantastic
languages I’ve every had to work in. I’m not really learning it because I have
a keen interest in Perl, I’m learning to be helpful regarding the legacy codebase
at my work.

A little grind goes a long way…

I wrote a bit of a script, after spending a few weeks perusing through a hefty
codebase, and even with a little bit of Programming Perl under my belt, I
still don’t have the skill to just roll out a lot of code off the top of my head. To
make sure I was putting some test coverage in place (of which there isn’t in
this particular project), I looked up Test::Simple and Test::More and started
the file that would house my tests.

I found after I have covered the existing code that I was looking at my new
function stubs, and wondering how to best describe what they were going to do. Without
even really thinking about it, I started writing tests to say, “It should
do this, or that” and in a couple minutes I had created a spec for the
function I was writing.

Almost like fun

The neat thing is, having the spec in place allowed me to play with the code a
little bit to see if it was doing what I wanted when I tried different things.
If you recall, Perl has that “There Is Moar Than One Way To Do It”(TM) thing,
which can be a good and a bad thing, but more about that later.

The real fun is when I made the realization that I was actually doing Test Driven Development
to learn Perl. TDD is something I’ve always thought would benefit my coding
style, but I never really realized how until today.

Until next time,
Af

Zombie.js

I’ve been waiting for quite a while to try out zombie.js. It seems like the
“End All.” of hard-to-test-super-complex-setup systems, for instance, a system
where you have a SSO with several redirects, then multi-panel single page app
with a lot of ajax requests and dynamic resources. Unit tests are one thing, but
I really wanted to test that the whole setup was going to perform as expected.

#epicfail

After a day and a half (and part of an evening), I think that zombie.js is
probably trying to be a little too magical. On my Vagrant box (Ubuntu Precise
server) I’m running Node v0.8.6. At first I tried the setup with Mocha as
prescribed in the docs, but to no avail. The biggest problem: our SSO
system does a couple redirects when you hit the application page, and just like
another user expressed in this discussion, my .then() callback fires way
too prematurely, and never hits the actual redirect. Specifying the wait time
didn’t help any either.

Frustration at it’s finest

I’m not one to give up, I rarely let a hard problem get by me, but this isn’t
just a ‘tricky’ API I think. I think it’s an immature project. Harsh, I know,
but have a look at this example:

1
2
3
4
5
6
7

var zombie = require('zombie')
  , browser = new zombie.Browser
  ;

browser.load('<html />', function () {
  console.log('foo')
});

According to the documentation, browser.load…

Loads this HTML, processes events and calls the callback.

But it actually gives:

1
2
3
4
5
6
7
8
9
10
11

TypeError: Object #<Browser> has no method 'load'
    at repl:1:10
    at REPLServer.self.eval (repl.js:111:21)
    at Interface.<anonymous> (repl.js:250:12)
    at Interface.EventEmitter.emit (events.js:88:17)
    at Interface._onLine (readline.js:199:10)
    at Interface._line (readline.js:517:8)
    at Interface._ttyWrite (readline.js:735:14)
    at ReadStream.onkeypress (readline.js:98:10)
    at ReadStream.EventEmitter.emit (events.js:115:20)
    at emitKey (readline.js:1057:12)

Am I just doing something plain wrong?

So the tally is…

Zombies 1, Aaron 0

As a side note, selenium is looking to do exactly what I want.