Work is Fascinating: The Metagame | Hacker News Reader

Work is Fascinating: The Metagame

yieldthought.com

114 pointsmoconnor21 comments

I think this is pretty much spot-on. I've always called it 'removing the pain-points' because any time I get sick of something, I automate it. Sometimes that's after 3 times, and sometimes it's 100. But if I start to hate it, I automate it.

I do choose to remove some of the pain points differently, though.

I write things in the newest languages at home, rather than at work. Anything I do at work should be re-usable by anyone on the team, and that's hard if it's in some fancy new language that nobody else has looked into yet.

Rather than sort through email manually, I set up filters. Then I scan the subjects of all the new emails in that tag, read the ones that are important, and then mark the rest read all at once. (I don't have to archive because I set my filtered email to never hit the in-box.) GMail has some nice shortcuts as he noted. I use this to mark all unread messages as read: UIN (Select all unread, mark read, unselect.)

I also streamline anything I'm asked to do repeatedly, like add new fields to a form. I know I'm going to be asked to do this constantly, so now it's just a matter of adding a little metadata and the rest happens automatically.

And I also put everything I can into the hands of others, so long as it doesn't involve changing code. If there's a list of Titles that change a lot, I give the ability to change them to whoever requests it. (Business rules are what stop them anyhow, not me.) Then I don't have to do that any more. (That's rather simplistic, but I can't give more elaborate examples for fear of breaking my NDA.)

> "I've always called it 'removing the pain-points'"

I call it "removing friction".

Just like in physics theory a weight would fall according to f=m•a whereas in real there is fluid friction, in an "ideal" world I'd just think only about relevant information and my thoughts would command actions I want to do on the computer instantly, but this world is not ideal and introduces friction. Which produces an awful lot of drag.

Friction can be taken away, up to the point of reaching wizardry, at which point one simply waves a hand at friction-inducing minute problems to move them out of sight and concentrate on the Real Problem At Hand.

Regarding putting things in the hands of others: another good example is data analysis. Say you're the sole programmer at a startup and all your time is focused on building your product. But you also have lots of data coming in that needs to be sliced up and visualized. Write a script that sticks your data in a format your business-types can easily work with (hint: spreadsheet). And let them go at it.

Of course this is a general approach for analysis. Get the data into a tool that makes data exploration easier: R, Excel, matlab. That rather than writing lots of custom scripts.

For those who have a longer procrastination time ahead, you might prefer (re)reading http://www.paulgraham.com/philosophy.html than elaborating on definition loops. It strikes me how simple and yet deep are PG insights on topics that seem to be outside his usual field. Here he just proposes to take Aristotle in one hand, Wittgenstein in another, wrap all philosophy in between and throw the thing over board. Then rebuild from scratch, changing the partially wrong premisses from metaphysics (general useless ideas) to science (general useful ideas).

Someone knows if this article had some echoes in the philosophy field? Or was it completely ignored?

I don't know of any impact on academic philosophy from that essay in particular. But in general, the Quinean school is much more friendly to empirical considerations than historical philosophy. For example, Daniel Dennett has said "AI makes philosophy honest," and people like the GAI researcher Eliezer Yudkowsky do some damned good philosophy.

The article has its merits, but the ideas it expounds aren't new at all.

I believe doing stuff like this is one of the big contributors to making a "10x-100x" programmer. The best programmers don't have to perform 20 clicks in their browser every 10 minutes. Everything is streamlined so that real work can get done.

Your multiplier also goes way up when you do work that makes everyone else in the team more productive. The test automation improvements in the article (automatic screenshots of the gui for failing tests) are good examples.

Advice is good, but to escape boredom it's a lot better to work towards having a passive revenue stream or fuck-you money, but I believe a steady/passive revenue stream is more achievable for most people.

Have you got any good advice on building passive revenue streams? I for one would love to read more about this; the only people I know doing it are really just putting out MFA pages. Actually creating software and selling it, well that's not exactly passive either :-)

My current passive revenue stream is low, as in I cannot afford to make a living out of it and still have a day job, but it is continually improving ... so I may not be the best source for such advices.

That said there are 3 advices that I've heard and that seem to work for me - (1) it takes an awful lot of time for going from zero to making a living, as in at least 3 years if you're lucky or really good, (2) whatever you do, it needs to be a low-enough effort (as in a couple of hours per week tops), otherwise it isn't sustainable and (3) you must not put your eggs inside a single basket.

Building software and selling it is a great source of revenue. It is also passive revenue. If you're good at building software, then do that. It doesn't matter what you do much, as long as you're good at it. Some people earn indecent amounts of money just by blogging.

I'm also interested in this topic.

Who are your influences on the passive income front? Any blogs/sites/books you'd recommend?

But you can't really do that while you're on the clock.

Interesting stuff, but I'd really like to know the before-and-after numbers. You've talked about a lot of optimisations, and metrics, but how much did the optimisations actually optimise your workflow according to the metrics?

Lots of good advice, nonetheless - and an actual reason to look at using Vim!

If there's any interest I'll happily do a more in-depth follow-up post with my specific numbers and scripts. My metrics (bugs fixed, commits made, functions changed) all jumped by roughly a factor of 10. Yes, really.

There's definitely interest -- on my part anyway. I'd be especially interested to see the scripts you used. I'd love to be doing this sort of thing, and more specifically what others have done would be helpful.

Waves an interested hand.

I went to VIM because of the powerful things you could do. Search and replace is usually tedious on IDEs, involving windows that popup and disappear, and retyping things a lot. Experimentation on changing is usually quite time-consuming.

With VIM, you try it, and if it doesn't work, a single keystroke gets you back where you were and a couple more retrieves the last thing you tried, which you can edit.

Similarly, moving or changing chunks of text is much easier on VIM than any IDE I've ever found.

And finally, you can have all that power on any system. I've yet to find a server that didn't at least have VI, and usually VIM.

Other great blog post on the same subject: http://timothyfitz.wordpress.com/2009/02/11/cycle-eaters/

Heh - I wrote a post on the same subject a while ago, also, but I called them "Time Vampires". "Cycle Eaters" is a great name.

(That post: http://guerillashowrunner.com/2011/01/time-vampires-stop-the...)

Both great reads, especially interesting to see the same effect crop up in another field; I wonder if it's actually quite well known...

The real Metagame: (Louis Kauffman. Popularized by Raymond Smullyan) http://docs.google.com/viewer?a=v&q=cache:yWUkoenw47oJ:w...

Reply on news.ycombinator.com