What the code says about the programmer

With this headline, I am not trying to stereotype programmers in general, but rather express in a few paragraphs my opinion on the reality I faced with my first professional project in the .NET. 

Lo que el código dice

My first coding experience was in college. I didn't start young as many of my colleagues did; quite the contrary, I felt like a genius at university when my first function returned a correct result on the screen. That's when I discovered I might become a programmer, although I had failed y first test.

The rest is history. Practicing made me an effective yet not an efficient programmer. Writing code only I could understand was maybe something I liked, but a habit I had to leave behind when I started my first professional project, where I learned that I knew nothing about what ''programming'' is.

Finding functions and methods that were longer than 50 lines was for me worthy of a hacker movie, so I would take my coworkers as professionals on the topic and focus on learning as much as I could about their activity, when they submitted their work for peer review. But as time went by, I found a certain pattern in my work. All of them were pitching in separate ideas that came together with a common goal: generating a high-quality, functional code that could be understood by the whole team.

I noticed that, depending on the task, the first thing to do was finding where in the project something similar was being applied at the time, not to ''steal'' code but to maintain a pattern when it came to implementing functionalities and being coherent with the overall technical solution.

That is why there may be standards to follow, but also personal style, and if said style is good, it spreads around the entire team. Additionally, if one is able to see positive things in others, sooner or later it ends up being adopted. This is where one can see the contribution of each stakeholder to a common goal of a functional, high-quality system, preventing the code from becoming illegible spaghetti.

I understand that each programmer, even subtly, leaves a personal footprint on each line they create. As a result, we can discover what type of coder they are, whether a rookie or an expert, a perfectionist or a pragmatist, if he or she follows the manual of good practices and leaves high-quality legible code so that other people can build on it, or if simply they create code that works but that may become obsolete very quickly.

Getting to know my environment made me understand the projects I work on more profoundly, and what's more important, gave me a different perspective on what is needed to be a good developer without losing the essence of what made me dive into this wonderful career.

Author:

Bernardo Ortiz.

.NET Developer at Baufest.

 

Contact Us

info@baufest.com