Mentorship at Nested part 1: A Call to Arms
Programmers love abstractions. Abstractions buy us leverage. They allow us to re-use something that we have written and tested already, in many different situations. This reduces the amount of code we have to write, but also increases our understanding of it, because at any one time there are less things to know.
Here’s an example. We could write a complex programme in 10,000 lines of Basic. Or you could define some simple primitives, things like ‘cdr’, ‘car’, ‘atom’, ‘eq’ and ‘cons’, then use those primitives to create a Lisp interpreter. From then on, we could think about the rest of our programme in terms of those Basic functions, and re-use them to express anything else.
That upfront effort of writing some Basic allows us to ignore it thereafter; we could write all future programmes in Lisp! In fact, unless our Lisp interpreter broke, we would (in theory) never have to write basic again.
The leverage in this case comes from the benefits of an initial effort (the Lisp implementation) being reaped multiple times, without having to repeat that initial effort.
Let’s look at another example of this. We can write code that is quick to write, or we can write code that is easy to read. Sometimes they are one and the same, but often code that is easier for others to understand takes a bit longer. If we put that initial effort in, every time that code is read from then on, we reap the benefit of having easy to understand code, without having to repeat that initial effort**.
And one final example. We can as programmers spend time learning about various techniques and programming paradigms. Or we can spend some time learning how to learn quickly and effectively. Which will reap more benefits in the long run?
The way to get good at the things that will buy us leverage is to practice them. Now I want you to consider hiring.
Hiring good senior engineers is a nightmare. They either don’t exist, or you have to poach them from a startup down the road — and good luck getting their attention amongst the slew of daily recruiter noise.
So what can you do? You can spend lots of time trying to hire seniors. Or you can hire the more plentiful mid/junior roles, and grow them to be the seniors you always wanted.
Now which is more likely to reap rewards? The answer depends solely on your ability to grow seniors Vs your ability to hire them. So the question becomes, which is a better investment of your time: investing to get good at hiring, or investing in teaching, coaching, mentoring people?
One of those things you will always have to do, regardless. If you never hired anyone else, and no one left, you would still have to grow, coach and mentor the people working in your business. I argue therefore, that our time is better spent on improving our ability to do these things. I argue that our ability to do so is a social good, a competitive edge, and that time spent learning and improving how you grow people will pay back multiple times over — simply that doing this will give us leverage.
Any investment in self development and progression directly tracks to an individual’s morale and productivity; you don’t just get seniors you get highly loyal and highly motivated seniors. Seniors that have practiced coaching and being coached, who are therefore well suited to develop more new people.
At Nested we want to make this investment. We want people of all levels to be empowered to progress efficiently. We want to get this leverage.
So how can we? With practice! But as all sports people know, practice is the most useful when it is deliberate, and for it to be deliberate we need to have clear goals, well defined sequences to practice and a feedback loop. What follows is my attempt at formulating some of these things to make practicing coaching more effective. It is split into two sections: Coaching and Being Coached. The latter section pulls from my experience as a junior developer, starting at Makers Academy and through two jobs. The former section will draw from my experience coaching and mentoring part time for two different companies, as well pairing with more junior developers in my day job. It is by no means exhaustive, but hopefully proves informative.
This is part 1 of a 3 part series
- Part 2 — Coaching
- Part 3 — Being Coached (coming soon)
If you like what you read, nested are hiring!
**incidentally, if we agree that code is read more times than it’s written, we should see that it’s always worth the effort to make it readable.
