Software Engineer Life Retrospective

Hi, my name is Rodrigo, and I’m here today to talk a little about my life, personal and career. Hope that some of the content that I’m going to share here helps you. This is some sort of journal where I share some of my experiences and opinions considering all the things that I live in the software development field. The content is like a lot of information in one place so read as you see fit, also, the text contains some highly opinionated subjects, about what is a software engineer, or what makes a good software engineer.

I did start my developer career 5 or 6 years ago with mobile development, and at this time I learn that working with software can be great and awful at the same time, like all the careers, right? But let’s not be ungrateful, being a software engineer provides you some good feelings when you create something, and you see that working and helping others gives you an amazing moment, even in the tiny things like seeing an algorithm that you learn working it is great. With time those moments of joy start to get more selected, but in the end if you like to code you will be happy just to implement a simple task.

Starting from the beginning

College degree … I can not say that to work as a software developer you need a degree in CS (Computer Science) or some related course, for sure everything that you learn there you can lean alone and for free, but what can I say is, a lot of companies today still demand a degree, so it is up to you the decision, I have one, and for me was more important the experience that I get than the knowledge, experience I mean the jobs/trainee offers and the friendship (network) that I build, without the college I do not know if today I would be working with software development. The first time that I code something was in college, that time was simple but was sufficient to decide which field I was going to pursue.

College also offers you the chance of trainee opportunities that for who is starting is significant, to have several trainees experience, this will help you to decide if you want to work with this, and if not which area that you want. It also provides you time to keep studying while you put your knowledge into practice. Trainee jobs are not all flowers, so you should consider trying a real job opportunity after some time.

Being different

Being a good software engineer as they commonly named today, you have some responsibilities in your daily work time:

Being a great team player: Helping others or asking for help when you need;
Keeping up: You should never settle, we always have new things to learn and practice, so do not stop;
Watching close: Today we have a lot of platforms that help you to have a close look at the software that you are developing, how can you say if it is working if you do not measure (with logs, analytics, and …)?;
A master planner: You need to organize yourself, in your daily work routine you have refactors to make (code improvements), analysis in the current project and future implementations, prepare new features that are coming (how we’re going to do it, when, and, …);
Being the change agent: Sometimes we found ourselves in places that are running with the same rules for a lot of time, but as we come from others background (the importance of having different experiences in your career), you can propose changes and even if it is not a valid proposal only the fact of trying worth it, in other words, the innovation guy.

Also …

The problem guy: You need to provide solutions for problems, but not only throw solutions at the table (like a brainstorm) for all the problems that you face, you should consider all the information that you have and use your experience to make the best decision to solve the current problem, and this does not mean that you will implement the best pattern or use the best architecture, normally when you are studying you see people saying that you need to decide wherever you should use something, they are talking about this, have the experience and the knowledge to decide what or when you use the strategy pattern for example. In some cases, like a startup, we use strategies like:

Build (Experiments) → Measure (Metrics) → Learn (Pivot / Persevere)

The market is always changing and sometimes the cost of developing something big could lead your product to lose the moment for that market and so on … What I’m trying to say is, being a good developer does not mean knowing all the design patterns, architectures, languages, or technologies (this too, of course, you can not drive a car without knowing how to drive).

You need to be a versatile person, learn about design techniques, and have an insight into UX/UI, today every application must worry about UX/UI because we have a lot of applications that do the same thing for example and having good usability you can get new users even being smaller than others, and for mobile applications what defines if someone will download your app is if they like what they see on the stores, so it is important to think on the user always.

Learn about agile, agile goes straight with what I said before about, your company losing the time of one opportunity, you should build small things test, and deploy. Test and deploy have several interpretations and different moments, it is not that you will always build the simplest implementation, with experience you will be able to build something ready to scale and that fits your current problem (refactoring it is a significant process on the project lifecycle, and it is here to be used), so you should learn about a project lifecycle and how to continue improving it, without needing to rebuild or passing through hard times if you need to constantly or periodically change it.

Your project must be specific to the problem to be solved, but also generic enough to meet future problems and requirements. GOF.

One good definition of a software engineer, you get paid to maintain the software most of the time, not to build a new one.

So being a developer is much more than open an IDE and code something, today the market is full of professionals (good and bad ones), so it’s up to you to stand up from all of them being a versatile person.

Seniority

One way to define the seniority level of someone it is with his versatility and experience, you can be a senior developer with few years, the hard part it is up to you, study, practice, share … But you need to put this knowledge to work because read about implementing a clean architecture with MVVM is something, and implement it successfully is something completely different (for example), so my advice, you should never stop the learning process, every day we have new languages, new patterns, new algorithms… Keep up with the market and put those new things that you learn into practice, create clone projects (from a simple one to a big one), work on freelancer projects (you can receive money while you learn), create personal projects (even if you will earn 0 dollars with it, portfolio means more).

Still, in the seniority subject, it is important to impact other areas than the area that you work because doing this you can help other teams, the product, and you to grow up. For example, being a mobile developer, it is significant to know how the backend process work, so when you are defining a contract you know what they can do or not, and the same works for them, normally we have lots of areas in a company that you can contribute with, start to attend meetings of them and see with what you can help. Experience and knowledge are always welcome, I’m sure that they will appreciate your help.

Complementing the seniority level, you should always look forward to the quality of what you are developing, work with tests, unit, integration, UI, and several others. Tests help us to identify bugs and make sure that the code behaviour will be always the same even if you change a part of the code. Unit tests are the base of a solid project, without them, you can not guarantee your business logic. Do not wait for the QA team to validate your tasks, it is your responsibility to make sure that IT IS DONE because sometimes bugs can pass through the QA process and reach final users, or the QA team catch the bug and return to you (time lost), so take your time, plan how you’re going to do the task, plan how you’re going to test the task, and after everything is ready, you go to the next one. Today, we have a lot of processes that help us to ensure that the software is ready for production and has quality. One of them is CI/CD’s (continuous integration / continuous delivery) to automatize the process of versions and deploys, reducing developer time lost, ensuring also code quality running lints, running tests before merges, and so on. If you do not have those in your project, you should consider having one.

The process of developing something can have some moments of imagination blocks, in other words, you are trying to do something, but you can not figure out how to do it, my advice, stop what you are doing and go do something else, the solution will come at some point, it is common you stop working and when you are taking a shower or getting ready to sleep, you have an aha moment, and figure out how to do or fix the problem.

What a said about seniority levels can not be considered as final words, what I tried to say is, being a versatile person is one way to differentiate yourself from the others, and as the market grows we have a lot of competition.

Personal

Everyone has his life, and it’s routine, to be constantly learning and improving your skills you should create a plan to keep up with the market, plan to read books, attend classes, create personal development plans with deadlines, this is important because without measuring you can not say if t is working or not, or you are growing or not. I believe that every field of technology today has one road map with the learning paths that helps you to understand what you need to learn to master it. Also look for design patterns, architectures types, the different development processes, data structure algorithms … We also have books to become a better developer, like Clean code, clean coder … Books are a great font of knowledge because most of the people that write them, have a lot to share (I love books ❤️).

One good thing that you can do that will grow your knowledge fast is code challenges, as a software engineer your primary role is to solve problems, so the more you do, the better you are, we have several online platforms that help you with different kind of problems (Big companies like FANG (Facebook, Amazon …), will ask you to solve some of them on the interview process ;).

One important thing to develop yourself as a person and as a developer is, to share content with otters, as medium posts, YouTube videos, meetups, or any kind of sharing content thing, doing that you are helping more people to learn and become better developers, and also creating a sort of notoriety for you, so every time that someone needs help with some subject they will look for you. You do not need to be a master in something to share content, even the simplest things can help someone.

Problems

Unfortunately or not (depends on the type of person) our field has a lot of unnecessary pressions and that depends, there are a lot of things that cause them, like people that do not know what they want, they send us some tasks, and after we finish all the process they say, oh no! It is not what I want … (Really?). So you need to be ready for problems like this, I’m not telling that this is right or that you should accept it or even that every place is like this, but in most cases, you will not be able to change it, so you need to be resilient and a professional to work out those problems.

In a team, we have a lot of types of people, and sometimes you find great people or not, so this is like life, you need to learn how to manage people, and how to work with them, we tech guys normally say that we choose this field because we do not like people and working with computers we will not need them, but saying this is wrong because even when we do not like someone we could need them especially working as a team, as I said before one of the rules of a software engineer is to solve problems, and working as a team do this it is a lot easier. So work on your soft skills and learns to work in different environments and with different kinds of persons because sometimes can be challenging.

As a member of the team, you need to communicate your problems and insatisfaction, otherwise, no one will know what you are thinking, and this can lead to misinterpretations of your actions (people think that you are lazy or do not have purposes), also, you need to be constantly talking with everyone to align what you are doing, if you are blocked with something, and you require help, it does not make sense you lose a lot of time with some tasks that someone can help you, so learn how to ask for help (Of course help is always good, but you should at least try it first right?), or someone needs your help, but they do not ask for it, what does it cost to you ask them if you can help with something? Regardless of the insatisfactions of your job, we can say that in some cases they will not listen to you, and that goes too for seeing you (you are doing a great job, making difference, growing like a rocket, but zero recognition), it is common they only see that when you receive a better offer, and you say that you are leaving the company, most of the cases this is something that it is intrinsic on the company culture and change that it is hard, so it is up to you decide if worth stay, help and wait to change the things or leave and take the risk of being on other company with the same problems (so that’s why you need to choose wisely job offers, otherwise you’re going to change rocks for rocks).

Speaking of issues, sometimes we receive bugs or unknown behaviours (bugs what the heck), to analyze and fix it, the base principle to resolve an issue is first to understand why and how the issue is happening, and only after that you should try to fix it, it is commonly you see issues that are fixed and sometime later they come back, this can mean that your project lacks tests or and your project architecture is flawless, also that you made a fix that only cloak the issue. Following the (ensure the project quality), make sure when you are working on bug fix that you fix it, create test cases, running the application, passing through different scenarios. A bug that returns is always sadness…

I think that it, folks! I hope that this little mess that I wrote in here helps you with something in your software engineer career.

There are some concepts that I wrote in this article that I explain better in others articles, in case that you have interest to learn more: