From my experience as a people manager (and an even longer stint as a developer), I’ve noticed that many engineers don’t see much value in goals.

If this is how you feel when your manager asks you to set yearly goals (or hands you new ones) you’re not alone.

In my perspective, they often feel like extra homework, tacked on after the “real work” of coding, only to resurface at the end of the year when someone asks about your progress. And from where I stand, you’re right: when treated this way, goals rarely deliver tangible benefits.

But it doesn’t have to be like this.

You’re missing out (on what exactly?)

Periodic goals, when used correctly, are a powerful long-term focus tool. In fast-paced teams, swamped with Jira tickets, code reviews, and spikes, you can be constantly busy yet rarely challenge the true priority or value of your next task.

That’s what goals are for:

• Company goals make sure you’re working on what matters.
• Personal development goals help you learn intentionally from your day-to-day work.

If your goals aren’t doing that, it’s probably because they’re not being used as intended.

How goals started making sense (and bringing value) to me

Once again: you must pick something that you truly feel strongly about. Realising this simple truth was the change in my case. It is better to have one goal that truly meets this requirement than four you only slightly care about.

My turning point came from my personal, not professional, life. I realised that my life wasn’t heading where I wanted, and if I didn’t change course, I wouldn’t be happy with how I’d spent it. This insight helped me see the importance of long-term planning (and I wouldn’t have seen it if I hadn’t read Stephen Covey’s classic book The 7 Habits of Highly Effective People).

From there, I began setting goals, actually tracking them, and finally seeing the value.

How to make goals work

For goals to work for you, you need three simple requirements:

1. Choose goals you genuinely believe are important and valuable.
2. Track progress regularly (if you’re not tracking, it’s usually a sign that requirement 1 isn’t really met).
3. Connect goals to your daily work, so progress happens as you ship, not as an afterthought.

Don’t isolate goals from your workflow

A common problem is that the goals are too detached from your daily work. You likely spend most of your time in the codebase, making changes based on your issue‑tracking system. Now consider a goal like:

By the end of the year, I will have finished a Kotlin fundamentals training.

That’s planning to fail. Will you truly make room for this while putting tickets on hold? If yes, great. But for most of us, day-to-day tasks feel more urgent. December arrives, and you realise you’ve made no progress. Cue the last-minute scramble.

Define a different goal instead: 

When I see a Kotlin feature in the codebase that I don’t understand, I’ll read the documentation and make a note of it (at least once a week).

Why this works: you don’t need much extra time, it won’t derail the task at hand, it’s easy to track, and it builds a habit of continuous learning rather than a one-off course completion.

Focus on the “how,” not just “what”

Another tip is defining goals that focus you on how you’d like to accomplish something. Probably the task from the issue tracking system already tells you what you need to do. A goal can help you define additional criteria or focus on the quality.

Let’s say you introduced a few bugs into the system recently and want to avoid this in the future. You could define a goal:

For every applicable pull request, I will leave a comment documenting measured test coverage before and after the change and ensure it increases.

This keeps the goal anchored in your daily work while adding a perspective often missing from the ticket.

Keep the goals visible

This relates to Requirement 2: if you do not see the goal often, you’re likely to forget to track it. Keep them in sight: as a sticky note on your monitor or pinned at the top of your to-do list.

Use OKRs (or something similarly effective)

There’s a reason OKRs have stuck around: they’re simple and effective. A practical check I like is to define the Objective and then ask:

Will it really happen once these KRs are met?

If the answer is “not quite,” adjust your Key Results until they make the objective inevitable.

Final thought

If you’ve made it this far, I hope it’s a bit clearer how goals can help. Pick goals that matter, track them regularly, and tie them to your daily work. You’ll feel the difference.

Happy goal‑setting!

The post Developer Goals Don’t Have to Be Corporate Theatre appeared first on ShiftMag.

You get an idea and a moment later, the code’s already in your head. And before you know it – bam! – it’s on GitHub.

But hey, it was your side project, not your day job. Because once you step into a “real job,” things get complicated by the minute.

At first, you might think, Oh, we refine the task, put it in the next sprint, implement it, do a PR, testing… and it’ll be done in about two weeks. No bam! this time, but it’s still fast… comparatively.

That speed reminds you of working alone (or with a small, familiar team) where ideas move almost as quickly as they appear. Code follows a thought, and suddenly it’s in the repo.

But once an idea crosses teams or touches parts you don’t own, time stretches. Days turn into weeks, weeks into months – not because the code is harder, but because communication is: unfamiliar code, processes, priorities, even languages.

Who you work with is EVERYTHING

Now I’m going to challenge you even more: how long would it take to implement a system‑wide feature? I’m not talking about some fancy, super‑complex, revolutionary refactor, just something that stretches across many components that aren’t yours. You don’t know them. You don’t even know the maintainers.

And let’s be honest, you don’t want to talk – you’re a programmer, after all, right? You think, Well, a couple of sprints… maybe a few months… if you’re feeling optimistic.

When you’re working alone, the only communication is between your neurons, and that’s pretty fast, isn’t it?

The same goes when you collaborate with teammates you know well. You understand each other, don’t need to repeat much, and many things are already covered by your working agreements (whether written down or just implicit) so you barely have to mention them.

But step into a new or larger team, and suddenly communication is full of obstacles. You don’t know the people, you don’t know how they work, they might speak another language – or worse, code in another language! Cooperation suddenly feels almost impossible.

It will take months, because you need to talk to the others, discuss multiple opinions, understand different perspectives and reach number of compromises. Implementation is easy-peasy. 

The less we know about the project, the more we try to handle it ourselves

Recently we’ve been implementing a very custom solution for a big client. We generally don’t provide custom solutions, but sometimes customers, especially big ones, manage to convince us somehow. 

For most of our integrations, we rely on two key components:

1. Component A handles queuing, throttling, and light request processing. 
2. Component B handles more substantial model transformations and aligns our data with the external provider’s protocol.

In this case, no major model manipulation was required. However, we couldn’t simply send data from A to the provider. We were aware of the configuration possibilities in Component A.

So the question arose: Should we stick to our usual A+B setup, following the well‑worn path? Or should we step outside our comfort zone, reconfigure Component A, and see if we can eliminate the need for Component B altogether?

If both were ours, the answer would be easy. But we didn’t know much about A – we didn’t even know the maintainers.

The temptation to stick with the usual path grew. Then someone had the clever idea to explore Component A using Claude Code. Now we know it, we’re AI-powered! We can do anything, even talk to strangers! Bring them on! we thought. This time, we did it the right way.

Jokes aside, Components A and B (and their ownership by different teams) are a classic example of Conway’s Law: the tendency to copy organizational structure into system design. The harder it is for two people or teams to collaborate, the more likely they are to build separate, siloed parts of the system (have you heard about silos?).

Still doubt that poor communication shapes architecture? Reread the first paragraph – you probably didn’t even notice it the first time. Or check out the insightful presentation The Only Unbreakable Law.

Still unconvinced? Here’s a knockout argument: think back to the last time you tried to sort something out at a government office. How many doors did you have to knock on? How many forms did you have to fill out? How many organizational units did you have to visit? And all for just one issue…

In a well-designed company, this doesn’t always need to be an issue. Why would a corporate lawyer need to talk to a DevOps engineer? Or an accountant to a UI tester?

But when it comes to software, the boundaries aren’t always so clear. In our example, the less we know about the people maintaining a given component, the more likely we are to misuse it and try to solve the problem on our own. That often leads first to overcomplicated architecture, and then to technical and organizational silos.

This is how my team fought the Conway’s Law

You’re probably thinking there must be a way around this, and you’re right. There’s an approach called the Inverse Conway Maneuver: if the organization shapes the architecture, why not design teams to build the system we want?

Sounds clever, but it’s not easy, especially in established companies.

Management must be tech-savvy and understand the right architecture, and engineers need to grasp the target design and reasoning, since changes often involve reorganizing the codebase.

Organizational changes don’t have to impact the whole company and they can be applied on a smaller scale. Here’s a simple example from my experience.

We used to work on a product end-to-end and our area was defined by the product, not the architecture. Sounds nice, right?

However, we were backend developers, and since the product included front-end applications, we also had to develop and maintain the user-facing parts. We were never front-end experts, so we struggled a lot. We knew the product and its business specifics, but our tech gaps were a constant drag.

Eventually, we decided to hand it over to front-end experts. What a relief! Product Managers got what they wanted on time, backend developers could focus on our strengths, and frontend developers had fun fixing our mistakes.

We thought everything was sorted, until later, when we all got together in one room, despite being geographically distributed, to talk about the product. During that session, we uncovered a few weird issues we hadn’t noticed before.

The key was sharing knowledge about how each part worked and how they worked together, which revealed bugs invisible when working in isolation. It was eye-opening, and I can’t overlook another benefit: building team spirit through shared activities and discoveries, which greatly improved our future collaboration.

Sit down and listen to other teams

So here’s the thing: Conway’s Law isn’t going away. No matter how hard you try, no matter how many architecture diagrams you draw, your system will always reflect how your teams communicate… or don’t.

But before you panic, remember the government office analogy: you’re knocking on doors because that’s how the organization is structured, not because doors are inherently evil. The same applies here. Yes, your architecture will mirror organizational boundaries, but it’s on you whether you knock or find a workaround.

Every time you sit in a room with people from another team and actually listen, every time you take the time to understand how the system really works, you’re actively shaping the architecture – whether you realize it or not.

The post Code Isn’t Slowing Your Project Down, Communication Is appeared first on ShiftMag.

At the Web Summit conference, Andrew Filev, CEO of Zencoder – a company that achieved a $2.25B exit – debunked that myth. He called it blind hustle, a mindset that destroys long-term innovation and sustainable growth.

For engineers and founders navigating fierce competition, Filev argues that success depends not on the number of hours worked but on the quality, focus, and sustainability of effort. He calls this approach the smart grind.

The toxic cult of 996

Filev highlights how overwork has become normalized, especially through the infamous “996” schedule, 9 AM to 9 PM, 6 days a week, a routine common in hyper-competitive tech markets.

This panic-driven culture often disguises itself as passion but ultimately stunts professional growth.

Creative output peaks only within a certain range; beyond that, productivity nosedives. Those extra hours often add little value and instead drain the energy needed for rest, reflection, and strategic thinking.

Many skilled engineers fall into what Filev calls the “over-engineer’s trap,” where they chase hours instead of impact. In doing so, they trade clear, strategic thinking for the illusion of productivity, creating overly complex solutions when simpler ones would suffice.

Even stepping away can feel difficult. Filev recalls taking vacations yet constantly feeling pulled back into work, a cycle that slowly erodes creativity. Innovation, he argues, depends on perspective – and perspective only comes when you truly disconnect.

The “smart grind” mindset

Instead of chasing blind hustle, Filev promotes the smart grind, which drives lasting, industry-defining success.

The myth of the “overnight success” fuels burnout. Filev explains that every transformative company, including his own, grew from years of consistent, intentional work. Real progress demands a sustainable pace, not a desperate sprint.

I’d rather work in a way that increases the law of probability that success finds me.

True success isn’t a lottery. It’s the outcome of steady, high-quality decisions that compound over time.

Think clearly and direct AI effectively!

Shift your focus from how long you work to what you work on and how you approach it.

Start by recognizing patterns, study market trends, and your team’s performance to make smarter, more informed choices.

Then, guide your direction by ensuring every hour of effort supports your long-term strategy instead of reacting to short-term, low-impact tasks.

Filev warns that AI could amplify the blind hustle mindset. As automation handles more tasks, the real advantage belongs to people who can think clearly and direct AI effectively. Burnout dulls that ability, leaving even talented teams ineffective as AI “bosses.”

The edge no longer comes from working longer, but from maintaining the mental clarity to make high-impact, strategic decisions. Filev’s message is simple:

The $2.25B exit didn’t come from sleepless nights at the office. It came from years of disciplined, well-rested, high-quality decisions. True innovation and lasting success come from sustainability, not sacrifice.

The post Zencoder CEO: Hustle Hype Didn’t Drive Our $2B Exit – Sustainable Work Did appeared first on ShiftMag.

Enter the Paladin – a brave soul with a new set of duties each sprint.

This role helps teams stay focused, move faster, and still tackle the things that usually fall through the cracks. Curious how it works? Let me share what we’ve learned in my team.

Meet the Paladin – defender of focus, slayer of tech debt

The Paladin is a dedicated team member with unique responsibilities each sprint – a hybrid between a sprint host and a support guardian.

This role runs alongside the sprint, not within its planned capacity, serving as the shield that protects the team from distractions, context switching, and chaos.

Duties of the Paladin:

1. Monitor team support and monitoring channels.
2. Provide immediate support and troubleshooting for reported problems.
3. Host all sprint-related ceremonies, such as daily standups, sprint reviews, and sprint planning.
4. Resolve tech debt and improvement tasks during support downtime.

The Paladin helps the team stay laser-focused on sprint goals while reducing distracting context switches. It speeds up response times for support, monitoring, and incident handling – all without impacting sprint or company objectives.

And a happy side effect? It frees up time to tackle tech debt and improvement tickets that would otherwise languish in the backlog.

What it looks like in action?

Our team has a dedicated Kanban board for tech debt and improvement tasks (including tasks with special labels and bugs). This allows us to prioritize items that the Paladin can tackle without affecting the team’s availability or deliverability.

Some examples of tasks the Paladin has successfully handled include migrating microservices to a new framework (.NET 6 to .NET 8), improving CI/CD pipelines, ensuring compliance with various ADRs, enhancing logging, and moving background logic to dedicated jobs.

Beyond task management, the Paladin also participates in PR reviews. This serves two purposes:

• Ensuring there are enough team members for quality reviews.
• Keeping the Paladin up to date with ongoing sprint tasks.

Additionally, having the Paladin facilitate sprint-related ceremonies indirectly strengthens soft skills while helping push sprint goals forward. Another indirect benefit is that the Paladin frees up time for tasks that often get sidelined in the normal team flow, such as improving documentation, support, and monitoring.

Do you need a Paladin?

The biggest value of the Paladin role is that it allows teams to focus their sprint time on delivering sprint and company goals without losing too much time to mundane tasks like support, monitoring, tech debt, and sprint ceremonies.

By having a dedicated team member each sprint to handle these responsibilities, we indirectly increase the value of the whole team and improve our ability to support future features. Of course, every team is different, and the challenges they face are unique, so this role can be used as a template to tailor the best experience for your own team.

The post Need Someone to Handle Support, Tech Debt, and Team Focus? Meet the Paladin appeared first on ShiftMag.

He drew a clear line through past transformations — User Experience (UX) reshaped digital products in the 1990s, and Developer Experience (DX) redefined platforms in the 2010s. Matt argues that AX drives the critical design frontier in the era of AI-driven development.

“Good DX doesn’t always mean good AX,” Matt said. Tools that feel intuitive for humans often frustrate AI agents. He urged builders to design platforms that deliver seamless human usability and strong agentic experience, allowing AI systems to interact, adapt, and create value without friction.

Redefining the Developer Population

Matt opened by challenging how we define a “developer.” He reminded the audience that the industry once dismissed frontend developers as “pseudo-developers,” only later to acknowledge them as essential builders of the modern web.

Similarly, he argued that today’s AI agents sit at the edge of legitimacy. With the right platforms and tooling, they could redefine development and bring billions more people into the fold.

Matt envisioned a future not limited to millions of professional software engineers but open to as many as three billion people — anyone with technical acumen and an internet connection — who could step into development through agents.

The opportunity is not just to grow the developer market, but to redefine what development means for the “next 100 million people coming online”.

Access, Context, and Tools: The Three Pillars of AX

Matt framed AX around three core challenges: access, context, and tools.

Access focuses on how easily agents can interact with a product. Traditional authentication models, like OAuth scopes, often block agents that need open-ended flexibility. Matt highlighted “anonymous flows” and sandboxed environments, which let agents experiment before locking in permissions.

Netlify, Neon, and Clerk provided clear examples of this pattern, granting limited access first and formalizing accounts only when necessary. Context ensures agents understand a product’s existence and how to use it effectively.

Matt spotlighted “context engineering,” where structured documentation — Markdown files, MCP servers, or custom .md rules — feeds LLMs the information they need to generate reliable output. He also suggested that search engine optimization could evolve into Generative AI Optimization, helping models surface and apply product knowledge more accurately.

Tools form the final pillar, shaping how agents act on information. Matt stressed that platforms must offer intuitive APIs, predictable interfaces, and robust debugging options so agents can perform reliably at scale.

For Matt, AX is not a feature or protocol but a discipline, much like UX. It requires constant observation, iteration, and empathy.

On the other hand, tools are the interfaces through which agents interact with products. Even well-designed CLIs and APIs can fail when faced with non-human users.

Matt showed how Netlify’s CLI, long celebrated for its developer experience, repeatedly tripped up an AI coding agent during deployment. He transformed the tool into an AX-ready platform by adding a single non-interactive command — useless for most humans but ideal for agents.

Standards and Ecosystem Shifts

A recurring theme in Matt’s lecture was the lack of standards around agentic experience (AX). He highlighted early frameworks like the Model Context Protocol (MCP) and lightweight conventions such as llms.txt as signals of the industry’s direction.

Matt warned against naively exposing entire APIs to agents. He urged developers to treat MCP like a user interface for LLMs, carefully designing the minimal tools and context agents need to succeed.

He contrasted Salesforce’s closed approach, which pushes proprietary agents while restricting integration, with HubSpot’s open strategy, which embraces MCP to give agents seamless access. The latter, Matt argued, shows how embracing AX can differentiate products in a fast-evolving ecosystem.

For Matt, AX isn’t just a feature or protocol — it’s a discipline, like UX. It demands constant observation, iteration, and empathy, not just for human end-users but also for the agents acting on their behalf. He suggested this shift could unlock enormous economic potential by serving existing professionals and bringing entirely new demographics into web development.

At Netlify, early investments in AX have already delivered results. Since launching these efforts a year ago, the company has seen a fivefold increase in daily signups and a sevenfold jump in paid conversions. Even more importantly, AX has empowered millions of new users with little or no coding background to become active builders on the platform.

A Call to Developers

As AI agents take on more tasks — writing, debugging, and deploying code — the barriers to entry for development are collapsing. Skills like algorithm design and CLI expertise may lose weight, while qualities such as product sense, empathy, and domain knowledge gain importance.

“This is an opportunity to invite so many more people into the room,” Matt said, highlighting use cases from HR teams designing surveys to marketers prototyping campaigns with AI agents.

The next generation of developers are coming, and it’s up to us to ensure the web is ready for them.

For developers, Matt delivered a clear message: just as UX and DX once drove competitive advantage, mastering agentic experience (AX) may soon decide which tools — and which companies — define the future of software.

Want to know what else was discussed at Infobip Shift at Zadar in 2025? Find out here!

The post Your Platform Might Already Be Incompatible With the Future appeared first on ShiftMag.

The survey shows GPT models dominate, with 82% of developers using them last year. Claude Sonnet is gaining ground too – especially among pros (45%) over beginners (30%). While many try “vibe coding,” 77% say it’s not part of their real workflow.

This gap between use and trust drove us to explore where LLMs truly help and where they can make a mess. To break it down, we put together a list of the top 5 good ways to use these AI tools, along with 5 situations where you should absolutely steer clear.

LLMs as superstars for these tasks

LLMs excel at practical, time-saving tasks – particularly those that are repetitive or well-structured. From generating boilerplate code and debugging to drafting docs or translating languages, they act as tireless productivity boosters. They’re also handy learning companions, offering explanations and exercises on demand.

Next, we’ll highlight where LLMs truly add value in everyday development.

1. Boilerplate and setup

We all know that LLMs solve repetitive tasks excellently. That happens because they can automatically generate a project template, initialization code, config files, or standard classes and functions in just one second.

For example, ChatGPT needs only one second to hit the usual patterns and syntax on the first attempt. They are most effective for generating base code, which the developer then reviews, shapes, and adapts.

2. Debugging assistance

LLMs always step in as reliable assistants when you need “another pair of eyes” to find a bug. They analyse code surprisingly well because they can spot logical gaps, propose fixes, and even explain why a function fails specific tests.

For example, you only need to insert an error message and ask, “What is wrong here?” – the model will suggest where the issue hides. Of course, always check suggestions through tests.

3. Documentation and comments

Writing documentation and comments often feels boring, but LLMs do it quickly and efficiently. They can generate docstrings, README sections, or comments based on code.

As one Reddit user says: “for simple tasks – like adding documentation or looking up syntax – I can get a near-instant solution.” So, in this case, LLMs are excellent for filling documentation gaps or creating explanations for colleagues who need help.

4. Code conversion

Porting code between languages or frameworks often feels exhausting. ChatGPT can help translate a Python function into Java or C# code. It works best with popular languages and standard patterns.

Naturally, you always need to validate the translated code and adapt idioms or APIs, but as a first step, it can significantly speed up the process.

5. Learning aid

Naturally, the thing we all use LLMs for: quick learning! They can serve as an educator available 24/7. They can explain concepts, clarify syntax, or offer exercises.

For example, you can ask ChatGPT: “What does this error mean?” or “Give me a recursion exercise for beginners.” The model will generate explanations and examples that align with your knowledge level.

Again, this proves very useful for self-study, with the note that you must verify every claim.

Where LLMs consistently fail

LLMs aren’t perfect. They can speed up development, but real-world tasks reveal their limits – from subtle bugs and insecure code to flawed designs and privacy risks. Over-reliance can even weaken core developer skills.

Next, we highlight where LLMs often fall short and the risks teams should watch for.

1. Risks in production code

Do not assume that AI code works for production. Even when it looks correct, it can contain hidden bugs or incomplete logic.

Experienced developers warn: always “double-check your code, run the appropriate tests, and use your best logical judgement.” Also, keep in mind that models act non-deterministically—the same prompt can yield different results.

2. Security vulnerabilities

AI often suggests insecure patterns. Research shows that about 40% of Copilot suggestions contained exploitable vulnerabilities.

ChatGPT can generate similar problems (e.g., SQL injection, weak encryption). Best practice dictates treating every AI-generated code as insecure until you check it with static analysis and a code review process.

3. Limitations in system design

LLMs do not suit the creation of architecture or complex systems. They can assemble a diagram or deployment script, but lack an understanding of context and trade-off decisions.

They can also suggest outdated libraries or naive choices. Use them only for smaller parts of the design you control and verify.

4. Data privacy issues

Stay careful with what you send to LLM services. Prompts often get logged and stored. That means your code may end up in a future training set.

Experts warn that uploading source code into a public model can “inadvertently disclose vital trade secrets.” Never input confidential data (passwords, internal comments, user information) into public models.

5. Skill degradation

Excessive reliance on LLMs can cause developers to neglect fundamental skills. Junior developers skip learning basics, while seniors lose the habit of diving deep into problems.

As analyses warn, “skills atrophy” is a real risk. Over time, teams may code quickly but stay underprepared for unexpected issues. Best practice suggests using LLMs as assistants and tutors, not as crutches.

LLMs serve as helpful assistants but never as infallible ones. Treat them best “like Stack Overflow snippets: useful, but unreliable.”

Take advantage of the “yay” areas to accelerate routine tasks, but always keep the “nay” risks in mind. With careful use and human oversight, LLMs can help you increase productivity without breaking your codebase.

The post 5 Times LLMs Help You Code… and 5 Times They Fail appeared first on ShiftMag.

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.

Procrastination – the act of delaying or postponing something – has been studied in academic settings, but never in the context of software engineers. What do developers procrastinate? How does it affect their work?

Researchers from the University of Southern California, Department of Computer Science, conducted an interview study with developers across different industries and levels of seniority to understand the process of procrastination.

They’ve found that procrastination has positive and negative effects, as well as factors that trigger it, as perceived by participants.

Getting That Deadline High

Among the 14 negative effects are rushed coding, accumulation of technical debt, poor code quality, and last-minute stress, which can lead to reduced team trust when tasks consistently run late. All of the participants also cited emotional distress as a negative effect of procrastination.

Yet, 80% of developers reported at least one positive effect, such as improved mood, creativity, or near-deadline efficiency. Racing against a deadline also boosts focus and productivity.

Why do Engineers Procrastinate

The study distills procrastination triggers into three buckets:

1. Task-related factors such as vague expectations, unpredictable scope, or excessive cognitive load.
2. Personal factors, including low energy, stress, impostor syndrome, or low intrinsic motivation.
3. External factors like shifting priorities, unclear ownership, dependency on others, or organizational friction.

The study highlights 19 practical techniques for mitigating procrastination. These include building awareness of patterns, structured planning, micro‑tasking, pairing or peer support, and task framing to raise engagement.

Struggling with procrastination? Read some first-hand advice from a fellow engineer:

The post Why Do Software Engineers Procrastinate? appeared first on ShiftMag.

That got us thinking: what if an AI assistant could make learning more interactive, personal, and fun?

In this article, I’ll share how the AI Base Engineering team at Infobip – of which I’m a member – built a prototype AI tutor for biology. I’ll explain why we chose this subject, how we tested it, and the key lessons we learned along the way.

Spoiler: it’s not about replacing teachers – it’s about helping students learn in new and meaningful ways.

So… Why an AI study buddy?

Our challenge was simple but ambitious: make textbook content more accessible, engaging, and curiosity-driven.

Biology was the perfect testing ground: it’s well-structured, widely taught, and available in digital form. For our prototype, we used official Croatian school textbooks, spanning 7th grade through the second year of high school.

The goal? To support every kind of learner – those falling behind, those racing ahead, and everyone in between. The AI assistant acts like a responsive study buddy: highlighting overlooked facts, answering questions from verified sources, and adapting explanations to each student’s level of understanding.

And just to be clear: this was never about replacing teachers. Our vision is to help students learn and engage more deeply, while keeping teachers central to the process.

Our AI tutor explains, not just defines

To build a reliable assistant, we grounded everything in the curriculum. Using trusted digital textbook content, we crafted precise prompts to guide the assistant toward clarity, simplicity, and curiosity-driven learning.

One of our favorite tactics? The assistant doesn’t just dump definitions. Instead, it might explain photosynthesis like this:

Plants are like little factories; sunlight turns water and air into sugar. Do you want to know more about how that happens?

We also trained the assistant to ask questions back: A Socratic approach that encourages critical thinking. It doesn’t just answer; it engages.

We taught our AI to talk the talk

Designing the assistant’s tone in Croatian was no small feat. The language includes formality distinctions and gendered grammar, so we had to strike a delicate balance: friendly, but not too casual; professional, but not robotic.

We also taught it to respond to tricky situations – from inappropriate language to sensitive topics like human reproduction – with calm professionalism and respect. When students pushed boundaries, the assistant didn’t scold; it simply guided them back toward curious, respectful inquiry.

To meet students where they already are, we brought the assistant to WhatsApp. And with Infobip’s Voice API, they can ask questions or get answers as voice messages. The result? A judgment-free, always-available biology buddy – just a tap (or a voice note) away.

When AI gets creative (and sometimes WRONG)

Let’s address the elephant in the room: the hallucinations.

Like all LLMs, ours sometimes got a bit too creative. Ask for an example? It might cheerfully invent one from thin air. Say hi? You could end up with a TED Talk on evolution. Ask who’s stronger, a lion or a wolf? You might get a philosophical journey through mammal diets, fur types, and migration patterns.

These hallucinations were part of the process – and even charming at times – but accuracy is essential in education. We improved prompts and curated the assistant’s knowledge base more tightly to fix this. Hallucinations might not disappear entirely, but we learned how to keep the assistant on track.

After all, when a student asks about mitosis, they shouldn’t end up hearing about whales.

Test drive, phase by phase: first staff, then students!

Phase 1: Internal Pilot

Our first testers were internal education and tech staff. They knew what to look for and how to break things. Their feedback helped iron out glitches and set a strong foundation.

Phase 2: Teacher Feedback

Next, we brought in real teachers. They tested the assistant against real student questions. Could it explain clearly? Did it stay age-appropriate? Was it pedagogically sound?

The feedback surprised us in a good way. Teachers appreciated the assistant’s thoroughness. When students asked if they could use the assistant during tests, it responded with integrity:

That wouldn’t be correct. But I can help you prepare by giving you 10 questions and evaluating your answers.

Not hardcoded, just good training.

Phase 3: Student Trials

Finally, students used the assistant in a classroom setting. They used it like a study buddy, asking it to quiz them or explain tricky terms. The results? Excited engagement.

They loved the follow-up questions that kept the conversation going. They liked the longer answers.

The only complaint? Voice messages sounded robotic! And yes, it sometimes reads formatting symbols out loud (literally saying “star” instead of bolding).

How AI Can Help Students Learn and Engage

Here’s what we saw, again and again: AI can help students learn and engage by providing:

• Instant help – Students can ask questions privately, anytime, without fear of judgment.
  
• Personalized explanations – If one metaphor doesn’t work, the assistant tries another.
  
• Active learning – With questions like “Can you think of household acids?”, the assistant nudges students to connect concepts to real life.
  
• A safe space – For shy students, the AI is a no-pressure place to be curious.

Notably, the assistant always encouraged students to verify with their teacher and the textbook. Teachers remain the core of the classroom, and the assistant is just that, an assistant.

Lessons Learned and the Road Ahead

This project started with a simple goal: help students get unstuck. Along the way, it became a deeper exploration of what AI can do in education. What we discovered is this: with careful design and clear boundaries, AI can enhance learning and engagement – complementing, not replacing, human teaching.

Success comes down to the details: prompt phrasing, tone, voice, UX, and content quality. Teacher and student feedback proved invaluable, showing how much students respond when learning feels personal, responsive, and judgment-free.

Next steps? We’ll improve voice UX, expand to new subjects, and keep gathering feedback to make the experience even better.

And to educators and tech innovators alike: building an AI assistant isn’t just a coding exercise, it’s a collaborative effort between tech and teaching. Done right, it becomes more than a tool – it becomes a trusted companion in the learning journey.

And if one more student walks away thinking, “Hey, biology is kinda cool,” then we know we’ve done something right.

The post How We Built an AI Learning Assistant – Approved by Teachers appeared first on ShiftMag.

How often do developers create pull requests (PRs) just because the process requires it, without thinking about their actual value?
And how frequently does your PR sit unreviewed for days because all potential reviewers are busy?
On the other hand, some might want to skip this part of the process:

“I’ve only changed one line of code. Can I push it to master?”

What could go wrong?

• A critical bug in production.
• Sensitive data is exposed.
• The team has no visibility into what changed.
• Developers experience burnout due to inefficient and frustrating review cycles.

Code reviews are essential, but if not structured well, they become a bottleneck instead of a productivity tool.

This article explores common code review challenges and practical solutions to make the process faster, more effective, and enjoyable for everyone.

Goals of the Code Review

Code reviews are not just about catching bugs. Well-structured code review process should:

• Ensure code quality – Reviewers provide valuable insights to improve the code.
• Maintain consistency – Code style, patterns, and best practices remain aligned across the team.
• Enable knowledge sharing – Developers learn from each other through reviews.
• Offer a fresh perspective – The author may miss issues another developer can spot.

However, without a clear structure, these benefits are often lost.

Code Review Problems and Possible Fixes

Reviews are too slow, or “no time for code review”

Example scenario: A developer submits a PR on Monday. By Friday, it’s still waiting for a review.

Can someone review my PR?

Yeah, I’ll get to it soon…[everyone is busy with urgent stuff]

By the time someone finally looks at it, the author has lost context, making it harder to address feedback efficiently.

How to fix it:

• Dedicated time slot for reviews—Some teams implement a “Morning review hour,” where engineers spend the first 30 minutes of their day reviewing PRs before diving into deep work. This helps to avoid delays caused by context-switching.
  
• Use team agreements to align expectations around how quickly PRs should be reviewed; for example – “PRs should be reviewed within 24 hours”
  
• Set up well-defined statuses (e.g., “ready for review,” “needs work,” “blocked,” “ready for merge”) that reflect progress.
  
• Align on the code style so there will be no disputes around the code style preferences.
  
• Dedicated Slack channel for the PRs that need attention; automatic reminders set up for PRs that are waiting too long.
  
• Improve commenting techniques to make the process faster
  • Use prefixes in comments to streamline discussions so the creator knows if it is a blocker or suggestion.
  • Write what exactly you took a look at if not everything was reviewed.
    
• Introduce a code review checklist, which could include the following steps:
  • Is the code well-structured and easy to understand?
  • Are functions and classes small and modular?
  • Are there any potential race conditions or concurrency issues?
  • Does the code introduce unnecessary dependencies?
  • Are API keys, credentials, or sensitive data hardcoded?
    
• Ensure PRs have clear descriptions. The description should outline what changed, why it changed, and any areas of focus for the review. It may also contain any additional information that could help reviewers.
  
  • Title
  • What changed?
  • Why?
  • What to check?
  • How is it tested?
  • Potential risks & mitigations

• Provide clear documentation in the code, which helps to understand the logic behind the changes.
  
• Separate logical parts into different commits in the PRs and make the proper message; this could help the reviewer to navigate through changes.

While speeding up PR reviews is crucial, it’s only part of the solution. Many bottlenecks also come from a lack of automation and PRs that are too large to review efficiently.

Large, complex PRs are intimidating and hard to review effectively

Example scenario: A developer created PR with 1000+ lines of code changed.

The title? – “Refactoring + feature + bug fixes + cleanup + magic”

As a result, no one wanted to review it. When someone finally looks at it, they request dozens of changes, and the cycle repeats.

How to fix it:

• Limit PR size—Teams could use a “Max x lines per PR” rule (e.g., 200 – 400 lines). Research suggests that the optimal code review rate is between 200 and 400 lines per hour. Productivity and defect detection ability significantly drop after an hour of continuous review.

source: smartbear.com

• Break changes into multiple PRs:
  PR 1 – Refactoring.
  PR 2 – Adding the feature.
  PR 3 – Fixing UI issues.
  
• For large changes, schedule a “Team Code Review” (TCR) meeting where the author explains the key changes before submission. This will make it easier to actually review the code.

No volunteers to review the code

Example scenario: In an engineering team, only the tech lead consistently reviewed PRs.

The rest of the team hesitated, thinking: “He knows the codebase best, so I’ll let him handle it.”

Over time, this became a bottleneck—the lead was overwhelmed, reviews slowed, and the team was not aligned on the code base.

How to fix it:

• Implement review rotations. Every team member will participate in reviews. PRs will be distributed better, preventing burnout. Junior developers will improve their skills by taking ownership. The tech leaders will be freed up for other strategic tasks instead of only reviewing.
  
• Assign a “review duty” each sprint – One engineer is responsible for making sure reviews happen.
  
• Encourage team engagement – Tracking who is the most active commenter on PRs, which PRs took longer than others can highlight imbalances.
  
• Limit code review sessions to a maximum of 60 minutes per day. As mentioned earlier, productivity and defect detection ability drop significantly after an hour of continuous review.
  
• Provide the team with information about the goals of the Code Review practice and ensure alignment based on the team’s agreement on the topic.
  
• Establish a positive code review culture where feedback is constructive and good practices are recognized (be objective, not personal; explain why; offer alternatives; encourage collaboration)
  
   “You forgot to handle edge cases.”
   “I see the main logic is solid. Just wondering, how does this handle cases where the input is empty? Maybe we could add a test for that?”

Lack of automation

Example: Review comments are filled with:

Fix indentation.
This function name should be camelCase.
Did you write tests for this?

Instead of focusing on logic and architecture, reviewers spend time pointing out issues that could be checked automatically.

How to fix it:

• Run automated tests in CI/CD—PRs should not be allowed to merge if tests fail. Measuring test coverage could also be done; however, it serves as information rather than a metric that guarantees the functionality is well-tested.
  
• Automate formatting – Use tools like Prettier and ESLint to apply consistent styling automatically.
  
• Use static analysis tools that can catch security vulnerabilities, and code smells (e. g. SonarQube).
  
• Tracking PR review patterns and efficiency metrics could help identify patterns that could be improved, such as when only one person reviews PRs or when some PRs are reviewed longer than others, which PRs are getting stuck.

When Code Reviews May Not Be Necessary

Example scenario: A high-traffic platform experiences a critical production outage. The team has an urgent fix ready, but if they wait for a formal review, millions of dollars could be lost in just a few hours.

Instead of waiting, they applied an emergency fix immediately and agreed to do the review afterward, ensuring the long-term stability of the codebase.

Not every change needs a formal review, considering that automated checks were done. Teams can define exceptions for situations like:

• Emergency Fixes: Allow expedited processes for critical bugs, however completely skipping reviews for even emergency fixes can be risky. One approach is ‘post-mortem reviews’ – after deployment, the fix is reviewed retrospectively.
  
• Pair Programming: Real-time collaboration to replace code reviews could be applicable in some cases, rotate pairs regularly to spread knowledge across the team.
  
• Isolated Changes: You could have in your team agreement that reviews are not necessary for small, well-contained updates if appropriate automated checks are in place.

Building an Efficient Code Review Process

By solving the problems mentioned above, teams can transform PRs from a bottleneck into a productive workflow.

The code review process should work for the team, not against it.

Code reviews aren’t just about catching bugs – they’re an opportunity to foster collaboration, maintain code quality, and strengthen team trust.

To make them truly effective:

• Set clear expectations – Define review timelines and responsibilities.
• Make PRs easy to review – Keep them small and well-documented.
• Automate what you can – Use automation tools to eliminate repetitive tasks.
• Encourage collaboration – Reviews should be a learning opportunity, not just a process step.

Before submitting your next PR, ask yourself:

“How can I make this review easier for my teammates? How can we improve our code review practices today?”

By taking small, deliberate steps to streamline reviews, advocating for process improvement, and starting to make small improvements, you’ll create a process that supports your team and your product—not one that holds them back.

The post Code Review: From Bottleneck to Productivity Booster appeared first on ShiftMag.