Ways to annoy your senior engineer

1 + 2: Tell them to open a ticket, mark it appropriately, and we’ll do it; but then when you come asking why we didn’t do other things, I’ll show you that chart.

4 + 4b: As a senior engineer, it’s literally your job to interface between leadership, PMs, and junior engineers. “Sync” usually means they want some time to chat about whatever comes to mind — make sure you regularly have these with all major stakeholders. Block out dedicated work hours, but let people consume your time outside of that — it’s your job.

5 + 7: Your job is to manage that we’re paid for features not craftsmanship; hacks are inevitable, but you should leave slack for improvements, document the business case for major fixes, etc.

3 + 8: Along the same lines, help leadership figure out a plan. Unavoidable thrashing happens at times at a startup, but even then, you should talk about roadmaps. Help leadership split the effort between long term goals and immediate payoffs; help them understand priorities.

There are people happier remaining at career IC levels (SDE2 at Amazon) because they don’t want to do these things — and that’s perfectly okay, too.

A 1 hour job will take 2 days.

A 1 day job will take 2 weeks.

etc.

‘As small as possible’? (Aka optimistic)

‘As accurate as possible’? (Aka as low variance)

‘As conservative as possible’? (Aka least likely to ever be exceeded)

‘As cheap to estimate as possible’? (Aka lowest overhead)

Most people have no idea which strategy they are even doing.

> Proper estimations take time.

IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion.

Software development is inherently chaotic. Every task is different from another, and developers can only get a sense of the time and effort requirements once they start working on something. And these are constantly changing during development. It might take a long time to discover that a bug can be fixed by a single line change, or a chain of bugs might be discovered that need separate investigation, or a bug might not exist at all, etc. Every case is different. Additionally, every engineer is different, and they're different from themselves every time. Tasks that require mental effort are unpredictable by definition.

Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless. They only serve to demotivate development teams when they're not met. I wish the industry would move on from them and adopt the more sensible approach of "it's done when it's done". Unfortunately, this doesn't gel with the rest of the business which functions on deadlines, so here we are.

As a lifelong prodigy manager I much prefer stuff like “here’s the spec, how long do you think it will take to type the code in”.