Actionable tips for the New Grad Software Engineers out there

Overview

Fresh out of college and enjoying finally getting that Software Engineer title? Here’s some actionable guidelines I wish I’d known getting started.

1. Do high-quality work.

My first pull request ever, the first comment was a typo fix from my manager on a schema that practically everyone working with our application would touch. I would have caught if I had even just thoroughly read through my code once. Regardless of whether my eyes just slipped over it, not quite the ideal way to come in.

Point being, as a software engineer, our work is one of the main ways people form their opinion of you, due to code review. Write high-quality code, proofread to no end, and shake off your mistakes in favor of being excellent in the long-term, and that will shine through.

2. Be efficient with your time.

I recently read The Four-Hour Workweek by Tim Ferriss. While a lot was useless, I did take away one nugget — the Pareto Principle (yes, the 80/20 rule). 20% of your time leads to 80% of the results. Don’t waste that other 80% of your time. Don’t spend time on something if you don’t get tangible value from it (loosely pulled from the Agile Manifesto, which many people say they’ve read but actually don’t — please do, it’s worth it). Don’t waste your time. I’ve restated the sentiment four different ways, because it’s four times as useful as most other things you’ll learn. I exercise two main applications of this rule.

First, make the most of the time you have to be at work. Be a relentless advocate for your career and focus on good, tangible, measurable resume bullets and what will give you useful experiences to talk about in interviews. Maximize the amount of career value you get out of every minute at work, just as you maximize the amount of value a recruiter gets from every word on your resume.

Second, low-time, high-value things matter too. Ideas:

Put effort into LinkedIn. Post about articles written about you, projects you’re proud of, or whatever suits your fancy — just do it much more than only when you hop jobs. LinkedIn is actually cracked when it comes to how many people you can get in front of with a low amount of effort. Second — put your resume on the cloud somewhere and put a link to it on your profile, so that whenever you update it, all your links to it across the internet auto-update. And third— interact with people. Congratulate them on new roles, even if you don’t know them well. It’s a feel-good situation all around, and people will absolutely remember that if you need a referral down the road.
Keep a technical blog. You ever hear the saying “you don’t know it unless you can teach it?” Yep, that’s what a technical blog is doing. Impart your knowledge. Getting your name out there in a context where you come across as knowledgeable is invaluable. Just write a quick post whenever you solve a bug that doesn’t have much on the internet (it’s a great feeling, as I’m sure you know), or recap the hardest things you did the last month. Or, be me right now, trying to give my take to all the fresh college grads out there.
Put together a decent GitHub profile. You can do interactive GitHub README’s (here’s mine — feel free to copy-paste and edit it), which is a super easy way to basically set up a quick description of your development involvements. It’s Markdown, so gives you a little more of a freeform format to work with.
Put up a portfolio website. Unless you want a job in frontend or UI design, feel free to just go with a template. Throw it on GitHub pages, which is a great, git-integrated, free way to host static sites. You get a virtually zero-maintenance way to get you in front of more people, and have tools to measure your audience via Google Analytics or similar if you like.

3. Motivation is key. Focus on quick wins.

Our field is rife with people with ideas, but it’s so criminally hard to actually finish them. I personally have about thirty private repositories on GitHub that are just ideas that I ultimately just lost motivation on. Good news, though — I finally have something to show for it. I officially have an MVP put together for a task/calendar/time management service, which has given me a great bullet point.

I learned two things:

Focus on the quick, minimally viable first. With any project, you’ll keep identifying things that can be done more optimally, or additional features that will be easier if you design it right the first time. If you want to get stuff done, you need to become brutally good at cutting off this voice, and aiming for something minimally working across the board, then work one feature at the time (this is generally referred to building in horizontal vs. vertical slices).
Focus on things you genuinely have a use case for. If you’re just doing something for money, that’s fine, but you better make sure your motivation and discipline for getting it done is figured out, else it’ll fall apart midway through, and odds are that time would have been spent better elsewhere. The ideal scenario is if you’re building something that you’d personally use. Most entrepreneurs out there come from identifying a place where something can be done better, and they full-commit to it.

4. Networking is important, but go in with a purpose.

You’ve heard this before. My personal take on it is that you can get like 70% of the networking benefit just by trying to be involved in things around you, and just saying yes to most things that hit your inbox. Coffee chats are worth it, and have never been so easy to set up due to the recent prevalence of Zoom.

And pro tip — high-level people at most companies (like, Vice President or Managing Director level) are surprisingly free for coffee chats. You’ll get some no’s, but there’s lots of knowledgeable people out there. I personally can’t wait until I’m senior just so people set up coffee chats to learn from me. Just come prepared with some questions (or, better yet, send them an agenda or question list ahead of time so you get more thought-out answers) and it’ll be a great time.

5. Respect other people’s time.

Do some troubleshooting before you ask for help. You learn a ton from the troubleshooting process, and you don’t want them to google it and find the answer right away, because that is not a good look. I’d recommend you don’t spend more than an hour struggling, but spend that hour learning.

Though, asking for help does have its upsides. Especially as someone new, you will be pretty lost, and you can only get so much from documentation. Fight to try and be as involved with your team as possible.

And, an aside on meetings — companies are getting better about meeting culture, but it’s still a problem. All you can do is administrate your meetings well and try and be a culture carrier that encourages better meeting standards from everyone else.

My guidelines:

Meetings only happen if a decision needs to happen. Otherwise, email.
Only invite the necessary people. If someone isn’t necessary but would likely benefit from being there, make them optional.
Send an agenda ahead of time and encourage everyone to come with ideas.
Try and put your meetings near other people’s. This minimizes everyone’s context switching overload and helps productivity.
Trim five to ten minutes off the beginning of your meeting (depending on length) to give people an opportunity to use the bathroom, grab a drink, or whatever. This will almost always give people an appreciated break, because meetings often end on the hour.

6. Focus on depth over breadth.

The desire to touch on everything out there, and to always be starting something new, is endemic among software developers.

I’ve been there, done that.

7. Manager 1-on-1’s are worth it.

Your manager in short, is the person people go to if they want to know how good of a worker you are. You want to work with them on being a good worker, and communicate well, rather than the alternative of constantly wondering if you’re doing a good job. And, aside — if your manager or team says you’re doing a good job, trust them. They are the authority on the job you’re doing, not you.

8. You don’t need to code in your free time.

It’s your day job now. Don’t get burnt out. After you’re out of college for a year or two, side projects, while still a bonus, get deemphasized, and you can easily just use one or two of your big experiences as the entirety of your interview material. Focus on doing high-quality work, on using your time well, and on living whatever life you want to live outside of work.

Conclusion

Thanks for reading. Enjoy being done with college — I know I am! Hope you got some value from this.

About Me

I’m Anden, a Software Engineer at JPMorgan Chase & Co., and a software consultant for the Center for Design and Manufacturing Excellence. Get in touch at any of these:

If this article was useful for you, and you like Medium, please consider signing up for a Medium membership using my referral link here or buy me a box of coffee (they’re K-Cups from ALDI —please don’t judge me) on Paypal here.