• ↑↓ to navigate
  • to open
  • to select
  • ⌘ ⌥ ↵ to open in panel
  • esc to dismiss
⌘ '
keyboard shortcuts

Joining a new job, when you have people relying on you as the sole income stream is no less than a war.

It’s so easy to be tensed, have jaw and shoulders clenched trying to deliver, making an impression, doing everything all at once and more, that we forget to even take a breath for a moment; close eyes and not instantly think about the problem.

Sometimes thinking about the problem solely for the sake of it. Not even figuring a solution; just staring dead-eyed at the problem. Somehow, it feels more productive and resting feels guilty, undeserved.

If you’re in a fast moving start-up team. It is expected you will find and solve problems, mostly on your own and within timelines that stretch out every dendrite and fry all your axons.

Now that engineering is cheap with coding agents, and most teams onboard you in a few of them, it’s so easy to spiral into the loop of prompt broken output prompt again till after 2 days you realize your agent was editing legacy, dead code because it didn’t bother tracing the production path and just went by vibes from the file names.

Breathe.

Breathe. Watch a movie. Go for a walk. Watch a movie.

Come back. Read but, slowly. Read the part of the codebase, and some additional contracts which are necessary for your current ticket. You do not need to understand the full pipeline End-to-End within your first month/week/day. Just enough for you to build your mental model of the code what it does and why it does it.

Take notes. Lots of ‘em. Pen and paper, fingers on keyboard, whatever works. But ideally, avoid using AI to write those notes. You can definitely use it for generating better diagrams, but keep the codebase study part limited to your own cognitive capacity and not offload to agents. Beyond confidently hallucinating a legacy dead path, it also strips away foundational understanding of the codebase that you’d have gotten from actually sitting through it.

After a day or two you should have a good enough idea of the part of the code base you need to work on. Now, write down your problem. Write it down exactly what the problem is and exactly which part of the code base it’s in.

This blog is in progress…