Hi readers,
So big news! Last month, I left my previous employer (Hypertherm) and started a new job this month at Divisions Maintenance Group as a Sr. software engineer.
As it is fresh in my memory and that I am still being onboarded, I would like to share what I’ve been doing/planning on doing at work. Hopefully, my recommendations will help you start on the right foot 🙂
1. Be kind and treat others with respect
Before starting in the technology industry, I used to think that as you grew in seniority (senior/staff/principal/CTO), you were expected to be strong and powerful to govern your software projects. Hopefully, you won’t be thinking like me if you’re just starting your career.
If I were to think about the best advice to give to someone, I would say to just be kind. Seriously. The mindset and the culture in the team and the company are so important; disrupting it or being arrogant/mean with your coworkers, might mean that things won’t fly well for you.
You’ll start on the right foot by simply being kind to people and treating them with the respect that they deserve. Always remember that.
2. Have a positive attitude towards your tickets
When you start a new job, you will typically be given small tasks. Even if you are not given the “fun” stuff right off the bat, show that you can do those very well. Show right away that you are excited about these small jobs. This is a way for you to learn things from the ground up!
Trust takes time to earn in a new team. Be grateful for every opportunity that you get to provide value for your team. When working on your software tasks, do your absolute best to make sure it is quality work. Below is a list of things you can check when working on your ticket:
- Make sure that your branch name is meaningful. Respect the guidelines of your team. Usually, I’d put the ticket number along with a summary of what the branch is doing.
- Make sure that your code is clear and easy to follow. When naming your variable or class or method, make sure that their intent is effortless to grasp. Do not forget to add helpful and declarative comments for obscure portions of your implementations that could be harder to understand.
- Do test your code. When fixing a bug or implementing a new feature, your changes always risk the integrity of the codebase. Adding tests to your pull request shows that you care about making your implementation more robust.
- Apply defensive programming to your code. Thinking of the edge cases and making sure your code is not prone to runtime failures will make you shine in your team 🙂
- Make things easy for your reviewers when submitting a pull request. Add the context on the ticket and your solution to the description of your pull request.
3. Defining success with your development manager
A new job can bring a lot of stress and anxiety for people. You don’t know where you stand and you’re trying to give out a great first impression. In your first days/weeks, I would recommend finding an opening in your manager’s calendar to organize a sit-down with them.
It can take a while to ramp up on a new job, sometimes up to 6 to 12 months. During that time, it is crucial to realize the right things to do while you’re working. You do not want to wait an entire year to hear about the things you’ve been doing wrong this whole time and then try to break out of your “bad habits”.
During that meeting, you can discuss your future in the team and how best to guarantee your success. By doing so, you show your new boss that you’re effectively taking responsibility for your career. That allows you to know the valuable aspects your new boss would like to see out of you while you’re starting.
Additionally, you can schedule with your team leader a few meetings in your first few months to see how you’re performing. The first meeting you’re having to ensure your success in the team won’t cut it. As time passes by, you may be headed away from the direction you initially embarked on. Having multiple performance assessments from your boss early on will benefit you in the long haul. Having them in small increments in your evaluation will help you adjust throughout the year what you need to do to be successful.
4. Be empathic towards your customers and team problems
As a software engineer, your main preoccupation is to solve business problems with automated systems/applications/tools. To function well, you need to understand what your team and your product are trying to accomplish and the problems that are being solved. When you are writing code, keeping that in mind will make you more practical at your job. It will give you an idea of whether your solution is sound enough to weather the storm out or not.
You are not here to be a code monkey; you are here to fix business problems by leveraging your expertise in technology. Maintaining or writing new code should not be THE goal by itself. Software engineers aren’t just there to be coders in companies. By thinking of who the customer is and the frustrations that lead them to your product or suite of products will make you a more effective engineer.
Feeling empathy towards who your customers are AND the problems that your team is facing and will face is a great way to thrive in your organization. Having those considerations in mind while working on a new/existing piece of software will help shape your perspective. Instead of trying to over-optimize your solution, you may find yourself getting away with a solution that is in-between adequate and excellent for a fraction of the time it would have taken to finish the perfect solution.
Trying to implement something flawless or trying to predict future problems may very well lead your codebase to unforeseen bugs in your code. Only focus on the matters at hand, but do leave some room for growth. You may very well have to go back on your code. Leveraging best practices in development can only bring you so far if you end up delivering your product commitment late. Your top priority is making your stakeholders happy; the rest is superficial. If you end up rushing through your implementation, document what you’ve done. There will come a time for solving potential technical debt later.
5. Do not judge the existing code
It is very easy to take a peek at the living code and start taking shots at it. The thing that you need to understand is that mitigating circumstances are surrounding the implementation.
Instead of telling your teammates why the code you’ve been taking a look like is bad/poor/whatever, you can take some notes about the code and organize a meeting with your manager to discuss coding guidelines. The outcome of that meeting might be to expand the coding guidelines and go refactor portions of the code that aren’t on par with the new standards.
There are always good and poor ways to communicate what you see as problems. Always keep that in mind.
6. When in doubt, do not hesitate to ask questions
It can be intimidating being a new member of a team. But seriously, never hesitate to ask questions. There are numerous things to learn in a new job. Amid your work, there shouldn’t be any blockers in your productivity. Nobody profits from that, no one.
There will be times, mostly in the beginning, when the team is discussing certain topics that you are not privy to. It is important to ask questions and clarify what is that you do not understand. Instead of remaining clueless, you get to participate in the conversation and bring something to the table.
7. Organize pair programming sessions with your team
In the beginning, it is easy to be confused by the work that needs to happen on your end. To be more effective, you’re better off organizing pair programming sessions with your teammates. By doing so, you get direct insights from your colleagues on how you can do your job better. It also helps you build a working relationship with your coworkers.
8. Try to find places where you can add value
When you were hired, your future team saw a lot of valuable experience and skills in your profile. Even you may start feeling overwhelmed at work in the beginning (totally normal), do not undervalue yourself.
For instance, if you see that there is a portion of the application that isn’t tested and you think that you can quickly build a suite of unit tests, talk to your manager. Don’t start doing work you weren’t assigned to. This could be helpful for you to understand the development process and actively contribute to the codebase.
9. Set up boundaries between your work and personal life
It’s important to find a balance between your work and personal life. Don’t push yourself too hard to the point where you find yourself investing more time than necessary. For instance, once you’re done working, put your emails and chat notifications away. It is very easy to answer emails and chats well past your working hours.
Being too invested and not setting boundaries for yourself could lead to burnout. Yes, working your hardest is important, but making yourself and your mental health a priority is equally as important!
10. Manage your time
Managing your time makes you more effective as an engineer. I recommend setting up your weekly calendar a week in advance and prioritize your work items and meetings. Therefore when starting your day, you do not have to ask yourself any questions about what you are going to work on.
What you can do to make sure that your colleagues don’t think you are inaccessible is to let them know that they can still send you direct messages throughout the day. If you are too busy, just get back to them whenever you have the time or reorganized your day based on the importance of their request(s).
Conclusion
In the end, every job is different. I am not saying by following every single recommendation I’ve made will ensure your success at work. What I am trying to do here is to help you do the best that you can while starting your new job 🙂
If you have any stories or comments to share on your new adventure, please do leave a comment!
Thanks,
Kevin
Black Coding Adventures 