Better Engineering Through Teaching with Bevan Arps

This is a article from my "Dev Chats" series where I speak to an awesome developer or techie every week or so. You can read more here. Let me know in the comments if you find these useful to you!

 

Bevan celebrating a birthday.

 

Introduce yourself! Who are you? Where do you work?

I’m Bevan Arps and you’ve probably met me if you’ve been to the Wellington .NET User Group anytime in the last few years. You might also have seen me at a local code camp or developer conference. Currently I work for Microsoft as a developer, creating parts of Azure Batch. Before that I worked for the Reserve Bank of New Zealand, developing software to help their economists make decisions.

 

Who or what got you into programming?

Way back in the deep dark mists of time, I was a pre-teen dead keen on computer games. When I was ten, my parents purchased a home computer - the classic Sinclair ZX81. To my deep disappointment, they didn’t buy me any games. Instead, they purchased the Sinclair ZX81 Programming Lab, and encouraged me to learn to program. Like any fool who doesn’t understand how hard something really is, I decided to make my own games. By the time I knew enough to do that, I was hooked on the programming.

In a very real way, my parents have a great deal to answer for!

 

I notice you taught some night courses and enjoy teaching, how have those skills translated into your development career? Has anything particularly helped?

Teaching starts with the very small things that anyone can do - such as giving someone a

clear answer to a technical question that’s pitched at their level of understanding and need. For example, my parent’s don’t need to know the all the gory details of the Meltdown, Spectre or Heartbleed vulnerabilities - but since these things appear in the mainstream news media, they do have questions and concerns. As the family IT guy, I need to have useful answers that don’t leave their heads spinning.

Much of what I’ve done is essentially this exact scenario, but in larger contexts - passing on things that I’ve learned so that other people can get their jobs done or achieve their goals. This covers presentations I’ve done to my teams, to user groups as well as speaking at code camps and conferences.

I wouldn’t suggest that every developer needs to become a capital-T Teacher, but we all can learn to teach, and I believe it’s a critical skill for career success. Very often, we’re the subject matter experts in the room who understand the technology and how to use it to solve a business problem - but if we can’t explain things to the business stakeholders in terms they understand, we’re wasting our time.

Oddly enough, it wasn’t until someone pointed out to me that much of my career had involved teaching that I started thinking of myself as a teacher - I’d always thought of myself as a technologist.

 

I really enjoy your blogs and talks, how have these had an impact on your career?

Both the blogging and the presentations stem out of my impetus to teach, as I discussed above. I think they’ve helped my career in a few different ways as well.

Nothing solidifies your understanding of a topic like trying to explain it to someone else. All of the fuzzy details that you’d glossed over in your own head suddenly become very apparent and you have to dig into the fine print to find out what’s going on so you can explain it to others.

 

What common mistake do you see developers making?

Giving up on being a developer after five or seven years because they think they know it all and they’re getting bored.

I’ve seen a large number of developers - really talented ones - who worked hard, gained a high level of proficiency solving a particular kind of problem, got bored, and changed career path entirely.

Why does this happen? I’m not really sure. I’ve been programming in some form or another for over 35 years (yikes!); professionally (full time) since 1997, and I’m still learning new things, still being challenged to grow, and still having a great time solving interesting problems.

If I had to guess, I suspect these people get stuck in a rut, solving a particular kind of problem with the same techniques using the same tools and they think (rightly!) that they’d go insane if they spent the next 10 years doing more of the same. Where they go wrong is in thinking that a massive career switch is the only solution.

The core skills of being a developer are extremely transferrable - while the syntax, semantics and idioms of each technology stack vary, the differences are often less than you might think. Admittedly the transition is easier if you’ve established the habit of constantly learning new things, but anyone can do it.

 

What has been your toughest lesson to learn in your software career so far?

There’s the well known cliche of a nerd as a socially inept boy who spends most of his time in the dark of his parents basement, preferring the company of machines to his peers. Well, my parents house doesn’t have a basement but much of that classic cliche did once apply.

What I’ve discovered, initially to my horror, is that the truly interesting projects are far too big, involving too much work, and requiring too many different kinds of expertise, for one person to successfully complete solo.This means that a successful career as a software developer necessarily involves working in a team of people with diverse skills and different responsibilities. This guarantees that you’ll be working with people who don’t think the way you do.

I’ve found it much harder to learn to work with the people around me than any of the technologies that I’ve had to pick up. Fortunately, it’s also much more rewarding.

 

What would be your number one piece of advice for a successful software career?

Never stop learning.

This underlies a lot of the advice you’ll find - learn a new computer language every year, read a new book for professional development every month, and so on.

We work in an industry where things move at a tremendous pace - and in many ways, our job is to foist that change on other people as well. No one is going to pay you to develop software if it doesn’t have any impact on the business when released.

One temptation is to focus on the technical side of things, learning new languages, frameworks and techniques. Those are important,but don’t ignore the so-called soft skills (the ones that are actually hard to learn). There are a million things to learn that aren’t coding that will contribute to a successful career.

 

Have you got any hobbies outside of your job? Do you think they help your tech career in any way?

Many would consider me somewhat unbalanced - my hobbies include programming and blogging. These are the things that I do for fun.

So at the end of a busy work day writing code and solving problems, I head home and spend the evening writing more code and solving more problems. The biggest difference is that the development I do in my own time is done for the pleasure of it, not because there’s a looming release deadline. If I’m having fun with a project, I keep working on it - if not, I’ll find something else to do.

I’m an active relaxer, so I can’t relax by just sitting and enjoying a moment. Instead, I need to be doing something, preferably something creative.

 

What books/resources would you recommend?

There are so many possibilities, but let’s keep it to a top five of sorts …

1. The Pragmatic Programmer (Hunt/Thomas) - this book talks about what it means to be a professional developer in the deepest meaning of the term. I reread my copy every couple of years and learn new things from it every time.

2. Refactoring (Martin) - learn how to improve the structure of an existing program in safe ways. Martin introduces a vocabulary that is very useful when talking to other developers about how to improve the code. Can be a little dry in places, but worth reading the intro to each pattern and then keeping it within reach on the shelf for when you need more detail.

3. Design Patterns (Gamma, Vlissides, Johnson & Helm) - reusable design approaches for writing maintainable and extensible systems. These patterns weren’t invented, they were harvested from the combined professional experience of the authors. Like Refactoring, these have value for the shared vocabulary. Very dry in places, and some of patterns are less relevant for more modern languages.

4. Smalltalk Best Practice Patterns (Beck) - lots of advice for design and implementation of object oriented systems. The discussion of the motivations behind each practice makes it invaluable for people working in other technology stacks as well.

5. Java Modeling in Color with UML (Coad, Lefebvre and de Luca) - look past the Java and the UML and you find Color modelling, an innovative idea that will turn your ideas of object and database design on their heads. Remember your classic lessons on object inheritance, where Student inherits from Person? Read this book and you’ll never want to do that again.

6. F# for Fun and Profit is a great website for learning about F# and functional programming. I’m no expert on F#, but I’ve found that learning FP has made me a much better developer, even when working on other projects.

 

Finally, make your shout out! What would you like the readers to go have a look at?

A bunch of us are organising Code Camp Wellington for April 14th - check out https://codecampwellington.nz/ for details and follow @codecampwelly on twitter. This will be our third Wellington Code Camp - the past two got some pretty good feedback.

I guess I’d be remiss if I didn’t mention my blog at http://nichesoftware.co.nz/ where I’ve been blogging for several years on a variety of topics.