Three Semi-Technical Skills I Developed at smartive
After nearly a decade of working as a dance teacher, I found myself developing a tool to customise and monitor security standards of single nodes in a network. It was quite an interesting project I thought. Still, the only question I was asked after its presentation was about my motivation for programming.
But no, this blogpost is not about gender and diversity in IT. It is not about why I think that programming is fun and exciting, why I like hard work, why it is cool to be paid for thinking or why technology can save the world. It is about what happened after I discovered all of this.
Smartive accepted me as an intern for six months. I had the privilege of being surrounded by 12 experts in their fields which allowed me to expand my knowledge on numerous topics, from GraphQL, working with third-party APIs, to Higher Order Components and Render Props, Hooks and Angular’s “Banana in a Box”.
But the most important thing I learned is not one of these things, an array of things or an array of objects of things, but that becoming a good developer needs both: proficiency in a set of technologies as well as some crucial complementary skills.
Divide and conquer with Storybook and Atomic Design
During my anthropological studies, I learned that a Social Scientist’s work is mainly structured by the holistic approach: studying an aspect of culture can never be treated as an isolated thing but always in the whole context — protecting the researcher from blind spots and uninformed hypotheses.
As a novice developer, I discovered soon enough that this approach was not effective. Too often I found myself in a mess trying to implement everything at the same time, and I struggled to see how it all somehow fits together. Finally, when I could no longer find a descriptive name for my pull request, I was painfully reminded that in order to conquer I must first divide.
A development team structures its process by defining and delimiting single pieces — stories, tickets, acceptance criteria — before tackling every single step successively. This mindset can not only be used when organising processes but also to build reusable, combinable user interfaces. This frontend methodology is called Atomic Design: components are reduced to their minimal, most abstract form as atoms, and then composed to form molecules, organisms and templates. For example, a button is an atom, which in combination with an input field atom could form a search box molecule, which in turn could be combined with other molecules to result in the navigation bar organism, and so on, until we get to templates and pages. Furthermore, Atomic Design helps you structure your codebase in small, easy to review pieces.
Component-based frameworks like Angular or React make it a snap to follow this principle, but they don’t provide a way to develop these building blocks — atoms, molecules, etc. Enter Storybook: an open-source tool for developing UI components in an isolated manner. It allows us to change the properties and to see how the component behaves in each state before integrating it into the app. Thus, Storybook works as a laboratory to develop components in isolation and as a catalog of reusable components.
Atomic Design as a methodology and Storybook as a tool allowed me to focus on the specifics of my code without losing sight of the whole project. Using it across the whole development process from feature slicing to the implementation of specific components helped me consolidate the divide and conquer approach.
Start mastering one trade
When I started my internship, I could build SPAs with React and Redux, manage SQL databases and work on RESTful APIs with Python and Django. But I never went so deep as to consider myself knowledgeable about a topic ;) Even if knowing many tools across the stack makes you a better developer and teammate, it is just as important to be jack of some trades, and a master of one. That’s why smartive encourages continuous learning, not only by going to conferences and meet ups, but also by growing individual fields of expertise.
This year’s premiere was a code retreat in the Verzasca Valley, where I learned from my teammates about Serverless, Design Systems or Elastic Stack among others. But it was also the perfect setting to get my teeth into a specific topic.
My mastery of choice has been Accessibility, a topic that had already raised my curiosity but where my knowledge was limited to a handful of best practices. Preparing the talk for the code retreat changed my way of looking at HTML. I realised why proper semantics matter — the biggest pitfalls are often the result of poorly used tags. I learned how simple it is to respect a user’s preference for reduced motion by adding a media query and why the ARIA’s (Accessible Rich Internet Application) first rule might be not to use it.
For me the code retreat wasn’t just a kickstarter on the way to mastering accessibility practices, it also showed me how our company’s culture encourages us to forge our careers.
Share values via code reviews
The first time I was asked to review my colleague’s pull request, I felt overwhelmed. What was I, as an intern, going to comment? After mentioning my concerns about taking on this responsibility, I got a great piece of advice: a code review is meant to be a discussion, not a dictation.
This discussion should reveal, for example, fragments that are excessively complex or hard to read, thereby helping to reduce bugs and improve code quality, but it should also serve as an instrument to communicate the ideals each programmer holds.
Some developers give less attention to naming, after all the computer only sees a variable. Others put readability above performance. Some like to be concise, some like to be explicit.
Working in a team, it is rather unlikely that these preferences are always in sync among all developers. I learned that code reviews lead to a more consistent codebase, maintaining styles, encouraging best practices and uphold standards, creating a common coding culture.
Anyway, luckily for me there was a forgotten console.log that made my first code review worthy :)
These six months of internship were crucial to my professional growth, of course by providing me hands-on experience and improving my technical skills, but most importantly by introducing me to the processes, teaching me the tools and giving me the opportunity to form opinions and values concerning my craft.
I started using the divide and conquer approach across all the development process and changed my way of thinking to be much more logical and detail-oriented. I learned how to benefit from and contribute to a company culture that empowers people to build up expertise. I started to embrace the impact given to me via code reviews.
Becoming a developer asks for much more than passing down props to the child component or picking the right key that uniquely defines a list item. Sometimes it is overwhelming, but — and this is my advice to anyone who starts to code — whenever we feel like there is too much we don't know, we should not give up but instead keep an eye on the complementary skills we are continually refining. Not every progress is rendered via hot-reload — once we gained this confidence, we only need a little bit of luck with our environment ;) I am thankful to every one of the smartive team for sharing some smartness and very glad to keep growing as a permanent member of the team!
