Since yesterday was my last day on a project after four years and two months, I decided to take a look back on those four years and write down some of the things I learned.
Things I learned about being a better listener, a better communicator, a better team mate, a better programmer.
Leave your ego at the door
This is probably one of the hardest and most important lessons I learned. I’m happy that I learned it early into the project.
Ego gets into the way of the actual programming. There is no place for it. People get defensive about their code, become deaf to advice, don’t take criticism well. This slows down the development process, makes communicating difficult, if not impossible.
Criticism of my code is not criticism of me. If I submit a pull request and the reviewer deems the code not fit for inclusion into the project, there is nothing to get upset about. The code needs improvement. If I know how, I’ll improve it, if not, I’ll ask for help how. It is much better and efficient than getting all protective about the code.
Don’t play the blame game
Removing the blame from the entire process is liberating. When dealing with a problem, don’t focus on trying to find the person, or persons, responsible for the issue at hand, but try to understand what caused the problem, what is the best and fastest way to solve it, and how to prevent it from happening again in the future.
I know I was lucky to be working on a project where this blame game was not being played and that there are a lot of teams and companies where there’s a ton of office politics and everyone wants to survive… But that stuff really isn’t helping any one. If possible, at least try to not play it within your team, with your closest coworkers.
Admitting to a mistake is hard. It’s scary.
Admitting first to myself that I’m not infallible, that mistakes happen makes taking responsibility a lot easier. And it becomes easier over time.
I believe that people tend to react positively to sincerity. Being honest and upfront that I made a mistake, saying sorry, goes a long way. Yes, the mistake might have repercussions, but I’m an adult and I stand by what I did.
Taking responsibility is the professional thing to do.
It’s OK to say I don’t know
I don’t know.
I’ve said it a lot. I’m still here, still alive, the world didn’t come to an end. No one punished me for it. The only thing that happened is that I learned new things I didn’t know before. And guess what? Learning new things is part of the job.
Saying “I don’t know, can you show me please?” is perfectly fine. If we ask for help, we will get it. People like helping.
Knowing the business domain is important
We, programmers, are a smart bunch of people. We solve problems for a living. Without knowing what is the actual problem the business is trying to solve and just waiting for others to give us a solution which we need to translate into code, takes away the problem solving for which we initially signed up for. The business will also miss out on properly utilizing the experience we gained so far.
Understanding the core domain makes it possible to give ideas, work together with other people (not necessarily programmers) to come up with better solutions. Everyone will benefit from this. The business gains by having yet another smart person helping out, and you by learning new things.
Not everything we learn need to be exclusively about code.
This goes hand in hand with knowing the business domain.
Keep asking why. Why is some new feature being implemented, why do they need it? If you are joining a project that is being developed for some time, ask why were some things done in a certain way. It will both make learning the business domain easier and faster and it will also help with getting to know the codebase.
Asking why shows the business owners that you care, and caring about the same things as they do will only be helpful during the project’s lifetime. They will provide help and explanations much easier.
Onto new adventures
Working on this huge project for this long is something I’m truly grateful for. Not everyone gets an opportunity like this, especially this early in their professional career.
I’m certain the new year will bring us exciting new challenges. If you have, or know of a project where the three of us could help out, let us know.
The Code4Hire team is here to help.