Here are the five most important lessons learned in software throughout the path to become a Project Manager. These, in particular, have helped me to survive in the software dev industry. 

The other day I was listening to a podcast on .Net Rocks! about Clean Architecture and at some point, the speakers started talking about those mistakes they had made during their software engineering career and therefore, the elements to consider to avoid them.

That situation made me think about what those lessons I have learned throughout my software professional career and what I need to continue learning. Here is a list with the five lessons I think are the most important to take into account.

1. Listen to the technical leaders but always question why decisions are made

Coworkers with more experience and knowledge (senior developers or architects) become those hidden coaches that teach us the craft. Thanks to that, and along with their understanding about the business and the industry, they can show us the best tips to do something specific in less time without sacrificing quality.

A while ago, when I was a Junior developer, I was struggling with Entity Framework to make it perform better by modifying my model and how I query it. Since the query was doing a lot, the Senior developer showed me how to use ado.net, and he explained why that was the best option at that time. That saved me countless hours.

What I learned from this experience is to ask the why when you don’t know.

On the other side of the coin, we need to avoid habits or confusing circumstances like when we stop asking and just follow a pattern on the code without really understanding it. A while back, we had a Junior developer that recognized a single way to handle errors in one small project and later applied it to a bigger project with unexpected consequences. He was a bit upset when we reviewed the code and he had to remove part of it.

As a simple conclusion or advice, even if you see patterns in the code, ask why.

2. Plan your code before starting

You get together with your team to plan the work, create every task, and then you open your Integrated Development Environment (IDE) and start writing the code. Hours or days later, you figure out that you have missed non-functional requirements, or even worse, you have some of them wrong. This scenario has happened to everyone, even the most experienced engineers.

One day, we were discussing what we could possibly do to fix this problem, and we remembered our first years in university. We decided to start by doing the code planning. But what does this mean?

This means that before opening the IDE we should grab a pen and paper and design the coding solution, as well as decide which methods, variables, classes, and patterns are needed to accomplish the requirements. After that, we do a peer review, and later, it is just a matter of sitting down, playing good music, and coding.

After months of practicing this planning we noticed that we were saving time on development, developers were more aware of the changes needed, and we diminished the amount of rework and bugs.

Content related: How to become a code review master

3. Learning from those “old” projects

It is true that in every big project, no matter the type of company you work for, there is a chance that at any given time, we may need to fix a bug or add a small functionality to a forgotten or Legacy project.

My advice, aside from taking it easy –this can happen to anyone–, is to see this as a learning opportunity and a mind exercise. First, try to put yourself in the developers’ shoes and think about what they are trying to design, what the main objective of the technologies used is, and if there is something new we can use to replace those technologies.

Then, try to figure out the added value that is behind the project, how the users use that piece of code, even if it is in an indirect way. If there are concepts or areas of the business that you do not know and they are not essential to finish the changes, my advice is to ask about those concepts. Remember, knowledge does not hurt.

Finally, verify if all dependent code is still being used. Sometimes, old projects are migrated by parts but not cleaned up, such as in the “just in case” proverb.

4. To comment or not to comment… that’s the question

There is an ongoing, decades-long debate about comments and code. You may have heard phrases such as “Good code is self-documenting” or “Reading the code tells you exactly what it does”. I agree more with the last one; however, good or well-written code that follows good practices and clean code patterns is really easy to read and of course it never gets old. It could be obsolete but not old.

Furthermore, comments get old, and they could be misleading or have errors. Nonetheless, my advice is to use comments carefully and only for inconspicuous stuff or even show examples. Also, think of your future self when writing comments and code.

5. Understanding the app’s context vs the end user’s context

When starting a new functionality or a huge project, it is important to understand these two concepts. Let’s start by defining what a context and an end-user are. The Oxford English Dictionary defines context as “the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood” and defines the end-user as “the person who actually uses a particular product”.

This might be interesting: 3 common UX design challenges you must face in a software project

This is a great lesson I have learned throughout my professional career: in order to achieve a successful product, we need to understand not only what the user needs are, based on their capabilities and expectations, but what the context is in which that specific app will work. In my personal experience, this is where we, as developers and managers, can make the difference and stand out if we understand and keep those things visible every time we work.

In addition, from the developers’ point of view, we can try to make the solution easier, select the technologies that fit the changes and of course, detect possible inconsistencies in the requirements.

To Sum Up

In my experience, these have been the five most important lessons learned in software throughout my career and that have helped me to survive in the software dev industry. Fortunately, there will be more years ahead to keep learning.

For sure, we can’t forget to establish good communication with our partners, coworkers, and stakeholders, as well as to keep our eyes open on details, capitalize and seize the senior team members’ knowledge, and always remember the client is an ally and not an enemy.

Do not miss this: Communication in Agile Software Development… Does it matter?

Do you have any other great lessons learned to share with us?

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.