DEV Community: Asael Shinder

Somebody Will Ask You to Prove It

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

For most of the time this industry has existed, working was the standard. If the thing ran and the customers were served, nobody came asking how you knew it was right.

That is changing, and not because of one law. Customers now send questionnaires before they sign. Insurers ask what controls you have before they price the policy. Buyers in regulated industries ask who approved a change and want to see it. And the rules arriving around data and automated decisions all converge on one question: not does it work, but can you show how you know.

So expect the job to grow a second half. Not more code. Records. Where this data came from and what you are allowed to do with it. Who approved the change and on what basis. What the test actually proved rather than that it passed. What the system was told before it produced that answer.

The expensive version of this is reconstruction. Somebody asks in October about a decision made in March, and three people spend two weeks reading chat history and guessing, to a deadline set by a customer. The cheap version is a handful of habits.

Write the why down where it will be found, not only the what. Put the decision in the record rather than in a thread that will scroll away. When you cannot say where a number came from, treat that as a defect rather than a curiosity, because that is precisely the question you will be asked. And get comfortable saying you will find out and come back by Thursday, since a confident guess is a liability once your words are being written down by somebody else.

Here is the part I want you to take as career advice rather than compliance advice. Very few engineers can sit in front of a customer, an auditor or a regulator and walk calmly through how a system reaches a decision, in plain language, without becoming defensive. It is a rare combination of knowing the system and being unbothered by being questioned. The people who can do it get taken into every conversation that matters, and they tend to find out what the company is really worried about long before anybody else.

Monday: pick one thing you own and see whether you could answer, from records alone, how it decides what it decides.

– Asael Shinder

You Have Been Asked to Write About a Colleague

Asael Shinder — Fri, 25 Sep 2026 06:55:18 +0000

The form arrives in your inbox with four boxes and a deadline. Strengths. Areas for development. Anything else.

Whatever you type there is not a conversation. It leaves your hands, gets read by their manager, gets quoted in a room where eight people are comparing names, and outlives both of your jobs. That is worth about twenty focused minutes rather than the four most people give it.

There is one rule to settle before anything else. Do not put a criticism in writing that you have never said to their face. If you have been sitting on something since June, the form is the wrong place for its debut, and a person finding out about a concern from a review is a small betrayal they will remember for years. Go and say it this week, then write the version you already said.

Then stop writing adjectives. Great communicator, real team player, very reliable. All of it gets nodded at and discarded, because none of it can be repeated by somebody who was not there. Write the thing that happened, with a date and a consequence. She took the vendor migration in March, gave a cutover date in week one and held it, and two other teams planned their quarter around that date. That is a sentence a manager can carry into a calibration meeting and use, which is the only real test of anything you write on that form.

Add the part almost everyone leaves out, which is what you want for them next. The people reading it are allocating work and headcount, not just scoring a year. One line saying he is ready to own a service and I would put him on the payments piece does more for somebody than three paragraphs of praise.

On the development box, one thing, concrete, framed as what would make them more effective. Not a claim about their character. And nothing about the team, the process or your own frustrations, which have their own venues.

Take it seriously because this is one of the few moments when you can move somebody's year from outside their reporting line. A bland form is not neutral. It reads as a quiet vote against them.

Monday: for every adjective you were about to use about a colleague, write the dated example underneath it instead.

– Asael Shinder

Nobody Has Said Anything and You Assume the Worst

Asael Shinder — Fri, 25 Sep 2026 06:50:07 +0000

Your last four weeks have been fine. Nothing broke, the work went out, your manager has said almost nothing to you beyond logistics. And somewhere in that quiet a thought sets up: something is wrong, they have gone off me, this is what it looks like before a conversation.

Consider how comment actually gets distributed at work. People remark on the exception. Something failed, or something was unusually good, or a customer said your name. Ordinary competence produces no event, so it produces no sentence. The default state of a busy manager is silence, and that silence covers most of the good weeks of your career.

The trouble is that a mind with no information does not sit still. It writes something, and it never writes the flattering version. Then you start reading evidence into things that carry none. A short reply. Not being asked into a meeting you would not have contributed to. Somebody else getting the interesting ticket, which was probably about who had capacity on Tuesday.

You can end this cheaply, and not by scanning harder for accidental signals. Go and get one deliberate one.

Ask a question narrow enough to be answerable. How am I doing produces fine, yeah, good, because it is too large to answer in a corridor. Is there anything about my work at the moment that you would want different works much better, and so does if you had to pick one thing for me to improve this quarter, what would it be. You will usually get something small, specific and unalarming, and occasionally something genuinely useful that would have taken another eight months to surface.

Then believe the answer and stop auditing for a quarter. Checking every fortnight does not make you better informed, it makes you exhausting.

In the meantime, keep your own record, because you are allowed to have an opinion about your own work. What went out. What got easier because you were there. Who asked for you by name.

And notice the asymmetry you are running on. You read their silence as a verdict. They read yours as nothing at all, which is almost certainly how they intended theirs.

Monday: ask one narrow question about your own work, and then leave it alone until the new year.

– Asael Shinder

You Know Something You Are Not Allowed to Say

Asael Shinder — Fri, 25 Sep 2026 06:44:56 +0000

The further in you get, the earlier you hear things. The reorganisation that is three weeks from being announced. The colleague who has already resigned. The project that will be stopped after the quarter. And then somebody on your team, who has noticed exactly as much as you would have noticed, asks you directly.

Two answers come to mind quickly and both are worse than they look.

The first is the flat denial. No idea, nothing I know of. It buys you an easy afternoon and costs you something you cannot rebuild. Two weeks later the announcement lands, they replay your sentence, and every reassurance you have ever given them gets quietly repriced. People do not forget being lied to about something that then happened.

The second is the hint. The look, the it depends, the careful pause. You have transferred all of the anxiety and none of the information, and now they are guessing at midnight with nothing they can act on. That is not discretion, it is the cost of discretion with none of the benefit.

There is a third answer and it is unglamorous. Say there is something you cannot discuss yet, say it plainly, and then say what you can. I am not able to talk about that at the moment. What I can tell you is that if anything changes that affects you, you will hear it from me as soon as I am allowed to say it. Then keep that promise, because the promise is the entire value of the sentence.

Decide the words before you need them. This question always arrives unexpectedly, in a corridor, and improvising is how people end up denying things.

And do the upward half, which almost nobody does. Go back to whoever told you and ask exactly what you may say, to whom, and when it becomes public. Most confidentiality is vaguer than it needs to be, and people who ask usually get a workable boundary instead of an imagined one.

Your usefulness to the people above you depends on being watertight. Your usefulness to the people beside you depends on their never having caught you saying something untrue. Both are available at once, and that narrow path is most of what being trusted at work means.

– Asael Shinder

Pick One Teacher and Stay a Year

Asael Shinder — Fri, 25 Sep 2026 06:39:45 +0000

Most of what reaches you arrives as fragments. A thread with five rules in it. A talk you half watched. A post arguing the opposite of yesterday's post. You consume a great deal and end up with a pile of conclusions and no way of deciding between them, which is why a year of heavy reading can leave you no better at judgement than you started.

Try something slower. Choose one practitioner whose work is close to the problems you actually have, and stay with them for a year.

Not as a fan. As a student. Read or watch everything they have produced, in the order they made it, including the old material that is out of date. The out of date parts are the most useful, because you get to watch an idea form, get tested, and get revised, and that is the thing you cannot get from a summary. What you are after is not their conclusions. It is how they decide, which questions they ask first, what they check before they commit, what they are willing to leave unsolved.

Choose carefully. The one thing worth filtering on is whether they show their reasoning and whether they have ever changed their mind in public. Somebody who only publishes verdicts will teach you nothing you can reuse. Audience size is close to irrelevant.

Then use them properly. Build one thing they describe, properly, and notice where your version comes apart. Keep a short page of notes about their method rather than their opinions. And by the end of the year you should be able to say where you think they are wrong, with a reason. That is the sign it worked, because you were never trying to acquire a hero. You were trying to borrow a way of thinking until it became yours.

Two or three teachers like this across a career is plenty. It is also, I think, the most efficient learning available to anybody who has a full time job and a finite evening.

Tips accumulate and then expire. A method keeps working on the problems nobody has written about yet.

– Asael Shinder

Management Is a Different Job, Not the Next Level

Asael Shinder — Fri, 25 Sep 2026 06:34:33 +0000

The org chart draws it above you, so it reads as the next step. It is not a step. It is a change of profession that happens to come with a pay rise, and the reason so many people are unhappy a year in is that nobody described the job to them before they accepted it.

Look at what changes. Your output stops being anything you make. It becomes what other people manage to do, which means your good days are no longer visible to you. Your feedback loop stretches from an afternoon to a quarter, sometimes a year, and you will spend long stretches unable to tell whether you are any good. The skills you are proudest of become an occasional hobby. And the difficult part of the week is no longer a problem with a right answer. It is two competent people who cannot work together, or telling somebody their work is not at the level, or carrying a decision you disagreed with and cannot explain the whole of.

Some people find that far more interesting than any system. That is a real preference, not a compromise, and if it is yours you should go and do it.

The way to find out is to look at the day rather than the title. Ask three managers you respect what their Tuesday actually consisted of, and what part of the old job they miss. Then take a trial that can be handed back: lead one project end to end, run the team while somebody is on leave, own the graduate intake this year. Six weeks of the real thing tells you more than a year of wondering.

Two facts worth having before you decide. Find out whether your company has a senior technical track that genuinely pays and genuinely has people on it, because if it does not, the choice is being made by the company rather than by you, and that is useful to know. And know that going back is possible, common, and costs you roughly a year of feeling behind.

Choose by which kind of problem you want to be sitting with at six o'clock on a bad Thursday. That is the actual question, and it has no wrong answer.

– Asael Shinder

Promise the Hour, Not the Relationship

Asael Shinder — Fri, 25 Sep 2026 06:29:23 +0000

Somebody asks whether you would mentor them. You say yes, because you remember being them and because no feels like a small cruelty for no reason. Three weeks later you are in a release, one of your team is off sick, and their message has been sitting unanswered for four days.

You meant it when you said yes. The problem is what you actually promised.

An open ended promise has no unit in it. Nothing tells you whether you are meeting it, so it never reaches the top of any list, and it quietly loses to every deadline in your week. Worse, the person on the other end has no way to read the gap. They do not think you are busy. They think they asked too much, or they were not interesting enough, and they will not ask you or anybody else for a long time. Newer people take delays personally, always, and a mentoring silence is the most personal one available.

So make the thing you promise small and shaped. Not I will mentor you. One hour, on a named day, on one subject. An hour on Thursday to look at how you are approaching the migration. That is a promise you can still keep in a bad week, which is the only test that matters.

Then renew rather than extend. At the end of the hour, decide whether to book another, and say plainly that you work this way because you would rather keep a small promise than break a large one. Nobody has ever been offended by that sentence.

Cap the number too. Two or three people at a time is most people's honest ceiling once you count your actual job. If somebody asks when you are full, say so and be useful in one move instead of vague in two: name a better person, or offer a single session with no strings.

None of this makes you less generous. What people remember is not the total hours you gave them. It is that you turned up on the day you said you would, which is the whole of what feeling supported is made from.

Monday: take the vaguest mentoring promise you currently have open and turn it into a date and a subject.

– Asael Shinder

The Spreadsheet Became a System While You Were Not Looking

Asael Shinder — Thu, 24 Sep 2026 07:05:24 +0000

Somewhere in your company there is a spreadsheet with macros in it that reconciles something important. One person maintains it. Two departments depend on it. It has never been reviewed, backed up or tested, and if that person leaves, several weeks of somebody's life go with them.

You already knew about that one. What is changing is how many of them there are, and how much they can do. The automation somebody in operations built in a workflow tool. The form that writes straight into a database. The assistant answering customer questions that marketing set up in an afternoon. They were built by people who do not call themselves engineers and never will, and the tools have quietly become good enough that the distance between wanting something and having a working version has collapsed.

That is not going to reverse, so it is worth deciding now how you want to meet it.

Start by not sneering, because the instinct to is strong and it costs you everything useful here. That spreadsheet is the most accurate requirements document in the building. Somebody built exactly what they needed with the only tools they were given, and every workaround in it is a precise description of something your systems failed to provide.

Expect to be called in. More of what you are asked to fix will be software you did not write and cannot read in the normal way. The first questions are not about the bug. Who built this, what feeds it, and what is now depending on the output.

And understand where the real engineering work moves, because this is the part that will matter for your career. It becomes building safe roads. A sanctioned way to get at the data. Somewhere to run things that survives a laptop being replaced. A review that takes a day rather than a quarter. People route around a no, every time. They will happily use a yes that comes with rails on it.

The person who can map that layer, and who the people who built it are willing to talk to, ends up knowing what the company actually runs on. There will not be many of them.

Monday: find the spreadsheet everybody depends on and ask its owner to walk you through it.

– Asael Shinder

The Retro Where Everyone Says It Was Fine

Asael Shinder — Thu, 24 Sep 2026 07:00:12 +0000

Half an hour, seven people, and a general agreement that the last few weeks went reasonably well, the release was a bit rushed, and communication could always be better. The meeting finishes nine minutes early, everybody is faintly relieved, and nothing that happens next month is different.

It is easy to read that room as apathy. It is almost never apathy.

People stay quiet because the last three honest items produced no change, so speaking up has been priced accurately as a waste of thirty seconds. Or because the real item is about a specific person and nobody wants to open that in a group. Or because the person running the meeting is the person the truth is about, and everyone in the room can see it except them.

You can improve this without any authority at all.

Go first, and go small and factual. Not the release was rushed, which is an adjective and invites everyone to agree comfortably. We got the final scope on Thursday afternoon and shipped Friday morning, and that is the third time this quarter. A dated, countable thing cannot be nodded past, and it gives the next person a template.

Volunteer your own mistake before anybody else's. It lowers the price of honesty in the room by a surprising amount, and it takes the meeting out of the register where people are protecting themselves.

If you run the session, put the question on the process and not on the people. Ask what made the work slow rather than who was late. And close with exactly one change, with a name and a date attached to it. One change that visibly happens is worth more than eight good observations, because it is the only evidence the room has that this is not theatre.

Then do the quiet part. The things nobody will say in the meeting get said to you on the way back to your desk. Collect them, ask permission, and bring the pattern back to the group without the names on it.

Monday: take one concrete, dated observation into your next retro and say it in the first two minutes.

– Asael Shinder

Somebody Changed Your Code After You Left It

Asael Shinder — Thu, 24 Sep 2026 06:55:02 +0000

You come back from a week away, or you open a file you have not touched since spring, and the thing you wrote is not there any more. Same behaviour, different shape. Your structure gone, your names gone, someone else's approach sitting in its place. Nobody mentioned it.

The first feeling is a small cold one, and it has a sentence attached to it: so that was not good enough.

Before you accept that sentence, look at what usually causes this. Code is a shared surface that gets pushed around by whatever requirement arrives next, and the person who changed yours almost certainly had something you did not have. A constraint that appeared after you wrote it. A production incident at two in the morning that made a clever bit of it unaffordable. A standard the team adopted last month. A second caller that your version was never designed for.

There is also a plainer explanation that surprises people. A fair number of engineers rewrite things in order to understand them. It is how they read. It carries no verdict at all, and they would be genuinely startled to learn you had spent a day thinking about it.

The useful move is to go and get the information instead of sitting with the feeling. Ask about the change, specifically and without any temperature in it. I saw the import got restructured, what did you run into? That question costs you nothing, it is not a challenge, and it is close to the cheapest senior level lesson available, because you get handed a constraint you have not met yet.

Whatever comes back is worth something. A real problem you missed is the best possible outcome, since you now know it. A team standard nobody told you about is a gap in how people are onboarded, and you can fix that for the next person. Personal taste is information about your colleague, not about your ability.

The only version worth objecting to is silent replacement with no reason available when you ask. You are allowed to ask once, plainly.

And notice the other thing this means. Code nobody uses is never rewritten. Yours was in the way of real work.

– Asael Shinder

Write It So It Still Works After Somebody Forwards It

Asael Shinder — Thu, 24 Sep 2026 06:49:51 +0000

You post a clear update in your team channel. Everyone who reads it understands it, because they were all there for the last three weeks. Two days later your manager copies your paragraph into an email to somebody two levels up, and now your words are in a room you are not in, being read by a person who does not know what the Tuesday job is or who Marcus is.

Almost everything you write that matters gets relayed at some point. The message is not finished when your team understands it. It is finished when it survives being pasted somewhere else with no thread above it.

That gives you a simple test to apply before you hit send. If a stranger read only this paragraph, would they know what happened, what it affects, and what is being asked for?

A few things make the difference. Name things in full the first time. The nightly customer import, not the Tuesday job. Say what it means in the reader's terms rather than the system's. Customers cannot download their invoices is a sentence anybody can act on. The exporter is throwing is not, unless you already know what the exporter is for.

Keep the whole point inside one paragraph, because one paragraph is the unit that gets forwarded. The context two messages up will not travel with it. Avoid pronouns that reach backwards into the thread, since this and that lose their referents the moment the message moves.

Put the date and the ask together. A relayed update without a date invites somebody to act on a situation that resolved itself last week.

And never let a decision live only in a screenshot or a reply chain, because neither can be searched or quoted by the person trying to help you.

There is a second reason to do all this, which is that you are making it easy for somebody to advocate for you. Your manager forwarding a clean paragraph is your work arriving upstairs in your own words instead of their summary of it.

Monday: take the last update you wrote and rewrite it as if the reader joined the company this morning.

– Asael Shinder

The Tests Tell You What Somebody Was Afraid Of

Asael Shinder — Thu, 24 Sep 2026 06:44:40 +0000

You have joined a team with a large codebase and everybody has told you to go and read the code. So you open the main folder, scroll, and close it again slightly more discouraged than before.

Try the test directory instead. It is a better door, and hardly anybody uses it.

A test suite is not a quality artefact. It is a record of what has hurt this team. Every awkward test with the long name and the three pieces of setup is there because something went wrong badly enough that somebody spent an afternoon making sure it could not happen twice. Read in that spirit, the suite becomes a history of the product, written by the people who paid for it.

Start with the names and read nothing else. Test names are a specification in plain sentences, written by somebody who understood the domain, and an hour of reading them will teach you the vocabulary of the business faster than any document. You will also learn what the system is supposed to refuse to do, which is the half of the behaviour that never makes it into an overview.

Then look at the fixtures, the little fake records the tests are built on. Those are somebody's idea of what a real customer, order or payment looks like, and they carry the detail a schema never shows you. Look at what gets faked out, too. Every mock marks a boundary of your system, so the mocks together are a map of who your team talks to and what they assume those people will do.

The gaps are just as informative. The area with almost no tests is either very stable or very awkward, and either answer is worth knowing before you touch it. The tests marked skipped or flaky are arguments the team never finished.

Do not trust all of it. Some tests check the implementation rather than the behaviour and will teach you the shape of the code and nothing about the purpose.

Monday: open the test folder of the thing you are working on, read only the test names for twenty minutes, and write down every term you could not have defined beforehand.

– Asael Shinder