Tips I wish I knew starting out as a Software Engineer
Kickstarting your engineering journey
For new software engineers just starting in their careers, I know how overwhelming it can feel to enter this industry. When I began, I had so much to learn not only about coding but also navigating projects, communicating effectively, and growing my skills over time. I wish I’d had some guidance from more experienced engineers on what matters for long-term success.
This article is for you — the new SWE who wants to set yourself up for an enjoyable and impactful career. As someone still relatively early in my journey, I’ve discovered some valuable tips that I wish I’d known from the beginning. My goal is to pass along this advice to help give you a head start.
Top Career Tips
Never stop learning. The tech world is changing and your curiosity should never wear off. Learn about how other functions/roles outside SWE contribute to the company’s business model/mission. Try your best to stay updated on the industry in which your company is in. Keep that fire of curiosity alive. I also think that applying this mindset to anything in life is fulfilling whether it be a new hobby, sport, creative endeavor, etc.
People Engineering >>> Technical Chops. To preface, I’m not saying that technical skills are worthless or that coding is not part of SWE. Technical execution is a component of SWE, but as you go up in your career, a lot of your time will be spent with project management, delegation of work/components to other people and even aligning with stakeholders on project requirements/criteria/goals. Improving your communication with others on your project helps you grow into a leader. For example, during my most recent project, I proactively communicated my updates and surfaced blockers to the stakeholders in a dedicated Slack channel. If any discussions were best suited for a meeting, I would create a meeting doc to jot down the agenda, discussion points of the meeting, and the relevant action items. These methods helped ensure everyone was on the same page and any issues could be addressed promptly.
Take ownership. If something goes wrong during a project, never blame/point fingers at other people. That isn’t constructive. Take ownership/initiative to help identify where in the process improvements could be made. Write a 1 pager and share it out in your team meeting. For example, there was a production issue that arose due to a code change I merged in. I took ownership by writing down a detailed document explaining why the issue came up, how the root cause was investigated, and most importantly, what can everyone learn from this to prevent a similar problem from coming up in the future. Most importantly, I shared out this investigation doc to the team during our weekly Friday meetings for visibility and discussion purposes. As a result, you start to gain more trust/credibility amongst your teammates and solidify your subject matter expertise in the given area of your team.
Try to dedicate 10% of your time on non day-to-day engineering work. Expand your scope/visibility, meet others in your organization, and dig through areas of the codebase/product you’re curious to learn more about. Possible ideas include but are not limited to:
Help out recruiting by interviewing candidates, question creation/calibration, and even providing feedback on how the hiring process can be improved
1:1 with that colleague in the company you wanted to meet but didn't get a chance to in your day-to-day
Think through tech debt/paper cuts you can help clean up in the codebase and keep the respective team aware for visibility purposes. You could also kickstart or improve the culture of technical quality within your team
Document (or improve existing documentation) for certain tools, repositories, and processes that can be confusing for people new to the company. Your next new hire and future self will thank you!
Recognize any colleagues who helped you in your project. Take advantage of an employee recognition portal if your company has one. For example, my company uses a platform called Awardco to recognize employees. Kindness has a way of spreading
5. Organizing meetings/sessions that bring teams together is a fun endeavor you can take the initiative on instead of having your manager do it. For example, I collaborated with another teammate to organize a brainstorming session for the next year roadmap involving the current team and our sister team. We collaborated with both teams on coming up with an agenda/structure so that the session is as productive and interactive as possible for everyone involved. Benefits of taking on this type of initiative include:
You make your manager’s life easier
You can demonstrate leadership skills and incorporate your teammate’s feedback
There is a nontrivial amount of thought/effort that goes into organizing an effective session/meeting
6. “We” over “you”/“I”. Software engineering is a team sport. Uplift others around you. It helps you build a good reputation in the company/organization. Using “we” more often in communication helps you come off as more collaborative and your ideas are more likely to be well-received.
Suboptimal: “Your technical design doc is confusing and garbage”
Better: “How can we improve the technical design doc so that the stakeholders have a clear understanding of the project”
Suboptimal: “Hi team! Bob and I are organizing a brainstorming session for 2024 project ideas. Could you all please provide feedback and thoughts on the format of the session”
Better: “Hi team! Brainstorming time is almost here! Bob and I have scheduled a placeholder meeting on our calendars for next Wednesday. We wanted to share a Figjam which outlines the format and structure of the session. We would love to hear everyone’s feedback and thoughts in order for all of us to have an effective and collaborative session! Looking forward to some great ideas for 2024!”
Suboptimal: “I would have done this Y way instead”
Better: “What were the design decisions that led to doing X way? Would it be worth trying Y way due to A, B, C reasons?”
Suboptimal: “Brad, you spent only 30 minutes trying to solve this bug. You should have spent more time investigating”
Better: “Hey Brad. Hope you are doing well. Let’s document some steps we tried during investigation before hopping on a pair programming session. Looking forward to the session!”
7. Written communication >>> verbal communication (in most scenarios)
A written trail for anything is scalable, easily shareable, and clearer because you are forced to get the idea on paper in a clear/coherent manner
Your future self will thank you during the performance review process
Example artifacts include, but not limited to:
Technical Design Docs
1:1 docs with anyone from your team
Meeting notes
Investigation Docs (bugs, production alerts, etc)
Proposals for collecting ideas on areas where the team’s process could be improved
Onboarding Guide
Runbook for a system that is used by developers in the company
Wisdom from Others (mostly paraphrased)
Instead of asking “What can I do better?”, ask a question like “Based on what you’ve seen from me executing on the last project, how could I have made that 10% better?”
Specificity helps you gain tailored feedback
Anything you do should have the following tenets:
Benefit for the team: The team needs to realize this.
Not purely for personal gains, never optimize purely for yourself
Over-communicate with your manager and team lead
Funnel analysis/thinking can be a nice way to understand how your team works. It also helps you contextualize problems your team is trying to solve at the macro level
We erroneously think that in order to do good work, we need a good project. Given any project, you can demonstrate your skills. Take any project and make it the project you want to be!
Promotions
Getting promoted is understandable, but that’s a small goal
Growth mindset >>> promo mindset
Look at life in the “overall”. Don’t think in black/white/1 dimension
Growth is hard/painful, but those “things you see that feel unfair” are very common at a “small time level”. Over time, those variabilities level out!
Optimize for “long-term greedy”
Impact is not only about the monetary revenue you deliver to the company. You aren’t necessarily expected to deliver $1,000,000 dollars of revenue at the entry-level. Think a bit creatively about impact. Here’s a good rule of thumb:
Anything you do that OTHERS take notice of and express interest in IS IMPACT. The key is how you “sell/market your work to others”
Analogy: Ask 100 people to describe a cow. The majority would describe a cow as a “farm animal with black/white spots that goes ‘Moo!!!’ and produces milk”. Someone who answers the question from a different angle might talk about different species of cow, describe how cow populations behave, and the effect of cows on other animal populations. The latter seems like something that would pique one’s interest/curiosity
Takeaway
I hope you found some helpful career tips within this article that you can apply to take your engineering journey to the next level. The technology industry will continuously change and pose new challenges, but focusing on learning, collaboration, and continuous improvement will serve you well throughout your career.
Remember that technical skills are vital, but don’t forget the importance of effective communication, ownership, leadership qualities, and staying engaged beyond just code. Seek opportunities to contribute value across your organization to not just survive but truly thrive as a software engineer.
Thank you for taking the time to read this advice from a fellow engineer still early in his career. My goal was to pass along the lessons I’ve learned so far in hopes it gives you a head start on your path. Wishing you all the best in your engineering career — now get out there and build something amazing!