To Be Everywhere Is to Be Nowhere  — Seneca

When I was studying in Canada, during a self-presentation explaining what I do for a living after finishing it, an uncomfortable silence came up, and someone in the background asked louder, 'WTF do you do?' It was funny but though at the same time. Since that day when the draft of this article was written, it took until today to finish.

In high school, I used to write scripts, trying to make things work better. It was just me playing with a computer like in old hacking movies. I never thought that being a software developer would imply not only coding skills or writing new code but also soft skills. Even in the early years of university, I still had this thought

The transition from spending a lot of time writing new code to engaging in other activities, such as refactoring, dedicating months to validate a new warehouse technology, exploring new event-driven architecture approaches, and participating in code reviews happen so fast you have to learn all these things on the fly (while support from courses and university is ok, it's not enough). Therefore, being a software developer is basically being an eternal student, constantly experimenting, and playing with code.

This article is a brief overview of what a Software Developer does these days, sharing suggestions on how to handle diferent situations

Making things happen

The same technology that simplifies life by providing more functions in each device also complicates life by making the device harder to learn, harder to use. This is the paradox of technology.
- Donald Norman, The Design of Everyday Things (1988)

Make things happen means getting things done. However one of the more challenging things to do as a software developer is dealing with problems from scratch because going from a problem to a final solution involves having different approaches and discussions on the fly (crazy discussions). These kinds of challenges are usually assigned to software developers as a trust in their skills, making them a bit uncomfortable (pushing them out of their comfort zone). Nevertheless, it creates the correct environment to grow fast. In order to finish successfully, these challenges, there are some steps that can be followed:

  • Planning: How to organize the next steps, who will you contact to give you enough context, where you can start, how much time you have. It is important to start before even the task arrive (request be invited to every meeting related)
  • Testing, fails and measure: Most of the software engineering is about trial and error.  Don't just come to discussions with theories, go and test, run some use cases, make sure that the theories are tested(don't trust just a comment in blogs or docs). Known the limitations about each option, become an expert fast.
  • Supporting in coworkers: Many new problems are problems that someone has already approached at some point, but it just was not resolved (technical debt). Finding support in them will make your life much easier
  • Focus in the problem, no in the solutions:In the road, there will be a lot of suggestions, proposals, and probably some solutions on the desks. Stick with the problem, challenge it, and choose the best solution avoiding cognitive bias
  • Implement the final solution step by step: Technological changes are always disruptive. Make sure that the strategy is based on an approach step by step, either if it is a migration or a new solution. Ensure the implementation will not block other teams, so make sure that everyone is onboard and always have a rollback button ready because engineering is unpredictable as well the universe.

Dealing with complexity

if you don’t end up regretting your early technology decisions, you probably overengineered

Dealing with complexity is an essential part of being an engineer. Divide and conqueror is one popular way used to approach problems; it is a simple method used to resolve complex puzzles not just at the code level but also at the management level. Another popular way to approach problems is using design patterns, which are solutions to repeatedly or commonly encountered problems in software engineering.

All of them can be considered 'good practices' (it could be a completely different article about what is the definition of good practice). They are always welcome in whatever project you are working on, but dealing with complexity is about understanding what is the enough complexity needed; everything depends on the context, be aware about the domain complexity, and sidestep to overengineering

Using a bazooka to kill a fly is always a bad idea. Good practices in software development are concepts that we are still figuring out. 'Good enough,' 'keeping it simple,' and 'make it work' should be the phrases that will be so present in order to take technical decisions. A lot of projects fail because overengineering always ruins everything.


To be a good communicator you have to be a good listener

Effective communication is one of the most important skills not just as a professional but also as a human being, being able to articulate thoughts into words makes agreements much easier.

Software architecture is about decisions: choosing the best architecture, selecting design patterns, defining how APIs will communicate, and more. These decisions require different stages and one of them (maybe the most essential) is agreements, without agreements no one in the team can move forward (everyone is blocked). At this point, it is most about people that system, because this marks the beginning of a race to convince more coworkers

The art of convincing people to support your decisions require using different tools, Some people are stickler with courses; if they don't see a technolgy or archicture covered in a course, they may dismiss it. Others are ortodox with expirience; if a person have no exprience before with a technology, trying to implement they may not support it.  Then there are those who are enthusiastic about new technologies, and they are inclined to agree with anything involving the latest technology in the market. The list goes on but more important are the strategies that help to approach these situations:

  • Use books as refences in the presentations (if it is a book must be true)
  • Use videos to remark a point or to make your point stronger (preferably using speeches)
  • Using an article shared by famous companies, many big companies share their experiences on their blogs..
  • Draw on personal experience, supporting in story telling strategies

The learning road never ends. The strategies listed below require constant learning, reading, and staying informed about different strategies, methodologies, and technologies. Each of these sources of information help to developing intuition, thereby improving one's ability to articulate in professional conversations.

Code review

It's easy to hate code you didn't write, without an understanding of the context in which it was written.
Figure 1: code review; got from

Code review is an important process centered around feedback. knowing how to give feedback is a key skill that nearly every software developer should have. The following are important  points that could help at the moment to review a PR:

  • Context: it is crucial to know the decisions behind  the implementations. Usually, working in pair programming saves a lot of time in arguments in pull request because choosing one approach over another, frequently is guided by decision made before.
  • Architecture references: Understanding the architure base behind the project makes aggrements much easier. When the team is allinged with  the architecture used in the project, the code tends to be more understandable and easy to locate.
  • Acceptance citiries: As a code reviewer, it is important to know the non-negotiable requirements. The reason is that there could be situations where some technical debt is acceptable, but always keeping in mind that it should be addressed at some point.
  • How the feedback is given: Whether it's via comments or in a call, feedback has to be given in a kind way. Usually, I always back up my comments with well-known articles or references, emphasizing my points and trying to find agreements based on facts. Respectful feedback is key, not just to help your coworkers grow but also to help you learn and change your opinion if necessary.

Collaborative Work

Short-term gain, long-term pain

Working in full sync with other teams is much easier in small to medium-sized companies. This is mostly because these companies develop a culture where synchronization across engineering teams is an influential factor. I've experienced this culture, and the value is massive. When software developers can have a complete view of what is happening, they can bring the most significant value in their delivery, focusing on what matters and making the process easier.

A collaborative culture, as mentioned in this article, helps teams unblock as a value principle. It aids in avoiding bottlenecks with bureaucratic processes, accelerates the delivery process, and promotes better early feedback from each team. Certainly, a collaborative culture is something that should be promoted as part of the values of companies. Not all of them may see the value at first glance, but as a software developer, there are strategies to use to help make this culture more common:

  • Ask others teams what they are doing, have short call, ask questions give them opinions and suggestions
  • Try to help when they have a block, sticking with bugs or some tricky errors, take some time hands on doing pair programming
  • Frequent meets to share no just knowledge but also ideas, improvements, help them avoid reinventing the wheel (if your team already have a library or piece of code share it)

It is hardest to do follow-ups between all the teams and even harder in companies that don't promote this culture; therefore, start small, bring value fast, and make a proposal to promote this culture at other levels. There are success examples such as Stripe, Meta, LinkedIn, etc.


if you’re just using your engineers to code, you’re only getting about half their value.

Being able to understand code is undoubtedly the most important skill as a software developer. As time goes by, coding evolves, it's not just about writing new code anymore. It involves removing code, refactoring, supporting old code, and fixing bugs. Most of the time, things are on fire, not because of bad practices but due to new changes, estimations, and integrations. This is what makes software development beautiful. Every sprint marks a new milestone, and then ten more challenges arise, and the game start again it is  an infinite loop of challenges. The sensation of seeing the final work finished is close to the feeling an artist has when exhibiting their completed work to the world.