Note: This is dated July 23, but it really happened and most of it was drafted on July 8. I guess we see where finishing up blog posts sits on my personal backlog.

We’ve got some interns. I paired with one of them this morning, and we performed a mild refactoring in the area of dependency injection. What we did isn’t the point of this post. The point of this post is that he asked me later in the hallway (quoted as close as I can recall):

How did you learn all this stuff and make it so your code doesn’t look like college student code?

tl;dr - Experience.

jklol - The Evolution of A Software Engineer

I’ve said for quite some time that the purpose of formal education in our industry isn’t actually to teach you what you need to know in “the real world.” Its true value is in teaching you how to learn the things you’ll need to know. It’s important to realize that going to college and paying for a piece of paper isn’t the only way to gain this skill, just one way.

Learning On the Job, Apprenticeships, Mentoring⌗

The truth is that once you leave the school setting, there’s a world of crap you weren’t taught. Like how to use source control properly. Like team specific conventions. Like navigating an existing codebase larger than you’ve ever seen and fixing a bug without breaking anything else. Like doing that when there are no docs, no tests, and none of the original authors hanging around to answer questions.

So one part of my answer to the intern was a collection of things that fall under the “experience” heading.

  1. Find a mentor and/or engage in pair programming
  2. Pay attention to what works well for you and what doesn’t
  3. Request feedback through channels like code review
  4. Read the code that your team is writing
  5. Use the magic of open source to do all of the above with the entire world, not just the people at your workplace!

I could do a whole post on pairing itself, or perhaps a whole series on pairing itself. All of these have value, though. The lowest common denominator is share and spread awareness of what people are doing, and pay attention.

Constant Learning⌗

Our toolchains are very volatile. We need to be constant learners if we hope to work on interesting projects, or even to be employable until retirement age. I’ve seen colleagues who started their careers in VB6 have a hard time finding new jobs when inevitable layoffs or collapses occur because they never took the time to learn anything else.

The other part of my answer to the intern was a collection of things that fall under the “continuing education” heading.

  1. Find some books.
    1. You want some like Clean Code and Think Like A Programmer - general, conceptual, technology agnostic.
    2. You want some others that dive deep into the technology stack you’re using, like C# in Depth or JavaScript the Good Parts.
  2. Subscribe to some blogs or podcasts that cover the things you’re directly working with.
  3. Subscribe to more that cover areas you’re interested in, but not yet working with. It helps to get your head around those concepts and the vocabulary.
  4. Subscribe to still more that cover areas you’re not touching at all. See how the other half thinks, and reflect on whether what they’re doing could apply to where you are.
  5. Subscribe to some aggregators that collect a daily dose of ideas, new tech, tutorials, etc. Stay aware of what’s out there.
  6. Attend conferences, either physically or virtually, to get a sense of what’s going on beyond your own experience.
  7. For all of the above, do not accept everything anyone says without question or reflection. Think.

The question usually becomes, “Isn’t that a lot of reading and listening to do? When you do actually WORK?” The answer is that you don’t have to read it all. You’re looking for headlines to keep you aware of what’s happening, skimming to evaluate what’s important, and you choosing which ones are worth a full read. You control your own destiny. I have 79 sources in the “Development” category of my RSS reader, and I spend 15 minutes, maybe 30 max, each morning.

To steal (and perhaps repurpose) a talk title,

It’s not what you read, it’s what you ignore. - Scott Hanselman

And that’s all I have to say about that.