Post-Pre-Conceptions

Posted on April 27, 2016 by Planosophy

Within two weeks of graduating from Makers Academy, student lands a job as a software developer.

The student in question, despite having little to no experience at using Microsoft’s .NET framework (which she was surprised to hear has nothing to do with fishing) and C# (of which she remains unconvinced of the existence of an auxiliary non-musical definition of) will be mastering these at her new role in Software Development – despite the Makers Academy curriculum focusing on Web Development.

To be fair, that’s hardly new news. Makers Academy get their students jobs. Something around 85% of them last time I looked.

Little known or read blog about coding will continue. It will continue to have nothing to do with syntax, coding hacks or programming technologies and frameworks. It will continue have everything to do with the idiosyncratic and illogical side of coding.

You have been listening to the news at whatever time you’ve been listening to the news.

After the break, Illogicode.

Illogicode’s jingle

I realise it has been about a month and a bit since I posted something to the interwebs. Actually, thats not true, I’ve been posting git commits and making whole websites.

Here’s the final project that emerged from our team/the proof that I can now make websites: http://local-host.herokuapp.com/

So just forgive me for now, and I promise to get back on with blogging. Seriously, I don’t make promises that I can’t keep.

In the spirit of keeping promises…

In my first post I promised to go back and review all my naive preconceptions about coding that ultimately made me cough up for the Makers Academy course.

Bizarrely, most of those preconceptions still hold true. That’s not to say that they have any value.

I managed to have concrete hunches about things that quite literally don’t matter. Not even one iota. Like standing on speakers corner claiming that you have prophesied the coming of sandwiches for lunch today. Who cares?

There are far far far more important things that I was totally unaware would be much much much better reasons for me to sign up to a coding bootcamp than ‘tech is everywhere’.

Puuur-le-ase.

Thats the kind of insight Advertisers get excited about basing an entire campaign around. Ie. Totally meaningless.

But there are two places where I wasn’t vague enough to now claim that my preconceptions hold true. These:

Coding is Objective:

What I said:

Whilst few know precisely how their computers, iphones or PS4’s work, even fewer care – until the moment they cease to work. The programme either does what it’s meant to do, or it doesn’t. It either works or it doesn’t. The Uber driver either arrives at the right place, or he doesn’t.

Feedback is vital in ascertaining whether you have been successful at something. If you’re a performer, feedback comes in the form of applause. As a programmer, your code works or it doesn’t. And you know straight away.

What I should have said:

Coders are obsessed with ‘Quality’ and ‘Craftsmanship’. If I asked you to tell me what these mean, you might struggle to pin it down. You could probably point at something you deem to have ‘quality’, or to be ‘well crafted’, but you might not be able to tell me why.

To be odiously pretentious (yes the pretension of using the word ‘odiously’ was pretentiously intensional) the philosopher Immanuel Kant grappled with this very issue in his 1790 hit ‘The Critique of Judgement’. He couldn’t understand why everyone seemed to recognise the same things as having having an objective ‘quality’ or ‘beauty’, yet the way people came to that same unanimous conclusion was entirely subjective.

All schools of thought follow best practices and aim for quality. They just have different ideas sometimes over how to interpret and prioritise different best practices.

Everyone agrees ‘readable code’ is a good thing, but they all differ in what code they consider to be ‘readable’ and why. After all, not everybody likes the same authors.

Some people think you should type Array.new rather than [].

Everybody aims for SOLID principals yet people may differ when faced with having to make a compromise between two principals in which they would prioritise.

Some people hate testing private methods. Some people like it.

Coding is subjectively objective. There have been a few coders who I have very much respected for owning up to this fact. Some don’t. Which brings me on to my next piece of hindsight.

Humble People Code:

What I said:

Despite being an elite group of super-humans that not only understand the mysterious world of technology but actually built it, they never see themselves this way.

They are the unsung heroes behind some of man’s greatest achievements. You probably have no idea who Margaret Hamilton is – you definitely know who Neil Armstrong is. Despite being rockstars, they’re usually only ‘famous’ amongst other coders.

There are a few reasons why only the humble can code.

The more you know, the more you realise how little you know. It would be near impossible to know everything about coding, to learn every language. The more you know, the more you realise that there is much, much, much more to know. You never can feel like a know it all. You have to be happy about dealing with uncertainty and not knowing.
Computers tell you ‘no’ all the time. There are no marks for ‘effort’, or ‘nearly there’ – you get nasty error messages in angry red type if you’ve screwed up. You have a man-made object telling you that you’re doing it wrong every few minutes, and you can’t dispute that it is ultimately your fault.
You stand on the shoulders of giants every day. You didn’t make the Ruby coding language, you aren’t Alan Turing. You are NOTHING in comparison.

What I should have said:

Coders are _?__?__?__?__?_.

In retrospect, the word ‘humble’ wasn’t the best choice to describe coders. I’m not saying that they are ‘arrogant’, that would also be a poor adjective to choose. I might have to settle with the word ‘snobbish’, but I’m not really comfortable with that either. It’s much more nuanced than that and definitely less negative.

To be honest, the word I’m looking for probably doesn’t exist, so I’ll spend the next 200 words or so trying to pin this elusive adjective down.

TL;DR – I don’t find the right word, so you’ll have to read all the words.

It is arrogance because coders have the courage of their conviction. They can be pigheaded when they know they are right. At the same time, it isn’t arrogance, because they kinda want to be proven wrong. Being proven wrong is how you learn something new, otherwise, all you’ve done is reinforce/broadcast what you already know. They also know deep down that nobody can be an expert in a framework that only emerged 2 years ago.

In a way, it is a sort of snobbish quality, and intellectual snobbishness at that. Calling things ‘Code Smells’ or ‘design smells’ sounds like a put down. Being told your code ‘smells’ can sometimes feel like being told you, yourself, need a bath or some deodorant. It is actually down-right rude to tell anyone that they, or anything attached to them, smells. I would happily campaign for this ridiculous phrase to be banished in favour of something a bit less bizarre and reminiscent of 19th century cartoons where ‘paupers’ were depicted as emanating a certain stench that poshos would wrinkle up their noses at in disgust.

Caricature;_Faraday_giving_his_card_to_Father_Thames._Wellcome_M0012507-1.jpg

But it’s not snobbery because is not at all meant in a ‘I’m better than you’ kinda of way.

Because coders have a snobbish attitude to themselves.

Their own code rarely matches up to the high standards they set for themselves and for others.

It’s more like the good kind of pride, as in a pride in doing things well and not the Jeremy Hunt type pride that makes you do things pigheadedly badly because you’re scared of losing face. The line between the two, in practice, however, is much more subjectively objective.

For example, you may be utterly convinced that Array.new is a better way of declaring the existence of a new array than []. Your pair partner believes the converse. You may debate this for some time each thinking that the other is being pigheaded. Neither are being pigheaded, both are just taking pride in doing the right thing. No matter how small and navel-gazey the detail, it all matters.

Unlearning How to Learn

Posted on March 14, 2016 by Planosophy

If Makers has taught me anything, it’s taught me that being taught isn’t all its cracked up to be.

Seriously. Being taught is over-rated.

It’s that old chestnut: “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.”

Except its more like: “Give a coder a walkthrough and they’ll make whats in the walkthrough, give a coder Google, fast internet, a few relevant concepts and a bunch of keywords, and they’ll make whatever they want.”

Which is why Makers Academy has a different approach to a lot of ‘Learning Institutions’.

They want to make independent junior developers. Developers that don’t have to ask their seniors basic syntax questions. Developers that know how to navigate a github ReadMe and Mozilla’s JavaScript documentation. Developers that know where to find the best screencasts and whose blogs to follow. Developers that can figure things out for themselves. Self-sufficient Google search gurus – adept at pulling out the one line that will make their tests pass from all the jargon-laced guff on the interwebs.

At Makers, they’re very hands-off. Normally when you ask them for help they’ll say “Have you Googled it?” If you reply ‘yes’ they’ll say “Have you read the stack trace.” If you reply ‘yes’ they’ll probably say “have you tried using byebug or binding.pry?” If you’re still replying yes, they’ll probably give you a cryptic clue such as “if a table is dropped in the database and nobody heard it drop, did it still make a sound?”

Ok, they don’t resort to cryptic metaphors, but they do make you struggle.

Why? Why not just give me the sodding answer? WHYYYYY?

The only time they’d give in and give you the answer would be if Stackoverflow is down and they didn’t need to use Stackoverflow themselves to give you the answer.

flat,1000x1000,075,f.u3.jpg

Sometimes the frustration can be pretty intense. If you can’t deal with not knowing all the answers and want to be spoonfed information, don’t become a programmer. Simple.

And so, into lab week I skipped knowing that this was the week that I didn’t just consolidate what I had learnt over the past 5 weeks in terms of raw coding knowledge, but also, I consolidated what I had learnt about learning how to code.

First things first.

Developers have an ability to know what is important to know and what isn’t. This skill is important to develop for your own sanity as a programmer. It’s very easy to get overwhelmed with all the languages you could learn, all the testing suites you could master, all the things you could make because, the more you know, the more you realise how little you know.

And so, concepts, best practices and design thinking are more important than having another language under your belt or becoming an expert in some obscure JavaScript library. Learning to code is not about syntax – although having some knowledge can ease some friction – it’s about being able to apply the same abstract conceptual thinking across any challenge.

So the first challenge in Lab Week was the greatest.

What the hell do I do?

So these were the challenges I set myself.

Find out why I hate JavaScript. Find out how I can learn to love it.
Why is everyone obsessed with APIs?

Learn to love JavaScript?

Had I gone completely effing mad?

This was a tall order I had set myself. As this hill seemed so intensely difficult to climb, I knew I’d need a serious carrot at the end of the proverbial stick.

I decided to mingle my sheer dislike of JavaScript, with all its illogicalities, with something I love. Games.

I fired up Unity and started to follow some screen casts.

I soon realised I was allowing myself to be spoonfed. I was merely doing exactly what the slightly robotic man in my headphones was telling me to do. Everything was a bit too easy. I wasn’t learning anything. Makers would disapprove.

Top learning tip No.1: Turn off the sound on screen casts.

Why?

It changes the experience from passive to active. You have to actually use your brain to decipher what is going on on the screencast. You know what needs to happen, what code needs to be written, but you have to figure out the why. It tests if you are really following the logic behind what is going on. If there are some leaps that really confuse you, you can turn the sound back on for a little bit.

It also stops you from following in real time. Following something in real time prevents you from having to use your memory in any way. It’s not really learning unless your memory muscle is doing some lifting.

By the time I had finished two of these tutorials, I had become a bit more excited about JavaScript. My apathy towards learning this ugly monster of a language had been transformed into an annoyance that I didn’t know it well enough to use it to its full potential. I was fired up enough to read an entire book on it. This one:

Top learning tip No.2: Do the exercises in the book.

No matter how babyish they seem. Even if it’s just doing a basic for loop. You will make it stick if you actually type the damned thing. Learning comes through repetition. Keep typing!

Top learning tip No.3: Test drive

A lot of the walk-throughs online, and in many of the books, are not test-driven. It can sometimes feel a bit like you’ve cheated yourself if you just type whatever they tell you to – and, as I’ve said, struggling leads to learning, mmmm young Padawan.

15abdb2bae3ef9602995a1e3619f93350cdebfce133b501a4d714b97746e11a4.jpg

In order to test drive code, albeit in reverse, you have to understand exactly how that code works. It will also help you become more acquainted with a testing framework – so it’s a win-win.

The second half of the week involved scrapping together an API.

We were all told that the tech world is a little obsessed with these things.

And so, I set off building an API that I hoped I could plug into a rather nifty data visualisation Javascript Library called D3. An API is basically a way of plugging in a source of data to a webpage. It gets served up to the ‘client’ in the form of a Json file. Pronounced Jason.

Jason, whoever he is, sounded alluring and exciting.

(What I thought Jason would look like if he was a person)

It was to contain a bunch of economic statistics so that the user could find out whether unemployment or house prices were higher under the Tories or Labour – whether Cameron really is telling a bunch of, ahem, porkies, during PMQs.

Top learning tip No.4: Know what you are building.

Sounds obvious, but I certainly made the rookie error of not really understanding what I wanted to build before I set out. Sometimes you can get a bit excited about the prospect of doing something new – there are best practices for everything and honestly, you don’t ever need to completely re-invent the wheel.

If you haven’t heard of REST (in the computer-jargon sense, not in the sense that you burn the candle at both ends) before you build an API you have almost definitely done it completely wrong.

I didn’t know what a REST API was for at least a day of the three-day long project.

I also hadn’t thought about the learning potential of doing a CRUD API. CRUD means ‘Create, Read, Update and Destroy’ (yes, ‘destroy’ – intense but programmers tend to prefer this word to delete, probably because a lot of them are gamers). A CRUD API means you can change the Json file that the API serves. Unfortunately the API I chose to build only involved doing a lot of elaborate ‘Reading’ of the data – it didn’t exactly feel right to allow the users of my API to re-write economic and political history, considering that the whole purpose of the API was to set the record straight.

And so, unfortunately, I ended up meeting the boring Jason.

(The wrong Jason-type I met)

The kind of Jason who spends hours in the gym working on his ‘personality’ – the well-dressed Jason with not much going on between the ears. Certainly not the alluring still-rivers-run-deep Jason whose endless capabilities always manage to surprise and sometimes confuse his friends.

What I learnt:

I prefer doing whole projects in one language – I don’t like the jack-of-all-trades-master-of-FA-way web developers have to be – everything is scrapped together. Yes, OK, it’s kinda fun doing a bit of D3, but I would much rather be the person who built D3. The most rewarding project for me was the platform game built completely in Javascript.

Knowing the fundamentals is more important than building something ‘cool’ at this stage. If I had decided to build an API with some CRUDability (see what I did there) that would have been much better as a learning experience.

I am always going to feel like I don’t know anything. That’s fine. In fact, it’s freaking exciting to be going into a career where a lot of your value to your employer is based on your ability to learn. Learning is usually quite a self-indulgent exercise in the world of work – especially in the jobs I’ve been in where shit just needs to get done and emails need to get sent.

In the tech world, employers know that ‘new’ needs to be explored – because ‘new’ is the source of value. Whether it’s exploiting the new technologies around you to make better programs more efficiently, or whether it’s making the new technologies themselves – both involve explorational learning. Which means you get to be a perpetual student without the insane amount of debt.

**Disclaimer – This was half written at the time of Lab Week, and half written afterwards as I had the most intense flu known to man. Seriously, I was feeling so incredibly deathly – I thought I was going to be one of those people from a Daily Mail article who caught flu, suffered from a stroke and ended up being able to talk German fluently after coming round from a month-long coma.

Just Because You Can, Doesn’t Mean You Should

Posted on February 21, 2016 by Planosophy

I’ve decided that Tech people, in a controversially sweeping generalisation, live by the mantra “if you can make it, you should make it.”

Exhibit A. Artificial Intelligence.

Stephen Hawkins has come out against robots, which seems slightly bizarre for a man who’s very means of communication owes a lot to robotics and intelligent computer wizardry. Has Hawkins watched too many dystopian Sci-fi films? Or has his voice-computer has broken free of his puny human control and become rather out-spoken? Or maybe he actually has a point. Nevertheless, Techland is consumed with making ‘THE SMARTEST’ product that they can so that us humans don’t have to bother with thinking.

Exhibit B. Japan’s virtual sex industry.

Japan’s population is now shrinking. Some say this is because people are now getting their fix virtually and building ‘relationships’ with tamagotchi-type substitutes for real human contact to such an extent that simple communication with another human being seems utterly intimidating and futile. Nevertheless, parts of Techland are ever more consumed with making technology a substitute for real human relationships.

The list goes on with VR to replace reality or Google search to replacing having to actually remember anything.

So my point is this: Although there’s a certain sense of ‘progress for progress’ sake’ in Techland leading to a dismissal of those who resists the inevitable tide of progress as ‘technophobes’ or ‘noobs’, when it comes to writing the code this is positively reversed.

For coders, the mantra is more “just because you could do it that way doesn’t mean you should.”

The more a coding language enables the user, the more it’s users constrain how it is able to be used.

The more lenient a coding language is on it’s users the more rules and regulations it’s users impose on themselves.

I feel kinda bad for Yukihiro “Matz” Matsumoto who wrote Ruby. He gave Ruby so much intelligence and nifty functionality, yet a lot of these exciting shortcuts are considered ‘bad practice’ amongst Ruby coders.

There’s a belief that just because Ruby is super intelligent, doesn’t mean that you should just sit back and let it do everything. Just because Ruby lets you solve the problem in one line of code, doesn’t mean you should do so.

Similarly Douglas Crockford’s ‘Javascript, The Good Parts’ focuses on the bits of the Javascript language you should use. He encourages you to discard the rest, the bits he calls the ‘bad parts’. There are a lot more bad parts to JavaScript, as I have learnt this week in my introduction to the language…

…But surely you should be using all the tools in the toolbox to get things done?

It seems that the more tools and methods a language gives you, the more you should discard.

Just because you’re an extra in a film and meant to be sweeping the road, doesn’t mean you should sweep the road.

Weird right?

Here’s a list of some of the things you shouldn’t use in Ruby and why.

Global variables.

If a Makers Academy coach sees a $ anywhere in your script, they may have a nervous breakdown. Why? Because you’ve effectively given your $variable carte blanche to be anywhere in your program, meaning that you’ve given anybody who tries to add anything to your program carte blanche to use that variable anywhere they please. It makes your code harder to isolate when you test it. I could go on…

Class variables.

Same as above. Plus @@variable just looks darn ugly.

Forwardable.

Probably one of the oddest things in Ruby that I’ve encountered.The oddest thing about them is that they actually go backwards.

Using a forwardable, you can assign methods to variables without having to make actual methods in the longhand like so…

def method #do this method in here end

You can do it in this weird shorthand.

@blog_posts = [] def_delegator :@blog_posts, :push, :adding_blog_post def_delegator :@blog_posts, :pop, :last_blog_post

So this means, in short, instead of calling .push on @blog_post, call this method ‘adding_blog_post’. It goes backwards because you define the method name at the end, ‘adding_blog_post’, you say what it will do in the middle, and at the beginning you say what it can be called on.

@blog_posts.adding_blog_post 'Forwardable' print @blog_posts # => ['Forwardable'] @blog_posts.adding_blog_post 'Never do Forwardable' print @blog_posts # => ['Forwardable', 'Never do Forwardable'] @blog_posts.last_blog_post # => 'Never do Forwardable'

Nested ternaries.

These are my favourite things in the world, but you should never use them.
def grades(score) grade > 80 ? "A":grade > 70 ? "B":grade > 50 ? "C":grade > 40 ? "D":"E" end

Which actually means this:

def grades(score) if grade > 80 "A" elsif grade > 70 "B" elsif grade > 50 "C" elsif grade > 40 "D" else "E" end end
I love them because they make me feel like a whizz when I write them, squeezing everything into one line. You should never use them because they are so unreadable for anybody who comes to work on your code later. Normal ternaries are fine.

Coders can have martyr-like tendencies.

Most of the time they deny themselves using a tool that would make their own life easier in the short term its because they’re usually trying to make somebody else’s life easier in the long run. It’s not much fun reading through code that is using a bunch of forwardables and not understanding what they’re actually doing. Similarly, it’s not much fun trying to contribute to GitHub repo and seeing that all the variables are called things like ‘variable_x’ or ‘array_y’.

Or perhaps it’s not really martyrdom, it’s just plain selfish forward-thinking laziness. Coders know that ‘future self’ doesn’t fancy thinking too much about what that nested ternary actually does just because ‘past self’ couldn’t be bothered to press the few extra keys involved in typing if, else and elsif. Coders know that ‘future self’ doesn’t fancy trawling through a method that is 20 lines long and doing 3 different things at once when something goes tits up.

It’s about planned mental laziness.

However, it does feel sometimes that coders take special pride in making their life difficult for no apparent obvious reason. There are those who take a perverse masochistic pleasure in making their lives difficult.

Exhibit A. Vim users.

Vim is the most basic text editor you can use. It’s built into the command line. It has no nice JShint or Pigment packages like Atom – unless you spend hours customising the Vim-ness out of it until it vaguely resembles one of the many text editors out there that you could download in a matter of minutes.

i’m spartacus
i’m spartacus
i’m spartacus
i use Vim
i’m spartacus

— I Am Devloper (@iamdevloper) February 4, 2016

//platform.twitter.com/widgets.js

waiter, waiter
lemme guess, there’s a fly in your soup?
no i just wanted to say I use Vim

— I Am Devloper (@iamdevloper) February 8, 2016

//platform.twitter.com/widgets.js

Exhibit B. Anything designed for coders.

Take Github. Github is amazingly functional, but not exactly user-friendly. Firstly, it’s not the most beautiful looking of webpages – it has a plain white background for instance. It’s not something you can drag and drop into like GoogleDocs, it can only really be operated from the command line (they do have their own command-line esque add on thingy, but nobody really uses it). It’s not the easiest site to navigate either. I mean, where the hell is the delete button in case you accidentally put a sensitive file up there that you didn’t mean to. There isn’t one. You have to do these 9 awkward steps:

https://help.github.com/articles/remove-sensitive-data/

Exhibit C. Pride in mastering languages like Brainfuck.

This is ‘Hello World’ in Brainfuck.

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

I would put mastering something like JavaScript in here too. Okay, okay, it’s ‘The Language of The Web’ so it’s kinda a necessary evil. However, like I wouldn’t live in a house that was built in 10 days, I wouldn’t code the world web in a language that was written in 10 days. (There will be a full post coming up on the ridiculousness of JavaScript)

Coders are paradoxical.

They like rules but complain about them a lot. Especially when they seem to contradict each other.

They want to make technology that makes other peoples’ lives easier, but don’t seem to carry this through to the technology that they make for themselves.

They love languages that are intelligent but worry that they might be too intelligent for their puny human brains.

They love niche hidden ‘easter egg’ type syntax but deny themselves the pleasure of using it in case it causes anybody else unnecessary pain.

Coders are the type to spend ages perfecting the perfect paper-into-nearby-bin-throw.

They’re the type who look up cheat codes for games they play but hate pay-to-win fremium games.

Or why they automate their entire job with a few lines of code.

Because, ultimately, coders are ultimately both lazy and enjoy a challenge.

MagicNumber == 10

Posted on February 6, 2016 by Planosophy

Coders have a peculiar Noah’s Arc arrangement.

They come two by two.

They call it pairing. As in ‘pair programming’.

At Makers Academy, life centres around pairing. We pair all day every weekday swapping pairs every morning.

However, I don’t really see it as ‘pairing’ at all.

Let me explain.

When you think of two people spending time together, say a couple, you’d think it was a bit odd if they spent 70% of their time together looking at a screen. Like, I know ‘Netflix and Chill’ is a thing and all, but apparently you don’t pay more attention to the Netflix than the, you know, the ‘chill’.

When you pair program, I’d estimate that you spend about 70% of your time looking at a screen whilst you talk.

Surely it’s a bit odd to be looking somewhere other than the other person’s face in a one-on-one, you know, two-people-involved conversation for the majority of the time? I mean, if Albert Mehrabian is to be believed, we’re missing out on 55% of communication – the vital non-verbal bits like facial expressions and body language.

No wonder it can sometimes feel like there is a rather prominent 3rd wheel protruding from the tandem of coding bliss.

Yes. The computer.

So when you pair you’re basically having a sort of threesome with a computer.

Yeh, I said it. Or rather typed it.

I don’t think I would say that out loud.

Obviously it’s not like that dude did in the BBC’s ‘The Virtual Reality Virgin’, unless you’re into that kind of thing – but yeah, whatever floats your boat then, ey?

I meant it more in the sense that three can feel like a crowd, especially because, perhaps except for Eugene Goostman (the chatbot who managed to convince a panel of humans that he is, in fact, a human and therefore pass the Turing test), computers aren’t exactly emotionally intelligent conversationalists.

Computers make the worst dinner guest in the world.

This isn’t solely down to the fact that they don’t eat, and therefore directly insult the chef…

They want to be the centre of attention ALL. THE. TIME.

1993752b4799dab7c0622b91955b51d7

They’re downright inflexible.

images-1

They love pointing out all of your human flaws…

…especially forgetfulness and lack of attention to detail.

They can behave unpredictably at times…

…but then say that it’s all your fault that you haven’t been able to second guess what they might do when they don’t always let you know what they’re thinking.

They mostly only pipe up to punish you with aggravating and incomprehensible red error messages…

….a sort of mechanised word vomit, provoking a similar cringe-muscle reflex as when a friend throws up on the tube on the way home in front of the guy you’re trying to get round sometime for Netflix and Chill.

In fact, computers are darned rude.

So when you pair, you’re thrust into a rather awkward scenario where two of you have this rather uncouth and insensitive lump of silicon and metal making seemingly unreasonable demands in word-vomit gobbledygook.

Consequently, pairing can feel a bit uncomfortable at first because you’re trying to operate IQ and EQ simultaneously. You have to get inside your partners’ brain, fuse with how they are thinking about how the computer is thinking then talk to the computer and coerce it to be a bit more reasonable.

Clearly, you can’t just ignore the computer and have a nice day chatting with your pair partner.

That’s how no work gets done.

So why not just work on your own?

An online survey of pair programmers found that 96% enjoyed their work more than when they programmed alone. Clearly robotic threesomes are an acquired taste.

Many probably feel this way because the unwritten handbook of pairing etiquette can be contradictory and therefore difficult to fully adhere to.

Here’s a (by no means exhaustive) list of 21 faux pas of programming.

Screen Shot 2016-02-04 at 21.42.28.png

Why don’t we just forgo the awkward threesome?

Because you’ll probably slack off when things get difficult. Procrastinate. Spend hours looking for that typo you made.

(Above I proudly introduce ‘ERB face’ combined with the general Makers hand gesture for ‘I was coding when’… ERB is ‘Embedded Ruby’ – it’s like Ruby’s evil twin. They kinda look similar but they’re totally not because ERB hangs around with HTML and eats too much <%= ice-cream %> and has gotten fat and lazy. ERB face is the face you do when you first gaze upon it’s sheer monstrosity, which inevitably looks a bit like you’ve been ice-cream-coned in the face.)

Or just be a bit naughty…

…about observing best practices thinking ‘oh, well, it’s just me and my computer’s dirty little secret that we skipped a few unit tests, or dropped the global variable $-bomb. Nobody. ever. need. know.’

Until the damned thing breaks.

95% of those pair programmers also stated that they were more confident in their solutions when they pair programmed.

I would definitely agree.

Collective responsibility is so important. You need to have those debates about how to design the program, you need somebody to tell you to not get carried away with the code and write the test first. You need somebody to say, woah, hang on a minute, typo – otherwise you could be looking for that typo for a while. You need somebody to outsource your googling too so you don’t end up on cat videos on Facebook and wondering what the hell you were mean’t to be doing.

So generally, working by yourself may feel faster and less frustrating, but that’s how buggy and less well designed work gets done.

So here’s what makes for happy computer threesomes

… And it’s rarely at all related to how ‘good’ at coding you or your pair is.

a) Being laid back, but not so laid back you’re both horizontal.

c) Patience, just lots of patience.

d) An understanding that it’s never about demonstrating knowledge and coding wizardry, but about sharing it. It’s not about one-up-manship, it’s about two-up-against-computer-manship.

But most importantly…

…Communication

Use these following phrases frequently:

“Yeh, why not. Let’s just try it. See what happens”

Chandler-and-Joey-Rock-Paper-Scissors-joey-and-chandler-26773017-250-188.gif

“I found this thing on Stackoverflow. Wonder what it does.”

“Oh… Interesting. So it actually does this.”

“Oh well, could have worked. Let’s try this way.”

“Woah, what did you just do?”

as in.. “I never knew ‘Ctrl + Cmd + up’ would move a line of code up.”

or … “How do I get my command line to have that?”

or … “I didn’t know that ^= does that.”

“Don’t we need to write the test first?”

“But what about…” (insert best practice terminology, such as Law of Demeter, Single Responsibility)

“Shall we make it pass then tidy up?”

“Its kinda like a …” (insert metaphor)

“Let me draw a diagram”

“Show me what design you’re thinking of”

“Shall we read around this a bit alone then get our heads back together in a bit?”

Try to never use these phrases:

“No, but.”

“My way is definitely better.”

“It would be faster if I just did it.”

“Why don’t you get it? It’s not that difficult to get.”

“Jargon, jargon, jargon, jargon blah blah blah.”

“Why the hell would you do that?”

“taptaptap ts ts ts badumdum taptaptap “

(Ie. Nothing at all except the sound of typing and the tinny sound of somebody else’s headphones throbbing away in their ears.)

Testing: The Art & Science Asking Questions

Posted on January 24, 2016 by Planosophy

Why are we so keen to ‘get the answer’ and not ‘ask the question’?

I’ve been told, for most of my learning life, that I will be rewarded with gold stars and good jobs if I can answer questions.

All my life I have learnt to pass tests; spelling tests, maths tests, GCSEs, A-Levels then finals at Uni.

Life is geared towards ‘getting the answer’ – few of us think to ask whether the question being asked is the right question to ask and hence worth answering.

There are no gold stars awarded for opening your exam paper and writing 10 alternative new questions then answering those instead.

In fact, you’d probably get a big fat FAIL.

And so, whilst we’re all pretty good at deploying our knowledge to answer questions, most of us are shit at asking good questions. We kind of skip to the ‘important’ bit where you answer the question and get the gold star.

However, the art of asking the right questions (a.k.a “Testing”) is just as skilful, if not more, than answering questions. As these exam answers show – there’s a lot of room for misinterpretation.

enhanced-buzz-23347-1431370121-7

There’s even more room for misinterpretation when you’re testing a computer.

Coding is a bit like trying to direct a blindfolded person with a very very limited vocabulary, who is standing in a different room to where you are standing, to a sit on a chair that neither of you can see. You’re trying to speak to them in a language you don’t really understand and all you have is a vague map of the room next door, but you don’t even know if you’re holding the map the right way up and you might be having trouble understanding what the symbols on the map mean.

This is why you need tests.

To test if you’ve got the map the right way up.

To test if your blindfolded person heard you, then understood you when you asked them to move right.

To check they actually moved right.

To check didn’t walk into the wall in the process of moving right (if they had you might have had the map the wrong way up…).

To check that, in the end, the person ends up sitting on a chair and not a beanbag.

It’s kinda like something from the Crystal Maze. Wow, what a show. I hope it comes back soon.

Coders are Testaholics.

They have entire theories and concrete working practices for testing your code to find out if it’s doing the right thing.

They have banter about testing code.

They have programs with mental names that you can use to test your code.

Screen Shot 2016-01-19 at 17.51.19.png

(I took the screen shot above from here – honestly, this is what it said. It made me hungry until I remembered that I don’t like rabbit food, which cucumbers, gherkins and spinach undoubtedly are.)

They get high off green lettering.

Red lettering negatively impacts their mood.

When you learn to code, developers’ intense focus on testing can be super counter-intuitive.

Like, really fucking odd.

Not only have you been taught for most of your learning life that getting the answer is more important than asking the right questions, but also, when you first start coding you write code in a way that is totally unaware of testing.

You’ll probably have more flow, writing one-liners of method piled onto method that get you to your answer. Stuff like this:

string.split("").each {|x| x*2}.join(" ")

Writing code will make you feel like you’re being a bit of a whizz when it passes when you run your program from the command line to…

… test it.

So, actually, you have been testing stuff already, you just didn’t realise it.

When you run your program from the command line, you are actually testing whether it is ‘behaving itself’. You know, playing ball…

BDD (Behaviour Driven Development)

This is when you test that your program behaves in the way it is expected to. This is the ‘above the hood’ stuff – like when you flick a light switch, the light turns on.

Tests that do this are called ‘Feature Tests’ or ‘Acceptance Tests’. They’re kinda results-driven. A sort of, “if I put in x will I get out y?” scenario – they’re less concerned with how x became y. Some nutters might call it testing the “outside” of the program, because you’re not testing the stuff ‘under the hood’, but just the stuff that a user can interact with.

I’m not convinced programs can have outsides when they exist inside computers.

When you start out, you’ll probably run these through IRB (Interactive RuBy shell – this is a ‘REPL’, Read Evaluate, Print and Loop ThingyMcbobbin that allows you to run your programming script more than once and feed in different commands.)

What you’re probably less familiar with is…

TDD (Test Driven Development)

This is when you test all the little tiny weeny steps that need to take place to get the program to behave in the right way. This is all the ‘under the hood’ stuff. This is like checking to see if the lightbulb’s filament has gone, or the wire coming out of the lightbulb hasn’t been chewed by the cat, or that the switch has been wired up correctly.

Tests that do this are called ‘unit’ tests. They’re kinda process-driven. They’re more interested in breaking down everything into tiny weeny steps to see if the steps were carried out as expected. They’re more interested in the route between x and y.

The point of this is that you can pinpoint exactly where things have gone wrong. It’s about identifying the weak link in the computer’s chain of command. It’s apparently super helpful to real developers and saves a lot of time when it comes to fixing bugs later on.

Imagine if a customer came to you and said “the lightbulb isn’t turning on” and you had no idea about how lightbulbs worked, or electricity worked, or how a switch worked. You wouldn’t be able to sort it out at all and would probably just end up bashing away at the switch angrily.

Unit testing is the most counterintuitive of all testing.

Why?

Because it’s so slow. So painfully slow. So unbelievably myopic and time consuming. Every little goddam thing needs to be tested. EVERYTHING. For somebody with ADHD, this is so freaking painful. LET ME WRITE PROPER CODE ALREADY! It’s forensic, it’s iterative, and it can be really frustrating because…
If you don’t know what your code is doing in absolute detail, you don’t know how to test it.
Rspec, the language used to write ‘tests’ that you run your code through, is written in a bastardised form of Ruby that is similar enough to lull you into a false sense of security about writing and reading it, but different enough to thoroughly screw with your head. Because of this, you’ll trust the code you’re meant to be testing more than the tests that are meant to make you trust your code more. Which makes you seriously question the whole notion of testing.

(I’ll come back to Rspec another day in more detail as I’m still not 100% confident with it and I haven’t thought of a nifty way to philosophize around it to make it more digestible.)

But, the biggest headfuckery is writing the test first.

You have to write a test then make the code pass it.

You must fight all of your instincts and years of learning how to answer questions and say: NO! NO! I WILL NOT ANSWER THE QUESTION.

I WILL ASK THE RIGHT QUESTION.

Which is problematic, because you’re asking a question in a similar but different language to the language that you’ll use to answer it in your script code.

Ok. Let’s try this:

describe IHateRspec do

it { is_expected.to respond_to(:brainmelt)}

end

You are meant to write the absolute minimal to get the Rspec test to pass. THE MINIMAL.

No racing ahead with the answer. No. You must stop.

class IHateRspec 

  def braimnelt
     puts "It hurts, it hurts" 
  end 
end

Run Rspec from the command line.

RED? WTF?

I know my code is right. All I did was define a method. I didn’t even write the method.

I DIDN’T EVEN WRITE THE METHOD.

You start messing about with your rspec, which you assume is the culprit.

(2 hours pass)

Why can’t there be a test to test your tests?

(2 hours pass, you miss lunch)

Or perhaps your code is wrong.

(10 seconds pass)

Oh.

Typo in my code.

Goddamit.

Learning to code is like… London Transport

Posted on January 18, 2016 by Planosophy

Remember the dark old days before CityMapper and GoogleMaps?

Those days when your parents would warn of the perils of not taking a A-Z map in the car with you.

Those days when, before you would leave somebody’s house, there would be a lengthy discussion about which route would be the best to take on your journey home. These discussions could last anything up to 30 minutes, because, of course, whatever route you took to get there wouldn’t ever be the route they would take.

Those days when people took pride in knowing the best route without having to look it up and would laugh at tourists for standing gormlessly in front of the station tube map, frantically counting little notches between ‘here’ and ‘there’.

Those days when pretty much everybody would carry some form of tube map with them at all times but pretend they knew the tube map like the back of their hands, because they’re a “Londoner” and their DNA is composed of the Jubilee line helixed around the Northern line.

Those nights when you actually had to look at the letters atop of a bus stop pole.

Those days when you remembered street names and addresses and post-codes only seemed relevant when, well, you posted something.

Those days when people told anecdotes about getting lost.

Those days when you could use ‘getting lost’ as a failsafe excuse for being late.

Remember those dark old days?

Nobody gets lost any more.

Nobody.

Well, people who don’t know how to operate a smartphone may still get lost. But hey, they’re probably the kinds of people who like getting lost – the kinds who travel to Inner Mongolia specifically to ‘lose themselves’. People like Bear Grylls.

For most of us, there is a certain fear of getting lost. It makes us anxious.

Why?

When you’re lost you’re not in control. When you’re not in control, you’re at the mercy of ‘greater forces’ around you. When you have no say over how to get from A to B, the uncertainty of whether you’ll ever get to B can be a bit daunting.

Although people don’t get lost anymore, as is usually the case, something important has been lost in the name of so-called “technological progress” (and if you can’t identify what’s been lost, just demo whatever technology it is to your (grand)parents).

With the birth of GPS technology came the death of navigating uncertainty skilfully.

Learning to code is all about navigating uncertainty.

When you start out, you don’t know anything. You don’t even know how to know more because you don’t know what you don’t know.

It’s all unknown unknowns and error messages at the beginning.

So here’s the tortured metaphor.

Imagine you don’t have a smart phone and you’ve moved to London.

The first day you’ll learn the route to your nearest shop. You need to eat, so you’ll figure this out.

The next week you’ll figure out the tube route to work and a few nearby eateries. You probably won’t know what’s en route to work, you just know this isolated ‘city island’ or ‘urban village’ cut off somewhere North, East, South or West to where you live.

At some point in the week after, your born-and-bred Londoner friend invites you for a drink. You get the tube there and you mosey around a bit. You have a mental picture of another isolated island somewhere in London, this time near to where your friend lives.

One day you get drunk and lose your Oyster card. You are forced to walk home from the pub near your work. You’re terrified because you don’t know the route, but you’ve lost your wallet so you can’t take a taxi (you may have also lost your job at this point if you’ve been this sloppy drunk whilst at a work pub-session just a few weeks after you started).

You ask people around you for directions, listening carefully to the sequences of lefts and rights interspersed with names of key landmarks and tube stops that they hope will orientate you. You walk past where you went for a drink with your friend the other night. You walk past a tall building that you can see from your house. You then realise you’ve been paying £5 a day to get a tube to get to work, when in fact, it’s a rather pleasant 30 minute walk.

No need for Uber trips like this anymore…

Because, all of a sudden, London doesn’t seem quite so big and scary.

Over the next few months you realise, the more you explore, the more you let go of your map, the more you trust you are walking in vaguely the right direction, the more you look for landmarks you recognise and attempt to join the gaps between A to B, the smaller and smaller London seems to get.

This is like learning to Code because…

‘The Knowledge’ is just for Cabbies.

If you get bogged down in having to memorise the entire map the more you realise that you simply can’t know all the street names in London.

Nobody expects you to know the entire Ruby Docs inside out and back to front. They just need you to be able to navigate between key terms and concepts, like navigating between key landmarks.

Some people may know the docs inside out and back to front. This is probably because they write/update it. A lot of it is specialist knowledge.

Trusting your sense of direction is vital.

Having a sense of direction, and, more importantly, faith in that sense of direction is vital.

This doesn’t mean that you ignore other people’s directions if you ask for them, but it does mean that if you don’t know all the street names they’re referring to, you pay close attention to them gesturing left/right or giving you distances between landmarks.

More importantly, you should trust that you’ll eventually get there. With this comes recognising that…

Getting lost can be productive.

If you become reliant on the tube route and never stray from it you’ll never learn faster ways of getting your code to process something from A to B.

Explore and experiment without fear of ‘getting lost’. Be a little bit curious. After all it’s just a computer. It’s not like you’re experimenting with open heart surgery.

Sometimes finding a way out of being lost is more productive than never getting lost in the first place.

You’ll join up points in your ‘code knowledge map’ when you accidentally wander off piste.

One day you’ll be the one giving directions.

And you’ll know how difficult it was for you when you were drunk, penniless and lost.

So be kind on the ignoramus Tourists.

Jargon

Posted on January 10, 2016 by Planosophy

Jargon: The biggest barrier to entry into code-land.

Like not speaking French : The biggest barrier to entry to living in France.

Here’s a Slack conversation I had with my mentor at Makers Academy this week:

Me: “I don’t understand, something seems to have gone wrong. There’s an error: blah blah Fixnum coerced blah blah…”

Actual Coder: “What’s your terminal stack trace saying?”

Me: * Googles terminal stack trace *

Wikipedia: “In computing, a stack trace (also called stack backtrace^[1] or stack traceback^[2]) is a report of the active stack frames at a certain point in time during the execution of a program. When a program is run, memory is often dynamically allocated in two places; the stack and the heap. Memory is contiguously allocated on a stack but not on a heap, thus reflective of their names. Stack also refers to a programming construct, thus to differentiate it, this stack is referred as the program’s runtime stack. Technically, once a block of memory has been allocated on the stack, it cannot be easily removed as there can be other blocks of memory that were allocated before it. Each time a function is called in a program, a block of memory is allocated on top of the runtime stack called the activation record. At a high level, an activation record allocates memory for the function’s parameters and local variables declared in the function.”

Me: * Mutters to self, rummages for pen and paper, draws a diagram with a box labelled stack and a box labelled heap *

Actual Coder: “Dude, what’s your stack trace saying?”

Me: “What’s a stack trace? The thing in my terminal window box thingy is saying I have a problem with Fixnum coercion. Does that mean there’s a problem with my stack trace?”

Actual Coder: * Sigh * “Those are the error messages in the terminal when you try to run code that has errors. Usually the main errors are Standard Error runtime error type error no method error initialised constant error.”

Me: “Oh. So I haven’t got anything wrong with my stack trace. My stack trace tells me what’s wrong.”

Me: “So what’s a “Standard error runtime error type error no method error initialised constant error?” Sounds pretty serious to me. Is that what I’ve got?”

Actual Coder:

And this is why jargon is the biggest barrier to entry to learning how to code.

Because Jargon is code.

Jargon is just code about code.

Therefore, to learn to code, you need to learn the code used to talk about code.

I used to think that people who use jargon were mean or wanted to sound clever, that it was some sort of deliberate and malicious attempt to confuse, obfuscate and generally hinder my ability to understand what the hell is going on.

It used to be like this in advertising, where people would use jargon in boardrooms to protect their own personal “knowledge = power” equation. Jargon plays a powerful role in Adland when it comes to office politics.

It’s a way of shutting people out who they don’t want to know what they’re talking about in an ‘important conversation’ – A bit like how parents might spell out swear words when there are kiddy-winks around.

Conversely and confusingly, it is used by people who don’t know what they’re talking about when they want to give off the impression they know what they’re talking about.

It mainly came in the form of TLA’s (Three Letter Acronyms) and buzzwords.

“Can I get that wash-up by EOP today. I need key metrics like the PPC’s CPP and the CTR. We can find out the ROMI from that – that’s what the client is interested in anyway. Might be good to compare these with OOH figures. Inbox the deck to me.”

HUH?

I got so annoyed with buzzwords and jargon in Adland that I wrote a blog each week ripping into the buzzwords in a satisfyingly passive-aggressive manner. I wrote an article about a chosen buzzword, then put in blanks every time I used it. It got quite a bit of traction in it’s day.

At least in Code-land, unlike in Adland, the jargon is, well, freaking hilarious. There are some truly ridiculous words and phrases that get brandished around in all sincerity. I mean, ‘git commit’? Sounds like an order that a 35 year old unmarried woman says to her long-term boyfriend who still goes on ‘lads nights outs’.

But this isn’t the only difference between Adland jargon and Code-land lingo.

In Code-land jargon plays a very different role. Although it seems downright unhelpful to ask what (you think) is a simple question about the code you’re struggling with and be answered in gobble-di-gook, it’s not because there’s some sort of conspiracy to prevent you from understanding what is going on.

There’s a very good reason so much jargon exists in Code-land.

It is this:

Code-land simply wouldn’t exist without jargon.

Let me explain:

Newness

At university, during my Art History degree, I got quite in to a branch of philosophy called Semiotics – the study of signs. Words are just signs that ‘point’ to concepts, just like in coding ‘variables’ are just words you give to things you want to refer to again.

my_age = 24

your_age = 33

age_difference = your_age – my_age

Here my_age just points to the number 24. Like your_age points to the number 33. Therefore age_difference points to 33 – 24.

Every time you want to ‘make’ something new, you have to give it a name. A new one usually.

‘Makers Academy’ : The clue is in the name.

Computer programmers MAKE stuff. Every time they MAKE something they have to give it a name. This name is what you and I might call JARGON.

Abstract Concepts

Jargon is vital in Code-land because otherwise we would have to re-explain whatever mind-bendingly abstract concept we were trying to talk about every time we wanted to refer to it.

Code is the most abstract thing you can do. Even more abstract than a Pollock.

How the hell am I meant to explain what a ‘String’ is and does every time I want to make / use one?

Take 1 – Imaginary conversation with somebody I’m programming with:

Me: “So we need to basically tell that 6 figure number that we want to pretend it’s not a number for a bit, tell it to act more like a word or like a quote or something, so we can repeat it 3 times rather than getting the 6 figure number multiplied by 3.”

Actual Coder: “HUH?”

Take 2 – Imaginary conversation with somebody I’m programming with:

Actual Coder: “Hey, we probably need to convert that 6 figure number into a String so we can repeat it six times.”

Me: “Cool.”

Me: “What’s a String?”

Actual Coder: * Sigh *

Me: “Kidding.”

Me: * Googles ‘String’ quietly *

Clarity over Tools

Programs are just tools. You have to give each one a different name because they all do something ever slightly so different.

If you asked me to chuck you the “dust-cleaner-mcthingymcbobbin” and you were expecting a dust pan and brush, you might be a bit annoyed if I picked up a vacuum cleaner and threw it at you. Names help you to be specific.

Nobody had come up with a icloud-cross-linkedin-cross-googledocs for coders to upload their code onto for others to see and work on with them.

Until they did.

When they did, they called it ‘GitHub’. Not ‘iCloud for coders’. They called the files you had linked to ‘the cloud’ repositories (or repos). They called ‘saving’ ‘commits’. They called ‘uploading’ to the cloud ‘push’ and downloading ‘pull’.

Why?

You might need to talk about both uploading and pushing in the same sentence.

And boom. You have spawned a whole dictionary of jargon in order to ensure the things your iCloud for coders does don’t get confused with your standard iCloud features (like upload or download).

How to cope with jargon

Swallow your pride.

Just say you don’t have a clue. Nobody cares how stupid you look whilst you’re still learning. Those who care don’t matter, and those who matter don’t care.

Don’t follow wikipedia around for the myopic ins-and-outs of the jargon you’re looking up.

If you need more detail, it will surface at some point in the future.

Try and translate the concepts that the jargon is dealing with into concepts you know and understand by using analogies.

Have a few favourite go-to analogy topics. Like football. Football can be used to explain almost anything. These analogies/metaphors may be really tortured at first, but then just explaining it to yourself in terms of football might make you realise that actually it might be better to explain to yourself in terms of gardening, or baking or something.

Laugh at them.

Sticks and stones may break my bones, but words will never hurt me.

Preconceptions

Posted on January 2, 2016 by Planosophy

“Never assume. It makes an ASS out of U and Me”

– Anon

Screen Shot 2015-12-30 at 15.43.28.png

Most people will tell you that preconceptions, prejudices, assumptions and biases are totally not cool. I prefer to think of them as educated and imaginative guesswork and part of a system of trial and error.

Assumptions enable you to make quick ‘near enough’ decisions when lacking the time to collate the necessary information to make a fully informed decision.

When I decided that I’d learn to code at Makers Academy, I relied on assumption and preconceived notions (coupled with a hefty dose of idealism and imagination) of what it would be like to be a computer programmer. After all, I had never been a computer programmer, so how could my decision to spend all my savings and the next four months of my life learning to do something I’d never done before be anything other than an ‘uninformed’ decision?

Here’s a post-rationalised list of the assumptions and preconceived notions I had of coding that informed my uninformed decision.

What coding is:

Everywhere.

Pretty much everybody has come into contact with something that has been programmed.

Magic.

Nobody seems to know how computers work. That I can access any information in the palm of my hand, whilst remaining entirely ignorant as to how and why, is pure wizardry.

Difficult.

Get your head around this.

You tap a small silver box with a black ‘U’ on your iphone, then tap a box labelled ‘set pick up location’ hovering above a map with a blue dot signifying exactly where you are and tap where you want to go on that map, then, within minutes, a nice person arrives in their new smelling immaculate car at exactly the point where you are standing to drop you off at exactly the point where you tapped on the map, then departs without having to ask you for directions or even money.

Imagine understanding how that worked.

Then imagine being the person that made that work.

I can imagine that’s what being a genius feels like.

When coders say “anybody can code”, this reads to me like a well-intentioned humble-brag. It’s well intentioned because it keeps the dream alive, reminding us that it’s not impossible. But at the same time, if it were actually easy then saying “everyone can code” would literally go without saying. Nobody would say “everyone can code” if it really were that obviously true – it would be like saying “everyone can breathe.”

Therefore coding is difficult, challenging and thus rewarding.

Objective.

One word: Dopamine.

Meritocratic.

In most other careers, success is based on being subjectively good at your job. Objective feedback is rare. Many succeed through navigating office politics seamlessly – which, don’t get me wrong, is a skill in it’s own right, but just not one I find as rewarding to develop. I can play politics, but it just feels a bit false.

Your computer doesn’t not like you if you don’t listen to the right music, or if you’re a smoker, or chew too loudly when you eat. It only likes you if you get the code right. Your boss will like you, first and foremost, if you get the code to work efficiently. Your boss may also like you if you laugh at their jokes, but, for some reason this feels less important for a programmer.

I feel that people accept that programmers might get along better with computers than real people – it seems to come with the job. I only know two programmers, and this seems to be the main reason they like their jobs. They say there are some politics, but usually, when you’re one of the few with the pre-requisite knowledge to make things actually happen, people prize your knowledge over and above your personality.

I’ve sat in appraisals where my worth to the company has been based on pretty much everything other than my tangible achievements. Although they say “don’t take this personally”, given the lack of objective reasoning as to your contribution to a team, you can only ever take it personally.

In the rare occasion of your value to a company being more objectively assessed, it can feel like success is pretty much luck. Let’s face it, there is no exact science to knowing why people might buy one book over another, or why some people like some music and not others, or why some people believe renationalising the railways is a good idea and not others. You never really know why you’ve succeeded in doing your job ‘better’ because you don’t really know how much you, doing your job, has contributed to whatever metric of success you are being measured against.

You know if you’re getting better at programming because you can make more complicated things work, more efficiently, faster. And the computer will tell you. With no bias.

The better you get at programming, the more languages you can programme in, the more problems you solve, the more efficiently you solve them, then the more you’re worth and the more responsibility and money you’ll earn.

Who codes:

An insider club.

Coding feels like an insiders club. They have insider jokes (which I’ll dedicate a bit of my blog to, because they are just so brilliantly esoteric) and insider knowledge that bonds them together. They’ve connected across time-zones and continents, forming a tightly knit community with it’s own quirks and charms born from a common insatiable desire to solve problems.

Collaborators.

They use their own time and expertise to help others master coding, most of whom they’ve never met and will never meet, for free and for fun

They spend hours trawling through StackOverflow to answer other coders’ questions. I’ve never seen a troll on StackOverflow.

They make coding puzzles for other peoples’ enjoyment – www.codewars.com being my favourite.

They helpfully point out bugs, they collaborate on open source projects.

They make websites that they’ve clearly spent hours and hours working on to help people learn to code FOR FREE. https://rubymonk.com/ or https://www.codecademy.com/ or http://learnrubythehardway.org/

They defy the laws of behavioural and economic physics. They do all this work for free, to help other people, for free.

The humble.

Despite being an elite group of super-humans that not only understand the mysterious world of technology but actually built it, they never see themselves this way.

11825176_1603418429920793_1196420569297949286_n

There are a few reasons why only the humble can code.

The more you know, the more you realise how little you know. It would be near impossible to know everything about coding, to learn every language. The more you know, the more you realise that there is much, much, much more to know. You never can feel like a know it all. You have to be happy about dealing with uncertainty and not knowing.
Computers tell you ‘no’ all the time. There are no marks for ‘effort’, or ‘nearly there’ – you get nasty error messages in angry red type if you’ve screwed up. You have a man-made object telling you that you’re doing it wrong every few minutes, and you can’t dispute that it is ultimately your fault.
You stand on the shoulders of giants every day. You didn’t make the Ruby coding language, you aren’t Alan Turing. You are NOTHING in comparison.

Often coders aren’t looking for fame or recognition. They just want the code to work – this is their reward.

The next generation.

I remember watching my Dad spend 45 minutes trying to send an email, muttering about how technology is meant to make things easier and angrily tapping away at his keyboard using just his index fingers.

In just a few years time, I will be like my Dad, unless I learn to code.

Coding is now being taught in schools.

There are pre-pubescent kids who have made millions from apps that they have programmed, all by themselves.

I refuse to be left behind.

Mostly men.

Women are chronically under-represented in coding. In fact, females in tech are considered such an oddity that the BBC felt compelled to make a documentary about young girls learning how to code. It was also the most patronising piece of guff I have ever watched.

I can’t see any reason why women can’t code or why this bizarre thought has even entered into discussion.

And neither can Makers Academy – which is why they give a nice discount to women taking the course. They want to make more female coders to dispel this awful myth that women can’t do it.

I’m the kind of person who will do something just because people think I can’t do it.

Bring it on.

Just Preconceptions…

At the end of my course at Makers Academy I’m going to come back to them and grade these preconceptions out of 10 for their varying levels of naivety, wishfulness and downright misguidedness.

Do let me know if I’ve got it all wrong in the comments below:

Inception

Posted on December 30, 2015 by Planosophy

“Begin at the beginning,” the king said, very gravely, “and go on until you come to the end: Then stop.”

– Lewis Carroll, ‘Alice in Wonderland’

If only it were that simple.

Screen Shot 2015-12-30 at 13.50.45.png

What is a beginning?

I’m ‘beginning’ to learn to code, but I don’t really know when, where and how this began and consequently when, where and how to begin this blog.

Perhaps this blog is the beginning.

Perhaps not.

Does a beginning begin at the end of an end?

What came before has ended. I’ve quit my job, or my job quit me.

I was working in the soul destroying world of Advertising and innovation. It was a Dismaland inhabited by nervous Narcissists , manipulative Machiavellians and those who they have lured to the dark side under the false premise of creative freedom impossibly coupled with financial security.

I have not blogged on Advertising for over six months. That blog ended, so perhaps this blog is the beginning.

Perhaps not.

Can an end begin a beginning just by coming to an end?

Life is just one thing after another.

If you don’t begin something when something else ends you’re left with an impossible void.

Perhaps I’ll quit Advertising and do nothing.

Perhaps not.

Perhaps I’ll quit Advertising then become a florist, a teacher, an astronaut, a politician, a sommelier, a nomad, a fireman or an ice-cream taster.

All options of varying viability to fill that impossible void.

Perhaps not.

Perhaps an empty void is a viable way to fill the impossible void. After all, an empty void begins after the non-void bit ends.

Perhaps not.

(I had already experienced the impossibly empty void whilst working in advertising and found it unsatisfactory.)

Or does a beginning, by beginning, end an end?

Is it more a case of having to quit Advertising to become a florist, a teacher, an astronaut, a politician, a sommelier, a nomad, a fireman or an ice-cream taster?

After all, you couldn’t do both at once.

Or perhaps you could.

Perhaps not.

So a beginning, by beginning, doesn’t necessarily bring about an end.

Unless you want it to.

What makes you want to end something?

When you’re in the middle, the end is a known unknown. You know it exists, but you don’t really know what form it takes.

Why would you end something without knowing what comes next?

Why would you end something unless you felt you could begin something else that would be better than what you were doing before?

How do you know what you want to begin would be better than what you want to end doing?

You don’t know.

You imagine it might be better.

I wouldn’t have got into Advertising if Mad Men had been set in the present day and Advertising agencies weren’t so damn cool looking and well-branded compared to the corduroy clad, musty library laden microcosm of ivory tower academia at Cambridge.

Christ. I’m such a mug. Deceptively selling an aspirational lifestyle is the whole point of advertising.

Does the beginning of the end begin when you imagine what begins after the end ends?

I would still be in Advertising if it wasn’t for some sort of idea planted in my head.

Perhaps in my sleep.

Perhaps not.

It said “code”

I liked it.

I thought about it a bit more.

I liked it more.

I thought about it a lot more.

I liked it a lot more.

I thought about it all the time.

I got frustrated by how much I liked it.

I quit my job.

I liked it.

I applied to Makers Academy.

I liked it more.

I passed the interview.

I liked it a lot more.

I’m now writing this blog post.

So perhaps this is the beginning.

Perhaps not.

June 2017
M	T	W	T	F	S	S
« Apr
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30

*Illogicode’s jingle*

In the spirit of keeping promises…

Coding is Objective:

What I said:

What I should have said:

Humble People Code:

What I said:

What I should have said:

Because coders have a snobbish attitude to themselves.

If Makers has taught me anything, it’s taught me that being taught isn’t all its cracked up to be.

Why? Why not just give me the sodding answer? WHYYYYY?

First things first.

What the hell do I do?

Learn to love JavaScript?

Had I gone completely effing mad?

Top learning tip No.1: Turn off the sound on screen casts.

Top learning tip No.2: Do the exercises in the book.

Top learning tip No.3: Test drive

The second half of the week involved scrapping together an API.

Jason, whoever he is, sounded alluring and exciting.

Top learning tip No.4: Know what you are building.

And so, unfortunately, I ended up meeting the boring Jason.

What I learnt:

I’ve decided that Tech people, in a controversially sweeping generalisation, live by the mantra “if you can make it, you should make it.”

Exhibit A. Artificial Intelligence.

Exhibit B. Japan’s virtual sex industry.

For coders, the mantra is more “just because you could do it that way doesn’t mean you should.”

Here’s a list of some of the things you shouldn’t use in Ruby and why.

Global variables.

Class variables.

Forwardable.

Nested ternaries.

Coders can have martyr-like tendencies.

It’s about planned mental laziness.

Exhibit A. Vim users.

Exhibit B. Anything designed for coders.

Exhibit C. Pride in mastering languages like Brainfuck.

Coders are paradoxical.

Coders have a peculiar Noah’s Arc arrangement.

However, I don’t really see it as ‘pairing’ at all.

So when you pair you’re basically having a sort of threesome with a computer.

They want to be the centre of attention ALL. THE. TIME.

They’re downright inflexible.

They love pointing out all of your human flaws…

They can behave unpredictably at times…

They mostly only pipe up to punish you with aggravating and incomprehensible red error messages…

In fact, computers are darned rude.

Clearly, you can’t just ignore the computer and have a nice day chatting with your pair partner.

So why not just work on your own?

Why don’t we just forgo the awkward threesome?

Or just be a bit naughty…

95% of those pair programmers also stated that they were more confident in their solutions when they pair programmed.

So here’s what makes for happy computer threesomes

… And it’s rarely at all related to how ‘good’ at coding you or your pair is.

a) Being laid back, but not so laid back you’re both horizontal.

c) Patience, just lots of patience.

d) An understanding that it’s never about demonstrating knowledge and coding wizardry, but about sharing it. It’s not about one-up-manship, it’s about two-up-against-computer-manship.

But most importantly…

…Communication

Use these following phrases frequently:

“Yeh, why not. Let’s just try it. See what happens”

“Woah, what did you just do?”

“Don’t we need to write the test first?”

“Its kinda like a …” (insert metaphor)

Try to never use these phrases:

Why are we so keen to ‘get the answer’ and not ‘ask the question’?

There’s even more room for misinterpretation when you’re testing a computer.

Coders are Testaholics.

BDD (Behaviour Driven Development)

TDD (Test Driven Development)

Unit testing is the most counterintuitive of all testing.

Why?

But, the biggest headfuckery is writing the test first.

Remember the dark old days before CityMapper and GoogleMaps?

For most of us, there is a certain fear of getting lost. It makes us anxious.

Learning to code is all about navigating uncertainty.

So here’s the tortured metaphor.

This is like learning to Code because…

‘The Knowledge’ is just for Cabbies.

Trusting your sense of direction is vital.

Illogicode’s jingle