Note: this is (most of) the content from the first post to my Working in the Cloud email list - more are prepared and will go out soon, so if you don’t want to miss the rest you can still join the list here.
About a week after I published the iPad + Linode: One Year Later post, my employer decided to buy me a shiny new laptop for CUDA (GPU) development - a Dell XPS 15 with 8GB RAM, a quad-core i7 CPU and a 512GB SSD drive. It was shiny!
And it was fast. Compile times dropped from 53 seconds to just 20. Test suites ran faster. With 8 GB memory I could run larger tests, or more concurrently. Disk space - always a limitation on the Linode 512 - was no longer a problem.
I’ll be honest: after the first day, I began to have doubts about my future in the cloud.
There were one or two cracks in the armor; a laptop keyboard just isn’t as nice as the Apple Wireless one. It gets unpleasantly warm and it’s just a bit too high off the table. I tried an external keyboard, but then I’m sitting too far away from the screen.
I also missed touch. I never expected to say this, but moving the pointer around with a touchpad or even an external mouse just feels slightly awkward now. It’s less immediate; one more thing for my subconscious to work on.
Having a desktop-class browser is really, really nice though. GMail is more responsive and I can use Google docs like a Real Person again. I can even attach things to emails! Hallelujah!
The one thing I don’t really notice while programming is the screen. Everybody asks me how I can work on such a small or low-res screen with the iPad. Really, I don’t notice the difference unless I’m doing a 3-way merge and need the extra horizontal space.
I spent a whole week working on the new laptop. It was a busy time at work and I was multitasking like an over-caffeinated rabbit, flicking back to my emails every few minutes to clear the next dozen that had arrived since I last looked. Meanwhile, my iPad lay in the corner quietly discharging its battery into the void.
Until Thursday afternoon. It was a splendid autumnal day and as I stepped outside at lunch to pick up some fresh bread from the bakers something in the air called to my soul. You can’t sit inside on the last fine day of autumn, it whispered to me, come with me and be free.
I went back inside, packed up my iPad, some water and a rug into my rucksack and set of, into the great outdoors. Twenty minutes later I was lying in the dappled shade in the vastness of Munich’s English Garden, feeling the breeze playing in my hair as set up my 3G tethering. This is right, I thought. This is the life! And yet at the back of my mind was a guilty question: am I wasting time out here? Would I be more effective sitting back at home chained to The Machine?
I logged in and carried on hacking away at the same bug I’d tried and failed to track down the day before; a subtle problem that spanned several concurrently-running services in our system. I’d grown used to the rapid build/retest cycle of the new laptop and was finding the slower pace of the Linode increasingly frustrating. The air was beginning to turn chill and suddenly this wasn’t where I wanted to be or what I wanted to be doing.
I queued up another build and a set of offline tests to run and checked the time; it’d take a good five to ten minutes before the results were in. Time to move. I told the system to ping my phone when it was done then packed up and got back onto my bike, heading South to find a nice warm cafe to finish the afternoon in.
Back on my bike, gently coasting along the tree-lined paths, my muscles warmed up and my mind relaxed again. My thoughts turned back to the problem; not wanting to waste any more time I wondered how I could most effectively narrow down the scope of the bug. As I was crossing a small bridge I felt the buzz of the notification in my pocket; the builds were ready. Nearby was a small sunlit glade; I settled myself down between a small tree and the stream.
Before logging in on the iPad, I lay back, watched the leaves fluttering against the darkening blue of the sky and finished thinking about the tests I’d run; what the various outcomes might actually mean, and what my next step could be. Once I knew exactly what I wanted to try next, I opened the iPad, logged in and did exactly that - no more, no less. Thirty minutes later I’d solved the problem.
Riding back home, I realized I’d spent the entire afternoon thinking about and working on the problem. Not checking my emails, not writing a quick reply in some barely-related feature discussion. Not reading Hacker News. Just focused on the most important problem of the day.
The same thing happened a week later when I had to write a press release. I’d spent all week putting it off, finding ‘more urgent’ things to do in my emails, attacking small development problems. By Friday afternoon I’d run out of time. I closed the laptop and took my iPad to the window ledge, where I sat with a cup of tea and looked out across the grass, letting my thoughts come to rest.
Then I started typing. Typing on the touch screen is slower than a keyboard, just as compiling on a Linode is slower than on a quad-core i7. Yet again, here the bottleneck wasn’t my typing speed, but my thoughts. The slower pace became meditative, the lack of distractions absolute. An hour later I was done. Later that night our CTO replied saying that he loved it, calling it “quirky, refreshing, and extremely likely to get the coverage we need.”
I’m coming to the conclusion that the speed and generality of a laptop or desktop system is optimizing the wrong thing - it’s increasing the rate at which my brain receives distractions from the true bottleneck in my work: measured thought, repeatable inspiration.
Yet I have one more test left to try, and one that I think might interest you: what if I try to get the best out of both worlds and use the iPad to remotely connect to my work laptop? This is something you could try, too - after a little bit of setup you could take your tablet down to the building cafeteria, or library, or outside, or home, and get a taste for what working on it is like without having to sign up and set up and entire remote server.
I’ve now set this up myself using an iPad and Ubuntu 12.04 laptop and will send detailed instructions on how to do it in the next email. If you want to receive it, click here to join the list.
Thanks, and until then, happy cloud working!
A year ago I said goodbye to my trusty MacBook Pro and started working exclusively on an iPad + Linode 512. It was an experiment at first - one that I never thought would last.
Twelve months later and I find I’m still working like this. A combination of Vim and GNU Screen for development, Pages for writing, Keynote for presentations, Jump and VNC for unavoidable X windows work, Mobile Safari for web apps and a hefty dose of python scripts to smooth off all the edges. I use it for development, for presentations, for my side projects, for everything.
I really mean everything, by the way. A high-speed baby bottle demolished my MacBook Pro screen months ago and I still haven’t got around to getting it fixed yet.
I love this setup, but it isn’t perfect. I’ll be making some changes for in the coming months. Before I get into that, I want to share what this extraordinary year has been like.
In my original post - just one month after I started - I was still using the setup as a light, silent laptop replacement. Now I use it in ways and places I never even considered using a MacBook. It’s no exaggeration to say that, this year, the cloud has set me free.
It’s a crisp summer morning. The clear blue sky promises a hot afternoon, but there’s a hint of freshness on the breeze that ruffles my hair. I smile in the dappled shade of the tree and lean back against the rock. My fingers lazily stroke the screen, scrolling through the feature spec, but my mind is a thousand miles away weighing up design decisions for our new product.
I’m constantly surprised how readable the iPad screen is outdoors. Despite being glossy, it’s much better than the anti-glare MacBook Pro screen. It makes working outdoors not just possible, but enjoyable.
A fine mist of tiny droplets falls over the screen and I casually wipe it clean; working next to the fountain is refreshing but I doubt I’d have risked $2000 of hardware here. The iPad’s proven to be a rugged little thing; it doesn’t seem to care if it gets wet and as my files are remote neither do I.
A buzz from my iPhone tells me my build and tests are finished. I pull it out and glance at the push notification, courtesy of Prowl. New test failures. I finish jotting down my thoughts so far into the Pages document I’m using for the spec then swipe back to iSSH. The tethered 3G connection from the iPhone is great, there’s no noticeable lag as I flick to my Vim screen and hit a shortcut that opens and formats the test results.
Hm, the “quick fix” I came up with on the ride here this morning has caused problems elsewhere. I dive into the code for a while, effortlessly navigating around our million line codebase with an instant code search web app I hacked together using python and flask. Happily, iSSH allows me to forward ports through to the iPad, making it easy to securely use HTML for my scripts and helper tools without exposing any HTTP ports to the outside world.
I finish correcting the fix and push it to our main repository. Jenkins will tell me if it passes on the test cluster in due course. I glance at the time and realize I’ve been sitting here for two hours now. I find I can work almost anywhere for two hours at a time, but to stay in one place for longer I need more comfort than a jumper to sit on and a rock for a backrest! Our mid-morning devteam meeting will be starting in fifteen minutes so it’s a good time to go somewhere quieter for the call.
I throw the iPad and keyboard into my rucksack, wade back across the stream and hop onto my bike. A brisk ride later and I’m back on foot, strolling through trees and flowers with my hands-free headset on in a vast landscaped garden that cuts right through Munich. The call is taking some time to set up. As I’m on 3G, I asked the office team to call my mobile number, but one of our developers is at home and doesn’t have a landline in his study, only Skype. An unexpected hiccup - I feel bad; if I were in an office this wouldn’t have happened.
While waiting for him to start the call with SkypeOut, I discover a rose bush and spend a moment enjoying their rich scent. It feels almost like cheating, working in such a beautiful environment, combining meetings with summer walks through the park. And yet, it doesn’t seem to have affected my productivity at all.
I wish the rest of our team could enjoy walking and talking about the last and upcoming week out here surrounded by nature instead of being stuck in a drab air-conditioned box the best part of a thousand miles away.
Then it strikes me: they could. And yet I worked in that office for six years and I never did. There’s a beautiful castle near the office set in vast landscaped gardens; I could have switched to an iPad + server (one of the office servers would have been fine) and spent a day working there, or any of the other beautiful places I loved to be in.
Of course, back then I used a graphical IDE and the iPad didn’t exist, but surely it would have worked with a laptop, too. Well, unless I ran out of power after an hour or two of multi-core compilation. Or it got too sunny. Or it started to rain. And then I’d have had to worry about finding a nice cafe that also has a free space on a large enough table near a power outlet. So many conditions. So much to fear.
The 10-hour battery life, 3G connection and small form-factor of the iPad + wireless keyboard combination frees me from so much; today I can work wherever I can sit.
A chime from my phone snaps me out my reverie and we begin the call. The wind has picked up, so I mute myself when not speaking and cup the microphone in my hand when I am. It’s not perfect, but the fresh air filling my lungs and the rustle of the leaves in the trees overhead are worth it.
After so much nature I feel like sitting down with a proper seat and table when the call is done, so I cycle down through the park until I reach the Chinese Tower - a beer garden with fantastic benches in the shade. The perfect place to finish my morning’s coding.
At 1pm I leave the park and cut into the city, spending 45 minutes chatting with Matthias from MunichBeta over lunch in a tiny little Chinese place he knows, followed by a visit to Munich’s best ice cream parlour across the street. Matthias lives much as I do, flitting around the city trying out new places to work with his trusty Macbook Air.
This afternoon I’m giving a webinar to prospective customers; I need a quiet conference room and a rock solid internet connection for Skype. My location of choice: Combinat56.
I find a change of scene and some exercise are perfect to ward off any post-lunchtime lethargy and when I arrive at the stylish Combinat56 offices fifteen minutes later I’m feeling refreshed and ready to go.
Running the webinar from the iPad works just fine - Cisco have an iOS app and in any case we’re only sharing slides and dialling in. Usually I just email people the deck and call them on the phone, though; it’s simpler for all concerned.
After the call I catch up with my friends from the Combinat over a cup of tea in the lounge area. You can’t explore on your own all the time; working from home and in cafes is isolating after a while and I enjoy the community here as much as the decor.
While I work, afternoon becomes evening and I sign off from our team chat servers. On a whim, I kick off another round of data analysis on the million song dataset for a side project, then close the iPad and drop it into my bag. Knowing the Linode will keep working away at it, uninterrupted, while I cycle home and enjoy dinner with my wife and children gives me a warm, fuzzy feeling - my tireless robotic assistant, working away out of sight.
And yet not everything is perfect. I love having my data on a remote server and I’m deeply happy with my indefatigable Linode. Surprisingly, the weak link in all of this has become the iPad. And not just because of what it by design can’t do, but because the internet is moving towards richer and richer web apps and Mobile Safari still feels like a toy browser.
Using Google Docs has been a pain all year and it isn’t getting any better.
Having used the fascinating LightTable on the desktop, writing Clojure without it feels like wading through treacle, but Mobile Safari doesn’t have what it takes. I’ve even looked at hacking the engine out of the source and integrating it with the console, for goodness’ sake.
Luckily, splitting my devices between the server and a client means that I am free to change devices whenever I wish. I can work just as well on the twisted remains of my Macbook, a 3-screen office desktop or anything else with a browser, a terminal and a VNC app. My switching costs approach zero. And switch I will.
You see, a surprising alternative has appeared: the Microsoft Surface.
For a while now I’ve been telling people that Microsoft will become the new cool, the inventive underdog, and I still believe that. Windows 8 may be a huge gamble for Microsoft, but Windows 8 RT is a clear win for me.
Microsoft understands the keyboard. I can start, switch and control apps without leaving the keyboard. The device even comes with one.
Sometimes it’s really nice to have two windows open, especially when using video output to a larger monitor. I think the Windows 8 side-dock idea will suit me very well.
Love or hate Internet Explorer 10, I have every expectation that we’ll see the real rendering engine on Windows RT. I don’t care what they call it, if I can run LightTable and Google Docs without gouging my eyes out, I’ll be happy.
Last but not least, the Metro vibe feels fresh and new and I’m intrigued by Microsoft’s choice to make Javascript + HTML5 a first-class way to develop for the system. I’m already looking forward to hacking my own tiles together to smooth my workflow and simplify my day.
Perhaps in a year’s time I’ll be switching to another client. It doesn’t matter, and that’s the beauty of this setup - its flexibility. For me, though, this coming year will be the year of the Surface.
Last year I started this as an experiment, but it stopped being that a long time ago. Today the entire city is my office - its parks, its countryside, its cafes and its workspaces. I have worked on river islands, half-way up trees and on exclusive rooftop terraces.
My side projects are simpler, more flexible and more exciting now my development machine is connected to the internet by a big fat pipe, 24/7. Want to run statistics over 5 years of Gmail messages? Just do it! No need to worry about how long it takes or whether someone will reset the wireless router part way through. It’s simple. It’s pure.
Feeling free to set off into the unknown, assured that I will find a place I can work, to explore and enjoy my surroundings… no, this isn’t an experiment any more.
It’s liberating, rejuvenating. It’s a way of life.
I will not give it up.
Postscript: Intrigued and looking for more? Tempted to try it out one afternoon? I’ve decided to start a mailing list - I plan to write one or two emails a month about my experiences; the highs and lows of this desk-free lifestyle. I’ll also share more practical tips such as setting up a VPN or keeping in touch with the team. You can join the list here.
Breaking news: Today Allinea ordered me a high-end laptop with a massive SSD for doing CUDA development on. Stay tuned to see how the iPad+Linode combination stacks up against top-of-the-range hardware!
Today the visionary Light Table IDE from Chris Granger reached its $200k funding goal. We’re all excited about using it as an IDE, yet there are three things about the project that excite me even more! Light Table can:
Chris’ first concept video was met with some criticism that its values are ill-suited to real programming - say, Java enterprise development. These arguments are valid and yet irrelevant. Not being able to visually test and debug APIs that require complex, opaque class types or database access are not reasons Light Table will fail, they’re reasons some new programmers will learn Javascript and Clojure instead of Java and C#.
Having instant feedback and a great visual playground is so much more compelling than figuring out Ant build dependencies. Not all programmers need to pass ObjectMethodFactoryFactory classes around on day one (or at all, but that’s another topic).
Just because writing to a database isn’t code we can happily let the IDE run and re-run for us with different inputs while we work on it doesn’t mean we won’t use an IDE like that. It means we’ll separate code with side effects from algorithms and business logic. Wait, isn’t that what TDD was about?
Having certain great features not available to functions with side effects is a wonderful motivation for writing as much of the code in a functional style as possible and clearly separating code that’s difficult to test from the rest. Who doesn’t want that?
I can’t name a tool I use every day that was written with a functional language; the only complex one that springs to mind is Emacs - not exactly an inspirational poster-child. Popular wisdom is that functional programming is great for some niche areas or as parts of a solution but that you can’t create serious, useful software with it.
Light Table is written in Clojure, a Lisp dialect, and it will prove this wisdom wrong, wrong, wrong. Or possibly right! But I doubt that - it works just fine for Emacs, after all. No, the perceptions are wrong and it’s time they were challenged again.
Our world could do with more functional programming. I work in supercomputing and it’s clear that massive parallelism is coming everywhere - and soon. Code with explicit side effects and carefully-managed mutable state can be parallelized so much more easily that it’s not even funny.
I believe we’re entering an age in which functional languages will really blossom - and Light Table marks the start of this exciting new period! Good luck, Chris!
Update: Light Table reached its funding goal, and Chris promises to release the source as soon as is practical (see the comments) - everybody wins!
I love the principles behind Light Table, Chris Granger’s excellent IDE concept based on Bret Victor’s incredible vision. It’s up for funding on Kickstarter now, but it might not make it’s $200k goal:
Honestly? I’ll be happy if it doesn’t get funded.
Are you kidding? I love Light Table and I think the world will be a better place for it. I don’t know Chris, but I’ve read some of his code and have a deep respect for him and his work.
I’ll be happy if Light Table isn’t funded because Kickstarter feels like the wrong thing to do. Chris writes:
I haven’t thought about everything - and I won’t be able to… Light Table is meant to be a platform and it will be open source for that very reason… This is the power of a community full of builders… In the end, the only way to move us forward is for the community to rally behind something.
— Chris Granger, On Concepts and Realities
I couldn’t have said it better myself. To me, this makes the choice for how to proceed with the project crystal clear, but Chris seems to have chosen poorly. There are two options:
As the concept video reached 80k hits and the blog post 200k, I’d have been thinking:
Wow, two hundred thousand hits, that’s like - if every one of those bought a licence for $50 then I’d have TEN MILLION DOLLARS and a dream job and would never have any worries ever again! Hooray!
— What I’d have thought, if I were in Chris Granger’s position
There’s nothing intrinsically wrong with this. Clearly there’s a need for a product like this, and if a (finished) version of Light Table for Python existed today I’d drop $100 on it without even blinking. Perhaps even $500 for C++. And I’d be happy to do so.
Chris has chosen this route - trying to build a profitable business - and to his credit he’s also chosen to open source the core of Light Table, albeit in May 2013 after its release. And you still have to pay for a license.
Which brings us to his mistake.
Instead of putting up a kickstarter page, Chris could have put his source on GitHub, written about the principles he hopes the IDE will enshrine and started accepting patches. It would have instantly become incredibly active; he’d have his work cut out reviewing and accepting pull requests, discussing UI design and principles and making his vision real.
Perhaps it would have been valuable enough to the community for him to go full-time, in which case he could have opened a kickstarter to fund himself as the leader of the open source project. Set a low goal (one month’s worth) and then see what the community wants to pay him to do. There are other options too, such as looking for corporate sponsors, or just doing what he can in his spare time and delegating the rest.
The end result is less certainty for Chris, but much more certainty for everybody else.
Compare these two projects, for a moment:
Clearly option #2 is going to be better, both immediately and after 12 months. Trying to develop a community-style project like this with a small team and closed source is a ridiculous mismatch.
There are ways for Chris to get paid to work full-time on option #2, but they ask for a lot of trust - a leap of faith that a community will develop that’s willing to support him. It means taking the chance that the project won’t need him and that it will get along just fine without his full-time attention.
What about later on? Chris and team might get rich selling option #1 licenses for years to come; how can they do that if everything is free and open source with an active, vibrant community?
Here’s the choice reframed: either your time on the project is valuable enough for other people to give you money to do it, or it isn’t. You can open source the project and find out directly, or you can attempt to distort your value by creating a false scarcity, only licensing it to people who pay you.
I don’t know if I could make this leap of faith. It’s still the right thing to do.
Do you really want to extract money from people to work on something the world doesn’t need you to? If not, what are you afraid of?
If you believe the world needs your ideas, if you want to spend some of the few years given to you bringing them to life, then do whatever you can to share them and make these concepts real. In this case, it’s clearly to open source Light Table and trust that the future will bring good things.
Don’t be afraid.
Believe.
Teamwork is a tricky business. I write software for a living and teamwork amongst programmers tends to be defined as splitting up the work such as to minimize the need for any actual teamwork or, indeed, communication of any sort for the remainder of the task.
As a direct result of this, there’s often a short, socially-charged moment in any meeting in which the ‘team’ work is divided up into my work and your work, aka your problem. I’m lead to believe this isn’t unique to programmers.
There are so many little games played here as we jockey for social position, each wanting to get an interesting or easy piece of the work and to avoid the awful, blatantly difficult and unpleasant part that nobody wants to do. Don’t let it be me, we pray.
Those with social clout in the group use it now to quickly snap up the high-prestige-yet-surprisingly-easy work. Occasionally someone without enough influence to snatch a safe piece of work for themselves will throw a victim to the wolves. Well, Jane has always been good at random-terrible-thing, haven’t you Jane, so I guess it makes sense if I do unglamorous-but-safe-task.
Poor Jane.
And like this, Jane - perhaps the youngest, newest, or simply least-liked - ends up doing the work nobody else wants to do:
In other words, nobody wants to do work that’s difficult, risky and thankless. If there was a map of the landscape of work, this bit would be the vague, sketchy part marked simply with here be dragons, where the unfortunate are sent to their fate. I’ve played the don’t-get-burned game and even got rather good at it, which is easier when you realize some participants don’t even know that they’re playing, but that’s irrelevant right now.
You see, I don’t want you to play this game. Yes, you can wheedle your way into a position of some authority by building up your little corner, looking good to your superiors while betraying potential rivals with each step, always making sure someone else gets sent to the flames. And when you reach power, that’s the person you’ll be and the sort of people you’ll be working with.
There is another way. When deadlines are looming and the project is in trouble, people don’t turn to little empire-builders for help and leadership no matter how shiny they are. We don’t want someone to delegate away the dragons, we want a dragon-slayer. In tough times we follow a dragon-slayer because we know he won’t abandon us to our fate. We trust him because he’s proven his worth time after time while others tried to get away. And we love a dragon-slayer, because he makes it work instead of parceling out blame to the weak. A dragon-slayer has a freedom and authority that no amount of empire-building will ever match. That’s who I want you to be.
So when you find yourself in one of these nervous meetings where the work is being divided up, look for the part that everybody’s afraid of being given. You need to stand up and take that before anyone has a chance to react; take it and make it yours. Yes, it’ll be hard and risky and thankless, and sometimes you’ll get burned, but your colleagues will remember that if you hadn’t stood up it could have been them, and they will respect you when you stand up a second time, and a third, and a fourth.
Eventually, you’ll stop getting burned and start emerging victorious, because practice makes perfect and the experience you’re getting is the very best there is - always working on difficult, risky, problems instead of avoiding them and passing them off to the weak; those least equipped to deal with them. One day, you will begin to succeed and nothing will ever stop you again.
But that’s in the future and this is the here and now. Look around you and you’ll see what it is out there that nobody else dares to face. If you want to become a dragon-slayer then you’d better get started - and there’s only one way to do it.
You have to fight the dragon.
Last week I promised to share all the details about my cloud development setup - this is how I did it, in ten soul-crushing liberating steps:
I chose a Linode 512, which has been perfect for my needs. You get all phenomenal CPU power and an itty-bitty RAM. Surprisingly, this is enough as we’ll be doing most of our work on the command-line; you can always upgrade it later.
I also turned on the $5 a month backups. Zero-effort data safety for less than the price of a hot chocolate? Yes, please!
Linode’s interfaces walks you through adding your new node. Pick a region close to yourself - you want to minimize the roundtrip time to the server. I spend most of my time in Munich, so I have mine in London and get a 30-40ms ping, which is great.
I also picked one of their default 32-bit distributions - if you’re not sure or don’t care then just choose the latest Ubuntu and you won’t go far wrong.
After a few minutes the machine will be installed and booted, ready for use! Time to log in and set things up!
I found Ubuntu’s default vim didn’t have everything I wanted, but don’t worry! It’s easy to download and build it yourself:
I honestly can’t remember which plugins I installed and which ones I actually use. My currently-installed list is:
You probably don’t want all of those; I wouldn’t be without command-t though. You can get them all from vim.org/scripts - you might want to install pathogen and get them that way; I just copied the existing .vim folder from my MacVim installation, hence all the cruft.
Note that command-t requires you to build a stub - follow the install instructions in command-t.vim and it just works.
To use the clang_complete plugin, you’ll need clang: “apt-get install clang” should do the trick. I had to play around with it a bit to get it working on my project, which included adding all the -I and -D command-line options to a .clang-complete file in the project directory.
Here’s my .vimrc - some of the things here relate to e.g. our internal tracker system and won’t be interesting for you, but it should be clear what most of these things do and which keys are bound to them:
I don’t recall where I got this from, but it works well for me:
You’ll also want to create a few aliases to connect to different screen sessions painlessly - my .bashrc contains:
You can probably change screen’s escape key in the .screenrc file too; I never bothered to look it up. Here, ‘s’ or ‘t’ will attach me to my work or personal sessions respectively.
Many people have recommended tmux - I haven’t tried it yet; screen hasn’t given me a reason to want anything else.
Feel free to pick a display that makes you happy but make sure it matches the DISPLAY=:5 line in your .bashrc!
I chose an iPad2, (the 16Gb Wifi model). I haven’t tried working over (tethered) 3G yet, but ssh from my iPhone works well so perhaps that’s also an option if you’re often out of wireless contact.
If you already have a tablet that you like, use that instead - all you need is a good SSH client and a good VNC client. On the iPad I use iSSH and Jump for SSH and VNC respectively. I haven’t tried Prompt or Screens, if you already have them then let me know how well they work out.
Whatever you do, get an external keyboard. The Apple bluetooth one is amazing, I can thoroughly recommend it.
You’ll also want an adjustable stand / case for your tablet. Amazon offers plenty to choose from.
The hardest part of setting up a SSH client on a tablet is getting your private SSH key on there without entrusting it to a third party. I split mine across multiple services and removed it after recombining it; maybe you don’t really care.
If you didn’t add the export TERM line into your .bashrc then remember to tell your SSH client to report its TERM type as “xterm-256color” - providing it supports this (iSSH does) then you’ll get to enjoy beautiful soft shades in your remote Vim sessions - joy!
To begin with I used iSSH’s VNC client, which worked perfectly well but was a pain to switch to quickly. Last week I started using Jump instead and love it, it’s a super-smooth experience with lots of cute little touches that make me smile. Swiping to it with the new iOS5 gestures is much easier than changing the view in iSSH and the next update will make it auto-reconnect after the 10 minute background timeout, making the whole experience seamless all the time.
I learned a lesson: take a bit of time and money and try out various different clients. You’ll be spending most of your working day in them; try to smooth out every aspect of the experience.
There’ll be many other packages you want to install - Dropbox and Google AppEngine spring to mind - both can run in console-only modes.
If you’ve followed this far then you should have a fully-connected remote server and tablet client - welcome to the future!
thelongbreak asked: What auto-plugin do you use for vim? Something that can read referred libraries and not just Language standard libraries (boost et al.) perhaps?
I’ve got omnicomplete for python, javascript, c++ etc. installed. It’s ok, but I plan to switch to using clang_complete as soon as I get around to it - you can’t beat the output from an actual compiler!
Update: I’m still using this setup a year later - you can read on at iPad+Linode: 1 Year Later
On September 19th, I said goodbye to my trusty MacBook Pro and started developing exclusively on an iPad + Linode 512. This is the surprising story of a month spent working in the cloud.
It all started when I bought my first MacBook a couple of years ago. Frustrated by the inconsistent usage of ctrl/alt/option/arrow keys to jump words and screens and lines, I searched for a new IDE. Instead, I found Vim and fell in love. This isn’t another gushing post about Vim-oh-how-I-love-you-my-sweet-darling, but it’s important to the story - as we’ll see in a moment.
Although I like to use Python and GAE for my own projects, at work we write heavyweight C++/Qt code that runs on clusters such as the 200,000 processor Jaguar machine, so most of my time is spent in Linux and a lot of it on remote systems. Typically I’d develop in MacVim locally and run my code in VMWare Fusion or remotely.
One fateful day, VMWare and OS/X conspired to trash my shared filesystem, losing several days of uncommitted code in the process. I was angry.
While dd was recovering as much as it could, I started toying with the idea of giving up on local filesystems altogether. To my surprise, it seemed possible - even plausible.
I just had to try.
It turns out you need a little more than just an iPad and a dream, but not too much more:
Total cost: around $800 + $20 per month
I typically start my day by catching up on the bug tracker chatter, mercurial diffs and other emails with the iPad in one hand while lying on the Combinat56 sofa.
I actually hate the Mail app for this; the stupid animation when archiving posts adds unnecessary delay and the archive button is uncomfortably placed at the top of the screen. More recently I’ve been scanning mails over IMAP with a python script instead.
Next, I lazily swipe to Safari and review my tickets for the day in our web-based bug tracker then return to the keyboard and fire off a couple of emails before settling back into coding - the new four-finger swipe gestures in iOS5 have really improved my life.
But we were talking about coding, which brings us back to Vim.
Perhaps the only reason this transition has been so smooth was because my favourite editor / IDE looks and feels almost exactly the same running on an iSSH console as it did running locally on my Macbook. iSSH supports xterm-256color, which means you can still have pleasant colour schemes despite working in a terminal. All my plugins are there, my code-completion, quick navigation and so on.
In short, it’s a seamless transition from my MacVim envionment. If I were developing OS/X apps with Xcode, or used Eclipse or Visual Studio regularly this change would probably have killed me.
As it happens, working in the terminal on a remote Linode is even better than working locally, thanks to the magic of GNU screen.
GNU screen is like a window manager for your terminal sessions, giving you multiple tabs, searchable history, activity/idle notifications and - best of all - persistence.
So I fire up iSSH, tap on my Linode connection and reconnect to the already running screen session. All my terminal tabs are exactly where I left them. Other SSH tunnels are still set up. My cursor is still in the same position. The clipboard is as I left it. It’s as if I never left, because for my side projects, I have a different screen session with a different set of tabs and editor instances running. Perfect separation.
It’s hard to overstate how pleasant it is to be able to return to exactly the same session each day; on a MacBook there’d usually be some other distracting programs left that I’d opened in the meantime, and of course any remote connections would have been dropped. At the very least I’d have used MacVim for something else in the evenings. It might be a largely psychological benefit, but it feels as if I can drop back into flow almost as easily as I left it.
At work we develop a graphical parallel debugger, so I can’t spend all my time in the terminal. For hands-on tests and GUI work I need X. Luckily, iSSH has a workable, if not perfect, solution:
I tap on the VNC connection and up pops the GUI in shocking 1024x768 fidelity and a painful 256-colour palette. I could have 24bit colour, but somehow I prefer the extra speed to beauty. Although it’s a far cry from using a mouse to interact with a traditional GUI program, the on-screen ‘touchpad’ works better than I’d expect. And as it happens, being limited isn’t all that bad:
One good way to evaluate the usability of a program or dialog is to… try to use the mouse with just one finger.
— Joel Spolsky
iSSH’s VNC isn’t quite as bad as pushing the mouse around with one finger, but it does make you consider users with lower screen resolutions, larger font sizes and mouse control that hasn’t been honed by countless years playing Quake and Starcraft. I’d be lying if I said I hadn’t wished for bluetooth mouse support some days.
Today is not one of those days. I unwrap a chocolate croissant, make a fresh cup of tea and settle down to work; a quick hg pull -u && make to start the recompile, then ctrl-x to my editor tab and carry on coding while the rebuild happens. Ctrl-X is my screen’s ‘hotkey’; it defaults to Ctrl-A but on a wireless keyboard that leaves unicode characters in the terminal - I assume this is related to Apple’s support for some common Emacs key bindings in iOS. Strange, but easy enough to work around.
After a few minutes of coding the bar at the bottom of the screen notifies me that my compile has finished; I ctrl-x back, start a sanity test suite running just to be sure nothing horrible was broken overnight then carry on coding again. Compiling on the quad-processor Linode is around twice as fast as inside VMWare on my MacBook was. It’s also completely, blissfully silent. The only sound is the raindrop-like patter of the keyboard as I work. It doesn’t even get warm, a surprisingly refreshing change from the MacBook keyboard!
I swipe to the DuckDuckGo app and look something up in the Qt APIs, then swipe back. It’s becoming second nature, but I still miss a keyboard shortcut for task switching.
After an hour or two of uninterrupted development the UK team wake up and the first instant messages arrive. Thank heaven for the iOS 5 update! I use the imo messenger app, which is fine but of course before the notification center each pushed message would interrupt whatever I was doing with a frustrating popup. Now, the new notifications center behaves much more like a growl notification would; it lets me know and it gets back out of the way again.
I finish the function I was working on then four-finger swipe to the chat app; it’s my boss reminding me about our 11am conference call.
Skype-based conference calls work fine on both the iPad and the iPhone; at least, as well as VOIP calls ever work, i.e. fine after a few false starts while someone reconfigures their linux audio drivers. I appreciate not to having to think about that any more.
During the Skype call my iSSH session timed out in the background; it’s only held for 10 minutes or so. Fortunately a single tap reconnects me, and through the magic of gnu screen I’m back at exactly the place I left off again.
As is always the case, while fixing one bug I encounter another, apparently unrelated one. Time to submit a quick bug report - in the past I took screenshots on the iPad and emailed them to our tracking system, to get around not being able to attach in Safari. Now, I’ve switched to grabbing them and any log files or stack traces with a command-line app on the Linode itself. We use the Best Practical RT tracker (for our sins), which conveniently comes with a perl script to interact with it from the command line. Doing this is actually quicker and easier than uploading via a browser used to be; one command noting the ticket number and the attachments and I’m done.
Lunchtime already! I close the iPad and head off with the others. The remote rebuild I left going will still be there; no need to worry about any uploads getting interrupted, it’s all happening in on the Linode, after all.
During lunch I pull out my iPhone and connect to the Linode again; damn, the build failed early on - out of disk space on one of our office machines. The iPhone keyboard is somewhat painful to use, but for rm -rf /tmp/build-2011-* it suffices. I kick off a new build while waiting for dessert to arrive.
Now I’m feeling nicely fed and just a little dozy; to keep awake I move to a standing workstation and set off some longer-running performance tests on a remote cluster. I find I move around between a lot of different working configurations with the iPad; much more frequently than I when using a laptop. I’m not sure why; perhaps it’s something about having a separate keyboard and screen that makes it easier to find a comfortable typing position, or perhaps it’s just the novelty.
The tests will take an hour or so; I close iSSH and review the latest spec / schedule changes my colleagues have made to an upcoming spec, stored in Google Docs.
In a bitterly ironic twist, the only part of working in the cloud that doesn’t work smoothly is using Google’s cloud-based MS Office replacement. The mobile word processor is a joke, frequently losing the cursor position and sizeable chunks of text. The spreadsheet version is better, but is still a pathetic experience compared to the desktop version. Of course there are no native apps, and the desktop versions of the sites simply report script errors. I’ve even thought of trying to convince my team to switch back to OpenOffice.
Maybe it works better on an Android - no, wait, that’d be anti-competitive behavior and Google would never do something evil, right?
The tests have finally finished and the results are in; I move to the lounge area and connect up to the big HD TV with the VGA cable; something about seeing console-mode VIM in giant HD makes me smile every time.
There are some oddities in the logs; I copy and paste a few snippets to a colleague and discuss them in chat. I’m glad copy and paste work smoothly, although having 3 different sets of buffers (iPad, screen, vim) does lead to confusion from time to time. Idly, I wonder if any of my colleagues have noticed I’ve been using an iPad instead of a laptop for the last month.
6pm rolls around and it’s time to head home for the day. Despite a full day’s intensive use, my iPad’s still showing 15% battery life. I never bring a charger to work and I’ve never needed one. That in itself is a taste of freedom.
Later that evening I pull the iPad out and open up Pages to finish a blog post. The house is quiet; only the distant sounds of the city drift in from outside and mingle with the gentle patter of keypresses on this delightful wireless keyboard.
I started this experiment because I fundamentally believe that most people don’t want to rearrange windows, babysit their own general purpose computers or back up their data. Sooner or later, almost everyone will work like this and I wanted a taste of what that might feel like. I expected to find something that didn’t work, but as the days turned into weeks and the weeks gathered into a month, I found I hadn’t returned to my laptop even once.
I don’t miss the weight. I don’t miss the keyboard getting warm when I’m compiling. I don’t miss its fragility, both physically and virtually. I don’t miss running out of power. To my surprise, I find I am happy. Coding in the cloud isn’t for everybody, but for my workflow it’s a perfect fit and I love it.
After a few minutes the perfect peace is rudely disturbed by the twin jet-engine that is my MacBook fans spinning up to full power on the shelf behind me. I can’t believe I used to put up with this all day and night.
Despite that, I leave the MacBook running - it’s doing the only thing I still need it for on a regular basis.
It’s ripping DVDs.
Update: I’m still using this setup a year later - you can read on at iPad+Linode: 1 Year Later
Recently I started optimizing my workflow with various scripts and tools. I measured my performance and found it increased a lot.
Some people asked to see stats behind the story so here they are, calculated retrospectively from log files for 5 months before the change and 5 months after it.
I’ve been tracking 3 easy-to-measure metrics:
For your viewing pleasure and mine, I’ve tweaked my script to render graphs with the GChartWrapper python module:
I started trying to improve my own performance sometime in mid-January; unfortunately I didn’t keep track of the exact date.
The data are scaled to show bugs fixed per man-month rather than calendar month; from February onward I’ve been in parental leave (Germany’s extremely generous Elternzeit to be precise) and have been working exactly half-time at 18 hours a week.
As a rough measure, let’s compare my performance in Aug-Dec to that in Jan-May, ignoring the fact that I started this scheme mid-way through January and not at the start of the month.
Performance boost: 55.4 / 9.4 = 5.9 times more productive
A changeset can be anything from a bug that was too minor to both putting through the bug-tracking system (such as a message box typo) or a little tweak or extra feature added in passing. Static analysis tends to throw up lots of small fixes that I address with direct commits, for example.
Performance boost: 100.4 / 28.0 = 3.6 times more productive
I started tracking functions changed just out of curiosity; the numbers of tickets fixed and changes committed are open to various levels of manipulation - I thought the total number of functions touched by a change would be an interesting check to make sure I wasn’t just solving all the easiest tickets or committing lots of tiny, pointless changes.
Performance boost: 344.8 / 85.6 = 4.03 times more productive
Nothing about the above measurements or calculations is perfect; simply ignoring December artificially depresses the performance boost, as does treating all of January as the post-boost phase. On the other hand it seems incredibly unlikely that working half-time is exactly half as productive as working full-time.
We could argue that the email and communications burden remains the same when working part-time, so we’d expect less the time to be available for productive efforts. Or on the other hand that most of a full working day is wasted anyway.
We could argue a lot of things, but none of these concerns can account for a 400% increase in productivity.
Not only that, but the number of bugs fixes (5.9 times increase) - is a metric of real value to our company. Generally our software director chooses the set of bugs to be fixed for each release and gives them priorities, which means all those bugs had to be fixed and I wasn’t at liberty to pick all the easy ones.
I do like fixing the easy ones, though.
Whether my measured productivity has doubled or increased ten-fold is really neither here nor there; even just doubling your productivity by any set of measurements over a sustained period of five months is incredible.
I’ve also been a lot happier, which is like winning twice.
“I changed my editor bindings, and now I’m a super-hero coding monster. Also, my breath cures cancer. Hooray for Command-T!”
I’m tired of posts like this too.
I want to make something clear: there are really good reasons that you can’t write a commit script, track your performance and expect it to quadruple. There are good reasons not to even try:
In psychology and the study of education it’s well-known that intrinsic motivation is everything in learning and self-improvement. I already yearned to improve my own effectiveness, that’s why I started doing this. It fascinates me, it calls to me. That’s why it worked.
If you already long deeply to improve yourself, you will do with or without my advice. If you don’t, then drawing little graphs won’t help either. There’s no reason to believe that blindly going through the same motions I did will produce the same result for anyone else.
Your motivations can and do change over time though and maybe reading this will help to motivate you too - I hope so!
It turns out that offering employees bonuses or performance-related pay can be harmful. In some cases - such as programming - an external motivation, such as a bonus, produces measurably worse performance than an internal motivation, such as the love of coding.
Worse still, such an extrinsic motivation will often replace an intrinsic one, damaging performance and job satisfaction.
If you start measuring your performance, you may end up replacing your intrinsic motivation to do a great job with an extrinsic one to make the numbers go higher.
If you start measuring other people’s performance, you certainly will.
Be very, very careful.
So, should I ask for a 400% pay rise now? Am I four times as valuable to the company than I was last year?
No and no. I like to think I’m somewhat more valuable to the company now, but not by a factor of two, let alone four! You see. these stats don’t encompass everything a programmer has to do to produce awesome software; they don’t actually try to - they have another purpose.
It’s like running and football: professional players care about how fast they can run 50m. They even practice sprinting during training. It has some value to them. Yet if you ranked all professional football players by how quickly they can run 50m, you wouldn’t find all the top players at the top.
How would a football team composed entirely of olympic sprinters fare? Exactly. Running fast is one tiny part of playing football. Resolving bugs efficiently is one tiny part of writing excellent software.
Stats such as these are useful for your own training, for measuring and improving one specific aspect of your competence but they are worthless other purposes. Don’t use them for:
It should be clear that single-figure statistics are useless for these goals, but people love graphs and they love putting numbers on things so I’ll state this as clearly as I can:
It doesn’t matter how many bugs you fix per month if your code sucks and the UI looks like a Fukushima control panel after the explosion.
The bottom line is that you can use these stats to measure your own performance increases, but once your goal becomes to increase the stats, you’ve already lost.
Good luck!
Postscript: If you’re interested in seeing my sorry collection of hacked-together python and bash scripts, leave a comment to that effect and I’ll put together a “Metagame: Nasty Hack-Filled Scripts” post for you with all the sources. I’m happy to talk about this on twitter, too.
Edit: Here’s a link to the HN discussion and the Reddit thread for this post.
I’ve been bored at work for many reasons at many different times, but three things stand out as real killers:
These are the symptoms of a problem, not the cause, and I think most jobs will have elements of them. But surprisingly it turns out that - for programmers at least - boredom is a choice. Recently, I chose not to be bored. I chose to think one abstraction level higher. I chose to play the metagame.
I started thinking about programmer performance a while ago. Everybody will tell you that you can’t measure programmer productivity, but this is at best a half-truth. We can, and we should. Perhaps what we shouldn’t do is use those measurements to compare programmers to each other, but we can definitely measure ourselves.
When I started trying to measure my own productivity, it g
ot me thinking a lot more about:
It really doesn’t matter what anyone’s day job is; whether you’re working on sporting result clips for Google mobile or maintaining a 20-year old internal accountancy package the metagame is the same. The product may be pointless but the metagame matters to us all. It’s about:
When I started I was working on bugfixing before a major release, which is very amenable to this sort of thing because there are lots of small, well-defined packets of work. We were about 9 weeks from release and my typical day looked like this:
It was quite easy to measure my own performance in terms of the number of bugs resolved per week. Sure, it’s not a perfect measurement - I could also have factored in the priority of the bugs and so on, but getting an accurate figure wasn’t nearly as important as getting some measure, however rough.
With the goal of increasing my rate of bug fixes motivating me, I started laying into my workflow and adding automation wherever I found an opportunity to speed things up:
Email checking was clearly not related to my core metric (bugs fixed) but I couldn’t just ignore emails, however much I wanted like to. Instead, I added a bunch of extra filters to brutally cull all the emails I didn’t really need to read, then found out how to get keyboard shortcuts working in Gmail (hint: add &kbd=1 to the URL). Now I was whipping through the emails by pressing [ to read-and-archive for 95% of them, occasionally opening extra tabs to remind me of various actions I needed to take later in the day.
Next up was the ChangeLog. I don’t know if you keep a ChangeLog at work, but we have done for a while. The idea is that with each commit you log the broad reason for the change, then write a one-liner for each function you’ve changed, along with the filename, class and method. Writing these by hand was incredibly tedious. Rather than dump it altogether (for it had its uses) I invested a few hours in writing a 147-line python script that generated the entry stubs automatically with inline diffs for each function changed. I added a handful of vim bindings to jump between the ChangeLog entries and replace each diff with a one-line description of it’s purpose. Suddenly, writing ChangeLogs was ten times faster even somewhat fun.
It’s no coincidence that I started using MacVim shortly before my metagame trip. Vim is awesome for exactly one reason:
Writing a script in vim is a simply matter of typing the same characters you normally would to achieve that effect (which is why using hjkl for movement isn’t as stupid as you thought it was). I cannot imagine a lower barrier to customizing your editor. The end result is that vim makes it trivial to optimize all sorts of little common operations; it’s the first editor whose macro functionality I’ve used on a daily basis. It’ll change your life. Learn it. Love it. It’s worth it.
My previous attempt to make my job more interesting had been to volunteer to rewrite our clunky, frustrating GUI-click based test system with a new, streamlined one. Since we use Qt, I added a QScriptEngine which essentially lets you write a small C++ API for your application and then call that from javascript files.
This was a lot faster and less error-prone than manually baby-sitting fragile GUI-based testing as we’d done before, but the real benefit was that I had complete control over the system. Every night it ran tests across dozens of platforms and reported any new failures directly to our tracking system. I started adding extra code to our test-runner (a 1,500 line python script) to make reproducing and fixing bugs stupidly easy. Each test report now includes:
Adding this one piece at a time wasn’t a lot of work, but it has saved us hours and hours and hours.
I spend a lot of time on our test machines, so I added hostname auto-complete to my bash shell, added single-line aliases to change to the test directory, check out an overnight build, view the build and test logs, change to the test user and so on. I learned to love .ssh/config, and so should you.
Saving a few keypresses doesn’t sound like a big deal, but it makes me happy every day when I type:
cs
smoketest -kri 14956
to switch to the latest test directory, update its license file and re-run the bug reported in ticket 14956. I could write an essay just on this:
every single element of cognitive burden removed makes it easier to stay focused on the task in hand
Not having to remember a hostname, or a compiler directory, or keep track of which system I’m on, streamlining all that away makes it trivial to keep thinking about the problem and not the distractions.
I ended up adding lots of vim shortcuts specific to our systems. It’ll look up and fill in the title of any bug ticket for me. It’ll commit my current changes, automatically taking the ChangeLog entry I just wrote as the commit message and optionally resolve the bug ticket associated with that change using the same message. In one command.
Typing that one feels really good.
Bundling up all the points at which I’d otherwise have to switch to a browser, wait for a page to load, this was accidental but brilliant. Waiting is the death of focus. By wrapping it all together into one fire-and-forget command, I can just say the word and then start choosing the next bug to fix, keeping my momentum and focus intact.
Every week I find new places to tweak my setup or semi-automate more tasks. I’ve started producing beautifully-formatted HTML change diffs for code review on my iPhone, while reclining in one of Combinat56’s Sumo bags with a cup of tea. I’ve added extra notifications when a build fails or a test machine runs out of disk space.
I will never be done, because I can always keep moving one abstraction higher until I’m purely working on the most interesting problem of all: how much of a programmer’s job can be automated?
A nice side-benefit is that much of the code I write to automate things is not production code; I can write it however I like, using whichever languages and tools take my fancy. Yet it all goes towards making me - one day - into an extraordinary programmer.
After working like this for six months or so, the following pieces of advice seem like the most important to remember:
That’s it - print this list out, stick it next to your monitor then close the browser and start playing the metagame! You weren’t going to do anything more productive in the next hour anyway, right? ;-)
Update: just in case you’re not heading off to work, the HN thread is here and the Reddit thread is here.
[1] Disclaimer: I work with absolutely first rate programmers, people I learn from every day and yet there’s still an attraction to meeting new people too; I shudder to think what it must be like to work with dull people for years and years…