Kristian Glass - Do I Smell Burning?

Mostly technical things

Cover Letters: Always Send One

Younger-me believed a bunch of classic “naïve engineer fallacies”, like “marketing is a waste of time, it’s all about technical superiority”. One of them was “Cover letters are a waste of time! They should be able to tell my suitability from my CV alone!” (somehow I still believed this despite having a very short CV).

Younger-me was wrong, very wrong.

Send a cover letter. Please.

The Book of Armaments - Tools for Better Python

This is a long-form version of a talk I was invited to give at PyDiff (the Cardiff Python meetup) last year The audience was an exciting range of people, from professional software engineers, to mathematicians who’d written their first Python a few weeks prior.

Tools for better Python

There are things that will help you write better Python that are not Python-specific, like practice, good posture, documentation and empathy. These will help you be better at almost everything you do.

There are Python-specific things that will help you write better Python. However you may find them less useful in other areas of life…

Python’s ‘Surprise’ Imports

There was some code, it looked a bit like this:

from django.utils import timezone

start_date = timezone.datetime(2015, 1, 1)

Django recommends that you use, for example, to ensure you always get “the right now” (i.e. timezone-aware). So you might, as with the code example above, extrapolate that timezone.datetime(2015, 1, 1) will give you a timezone-aware “1st of January 2015” datetime object.

This is not what happens. You get a naïve datetime object. Why?

Removing Myself From the Equation

Through circumstance and history, there’s a bunch of tasks and procedures for which I’m either the only one on my team who knows how to do them, or at least the local expert who does them most frequently.

For the sake of my team’s autonomy, resilience, and ability to evolve these processes, it’s important that this knowledge and experience isn’t confined to just me.

So here’s what I generally do to change that:

User Stories

“As $role I want $desire so that $benefit

I’m growing to love the idea of user stories. A simple short sentence or two capturing someone’s need, providing context to indicate their motivation, and usually specifying little in the way of implementation details.

Treat Your Servers Like Cattle, Not Like Pets

(Having little experience of pets, and none of anonymous herds of cattle, perhaps “like blood cells, not like limbs” is a better analogy…)

This is a pretty common adage among people working at any kind of scale. I just wish it was more generally accepted.

Reboot your servers often. Destroy and rebuild them often. Poke them, prod them, ensure that your services continue.