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

Sounds like good motivation to do shit work just to get it done on time.

Inversely, offering rewards can be just as counterproductive.

https://www.nytimes.com/2018/10/27/opinion/sunday/science-re...

If it helps you maintain intrinsic motivation then it may be of benefit. Maybe depending on the person a gentle reminder or a wakeup call works best, but the motivation shouldn't be focussed on getting a pat on the back or to avoid someone yelling at you.




> Sounds like good motivation to do shit work just to get it done on time.

You say this like it's obviously a bad idea. Why?

The more work you do, the better it will be, even if you're not trying for any particular quality level. Most people have much more of a problem with the amount of the work they do than with the quality.

I read of an experiment conducted on a college pottery class. Half of the class was told they would be graded on the quality of the pots they produced. The other half was told their grade would be determined by gathering all the pots they turned in, smashing them, and weighing the pile of shards. The heavier the pile, the better the grade.

The grade-by-weight group turned in higher-quality pots.


I remember hearing of this before - I think it tells us a huge amount about how best to achieve our goals, or to coach others in that regard.

For example: ask a team to build a software project with excellent design and best practices and they may hit "analysis paralysis".

Ask them to build perhaps 5 distinct - but cheap and disposable - implementations and you might find they get a much better idea of how to do things "right" very quickly.

Note to self: remember this for future use!


This appears to be an example of Facebook's "move fast, break things" axiom, or an example of "make it work, then make it good.

I'm not sure where the latter comes from, but I've read several startup case studies that began with founders who did everything by hand at the beginning (just to see if their process worked).


> excellent design and best practices

Sounds like a sure fire way to spend all the time on premature optimisation.

Scott Guthrie at Microsoft used to talk about rapid prototyping, and to always throw away the prototype code and redo from scratch. Never keep the prototype, and especially don't just push it straight into production.


Exactly my point! That's an excellent technique in fact, tell a team upfront this will not be allowed to evolve into production and, freed from unease about future plans, they'll explore and experiment much more openly.


> You say this like it's obviously a bad idea. Why? I think the article he cites answers this question.


As far as I can tell the article basically says: If you reward people for doing something, they will stop liking to do it and quality will suffer.

BAAS helps people to do something they set out to do, but can't get themselves to actually do it.

It seems to me it doesn't really matter if you start to like it less, since you already don't like it enough to get started. And the quality point is moot, since it's better to have something shitty (that you can then improve), than have nothing at all.

Don't forget that actually getting started is the most important part of doing something. An effective way to finally clean up the kitchen is not to plan 2 hours for it, but to just take 2 minutes to wipe the countertop. Before you know it, while wiping the countertop you move stuff back to their proper place and two hours later the kitchen is done. And if not, then at least the countertop is clean again, which was better than leaving it dirty.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: