5 Things I’ve Learned in my First 6 Months as a Software Engineer on a SCRUM Team.
TL;DR:
- Work with a purpose driven mindset.
- Follow intuition if reason agrees with it.
- Be intentional in the relationships with your coworkers and manager.
- Come with ideas.
- Respect the work life balance.
Work with a purpose driven mindset.
Albert Einstein coined insanity as doing the same thing repeatedly and expecting an alternate outcome. When I started working I dove into a language and framework I was unfamiliar with. I spent days attempting to integrate a couple of lines of code successfully. I would receive a ticket and immediately browse the description and start working. After a day or so my approach was not working, I would reluctantly try a different approach, and eventually after repeating this I succeeded at fixing the problem. Then a quick rush to make a PR, and, wait for it, destruction.
My PR and my trial and error work flow inhibited any sign of coherent and well thought out code. Although, in some situations my code solved the problem, but, it was never semantic and easy to read. This meant days of PR changes and corrections. Now repeat this for about 8 sprints, and you get the picture.
Working with a purpose driven mindset translates into having a direct goal with everything you are working on. So, when you get a ticket, enter the planning stage, understand the problem, draw it out, ask Senior Engineers whats going on (they like this because no one wants to be hounded at the end of the sprint on questions about understanding), and get a game plan. Then, its simple execution. Break your ticket it to reasonable chunks, and give yourself realistic goals for the day. You will be surprised how efficiently you will get things done and start to improve and refine your workflow.
Follow intuition if reason agrees with it.
One day toward the end of a sprint I had worked methodically and my tickets solution started to come together. Essentially to verify that my fix was working I needed to check the database to see a new row that was suppose to be made. But, I did not see the new row. I panicked and stared diving into the ECS logs and everything was readying success. So I spent hours trying to dig into containers with a Senior Engineer and nothing seemed odd. After about 4 hours of trial and error I knew I had done this correctly, and everything was pointing to a success, but, I instead assumed something I had written was wrong. My intuition told me I was right, and lo and behold the GUI for the database I was using only displays the first 500 entries, so I clicked the pagination and there were my rows that I do desperately wanted to see.
The moral of the story is I knew, or had a strong feeling, that my solution was correct, and that was verified by the logs. So, I should have immediately assumed it was a user error with how I was verifying the fix. If I had followed my intuition I would have seen the test was fixed and would have avoided a ticket carry over into a new sprint.
Follow you intuition, if you have a feeling that something is wrong outside of your code, ask for help and rubber duck. Following this intuition can save you and your team much time. But, intuition must be developed over time to enhance the natural intuition. Set a limit on being stuck, whether it is 15 minutes or another figure, just make sure you are not staring at a screen or throwing random ideas against the wall.
Be intentional with the relationships with your coworkers and manager.
Being in a SCRUM team means you need to communicate effectively to your coworkers. This won’t happen over night, believe me, I struggle daily with communicating problems and ideas, but, you wont get any better if you don’t try. Listen to your coworkers and their thoughts and ideas, because emulation and listening is the key to getting better at this. The more you know and are comfortable with your coworkers, the easier and more efficiently y’all will work together (yes I am from Texas).
Now getting to know your manager is important because it will make taking constructive criticism easier as well as open a comfortable dialog with the person that reports on you to the higher ups. It can be hard to have pay or time off conversations with your manager, but again, the more you talk and listen to them, the easier and more effective communicators you both become. Understand that your manager has little to no time, so it is up to you to make the first move to schedule a meeting and if you need or want something you will have to ask for it.
Come with ideas.
Part of being a Software Engineer is being a problem solver. That means you are always seeking not only ways to solve a known problem, but its also discovering problems that have not been found, or ones that could arise based on a design and coding decision. This is what separates a Programmer from a Developer. The more exposure I get to the code base and coding best practices the more holes I fill in my own knowledge and valuable ideas starting coming to mind more and more frequently..
These ideas should be reviewed in your mind and if they seem promising bring them up to your team during a retro or standup. The worst thing that happens is that your idea is not considered for implementation. I have almost never had an idea fully rejected when I had the confidence to bring it up. This shows your team that you care about improvement and it hones in your own ability to make better solutions in the future. You should also note that bringing an idea is like asking the best type of question. It requires everyone to discuss a topic, understand the current limitations, improves your whole teams technical communication, why your solution may not be the best, but then drives the conversation towards a better and more tangible implementation that will save time and or give your team positive recognition.
Respect the work life balance.
This is probably one of the most important things to consider. You do not want to be burnt out, period. It makes everything more difficult, your typical developed methodical workflow gets inhibited because you just need to take a step back and breathe and let your brain relax. For those with kids this is even more important, we never stop working, so making sure to set boundaries with how much you are willing to do in a day is paramount. If you are feeling burnt out reach out to your manager and take some PTO, this is not bad, it does not show you don’t care, it just means you need a break. This refresh will pay off dividends down the line. You will be more productive with the time you are at work, and most importantly you will be much happier.
Also, get a hobby if you don’t have one, we spend all day in front of computer, so find something that is mind numbing and lets you forget about development. For example, I run just to exercise and get the anxieties in life. I play guitar to have goals out side of career development. These are just some of the many things you can do. But, please, balance your life, this leads to sustained happiness, and super productive individuals.
Conclusion
These are by no means the only things that I have learned but, surprisingly the main things that come to mind are not technology related. As Junior Engineers we are certainly learning new things everyday, but, I think these are some of the things that have paid off the most in increasing my ability as a team member on SCRUM team as a Software Engineer. Hopefully you can find some value in this, and if you have anything to add please comment below things that you have learned throughout the years as a Software Engineer.