Econometrician at Amazon; formerly taught at Iowa State. Obviously everything written here reflects my own opinions and not my employer’s.
- grayclhn parentWe sure as fuck developed specialized parts of our hands…
- Some of the things you listed are bad practices, some are bad outcomes. Change the bad practices (no version control, no beta environment, etc) and use them to prioritize and change the bad outcomes over time.
At least half of the stuff you listed will probably never change. Congrats! Being the senior person means becoming comfortable with people making objectively worse decisions than you would, and putting the structure and architecture in place so that it still works anyway. As a bonus, most of those “objectively worse” decisions can be really good and better suited for the team than your decisions would have been ;).
- Obligatory: https://www.nohello.com/
And as a blanket rule of thumb, don't send people chat messages that you wouldn't want to see displayed to an arbitrary meeting full of people. :)
- Splitting up a groundbreaking idea into so many papers that the idea is lost is 1) going beyond a “minimal publishable unit” and 2) not in the authors’ interest, since getting credit for a groundbreaking idea in a correspondingly prestigious outlet is much better than getting credit for 2 or 3 bad ideas. I’m sure there’s a level of novelty where 2 irrelevant papers is better for the author than 1 single paper, but I don’t think we should design academic publishing around slightly-better-than-mediocre contributions.
- IDK, I think tenure contributes a lot to 1. I understand and agree with a lot of the rationale (academic freedom, etc.) but when you select for people that prioritize, “if I work really hard for 6 years and get lucky, I can never be fired,” you get a lot of dysfunctional individuals and encourage some of their worst impulses.
- I would for sure want to know why a company was using svn or fossil for source control (just to take two examples)… there might be good reasons, but either one suggests that the company may not be making the right trade-offs.
(Nothing against fossil, it sounds lovely. But there needs to be a good reason to choose a niche product here.)
- Use data on how long it takes to complete “projects.” Or break the project down into your best projection of the component tasks and multiply “number of equivalently sized tasks” by “average time to complete that sort of task over the past X months.”
Regardless, “collect and use data from the past,” does not require a “completely steady state,” and is pretty easy to modify. I’d feel a lot better having a conversation around, “this is totally new, do we think it will take about 2x or 5x longer than our normal projects?” Vs “this is totally new, so everyone guess how many months it will take without looking at any relevant data on either past project duration OR the accuracy of your past guesses.”
When people talk about “estimating task size” they almost invariably mean some planning-poker version of the second. Especially in TFA where they bring up forecasting as a better alternative.
- >> Stop estimating.
> How does this person think an organization schedule, budget and allocate resources?
Collect data and use a trivial prediction model (i.e. median calendar time it took to complete the last 5 stories). Monitor and improve the prediction model over time if necessary. If you’re not collecting data reliably enough to generate a prediction automatically, you’re not taking any of these issues seriously anyway.