This month of July 2022 marked my first 5 years of professional experience as a software developer, I will be always grateful for doing the thing I started as a hobby in my room back in the day. During that period It has been a lot of learning, some of my beliefs have been reinforced or challenged and others needed to be re-learned to fit into the real world.
So here I will reflect on the lessons, my reinforced beliefs, and challenges.
Background.
Why software engineering?
I can say that my life split in two the day I discover how software is made being able to create something from text and dragging components from an editor. I would go to the lab doing the common programs for the class (calculators) and doing my little projects like a clone of the login and home of Facebook in Delphi back in the day.
From that year until 2017 I was just playing around with languages like C, C++, Java, and C# doing CLI programs for my classes or experiments just as a hobby until I learned decent English and met the programming languages of the web, made my first web application an sold it to a local ISP company.
My drivers were curiosity and the creative nature of software development but also the fact that I could create things to make other people's jobs easier, we are the support career by excellence.
Beliefs
Do Something you like
There’s a dilemma I hear constantly about if you need to have passion for your job or give the extra mile. I find more regarding doing something you like for work (if you have the opportunity to do it), as learning and progress will be something that you see as challenges.
- Discipline: It is easier to keep discipline by doing things you like rather than doing it just for the bag.
- Better to have rather than 2 days a month: If you are just happy on the paydays the other days must be like a prison.
Holistic Approach
Try to see the whole picture, even when you don't have to take part in the whole process to learn how it works. Product Owners, Project Managers, Scrum Masters, Designers, Backend Development, and Frontends whatever the position you are doing try to know the limits, the responsibilities of each other.
Being concerned about the value that every part of the team brings to the table, the effort makes you don't undervalue the Job of anybody, help where you can, and analyze better some technical details when it includes cross-teams effort.
Understand the business side of the project.
Challenges and Lessons
Beyond code
I am one of those who thinks that not everything that comes to mind needs to be told and it's ok to not have an opinion on everything (unless this is your Job)
There are a lot of no-code-related things we need to work on and learn
Communication: Be able to communicate effectively with the people involved in the product and clients is a multiplier. The most productive teams I have been on has been the ones that understand that the team is a single unit and we all are pushing to same goal and we need to back each other from the sales team, designers, back and frontend developers to testers.
Maybe this is one goal of every team but in practice it is a hard one specially when the pressure and deadlines are tight.
Documenting, Talking about the scope of a ticket between backend and frontend before writing any line of code, having a clear definition of ready before taking any ticket, defining guidelines for the projects, etc. are all good signs of an effective communication.
Processes: The value of retrospectives are underestimated sometimes but they are the key to improve the process in each iteration and are a good space to reflect and recognize the accomplishments of previous sprints. yet it seems like the first ceremony of scrum to be sacrificed in projects.
Business vs Tech: At the end of the day we are doing software for people to help them but also to get some revenue in most cases. As software developers, we need to know in what situations.
- Talk to buy time and do a better implementation if is a big important feature for the business
- The latest is not better, the best is what gets the job done
- When a business expectation is not realistic and needs to be broken.
Have an opinion but be realistic
At the beginning of my career, I used to dislike code challenges that weren’t a reflection of the day-to-day Job tasks, I still kind of dislike them but I am more open and in fact, prefer live coding rather than project assignments (because the latest requires more time and on top of that you have to explain while in the former you can explain and interact with an interviewer right there). I know it is not ideal but is the only tool they have to make sure they are going for the person they will pay.
I still need to do some improvements in the complex code, and FAANG-like coding challenges as I know I am not in a position of changing a standard you got to play by the rules of the game
Keeping feet on the ground
- Under-pressure: Software is a demanding field, as we are a support field working with information and giving service to users or working in the next big startups there are always deadlines, sometimes bugs on production, and changing markets. That means that pressure is something that we’ll be dealing with (hopefully not in extreme cases so much) even though the pressure is on the environment to understand the urgency.
- 100%, not 110%, 150%: Time is an asset that we don't recover. Rest is important, family is important so is important to set healthy limits and enjoy life the way you like. Don’t give your time and effort for free to people that just take but never give
- On trust (everything on paper) & stability: In Information security, there’s a say that the most vulnerable point of a system is people because we tend to trust people. In software having things jot down can save you a lot of time and effort. having the client requirements written, on email because words are easy to forget.
The best stability is to be prepared because everything can change and opportunities always come for those who are prepared.
Top comments (0)