10/04/2013

10-04-13 - The Reality of Coding

How you actually spend time.

4 hours - think about a problem, come up with a new algorithm or variation of algorithm, or read papers to find an algorithm that will solve your problem. This is SO FUCKING FUN and what keeps pulling me back in.

8 hours - do initial test implementation to prove concept. It works! Yay!

And now the fun part is over.

50 hours - do more careful implementation that handles all the annoying corner cases; integrate with the rest of your library; handle failures and so on. Provide lots of options for slightly different use cases that massively increase the complexity.

50 hours - adding features and fixing rare bugs; spread out over the next year

20 hours - have to install new SDKs to test it; inevitably they've broken a bunch of APIs and changed how you package builds so waste a bunch of time on that

10 hours - some stupid problem with Win8 loading the wrong drivers; or the linux dir my test is writing to is no longer writeble by my user account; whatever stupid computer problem; chase that around for a while

10 hours - the p4 server is down / vpn is down / MSVC has an internal compiler error / my laptop is overheating / my hard disk is full, whatever stupid problem always holds you up.

10 hours - someone checks in a breakage to the shared library; it would take a minute just to fix it, but you can't do that because it would break them so you have to do meetings to agree on how it should be fixed

10 hours - some OS API you were using doesn't actually behave the way you expected, or has a bug; some weird corner case or undocumented interaction in the OS API that you have to chase down

40 hours - writing docs and marketing materials, teaching other members of your team, internal or external evangelizing

30 hours - some customer sees a bug on some specific OS or SDK version that I no longer have installed; try to remote debug it, that doesn't work, try to find a repro, that doesn't work, give up and install their case; in the end it turns out they had bad RAM or something silly.

The reality is that as a working coder, the amount of time you actually get to spend working on the good stuff (new algorithms, hacking, clever implementations) is vanishingly small.

6 comments:

Aaron said...

Heheh, and and if it's a user-facing product:

400 hours getting the UI for it right.

RandTheDragon said...

Or you could....build it as a web app. Desktop development is dying

Elliot said...

This is somewhat more dismal than my experience. I think there's a kaizen-style fulfilling contentedness that comes from honing the thing you're making and redesigning it and deciding not to add features and thinking deeply about whether it's worth adding the slightly different use case.

That application of judgment and taste, and the corresponding playful experimentation to try different directions of each thing, represent most of the time programming for me, and they along with the joy of hearing about or seeing people use your stuff and have it improve their lives, are why I still program. A little bit like Jiro in the endless honing and pursuit of improvement and growth, but hopefully not as crazy.

I don't think that stuff is restricted just to new algorithms. I think any kind of coding as long as you're not boxed in by bosses and coworkers can be like that, if you let it.

cbloom said...

@Elliot - Of course this post was written in a dreary moment of waa waa programming sucks. Sometimes I like it.

But I do think that *in isolation* the actual work of programming does just suck horribly 99% of the time.

If you love your product, for whatever reason, you think it's important, or you think it's a beautiful piece of code, or you're proud of how it works - if you have that love, then fiddling with it and doing all the shit work is okay.

All real products are actually really awful code. Code starts as a little gem that is inherently beautiful in isolation, and as the product becomes more real the code gets worse and worse, until it's shippable and the code is just appalling.

When people are actually using your stuff, and doing cool stuf with it, that kind of makes everything okay. Even the most horrible grunt work programming can be fun if you're delivering tools to artists who are using it to make something amazing, and you're talking to them and have a bond and so on.

(humans can enjoy the most horrible things in the world (like even war) if they have a team that they love and feel bonded with or feel like there's a reason to it).

Elliot said...

I have experienced that crappiness a lot, but the best guy I ever worked with, named Trevor Blackwell, clearly did not have that problem very much. He so thoroughly and transparently enjoyed fiddling with random bits of code that you could even tell just by reading it; it glowed with play and hackerliness.

He wrote an essay about how C++ is nice because it gives you an excuse to futz with things, which also betrays a completely crazy love of programming.

And, of course, not coincidentally, he was absolutely superhuman in everything he did with a computer and basically any software task was better accomplished by making him coffee than by trying to do it yourself.

So, since then, and also prodded by this, I have tried to cultivate that pure delight in frobbing a frob, and I have succeeded some of the time in making things less dreary partly just by believing that I could enjoy them if I decided to. And, I think some of the resulting software has been better as a result, even after it shipped.

cbloom said...

I dunno, fiddling with code is all well and good, but I believe that even that aspect of coding is less than 5% of the actual time spent.

If you had an observer with a stop watching counting the actual minutes spent doing anything that could be considered "hacking", I bet it's less than 5% of the average day.

My time is spent on the Durango build failing because the manifest format changed. Or one of my obscure APIs is failing on Linux. Or I have a bug that only occurs on 2G+ files so it takes hours to reach in the debugger. etc. etc. etc.

Obviously it varies by job, but I suspect that all coders actually spend much less time coding than they think. I suppose that's part of why so many coders choose to code in their free time - because they're not actually coding at work.

old rants