[heads]

I feel like there are metric lurking in here somewhere. Something to do with the following concepts:

(1) the number of documented atomic changes to the codebase, be these merges or pull-requests or changesets or patches — the thing with a title and description that was code reviewed;

(2) the number of tasks in your task management system that might be bugs or feature requests — these are large and must be implemented in pieces, with testing and reviewing of assumptions along the way; and

(3) the time period on which you are required to be held accountable for actually finishing stuff.

I do maybe 30 commits for a big task and will spend six weeks on it. There might be small bugs along the way that get closed out with a 1:1 mapping between task and commit. The majority of the work is a giant slowly but surely moving set of iterations towards a top level goal. The cadence is to review on a quarterly basis.

Not so in the past though. I’ve had to do one commit per task. Multiple tasks in a big bushy tree of verbiage that overlaps too much with the actual commits (the meaningful bits!) and all done on two week cycles. It felt exhausting and piecemeal, as if software engineers were a fungible resource there to further marketing goals instead of innovate the next big things. Nowadays I demand to work for a true technology company, not a marketing company that sells tech.

[nradov]

It's nice to have your labor in high enough demand that you can pick and choose which types of companies to work for. Most developers worldwide don't have that luxury.

[NotSuspicious]

Exactly. It's so interesting seeing the unstated assumptions software engineers let slip out. It really reveals the bubble they live in.