By Jason Lowenthal October 16, 2015

How To Learn From A Novice

Rookie. Sport. n00b. These are some of the “nicer” terms we use to describe the less advanced amongst us. Idiot, Moron, and a few other insults really should have no place in our vocabulary whatsoever.

All of us started as novices. Those of us who have had the blessing of one or more mentors along the way know how easily we can feel like a big idiot.

There are plenty of reasons why insulting someone honestly doing their best to learn doesn't really help anyone, as demoralizing people really just shows off an unmanageable ego.

Instead of looking at novices as cumbersome and annoying, every time we teach, we have an opportunity to learn too.

There are some novices out there that want a handout or easy-street. They’re not always easy to spot, but in general, even these people you shouldn’t be rude to. However, I’d also suggest avoiding them if possible to favor the people that really do want to give their best.

Here’s some great ways you can be a teacher in your office (or elsewhere), while in the meantime learning something about yourself or your craft.

Brown Bag Lunches

lunch bag with note on it

Anyone can present any topic that has merit in our profession in an informal setting when we all eat lunch together.

That’s one of the really great things about brown-bags. The elimination of formality makes it easier to boost the confidence of novices as presenters.

And the topics can be anything that anyone you work with finds relevant to the cause. Here’s some ideas that we’ve talked about (or presented to one another informally):

  • OOP Fundamentals
  • Basic Design Patterns (and when they’re not actually the right choice)
  • How to evaluate your testing strategy
  • How to write a unit test (using a mocking framework)
  • ETL Tools
  • System Monitoring
  • Logging patterns
  • Database tuning ideas

This list is by no means even remotely exhaustive, and by no means maintained by any one person at my office. The main idea behind brown-bag is community. Everyone gets a voice, and everyone gets to learn something.

And, like everything else I try to encourage, it’s an iterative process. We evaluate the format and content as we go along, making adjustments as needed so that the next brown bag works even better than the previous one.

Online Communities

StackOverflow and related sites

If you’ve had a problem figuring out Hello World, you’ve probably turned to StackOverflow.com at some point. What started as a forum for programmers to ask questions and get answers to those questions has exploded into a multi-site, multi-topic conglomerate that covers the gamut.

While StackOverflow remains the core competency for the company, it really is a mecca for programmers and other technical know-how.

However, one of the major drawbacks of StackOverflow’s popularity is what I call, for lack of a better terminology, new guy shaming.

There are all kinds of community support and advice for figuring out which StackExchange site your question belongs on, and also for making your question as specific as possible.

However, there’s plenty of know-it-alls that will say things like, “This question can’t be answered. You’re a dumb” and downvote in a moment’s notice. I’ve seen several questions reach -4 or -5 before the moderators step in and close the question outright.

Don’t get me wrong, StackOverflow has an amazing amount of knowledge and is an incredible learning tool, but there are plenty of novices on that platform, and when I find them I do my best to help them mature into using it correctly.

Not everyone is so kind – just poke around at newer questions and you’ll see what I mean.

Other social media

Though it’s probably not quite as direct as on the StackExchange family of sites, other social media outlets also provide avenues for us to connect with one another. I’m a member of a couple of Facebook groups and a couple of Google+ groups related to programming.

Would you believe people are rude to each other on social media? I know, right?

In general, if I encounter a new programmer on the internet, my first course of action is to recommend good learning materials on the given subject matter. If the novice still seems confused, I'll do my best to engage them more directly to help them past a learning hurdle.

Usually I'll uncover a nuance I hadn't considered before, so in teaching I most definitely learn something.

Encouraging best practices (not demanding them)

Thumbs upWhen I interact with junior programmers, I almost always make recommendations for ways I see to improve code. Right now our big drive is reusability, so I focus our attention on modularity patterns. But I do it by teaching, not by demanding.

Often the optimization I recommend leads to refactoring. And often it leads to a brown bag lunch topic where we can discuss the pros and cons of each approach as a team.

After all, I'm of the firm belief that even the less experienced team members are super smart people. I give them the knowledge they need to make an informed decision, and then collectively we build wisdom into the best software we can.

Peer code reviews

One of the tools that I advocate very heavily  during development processes is peer code review. Recently, for me, that involves pull requests in BitBucket. I've also used Crucible, a very similar tool, also by Atlassian.

Next to pair programming (see below) I feel as though peer review is one of the most essential tools of the trade. It allows asynchronous communication between me and other members of my team.

I can request advice on a complex problem I'm working on, or provide pointers to best practices when I see something that might work better a different way. And it's all documented in line right in the code, so we can all be part of the conversation.

Pair programming

Do this. As often and as thoroughly as you possibly can. Find a room with a big screen and throw code on it. While there’s several definitions of pair programming, here’s a brief synopsis that I like:

  • One person acts as pilot (writes code). The other acts as navigator (plans code being written)
  • As the pilot works on getting code written down, the navigator examines each method, loop, function, and class (if you’re OOP) and ensures that the logic in the code adequately solves the problem.
  • This goes on most or all of a given day. During that whole day, the role of pilot and navigator may switch many times throughout

There's tons of resources about the best way to do pair programming. This Article from ThoughtWorks is a great starting point.

However, in my experience, the first and most important step is to just start doing it. Sit down with a person, look at his/her code, have him/her look at your code, and talk about it.

As with so many things in programming, feedback loops are the most important thing to shorten. And instantaneous feedback from a pair programmer is about the shortest loop there is.

Peer non-code reviews

While programming is the thing that we’re all paid to do, I don’t see any programmer writing code 100% of the time.

As a good starting point, anchor your burndown rate at 6 hours of “productive work” for an 8 hour day. And that 6 hours doesn’t always mean “I spent 6 hours writing code today”. That just means for 6/8 of your day you weren’t in meetings, answering phone calls, or doing other “non-product” things.

As an example, more than once I’ve sat over the shoulder of a junior programmer and helped them be concise and pointed in an email. I think it’s important to hone communications skills, not just technical skills. Reviewing email is easy, and it’s also something that can help form a personal bond between two individuals.

Another example is this blog post. While this one isn’t as limited in scope to a bug report or as directed as an email, this thing is going through three separate editing rounds.

And I love it.

The editors call me on my B.S.,help me to eliminate extraneous stuff, and point out areas that I needed to improve or lengthen. I consider myself a novice writer. No way am I going to pass up advice from experts.

Having someone around to help you review your writing is just one more way to make sure that the signal you’re trying to send isn’t broken down by the noise around it. I already pointed this link out once before, but it really is an important read.

Novices aren’t the only ones who gain to benefit from having other people peer over their shoulder. As the expert, you get to really gain something somewhat difficult to put a value on.

Pride.

Honestly, I don’t know of any better feeling than having someone else tell me “thanks for the help.” Not that programmers need help with our egos, but man it’s an ego rush.

Don’t carry a gavel

Notice, in all of the review examples I provided above, not once did I act as judge/jury/executioner (and nobody else in my organization did either). Best practices work better curated, not demanded.

When the whole team has a stake in the culture of the team, everyone is more protective of the team dynamic and gets more productivity out of interrelationships. Once again, I’m going to point at Team Geek: A Software Developer's Guide to Working Well with Others for doing a better job explaining this than I ever could.

Don’t Be The Big Bad Wolf

Wolves, man with mask wolf and lamp with colored smokeHopefully you know the story of the Big Bad Wolf and The Three Little Pigs. You know, wolf, pigs, three houses. Two houses huffed and puffed down. Third house made of bricks. Wolf gets his butt burned because he decides to try sneaking down the chimney.

The main point I want to make is that I’ve known a Big Bad Wolf (actually, more than one) in my professional career. These people bully other programmers by belittling, making fun, and otherwise putting down their work.

Instead of offering constructive suggestions about how to improve, they tend to be more like Dr. Cox in Scrubs. “Wrong, wrong, wrong, wrong.”

Granted, Scrubs is comedy and not real life. But, as a reflection of real life, it also offers us a reflection of how bullies behave in our world.

Eventually the ego will put your butt in the fire

Here’s the fun thing about being bullied. If you stand up for yourself and don’t let the wolf win, you’ll be in a position where you instead built a house out of bricks. Then when the wolf tries to come in, instead he’ll get burned in your fireplace.

OK, so the metaphor is kind of dead and lame at this point, but the main idea is that bullies eventually get their comeuppance. They’ll smart off to the wrong senior engineer. Or they’ll smart off to the wrong junior engineer. Trust me, I’ve seen it happen. When this smarting off happens, either they’ll get fired or severely reprimanded by senior management.

Also, in general these people get ostracized by their peers. They can’t find other people to help them make their code better, so in the end they have to work twice as hard to keep up with everyone else who has a solid peer group. Big Bad Wolves tend to be very lonely, and also tend not to stick around for long.

Dialogue

ProgrammersThe biggest take away, more than anything else, is dialogue. Starting a dialogue, no matter what tool, is the best way to make a novice into an expert.  It’s also the best way to make an expert better understand the material they’re covering.

Experts learn how to connect with new people, and in the process move the entire team to a higher standard. Novices learn how to comply with a higher standard. And, as cliche as it may sound, the rising standard of quality breeds an atmosphere of respect and bonding over shared personal investment in each other's work.

I’ve worked in a place before where the dialogue between teams and peers was very subdued. It didn’t last very long, and I really don’t feel like I learned much while I was there. The professional relationships I’ve built over time really depended heavily on dialogue between peers.

The biggest thing about dialogue is how it opens up doors for learning. Honestly, even now, I’m not sure if I'm even allowed to call myself an expert! I’m still learning all the time because programming is a community of perpetual learning. I might even decide to throw everything away and start over tomorrow! (No, not really, but it’s definitely nice to know I’m in a profession where I can do so easily).

So we need to do our best to support and encourage one another. If there's one thing we all need expertise in, it's learning. So don't be rude to novices. Because someday you'll be one again. I promise!

About the author

    Jason Lowenthal

    Jason Lowenthal is an Architectural Software Engineer based in Springfield, MO. A graduate from Drury University, his past work includes stints with Bass Pro Shops, O’Reilly Automotive Inc. and Paperwise. When not contributing his time and talents to his employer, Asynchrony, Jason spends his free time raising his 3 girls, and learning about new technology. You can link up with him on Twitter, too: @lowenthal_jason