DEV Community

loading...

Lessons learned from Junior to Senior Developer

Vincent Tang
Cohost of Code Chefs, a coding podcast https://codechefs.dev. Software blogging @ https://vincentntang.com
・4 min read

3 years ago, I decided to change careers and become a software developer. I had no formal training in software development and decided to learn on my own. Through countless youtube and Udemy tutorials, and hackathons, I landed my first job working on construction management software.

Fast forward to today. I'm a senior frontend developer in charge of delegating & delivering features affecting millions of users at a time. I've come a long way since then and I'm writing this post reflecting on what I learned along the way.

This isn't an exhaustive list but just lessons I learned along the way

Working with stakeholders

  • If you demo to stakeholders, record a video of the demo in advance as a backup.
  • Live coding/testing has a high chance of failure
  • The frontend is always highly scrutinized by non-tech stakeholders since it's visual and easier to understand
  • When you demo, talk slow and move your mouse slow. Things that are obvious to you are this way since you spent several weeks on a feature. Stakeholders are seeing your work for the first time

Working with management

  • If you need to estimate a task, assume it's way harder than it is
  • Deliver bad news early and good news frequently
  • If your PM is messaging you directly for updates frequently, either there's an issue with the process or you are doing things wrong.
  • Push back deadlines as far back as possible during planning phases. You'll thank yourself later. It's better to underpromise and overdeliver

Working with engineers

  • Create living documentation upfront and do it regularly, it saves everyone time. Google docs is your friend
  • If you get stuck on a problem for more than 3 hours, ask for help.
  • Make your teammates look good and give credit where it's due. The analogy is if you hang out with awesome friends chances are you are awesome as well
  • Make an ADR (Architectural Decision Record) when you implement big changes to a codebase. It prevents you (and others) from 2nd guessing why certain things were done 6 months ago

Code Reviews

  • For code reviews, critique the code, not the person
  • Make your code reviews awesome by explaining every question a person might come up with

Leading a team

  • Mentoring developers can be fun and enjoyable, but you need to spend time and effort on it
  • Plan out your ticket action plan for the team over several days to iterate and improve
  • Spend time onboarding newer developers on the project, and write documentation on questions they have. They're looking at things from a fresh perspective
  • Always give good candid feedback to your teammates when possible
  • Emphasize the big picture and give room for others to be creative/ take ownership of features
  • When you pair program, one person is the driver, the other is the instructor

Time Management

  • Plan large focus periods of work where you won't get interrupted
  • Don't forget we're all people too. Plan your vacation and sick days
  • Think win-win and lump related tasks together and get them done in one go

Reducing Technical Debt

  • Don't over-engineer things unless it's warranted
  • If you use two booleans that conflict with each other, use an enumerable instead
  • Type safety is effective at reducing technical debt.
  • Always use pure functions when possible. This makes the app reusable and obvious at a glance
  • Write more tests against iterative and less obvious code
  • Use undefined instead of sentinel values. Sentinel values are checks on seemingly random values in the codebase
  • Always use a linter. It saves you time and effort
  • Don't have competing sources of truth. Use as few scoped variables as possible, and use as few derived/computed variables as possible
  • If you need to tackle legacy debt, migrate one feature at at time

Architectural Rules

  • Most systems use soft deletes. This means companies don't actually delete your data, it's just marked as inactive
  • Use caching to reduce amount of work service-layers need to make. But don't treat it as the source of truth if possible.
  • Never trust the frontend. The backend should handle the vast majority of business logic. Avoid database business logic if possible, it's hard to maintain.
  • If you don't need high scalability on your project, just ship it out and don't worry about it until needed
  • Don't put too many shiny things in the app. It increases the risk of failure. Pick preferably popular libraries with good documentation
  • Feature flagging helps you deploy and deliver features to other teams while still deploying regularly

Database Rules

  • Keep your database designs as simple as possible to reduce complex JOIN SQL statements
  • NoSQL datastores don't have ACID requirements, so it's great when you design a system where users don't talk to each other

Summary

Let me know what you learned over the years and add it in a comment :)

Discussion (0)