DEV Community: Asael Shinder

Your Team Wants Peer Feedback and You Have Been Asked to Set It Up

Asael Shinder — Fri, 16 Oct 2026 18:35:01 +0000

At the retro someone said it out loud. We never tell each other what is working or what is not, we just wait for reviews. Everyone agreed, and your lead turned to you. Could you set something up?

It is a good job to be given, and a surprisingly easy one to get wrong. Most peer feedback schemes fail in one of two ways. They become a form nobody fills in, or they become a quiet way of collecting complaints for performance reviews. Your design should avoid both.

Keep it separate from ratings. Say clearly, and get your lead to say it too, that what people write to each other goes to each other and not into anyone's review. The moment people suspect it feeds a score, they start writing politely and carefully, which makes it useless.

Make it small and regular rather than large and rare. A short exchange every six weeks is far better than a long survey once a year. Pair people up, rotating each round, so everyone gives and receives with someone they have actually worked with recently.

Give people questions that produce something usable. What is one thing I did recently that helped you? What is one thing I could do differently that would make working with me easier? Two questions, one concrete example each. Open boxes labelled strengths and weaknesses produce adjectives, and adjectives cannot be acted on.

Suggest a conversation, not just a written note. Fifteen minutes on a call, exchanging both answers, with the writing as preparation. Spoken feedback between peers is easier to soften and clarify, and easier to thank someone for.

Go first, visibly. Ask a colleague for feedback in the team channel and share, briefly, what you are going to change. People copy what they see more readily than what they are told.

Make it optional at the start, and check after two rounds. Ask the team whether it is helping and what to change. A scheme that the team adjusts is one they will keep.

And expect the first round to be cautious. Trust grows round by round. That is the scheme working, not failing.

– Asael Shinder

Someone Asked You a Question in the Meeting and Your Mind Went Blank

Asael Shinder — Fri, 16 Oct 2026 18:29:50 +0000

It was a simple question. Why did we choose that queue over the other one? You knew the answer. You had argued for it in a design discussion two months ago. And yet, with twelve faces on the call looking at you, nothing came. A second of silence, then three more. You said something vague, the meeting moved on, and you replayed it for the rest of the day.

This happens to almost everyone, including people who seem endlessly fluent. Under pressure, recall gets harder. It is not a sign that you do not know your work. It is a sign that you are a person being watched.

The useful thing is not to stop it from ever happening. It is to have a plan for when it does.

Give yourself permission to pause on purpose. Good question, let me think for a second. Said calmly, a pause like that sounds like care. Most people in the meeting will barely notice it, and the second you buy is often enough for the answer to arrive.

Start with what you do remember, even if it is only part of it. We compared both on cost and on how they handle retries, and I can walk through the rest. Starting to speak often brings the rest back with it.

If nothing comes, say so honestly and promise something specific. I do not want to give you half an answer. I will send the reasoning in the channel this afternoon. Then do it, well, before the end of the day. A clear written answer a few hours later often lands better than a perfect spoken one would have.

Prepare for the questions you can predict. Before a meeting where your work is discussed, write down the three questions you would least like to be asked and one line for each. You rarely need the notes. Having written them is what helps.

And go easy on yourself afterwards. The meeting has forgotten that silence already. Only you are still replaying it.

– Asael Shinder

You Are Chairing a Meeting Where Half the People Are Remote

Asael Shinder — Fri, 16 Oct 2026 18:24:39 +0000

Six people sit around the table in the office. Five more join on video, small faces on a screen at the end of the room. You are running the meeting, and you already know how it usually goes. The people in the room talk to each other, someone makes a joke nobody remote can hear, and the people on the screen give up and start answering email.

This is not because anyone is rude. It is because a room naturally favours whoever is in it. If you are chairing, balancing that is your job.

Start with the sound. Before the meeting, join from your own laptop in another room and listen. Can you hear the far end of the table? If not, move the microphone or ask people to move closer. People forgive a fuzzy picture far more easily than voices they cannot make out.

Put the agenda and any document you will discuss in the meeting chat, and share it on screen rather than holding it up or pointing at a whiteboard. Anything only visible in the room might as well not exist for half your audience.

Go to the remote people first. When you open a topic, ask someone on the screen for their view before the room starts. In a discussion, the room fills every gap within a second, and someone on a slight delay never finds a moment to speak. Asking them by name gives them one.

Watch the chat as if it were a raised hand. Read questions out loud, credit them to whoever asked, and answer them.

Say decisions out loud and write them down where everybody can see. Side conversations at the table often contain the real decision, and remote people find out about it a week later.

Some teams solve this by having everyone join from their own laptop, even those in the office, so everyone has the same small square. It feels strange at first. It is usually fairer.

At the end, ask the remote people one question. Did you get to say everything you wanted to? Their answer will tell you how well you ran it.

– Asael Shinder

The Course Says Your Team Is Doing It Wrong

Asael Shinder — Fri, 16 Oct 2026 18:19:28 +0000

You come back from a two day course on service design full of energy. One slide is still in your head. Each service should own its own data, and services should never share a database. Then you open your laptop on Monday and look at your team's system. Four services, one database, and three of them reading each other's tables.

The temptation is to walk into stand up and announce that we are doing it wrong. Resist it for a week. What you learned is only half the picture, and your team holds the other half.

Courses teach with clean examples on purpose. The example system has no history, no deadlines, no customer who needed a feature by March, and no team of three supporting it. Advice built on that example is usually sound in general and silent about your particular situation. Your job now is to translate it, not to import it.

Start by finding out how the system got this way. Ask the person who has been on the team longest, with real curiosity. Why do these services share the database? Often there is a reason you could not have guessed. A reporting requirement, a migration that ran out of money, a decision that was right at the time.

Then look for the actual cost in your system, not the cost the course described. Has the shared database caused an incident? Does a schema change in one service regularly break another? Write down two or three specific examples. A problem the team has felt is far more persuasive than a principle from a slide.

If the cost is real, propose something small and reversible. Not a redesign, but one table that only one service may write to from now on, and a review after a month. Small changes let the team test the idea without betting on it.

Frame it as a question, at least at first. I learned something on the course that made me wonder about our database. Can I show you what I mean? People join a question far more readily than they accept a verdict.

And be ready to conclude that your team was right. Sometimes the principle is sound and the trade off still goes the other way. That is also learning, and probably the most useful kind the course gave you.

– Asael Shinder

You Want to Ask to Work Four Days a Week

Asael Shinder — Fri, 16 Oct 2026 18:14:17 +0000

You have done the sums. With a little less money you could have Fridays back, for your children, your health, a parent who needs you, or simply a life with some air in it. What stops you is not the money. It is the worry that asking will quietly mark you as someone who is no longer serious about their career.

That worry is worth taking seriously, and it is also worth testing, because it is often bigger than the reality.

Find out the rules first. Look in your handbook for a flexible working policy, and check whether anybody on your team or nearby already works reduced hours. In the UK, since April 2024, employees can make a formal flexible working request from their first day, up to two in any twelve months, and the employer has to respond within two months. Other countries have their own rules. Knowing yours changes the conversation from a favour to a process.

Then think through the job, not just the hours. Which meetings fall on the day you want off? Who covers an incident on a Friday? What work will genuinely stop, and what will just get squeezed into four days? Write a short proposal that answers those questions before your manager asks them. A request that already solves the obvious problems is far easier to approve.

Be precise about pay and scope. Four days usually means eighty percent of the salary. It should also mean roughly eighty percent of the work. The common trap is taking the pay cut and keeping the full workload. Agree with your manager what comes off your plate, in writing.

Ask for a trial. Three months, then a review together. It lowers the risk for everyone and gives you evidence to point to.

On the career question, be honest with yourself. Reduced hours can slow some kinds of progress, especially roles that depend on being present for every decision. But plenty of people have been promoted on four days, because what gets people promoted is visible impact, not hours.

And if you get it, protect the day. A day off that fills up with messages is just a fifth workday with a lower salary.

– Asael Shinder

Your Mentee Wants to Ask for a Pay Rise

Asael Shinder — Fri, 16 Oct 2026 18:09:06 +0000

Your mentee has been quiet for half the call, and then it comes out. They have been doing more for a year, they found out what the market pays for their role, and they want to ask for a rise. They have never asked for money before. Can you help them say it without sounding greedy?

Start by taking the word greedy off the table. Asking to be paid fairly for the work you actually do is an ordinary part of a working life, and managers have this conversation many times a year. Most of them would rather be asked clearly than discover months later that someone has quietly started interviewing.

Then help them build the case, because a request for money is really a request for a decision, and decisions need evidence. Ask them to write down what has changed since their pay was last set. New responsibilities. The service they now own. The two people they onboard. Results with numbers wherever possible. Then the outside view. Salary surveys, published bands at comparable companies, job adverts that show ranges. Two or three sources are enough.

Find out how pay decisions are made where they work. Many companies set pay once a year, and budgets are decided weeks before anyone is told. Asking in the right month matters more than asking well. If they do not know when that is, the first conversation can simply be a question to their manager. When are pay decisions made, and what would you need to see from me?

Rehearse it with them. Play the manager. Say the difficult things a manager might say. There is no budget this year. You are already at the top of your band. Let them practise answering calmly, and help them prepare the follow up question for each. Then what would need to change, and by when?

Talk about the no in advance. A no with a plan and a date is a real outcome. A no with nothing attached is information too, and they are allowed to act on it.

And afterwards, whatever the answer, ask how it felt. The first time is the hardest. You are helping them with this rise, and also with every one after it.

– Asael Shinder

Your Customers Will Ask What Your Software Is Made Of

Asael Shinder — Thu, 15 Oct 2026 05:52:57 +0000

In May 2021, an executive order on cybersecurity in the United States set out that software sold to the federal government should be able to come with a software bill of materials. Two months later the government published the minimum elements such a list should contain. The idea is simple. A machine readable inventory of every component inside a piece of software, with names, versions and where they came from, so that when the next serious vulnerability is announced in a popular library, buyers can find out in minutes whether they are affected.

It started with governments, but it is spreading through ordinary contracts. Large customers increasingly ask suppliers for one, and the standard formats, SPDX and CycloneDX, are now supported by many common build and scanning tools.

For an engineer, this changes a quiet assumption. For years the list of dependencies in your project was your team's private business. A file nobody outside engineering ever read. That file is becoming something a customer, an auditor or a procurement team may ask to see, and may question.

That rewards a set of habits that used to feel optional. Knowing why each dependency is there. Removing the ones nobody uses. Keeping versions current, so that the list you hand over does not include a library with a famous problem. Being able to say which of your services ship which components, without a week of digging.

It also creates a useful role. Someone on most teams will need to understand how the inventory is produced in the build, what it does and does not include, and how to answer a customer who has questions about a line in it. That person sits between engineering, security and sales, and is usually trusted by all three.

You do not need to become a supply chain specialist. But being the engineer who can produce an accurate list of what your software contains, and explain it calmly, is likely to matter more each year.

Monday: generate a software bill of materials for one of your services, and see whether anything on it surprises you.

– Asael Shinder

A Friend Has Asked You to Look at Their CV

Asael Shinder — Thu, 15 Oct 2026 05:47:46 +0000

A friend from your old bootcamp sends you their CV on a Saturday morning. They have applied for forty jobs and heard back from two. Be honest, they write. What is wrong with it?

Be honest is a hard instruction to follow with a friend, because the honest answer might be that it is two pages of duties and not a single result. It is still the kindest thing you can give them. Forty silent rejections are already telling them something, and they are telling it far less clearly than you can.

Start by reading it the way a busy hiring manager reads it. Quickly, once, in under a minute. Then write down what you remember. That list is roughly what a stranger takes away, and it is usually shorter and stranger than the author expects.

Then go back and read properly. Look for the gap between what they did and what they describe. Responsible for maintaining the reporting service says very little. Cut report generation time from four hours to twenty minutes says a great deal. Most CVs written by engineers describe duties, because duties are easy to remember and results feel like boasting.

Limit yourself to the three changes that will make the biggest difference. Usually that means the first third of the first page, the strongest two or three results, and anything that makes the reader stop and frown, such as unexplained gaps or a list of thirty technologies.

Give the feedback in a call rather than in comments on the file, if you can. Tone gets lost in a document full of red marks, and you will both learn more by talking. Ask them questions as you go. What was the result of that project? Who used it? Their answers are usually better than what is written down.

Be careful with your own preferences. Fonts, layout and whether to include a summary at the top are mostly taste, and hiring managers disagree about all of them. Spend your attention on content.

Then ask to see the next version. Feedback on a CV only really helps once it has been used, and the second read is where you find out whether it was understood.

– Asael Shinder

You Have Ten Minutes in Front of the Leadership Team

Asael Shinder — Thu, 15 Oct 2026 05:42:35 +0000

Your project has done well, and somebody senior wants the leadership team to hear about it. Your manager tells you on Monday that you have ten minutes on their Thursday agenda. Directors, the chief technology officer, the head of finance. You will be the most junior person in the meeting by several levels.

Here is what most people get wrong, and it has nothing to do with nerves. They prepare the presentation they would give to engineers. Architecture, a clever detail, the story of how hard it was. Leadership teams rarely want any of that.

Find out what they want before you prepare anything. Ask your manager. Why are they asking for this, and what do they need to decide or understand afterwards? Often the answer is short. They want to know whether to fund the next phase. They want to know if it is safe to tell customers.

Put that answer in your first minute. What we did, what it changed, and what we need from you, if anything. The rest of the ten minutes is support for those three sentences.

Use numbers they recognise. Not requests per second, but orders, hours saved, customers affected, money. If the numbers are uncertain, say how uncertain. Senior people are used to imperfect figures. What bothers them is false precision.

Expect to be interrupted. In many leadership meetings, the ten minutes become two minutes of slides and eight of questions. That is not rudeness. It is interest. Answer briefly, and if you do not know, say so and promise a follow up by a specific day.

Rehearse once with your manager, and ask them to play the most difficult person in the room. What is the question you are afraid of? Prepare one honest sentence for it.

And remember why you are there. You were invited because you know this work better than anyone at that table. They are not testing whether you belong. They are trying to learn something from the person most likely to know it.

Afterwards, send a three line summary with the follow ups you promised. Plenty of people present well. Fewer of them follow up.

– Asael Shinder

You Want Your Manager to Pay for a Tool

Asael Shinder — Thu, 15 Oct 2026 05:37:24 +0000

You have been using the free tier of a profiling tool for a month, and it has already found two slow queries nobody could find before. The paid plan costs a few hundred a year per seat. You would like the team to have it. You mention it in stand up, someone says that would be nice, and nothing happens.

Nothing happens because a remark is not a request. If you want money spent, you have to make it easy for someone to say yes.

Find out who actually approves it first. Your manager may sign it off, or may need to ask a director, or security may have to review anything that touches production data. Ask your manager directly. If I wanted us to buy a tool, what would you need from me, and who else has to agree?

Then write a short note. Half a page is plenty. What the tool does, in one sentence a non engineer could follow. The problem it solves, with a real example from your own work. It found the slow customer search query in ten minutes after we had spent two days looking. The cost, per year, all in. And what happens if you do not buy it, which is often the most persuasive line.

Be honest about the alternatives. Is there something the company already pays for that would do most of the job? A free option? Saying so yourself makes you sound like someone weighing it properly, not someone who has fallen for a product.

Answer the questions they will ask before they ask them. Where does it send our data? Does it work with our single sign on? Can we cancel after a year? If you do not know, find out, because a security question with no answer will stall the request for months.

Suggest a small start. Three seats for three months, then a look at whether it earned its place. A trial is far easier to approve than a commitment.

If the answer is no, ask what would change it. Sometimes it is timing, sometimes it is budget, and sometimes the next request just needs a better example.

– Asael Shinder

You Get Five Learning Days a Year and Have Used None

Asael Shinder — Thu, 15 Oct 2026 05:32:12 +0000

It is October. Your contract, or your company handbook, gives you five days a year for learning, and you have used none of them. It is not that you forgot. Every time you thought about booking one, there was a release, a bug, or a sprint that felt too important to leave.

So here is the uncomfortable truth. Those days are almost never taken by people who wait for a quiet week, because there is no quiet week. They are taken by people who book them like holiday.

Look at your calendar now and put two dates in it before the end of the year. Tell your lead the same way you would tell them about leave. I am taking the twelfth for learning. Most leads say fine, because the company offered the days and would rather people used them.

Then decide what the day is for before it arrives. An empty learning day becomes an inbox day by ten in the morning. Choose one thing, small enough to finish. Read the chapter on transactions you have been bluffing through for two years. Build a tiny version of the queue your team depends on. Work through the official tutorial of the tool you use every day but only half understand.

Leave the building, at least in spirit. Sign out of chat. Set an out of office that says you are on a learning day and will reply tomorrow. If you stay reachable, you will be reached.

Write down what you learned at the end of the day. A short note, half a page, in your own words. Share it with your team if it is useful to them. That note does two jobs. It fixes the learning in your own head, and it shows the company what the day produced, which makes it easier for everyone to take the next one.

If the days do not roll over, the deadline is real. Unused learning days usually just disappear on the first of January.

Monday: open your calendar and book the first one.

– Asael Shinder

You Have Been Split Between Two Teams

Asael Shinder — Thu, 15 Oct 2026 05:27:01 +0000

The decision is announced as good news. Your skills are in demand, so from next month you will spend half your time on the payments team and half on the new partner integrations. Two stand ups, two backlogs, two leads, and one of you.

Most people in this position end up doing roughly seventy percent of each job, feeling behind on both, and getting credit from neither. That outcome is common enough to plan against from the first week.

Start by getting the split in writing, in concrete terms. Not half and half in principle, but which days, or which mornings, belong to which team. Fifty percent of a week that is decided fresh every Monday turns into whoever shouts loudest. Fixed days let both teams plan around you.

Ask both leads the same question, ideally together. When your priorities clash, and they will, who decides? If the answer is that you should work it out, push gently for a name. You should not be the person settling disputes between two senior people about your own time.

Drop something. Two half jobs cannot carry every meeting of two full ones. Look at both calendars and agree which ceremonies you will skip on each side, and how you will catch up instead. A short written summary from a teammate often replaces an hour of a meeting.

Be careful about review season. In many companies, a person split between teams gets reviewed mostly by the lead who happens to write the review, who has seen half the work. Keep your own record of what you delivered for each team, and make sure both leads contribute to your review. Ask for that now, not in December.

There is a real upside here, if you notice it. You are one of the few people who sees how two parts of the company actually connect. You will spot duplicated work, mismatched assumptions and integrations that nobody owns. Saying so, clearly and early, is the kind of contribution that gets people noticed.

Set a review date too. After three months, ask whether the split is working for both teams. Arrangements like this tend to drift on long after anyone remembers why they started.

– Asael Shinder