Hacker News new | past | comments | ask | show | jobs | submit login

While I don't disagree with the conclusion, I'm not sold on the argument.

It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.

Someone who's young, just got their first job, needs the money and is insecure about their ability to get another job will not take the same risks as someone with a decade of experience, that has a network and knows they can get a new job if they need to.

Similarly someone close to retirement might have the most to lose in the few years before pension kicks in.

So it rather seems that what we need is to give people a work environment where they don't have to be afraid of speaking their mind or making mistakes.




> While I don't disagree with the conclusion, I'm not sold on the argument.

> It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.

Wholeheartedly agree.

Notably, this is also the underlying key to accelerating a team's velocity, whether we're talking about TDD, CI, blue/green deployments, database schema rollbacks, canary releases, blameless retrospectives, Lean Startup MVPs, or many other tactics.

The basic strategy is: focus on reducing the cost of making a mistake (and learning from it) instead of on making fewer mistakes.

Because the easiest way to make fewer mistakes is always to do nothing (alternatively, "nothing interesting", or "nothing new", etc.).

Developing without fear isn't so much "move fast and break things", it's more "Move fast and have an undo button (for anything important you might break)."


As a personal analogy, we're currently redecorating our home. We've just spent about 4 days planning the layout of the electrical boxes and wiring pipes for a small hallway. Once it gets covered by the rock sheets and all that it's a PITA to make a change.

Once we had rechecked everything for the n-th time, the job of mounting it all took about half an hour.

This is in stark contrast to software development with git or similar, where there's little to no fear when making radical changes, as it's easy to undo, have multiple versions in different branches for comparison etc.


Right, but the correct analogy for putting up the drywall is deploying to production...


At work we have a launcher that lets our users select one of the five previous minor versions of potentially multiple major versions they have installed. A local service checks for new versions every hour and downloads them automatically.

That way we can deploy to production quickly and with far less worry than before we had this system. If a user runs into a blocking issue they can just re-launch a previous version and continue working.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: