3 Communication Hacks for New Grad Software Engineers
Going from working on CS assignments in college to collaborating with other engineering professionals is an exciting transition. You go from stressing out about a bug 10 minutes before the midnight deadline to shipping code for a real product that has users(unless you join an early startup 😅). And now you are getting paid 🤑. I don't know about you, but a lot of “collaborating” for me was huddling with my fellow college students around the one TA that was approachable. Fortunately, that looks a little different in the workplace.
Collaborating in the corporate world involves effectively communicating to our coworkers. Here are a few communication hacks I wish I knew before I started my first job as a software engineer!
Ask Good Questions
Asking questions is an essential part of being a software engineer (SWE). You can ask questions about a design you have, a coding approach, debugging etc! The core theme is presenting your questions in a way that provides good context on what you are working on, the problem you are trying to solve and how your coworker can help you achieve your goals.
What most people don't tell you is that there is a way that SWEs should ask questions. Whenever I get stuck on a problem or need assistance with a gnarly bug, I communicate my thought process to my peers. What you ideally want to convey to another engineer is that you spent time thinking about the problem, tried a few approaches and have a sense of what could be wrong. This signals to other engineers that you exhausted different pathways before asking for help.
As engineers, problem-solving is an essential part of the job and being able to get another SWE effectively into the context of your problem is a skill that will enable you and your co-worker to get back to work more quickly. It also demonstrates your knowledge and effort all while signaling respect for their time.
NOTES I TAKE WHILE DEBUGGING:
How to reproduce the problem/bug
Educated guesses as to where the bug is being caused
Different ways I have tried to solve it
Who else I may have talked to about it and their takes on it
Track Your Work
Track everything. Track the work you do and the conversations around it. I mean it. Especially if you work remote, like myself. Regardless of your remote status, there are so many conversations occurring asynchronously, that it can be hard to keep track of all the outcomes and decisions.
Sometimes when a Jira ticket is written, the requirements might change or new requirements are added. I always try to make a habit of updating the Jira ticket or adding comments. If there are unknowns that need to be figured out, add them as a comment. If there are answers you discover along the way, document your findings. If you reach new conclusions with your teammates in regards to the work that is assigned to you.. you guessed it. Add it as a comment. Over time, people will forget the complexity of the things you worked on. Or you won't remember the hurdles you had to jump through to make the feature work. Or you want to remember why you made one design decision versus another! This gives you a public place to track your process and progress as you solve a problem.
Leaders, especially non-technical ones, will utilize software like Jira as a window to understand the work you are doing. It is important that they fully understand the entirety of your work. Don't be like me when I first started working and think people will remember all the problems I had to solve to get something working.. they won't 🥲.
NOTE - There is nothing wrong with people not immediately remembering. In fact.. it is human! There are a lot of people, events, deadlines, etc that occur in a workplace. You may even forget some of the work you did.
If there are decisions that are made during a PR, make sure you document them. For example, let’s say there’s an inefficient query that needs updating, but my PR reviewer and I agreed offline that the change will be cleaner in a separate PR. Great! But I don't want to make it seem that I was unaware of the inefficient query. So, I will say something along the lines of "Per our conversation @engineer, I will update this query in a different PR". You want your writing to speak for you when you are not in the room. So that anyone can look at your PR/Jiras and know what you did and why you did it to some degree.
Give a Killer Standup
Standup. The occasionally dreaded morning meeting can leave anyone floundering about what to say. Chances are, that you’re sharing updates about your work in progress. I highly recommend writing down what you want to say beforehand. Even if it is just a few bullet points. On the surface, standup is pretty simple, but it can be much more.
Its all fun and games until one person on your team gives a really good update. And then the seeds of uncertainty begin to rear their ugly head. Your coworker gives a complete update filled with loads of good information and they even threw in a good joke! And now it’s almost your turn and you want to give a thorough update as well. Every team or company approaches standup differently and it is important to follow the best practices set for your organization. That being said, I tend to follow a simple pattern:
STANDUP TEMPLATE:
Yesterday I did.. (jira, bug, helped coworker, etc)
Today I will.. (continue working on feature, talk to another team, etc)
Shoutout to (Person X for helping me with a bug, Person Y for talking through a design with me)
Questions that I may have
More in depth explanation below:
First off, you want to talk a little bit about what you did yesterday. Mention the things you completed/still working on. Even bring up the things that you are blocked on, which will give the team an opportunity to point you in the right direction.
If someone has helped you squash a bug or unblocked you in any way, give them a shoutout! I have found that giving shoutouts to people during standup is a great way to signal to folks that you appreciate their assistance and time. Then, you want to talk about what you hope to accomplish today. Remember, standup is a place to notify folks what you are up to and where they can assist you in completing your work and vice versa.
Conclusion
This is far from an exhaustive list and I am sure that a whole book could be written on this. Being a good communicator is a form of self-advocacy. It is the light that illuminates all the work that you do. Oftentimes, there is a lot of hidden complexity in projects that may not be apparent on the surface. This can be especially true if you work on a solo project or a significant infrastructure with a lot under the hood. Remember, you are your biggest advocate. Mastering soft skills will give you an advantage when it comes to promotions, projects, and other opportunities. I have found that these are some small, but effective, ways to provide the people around you visibility into the good work you are already doing. Add them to your toolbox.
Until next time, be whole and be well! 🧘🏾♂️
