After writing the article My Software Engineer Roadmap
I was confronted with a set of questions, that wrapped up, translate into:
“But then again, how to become a successful Software Engineer? So many topcs…where to start?”
This is more than fair. If I tried to put up the what in a structured way, in the previous article, then I clearly see the void on the how to do it if you are new to the Software Engineering world and there is so many to tackle.
I have experienced this struggle many times in my professional life. Might have been because I thought from daily work my learning opportunities were close to 0, or because I was overwhelmed with so many topics I needed to tackle from scratch, or the project was so demanding I entered work/rest/repeat mode and did not had the energy to invest in additional digging outside work.
So, having experienced different strategies, some that worked better than other, I will leave here how I see this. What can be an effective way to make sure each step of the path, that you take, is a useful one in order to increase your value as a Software Engineer.
“Try not to become a man of success, but rather try to become a man of value.” Albert Einstein
There is no way around this! We spend so so many hours working, that if we can make it a learning opportunity, every time, we cannot but go on the next step of the ladder.
Many times we don’t fully control what lands on our plate, but whatever it is, make sure you see what is the learning you can get from it. Even if your task does not give you the opportunity to apply it in full scale, make sure you know what you are doing in the biggest depth you can. And you will end up with the knowledge for next time you can contribute to your team and your project with that knowledge and insight. So here are some suggestion on how to do it.
If you are applying any development principle or methodology, why not go deeper and bring more light into it? If it is something that you are new at, for example you are in your first Agile project, go and checkout the basic, for example checkout the scrum guide. If it is something that I already know, usually, I try to catch what is it that it is always coming into my mind as a doubt or something that I believe could be done in a different way, and then go deeper on that path. For me, a few months ago was checking out Nexus and SAFe for scalability of Agile, as I saw Agile being applied over and over again to projects, being a project of 1 team or 5 teams, the same way.
Make sure that, whatever software you are working on, you have a good overview of it. So that you don’t end up working on a very limited box made by the lines of code that are part of the next bug that is assigned to you. Make sure you know what is the architecture behind what you are working on. The technologies. The integration landscape. The protocols being used. The infrastructure. The CI/CD pipelines . The quality gates. Testing strategy and technologies associated. The development process…And the whys behind it. Might even be historical ones. But from the decisions took, you can always learn. And make use of it in the future. Even if you don’t understand it all at first. Don’t worry. Keep pushing. You will notice, that as you go, your questions will also evolve. You will notice that at first you don’t really know what you don’t know. But then you might be given an insight with some additional details, that you didn’t knew to ask for, but now you do. And for the concepts that are foreign to you, take the time to understand them!
For the technology being used, go and search sources for best practices on it. If it is an implementation, test cases, automatic tests, if it is some part of the building process, orchestration, deployment…whatever it is, there will be a good change there will be articles, repositories, resources or considerations on what could be a good approach to it or even alternatives. For example, if you are doing some small bugfixing in a backend with node.js, go and check Node.js Best Practices. Even if you are not going to do a full refactor of the code after that, you have gained knowledge on what is the way to go, building your view on it, and you already are building your go to resources for when needed.
Might be that you are doing some bugfixing or doing a new feature from scratch. Either way, if you are coding, ask yourself: is it that the problem that I am trying to solve might be that someone else already gave good thought about it? There might be a design patter that answers your questions. A data structure in the language you are implementing at, that is performance wise suitable for the search algorithm you need, and included for such purposes. There might even be a library that you can include in your project that optimises the business logic that you need to implement (be aware of the license). So this is a good opportunity, to know your design patterns, data structures and algorithms and do a check on the language you are working on to see the latest features.
Over all this process, might be reading an article, going through a piece of code…turn on your critical mind. Not in a judgemental way, but in a constructive way. From what you know so far what do you agree and what do you disagree? And why? What would you do differently? Go check other sources. Try out a small implementation or project to prove the concept in discussion and your point of view. I say this, because, sometimes, when we are the new guys on the block, we tend to shut down our mind and follow whom we think has more expertise. And, it is important to keep in mind that we have our contribution to give. And from questioning I believe comes the most solid knowledge. And as we go on the road, also it is important to be open to other views and opinions and let our critical mind be and instrument of communication with others.
If you are lucky enough to be in an environment where pair programming is promoted, code reviews are really taken as an opportunity to share views and learn, where the success of one is the success of the team, the latest software methodologies have space to be discussed and innovation corners give opportunity to try out new technologies…well this will have a great impact in your path as a Software Engineer. As being in an environment that breaths technology, quality in the process, innovation, discussion, has really this effect of putting traction on your path.
But no worries, if it is not the case, find one colleague, a group of colleagues, from the same company, outside the company, in person, virtual (go check https://www.meetup.com/ lots of groups on different topics)…don’t care! Go find people that are on the same line of though as you, of wanting to grow, learn, to be the best Software Engineer there is!
Again this has a great effect! All of a sudden, not only you have someone else, that also shares with you the latest article he landed his eyes on, so your efforts are multiplied, but at the end of the day also it is so much fun.
Choose a subject that really interests you. But for real. For whatever reason. And go for it! Might be something you are dealing at work and you want to know more, or even a completely different subject and invest your time on it!
If you are into security, take your time and prepare for yourself for any Hacking competition.
If there isn’t anything at the moment that is catching your eye, let it be! Don’t make this an obligation upon you! And don’t worry. It will came to you.
“Luck Is What Happens When Preparation Meets Opportunity” Seneca
To finalise, you never really know what up in the road will make a difference! What I know for sure, is if you make the most out of your daily work, environment and keep a curios mind, this will for sure make you a successful Software Engineer!