I recently started thinking about the non-obvious things I’ve learned from other people over the last 5–7 years working as a software engineer. Here are a few of them.
"Don't let work find you, find work first". This quote from one of my first managers deeply resonated with me. As you grow more senior in the career, people stop telling you what to do. You are expected to figure it out, prepare a plan, get your manager excited, execute on it and then proudly report results. Depending on what your company or part of company cares about (happy users / less risks / reliability / low costs / revenue / opinions of Wall St. analysts or VC investors), project objectives might look different, but you are still going to have acquire a skill of inventing new things to work on and making bets on behalf of the company. One common instance of this rule is fixing bugs and incidents — in general, you should learn about them from logs and alerts ("finding work"), not Slack messages or customer emails ("work finding you").
-
Make your design docs, specs, and documentation look good. Clear numbered sections, a “Definitions” part, consistent naming, some pseudocode, visual mapping between design elements and API fields, and an FAQ section. Nowadays, this also means no AI slop. Even small things like text color for headings or callouts help. When you include diagrams (I like Excalidraw), make sure they’re clean too: good layout, consistent sizing, colors for different element types, and a legend. Usually, this just means spending an extra 10–20 minutes polishing the document after writing the main content. This advice feels a little bit shallow, but surprisingly effective for getting more people to read and understand what you're working on.
Related to the previous point, but also stands on its own — writing a great spec, both in substance and form, makes projects move so much faster. Onboarding more engineers to the project, championing the chosen architecture, sharing project updates with executives and communicating what's going to change for other stakeholders (for example, support, security or sales) — all of this is easier with a good spec. Also, writing is thinking, so you'll make better decisions after writing more.
Record your achievements in a doc, even small wins, with links and screenshots. Share these regularly with your manager and keep an aggregated version for your next performance review. Do the same for your peers, as you're likely going to asked to review them as well. Regardless of performance reviews, communicate your big wins in team-wide channels and do thoughtful shoutouts for teammates.
Create a "playground" script in the context of the codebase you're working on. It should allow you to experiment with internal modules (especially the ones you're not familiar with during code reviews), build one-off data exports, benchmarks or prototypes.
When preparing or reviewing a change to some API endpoint, triple-check if you added proper access checks, parameter validation, metrics and logs.
Optimize CI pipelines overall and do frequent deploys. Even beyond the regular deploys, when working with frontend or mobile engineers who run into an API issue, can you unblock them within a few minutes? Most likely, you should have some staging server available without a PR review — for example, a "preview environment" on Vercel or using a direct deploy to a dev server. On frontend or mobile, you should have an ability to override the backend endpoint to support this flow.