Python 3.6 brings smarter text formatting

Python 3.6 is out!

New major release of Python today brings a few handy upgrades.

I particularly fancy the F string formatting. I’ve always liked how simple formatting of strings is in Python but it got even easier. I’ll let you RTFM if interested but essentially you stick an ‘f’ in front of a string literal to perform a more succinct version of .format(). Pretty cool.

Good review of AI research and where it might lead

If you’re interested in getting an overview of AI research and possible future trends check out Building Machines That Learn And Think Like People and the previous post on the same blog Artificial Intelligence And Life In 2030.

In fact even if you’re not fussed on AI the whole blog is great if you’re into general CS research. The author, Adrian, takes a new research paper every weekday morning and reviews it.

Find Yourself In Vim

Find Yourself In Vim

Moving on

So, if you’ve used Vim a bit then “hjkl” is hopefully second nature. Moving by objects (w/W/e/etc.) makes things easier but it still lacks finesse. One of the best tools for moving in Vim is f and its variations. When we use f we’re doing a find for a single character on the current line. This allows us to jump straight to (or very close to) the point we next need to be at without using the mouse.


As always, the best way to learn is to see it. In the below sentence, my cursor is on the first character on the line in normal mode (I):
It was the best of times, it was the worst of times.
Now if I wanted to jump to the word best, I could press w a few times. However, fb will find the b with way less effort. As usual, it’s mnemonic so it doesn’t require extra thought to think of the command. It just works:
It was the best of times, it was the worst of times.

F, t, T, “,” and “;”

To make finding extra powerful, here are a few bonus commands:
F – searches backwards on a line.
t – same as lower case f except it stops a character early.
T – same as T except backwards on a line.
, – find next occurrence of character (can repeat until there’s no more).
; – same as “,” except backwards on a line.

Scrabble grandmaster

Ever played Scrabble? If you have then this last tip will make your life a whole lot easier. Luckily, it’s still easy to remember if you haven’t played. Try the above commands in a vim session for a few minutes. Very quickly, you’ll see that it can sometimes be a bit tricky to nail the exact character you’re after and you might find yourself resorting to “hjkl” to get there. One way to solve this is to try to mentally note which “high value” letters are near the place you’re trying to jump to. In Scrabble these letters are the ones with higher points but in English we just mean the letters we see less often (z, x, b, y, etc.). Let me show you an example to get my point across:

Insanity: doing the same thing over and over again and axpecting different results.

Oops! I’ve made a typo. Instead of expecting I’ve written axpecting! What a numpty. My first instinct might be to use f to jump to a right? Notice that high value x right beside it though? Instead of doing 5 or 6 jumps, I can just do one. fx followed by i and backspace once to correct my mistake.

Insanity: doing the same thing over and over again and expecting different results.

Keep an eye out for those high value letters. Don’t forget that capital letters and punctuation can be found too and might be higher value.

Bokeh Visualisation Using Pokemon Go Data – Part 2!

Bokeh Visualisation Using Pokemon Go Data – Part 2!

Python and Bokeh

Introducing Part 2 of my “let’s mess about with Python and Bokeh” series.


So last time, I created a simple bar chart showing the top Pokemon by Combat Power (CP). I used this Pokemon Go dataset from Kaggle. I want to keep it fairly simple again, but still learn something and show the data in a different way. I thought a scatter graph might be a good shout.

The Data

Scatter graphs show trends in two numbers right? We already have CP from last time so that’ll do for the Y axis again. For the X axis, I think it might be worthwhile using Hit/Health Points (HP). I would imagine there’ll be a positive correlation between the two but it’d be cool to confirm and any outliers might be interesting to note.

Looking at the dataset again, it seems like there are a few other variables we should include:

  • Pokemon Name – scatter points are kind of useless unless you know what they refer to.
  • Type 1 – this is the Pokemon’s main type. I figure we might get some trends out of it.

The Code


Just using pandas and bokeh again:

from bokeh.charts import Scatter, output_file, show
import pandas as pd


We’ve use dataframe’s read_csv() method again to grab the data and specify our columns (including our new ones). Notice I’ve also used the rename() function to get rid of spaces in some of the columns names. This is because the tooltips parameter in the graph builder needs it. NOTE: you’ll need to latest Bokeh to get the tooltips in the builder to even work. Older versions vomit. If we were to use the lower level Bokeh components this wouldn’t be an issue because we wouldn’t be using chart builders.

data = pd.read_csv('pokemonGo.csv', header=0, usecols=['Name', 'Max CP', 'Max HP', 'Type 1'])
data = data.rename(columns={'Name': 'name', 'Type 1': 'type1'})
scatter = Scatter(data, x='Max HP', y='Max CP', color='type1', marker='type1', tooltips=['name', 'type1'])


What did we find out? Well the graph confirms a positive correlation between HP and CP:

Luckily the code all worked too. We’ve got a key showing the primary types and if we hover on a point we can see the name and type appearing as they should. Great! Using the scatter has definitely added a bit more value to the previous post. We can see that normal Pokemon lead the field when it comes to HP.

We can also see that bug Pokemon don’t have great stats:
But anyone who has played Pokemon knows that doesn’t tell the whole story. Maybe I’ve got an excuse to create more parts to this series!

Deaf in the software industry

Deaf in the software industry

Deaf insights

Not a technical post, but hopefully still an interesting one. I want to take you through a quick tour of some things I’ve experienced (good and bad) as a software engineer, specifically from the perspective of someone who has drastically lost their ability to hear over the last few years. NOTE: I’ll use the audiological term deaf in this post but it’s worth noting that there are differences between deaf, Deaf and Hard Of Hearing.

My hearing

A lot of this post is going to apply to others but some bits might be more significant, depending on the person’s hearing levels. For reference, my hearing (or lack of!) consists of high frequency deafness, which I’ve had as long as I can remember, as well as severe loss in the other frequencies caused by Ménière’s disease. I lost around 90% of hearing in my right ear about 5 years ago and had a similar loss in my left over the past year. Since then I’ve managed to gain a fraction back in both ears but I still require hearing aids on both sides, with supplemental lip reading, to maintain a conversation.


Anyone familiar with “Agile” development will be aware of standups, where everyone in a team gathers to quickly chat about what they’re working on and any obstacles they might be facing. Open communication is key in the Agile world. Unfortunately when you’re deaf, hearing 5-10 other people in a meeting room, which might have funny acoustics and/or AC on, can be tricky. I’m lucky that I have an understanding team who will take care to make me aware of what they’re talking about but sometimes even that isn’t enough.

For any deaf SEs out there, I recommend firstly making your team very aware of what level your hearing is at. Secondly, just like with normal group conversations, make sure to find a position in the room that facilitates hearing what you need to hear – this might require standing where you can see the most faces or perhaps beside the quieter speakers. If I’m having a particularly low hearing day and I can’t hear someone who’s talking to me directly then I’ll just walk over to them and ask them to repeat what they said.

For the hearing SEs reading this, if there is someone in your team who is deaf, be sure to make yourself seen as well as heard. Speak clearly and loudly. Move closer to your other team members if necessary.

Call me maybe

Standups aren’t the only meetings we have to deal with. Like it or not, they’re a fact of software life. If the company you work for is global, then you’ll also have the dreaded conference calls. Luckily, compared to a lot of industries, we have tools that make it way easier for deaf people to participate. GoToMeeting software or other video conferencing means there can be a visual element to calls. Slack or similar chat programs are ubiquitous in most development shops. For me, I couldn’t live without both of these. I occasionally have to attend calls that are audio only but they really zap my energy because I have to spend a lot of effort just trying to extract the meaning out of what’s being said. With a video conference, where there are slides, or a demo, I don’t have to focus quite as hard on the audio as the visual cues will help cover what I miss. Chat software like Slack solves the problem in a slightly different way – it allows me to gather some pre meeting info from one or more participants, so again I can expend energy more efficiently during the meeting itself.

Quick side note here for any recruiters out there. Try to be conscious of candidates that prefer written or face to face communication over phone calls. I love my job and don’t foresee any change of job in the near future but if I were invited for a phone screen or told that I could only find information on a job via phone, both of which were fairly common when I was on the job hunt, then I’d potentially be put off because I know I might miss out on important information.

Syntactic sugar

The company I work for has a great cutting edge tech stack and is always willing to use a new tool if it will solve a problem better than the existing offerings. This is awesome! I can learn new stuff and it helps me do my job better. However, being deaf, new terms or methods can cause a bit of a headache. If I’m chatting to my coworkers and someone suggests some cool AWS gizmo to store our data more robustly, I’ll make a mental note to do a quick review of any domain specific terms once the conversation is finished. This helps me as an engineer because I can do some investigating into whether I think it’s a worthwhile move but it helps me more as a deaf person. How? Next time that tech, or the terms that surround it, come up in conversation I won’t have to do as much mental gymnastics to decipher what’s being said and I can just concentrate on the content of the conversation.

Deaf not dumb

Related to the last point, I’ll often make people “explain like I’m 5” when I want to be absolutely clear of the point they’re making. I’m pretty methodical at times so my colleagues need to be quite patient but in the end everyone benefits. I’ve been developing long enough to know that one of the most lethal blows to a software project comes in the form of assumptions. In my opinion, clarity is paramount.

Music to my ears

Being deaf definitely isn’t bad; it has some surprising upsides. One great thing is that I don’t need to stick headphones on to get in the zone. The hustle and bustle of a normal workplace can easily be ignored when it barely registers above silence. You could argue that this means I might look more approachable and therefore might get more interruptions but I find I’m more productive if I take occasional breaks from my screen anyway.

1 on 1

Sometimes the trickiest encounters are the simplest for most people. Ever pair program? It’s a great process for working through a non trivial task. Unfortunately, it can be a bit more work when deaf. If someone else is driving then they’re probably going to be looking at the screen, meaning their voice isn’t carrying towards me and I can’t see their mouth properly to get a bit of lip reading in. If I’m driving then I’m probably looking at the screen, meaning I have to keep turning back and forth to hear what my co-pilot is saying. I still encourage it in my team and try to pair program when it suits because I feel overall the pros outweigh the cons.

Programmers have this reputation of being socially awkward. I’ve found the opposite to be true in the majority of cases, though maybe I’ve been lucky. With that said, I do find a lot of people in the industry quite soft spoken. If you’re one of those people, please make an extra effort when speaking to someone like me in future. Also, try to recognise when someone has an issue communicating, in whatever way. Everyone in my work knows I’m the deaf guy, so they’ll really go the extra mile to communicate, but occasionally someone from a different office will travel over and there can be an initial fumbling through a few conversations until it sinks in that I’m not kidding when I say I’m deaf.


I’m convinced that lack of hearing is not a disadvantage but it obviously does provide unique challenges in life. Hopefully this post has shed a little light on the subject. Reading this back I’m wary of painting a negative picture. This industry is really great for deaf people, especially if you’re surrounded by the right people in a supportive company.

Things Vim is fecking great at #912983772: Joining text


I love Vim. Have I said that before? I want to share another command that I use every single day. It’s extremely simple and, as is often the case with simple tools, very powerful.

J for Joins.

What it does

Simply, if I have two or more lines of text I can use J to join them together on one line. Let’s take some example text (note cursor is on the H):

Here is some
example text, spread over a
few lines.

I can join this in a few ways:
1. Execute 3J (Join 3 lines)
2. My preferred way, especially if dealing with a lot of lines, is to visually select the text first and then executing V2jJ (Visually select this line [V], go down 2 lines [2j] and Join [J]). V}J would also work a treat in this case and is essentially one less key press.
3. Do one of the above with gJ e.g. 3gJ. This actually changes the command to remove spaces which is useful occasionally. The example text would end up looking like this: Here is someexample text, spread over afew lines. That probably isn’t what you want in this case but I’m sure it’s obvious how automatically removing spaces might be useful.

Why it’s good

Like all great Vim commands, it’s mnemonic so you’ll not need to look it up once you’ve used it once or twice. Its real strength is apparent when refactoring. Combined with a good IDE (IntelliJ + IdeaVIM) and the other staple Vim commands, you’ll find that manipulating text becomes a pleasure rather than a chore.