Beware of the Train

Happy New Year! You're all no doubt itching to learn how I got on with my 2016 New Year's Resolutions.

[Content note: weight loss/gain]
( Read more... )

Previously on posts tagged with 'angst' (mostly friendslocked): our hero became depressed, sought help, and is now (mostly) feeling better. Now read on...

John Walker, in his excellent book The Hacker's Diet, distinguishes two approaches to tackling problems, which he calls the Manager's approach and the Engineer's approach. Management is about monitoring and ameliorating chronic problems to keep their symptoms to within an acceptable level; engineering is about solving problems outright. Most difficult problems, he claims, must be tackled using a combination of both approaches.

My problem, which might be summarised as "I became depressed because I suck at my job", has so far responded well to a management approach: leaning on friends, attending CBT workshops, prioritizing exercise, talking to my supervisor about my problems. I'm very grateful to all of you for your support, and to the Glasgow NHS mental health team. Now that I'm feeling a bit more spoonful, it's time to apply the engineer's approach, and suck less at my job.

[A perhaps more honourable alternative would be to find another job at which I wouldn't suck, but that would be fraught with risk, and my current job has much to recommend it. Besides, I'm not sure that such a job exists.]

I have three basic problems:

1. I'm not a good enough programmer;
2. I don't know enough about the problem domain;
3. I am now effectively an experimental scientist, but I don't know anything about experiment design.

On the first point, I'm reasonably happy with the readability of my code, but I'm unhappy with its testability and correctness, and I'm very unhappy with the time it takes me to produce it. I'm frequently struck by analysis paralysis. I've spent most of my programming career working with high-level languages, so I'm not very good at lower-level programming. I think the only solution to this problem is to write (hundreds of) thousands of lines of code, at as low a level as possible.

On the second point: before starting this job, I'd previously worked at a compiler vendor and at a web startup which did some machine-learning; back in high school, I'd done some assembly programming for an embedded system. I'd also done a bit of background reading on compiler theory. It turned out that this was insufficient preparation for a job using machine-learning to improve the state of the art in compilers targetting embedded systems. Astonishing, I know.

There used to be a cute slide in the Edinburgh University first compilers course:



Now, that's true for compiler theory, and it explains why compiler research is still a going concern after sixty years, but it doesn't explain why day-to-day hacking on compilers is hard. For me at least, that's because hacking on compilers is systems programming. You need to know, at least to the level of "understand the basic principles of and can look up the details if needed", about things like addressing modes, instruction set architecture design, executable layout, and calling conventions. Forget the fat guys who know C++ who apparently keep Silicon Valley running; I work with guys who know Verilog and the GNU ld control language.

[Betcha didn't know that the GNU linker embeds a Turing-equivalent programming language :-)]

Now, none of this stuff is especially difficult as far as I can see. But it's a lot of background knowledge to have, and if you lack it then you'll be constantly hitting problems that you lack the mental toolkit to address. So here's what I'm doing about it:

• To address the patchiness of my knowledge about machine-learning, I went to the library and got out a couple of ML textbooks, one of which I've now read. I've also signed up to the free online machine-learning class from Stanford, and, while I was at it, the Introduction to AI class too.
• To address my ignorance of architectural issues, I'm auditing the computer design undergrad course at Edinburgh; when I've finished that, I'll audit the follow-on course in computer architecture. So far it's mostly been the sort of boolean algebra and digital electronics that I learned at my mother's knee, but there's a lot of stuff I don't know later on in the course.
• Linkers are a particular problem for me; I think linker errors are the Universe's way of telling me what it's like for a non-techie who thinks they need to press the "any" key. zeecat kindly lent me a copy of Levine's book Linkers and Loaders, which I am now reading; as an unexpected bonus, one of the early chapters is a 30,000ft tour of computer architecture. To my delight, the book walks you through the construction of a simple linker in Perl.
• To address my lack of C and assembly language experience, to solidify my understanding of basic compiler theory, and to give me a testbed for implementing some optimisation algorithms later on, I started writing a simple compiler in C. Currently it accepts a simple term/factor/expression grammar and outputs x86 assembly; the plan is to extend it so it accepts a subset of C. "Compiler" is currently a bit of a joke; it is technically a compiler, but one that does really aggressive constant folding :-) I haven't hacked on this for a while, because work got in the way, but intend to pick it up again soon.
• To address my ignorance of C minutiae, I started reading through the comp.lang.c FAQ, at Aaron Crane's suggestion. This is also stalled, as is a project to convert said FAQ to a collection of Mnemosyne flashcards.
• The world seems to be standardising on Hadoop as a clustering solution; I should try that out at some point.

So, anything else I should be doing? Anything in that list I should not be doing?

I have no real idea how to start addressing my third problem, namely my ignorance of experimental design. Go to the library and get another book out, I guess. Anyone got any recommendations?

In Clackmannanshire, where wormwood_pearl grew up, the word "minky" means filthy, messy, disgusting; there's a heavy connotation of shame. "Ugh, this kitchen's minky!" An approximate synonym is "clatty".

My friend buffalo_gill, who is from... somewhere in England, uses "minky" to mean great, excellent, cool: "that party was minky".

In the teenage fiction of Joanna Nadin, "minky" is a noun meaning "vagina": "According to Sad Ed, it is the law to have been sick on Strongbow and have seen several willies (or minkies in his case) by the end of Year Ten."

So I was delighted to see this at the shops yesterday:

wormwood_pearl's brother, who is a cycle instructor, very kindly gave us a copy of John Franklin's book Cyclecraft. There's an exercise on page 83 for which you have to look at a photo of a town road, identify all the hazards, and plan your response to them. We both had a go - parked cars, children waiting to cross, a driver clearly about to turn out into the road without looking, all the usual stuff - and then checked in the back of the book to see how we'd done.

We'd missed "poor road surface". None of the roads we cycle on are anything like that good...

Here's the email I wanted to send last night:

From: pozorvlak
To: Dan Bailey
Subject: Coire Gaothach circuit

Dear Mr Bailey,

First off, thanks for writing Scotland's Mountain Ridges. It's been a great source of beta, and has taken me to some beautiful parts of the country and up some great routes which I otherwise wouldn't have thought to visit.

( However. )

Climbing over the lip of the corrie, the North Ridge ahead of me.

I just finished reading a great book: It's All About the Bike by Rob Penn.

Some years ago, Penn threw in a career as a lawyer in order to spend three years cycling around the world. Now he works as a journalist for outdoor magazines and lives in the Black Mountains, cycling everywhere he possibly can (leading his neighbours to speculate that he must have done something really terrible to lose his driving licence for so long - surely a lost driving licence is the only reason to cycle anywhere, right?).

He's got his old mountain bike and his new mountain bike and his old racing bike and his new racing bike and the frame of his round-the-world bike (wrecked in an Indian pothole the size of a hot-tub, and held together by the disfiguring ministrations of an Iranian welder), but it's not enough: he wants a bike that's really his. A bike that's made to fit him and the kind of cycling he does; a bike that's not exactly like every other bike that came off the same Taiwanese production line; a bike that celebrates the history of one of humanity's greatest inventions.

And so he sets off to construct his Dream Bike. One on which every component - while not necessarily the most expensive - is of uncompromisingly high quality, and perfectly suited to its owner. A bike that he'll cycle every day; a bike that will last him the rest of his life.

His trip takes in artisan frame-builders in Stoke-on-Trent, leatherworkers in Birmingham, the original mountain bikers in Marin County, California, dreadlocked Portlanders and sharply-suited Italians, all united by two things - their love of the bicycle, and their passion for beautiful, precise, harmonious engineering. But the construction of the Dream Bike is somewhere between an excuse and a jumping-off point for the book's real strength: a delightful wander through the history and engineering of the bicycle, and its role within the greater history of the Industrial Revolution. Reading this book won't turn you into Sheldon Brown, but you'll learn a bit about frame geometry, how bikes contributed to the emancipation of women and the lower classes, the benefits of tensioned wheels, the non-stop six-day endurance races that used to run at Madison Square Garden, and some of the surprising array of technologies that go into the modern bicycle. And you'll have fun doing so.

There's a BBC 4 TV programme that accompanies the book, called Ride of My Life: The Story of the Bicycle. It's only an hour long, and so it's a lot lighter on detail than the book, but it has the compensating benefit that you get to see the people, and some of the construction processes described in the book. Penn's description of his wheels being built is lovely, but the real thing is even lovelier. Maybe a two-hour film would have been the perfect compromise; but I'll take what we've got.

If I have one criticism, it's that book and film are both weirdly centred on Europe and America. Doesn't Asia, the continent where almost all modern bikes are made, deserve more of a look-in? Japanese components giant Shimano get exactly one mention in the book, and aren't mentioned by name in the film at all, despite having pioneered many significant inventions. And surely the bicycle industry's role in Japan's post-War economic recovery deserves a mention? Then again, Penn racked up a pretty horrifying number of air miles on his existing trip; probably just as well he didn't go to the Far East as well.

Eliezer Yudkowsky just kicked it up a notch:

"Blood for the blood god!" screamed Neville. "Skulls for the skull throne! Ia! Shub-Niggurath! The enemy's gate is sideways!"

...

"I am Neville, the last scion of Longbottom!" screamed Neville to the sky above, holding his wand pointed straight up as though to challenge the blazing blue heaven itself, knowing that nothing after this day would ever be the same again. "Neville of Chaos! Face me if you da-"

( Some random thoughts, including spoilers )

A while back I read a book called Gin: the Much-Lamented Death of Madam Geneva, from which I learned all kinds of interesting things about the Gin Craze (and parallel Gin Panic) in eighteenth-century London. I can't whole-heartedly recommend the book - it would have been better with fewer rhetorical flourishes and more serious analysis - but it should be required reading for anyone proposing measures aimed at cutting "binge drinking", or any other kind of drug abuse. Short version: whatever your idea is, they tried it in the eighteenth century, and it either didn't work or made the problem worse. Concentrate on fixing poverty instead.

One titbit that particularly surprised me was that it used to be common for workplaces to provide gin to their workers, with the cost of the gin being deducted from wages. No risk of being sacked for showing up drunk to work! However, I wonder if our descendants will feel the same about workplaces today which provide unfiltered Internet access to employees...

Should you be bored and have a Twitter account to play with, can I suggest Project Twutenberg*? To quote their page:

Project Twutenberg aims to make literature accessible. We take classics of world literature and translate them to "twiterature" - from stodgy, unappetising tomes into easily digested tweets.

Everyone is welcome to contribute to Project Twutenberg. To participate simply digest a well-known book into a tweet and add #twbg to the end, like the glacé cherry on a word bun.

So far I'm most proud of "Farewell, arms!"

* Disclaimer: my employers are behind this.

It was one of those lovely nights which occur from time to time in an English June, mitigating the rigours of the island summer and causing manufacturers of raincoats and umbrellas to wonder uneasily if they have been mistaken in supposing England to be an earthly Paradise for men of their profession.

P. G. Wodehouse, Ring for Jeeves.