About those lava lamps
gist.github.com
gist.github.com
Now, you may have internalized a lot of this motivation, but at that point it's not a question of willpower just habit.
> Have you ever cleaned up because company was coming over?
Yes, but irrelevant. Note that I don't make an special effort, I just move my regular chores forward a bit so my place is seen at the peak of the cycle, rather than the trough.
That's normal behavior. The point is by moving up the cleaning cycle you’re reducing the time in a trough which increase the average level. Aka 100,95,90,100,95,90... has a lower average than 100,95,100,95,90,100...
PS: Anyway, this is most people. If you’re an introvert that does not have guests it's a non-issue.
I clean routinely and haven't had company over in nearly 3 years. I have absolutely no external motivation to clean my house other than I want my house to be clean. I exercise 3/4 times a week and my garage has become more or less a home gym.
I disagree with /u/ kaiuhl's examples and I'm not sure I understand their point.
My yards are a complete mess because I don't give a crap about how my yards look. I don't remember what my backyard looks like and I see the front yard twice a day getting in/out of my car to commute to work. I cut it from time to time when the sandburs become a problem.
I don't really consider the lack of lawn care to be less accomplished.
Or, it was grass when Nadya bought it, and I assume he doesn't care enough about it to go to the effort to put something else in.
Something other than grass implies caring, which the "I don't give a shit about yards" people axiomatically don't.
Plus I'm not the home owner.
I don't feel like calling the estate management for them to contact the home owner to get permission to tear out the yards and put in a chip or rock then have to go through the hassle of calling a place to order chip/rock, killing off the grass, and... eh.. I just don't care. That's already 5 steps too many to change something I don't care about. Without even getting into the cost of doing so (which is just another layer of "I don't care enough to pay to have this changed")
I think that's the core observation. Some people care about how their house looks. Personally, I don't, so I usually clean stuff up only when someone is coming over. Some, like me, care about how their documents look, or about using interpunction, paragraphs, etc. Others (most of the people I know) don't. There's limited amount of things one can care about, and different people care about different things.
But... as it turns out... it is all for show anyways. When I dig deep into "why" It comes out that I like to be seen as someone who cares and can do things right.
So, agreed.
https://en.wikipedia.org/wiki/The_Theory_of_Moral_Sentiments
http://www.amazon.com/Adam-Smith-Change-Your-Life/dp/1591846...
I realised something after having with someone who likes cleaning. A clean house made me feel better.
Not just the way it looks, but untidiness translated into a tiny little worry-bubble in the back of my mind.
I realised I felt free in a way I hadn't before. So now I clean.
--
I slept and dreamt / That life was joy.
I awoke and saw / That life was duty.
I acted, and behold— / Duty was joy. [0]
--
(Wish HN treated single line breaks appropriately.)
[0] http://workingwithwords.blogspot.com/2009/12/on-duty-and-joy...
"Everyone knew broken builds should be fixed quickly", but each individual felt a benefit of being able to push code without waiting for compilation / tests to run. Breaking the build had a cost, but that pain was being distributed across the team (other programmers finding the problem), and delayed (waiting for them to complain). So the feedback loop was too weak to discourage breaking the build.
This is a classic tragedy of the commons, and far from being "unreasonable" as the author suggests, it's a fairly rational inclination for each individual actor. Other people will find my bugs and breakages for me, and probably do some of the diagnostic work for me too - why wouldn't I pass off that work to them?
Since a team is (hopefully) a society rather than a competition, one answer is "because I don't want to be known as a careless individual who creates work for others". That's why paying attention to the lava lamp isn't "unreasonable" either - everyone can see it, so it makes that social pressure much more visible. It also means the cost of a broken build is less likely to get spread across the team - if someone hits a problem, instead of puzzling for half an hour whether the build is broken or they did something stupid, they can just glance up and see the red lava lamp, and immediately exert social pressure.
By making social pressure stronger and more immediate, the lava lamp pushes the cost of breaking the build back onto the person who broke it. That restores a missing feedback loop, which is often an effective way to change a culture.
"In every job that must be done / there is an element of fun. / You find that fun and snap! The job's a game."
I don't expect the average startup to get anywhere with that (unless they're a games startup), but the bigcorps should be doing this sort of thing, and should be producing tons of evidence in how this-or-that idea works out that startups could just learn from/copy/steal.
Or worse, it could backfire and turn teamwork into a die-hard competition. That happens when you tie the "game" with serious monetary or status rewards, and I think it's considered a pathological situation.
In this case, consider LoL's honor system[1]: an incentive system designed explicitly to reward good sportsmanship, which apparently works quite well.
You own company could make a game out of, for example, technical debt: imagine the equivalent of "carbon credits" handed out for good work, that team-members must then buy from their peers (not necessarily with money) to be able to commit technical-debt-creating code.
[1] http://www.themarysue.com/so-far-so-good-league-of-legends-t...
---
And, on a tangent, here's a bit of a rant: game designers are really wasted on the current trend of "casual game" slot machines. Game design isn't about "how to make people addicted to a game" any more than industrial design is about "how to make people keep pressing the buttons on your radio." Inspiring addiction is what CEOs want, but it's not what game designers are trained in. Companies like Zynga could have done much better hiring people with experience in designing the layouts for casinos and theme parks.
But experience in game design—making games/toys/puzzles engrossing, fun, educational, or whatever-else—teaches game designers a set of skills that are applicable outside of games. It's not just "gamification" (which is almost only used in reference to systems of points and rewards used to bait the Achievement-oriented Bartle types[1]); it's the architectural level of "systems engineering", the same thing done when e.g. NASA tries to figure out what goes into a working satellite: designing the satellite itself, designing the support systems for it, designing an ongoing training system for the ground crew, creating training policies so that new lessons are incorporated back into new training, sourcing replacement parts and sourcing budgets for part-replacing missions and sourcing suppliers when other suppliers go defunct and setting up competitive supply-chains so a monopsony isn't created that chokes the budget... and so forth.
Figuring out how to make a cohesive system, composed of both humans and technology, get something done together, is mostly working out incentives so that the system doesn't fall over from one of a thousand ills. There's more expertise in the pinky finger of an MMORPG Live Team content designer on this sort of topic than in the entire apprenticeship of a civil engineer.
Making a game out of fixing a bug before a lava-lamp bubbles up doesn't make bug fixing easier. It just makes it into a more compelling option than taking off for an early lunch after deploying.
My guess is no. Once a person gets involved in picking the time, it stops being a fun thing to challenge yourself against, and starts being your annoying boss trying to micromanage failed builds.
For a naturally occurring timer, you just work within the constraints you're given. That's what they are and there's nobody to blame or change it. (I mean, you could easily put a lower wattage bulb in, but that won't occur to most people)
Or maybe it's like the placebo effect where you know what's going on but somebody could control the timer and it works anyway. Who knows?
One developer got a little annoyed at this so he cut the chicken's head off, then repaired it with hose clamps. It was sort of a Frankenchicken.
That's exactly what happens when such games are overdone or (ab)used in attempt to "compensate" for programmers being unsatisfied with whichever aspects of the project.
Commonly we see many folks (particularly non-coding managers) treat a nightly build as some sort of indicator of developer competence or code quality. I have even heard anecdotes of devs being fired for breaking the build in a sufficiently large organization (but not the one with the chicken). A successful nightly build is one of those things that's trivially easy to measure and on the surface looks like progress. But of course, the easiest way to never break the build is to just never check any code changes in.
But I believe strongly that a nightly build should be treated as a tool like any other: in any large software project there will be times when a dev makes an honest mistake with the checkin process or simply cannot succeed at testing every interdependency by building on his own box beforehand. So give the devs something to break, and this ought to be the function of the nightly build. If the nightly is so critical to organizational progress that it simply must not be broken, then you need to give the devs something else.
The system should be made to serve its users, and not the other way around.
Shaming displaces camaraderie.
Beheading the chicken was a bold statement.
"100% of software engineers don't like Justin Bieber"
Or for DIY, a cheap micro plus a opto-isolated relay board.
Or just get a particle photon with the relay shield. Extremely easy to set up, and it comes with a REST API.
What are some good ones?
> Or for DIY, a cheap micro plus a opto-isolated relay board.
What does "micro" mean in this context? Microcontroller?
http://smartplug?state=on
http://smartplug?state=off
Then to get the state of the plug: http://smartplug?state
In jQuery this would be a easy call $.ajax('http://smartplug?state=on')
Of course you'd have to code the plug server to add the appropriate CORS headers but that's true no matter how you structure the API.You could either replace 'smartplug' with the local ip of the device or alias it in `/etc/hosts`. All pretty standard stuff these days. If you wanted to expose it to the outside world (which actually should be hard to do) you would use DHCP reservation based on it's MAC address and a DynDNS service.
The part that stymies me (and which no-one seems interested in addressing!) is what hardware to get.
https://hackaday.io/project/6799-smartee-the-smart-plug
I find it pretty incredible something like this doesn't already exist from a major manufacturer! I mean, I understand why Belkin/GE/etc want to lock you into their ecosystem, but it seems not that hard to build an open alternative - and eat their collective lunches.Why? Using it to change state seems precisely wrong. PUT seems more appropriate.
You can see pictures and source: https://github.com/tantalic/build-light