After almost two years as an engineer at my current company Moda Operandi, I'm moving onto my next engineering role at an ed tech company called 2U and I could not be more thrilled! Through years of private tutoring since high school, teaching several classes of Bootcamp Prep at Fullstack, and working at National Writing Project, the importance of education has been top of mind and it's been a dream of mine to be able to improve the direction of education on a larger scale — which I now have the great fortune of doing, with an awesome team to boot!

I've had a great experience at Moda these past few years and it's definitely bittersweet to leave such great coworkers and some amazing products behind. On that note, I want to recap some of the lessons I've learned during my first two years working as an engineer.

Disclaimer: Some tips may seem obvious to you or are things you already learned before your first role. Some may be more general and apply to fields outside of engineering. This is my specific experience and therefore may not necessarily apply to you!

Make friends with coworkers

During my first few months at Moda in marketing I had to actively learn how to smile at coworkers and make a lot more small talk than I knew how (in case it wasn't obvious I am 100% an introvert). After a while it became more natural to talk to my coworkers about my weekend plans or have heart to hearts with them over coffee breaks. When I moved to the tech team two years later, I was so focused on trying to pick up new technologies and figure out how to navigate the codebase that I assumed making friends with my new teammates wasn't as important. This was amplified by the fact that programming can be pretty heads down and independent minus a few meetings here and there.

I didn't reflect on this much until being encouraged by my manager to share my wins and communicate more, and hearing a Developer Tea podcast on the importance of getting to know your coworkers even if you're an introvert. Once I made more of an effort it made such a visible difference both to my happiness/morale and communication with teammates. Of course, no one has to be best friends with their coworkers, hang out with them on weekends or even happy hours and so on, but make the time to ask them about their weekends or hobbies. Be curious and treat them like fellow people. Lower your guard down (within reason) and trust me you will reap the benefits and be a lot happier working with people you know beyond their job functions.

Think about what you can do for your company, not what your company can do for you

Many complaints or resentments you hold towards your company can result in direct action items on your part as soon as you reframe your state of mind.

My personal experience with this was feeling envious of other companies that had heavy outward presence in the tech community, especially knowing that Moda had the talent and awesome products to be well-known. After some time of wishing leadership would do more, I brought up the idea of us having an engineering blog which eventually led to me spearheading an entire team initiative of building our presence in the industry through things like hosting meetups, starting our team blog, organizing discussion circles and more.

The point is, ask for what you want instead of wishing everything will fall into place. When you ask, frame it in a way that makes it obvious that what you want is for the company's benefit. Want to get promoted? Ask what you can improve to move to the next level, and execute. Want to be in fewer meetings? Talk to your manager about how you'd be more productive with more solo time.

Another point is to not be too discouraged by any projects or features falling through because of change in business plans. Part of working at a company is not being a cowboy coder obsessed with your code and your progress - you're part of a team, and the team follows overall business priorities, not a sole individual's. Also there are always lessons to be had and things you learn even with projects that don't come to fruition. You can gain lots of insight with time spent without necessarily deploying the code to production.

Do not take feedback lightly!

When you're starting off your career in engineering, feedback (most commonly through code reviews) is singlehandedly the biggest way to grow. Therefore do not take this lightly — take to heart all the lessons people want to teach you and actively work on pain points that managers or coworkers point out.

Also ask for informal feedback and advice from your coworkers on how to grow! They are your best resource for navigating both how to be a better engineer and how to be a better employee at your specific company.

Work on building your skills outside of work

This is not something that every engineer will necessarily have the time to do but if possible, I highly encourage sharpening your technical skills outside of work. It helps a lot to work in different contexts so that you touch different technologies, interact with lots of different people, and get opportunities that you might not have at work.

For example, as I mentioned earlier I taught at Fullstack for a few months part time. This was beyond helpful in improving my ability to explain coding concepts and help others debug code. Beyond teaching/mentoring, some common ways to build skills would be open source projects, side projects (solo or with friends), code kata, giving engineering talks, and more!

Write everything down

I don't know if it's because I'm getting older or relying on my phone too much instead of memory, but I find myself easily forgetting things I learned not too long ago. For this reason I find it absolutely crucial to log everything.

Write down when you struggled for hours on something and what the fix was (trust me, it will definitely happen to you again - and it feels terrible to waste time struggling on something you already know you solved). Write down common commands you use and passwords along with notes during planning meetings and one-on-ones. Keep it all handy and organized!

Optimize your pull requests/code reviews

Before submitting pull requests do a final line by line check to catch any minor errors. Also, directly mention team members on lines of code that you're unsure about or want specific review. It's common knowledge that the more lines the PR has the less heavily dissected it will be, so calling specific attention guarantees review of what you're unsure about.

If you have time, look at other team members' pull requests even if they're not directly asking you for a review (the more related it is to your project, the more important). Try to understand what the code's doing and pinpoint any areas you see that could be refactored. Reading others' comments on pull requests that aren't your own is a huge opportunity for learning how to refactor.

As for your own code reviews, if you feel that you've gotten feedback to change some line that you feel is better written as is, talk with your reviewer! Code is not always black and white and you may have picked up on some aspect that your reviewer hasn't. Or if the reviewer's way is better, you want to make sure you clearly understand why it's optimal.

Some rapidfire tips specific to software engineering:

• Knowing when to ask questions or when to continue struggling on your own
  • Give yourself time limit (e.g. 1 hour)
  • Plan specific action items before you'll ask (e.g. I'll read these 10 tabs and I'll try these debugging tools first)
  • If it's locating a file within the codebase or anything more contextual that you're totally unfamiliar with, just ask
• Familiarize yourself with team's style guide/code style (even if they don't have an official one documented) and adopt. These might be anything from preferring utility libraries like Lodash over custom functions, preferring ternary operators or not, writing short blocks of functions or if statements on one line vs multiple, always explicitly including return in Ruby, etc.
• If you're not particular about IDEs it's helpful to conform to what the majority of your teammates use that you'll be working with most frequently. It saves a lot of time when pairing or debugging something together.
• Help look into urgent issues and step up for support, including in more unfamiliar domains that are unrelated to any code you've written. Even if your efforts lead nowhere and the problem is fixed before (which as a junior will most likely happen), it'll help you get more practice debugging and fighting fires.

Overall I know I have much left to grow as an engineer, but seeing this list makes me proud of how far I've come during my time at Moda. Growth in programming can feel incremental and slow at times, especially when you "waste" half a day on a bug that another engineer spots the error for within a few minutes, but if you're tackling new challenges with smart, hard-working people every day, everything else will fall into place!

Cross-posted at carolynyoo.com