tara_hanoi

Occasionally I moonlight as a python tutor for someone. Sometimes I show them the ins and outs of the language, and sometimes I talk to them about their current challenges in the workplace.

That's when I was reminded of a management phrase I absolutely loathe, "Don't bring me problems, bring me solutions".

If that saying was a person, I would encase their limbs in concrete¹, and smash it open again with a lump hammer. Then I'd do other unspeakable things to the rest of it.

I hate that phrase.

To me, it's a management smell. When I hear that from a manager, I wonder if I'm in the right job.

I had a manager who said that. I was talking about problems I was having working with another member of the team, and lots of other people had them as well.

My manager told me he didn't care, and to sort it out. He then followed it up with the grand proclamation of "Don't bring me problems, bring me solutions".

To me, that's entirely the wrong approach to management; at least, it's the wrong approach to managing me.

When I got my first Forever Job², I used to have a one-to-one with my manager every 2 weeks. That meeting was basically an opportunity for him to tell me what he needed from me, but at the end of it, he'd ask, "Is there anything I can do for you?". It was a ritual for him, he'd always end the meeting with that. Mostly, I'd just say, "No", and totter back to work, but it was a useful hook for when I did need something.

Once or twice, I did need a path cleared for me, in order to do my work, or to ask a favour, and that was the perfect opportunity to raise non-urgent issues.

And, with this manager, they got looked at.

When I was an intern, I had another good manager. If I had a problem, especially technical, he frequently restated, reframed, and decomposed my problem into chunks manageable enough for me to be getting on with. In other words, I went in with problems, and I came out with things to be getting on with. Now, in fairness, I was an intern, and I'm pretty sure that manager saw his role as being a mentor in that situation³.

These days, I work in an "agile" environment, and a Scrum Master is meant to be the person that clears the shit from a developer's way, and lets them get on with their work. That's pretty much what I think a line manager should be to their front-line staff. This is why I don't trust someone that will say, "Don't bring me problems, bring me solutions".

Maybe the phrase is meant to mean something else, but I take it to mean, "I don't give a shit about your problems, get me results".

That phrase betrays an attitude that the manager has no hand in the results. They're given a requirement that they relay to the team, and they expect results. They may have a hand in planning, or anything else, but that's as much as they're willing to enable their workers to get on with it.

Sometimes a problem is beyond the control of the developer.

Sometimes a problem is about resources, or politics, or a lack of information.

Personally, when I hear that phrase, all I think is, "Well, if I had a solution, I wouldn't have needed come to you".

In most industries, the rank-and-file workers are not unintelligent. Frequently, they know what's going on, and they know what is and isn't within their control.

Sure, it would be good for any employee to know what the ideal solution would look like. Actually, no. It would be good to know what the end-state would look like. Sometimes the end-state will be as simple as, "the impediment is not there any more", but they shouldn't have the solution immediately to hand. It's great if they do have the solution to hand and say, "I need access to this device, but I need written approval from you first", but they shouldn't have to have the solution if it's not readily available to them.

The manager may be able to instantly point to a known solution. But in most cases I expect there to be negotiation. I expect a conversation as we work out what needs to be done to remove my impediment. Sometimes the meeting itself is enough. That meeting will be curtailed if the initial response is, "Bring me solutions".

Sometimes that meeting involves figuring out what end-states are most achievable. "Will it work if we just can get this to happen?". Again, if The Phrase comes up, it just suggests a fundamental apathy, a complete and total lack of engagement.

Personally, when I heard my boss say that phrase, that's when I started looking for a new job.

Management is a tricky job, and I don't want to do it yet. But it involves making sure your team works smoothly. As a manager, you aren't directly delivering results, but you make sure your team has the best shot of doing so. That means doing the hard sums of figuring out what colleagues don't play well with others and giving individual work to them. It means making sure that you don't have a single point of failure in your team (aka increasing your bus factor). It means keeping morale to a level where all your employees don't want to quit all at the same time, which itself means resolving interpersonal conflicts, or at the very least keeping conflicting employees in opposite corners. It means sheltering your team from the shit flung from further up the ladder, and from people on the same rung of other ladders.

But, overall, it means keeping your team impediment-free, so they can do their fucking jobs.

Saying, "Don't bring me problems, bring me solutions" means you do not want to be part of that process.

If every employee gave you a solved problem, there'd be no justification for your job.

( Obligatory footnotes )

So, this has been a mild rant in my head, and I feel like I need to articulate it somewhat.

Recently, I was out drinking with some developers, and I got talking about some pattern that some framework uses that another developer considered harmful¹. To be honest, I didn't have a strong opinion on it, I just liked to use it on occasion when I was working with that framework a few years ago. However, the other developers argument against it is what I'll call an Appeal To Personality.

In this particular case, it went something like this, "I worked with the smartest programming guy ever, and he was really anal, and really obsessive, but he produced great quality code, and he said not to do X", with the implicit followup that I'm not going to claim I'm better than this guy I've not met, or otherwise challenge the authority of this Personality.

Similarly, when having a discussion about Agile, one of the developer said to another (who claimed Agile didn't work), "This was put together by some Very Smart People, and they found it worked. Who are you to argue with them?"

I have 3 words for this style of argument: Bull fucking shit.

My own personal take on this is simply that programming isn't a religion, there aren't the gods from on high, there aren't high priestess, priests or Great Rites that confer upon us the wisdom of the gods, and these great Personality Deities. Maybe it's just my own mental blocks, but I need a Reason^tm to accept this. I need to understand why something is a bad idea.

Here's a list of things I know to be a bad idea:

• Programming in really complicated Regular Expressions - I've done this before. I've had to debug some very complicated Regular Exression. As time went on, I spent less time fixing the broken big regex, and either reducing them to small ones in multiple phases, or just taking out the need for them altogether, because that was easier for me to debug


• Similarly in python, I try not to use nested loop comprehensions. Yes, you can look smart and cool, but I don't do them. I can, but I won't because I've learned from regexes that just because you can do something is not a reason for doing it.


• Operator overloading is cool, but unless the semantics fit what you're trying to do, you're just going to confuse yourself when you go back to it later


• Don't write a one-liner just for the sake of writing a one-liner if you expect to rely on that code. If it fits more naturally in multiple lines, do that instead.²

It's not a whole load of stuff, really. They're just mistakes I made for myself, and that I've learned from. I learned a lot from mistakes I made. In fact, I'm pretty sure I've learned the most from mistakes I've made for myself.

Maybe it's a mental block that I can't accept wisdom from others without the memory of pain to back it up, or it's that I can't accept a good practice without a similarly good reason, but an appeal to personality is just not a good enough reason for me.

That said, there are Personalities that I will listen to. I have a few colleagues like that. One even gave a presentation on refactoring. He worked through an example from a book he was very fond of. So, you might be asking, how does this differ from the "Appeal to Personality" that I've just been wittering on about?

Well, in this guy's case, he didn't just rework an example application, following what was in the book, but he took the time to explain what he was doing. Moreover, he wasn't just explaining what was in the book, he was explaining his interpretation of what he'd learned in the book. He'd learned something, distilled it, and shared this knowledge with us. His personality lent a lot to the process, but he wasn't the reason. He didn't say, "I'm pulling out the code and putting it here Because I Say So", or saying, "Whenever you see this, this is a Code Smell and it must be moved", but took the time to explain why he was doing it. These reasons mean a lot.

I'd much rather hear someone who has lived through some pain share tales and stories of their pain, and reasons why they do what they do. I'd much rather have a good reason to do something, and because I'm told to by a Personality is not it. I don't care if Denis Ritchie said it, Linus Torvalds, or some super-smart guy in the back-ass of nowhere said it. I want good reasons, not the celebrity.

( Herein lie the footnotes )

So, it's Thanksgiving again. It's that time of year where you can get games at super-discounted prices from the likes of Steam. However, you might also notice, if you regularly buy indie games from the Humble Bundle, that the Humble Store is open.

The two have very similar briefs - sell games cheap. The humble store say they give 10% of their earnings to charity.

This is not the reason to buy from them if at all possible.

The simple reason is, a number of years ago, Steam chose to sell to Europeans in Euro. However, they didn't bother with an exchange rate, they simply priced each game at its dollar price but in Euro. Given that the dollar is almost always weaker than the euro, that means that Steam get an extra bonus from any European customer. I can't see any good reason for that, it's the same game, but Europeans pay extra just because Valve can't be bothered to do the conversion.

I don't know where that extra money goes. Most likely into Valve's accounts.

In the case of the Humble Store, you only see a game's price in US Dollars. You pay in US Dollars - which are generally cheaper than Euro.

10% of the money you pay goes to charity (Child's Play is one of the 5 named charities - which I take issue with, because Penny Arcade and its general shittiness¹², but I can ignore that in favour of a good deal) and it's cheaper. It may not be cheaper than the flash sales that Steam have on offer, but otherwise Humble is the way to go.

But overall, Humble Store is taking less of a cut, and you're still getting the same game, but for a cheaper price. Also, if there are multiplatform options, you get those (including Android). And if there's a steam key you get that, so rather than just pay for an individual Steam key at a higher price, you get more platform support AND the steam key for a lower price.

For instance, I've just bought Gone Home, Ironclad Tactics, Game Dev Tycoon, Kentucky Route Zero, Beat Hazard Ultra, Anodyne, The Bridge and Risk of Rain for a US Dollar price of $60. After currency conversion in Paypal (which isn't always the most favourable) it's just a few cent over €40.

The total on Steam, at time of writing is €56.70 - I just won with Humble (I realise that I could have saved a chunk by picking the cheaper options from Steam (for instance, Beat Hazard Ultra is cheaper on Steam right now) , but it still worked in my favour overall)

I hope more Europeans realise this, and make a move to Humble whenever possible.

¹ (Trigger warning - Rape and general shittiness) Google "Dickwolves" - not for the faint of heart

² (Trigger warning - Transphobia and general shittiness) Google "Tycho Brahe" and "transphobia" - also not for the faint of heard

I'm a techie; currently I am living in the world of Linux¹. I didn't always think I would be. In my teens, I was into computers. That meant that in the late 90s, I was chatting to folks on IRC over a dial-up modem. I didn't consider myself technical, just lucky to have an internet connection with enough wherewithal to understand how to use the applications². I liked to learn how the things I used worked, but I couldn't do anything with that knowledge. I learned bits of IP and TCP until I realised I didn't have the programming chops to make what I wanted to make; sure, I did a bit of c++ when I was 13, but never got past for loops. Also, a friend of mine was seriously getting into programming at the time, and was zooming ahead with programming. That friend also made a lot of noise about himself and his skills. He believed his own press, and so did I.

Also, because I was trying to figure out my own gender issues around the same time, I spent more time with online trans communities than pursuing things like programming. Like I said, I was satisfied with a Win95 box, an mIRC client, my Netscape 3 suite with its mail/news utilities. Some of the people in that community also bigged up their skills and their involvement in the open source communities and whatnot. Their press machines were in full flow, and I believed them like I did with my friend. I didn't believe I could measure up in any meaningful way. Hell, I didn't know much about Linux. My friend had Linux (an early Redhat³ if I remember correctly) on his machine. So did my girlfriend, who was coding. So did the Open Source guru, and if she was to be believed, she wrote parts of it. I decided I wanted different dreams; I wanted to be a psychologist⁴.

Sure, I was good at Maths in school, and I was good at science... But there was a talk in my school from some software developers, and they tried to move people away from the image of a maths and science person. "We don't want NERDS", I remember one of them saying in a thick country accent. "We want team players; we want the type who do well in soccer." Given that I knew I was a bit of a nerd in school, I took that as a deterrent. I don't think the general encouragement managed to really sink into the ears/brains of those around. That said, the class-mates I took for shoo-ins in computer science never actually went for that course in college. Good thing I had already decided on psychology.

By the way, psychology didn't work out for me. There are a whole number of reasons, but the main one was that when we learned about the nervous system, and neurons, and the general hard biology of the brain, I realised I really liked those details, and while I like asking if the psychological experiments we did actually demonstrated what we were taught they should demonstrate, the rest didn't hold me. So I decided I wanted to be a Scientist; a Theoretical Physicist to be exact.

In my science course, I had to take an extra module, so I took one in Java programming. I did pretty well. I surfed by on some of the stuff I learned when I tried to teach myself c++, and was able to figure out the rest from some basic maths. "Functions? Man, they look an awful lot like the polynomial functions used in maths, and I think all the variable types are just hints to a compiler so it knows what sort of data goes in and out." I knew just enough to know when I knew something, but also knew enough to know when I didn't know something, and would have to work it out by myself. So I did a lot of internal monologuing, and told myself a lot of stories about how I thought things worked. Then I figured out if it worked the way I thought, and amended the story appropriately. I did extremely well in that module. Unfortunately, while I did extremely well in that module, I didn't do so well in my 2 physics modules⁵, to the point where my programming score was twice that of my two physics modules combined⁶.

Anyway, I didn't do well enough to continue to second year, so I dropped out, worked for a year in a clerical role, hopping from one short 1-3 month to the next contract, always on the lookout for a new job because I was never sure if my employer would renew the contract. Eventually, I got the chance to try one final time for a degree. I knew what I wanted to do now. I did computer science; and I worked hard at it⁷. While I wasn't top of my class, I did well, and I've been working in the tech industry for nearly 5 years now. I count myself extremely lucky in that story. There are so many place I could have failed before I got to where I am now.

In that time, I've looked back at some of the things that those technical people did. I realise now that a lot of it wasn't so big. They just were able to talk about it well. My friend in my teenage years, looking at his code from back then makes me wince. I hope it makes him wince as well, otherwise he's probably not learned much from it. Another talked about being able to make certain tools in a few evenings, and I realised a few years back how easy that job would have been.

What really stuck with me is that talk I got in school. I think I get what they mean now, although their delivery was, quite frankly, piss poor. I think they thought that they could get a more diverse bunch interested in the IT business if they appealed to the not-a-nerd crowd. I think they went about that in the wrong way, while potentially alienating the people who thought they wanted to be in that field.

For years, I've thought about how I'd deliver a similar recruitment speech to schools. I thought about how I'd deliver it to young men and women to see how I could get them in the door. I don't know about the rest of the world, but people keep concentrating on maths as a skill. I disagree. But before I go on, I'm going to digress for a second⁸.

I believe we need more women in the IT fields. Far more articulate people can detail why. Personally, as a trans woman (in a very odd position by way of transition), I want more diversity in general, and I think addressing the basic gender imbalance would make a pretty good start. That said, I'm not going to call myself an advocate, just an ally at best. I don't have the energy, nor do I think that my direct involvement based on my own issues are going to help much⁹. That said, I do take a keen interest in what others are doing, and can appreciate what is being done in that area. So when I saw she++, a video talking about women in tech, while also trying to encourage women to try technical roles, I was very interested.

Overall, I love what it's doing. I like that there's honesty, and I also like how it's nothing like the EU's ill-fated attempt to encourage women in science¹⁰. That said, some elements of it really reminded me of that recruitment talk in school.

What follows isn't a criticism of the video. I think it's excellent. However, it did raise various gut reactions in me. Thing is, I know this video isn't for me, so I would be mortified if any of these ramblings were used to try and justify demanding that the video be changed, especially if it's by a group this video isn't for.

So, tying back into how I'd want to present a recruitment drive in schools. I'd want to dispel the idea of maths being a necessary thing in computer science. Near the end of she++, there seemed to be a lot of emphasis on that. You know what? In the last 5 years (basically my entire working life in IT), maybe a little more, I haven't needed major maths, just some understanding of addition and multiplication. I think the last thing I needed it for was some pretty heavy and trippy stuff involving neural networks. And before that, when someone tried to teach me lambda calculus.

Let me just say: No. I mean, yeah, lambda calculus is a fairly core theorem in computer science, but it doesn't impact on my day to day life. In stuff like neural networks, it's domain knowledge. Similarly, if I was programming a simulation of particle collision, I'd need to know, and understand, some formulæ that model the world. But aside from domain specific knowledge, and understanding some of the seminal contributions to the theory of computing, I can't say it's absolutely crucial.

What I think is essential is language, and task subdivision. Can you break down a task into its most fundamental elements. Could you take those fundamental elements, and then sit down with a creativity-impaired 4 year old and communicate those fundamental steps to that kid? When you see the kid mess up, can you put yourself in their very literal shoes and figure out where you went wrong in your instructions? If you think you can, then congratulations, I think you could make it as a computer scientist.

A computer is a like a really dumb, but really fast, toddler. Don't believe me? If you have an hour to spare, listen to Richard Feynman on the topic¹¹. Realistically, in this day and age, unless you're working on a really low level, you'll be treating a computer like a toddler giving it simple instructions. The difficulty of my job is not in the maths, it's the careful and unambiguous expression of what I want the computer to do.

That said, I'm biased. The way I learned programming, and general tech stuff in my adult life was by telling myself stories about I thought things worked, and refining and retelling those stories until I had a small working model of computers in my head. To me, programming is about words, stories and clear expression.

That's not to say that maths isn't a bonus; it really is a bonus. Chances are, if you're good at the maths side of things (or any science), you're probably good at the sort of logic needed for programming, and for breaking a problem down into its constituent parts. Also, if you happen to end up making a program to analyse statistics, you probably want to understand the maths behind the stats calculations.

So, what about the stuff like lambda calculus, should that get thrown by the wayside? No, I think that understanding that really helps you understand other things, but I've seen lambda calculus expressed in interesting non-mathematical ways.

Anyway, communication doesn't stop there. Communication and collaboration is needed in pretty much any technical job. More than likely you're not going to be the solo techie on a project. Even if you are, you'll either have a customer, or a boss, or someone else that you need to talk to. In general, if you're skinny-dipping in code, you're not going to able to speak to humans that well for a few minutes after surfacing. No really. Specific words take on very specific meanings in the field; one word is not always substitutable for another. It has the effect of limiting your active vocabulary for a while, so that when you're talking to non-techies you may sound like you're speaking a different language for a little bit. That said, if you're someone who's good with their words, you will have less of a problem getting back to a point where you can speak human. If you really know your stuff, and are articulate enough, you can be a good intermediary between non-techies and techies. I honestly believe that the tech sector lacks diplomats and translators (purely because of the mismatch of expectations on both sides) - this is somewhere I would love to end up, although right now I enjoy working in pure tech too much to consider an intermediary role.

Communication is necessary in all levels of my job. I need to be able to talk to, and collaborate with my colleagues. I need to be able to tell my various bosses what's going on in various levels of detail, while still giving them what they need to know. I need to be able to train in, and mentor, new joiners. I need to communicate what I'm doing to the customer. Each needs varying degrees of detail, and I need to deliver it in an effective way that conveys what they want/need to know, without too much embellishment. Last, but not least, I need to tell the dumbass computer what it's bloody well meant to do.

There were some other little things in the video that rankled my wrinkles, namely the implication that being good at tech meant you were better at everything. Yes, the skills of being able to break down a task into its constituent parts is a good thing, but the general hubris can be annoying. Almost every time I go on reddit, I want to smack that attitude out of some CS student who seems to think that because they can tell a computer what to do that they know how to do everything and that they have a solution to all the world's ails. Yes, you are trained in the use of a very powerful cognitive tool, but if all you have is a hammer, everything looks like a nail, and this world isn't made of nails. You also need to know when to turn off that bit of your brain. It's only a minor snag, but I reckon the less encouragement we can give folk to think that they can rule the world because they're a computer whisperer, the better.

That said, an excellent point was made that programming lets you look at your hobbies a different way, and your hobbies help you look at programming in a different way. Have a look at juggling some time. I see a beautiful marriage of a simple set of instructions, motion, and hand-eye coordination. I've recently taken up crochet, and find it really satisfying in the sense that there's an order that I could probably model in a machine. Who knows? Maybe those things will help me think of a solution to a programming problem I have some day.

Anyway, on the subject of how I'd sell my field to kids in school, I haven't thought further than trying to express the fact that it's down to communication. Sure, if you're good at maths, that's great, we want to hear from you. But if you're good at communication or are able to express yourself in different languages (which always felt like I was using the same bits of the brain for that as I do for programming), we also want to hear from you too. I just wish the guys who came to my school managed to put it that way, rather than alienating the self-identifying nerds.

As for the video, I really did love it, and want to see more like it. It just got folded into my general rambling rant because I happened to see a link to it when I was thinking about writing a blog post talking about the habit of misrepresenting CS as a maths-only kind of deal, which I think does an injustice to IT.

The final thing I want to say is for anyone starting in IT. The she++ video does a really good job at identifying and calling out the sort of stuff that leads to impostor syndrome. The really funny thing is, even though I looked like one of those speed-ahead folks in the labs, I was still trying to figure my way out. I also slowed right down in the "weeder" modules in the following year; it humbled me.

If I could offer one bit of advice to anyone looking the others speed ahead it's: Don't. I know it's hard, but don't look at those speeding ahead if you can at all. The last time I was in fresh meat, I was struggling along, and could only see the skaters who lapped me time and time again. It was incredibly hard not to feel like I was the runt of the litter. The funny thing was, when I stood off-track for a session, I noticed the really good skaters but how few of them there were, and how the rest were in the same position. I even remember telling another trainee skater, at the end of that session, how she honestly wasn't doing as bad as she thought she was; she was keeping pace with most of the rest, but could only see the really good ones overtaking her. I realised she was doing the same thing I was¹³, and I managed to feel a bit better about myself. Unfortunately, because of an injury I wasn't on track again to put that knowledge to the test.

Anyway, I know how hard it is to conquer the feeling that because one person is racing ahead, that everyone else must be doing the same as well, so the simplest advice (even though it's so much easier said than done) is to ignore it, and keep doing what you're doing.

If that doesn't work, comfort yourself with the fact that, like a lot of the people who made me feel like tech wasn't for me, probably a lot of them are churning out crap in the name of looking like they're racing ahead, or because they think they know it all already.

( Herein lie the (gargantuan) footnotes )

Once upon a time, in my more evil days, I came up with an idea that I found entertaining.

The idea went a little like this: I ever ended up teaching in secondary school, I'd probably have to teach a transition year module; I'd call that module "Practical politics". I'd make a nice big web-application based on the Risk board game, but with various enhancements as were needed. I'd make a LOT of territories, and give a few to each student. I'd then give them non-destructive, but competing, goals like "secure territory X", wherein anyone with that goal would get 1 point towards their final score if they held that territory for a day.

I hadn't even heard of the Stanford Prison Experiment by that stage.

It got worse: my idea encompassed giving a survey at the start, to work out the various social networks and subnetworks in the class, and then basing the goals on that. In my thought experiment I reckoned it'd be fun to have friends vie for similar territories to see how they'd resolve the issues. I tried to predict the fun of a role-reversal as the unpopular kid found themselves in a position of power holding a resource that others would have to negotiate for in order to get their points. My mind positively spun with the idea of giving some people "reporter" roles, where they required the co-operation of a host army in order to operate, but earned their points based on the subscriptions of the other classmates.

Somehow, optimism prevented me from seeing this turn a little in the way of Lord of the Flies. I thought that it'd be an entertaining way to teach kids about the disconnect between what's seen on the map and what they are trying to achieve, and how a tiny bit of back-room chat could make or break a situation.

As much as I've grown as a person, and realise it's a fundamentally bad idea, I'm still ever-so-slightly in love with the idea. But a recent game of risk (the game that started this chain of thought) reminded me why this is a fundamentally Bad Idea (tm): back-stabbing is part of the game. You form tenuous alliances waiting for the point where they fall apart, knowing it will end in tears, and you still cry when they do (sometimes cries/tears/howls of laughter).

While this is a valuable lesson for everyone to learn, the above method is not the way to teach it. And this is why I should never be a teacher.

(P.s. I don't think anyone actually reads this, but if you do, I'd love to hear of any Horrifically Bad Ideas you've had)

Conferences are fun. They're a great way to share skills with other people, chew the fat, and an excellent chance to just take off your blinkers and look at the technological world outside of your job. It's also good for getting drunk and telling war stories.

Sometimes you even get employers paying for employees to go to conferences to learn stuff. Unfortunately, working in QA there aren't a lot of technical conferences geared to my profession. QA have the best, and most damaging, war stories and they'd probably count as confidential information. So, companies don't pay for us to meet and trade tales of happenings that they'd really rather not let the public, or their competitors, know about. This means I tend to just go to some local OSS conferences and mill about playing the technological magpie, and also socialising.

One group that I like is the monthly Python Ireland group (although I've not gone to a meeting in far too long), and I also attended 2011's Pycon Ireland. It's great to see a number of talks and presentations that make me aware of new technologies, or novel uses for what I already use.

These days, in lots of meetings like this, there's a tendency to record the presentations and distribute the slides and source code. This is really cool, although frequently I find myself miffed that I get a choice of one or the other (recording or slides), but generally not the one I want at the time; that's just Murphy's law at work.

Recordings make interesting presentations like 'Daemon Slaying! Or, Unix Daemons in Python for fun and profit!' available to me, and I'm able to start thinking of how I might want to use them or if I should squirrel away that information for a rainy day. Having also been involved with Toastmasters, I immediately began to write up feedback for how that presentation went, so that I could have a list of tips for what I'd do if I had anything to present (this is from the speaker's point of view, not that of the organisers/camera folk):

What went well

• He spoke clearly - he obviously had some sort of sound check as well


• He knew the material he was going to present - it's actually amazing how many don't, and think they can wing it. That said he did surprise himself once with his code.


• I didn't notice any verbal crutches or audible hangtime - that means he had no 'umm's or 'ahh's. Blank space was either left blank, or he repeated a point while giving himself time to think.

What could have gone better:

He forgot he was being filmed. Normally this is a good thing in that you don't get self-conscious or talk to the camera when you really should be addressing the people in the room. However, there were occasions where it worked to the detriment of the video audience (which is potentially bigger than the people who are in the room):

• During one slide, he pointed to elements of his slide that he thought were and were not important - he didn't bother to say what those points were, he just pointed to them, leaving the camera operator to quickly orient and focus the camera not just on the speaker but on the points he was making.


• Question time - he didn't repeat the questions he was being asked by the audience. In fact, I'm pretty sure there was a whole bunch of audio problems as the sound didn't cut back to him until he was half-way through his answer, but it's good practice to repeat the question back on the mic so that the video audience will know what's asked rather than trying to infer it from the user's answer.

It should be noted however, that I work for a multinational where I'm not always in the same room for a presentation. Sometimes all I have is a pdf and a phone, and I have to keep up with the rest. After enough of those, you start to consider the above to be a hanging offense, and you become conscious of it FOREVER MORE!

But overall, I really enjoyed that presentation and its content. He did nearly everything right, except for ignore the video audience, and it reminded me of some basic points which still apply to pretty much every talk:

• Speak clearly


• If you're being recorded, be aware of what the video audience can and cannot hear, and relay anything that may be of interest back to the video audience


• Know your material and its flow


• Avoid verbal crutches in the main material - it never comes across well on recordings (video or audio)

Hopefully I'll remember them if I ever have to do something like that.

Last year, my attempt at Fresh Meat came to an abrupt halt due to a groin strain. I was fairly disheartened given my poor performance for that second session (I was falling over on basic knee falls, which wasn't exactly safe). Eventually I pulled myself from the session and realised a few days later that while most of my owies had disappeared (as expected), this one was a real injury.

As a result, I dropped out of the programme and, as a way to keep involved with a great bunch of people, I decided to help out as a Non-Skating Official (NSO).

As a quick side note, if anyone ever feels they want to get more involved with their local league, without learning to skate, I would suggest volunteering as an NSO. Leagues love good NSOs, and it's a great opportunity to get to know your local league, and all the people within it.

With 2012 rolling around, I decided my new year resolution was to get through a full Fresh Meat programme; I don't care about whether or not I pass assessments at this point in time, I think it's ambitious enough to work towards surviving the full 8 to 12 weeks.

( What little prep I did )

( How the Fresh Meat sessions went )

All in all, 'twas fun. And I'm still not sure how I'm not sore right now. (Warning, this post may be edited tomorrow so that I can articulate exactly what exquisite pain was waiting for me in the morning)

One of my fascinations, although not enough to warrant giving myself any sort of title, is the history of computer folk in the days when unix and the internet were purely academic subjects. A lot of interesting culture and cultural terms emerged from that time, and seem to be relatively consistent. There again, the consistency probably stems from the fact that the authoritative tome for these terms is the FOLDOC (Free On-Line Dictionary Of Computing).

Some of its more famous articles are still common terms in industry today, such as Cargo Cult Programming. One of my favourites is the Magic Switch Story (although it's rather less famous, or at least not used commonly).

What really captures my imagination is that these terms are relics from what is the closest thing to an oral tradition as we're going to get. A lesson abbreviated into the title of a story or lesson. You hear terms like "Deep Magic" and you can guess at what they mean, even before you read the definition. Sometimes when I take a step back and look at what programmers are actually saying to each other, I can only think of "Darmok and Jalad at Tanagra". (By-the-by, the fact that I'm linkspamming with various pieces of hacker folklore, and the plot summary of a Star Trek episode is not lost on me)

Sometimes I'd get a little lost feeling about not having the same common depth of folklore nowadays, but hanging around the likes of reddit, I realise that there's as much of a common language now as there was before, but it's shifted. I can talk about doing a Bobby Tables and expect that folk understand it. If I say someone's a real BOFH, you might get an idea as to what to expect.

There are also traditions that are spreading as memes. For instance, the editing of production code, live on the server, now requires the perpetrator to wear a Pink Sombrero... and the thought of the pink sombrero brings me onto one of my own traditions.

Just over half-my-life ago, I was at the right age to appreciate the cartoon Earthworm Jim when it came out. I loved the graphical beauty of the game, even though I wasn't very good at it, and its attitude. To my mind, the cartoon managed to faithfully recreate and enhance aspects of game, and it was just enjoyable.

There's one scene from that cartoon that's stuck in my mind from then until now: Jim is, once again, captured by the bad guy of the episode, a particularly televangelist-sounding fish, who wants Jim's suit and, as a bonus, wants a nice worm-roast for dinner (what with Jim being a worm and all). The henchman tasked with making said wormroast decides to watch a cookery programme and learn how to make pot-roast. The henchman, not being the gifted in his class, says something to the effect of, "I know, when he says 'pot', I say worm."

The conversation follows something like this:
Chef: We're gonna make a pot-roast tonight.
Henchman: Worm Roast!
Chef: To make a pot-roast-
Henchman: Worm Roast!
Chef: you get a nice shiny metal pot and stick it in the oven.
Henchman: Get a shiny metal worm.
*casts eye around, and settles on a generic cartoon missile and shoves it in the oven*
*Hilarity ensues and our protagonist makes his escape*

So, how does this have anything to do with hacker culture, folklore, sayings and traditions?

Well, I sometimes have to heavily modify existing scripts. For better or for worse, I frequently find myself renaming and retasking one major component to make room for another. That's mostly fine but, from hard experience, I'm always conscious that I'm probably missing some of the subtleties that stop me from directly renaming one thing to another. Chances are I've got 90% of the problem in my head, it's just that last 10% is going to hurt me if I stumble blindly just swapping bits around.

It's just like saying 'worm' whenever they say 'pot' without understanding that the two are not completely substitutable.

Just to remind myself, when I do that sort of work, I chirp out in my dumbest little voice, "WORMROAST!"; it's fun trying to explain that one to co-workers who already think you're half-mad. Now that I've explained it to them, I'm more prone to chirping "WORMROAST" in the office.

I know that my call of "WORMROAST" isn't going to catch on any time soon, but it's a story that keeps me amused while I go and break things in the name of progress.

I know places like Stack Overflow like to enumerate all the new little terms that have turned up, but I'd love to hear any personal little terms you use, either in the comments here or by twitter.

We're hiring in work. I happen to work in a Unix place so, when we hire, we tend to ask Unix questions (strangely enough).

Like most interview processes, we have a bunch of questions that we make sure we ask, and we might spit-ball a few follow-on questions just to test the range and depth of the candidate's knowledge in that area.

As an aside, I know everyone gets nervous in an interview, but in our interviews we want you to succeed; we're asking questions to see how much you know, not because we want to jump down your throat for not knowing it. The only rule I have as an interviewer is Don't Bullshit Me; if you don't know something, say so.

Anyway, there's one set question that is interesting. "What does the term fork/exec refer to in UNIX?" I didn't write the question, if I did, I'd leave it at fork(), because the answer we're looking for has nothing to do with exec(). What we're looking to segue into is a little chat about processes and subprocesses. Once they pick up on the fact that we're talking about processes, I'll start asking the questions that aren't set, like how you can find out what the parent process is. One of my favourite follow-ons is quickly becoming my head-desk question:

"What happens to the subprocess when the parent process dies?"

The inevitable reply is "Um, Zombie Process?". Normally, I'd let that slide; partially because I'm so nervous I forget the term "Orphan process" and don't mention that it's reclaimed by PID 1 (or at least, it typically tends to be init in most implementations).

An orphan is a subprocess that's still doing work after its parent died.
A Zombie process is a process, that has finished its work but is still in the process table because its parent hasn't reclaimed it with wait().

This is just one of those things that starts to bug me because a Zombie process is something to worry about, but orphans can be fine. I've used, and modified, shell scripts that spawn off children to finish their work while the parents go off and die in order to return control to the user. It's not great architecture, but it's ok, because the work done is big, and we don't want a user sending a SIGINT and leaving the work half-finished.

But, people say "Um, Zombie Process?" because it Sounds Cool.

Please, stop that. I don't want to sound like those bloggers that shout "YOU'RE WRONG" at the entire Internet, or one of those "Too cool" bloggers that likes to use a harsh tone because they're the uber-elite caste of computer professional. I just want people to know a little more so I don't have people trying to score cool-points when I ask a slightly obscure Unix question.

Cross-posted to command_liners

I'm a fan of twitter, and one of the features of the territory is shortened links. The twitter web interface generally does a half-decent job of expanding these posts, but I don't always get to see the expanded link.

Sometimes I want to see where the link leads without actually visiting the site in case it's hosting malicious scripts. After a little bit of digging I found that wget can do exactly what I want. I have a little throwaway directory (in my case, '/export/home/sketchy', which allows me to see where the link points to.

For example, let's say I see a link (it leads to a blog post of mine, so nothing very interesting) and want to know where it leads:

tara_hanoi@tara_babel:/export/home/sketchy$ wget --max-redirect=0 http://t.co/8xED8dz
--2011-07-25 16:01:10-- http://t.co/8xED8dz
Resolving t.co... 199.59.148.12
Connecting to t.co|199.59.148.12|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://bit.ly/guxtdh [following]
0 redirections exceeded.


The bit in bold is where you should be paying attention. In this case, the t.co link points to another shortener, bit.ly - if I want to follow that on, I don't have to paste that back into wget, I can just increase the 'max-redirect' parameter:

tara_hanoi@tara_babel:/export/home/sketchy$ wget --max-redirect=1 http://t.co/8xED8dz
--2011-07-25 16:03:50-- http://t.co/8xED8dz
Resolving t.co... 199.59.148.12
Connecting to t.co|199.59.148.12|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://bit.ly/guxtdh [following]
--2011-07-25 16:03:51-- http://bit.ly/guxtdh
Resolving bit.ly... 168.143.172.53, 2001:418:e801::12:1, 2001:418:e801::15:1, ...
Connecting to bit.ly|168.143.172.53|:80... connected.
HTTP request sent, awaiting response... 301 Moved
Location: http://tara-hanoi.dreamwidth.org/1508.html [following]
1 redirections exceeded.


Ok, so it leads to my own DW entry, so I'm pretty sure it's ok.

This might be useful for folks as a quick and dirty way to expand shortened URLs.