This is the transcript of my talk at RubyConf Portugal ‘16. Unfortunately the recording was corrupt and is unavailable. Check the slides that went with the presentation.
I want to start with the following quote from Ernest Hemingway as the premise for the talk:
There is nothing noble in being superior to your fellow man; true nobility is being superior to your former self.
Ernest Hemingway
I saw this quote for the first time in the movie Kingsman. I didn’t realize who it was from at the time, but I did know who it should be for: every software developer who understands the value of their craft, as well as the need to constantly keep up with the latest technologies and schools of thought.
This happened in early 2015. I certainly knew that I was already curious about things than most colleagues I’ve met in my career were not. I always felt apart from most of them. I had to chance to change that trend and work with some of the best people from around the world when it came to education.
My time at Tuts+
I joined the company in March 2012, one of the best companies to work for if you want to pursue an educational path. This was a great opportunity for me because I always enjoyed helping others learn something new to them. Tuts+ helped me become a better teacher by exploring small details a lot deeper: structuring content, improving assumptions about students, finding their limitations, using quality analogies and examples to convey your message.
Feedback from my students was paramount. They were the ones learning from me and their results were my evaluation. I felt comfort and satisfaction from their success stories, the same way I was concerned about their inability to comprehend certain parts of my lessons. Regardless of the outcome, I would know where to go and what to improve in order to become a better teacher.
Aside from being able to improve my way of approaching students and their educational needs, the second most important thing I got from teaching was learning those things myself. There was so much to soak in that there were times I was pretty tired of learning! Serial learning can be exhausting at one point but don’t let that become an obstacle to you. Cherish your passion for learning new things always. I only mentioned this curiosity because it was my job to learn so I could teach back and the process of digesting content for other people to learn from proved to be somewhat of a difficult task.
Screencasting vs in loco teaching
I used to screencast back then. Some might contest the format, in the way that it limits the interaction between a teacher and a student/class and therefore the overall learning experience is compromised. It turns out that the argument is quite valid. The strongest point of screencasting is persistence, access and cost effectiveness. Content should be potentially stable in the future, preventing updates to happen. When content is handed off for recording, it’s only a matter of producing it through simple themes to convey the message.
Screencasting can be a great way to educate unidirectionally, using a different pedagogy. Students expect an unambiguous, straightforward take on a common problem that promotes little to no discussion; at least on an immediate level. A followup usually takes place through some other format: email, Twitter or forums are the usual suspects.
When I run training sessions in loco, the experience changes dramatically. The agenda can be planned to be more challenging but also more thorough and/or more appropriate to the audience. I can connect to the students’ minds and shape certain parts of the training to their own context. The result is a much more diverse, richer environment where everyone shares their learning process willingly and persists the training a lot better; pretty much like human beings persist memories better through sound or smell.
Personal training sessions have been the classical form of educating for decades, if not centuries. A teacher educates through spoken word, while sometimes resorting to auxiliary material: slides, audio, video, exercises and field trips are the most common. There must be a reason why this is still the most common practice.
How the brain works
My daughter is now 14 months old. She has a very intense routine in the way that she lives her life very fully. At this time, it’s only a matter of a few days until she learns a new gesture or associates a new word to a new toy or object, which I find amazing.
My wife and I regularly turn music on for her and she enjoys it. Music (or sound, for that matter) or any other sense is a great way to boost memory. How many of you recall a certain place or a certain event in your life by just listening to a song or by smelling a certain perfume? For instance, I recall a certain emotion I felt by listening to a song from Bryan Adams, or a person I cherished by smelling a particular perfume.
A video or a podcast can only exercise parts of your brain so much. There’s only you and the words in your ears and/or in your screen. Content is peeled away from its potential to stick onto your brain, requiring much more effort from both you and your teacher, without necessarily ensuring you learn effectively and efficiently.
In loco training sessions give room to all senses to take part in the learning process, added to the fact that the teacher can pick up on each student’s experiences and shape the content to them. Your brain learns far easier based off your own constructs than anyone else’s, because they are not your own. I’ve done this in my last session and the results were very positive. Students soaked the knowledge much better because I’ve used their own context.
The orchestra that played a symphony
Fables are wonderful for children. Simple stories that lead to a meaningful ending that applies to our own lives. I’d like to share a parable to establish a comparison that I told a class before. Software is often comparable to other crafts, particularly music.
Enter the orchestra that played a symphony.
An orchestra is to interpret a symphony. The maestro will conduct it. Each musician plays a different instrument, which in turn is laid out in their rightful place and fulfills a role in the whole masterpiece.
Strings are at the front, from violins and violas to cellos and double basses. Woodwinds are next with clarinets, oboes, flutes and bassoons. Behind them lie the brasses: trumpets, trombones, french horns and tubas. Percussion goes way in the back along with a possible piano and a harp.
A symphony has a well defined structure. It usually has 2 or 3 movements and is written in a particular tone. Unlike a concerto, there is no highlighted instrument that plays a lead role. Each one is a different but essential part of the machine, with no more nor less importance.
The maestro has the responsibility of guiding the musicians along the interpretation. He knows what each instrument plays and how they should be played. Dynamics, tempo and musical interpretation are his to portray and demand. The entire collective of musicians must obey his instructions to achieve brilliance and harmony.
Writing software is very much like a symphony. Well, at least it should be. Coordination; orchestration; separation of concerns and responsibilities; clear entities and roles; these are key points to brilliance, mastery and ultimate satisfaction. When we write simple, malleable code with these principles in mind, we achieve confidence which turns into bliss, among opportunities to tackle new challenges, improve ourselves and focus what really matters, instead of having to babysit our code each time something new appears.
Long should be the days of writing bad code and feel indifferent about it. We are no longer young, illiterate beginners; we are professional software developers and it’s time we bear that entitlement more seriously. But how can we face new challenges everyday while still keeping the quality we want to portray?
Improve yourself
English skills
Let’s face it: we write code in English all the time. We communicate in GitHub in it. We wouldn’t think of doing otherwise. It is the universal language for software developers and at some point in time we just end up living our lives in English. For instance, is your phone’s language set to English? Is your Facebook page in English? Your website, your operating system, your video games? I know for a fact that I live my life pretty much in English. My wife is even considering teaching English class to my daughter so she can be prepared for the future.
Despite all this, the questions I want to bring up are:
- Are you speaking/writing in English almost as often as you write code?
- Do you think you master the language? Do you even care?
- Do you struggle with expressing your thoughts/ideas through spoken or written word?
Learning how to convey our thoughts through a vehicle other than code is an extremely important soft skill to develop, so much so that our ability to code benefits from it directly. If we dedicate a little effort in practicing both written and spoken word, we stretch our boundaries and we collect incremental but significant results. Eloquence and mastery of the language open doors for new ways of approaching problems with more elegant, more insightful solutions. By improving on vocabulary and syntactic constructs we flex our perspective and we relate to challenges a lot more intelligently.
I’ve been speaking English for 22 years now. Ever since I was eight years old, I have been exposed to it by American friends coming to our home and they would talk to me in English so I could practice. I watched a boatload of cartoons; in English. All the way from Dexter’s Laboratory to Cow and Chicken, so many others that I lost count. I soaked everything.
I can imagine most of you didn’t have the same fortune as I did. Truth be told, the only thing I had was a head start. There is no time like the present to engage in the commitment to improve the way we speak and write.
Charisma and confidence
It’s one thing to grasp a natural language on your own; another thing is to come out and express yourself to someone else. For some, this capability is natural — I, for one, have no problem with coming up on stage and speak to an audience —; for others it is their biggest fear in life.
When I was little I was afraid of talking to people, I was awkward that way. However, with time I have conquered my fear by pushing myself around different levels of comfort zones. Sure, it took years, but then again I was a child and I wanted to play video games more than I wanted to speak to others.
I was an active member of a religious group for some years and I was constantly challenged to participate in regular meetings. There was a segment in these meetings where people would stand by the pulpit and speak to the congregation. I started doing that at the age of nine. I planned and wrote the content at home, while resorting to the scriptures and quotes from leaders of that time to support it. When I was done I would rehearse my speech with my parents to make sure I had it right. I’m 30 years old now and I still review my talks with my wife.
One thing I also did to improve my stance around people was learning how to dance. A true game changer! I entered college at the age of eighteen and even though I still wanted to play video games, I also wanted to meet women and be comfortable around them. So I joined a Salsa class to get my own way. You wouldn’t imagine how nervous I felt when holding a girl in my hands. It took me a year until I went to a Salsa joint at night to dance with girls I knew, let alone total strangers. As time passed, my inhibitions faded and I felt a lot more confident in awkward situations.
My last step to develop more confidence was to join a Tango class. It was a lot different than dancing Salsa but certainly no less a challenge in itself. Tango requires coordination, balance and communication. I was told that Tango is the only place in the world where the man is fully in charge. I took that joke as a challenge to myself. I was in charge of my body, my mind and my partner’s body as well. We were apart by no more than a hand’s measure. It takes grit and skill to do the Tango properly.
This was my way of developing the often overlooked but very important soft skill to master: confidence. I took each of these challenges by the horns and I succeeded in being more confident around other people; not just women, mind you. Along with that came more self esteem and charisma to deal with today’s objectives. The thing I enjoy the most about learning completely different trades is that they always bring something we can take into our work and life, something transversal to all disciplines.
If we managed to have the guts to engage with our girlfriends back in the day, I’m pretty sure you’ll be able to speak to a small audience such as your team. I’m not saying you should learn how to dance but try and dare yourself to do new things every now and then. Step out of the comfort zone and expose yourself to new experiences outside of work.
Improve your project
Meaningful documentation
How many of us have gazed through a terrible interface, a sidewalk placebo button or a cheap appliance with weird, unexpected behavior?
The worst feeling when trying to use any library is to realize that it’s not well documented: perhaps it’s not scientifically correct; it has been written poorly. We can’t go anywhere in a sensible time frame. What could be a potentially great asset to your project ends up in the bin because we can’t reason with it and you question its reliability in the long term. No one wants a stale library that won’t fit some time from now.
A README document is the doormat for any piece of software, regardless of it being a gem, a plugin or your own Rails application. It should answer the following questions:
- What is the project about?
- What does it do?
- How does it work?
- What are the general options?
- How do I install it? Any requirements?
- What are its quirks and caveats?
- Have other people asked common questions? What are the answers to them?
First impressions are paramount. That also happens with the README, you should nurture it and give it as much attention as you do with your code. It reflects the overall quality of your software. What you write in the document should be exemplary, trustworthy and reliable. Go the extra mile and ask a proficient — if not native — English speaker to proof your document for spelling errors and poor phrasing.
Ensure scientific correctness, in the way that the words you write should match your code. I’ve come across a library once, and one of the inaccuracies I found was that it claimed to be for Rails only. However, that was definitely not the case as there was nothing in the source code that targeted any Rails feature, even though there was a railtie. Rails was declared a hard dependency when it needn’t be. Besides working my way to remove the unneeded dependency, I ensured the README stated clearly that Rails wasn’t needed and could target any Ruby project, along with a couple of examples to prove the point.
Small but effective initiatives like these are extremely cost effective. Whether you’re bringing a new developer to your project or publishing a new open source library for others to work with, they will simply not dig through the code for answers. I dare to say they will drop your library almost instantly if they find a poorly written, incomplete, inaccurate or non-existent README.
Educated code / code as narrative
Following up on the previous topic, when we grok the language we use daily for communicating our intentions and we apply that ability when writing code, we significantly improve its quality and life expectancy.
If you ever attended a code retreat before, you might recall the Conway’s Game of Life exercise. It’s one of the best opportunities to explore new ideas, try new things and improve one’s craft. I’ve come across several attempts at the exercise and the conclusions I take from them are very interesting:
-
Novice programmers tend to express their ideas very vaguely. Poor naming, complex and/or nested code structures, little segregation of behavior, among others; these are the most common patterns. When I ask the reasons behind their approach, they often struggle to explain their thoughts clearly. This inability to speak their code blocks opportunities for improvement in an efficient, timely and confident manner. Things like substantial refactors and behavior swaps pose a significant challenge. Tests have little impact on their role as quality enforcers.
-
Experienced programmers have a much more mature grasp of the concepts to be put to test in these sessions. They showcase great skills in naming variables and methods, extracting behavior into their own classes, simple testing and mild refactoring. Furthermore, these programmers like to take different approaches in terms of perspective. They usually like to explore uncharted territory, attempt creative solutions, take stabs on performance or simply explore tools that are new to them: perhaps a new language or a new test framework. Since functional programming is the new hotness right now, a lot of them tend to explore that paradigm.
What I tend to do in these sessions is to teach beginners how to write prose with code. A narrative is much simpler to interpret and rework than just using code primitives. They are just too distant from our regular thought processing, we need to write code that is as close to natural language as possible, without compromising quality or performance. By doing so, we avoid getting lost in translation, while representing behavior by a proper name and create opportunities for change to happen within a natural language domain if needed.
In a nutshell, narrative is the linchpin that holds every part in the business: developers, clients and managers. It is the common denominator to all disciplines. Eloquence promotes clarity which is paramount to success. There’s no reason not to promote this idea in your team.
Challenges
There’s no doubt that promoting education in a company is a serious endeavor. It costs time and, ergo, money. Developers want to keep up with the latest and greatest, but things like deadlines, overall fatigue or bad management (macro and micro) prevent us from taking the plunge. To make matters worse, management often encourages innovation and new ideas, albeit on paper because there’s no time or money to support it. I’ve come across this very scenario and it’s very disheartening to experience the paradox.
We all want to upgrade our apps from Rails 4 to 5, rebuild them from scratch because of all the technical debt, use microservices, a SPA with Ember or React, implement a Docker infrastructure in AWS, perhaps use Kubernetes, switch from Rails to dry.rb or even Elixir and Phoenix entirely, kick the asset pipeline out for Webpack or Brunch. What’s preventing us from doing so? You can only know the answer if you take the time to find the true answer. Remember that the first answer might not be the best one.
It’s important to take small steps when going to introduce change. Software isn’t a one trick pony that often and determining how much value a tool brings to our organization is crucial. Don’t just use React because you want to, determine its cost of investment over its return. I remember one time where React was brought up to the table and as much as we would like to use it, it just wasn’t meant to be. It meant an entire rework of an application that was 5+ years old with so much debt that it would be ludicrous.
Instead of going for reworks, why not building a small, internal tool? Like Subvisual does? Apply your investment into a leveraging, usable product and draw conclusions after that. Learn by doing something valuable and yet without restrictions. Think about how it could be injected into your already existing apps while considering its implications:
- Is it feasible?
- Does the integration do more harm than good?
- Does it fit into your infrastructure or does it need to fit the app?
- Does it scale well?
- Does it hurt your users’ overall experience?
- Does it cause regressions?
Should you find value in the change and ensure it’s within your company’s reach, you should go for it. Part of who we are as software developers is to push the limits, if ever so slightly. Record what you did and for what purpose. Throw a wednesday talk about it, share your insights to the entire team. Have it participate in the debate with each colleague’s own ideas.
Create an education strategy
What do you think about all this? Is this too farfetched a vision? Are you afraid you might waste time and money? Does your manager resist change or does your company simply not create the investment or interest that’s required for improvement?
I challenge you and your team to consider and implement an education strategy. Don’t just stand in awe before someone else’s achievements, set goals to achieve improvement yourself. Work with each other, include management in the endeavor too. Start small. Save an hour each week to talk candidly about your projects, how they stand and what’s not working so well. Track your findings in a log and go from there. Arrange internal talks and promote meaningful discussion. Be organized when you do all this, it’s hard enough to live under deadlines and technical or educational debt, let alone in chaos.
It’s not easy most of the time, I’ve been through that myself. In fact, it was so hard to try and bring these ideas that I had to quit my job. Sometimes the path is too treacherous to even try, especially if you’re alone.
In a nutshell
Take the time to get educated. Raise your standards, your team’s and your company’s. Be better than your former self. Stop coding for yourself, start coding for others. Tell a meaningful story. Be confident in your code and your words. Take the time to practice and master the little things so as to give space and time for more important things. Grow your judgment to be unbiased and enriching, rather than demeaning towards others.
If you’re going to pursue teaching in any way, teach others the way you’d like to learn. Don’t just throw words out for free; hone your method, be valuable to your students, respect one of the oldest professions in history.
Take initiative towards your peers and management, speak up about your concerns and ambitions. Make sure those will benefit the company or team in any way. Start with small things and climb your way up towards more challenging but more rewarding endeavors in order to grow as an individual and as a team.
Increase accuracy in your projects by writing code that represents your business, in a context that everyone gets right off. Reduce the risk of error and give room for progress and for important communication to happen, instead of fighting over avoidable bugs and regressions.
A call to our managers: promote time in your company for its education, allow developers to embrace innovation and respond to challenges, empower them with the craft they need, as well as soft skills. Walk alongside them, not behind or in front of them.