We all agree: saying no is important – it can be liberating, support work-life balance, and is a crucial life skill.

What’s discussed far less is the cost of refusing, especially the psychological cost. That’s what I’d like to explore: the emotional toll of refusing – on ourselves and on those we ask for something, even when we reassure them, “It’s totally fine if you can’t.”

It’s hard to refuse – and all too easy to agree

Overall, saying no often carries negative connotations, which is why we tend to avoid it. We dislike being in situations where our words or actions might be perceived as negative. It becomes even more difficult to decline in person – especially when we know the person well or feel emotionally connected to them or the topic.

People are generally more dismissive online or in anonymous settings, where the perceived consequences are minimal. It’s much easier to ignore or mock a request to “like” a post on social media than to say no to your mum when she asks for help picking apples.

In a professional setting, declining becomes even more complicated.

We’ve created a work culture where declining requests too often can feel like a career risk, especially for women and members of minority groups. Declining isn’t only disappointing for the person who asked; it might also mean missing out on a promotion or an exciting opportunity. Holy carp!

Conversely, accepting is effortless.

It feels nice and positive. You’re pleasing the other person, maybe even securing a future reward for yourself. What could be better? Since humans are wired to chase immediate rewards and often overlook future pain, we tend to say yes just to see that happy twinkle in someone’s eye – consequences be damned!

If you Google “how to say no”, you’ll get a lot of results, mostly focused on the actual skill of rejecting something. If you Google “how to say yes”, you mostly get results about how to say words and phrases in different languages. Declining is a tricky soft skill; accepting is often just about language.

Turning something down is… stressful.

So, where are we with no?

• We’re not that great at saying it.
• It’s not a pleasant thing to do.
• It can have negative consequences.

As a result, it’s often stressful to refuse a request.

We tend to worry about it before, during, and after the fact. This stress can be even worse if we’re already dealing with things like burnout, impostor syndrome, or anxiety. Saying no in those situations can feel like adding fuel to the fire. If I already don’t believe I’m doing a stellar job, turning something down might only reinforce the fear that others see me as a failure.

Our tendency toward herd mentality doesn’t help either. When most of the team says yes and we’re the only ones who want to say no, we often end up going along with the group, even if we feel conflicted inside.

Many of us have experienced this in sprint planning and sprint reviews – the team takes on more work than necessary during planning to avoid refusing requests, and then feels deflated and disappointed when they can’t deliver everything by the end. Over time, this can hurt team morale and spirit, lower motivation, and even create a toxic dynamic between teams and their stakeholders.

All of this leads to a simple point: refusing comes with its own burden. Telling someone to “just say no” can be disingenuous – placing the emotional and social cost of rejection on them, while pretending it’s easy.

Expecting a simple refusal hurts the ones who care most

The people who are most invested in a project, those who care deeply about the quality of their work and their team’s delivery, often your “best performers”, are usually the ones who find it hardest to say no. As a result, they often take the initiative to pick up tasks that others might reject.

If you keep asking, they may continue to agree, depending on their situation, until they eventually hit a wall and burn out.

Be kind. Don’t act like no is just a simple word

We should be mindful of our colleagues’ workloads and, whenever possible, avoid asking them for additional tasks if we know they might already have a full plate.

It’s important to recognize that they may feel unable or reluctant to refuse, even when they want to. And even when they do refuse, it can still come at a cost to their emotional well-being or personal life.

We should also recognize that refusal comes in many forms. It can mean:

• Literally saying no.
• Taking only 5 tasks out of 10 that were offered.
• Choosing not to volunteer when most others do.
• Not attending a meeting or participating in a Slack discussion.

All of the above can be difficult to do and may lead to negative consequences down the road, for both the individual and the team.

What’s the solution?

• Talk openly with your colleagues. Be aware of the challenges they face and the workloads they carry. Don’t expect them to simply reject additional work – understand their situation through honest conversations.
• Keep expectations realistic. Avoid presenting people or teams with overwhelming wish lists they can’t reasonably deliver. Don’t assume others will just say no to unreasonable demands.
• Diversify your requests for help. Instead of always turning to the same people who tend to say yes, reach out to others and distribute the load more evenly.
• Avoid herd mentality pressure. Give individuals space and time to make decisions independently, and encourage sharing outcomes in a safe environment. This is why practices like writing retrospective points individually or revealing estimations simultaneously in planning poker are important.
• Lead by example. Show that saying no when it’s appropriate is acceptable. Recognize that you might also struggle with this and discuss it openly with your team.
• Establish fair systems and processes. Ensure workloads are distributed transparently and fairly, rather than relying on informal methods that often favor those who find it easier to say no – which can unfairly burden those who care most about the project’s success.
• Don’t reward or idolize overwork. Encourage a culture that values balance and sustainable effort over relentless hustle.

The post Saying NO is not a free action in the world of software engineering appeared first on ShiftMag.

When you combine that with mostly remote, written communication in a foreign language between people who might not know each other that well, who are under various types of pressure (time, quality, focus…), with various skill levels and seniority, you have a good chance of things getting out of hand.

Luckily, there are some easy things we can do to make this easier on everyone. Read on to find out what!

Sidenote: This document is not a PR review checklist. It will not tell you what to check during a review or what code to expect. I wrote this to show you HOW to communicate during reviews to make the experience more useful and pleasant for everyone, but it will not define any rules. For that, I suggest you talk to your team, your partner teams, and your stakeholders and agree on some rules with them.

The Pillars of a Good PR Experience

There are just two things that need to work well in order for the whole thing to be a success:

1. Mindset
2. Communication

Now, let’s break those down.

Mindset: PRs are not Personal

In general, it is good practice to assume everybody in a PR means well. That should be your initial starting point. The PR author is not there to deliberately push horrible code. The PR reviewer is not there to “get you” and “publicly shame you”. In the vast majority of cases, the goals of the authors and the reviewers are actually the same: to deliver good code that does what it is supposed to do.

Keeping this in mind is a very good start.

This does not mean you should not be vigilant and should not do your best to find problems as an author or reviewer. But it does mean that when first communicating, you should assume mistakes are honest, decisions had a reason, and intentions were good. It is your job to confirm this and make sure you understand the context. 

Only if facts later prove the opposite should your tone change accordingly. If there are serious concerns or doubts about the intentions or skills of a team member as a result of a PR review, those should be taken to the relevant line manager (but before you escalate, try to reach out to the other person via call / DM and get as much clarity as you can). They should not be discussed in the PR itself.

Another thing to keep in mind is that PRs are not supposed to be personal, and they are supposed to be educational for both sides. People get very emotionally invested in their work and get defensive quickly. Try to avoid this. See if there are things you can learn from the ongoing discussion and become a better engineer. Always enter PRs (both as an author and as a reviewer) with the goal of learning something new. And remember, this is not only about author-reviewer communication. Reviewers can also learn from each other by working on the same PR. So when communicating about the PR, do not just think about the author, think about the other reviewers as well – are there things you can include to help them?

Please remember:

• a team will survive a certain amount of messy code
• but a team might not survive broken human relationships

As long as the intentions are good and nothing is exploding, prioritize people over code (in other words, be nice).

Communication: Be Kind and Helpful

A colleague informed me of this beautiful and very simple approach to making PR comments much more helpful. It complements what I was trying to say below and makes it much more explicit and elegant.

As a PR Author

• Review your own PR before you submit it. You might be surprised at how many things you can find yourself.  You can even leave comments in the PR yourself for other reviewers in case you think it would provide more context.

I added this method to gather more metrics for the issue described in GRG-543. We should probably consider some more centralized auditing/logging solution in case this becomes a frequent use case, but for now, it is good as it is, I think.

• It is your responsibility to get your things reviewed. Make sure you understand how reviews are prioritized and picked up by reviewers. Do you need to ask for a review on Slack? Is there time dedicated to reviews on standups? Is there a dedicated group of reviewers? If unsure, ask the repo owners for guidance. Don’t let your PR be forgotten.

Hi everyone! I have a new PR that is a bit urgent due to our sprint ending soon. Could you please take a look? Please get in touch with me on Slack directly if this can help us get it done more quickly. Thank you!

• Provide a short PR description with some context:
  • Are you new to the project? Do you need help/guidance, or expect a lot of issues?
  • Do you have a preferred way of discussing the PR (e.g., a huddle, a DM exchange on Slack, Bitbucket comments)?
  • Is the PR work in progress?
  • Is the PR very urgent? If yes, why? Did it force you to take shortcuts?
  • Was performance a major factor? Was some code optimized for it?
  • Are there any follow-up tickets that will improve on the solution further?
  • Did the architecture, API, or something else change significantly?
  • Does it have dependencies on other work/teams?
  • Is there some relevant documentation you can link to?

Integration of the new component to display a shopping cart into the main navigation. Will be further reworked under BLAH-123 and BLERGH-456. I realize the navigation component is a bit messy, unfortunately, I did not have time to fully refactor it due to the project deadlines, so I only touched the code required for the new functionality. I will try to get back to it under BLERGH-456. Please check the Jira ticket under which this was done for complete business requirements when reviewing, they are more complex than expected, which can explain some of the possibly messy code in the addItem method. Oh and I am still a bit new to this repository, so apologies if I messed something up – please let me know if there are some guidelines/documentation that I missed!

• If you cannot implement some of the suggested changes, make sure you follow up in writing, either by explaining why the change will not be implemented or by providing links to follow-up tickets/PRs where those comments will be resolved.
  For cases where time is the limiting factor (approaching deadline, bigger suggested changes, etc.), always consider what would cost more—making the change now or postponing it (which carries its own overhead in planning, focus switching, etc.). Failure to do this can really frustrate reviewers, who dedicate time and energy to the review and then get nothing back.

Thank you! I don’t think I will be able to make these changes under this PR since they would require more time, and there is a risk we would miss the deadline, but I think your suggestions are totally valid, and I will cover them under BRUH-789 if you don’t mind.

• Always indicate if you resolved the comment. If you resolved it using a different approach than the one suggested by the reviewer, explain why.

I managed to resolve this differently by moving the whole method to the PaprikaChipsService. It probably should have been there from the start… Thanks for the comment!

• Always thank the reviewers in comments for their time!

Thank you!

As a PR Reviewer

• Before starting the review, check who the author is and what their background is. Tailor your approach based on that. A junior developer who joined a remote team 1 month ago will require a dramatically different approach than a 5-year senior who sits next to you in the office. If unsure, ping that person directly and ask.

Hey! Nice to meet you! I just picked up your PR, but since this is the first time we will work on something together, I wonder how you would prefer to do it? We can just go through it together in a huddle if you would prefer that, or I can just leave comments in Bitbucket. I noticed this is your first PR in this repo, if you need help or something is not clear, please do not be afraid to ping me, I will try to explain if I can.

• Explain why you are asking authors to change something. Provide links, context. See your comment as a possible way to share knowledge. Do not assume the author will automatically understand. Authors have various skills and seniority levels, and something that is obvious to you might be completely new to them. 

I suggest you rewrite this to use streams. Unless you need really hard-core performance (which does not seem to be the case), streams are much better for readability/maintainability. Check this out for a pretty good introduction to streams and a comparison to standard loops. 

• Provide specific suggestions to fix if you can. If you do, don’t forget to explain why. This is good practice even if you know the author will understand. There might be other PR reviewers who might not understand, and this can still be an education for them.

a.b?.c instead of a.b.c.This will prevent runtime errors in case b is null, since if you look at the method above, there are cases where it can be null. See here for details.

Both Author and Reviewer

• Be friendly, polite, and empathic. There is another human at the other end. Do not write anything you would not want to read yourself in your own PR. Use emoticons (but don’t overdo it). Don’t be sarcastic and don’t mock/make fun of the other person’s work. Don’t forget to also give credit if you see something cool!

Nothing to change, I just really like how you solved this.  Well done.

• Be aware of the team’s working agreement or coding standards. Is there a Boy Scouts rule in place to always leave code in better shape than you found it? Are there specific requirements for tests, external dependencies, formatting, etc.? If unsure, ask before you start development, submit the PR, or start the review!

Hi everyone, I’m wondering if it’s okay to include Lombok in this project. Could you please let me know? I could not find any explicit rules regarding dependencies. Thanks!

• Consider reaching out to each other directly for more complex reviews, reviews with urgency, or reviews with a lot of findings, and have a huddle/chat to avoid a lot of comments/ping-pong

Hey! Would you have time to talk about this PR <link> today or tomorrow? I see there are a lot of changes, and the requirements are complex as well – discussing it in person, at least for the first round, might be easier. Thanks!

• Stick to facts. If you have an opinion about why something should be done, provide links to support your statement.
  • For more subjective topics, be prepared for compromises. If you cannot find definite sources to support your case (this happens often in discussions about code formatting, etc.), consider just doing whatever feels easier / quicker / more friendly to the other party. Mutual respect and a good working relationship in the team are usually better than completely uniform code. If necessary, agree to follow up on a team-level meeting to reach an agreement there.

I don’t think we actually have an agreement about this in the team, but we should try to agree on some naming pattern for test methods. Let’s keep this as it is for now, but I will add this to the agenda for our next sync if you don’t mind. If you have any suggestions, please let me know!

• Do not jump to conclusions. Respectfully ask for context and reasons.

I am not sure why this needs to be package-private. I see you refer to it in the tests, is that why? I think they could be refactored to avoid this, but on the other hand, I am not sure it is worth the effort… Could you please provide a bit more context? We can also chat on Slack if that would be quicker. Thanks!

• Be mindful of the time. Will it take you more time to argue about something, or will it be easier to just implement the change and move on?
  
• Put the conclusion back into the PR in writing if you agree on something in a huddle or some other communication channel. This can help others who did not participate in the call understand what was decided and why.
  
• Be prepared to be wrong.

And I think that’s it! Stay nice, keep a positive attitude, make friends, and write good code and the future will be bright.

The post How to Participate in PR Reviews, Make Friends and Influence People appeared first on ShiftMag.

There is this idiom, “It goes without saying…” which basically means that something is obvious and does not need to be said. I tend to think the heading above is one of those things.

But practice shows that maybe it isn’t, and it needs to be said once in a while.

Sometimes, we all have planning sessions  where we say stuff like, “Let’s do the rough implementation now, and we will add unit tests in the next iteration.” or “Let’s put out a quick POC and improve it later.” We also have sprint reviews where we say things like, “It is available on PROD but needs some refactoring—I created a task for it in the backlog. But we can close this one.”

It feels very natural. We are agile; we iterate, and we improve as we go.

All good.

The Metaphor

And now I present to you a picture of a pile of manure, with the author of the pile included:

Now, how do piles of manure come to our world? A cow eats some grass and becomes very introspective and thoughtful after some time. After a couple of minutes of pondering the hard questions of life and the universe, it produces a small pile of cow feces. This cycle then repeats itself. You could say the cow is iteratively building the pile.

However, and this is quite crucial, at no point does the pile of manure transform into a gleaming palace. It stays a pile of manure.

This example gives us our first piece of wisdom:

By producing little shits iteratively, we do not build examples of beautiful architecture. We build piles of shit.

The Second Metaphor

Now, this is a gleaming palace:

How are palaces constructed? Well, you start with a lot of high-quality building blocks, from bricks to pillars and statues, which you produce over and over again and combine to end up with a palace (this is somewhat simplified, but you get the point).

For a good and sturdy palace, not easily conquered by marauding barbarians, it is vital you maintain a standard of quality throughout the process and within every iteration. A single batch of incorrectly baked bricks in the wrong place can cause structural damage with potentially catastrophic consequences.

This gives us our second piece of wisdom:

To build a solid palace, stick to a quality standard every time you deliver a brick.

I think you know where I am going with this. We all know that in many cases, the phrase “we will improve this later” means “we will never improve this.”

Creating a task for fixing technical debt is not the same as fixing the technical debt; however we wanted to wish the opposite. There is a good chance that every time a cow shits, the shit will stay shit and will not get improved later into a brick of gold.

The Point of the Article

This is why we all need to have definitions of done (DOD) and stick to them. 

A definition of done protects us from producing little bits of manure and forces us to actually produce proper bricks. It is completely fine not to deliver a palace in one sprint. You can just deliver a brick. But the brick must still be inspected properly, properly manufactured, of the correct shape, density, and material, and baked for the correct time and at the correct temperature.

Or finally, to switch to a software language, it is fine to deliver a single component that does not cover the whole feature set. But the component should still be documented, covered by automated tests, with proper architecture and software design, reviewed, and have monitoring and alerting configured, etc. etc.

What does this mean for your planning sessions?

When discussing any story, it should just never be an option to reduce the estimation by removing parts of the DOD requirements. This brings us to our last piece of wisdom.

You should never compromise on quality when estimating and planning.

At the end of the sprint, you should not close tasks or merge / release code that does not fulfill DOD criteria either. Even if this means missing the release date. This should rarely happen if you take quality into account when estimating, but if it does, it should mean failure. (There is another point here, which is that if our stakeholders only find out we are late with something a day before the sprint ends, we are already in trouble, and there are other problems we need to solve. But that’s a story for another day.)

This is painful. It will create immediate friction and stress. People will be angry.

“Why cannot you release this if just unit tests are missing? This is madness! You can add the tests the day after tomorrow!”

Sometimes, you will add them. But often, you won’t because there will be other priorities and pressures. And the manure pile will keep growing. 

At some point, it will become almost impossible to deliver a palace—even if you build a proper brick once in a while, you will still throw it at the existing pile of manure, and it will just become dirty and not usable long-term.

There is going to be no palace at the end of this story.

Just a thoughtful cow.

MORE READING:

The post How to build a palace: Building in iterations is not the same as postponing quality appeared first on ShiftMag.

You see a car parked by the side of the road. Passengers are gesticulating wildly, and you hear the engine failing to start repeatedly. “Damn, their car battery is dead! I better run and help!” you think to yourself, being the good Samaritan your mother taught you to be.

Reflecting back, my career began with a slightly anarchistic approach as a software developer. I did not think much of hierarchy. I was not a fan of “corporate culture”. The idea of someone telling me what to do was alien to me.  

Despite this attitude, I quickly moved from software development to management. One of the first things I told myself and held on to was the simple rule of “I will not tell people what to do.” 

It took me many years of experience to realize this slightly dogmatic approach is not always a way to go. There are valid reasons to push people to do something.  

However, like with most things in management, knowing who to push, when, and into what, is crucial for success. Misjudge the situation and the price you pay for failure can be steep indeed. 

To push or not to push?

Without a second thought, you break into a run. You grab the car trunk and start pushing. The people in the car look back at you in surprise, and the driver opens her mouth in a big O. “Another good deed done!” you think to yourself with satisfaction as you feel the vehicle starting to move on its own. Moments later the car and its occupants disappear as the terrain suddenly drops away. You hear a loud bang.  

So what does it mean to push someone as a manager?

In simple terms, it means directly asking someone to do something that they would not sign up to do by themselves. You are forcing them to get outside of their comfort zone! If you do this correctly, the benefits for the person pushed are numerous: 

• They can acquire a new skill, 
• They can gain confidence and be more willing to engage in similar activities in the future, 
• They can get recognition, 
• They can eliminate internal mental barriers or dogmas, 
• They can gain a new perspective or widen their horizon, 
• Even if they ultimately fail, they can learn from the failure. 

Your best bet for pushing someone is to identify strong points that the person has but is not aware of or is not utilizing fully. That way, you set them up for success from the get-go. But this is easier said than done. 

If you make a wrong decision at the wrong time, disaster can strike.  

People you push can become frustrated, even to the point of quitting their jobs. They can fail at the task you pushed them to do, sometimes with serious consequences for the project or the company. This can also lower their self-confidence and cause them to avoid this type of work in the future.  

Ultimately, they can blame you for the whole thing without learning anything. And they would not be wrong. 

Get to know your colleagues

Luckily for you, this is a time-traveling story. You rewind the clock 10 minutes back and you find yourself facing the car again. This time you do not run. You do not push. You take a few breaths and approach the car slowly. “Hey, you folks are having some problems?” you ask. 

You need to know someone’s circumstances before you can push. Every person is different, so you do what good managers do. Get to know your colleagues! Build a relationship and trust via the time-tested framework of one-on-ones, working together, being present, and following up. This takes time. As you go, make sure you understand what makes the other person tick. Ask yourself (and ask them!): 

• What motivates them at work and in their lives? 
• Where do they feel their current limits are? 
• What are their strong and weak areas? Which ones can be improved? 
• Are there areas where the person might benefit from a new experience or perspective?

A relatively common occurrence during my career was working with folks who tend to avoid communication but do a good job communicating once they did do it. Another would be a colleague with strong technical skills and a natural talent for software architecture, who was for a long time unable to step outside of the shadow of a more senior team member.  

These are great examples of people who might need a bit of encouragement or push to move to the next level of their careers. As a manager, you need to learn how to spot opportunities and take advantage of them. 

As you ask your question, you feel the multiverse split off into several branches. In one, the driver looks at you in surprise. 

“What problems? We’ve just arrived and plan to have a picnic right here. There is a cool cliff up ahead, and we want to enjoy the view!”  

“But didn’t your car just fail to start? Do you need a push?” 

“I hit the ignition with my knee by mistake. I am way too tall for this car.” 

You nod and slowly back away. These people have it under control. 

Sometimes, people are just OK. They are in a good place at their job and grow at their own pace. All you need to do is give them space. And sometimes, people are just not OK. The last thing they need right now is a push. Maybe they have problems in their personal lives, or they are already struggling at a new position or in a new team. Perhaps they have solid reasons why they cannot do what you are asking them to do.  

Learn and respect. 

Build your case and then act 

In the other branch, the driver looks at you with relief. ”Oh, thanks for stopping by! You know, today is pretty cold, and I guess our old battery could not take it anymore. A little help would be nice. We need to be in the town by noon.” And so you roll up your sleeves and get behind the trunk. It’s time to push some folks to success! 

Once you determine you are ready to push, the next step is to build your case. You should not just out of the blue and without context shout orders at people.  

Use your 1-on-1 to explain what is going on and why their involvement might be beneficial. Explain what you see as their strengths and why you believe they have a good chance to succeed. Explain how the process will work and provide a safety net in case of failure. 

• “This is as much about delivering the feature as it is about you learning the ropes. We can manage the client in case things don’t work out.” 
• “You will not be alone in this. Claire has done this before and she will be your mentor throughout the process”. 
• “Before you even start, there is a week-long workshop to give you all the basics you need.” 
• “I will have regular 1on1s with you to help out and act in case you need it.” 

Often, as part of these conversations, the person will decide to sign up themselves and no push is needed at all! Those are the best times. But if that does not happen and you do need to give them a nudge, make sure you are direct and explain why you are picking them. 

• “I believe you are the best person for this job. Not only is it the logical next step in your career, but you have all the right skills. You did a lot of work in native development and have already designed complex UI components that were well-reviewed. You will get a chance to work with seniors outside of your team and learn a lot about designing larger UI systems. The deadline is tight, but I’ve seen you work under pressure, and you always deliver.” 

And there you have it! As with most things when working with people, the key to success is taking your time, understanding the context, communicating regularly and clearly, and being direct when needed.  

Good luck! 

You watch as the car takes off and approaches the town in the distance. The sun is slowly setting behind the horizon, and you get lost in thoughts for a while until a lonely call of an eagle above drags you back to reality. Well, it’s time to get back to work. You rewind the clock a couple of millions of years back and push those early homo erectus folks to play with fire a bit more actively. After all, they have what it takes. 

The post The subtle difference between pushing developers to start their engine and pushing them off a cliff appeared first on ShiftMag.