diff options
| -rw-r--r-- | _posts/2016-10-27-take-the-time.markdown | 427 |
1 files changed, 427 insertions, 0 deletions
diff --git a/_posts/2016-10-27-take-the-time.markdown b/_posts/2016-10-27-take-the-time.markdown new file mode 100644 index 0000000..343d9ca --- /dev/null +++ b/_posts/2016-10-27-take-the-time.markdown @@ -0,0 +1,427 @@ +--- +layout: post +title: Take the time +tags: [ learning, presentation ] +--- + +> Check the [slides](http://slides.com/josemotanet/take-the-time) 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: + +1. Are you speaking/writing in English almost as often as you write code? +2. Do you think you master the language? Do you even care? +3. 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: + +1. 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. + +2. 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. + +## Useful links + +- [The Art of README – Stephen Whitmore](https://github.com/noffle/art-of-readme) +- [We, the community – Tiago Pedras](https://www.youtube.com/watch?v=_voYKIMOA0M) |