Ask HN: What's one thing you would change at work to increase your productivity?
If you had superpowers to eliminate meetings, lower build times to milliseconds, etc, what one thing would you change? For me one of the top things has to be long build times. I get bored, distracted, demotivated, and I feel like I'm not getting anything done.
Eliminate required start times. I know there is a non-trivial population of night owls that is operating at a fraction of their available brain power because they are chronically sleep deprived.
Don't ask me to "estimate" things. Don't ask me to "spike things". Either something needs to be done for the business to be successful, or it doesn't. If it does, we'll just spend the time, and we won't "spike it" we'll just do it. We may iterate on it, we can design it, think about it, but fuck spikes and estimates. Just spend the time to actually do it.
Doesn't seem reasonable to me.. you need to estimate things to plan. How long is this pizza going to take from when you call in to when you can actually eat? How many people do I need to build this house? Etc etc.
My problem is with people thinking that estimates are commitments. You just gave me a 30 second elevator pitch on a project you want me to build and I said it's gonna be 3 months? Then you proceeded to scope-creep and delay the project start by 3 months and you're surprised we're not done? Ok then..
I suspect this issue is rooted in human nature aka cognitive biases. I don't stress out about estimates any more. They are just like, my opinion man [0].
I'd make a little alarm sound when there are reconciliation issues between different perspectives, so I don't end up wasting effort until I can de-contextualize and identify which perspectives need attention.
For example, if I'm at a point in a project where I need to get a task done:
- The checklist perspective: "Task A must be done."
- But then there's the logical perspective: "How must it be done? There was a recent discussion that affects the process."
- And then there's the time-intuition perspective: "Something is wrong, the discussion included aspects that may alter the way the project is fundamentally designed. If we continue down this path we won't be able to complete the project without a change in approach."
- And then there's the feeling/emotive perspective: "I really hate the way this project keeps changing. It's only fair that we discuss this. Better to discuss it now than later."
- And finally, the checklist calls: "You need a new list for all that new stuff, right? What's the status in making that?"
And these are only _some_ of the perspectives that can complicate things!
Still, it's really helpful to attend to this kind of perspective-integration. Without it, even one outstanding reconciliation can bring things to a sort of inscrutable halt, and _that_ tends to look and feel like unreasonable procrastination.
Plus if anybody mentions the delay, it's easier to make a quick single- or double-perspective decision than to reconcile things in multiple dimensions, which tends to compound the issue but also informs a superior process.
I have some templates I use to work through these kinds of situations, but I'd much rather outsource the alert itself to some external system that doesn't require so much consciousness...
Eh, how many hours is your build? Is a daily build possible, given a normal day on planet Earth?
When I worked at a place that normally had 8-hour builds and sometimes had 30-hour builds, it wasn't bad. Building the software could be done a few times per week. That was fine. Start a build when you head home, then expect it done the next morning or the morning after that. You don't need a build for every little change you make. Complete a few dozen bug fixes or features, start a build, and then keep working on more bug fixes and features while the build runs.
It is suggested to not make mistakes. You get to be good at that.
Be thankful you aren't doing hardware, where a build might take weeks and cost millions of dollars.
My problem is with people thinking that estimates are commitments. You just gave me a 30 second elevator pitch on a project you want me to build and I said it's gonna be 3 months? Then you proceeded to scope-creep and delay the project start by 3 months and you're surprised we're not done? Ok then..
I suspect this issue is rooted in human nature aka cognitive biases. I don't stress out about estimates any more. They are just like, my opinion man [0].
[0]: https://youtu.be/pWdd6_ZxX8c
And they do that because customers want to know when X is going to be done/fixed.
And pizza analogy is inappropriate. Software development is nothing like making pizza.
For example, if I'm at a point in a project where I need to get a task done:
- The checklist perspective: "Task A must be done."
- But then there's the logical perspective: "How must it be done? There was a recent discussion that affects the process."
- And then there's the time-intuition perspective: "Something is wrong, the discussion included aspects that may alter the way the project is fundamentally designed. If we continue down this path we won't be able to complete the project without a change in approach."
- And then there's the feeling/emotive perspective: "I really hate the way this project keeps changing. It's only fair that we discuss this. Better to discuss it now than later."
- And finally, the checklist calls: "You need a new list for all that new stuff, right? What's the status in making that?"
And these are only _some_ of the perspectives that can complicate things!
Still, it's really helpful to attend to this kind of perspective-integration. Without it, even one outstanding reconciliation can bring things to a sort of inscrutable halt, and _that_ tends to look and feel like unreasonable procrastination.
Plus if anybody mentions the delay, it's easier to make a quick single- or double-perspective decision than to reconcile things in multiple dimensions, which tends to compound the issue but also informs a superior process.
I have some templates I use to work through these kinds of situations, but I'd much rather outsource the alert itself to some external system that doesn't require so much consciousness...
When I worked at a place that normally had 8-hour builds and sometimes had 30-hour builds, it wasn't bad. Building the software could be done a few times per week. That was fine. Start a build when you head home, then expect it done the next morning or the morning after that. You don't need a build for every little change you make. Complete a few dozen bug fixes or features, start a build, and then keep working on more bug fixes and features while the build runs.
It is suggested to not make mistakes. You get to be good at that.
Be thankful you aren't doing hardware, where a build might take weeks and cost millions of dollars.