Agreed. I think being able to predict what is likely to change is heavily dependent on knowing the business domain well since that is going to be the driver of change. I think it is a specific application of curiosity. It's also a matter of being forward thinking in general. I think both are skills one can foster and can apply more generally.
I also really like this feature of GitHub reviews and when deleting a comment as I continue reading I try to question whether to add a code comment so the next person doesn't get tripped up because they don't have the full context in their head.
You can do this in vim with the scrollbind option. You could create a simple script to set up the windows and get the views lined up to the correct line numbers. The one caveat is that enabling line wrapping will screw it up.
:windo set nowrap
:vsp
ctrl-w ctrl-w ctrl-d ctrl-d
:vsp
ctrl-w ctrl-w ctrl-d ctrl-d
:windo set scrollbind
Some other very handy shortcuts in MS Office programs (and maybe others) is alt-shift-up/down arrow will move the entire line up or down. Quite handy to move text around when composing an email for instance.
Ctrl-up/down will move the cursor past newlines, so you can more quickly navigate when there are long lines with lots of wrapped text.
I think stories like this show up because there is a set of Amazon users that still want it to be a neutral marketplace where Amazon doesn't have a vested interest in one product selling over another. That hasn't been true for quite a while though.
I think a large part of this topic isn't about a team making a promise and not living up to it. It's about a business (management) wanting to make a promise and getting the team to accept responsibility for it. So let's assume the estimate is very accurate but the business wants it done in half the time. When the project runs past that date being able to point to a very accurate estimate and say I told you so isn't very productive. So we need strategies and techniques for dealing with the mismatch between the desires of the business and what can actually be delivered in a given amount of time.
TFA advocates for bargaining on scope, where I prefer to start the conversation by asking about both scope and timelines to understand which parts of the overall request are negotiable. This is also a great opportunity to make sure the business context is well understood so everyone understands what success means from the perspective of the business
You might then find every single feature really is necessary and the timeline can be relaxed. Audit compliance can be an example when it is something new to an org. You are either going to pass or fail the audit, so there isn't really room to reduce scope. But you may be able to negotiate on the timeline.
I think there's a large difference between arbitrary deadlines that the team themselves set and buy into as a rallying cry vs. an arbitrary deadline that was externally imposed upon a team, often without full context provided to understand the relative priority of features as well as whether the deadline itself is negotiable.
"Apparently" makes it sound a bit like Holmes was something other than a fictional character, composed only of Doyle's beliefs about what would make an entertainingly eccentric genius. It's not even what Doyle thought would work!
If you are editing over a network connection and you normally have cursorline on, then try turning it off. That makes a big difference for me when there is network latency.
