The estimate, the disagreement, and the handover

The engineering is usually not what decides whether work lands.

Estimates

You will be asked how long something will take, and you will be wrong. Nobody minds being wrong; they mind finding out late.

Give a range with the reason for its width: "two to five days, and it is five if the export format turns out to be undocumented." That is more useful than a confident three, because it tells the other person what to worry about.

Then say something when it changes. A slip mentioned on day two is a schedule adjustment. The same slip mentioned on day nine is a broken promise.

Disagreement

You will think a decision is wrong. Sometimes you will be right.

What works: understand the reasoning first, because there is often a constraint you have not been told. Then argue the consequence rather than the preference. "This will make the migration take a weekend of downtime" travels; "I do not like this approach" does not.

And when the decision goes against you, say so plainly and commit to it. Relitigating a settled decision costs more than the decision did.

Documentation

Write for somebody who arrives in a year knowing nothing. Two things matter far more than completeness:

• Why, not what. The code says what it does. Nothing but a comment says why the retry limit is three, or why this table is deliberately denormalised.
• How to run it. The commands, the environment, and what breaks first.

Handover

You will hand work over, and you will inherit it. A good handover answers: what it does, how to run it, what is fragile, what you would fix next, and who to ask.

That last row is the difference between a week of reading code and an afternoon.