Having a growth mindset is crucial for reinventing ourselves in different realities. However, this can also lead us toward the darker side of perfectionism.

As with many aspects of life, it is impossible to have something perfect in software development. Therefore, I try to maintain the sense of living in what some people call a beta version, acknowledging that there will always be something to improve.

One of the main processes affected by perfectionism is delivery. How many times have you waited until everything is ready to be pushed to production, instead of admitting that some things don't work as expected? From a different perspective, if we can let go of perfectionism, we can start delivering value incrementally.

Without going any further, something like this happened to me while developing this website I wanted it to be “perfect”.

I started to work on things that weren’t necessary, and at some point, a friend of mine told me just to put it there and that I will eventually evolve into something better for my expected audience. I must admit he was right, my fears and perfectionism were holding me down, and then nothing bad happened.

Waiting for the ideal moment and the perfect product is one of the main reasons behind procrastination. As a side effect, we can also encounter the named analysis paralysis, which is the result of making a decision due to overthinking a problem, where analysis of the pro and cons, basically leads to procrastination.

Keeping this in balance is probably one of the underestimated skills that I have developed and improved more over the years.

From my personal perspective, as a practical or pragmatic person, I tend to avoid getting myself trapped in processes and endless discussions. Not saying they are pointless, but sometimes we rely on this resource to fix doubts that include more than one person.

The drawback of this characteristic is that I sometimes overuse the ability to take shortcuts.

It’s difficult to draw the line between going fully practical and covering everything at once. The clue is that we can iterate, but that shouldn’t be an excuse for skipping the plans or procedures.

One thing that I try to remember to avoid going super pragmatic mode is to keep what I consider high standards before I consider something ready or done.

Clinical and critical eyes to analyze the details is a very good skill to have, but not if you are using it all the time. Not every decision needs to be deeply discussed. Otherwise, getting into the rabbit hole of a problem would be the norm.

One of the things that experience gives you, rather than technical skills, is the ability to pick your battles on getting deeper into a subject that in the end has zero impact on the end goal.

To put it into an example, Imagine that we are refining a new feature to be released, but we keep on postponing the release due to different challenges we get from a team member pretending to be ready and preventing every edge case. In the long haul, this will translate into demotivation and a lack of value delivered.

Turn the wasting time about possible scenarios or users’ behaviors based on assumptions, into investing time in matters such as the way of delivering, analyzing, and deciding on actual data.

Introspections are one of the ideas and practices that emerged with age and helped me better understand that the dreams I was chasing were not actually mine.

A bit cliché, but we only live once. For years I have pursued what I was convinced was my dream job, and I ended up realizing that I was following other people’s dreams.

I can’t blame anyone but myself. The social pressure and the fact that I needed to prove that I was capable of achieving something on my own, are some of the conclusions I usually get when reflecting on this.

As I have already shared in other posts, every time I am asked for advice by junior developers or anyone starting a career in IT, it is to live your life and not someone else's.

Nowadays with the overload of information and uncontrolled toxicity in social media, it’s quite easy to get confused. It personally took me years to realize that I was fighting to get something I never wanted.

Having a freeze or controlled use of social media, and avoiding putting other people's opinions on top of mine (just because they have thousands of followers) were important remarks to keep my mind under control. Living on my own without a script of life designed by someone else.

Finding people to refer to or to get inspiration is a useful resource, but we most probably have no idea about their inner fights or goals. From a different perspective having references to fight social conventions would help to promote diversity and inclusion.

Looking back to when I started my career, I just wanted to be recognized for my work but it was just a reflection of my childhood, full of insecurities, which my defense mechanism turn into proving that I was capable of reaching “success” on my own.

It’s proven that comparison can be our driver and makes us envy what others are living.

The book Big feelings (probably the best book I read in 2022) introduced me to this concept and taught me about the two sides of comparisons.

These are a few takeaways and my favorite parts:

We always compare our inner self with the exterior of others.

Comparisons can teach us what matters to us, and what are our core values.

Envy for the success of others can inspire us or reveal which are our real interests, so envy is not always necessarily bad.

Self-comparison with an old you can highlight your progress and evolution.

When trying to change or learn anything from scratch, avoid comparing it with the best or top talent in that area.

From the outside only the success is visible but how we get there is invisible and ignored.

Being ambitious is good as we always need the motivation to turn an idea into something real, but it can also lead us to burnout and lose the focus of our core values and objectives in life.

As someone who was instructed to build performant and robust software, and to think about every detail of a solution, I struggle to limit that to work and not to extrapolate it to my daily life.

Putting my ego aside and not trying to convert myself into my own piece of software is just hard.

With time to process information, reading books and blogs, taking courses, and experiences in general, I learned to have a quiet life, and enjoy other things outside work.

My stress levels are slowly going down, I have now a feeling of self-control, plus I mastered celebrating the success of others, and how much it motivates me. Funny enough, my productivity gets better as I get more energy when getting back to working hours.

Basically not wait until I get retired to start enjoying.

Although frustration and getting into that was part of what I consider my learnings, some of those stressful situations could have been avoided. Which I expect to be the most important takeaway to whoever reads this post.

The thing is, that feeling of chasing something in particular never ends, kind of a hamster in a wheel. So we have to learn to deal with that feeling all the time.

Challenging my network among other things like introducing habits such as reading and writing, and limiting others like social media, were what produced this change in me.

I have no idea when I started to “work” on this but I believe it was something that came up as a side effect of the pandemic, where, like most people, I faced something unexpected and unprecedented.

Things like filtering my Twitter feed by muting words and blocking particular accounts, reducing the amount of exposure on social media, or even stopping entering into endless discussions on Reddit, were activities that enhanced my wellness, making me more relaxed and avoiding falling into meeting standards that I don’t even believe in.

So I went through that introspection about belonging which has helped me to focus on people that I actually care about, and make me feel like they care about me too.

Months after going through this process, I was told that I was lucky with the friends I have and the network I have. And as with many things in life, this ain’t luck! I worked hard on this to make me feel peaceful.

One of the benefits of working in product companies is watching your product evolve, nevertheless, that road won’t be only a matter of innovation but avoid things turning into impossible to mature legacy systems.

One of my favorite references to the term I came across, which also motivated me to write about this, is from a book called “Kill it with fire” which I truly recommend.

“To understand legacy systems, you have to be able to define how the initial requirements were determined. You have to excavate an entire thought process and figure out what the trade-offs look like now that the options are different. Simply being old is not enough to make something legacy.”

The reality of the moment something was created doesn’t mean we have to carry on all the decisions when making a refactor or an upgrade, as the definition says tradeoffs might take a different path depending on newer contexts.

Modernizing technology for the sake of using something newer can be mistakenly confused as a way of dealing with legacy systems.

Defining which part of our solution needs to be evolved is where the puzzle is. Switching product A to a newer technology doesn’t mean it will be easy to adapt to the new reality.

I have seen this situation happening in places where a framework is introduced as a result of a partnership or just because it’s trending.

Although it can have drawbacks, using a well-known framework can also have benefits, as, it will make it easier to get new people on board. Imagine that if we have to still provide support to an old system that developers are unlikely to find, we might end up blocked.

As part of the previous point, we need to identify and scope as small as possible which is the part that needs to modernize.

Things like refactors and revisiting past decisions, and old vs new requirements can become crucial in the way we define the parts that are considered legacy against just old but functional.

Having deprecation policies will help us in regard to communication with our customers or consumers. It will make innovation and migration a lot easier to handle.

We have to make people aware of the change by explaining, not turning this into a revolutionary change, provide context and data on which we based our decisions.

There was a time I worked on a project that involved convincing people to move to a mono-repo setup and it was quite important to emphasize the communication of it, explaining the reasons behind the change, in order to have everyone onboard by understanding the reasons and not only the technology implications.

Communication is key, in preaching the idea and the people that might be affected by any change we would like to introduce. Speaking a common language to convince stakeholders what needs to be done, will play an important role in the whole process.

How often have you heard the phrase: “it has to work like this”?

In situations like this, where requirements are not set, and by looking at the code it’s tricky to abstract the decisions that were made while that was developed.

Moreover, as we cannot understand the context and historical decisions, is quite easy to drag errors or mistakes that were made back then and pull them into the new solution.

After going through this situation a few times, I try to remind myself to write conclusions and decisions that I have made when developing something. Rather than putting documentation that can be seen in the code, I focus on context. So that if someone is reading my code plus reads the story I tell, it will be much easier to avoid mistakes.

The same concept applies when submitting solutions for take-home type of code challenges in technical interviews. It will help the interviewer to understand my way of thinking and the tradeoffs I have to consider while thinking about the future, which could be completely wrong. But in a situation where the future is unknown and requirements are vague, it’s completely valid.

One of the things that people tend to forget when dealing with this situation is institutional knowledge (also known as institutional memory), and how tight these decisions of evolving a legacy are to the process and the culture of the company.

Having people who are long committed to the company culture, and have been working there for several years in multiple positions, will help to move the process easier.

As you can imagine in places with low retention and high attrition, having people leaving constantly will cause the institutional knowledge to be gone. Thus, having discussions or defining processes to move legacy systems would be more difficult to structure and move forward.

A bit related to institutional knowledge, there are cases where evolving something legacy affects the shape of the organization as well.

Coupled software tends to be by definition, more complex to maintain, difficult to test and scale, and hard to adapt to new situations, among other technical advantages, but from a business and strategical perspective keeping the parts decoupled can benefit from outsourcing part of our solution, to name one example.

Let's imagine we have an e-commerce website, and we have our custom in-house logging system if that was coupled or de-coupled, it can make the transition to external solutions simpler or more complex.

Hola, welcome to my safe space!

Latest articles

The dark side of perfectionism

Chasing my dream job

Evolving the Legacy