Make change cheaper: Making a new engineering job less draining


We glorify adaptability in tech. Pivot fast, learn faster, ship faster. But every change taxes the same systems you use to think clearly and make good decisions.


Starting a new job as a software engineer is peak change. New codebase, new tooling, new rituals, new acronyms, new people. Your brain is building fresh predictions for everything. How PRs get reviewed, where incidents get triaged, which tests to trust, which Slack channels matter. That learning tax is real, and it draws from the same pool you need to do meaningful work.


In stable environments, habits carry you. Shortcuts form. Complexity becomes familiar. But a new role puts your brain in “cold start.” There’s no autopilot, just constant updating, constant learning. Stack enough changes, new manager, new architecture, new deployment pipeline, and you hit change fatigue. The instinct is to push harder or wait for things to “settle.” Both can backfire.


What helps when you’re onboarding and everything is moving:

  • Stop trying to get back to normal: Old workflows, old muscle memory, old velocity don’t apply here. Normalise slow starts, incomplete context, and small wins. Aim for present fit, not past performance.
  • Take inventory, fast and often: What’s actually working? Which doc sources are reliable? Who unblocks quickly? Which tests are flaky? Keep a running list. Pattern finding is how you reduce cognitive load.
  • Design tiny experiments. Treat onboarding like a lab and try out new things often.


Change won’t slow down. But its cost is adjustable. When you accept that adaptation consumes energy, when you surface what you’ve learned, and when you run small experiments instead of waiting for perfect conditions, you lower the tax. The goal is signal over speed. Ship less noise, learn the right things, and let the system become familiar enough that focus returns.

Leave a Reply

Your email address will not be published. Required fields are marked *