2 weeks ago by coyotejl
Two weeks ago I outlined a number of challenges faced by apprentice (or other first-time) developers. The very first of these hurdles is new concepts and code standards, my description of which is below:
“…wrangling with philosophical concepts that are either completely foreign or understood only in theory…(e.g.) the Law of Demeter, command-query separation, separation of concerns, and other SOLID principles.”
Today I’d like to elaborate on this challenge and provide some advice for both new apprentices and their mentors on how philosophical code concepts can be best learned and understood.
For apprentices, I have three recommendations regarding immersion, repetition, and feedback. The first suggestion, immersion, is self-evident, but important enough to state explicitly:
In order to learn as efficiently as possible, you really have to study (and I mean this in the traditional sense of the word) programming concepts regularly. I like to take time at the beginning and end of my day to check any blog posts shared in HipChat or on Twitter. I also read regularly outside of work. Reverb’s dev team meets weekly to discuss programming literature over lunch, which helps supplement my regular self study with expert opinions and anecdotes. Overall, I make sure that I’m constantly engaging with the dev community to keep up with both historical and current programming concepts.
This segways naturally into the second recommendation I have, which can be distilled down to one word: repetition. In order to transform described concepts into engrained knowledge, you need to apply these theories to your code.
This is actually easier said than done when you are working on projects that you don’t choose yourself. I try to find one thing that speaks to me and keep that in the forefront of my mind for a couple days. It’s only after implementing written rules in your own code that it truly begins to become second nature. For this reason, be aware that (depending on the concept) it may take a while before you can find a place to implement a particular strategy. I encourage you to bookmark articles to revisit them later and take notes when reading books so you have something to review in a couple weeks. Reviewing past literature will help you gauge your progress; an important part of growing from apprentice to journeyman.
The last suggestion I have regards feedback. While studying and applying new concepts and code standards to your work, it is easy to become isolated from the most important aspect of your growth: personal feedback. Open yourself to criticism; it is the best catalyst for learning. If possible, discuss your takeaways regularly with colleagues. Not only will this challenge your interpretations of your reading, it will also reinforce what you’ve read and help you adapt new concepts to your style of programming.
On the flip side, assisting mentors as they learn high level concepts can be a challenge. Too little help and an apprentice may develop incorrect practices or standards that aren’t aligned with the rest of the team. Too much information, however, can overwhelm an apprentice and impede the rate at which they learn. Mentors need to allow for appropriate pacing; rushing through literature for volume doesn’t allow for the knowledge to ‘sink in’. Encourage your apprentice to read and, if possible, read along with them and discuss the described concepts together. This will help you keep tabs on the apprentice and make sure they don’t wander astray.
That said, be patient. Expect repeated mistakes. It’s difficult to juggle multiple concepts at once when all are foreign. Try to focus on one area per week in order to make learning manageable. When critiquing code, address the area of focus as much as possible. This will help the apprentice learn by doing, but keep the criticism poignant enough that they don’t feel overwhelmed.
Finally, engage in empathy. This is universally important, but when dealing with an apprentice, its relevance is tantamount. Criticism is extremely helpful, but make sure your feedback is specific, actionable, and kind.
Welp this turned out to be far longer than I intended originally. Stay tuned for my next post, which will focus on improving tech-specific knowledge and the difficulty this might give a first-time developer.