Practicing & Performing

Tiago Gabriel — Wed, 23 Mar 2022 18:38:04 +0000

Key Takeaways

Practicing is key to achieve better performance.
Musicians, acrobats, sportsmen, etc., spend much of their time practicing, and little time performing. Software professionals should follow the example.
The focus should be on continuously getting better, instead of trying to achieve perfection.
Find yourself a time schedule where you can apply relevant techniques. Reflect on the process, on the discovering, and on the feedback you are getting. Do it again, over and over 😉

Have you ever wonder about what makes great professionals, well, great? Is it a matter of being "naturally gifted" or something else?

Imagine you are at a concert, watching your favorite band, and you are astonished by their mastery of the instruments (and their music, of course). How did they manage to achieve such ability and make such great music?

Now, if you extrapolate the same thinking process towards acrobats, sportsmen, doctors, sculptors, architects, etc., you will end up asking the same question. The answer may be in the difference between practicing and performing.

Practice makes better, not perfect

You may have heard of the 10,000 hour rule, popularized by Malcom Gladwell, in his book Outliers: "(...) it takes 10,000 hours of intensive practice to achieve mastery of complex skills and materials (...)". This statement has been debunked several times (see 10,000 Hours May Not Make a Master After All), because there are a lot of factors that influence the mastery process, not only practice. But, one thing seems to be reasonable to claim (see Over-Practicing Makes Perfect): continuous practice makes it better.

Perfection is quite subjective idea. So, that seems to be a good enough reason to strive to be better, instead of perfect, simply because there is a previous state to compare to. Since your current state of better may be perfect to someone else, constant practice leads to eventual perfection.

The art of performing

When you practice something, whatever it is, you do it for a reason. Maybe you want to be great at playing football, or guitar, or piano, or picking up an heavy weight, or typing really fast, or writing awesome and correct code, efficiently. In our daily job, we spend our time performing code (I am ignoring all the meetings 😂). Remember watching your favorite band? A band performs one to three hours, but practices so much more. Just think what would happen if they came on stage without previous practicing... Their performance would be a practice session, and maybe not exactly what you were expecting and paid for. Hence, seems reasonable to assert that high-performance is a result of consistent practice.

Better performers

How do we practice "correctly" to improve performance? Well, allow me to use an analogy of my own. I do CrossFit and it is an activity that has taught me a lot about this topic. Every week we do a benchmark Workout of the Day (WOD) to evaluate how we are performing. Given a WOD like "Grace", we do not start by doing the exercise immediately, because that would be dangerous and lead to severe lesions. We start with a lighter weight, practicing each small part of the movement to achieve a good technique – most of these are practiced daily – and, afterwards, link each of those parts together. With time, we are ready to start the WOD and measure the results. If you have done better than last time, you know that you are improving.

Thus, to better perform, we must practice and measure continuously, even if it means that the measurement is qualitative (e.g., do you feel you are a better problem solver than yesterday?). Find yourself a time schedule without interruptions, without stress, where you are dedicated to solving specific challenges and focusing on the techniques involved (e.g., design, refactoring, code reading, approval testing, etc.). The end goal is to reflect on the path taken, on the feedback you are getting, and the discovering you are making. When the time comes to perform, you will do it better than ever before 😎

Não percam o próximo post, porque eu também não

Sharing is Caring

Tiago Gabriel — Tue, 01 Feb 2022 20:19:27 +0000

First post. Wow! I was not sure that this would happen, at all. I always felt a little reluctant on sharing my experiences, thoughts, ideas, simply because I do not view myself as a mastermind or anything like that.
However, I realized it does not have to be that way! Time and experience taught me that it is desirable to share: this will result in feedback, in useful discussions, in different points of view colliding, which ultimately results in a deeper and more consolidated knowledge 😎

A little bit about myself

My story is kind of "weird", in a good way, I think. From a young age, I was always very curious about the world and things around me. I disassembled toys to see how they worked from the inside, which pissed my dad off; I grabbed my books to build little model houses; I did fine arts; I was into science, literature and mathematics; I was (ahah, "was"... right!) essentially a little geek.
At the age 14, I decided I was going to be a Chemical Engineer, encouraged by a teacher who saw talent for that.
Years passed, and life's circumstances did not allow me to go to the university, which ultimately lead me to work in the manufacturing of cork stoppers (for real!).

Fast forward to 2012, I got into a technical course: Industrial Electronics, Robotics and Automation, hoping to align my industrial career to something I also enjoyed very much: electronics. There, I learned programming! A whole new world opened up in front of me! "This is great! I am a God to this machine!". Driven by that feeling, I took my learning path one step ahead, and in 2014, I jumped into Computer Science and Engineering's degree. It was difficult, especially because I was working at the same time I was studying, but, in the end, it turned out to be an amazing experience.

Meanwhile, 3rd year into the course, and got my first job as a Software Engineer. Since then, I worked with many types of systems, some of them with almost my age (Gen Y, 90s 😅), different technologies and keep on learning everyday -- which is the reason I started writing.

Why?

The straightforward answer is: getting out of the comfort zone, by sharing my opinions, knowledge acquired from personal experience and from relevant literature of the business (I am an avid reader 📚).
Being an introverted type of person, this exposure allows me to "digest" my thoughts and mold them into something tangible, something that I think it can bring value to other people. Also, it is a huge help on bringing my career forward, of course. Last, but not least, I have a feeling that writing these posts will also improve the way I write code.

What will be shared?

Everything! Of course, depends on the context. Do I really mean everything? Well, everything that can be related to the software development field, yes! If you also want to know about the manufacturing of cork stoppers, I can also share that! ahah

Most of the content will focus on eXtreme Programming, Legacy Code, Evolutionary Design, Refactoring, Test-Driven Development (TDD), Lean Development, Continuous Delivery, Concurrent Programming, etc. I am mostly interested in presenting a more analytical view of these several topics, but I will also strive to show some practical examples, when relevant.

Let the fun begin

This post marks the starting point of this sharing path. Sharing is caring, for all developers out there, and for myself as well. I am in the baby steps phase, therefore I will try to post new content every month, while starting up. With time, I will adapt to what fits best for me and the community.

Feel free to read, to criticize (constructively, please), to share ideas and suggestions, and to reach me out through here, LinkedIn or Twitter.