Recently I built a system
that uses vector search to logically truncate long documents
and retain the most significant parts
according to some search term.
I'm a dummy,
with no background in machine learning or mathematics,
so there were new concepts for me to understand
and implementation details to figure out.
This post summarises what I learned.
For the last ten months or so
I've worked on integrating GPT
with a large production codebase.
It's been one of the most chaotic periods of my career,
featuring numerous false starts,
changes of direction and
rapid improvements followed by major setbacks.
This is what I've learned.
Production outages are great
at teaching you how not to cause production outages.
I've caused plenty and hope that by sharing them publicly,
it might help some people bypass part one
of the production outage learning syllabus.
Previously I discussed ways I've broken prod
and with healthchecks.
Now I'll show you how I've done it with Redis too.
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.