Mentors
A few weeks ago, we had the usual meeting with the technical leaders on “junior developers in the team”. The session was quite long to be summarised in a single blog post but it started with an interesting exercise: “Find some aspects of your mentors – when you started programming – that you remember favourably”.
After some reflection, I came up with this list:
I ended up with this list:
- patience
- general indications
- lateral thinking
- the ability to simplify
- constancy in taking notes on decisions/meetings
- the ability to organise your own work
Let’s see why I think these features are valuable to a mentor.
Patience
I started “programming” quite young: my father was a programmer and I had access to an 8088 immediately after an Apple II machine (which I only used as a user, playing with the legendary choplifter!)
I remember asking around a million times the name of a keyword or the name of a program (or sometimes just the correct spelling) and I always had a calm answer, as if it were the first time I’d asked.
For a beginner every word is new, no question is meaningless, be polite and answer. Beginners are stuck without that exact piece of the puzzle.
General indications
I started programming in Visual Basic and then in PHP, writing management software, so nothing complex, lots of graphical interfaces, data to be manipulated, a little business logic.
To estimate for a new project I was advised to count the masks and to estimate the project based on them. And it worked quite well. Sometimes a simple window “covered” a more complex business logic, sometimes the opposite was the case.
The broad indication was: when the problem is complex, choose a strategy to break it up.
No matter what strategy you have chosen, the main value is to split the problem into more manageable parts.
Another example of this type of teaching is the “Zen of Python“:
The Zen of Python by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!
These rules are too vague to be directly applicable, but they are clear enough to give a direction.
Another rule I try to respect concerns the application of the EAFP rule : “Easier to ask for forgiveness than permission.”
if os.access("myfile", os.R_OK):
with open("myfile") as fp:
return fp.read()
return "some default data"versus
try:
fp = open("myfile")
except PermissionError:
return "some default data"
else:
with fp:
return fp.read()This rule applies whenever a race condition is perceived but it is not a rigid rule. If the nested function needs some input prerequisites to be verified, the error in case of invalid input could be a cryptic ValueError or KeyError without enough context to understand the problem.
See also the article by Brett Cannon « Idiomatic Python: EAFP versus LBYL »For a slightly broader analysis.
All these general rules are vague indications; fail early, or even explicit is better than implicit, come into play in an undefined way. The goal is to give more weight to the one that best suits the context.
Lateral thinking
Most of the time, we face problems to which no-one really knows the correct solution and our path is set by our first steps in one direction or the other.
The difficult part is that often, once we have started a journey, we are only looking for the minimum changes that can improve our work. But, without changing the structure, we risk getting stuck in a local minimum.
If we have friends who have an aptitude for lateral thinking, that is to be able to approach the same problem from other angles, we discuss our problem or our architecture with them and perhaps we will have a new perspective, perhaps a new, easier path to follow, reusing at least part of the work already undertaken.
When something seems not optimal, ugly, take a step back, start with a fresh mind, question your assumptions. It is better to rewrite it now, essential with no other work created above it, than later.
The ability to simplify
Here is another application of the general rule that brakes up a complex problem: as in understanding a problem, also in creating a solution, dividing and simplifying are excellent strategies.
Whatever the problem to be solved, however complex it may be, it may be useful to resolve a simplified version, if only to better understand its context.
Sometimes it is possible to start to simplify in the planning phase, sometimes instead it is necessary to do so when there is a problem that invalidates the initial plan.
Constancy in taking note of decisions/meetings
Start thinking about the big picture, so start with the first step that gives you a value: it can be an API or something working. And then iterate for small improvements in operation.
Verba volant, scripta manent, “the spoken words fly away, the written words remain”.
We usually talk a lot during a meeting, we deal with various topics, but after the meeting … what remains? We often note something that we would have remembered very well and instead omit things that seem obvious to us, but which we do not remember. Fortunately we are not alone, so sometimes you just need to ask a colleague to reconstruct the puzzle.
Writing helps to remember decisions, to summarise digressions and to identify a missing logical step in a verbal discussion. Also, meeting notes are a good place to assign tasks and deadlines.
Unless you have a super memory [^1] – and even if you have one – be kind to others: write a summary after each meeting, decision, brainstorming, assignment of tasks and deadlines..
I share most of the suggestions in this post: Manage efficient meetings with engineers .
The ability to organise your own work
In the past we had a single task in our team and someone else was guiding us, assigning things to do, and following us, asking for updates on our progress. Now perhaps we have 3 development projects to follow with 6 developers, 1 upcoming conference to organise, 1 blog post to write for the company’s technical blog and a 2-day course to prepare. Not forgetting the 3 stand-ups and the endless notification flow of your company’s favourite chat.
Working on a single task is a forgotten dream, the new reality is the change of context. But if you let your tasks guide you, at the end of the day, when others head home, you’ll end up thinking “Wow! Finally I can start doing something today!”.
There is no easy solution for this, or, at least, if you have one, please let me know! The only way I found to feel – and perhaps be – a little more productive is to plan any activity on the calendar, and to record all the activities with enough details to remember what was done by reading the list a few days later (toggl.com is my favourite tool).
If you have a meeting, perhaps you should be prepared for the topic you are about to discuss, so schedule some time in your calendar to prepare; you could even schedule a meeting with yourself, so others will also know you’re busy.
Bonus track
During the TL meeting we also watched together the intervention of Netta Bondy, presented at You Gotta Love Frontend 2016: 6 things your junior developers don’t tell you , same topic, very interesting ideas.
Conclusion
This is the story of one person but at that meeting we all had a list like this, sometimes similar, sometimes very different. In any case, in the end we all needed a lot of help to get started, and now we’re in the position of having to do our best and help new developers [^2].
Here it is then, a small piece of wisdom that I believe I received from my mentors. What is your experience?
[^1]: I have a super-powerful memory by Damian Gryski
[^2]: The number of developers in the world (currently) doubles every 5 years (source: The Changelog #367 – Back to Agile’s basics).