One reason I like working at startups is
you get to wear many hats.
by "wear many hats" I really mean
"suffer occasional periods of extreme stress when things fail
and there are no grownups you can go to for help".
I like to think of it as Extreme Learning.
One of my stock interview questions goes:
"When picking between dependencies to use in production,
what factors contribute to your decision?"
I'm surprised by how often
I receive an answer along the lines of
"Github stars" and not much else.
I happen to think Github stars is a terrible metric
for selecting production code,
so this post sets out my idea
of a healthier framework to evaluate dependencies.
As engineers we spend a lot of our time debugging problems,
yet it's rarely taught as a skill in its own right.
Some bugs are difficult enough
that they can seem borderline impossible to solve,
especially for devs toward the junior end of the spectrum.
There's no worse feeling than being stuck
on a hard problem,
not knowing how to proceed.
the right thing to do if you're stuck like that
is ask for help;
from your team,
from other engineers in your org or social circle,
from random strangers on the internet.
As a random stranger on the internet then,
this post is my attempt to help get you unstuck
if you find yourself in that situation.
I've always wanted a dog,
but could never get one
because I lived in rented accomodation.
Happily that changed last year
so as soon as I could,
I bought a puppy.
This is what I learned
about dogs, people and code.
Last week I received the result
of my WSET level 3.
I got a pass with distinction
for both parts of the exam,
and the theory.
So, keeping up the tradition
I started with level 2,
this post summarises my advice
for anyone out there
thinking about level 3.
Automating your release process
eliminates tedious busywork
and reduces the likelihood of mistakes
when cutting a new release.
There are plenty of off-the-shelf solutions available,
but this post will show
how easy it is to build your own release script
and why the end result can be better
than using a generic, third-party option.
Throughout the post
I'll use the case study
of some recent work we did
to automate the release process
to provide concrete examples
of what I'm talking about.
the Firefox Accounts (FxA) codebase
was organised as separate repositories
because it's deployed as separate microservices
that arrangement caused us
some nagging issues
so we decided to migrate the code
to a monorepo instead.
This post discusses
why and how we did that,
and how things turned out
in the end.