DEV Community: Serguey Asael Shinder

Somebody Is Saving Your Traffic to Read It Later

Serguey Asael Shinder — Sat, 26 Sep 2026 09:21:49 +0000

Everything you encrypt today
is protected by maths
that is hard right now.

Right now is the phrase
that matters.

An attacker does not have to break
your traffic this year.

They only have to keep it.

Storage is cheap.
Captured traffic is patient.

And there is a long-running effort,
backed by very large budgets,
to build machines
that would make some of today's
key exchange and signatures
easy to undo.

Nobody can honestly tell you
the year that arrives.

Maybe never.
Maybe well after
you have changed jobs twice.

That uncertainty
is not a reason to relax.

It is the whole calculation.

Ask how long
each thing you protect
needs to stay secret.

A session token matters for an hour.

A medical record matters
for the rest of a life.

A contract, a source tree,
a list of who talked to whom,
the negotiating position
in a deal that closes
three years from now.

If the secret has to last
longer than the maths might,
then it is already exposed
to whoever recorded it,
and nothing you do later
reaches back into their archive.

The replacement algorithms exist.
The first standards
were published in 2024,
and the large browsers and providers
have been quietly mixing them
into ordinary connections since.

The hard part is not the new algorithm.

It is finding every place
the old one is written down.

The library pinned
four major versions back.
The device in a warehouse
that can only speak
what it shipped with.
The certificate format
a partner insists on.
The algorithm name
typed as a string
into a config file
in forty repositories.

That inventory
is dull work,
and it is the actual work.

So start with two lists.

What must still be secret in ten years.

Where your cryptography
is chosen,
by whom,
and how hard it is to change.

Aim for the day
when switching an algorithm
is a configuration change
and a test run,
not a programme of work
with a budget and a steering group.

The code you write this year
will still be running
when this matters.

Build it so that changing the lock
does not mean
rebuilding the door.

– Serguey Asael Shinder

Your On Call Week Is Not a Normal Week With Pages in It

Serguey Asael Shinder — Sat, 26 Sep 2026 09:21:17 +0000

The sprint plan has your name
against the migration.

It is also your week
holding the pager.

Everybody agreed to this
without noticing,
because the pager might be quiet.

It is never quiet in the way
the plan needs.

It does not have to ring much.

It only has to be able to.

Deep work needs a stretch
where you believe
nothing will pull you out.

A pager removes the belief,
whatever it does with the noise.

So you circle the migration.
You open it, load it into your head,
and hold back the last part
of your attention,
in case.

Then one alert,
twenty minutes, a false alarm,
and what you had loaded
has gone.

By Friday two things are true.

The migration moved a little,
and badly.

And the incidents got
half of a person
who resented them,
which is the wrong half
to meet a production problem with.

Nobody chose that week.

It fell out of a plan
that treated on call
as a background task
rather than as the job.

Plan it the other way round.

On call is an interrupt week.

Take the large work off the board
before it starts,
out loud,
in the planning meeting,
so nobody counts on it.

Fill the week
with small, finishable things.
Pieces you can put down
in the middle
and pick up without loss.

Better still,
give the week a theme
that the pager feeds.

The alert that fired for nothing,
tuned or deleted.
The runbook step
that was wrong at three in the morning,
rewritten while it still stings.
The manual fix
you did twice,
turned into a script.

That work is done best
by the person who just felt the pain,
and it makes the next person's week
quieter.

Then hand over properly.

One note on what happened,
what is still open,
what you changed.

Done like that,
the rota stops being a tax
on everyone's real work.

It becomes the week
the team spends
making the system
easier to be woken by.

And the migration
goes to somebody
who can give it
every part of their attention.

– Serguey Asael Shinder

Your Best Day Is Not Your Baseline

Serguey Asael Shinder — Sat, 26 Sep 2026 09:20:45 +0000

There was a Tuesday
two years ago
when everything worked.

You understood the problem
by half past nine.
The design fell out of it.
The tests went green
on the first run.

By the afternoon
you had shipped
what the plan said
would take a week.

You still think about that day.

Worse, you think of it
as your speed.

Every estimate you give
is quietly priced
at Tuesday.

Every ordinary Thursday,
when the build is slow
and the problem is murky
and somebody needs you
for forty minutes,
feels like a decline
from the person you really are.

It is not a decline.

It is the job,
at the rate the job actually runs.

The best day was real.

It was also the top of a range,
reached once,
with a clean week behind it,
a problem shaped
exactly like something you knew,
and nobody asking for anything.

Treating the peak as normal
does two kinds of damage.

Outward, you promise Tuesday
and deliver Thursday,
and people learn
to add their own padding
to what you say,
which is a quieter way
of trusting you less.

Inward, you are always behind
an imaginary colleague,
the one who has that day every day,
and you read an average week
as evidence that something is wrong with you.

So find your middle.

Look at the last ten things you finished.
Not the one you are proud of.
All ten.

How long did they take,
from start to done,
including the waiting
and the interruptions
and the bit you redid?

The number in the middle of that list
is your pace.

Plan from it.
Promise from it.

Keep the best day
where it belongs,
as a rare thing
you are allowed to enjoy,
not a standard
you owe anybody,
least of all yourself.

A middle you can hit
every week
is worth more to a team
than a peak
they have to schedule around
and cannot count on.

And on the murky Thursday
you will know
you are not slipping.

You are exactly on pace.

– Serguey Asael Shinder

You Cannot Hear How Long Your Intro Is Anymore

Serguey Asael Shinder — Sat, 26 Sep 2026 09:20:13 +0000

The song opens with
sixteen bars of guitar
before anyone sings.

To you it feels like
a breath in.

You have heard it
four hundred times.

You know what is coming,
so the waiting is full.
Every bar is leaning
toward a chorus
that already exists in your head.

The listener has none of that.

They have sixteen bars
of a stranger's guitar,
a phone in their pocket,
and a friend beside them
halfway through a sentence.

This is what repetition
does to a writer.

It fills the gaps
with what you already know,
and then it hides
that it is doing it.

The long intro.
The second verse
that says the first verse again.
The solo that is lovely
and about eight bars
past lovely.
The ending that fades
for longer than
anyone would wait for a bus.

You cannot hear any of it,
and your ear is not the problem.

You are the one person
who can never again hear
this song for the first time.

So stop asking your ear
a question it cannot answer.

Watch somebody else's attention.

Play it to a person
who has not heard it,
and do not look at their face
while it starts.
Look at their hands.

Note the exact second
they reach for the phone,
or the drink,
or start talking.

That is the length
your intro actually is.

Do it with three people.
If they drift at the same place,
the song is telling you
where it goes slack.

Time the first line of the vocal
with a stopwatch,
and write the number
next to the title.

Then cut something,
even if it hurts,
and play it to somebody new.

You will not miss the bars you removed.

Neither will they.

They will simply
still be there
when the voice comes in.

Your version is not the long one.

It is the one you can no longer hear.

The shorter one
is the song a stranger
gets to meet.

– Serguey Asael Shinder

The Package the Model Recommended Did Not Exist

Serguey Asael Shinder — Sat, 26 Sep 2026 09:19:41 +0000

You asked for a way to parse
an awkward date format,
and the answer was tidy.

Install this package.
Import this function.
Three lines.

The name was perfect.

It sounded exactly like
the thing you would expect
somebody to have written.

That is the problem.

A model producing a dependency name
is doing what it does
with every other word.

It predicts what a name
in that position
would plausibly be.

Most of the time
the plausible name is real,
because real names are plausible.

Some of the time
it is only plausible.

And a name that a model
suggests to one person
it will suggest to thousands,
because it is the same model
answering the same kind of question.

So the invented name repeats.

Which means somebody
can collect them,
register the popular ones
on a public registry,
and wait.

No break-in.
No stolen password.

Just a package
that did not exist
until the model kept naming it,
with an install script
that runs on your laptop,
with your tokens in the environment,
the moment you type the command
the answer gave you.

Reading the code will not save you.

You were looking at three lines
of sensible code.
The danger was never in them.
It was in the one line
that fetched somebody else's.

So put the check where the risk is.

Before a new name goes in,
look it up yourself.
Not through the assistant.
On the registry.

How old is it.
Who publishes it.
How many people depend on it.
Does it have a repository,
and does that repository
look like somebody's work
or like a costume.

A week old,
one version,
one maintainer,
and a name that sounds
like it has always existed,
is the exact shape
of this trap.

Then make it structural.

Install from a lockfile in the pipeline.
Put new dependencies
through review as their own change,
where the only question
is whether this thing
should be allowed in at all.

The model can suggest.

The registry is where
you find out
what you are about to run.

– Serguey Asael Shinder

Anyone With the Link Means Anyone

Serguey Asael Shinder — Sat, 26 Sep 2026 09:19:09 +0000

Somebody needed a contract
looked at by a lawyer
outside the company.

The lawyer had no account.

So the file got a link,
long, random, impossible to guess,
and the setting said
anyone with the link can view.

It was a sensible choice.

The link could not be guessed.

It did not need to be.

Watch where it went.

Into an email,
which was forwarded
to a colleague of the lawyer,
and then to a client
who did not need
the pricing schedule on page nine.

Into a chat,
where the preview service
fetched it
to draw a tidy card,
from a server you have never heard of.

Into a ticket,
pasted as context,
in a tracker
that forty contractors can search.

Into a browser history
on a shared machine
in a hotel business centre.

And back out again,
eighteen months later,
still working,
because nothing ever told it
to stop.

An unguessable link
is a password
that gets pasted in public
as a matter of routine.

It is a key
with no name attached,
no expiry,
and no record of who turned it.

The door was built properly.

Its key simply travels
through every channel
you use to send links,
which is all of them.

So treat the link as what it is.

A credential.

Give it an expiry by default,
and make forever
something a person has to choose
and has to justify.

Scope it to a single file,
not the folder
that will fill up next month.

Make it revocable
without deleting the document.

Record every open,
so that when somebody asks
who has seen this,
you have an answer
that is not a shrug.

And for anything
you would not read aloud
in a crowded lift,
ask for a sign-in,
even a one-time code by email,
so the link finds a person
instead of anybody.

Then go and look
at what your own account
has shared this way.

Sort it by age.

The oldest link on that list
is still valid,
and you do not know
where it has been.

– Serguey Asael Shinder

Your Function Changed a List It Was Only Lent

Serguey Asael Shinder — Sat, 26 Sep 2026 09:18:37 +0000

The report came out right
on Monday
and in the wrong order on Tuesday.

Nobody had touched the report.

Somebody had touched a helper
three calls away,
a small function
that found the top five customers.

It sorted the list it was handed.

In place.

Because that is what the sort method
in front of them did,
and it was one line shorter
than making a copy.

The helper returned the right five.

Its own tests were green.

And every caller
who had handed it a list
got that list back
rearranged,
with no sign on the call
that anything had happened.

This is the bug
that ruins an afternoon
precisely because it is nowhere.

You read the report code.
It is correct.

You read the helper.
It is correct.

The fault lives
in the space between them,
in an assumption
neither of them wrote down,
which is who owns the list.

It has relatives.

A function that pops the key
it was interested in
off a dictionary it did not create.

A validator that trims the strings
of the object it is validating,
so checking the input
quietly changes the input.

A default argument
that is one shared list
for every call,
growing a little each time.

A config object passed to three services,
and the first one to start up
adjusts a setting for itself.

In each case
a caller lent something
and got back something else.

The rule is easy to say.

A parameter is borrowed.

Read it.
Build your answer from it.
Return the answer as a new thing.

Leave what you were lent
the way it arrived.

When a function truly exists
to change what it was given,
put that in the name,
so the change is visible
at the place where it is called.

Sort in place.
Normalise the order.
Strip the payload.

A verb the caller can see
is a warning they can read.

And where the language lets you,
make the borrowing enforceable.
A read only view.
An immutable collection.
A type that refuses the edit
before a reviewer has to.

Then the question
of who changed the list
has one answer,
and it is in the code
you are already reading.

– Serguey Asael Shinder

You Built This for a Body Like Yours

Serguey Asael Shinder — Fri, 25 Sep 2026 07:17:29 +0000

Every screen you have shipped
was checked by one body.

Yours.

Your eyesight, at the distance
you sit from that monitor.
Your hand on a mouse
that has never once missed.
Your ears, which were not needed.
Your patience, which was endless,
because you already knew
where everything was.

That was never decided.

It is only who was in the room.

Look at what it leaves behind.

A menu that opens on hover,
which means it does not open
for a finger or a keyboard.

An error announced
by turning a border red,
to somebody who cannot see red.

A container with a fixed height,
generous until the text is set
to twice the size,
and now the confirm button
is below the edge of a box
that does not scroll.

A dialog a keyboard can open
and cannot close.

A form that times out
according to how fast
you fill it in.

A price rendered into an image
so the font would be exact,
and now it cannot be enlarged,
selected, translated
or read out loud.

None of that appears in your numbers.

The people who cannot finish
do not write in to explain.

They go,
and the ones who reach support
are the ones
who could still reach support.

Now the direction of travel.

An audience only ever widens,
and it ages every year,
which your interface does not.

Everyone arrives eventually
at larger text,
stronger contrast,
one hand on a train,
sun on the screen,
an afternoon when the small grey label
is simply not there.

And this is skeleton, not paint.

A div with a click handler
has no name, no role, no state,
and no position in the keyboard order.
Ten of those inside a design system
is one defect
stamped onto every page
you will ever ship from it.

Which is why the retrofit
gets priced like a rewrite,
and why the only cheap hour
is an early one.

Take that hour this week.

Unplug the mouse
and do your own main flow.
Then set the text to double
and do it again.

You will find things
that have been sitting there for years.

You are not building
for strangers with a condition.

You are building
for yourself at sixty,
and that person
is not going to file a bug.

– Serguey Asael Shinder

Your Build Time Is Choosing What You Think About

Serguey Asael Shinder — Fri, 25 Sep 2026 07:16:57 +0000

Time the loop you are really in.

Save the file.
Run the thing.
Find out whether you were right.

For a great many people
that round trip is
a little over two minutes.

Too long to sit and watch it.
Far too short to start anything.

So you fill it.

The inbox. The channel.
The review somebody tagged you on.
The thread about next quarter
that does not need you.

Then the run finishes
and you come back
as a slightly different person,
holding a slightly different problem,
and you spend the next half minute
remembering what you were testing
and why.

Do that thirty times in a day
and you have not been interrupted once.

Nobody came to your desk.
You chose every one of those detours.

And the day still went
the way an interrupted day goes,
because the gap was there,
thirty times,
and a gap that length
has no good uses.

This is where the conversation
about discipline goes wrong.

You are not weak for filling it.

You built a rhythm
in which stopping is compulsory,
at an interval your tooling picked,
and then asked yourself
to have the strength
to stand still inside it,
thirty times, every day.

So work on the loop,
not on the willpower.

Find out what the number is.
Not what you assume it is.
Measure it on the machine
you actually use.

Then treat it as a defect,
because it is the most expensive one
you own.
Run the single test, not the suite.
Keep the process alive
between attempts.
Stop rebuilding
what did not change.

And where the wait genuinely
cannot be shortened,
give it one job and only one.

Stand up. Look at something far away.
Write the next line of the note
about what you are trying
and what you expect to see.

Anything that hands you back
the same thought
that you were holding
when you pressed the key.

A good day is not measured
by the hours you sat there.

It is measured by how often
you got to ask a question
and hear the answer
while the question
was still yours.

– Serguey Asael Shinder

Half Your Review Comments Are Autobiography

Serguey Asael Shinder — Fri, 25 Sep 2026 07:16:25 +0000

Read your last twenty review comments
as though a stranger wrote them.

A pattern comes up
that has very little to do
with the code in front of you.

You always ask about the null.
You always ask what happens
when the list comes back empty.
You always want the timeout named.
You block anything that catches
an exception and carries on.

Every one of those is reasonable.

Not one of them
came out of that diff.

They came out of a Thursday
several years ago.

Somebody lost a weekend
to an empty list,
and it was you,
and you have been reviewing
that incident ever since
in other people's branches.

This is how craft actually moves
between people,
and most of the time it works.

The cost lands on the author.

They cannot tell which comment
is a rule the team agreed,
which is a real property
of this system,
and which is your history
wearing the voice of a standard.

So they treat all of it as law,
because you are senior
and arguing is expensive
and they have a Friday to get to.

Now your scars are the house style,
having never once been discussed,
and whoever comes after you
inherits them
with no idea where they came from
or whether they still apply
to anything.

There is a tell.

You are certain, you are brief,
and you cannot name the evidence
that would move you.

Certainty that cannot cite
its own source
is a memory with authority
attached to it.

The remedy is one clause long.

Say where it came from.

This is a rule we agreed in March.

This service has been bitten here twice,
and here is the incident.

Or, plainly,
I lost a weekend to this once
and I have been nervous about it since,
so push back if I am wrong.

That last sentence costs nothing,
and it turns the exchange
from obedience
into two people thinking.

Your experience is the most
useful thing you have to hand over.

Label it,
so the next person can weigh it
instead of simply obeying it.

– Serguey Asael Shinder

You Wrote a Part for a Band You Do Not Have

Serguey Asael Shinder — Fri, 25 Sep 2026 07:15:53 +0000

The recording is finished
and it is the best thing
you have ever made.

Two guitars in the verse.
Four in the chorus,
because nothing stopped you.

A harmony stack
sung one voice at a time
by a person with one voice.

A keyboard pad underneath
all of it,
so quiet that nobody notices it
until the moment it is gone.

Then somebody books you a gig.

There are four of you.
Eight hands.
One of you sings.

And the song does not exist
in a form that four people
can play in a room.

What happens next is familiar.

You put the pad on a laptop,
and now the band has a member
who cannot listen,
cannot slow down,
cannot find its way back in
after the drummer drops a stick.

Or you give the pad
to the guitarist,
who then cannot play the line
that was the reason
the song exists.

Or you play it stripped,
and it is thin,
and the room is comparing it
with the version
you taught them to expect.

None of that is the recording's fault.

The recording was an arrangement
for a band that does not exist,
written by one person
who could add one more part,
at a time,
alone,
for as long as the night held.

A room does not work like that.

In a room everything happens at once,
by people, with hands,
who have to hear each other
to stay together.

So ask the question early.

Who plays this.

Not in principle. By name.

And if the honest answer
is that the studio plays it,
then you have two songs
and it is better to know.

One of them is for speakers.
One of them is for the four of you.
They are allowed to differ,
and the differences
are where arrangements
actually get made.

The version you can perform
is the real one.

Everything else is a very good record
of something you cannot do yet.

– Serguey Asael Shinder

The Model Cannot Miss What It Never Received

Serguey Asael Shinder — Fri, 25 Sep 2026 07:15:20 +0000

You pasted the file
and asked why the totals are wrong.

The answer came back confident
and slightly beside the point.

You went round three times,
sharpened the question,
got better prose
and the same wrongness.

The file was two thousand lines.

About nine hundred of them arrived.

Nothing told you that.

This is the quiet failure
in every tool that reads on your behalf.

A retriever returns three passages
because three was the number
in a config file
somebody set in June.

A file reader stops at a line limit
that was chosen with logs in mind.

A window drops the oldest turns
to make room for the newest,
including the one
where you stated the constraint
that the whole question rests on.

An indexer skips anything
over a size,
and the large file
is the interesting file.

None of them raise an error.
They all report success.

And the model does
the only thing it can,
which is answer from what it holds,
with no way of knowing
that the part that mattered
fell off the back.

To it, an absence
is indistinguishable
from a thing that is not there.

So you are not arguing
with a bad answer.

You are arguing about
a different program
from the one you meant to show it.

Verify the input like input.

Ask it to quote the last line
of what it received,
and compare that with the file.

Ask what the final function
is called.

Count the characters you sent,
if that is the only number
you can get hold of,
and check it against the source.

When a tool fetches for you,
read what it fetched,
not the conclusion
built on top of it.

And prefer the smaller ask.
One function, entire,
beats a whole service
trimmed by a rule
you have never read.

The habit is older
than any of this technology.

Before you debate the output,
prove the input arrived.

Otherwise you will spend
an afternoon doubting
your own reasoning,
and the machine will turn out
to have been perfectly correct
about a program
that does not exist.

– Serguey Asael Shinder