Forem: Shift Mag

Things ancient Romans taught me about software development

Shift Mag — Tue, 13 May 2025 12:28:48 +0000

For more content like this subscribe to the ShiftMag newsletter.

Si vis pacem, para bellum

If you want peace, prepare for war. In other words, if you wish to handle traffic spikes, stress test the service. If it can handle twice the expected traffic, it will handle the expected traffic. A similar point was expressed by Kentus Becchus , who famously wrote Scribe probationes donec timor in taedium mutetur.

Aequam memento rebus in arduis servare mentem

Remember to maintain a calm mind while doing difficult tasks. The natural response to a production outage is panicking. DON’T PANIC. Troubleshooting production issues is just an ordinary task with the highest priority.

Mens sana in corpore sano

A healthy mind in a healthy body. Software development involves a lot of thinking, but it also involves a lot of sitting, which is not a particularly healthy activity. To keep the mind fresh and sharp, sleep and physical activity are paramount, as Vladus Mihalcaeus has put it Somnus octo horarum optimus emendator est.

Divide et impera

Divide and conquer. Apart from being a well-known algorithm design paradigm, it is a sound piece of advice: when faced with a complex task that takes a lot of time, divide it into a set of smaller tasks and handle those one at a time.

Ad praesens ova cras pullis sunt meliora

A bird in the hand is worth two in the bush. First implement the basic functionality , show it to the user, ask for feedback and iterate. The same idea is expressed in the old dictum from the Manifestum which teaches us to prefer working software over a mountain of requirements specifications.

Bene vixit, bene qui latuit

He who remained hidden lived well. Although some malicious hackers may draw inspiration from this one, it is also inspiring to infrastructure engineers: if you break something, it will not go unnoticed.

Discere faciendo

Learn by doing. The mastery of software engineering cannot be attained only by speculative thought, reasoning from first principles, or by learning the sacred texts by heart, to learn how to build software it is necessary, but not sufficient, to build it.

Panem et circenes

Bread and circuses. A great deal of software engineering job is maintenance; it is necessary but not appreciated enough. To silence the murmurs, you need to show some impressive dashboard, shiny UI, or AI-related feature to management from time to time.

Cessante causa, cessante effectus

When the cause ceases, the effect ceases. Unless you know the root cause of an incident , you cannot consider it resolved. Rebooting or scaling may resolve the issue temporarily, but this is just buying time to fix the real problem.

Verba volant, littera scripta manent

Spoken words fly away, written ones remain. Agreements from meetings need to be written down in meeting notes, architectural decisions need to be documented, tasks need to have descriptions, when possible, agreements need to be expressed in code as automated checks. You will forget things!

Periculum in mora

Danger in delay. Integrate code changes to main branch often and deploy often. The more you wait the harder it is to integrate the change and the riskier it is to deploy it.

Historia est magistra vitae

History the teacher of life. As Patruus Bobus points out majority of programmers are not very experienced, however there are those who have been shipping software for decades, and there is much we can learn from them. *Study their advice. *

Non omnia possumus omnes

We can’t all do everything. It is easier to ship software in a ** cross-functiona**** l team made up of **people with different skill sets and roles.

Omnium enim rerum principia parva sunt

The beginnings of all things are small. Big systems evolve from small systems. Create the simplest thing that works well and build on top of that. This was succinctly expressed by Johannes Gallus who wrote Systema complexum quod operatur, ex systemate simplici quod operavit ortum esse inventur.

Pacta sunt servanda

Agreements must be kept. Take care not to break backwards compatibility. Take great care when designing APIs; if it exposes some functionality you did not intend to expose, do not whine when someone starts to use it.

Vinum bonum, pax in domum

Good wine, peace in the house. Since building software is a group activity , it helps if members of the group can get along with each other. Occasional team building activity helps to foster a friendly atmosphere.

The post Things ancient Romans taught me about software development appeared first on ShiftMag.

Devs and DBAs can’t find peace, but could they call a truce?

Shift Mag — Fri, 18 Apr 2025 13:12:40 +0000

For more content like this subscribe to the ShiftMag newsletter.

Picture this scenario: You’ve just joined a new tech company, excited to start onboarding and dive into your first projects. But soon, it hits you – the tension.

Developers gripe about sluggish and obstructive DBAs, while Database Administrators grumble and murmur about the constant stream of poorly optimized queries, chaotic code, and last-minute demands from developers.

Did you stumble upon a toxic workplace? Not exactly. It’s the age-old clash that’s been brewing for decades between two ‘tribes’ : those who want to build quickly and those who safeguard stability.

So, do DBAs play the role of protectors, or are devs just a tad bit spoiled?

How did we get here?

The friction comes from a classic disconnect: speed vs. stability.

Developers are eager to ship features as fast as they can (preferably yesterday), often under pressure from clients, management, or some other deadline-driven force, while DBAs are focused on ensuring the database doesn’t crash tomorrow.

When these priorities clash, chaos is inevitable – and I know this firsthand because I’ve been on both sides.

Let’s take a closer look at it from a developer’s angle

‘** We need to speed up our delivery!’**

The main argument is that developers often work under tight deadlines. To them, a database is just a tool – the simpler, the better. Why involve DBAs early if it slows down prototyping?

There’s also a prevailing ‘good enough for now’ mentality, where getting a working prototype is the priority.

‘** Setting up new databases takes ages *.* ’**

Waiting for approvals, scheme checks, or infrastructure setups feels like watching paint dry.

‘** Getting DBAs involved can feel like pulling teeth ***.’*

When DBAs push back on quick fixes or demand documentation, developers see red tape rather than guardianship.

Now, let’s dive into the DBA’s side of the story

‘We’re called in too late!’

DBAs often inherit poorly designed schemas or performance nightmares. Fixing a burning database at 2 a.m. is never fun, especially when you don’t know anything about it or where to begin.

‘Devs don’t listen.’

Recommendations about indexing, query optimization, or security often fall on deaf ears – until an outage happens. No matter how many times you share documentation, hold knowledge-sharing sessions, or discuss the topic, it sometimes feels like no one listens.

‘We’re the unsung janitors.’

While devs chase innovation, DBAs clean up the mess. Their priorities – backups, scalability, and compliance – may not be glamorous, but they’re non-negotiable.

If a company wants to make it in the worldwide market, it needs to be compliant with numerous regulations. And that is just the beginning – data needs to be secured , and data leaks and privacy concerns aren’t fun for anyone. We need backups and replication set up for disaster recovery, satisfy numerous architecture decision records, and all that complicates the process. It will never be as simple and fast as just deploying a DB locally in Docker.

So, what do devs and DBAs really want?

DBAs just want preventative care – they’re like doctors urging you to eat your veggies, not just treating heart attacks.

On the other hand, devs need speed without fallout. They want to innovate without waking up to a dumpster fire.

But do devs really want to own databases?

Sure, devs can deploy their own database, but maintaining performance, security, and costs? That’s a full-time job – one many devs aren’t signing up for.

It may sound great at first, but once you deploy it, the database works fine – until it doesn’t. It’s just a matter of time before the first issues arise. And surely, devs would rather spend their time programming than maintaining and troubleshooting a database.

Think it can’t get worse? Well, say hello to AI

Enter AI and vector databases – tools promising lightning-fast analytics.

The number of new vector databases is skyrocketing, and devs want them all, each with a specific feature they need. But for DBAs, this is a nightmare. Integrating a new database is a slow and painful process , as all checks for security, compliance, and requirements need to be tested and approved. New database types (e.g., vector DBs for ML) often lack mature tooling or expertise. DBAs scramble to secure and scale them, while devs resent the learning curve.

So, who is right?

They both are, and at the same time, they both aren’t – much like the relationship between devs and clients.

Devs often complain about clients’ broad demands, tight deadlines, and constant changes. Sound familiar? The Dev vs DBA battle is similar: devs forget that, as clients of DBAs, they’re the ones pushing for deadlines and changes, just like clients do to them.

So, devs must make compromises with clients because the company’s revenue depends on it. However, I think DBAs tend to be ‘harder’ on their clients since they don’t face the same pressure of potentially losing business.

Is there hope for peace?

There isn’t – at least not a simple one.

But we can all work together to reduce tension and aim for some kind of truce. We need to be more understanding.

Devs should recognize that DBAs aren’t just complicating things for no reason and should involve them in the service architecture process. On the other hand, DBAs should view devs as clients , understand the need for compromise, and simplify the process of providing databases by using automation or internal tools whenever possible.

The post Devs and DBAs can’t find peace, but could they call a truce? appeared first on ShiftMag.

Code Review: From Bottleneck to Productivity Booster

Shift Mag — Thu, 20 Mar 2025 14:01:22 +0000

For more content like this subscribe to the ShiftMag newsletter.

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”
Se** t 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 reviewer to navigate through changes.

While speeding up PR reviews is crucial, it’s only part of the solution. Many bottlenecks also come from the lack of automation and PRs that are too large to review efficiently. The next sections will dive into how to fix them.

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—E very team member participates 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.

As an engineer, I’d rather be called stupid than stay silent

Shift Mag — Thu, 13 Mar 2025 14:16:39 +0000

For more content like this subscribe to the ShiftMag newsletter.

A new message pops up in our Incident Management channel – A part of one product feature isn’t working.

Adrenaline kicks in. The developers maintaining the affected feature jump into the thread, assessing the impact and what’s needed to fix it. All eyes are on the thread. Pressure mounts. The clock is ticking – we need to notify clients ASAP. We must understand the impact.

Finally, a message comes through:

Our photon phasers aren’t working due to an issue on our flux capacitor module in charge of stabilizing the ion flow!

At this point, you’re probably thinking – what on earth is the affected product, and what exactly does this company do?!

Am I missing something, or will I just look stupid if I don’t get what we’re talking about?

Feeling stupid? You are not alone!

Obviously, the example I gave is a gross exaggeration , but it’s a good representation of situations we encounter in our daily work.

Our photon phasers are just fine, and the ion flow is fully stable – mostly because they don’t exist in our company. Yet we often find ourselves in situations where someone describes a problem that sounds exactly like this: What would my colleagues think of me if I don’t have an answer to a question?

For those familiar with the technology, it’s clear what happened. They just shrug and say, ‘Oh well, it looks like our recent adjustments to the flux capacitor aren’t working in this scenario—we’ll fix it immediately.‘

And here I am, pondering the meaning of life of our photon phasers in the OMGaaS stack while our clients are still uninformed!

I’d love to ask the devs to translate this from Star Trek language to plain English, but I should probably already know that. If I ask, they’ll think I’m stupid.

What should I do?

I just have to deal with it, right?

I started my career at Infobip as a Customer Support Engineer, requiring a basic technical understanding of our platform and product stack.

It was a jack-of-all-trades role, often leading to ‘I don’t want to seem stupid by asking an obvious question’ moments, especially with developers, because I lacked the technical depth to fully understand our platform.

As time passed, I realized I couldn’t know everything, especially on a platform of this scale.

My knowledge and confidence grew ; I understood our product stack better and could troubleshoot basic issues, but I still wasn’t comfortable with the broader technical picture of our platform.

Though confident in troubleshooting business and client errors, I couldn’t grasp our technical infrastructure or handle the myriad of photon phasers in complex issues. I always felt stupid.

So, it was time to ask myself…

Am I actually this clueless?

I realized I had to step up my game and throw myself into the fire to turn dev-talk into something I could understand and explain. That way, I’d know for sure: either I really was stupid, or I just needed to change my approach.

So, the decision was made: I’m going to slay this hydra (or die trying). But how?

There are plenty of online courses for specific areas (cloud, networking, VMs, programming, etc.), but I didn’t have a set curriculum. If I could create one, it would mean I already had some knowledge. Meanwhile, I had access to a massive untapped well of knowledge…

Proud to be ‘stupid’!

My job involved daily interactions with developers on various matters, from notifying clients about platform incidents to troubleshooting isolated platform issues. This allowed me to ask questions.

It sounds like a groundbreaking revelation – after all this time, I could finally ask the ‘stupid’ questions! But in reality, the opportunity was always there; I was just too afraid of being perceived as stupid.

But now, the mask was off! I felt stupid anyway, so there was nothing to lose by asking those questions. Worst case scenario – I really am stupid. Might as well embrace it!

Hold on, I actually get this…

After tons of questions like ‘What does this actually mean?’ or ‘Could you explain this in simple terms?’, I began piecing together a new world of knowledge that helped me understand the complex world of tech.

Yet, I had only scratched the surface, but at least I knew I wasn’t stupid. Not because I’m some hidden genius tackling customer complaints but simply because I learned that when you dare to ask questions, people usually answer them.

Data centers became physical spaces with racks of hosts running VMs, powering the magic our clients experienced as a service or product. In this world, photon phasers transformed into VMs, and flux capacitors became hosts. From this simple sentence, you can see how this entire world looked to me:

What happens if you don’t let yourself feel vulnerable?

It’s time to ask: what happens if you let yourself seem stupid? Sure, no one wants to reveal their gaps in knowledge, but staying silent comes with its price.

My initial example was an incident for a reason – the consequences of staying silent are clear. If no one asks, ‘How is the photon phaser affecting clients?’ or ‘Can you explain this?’ we can’t connect the issue to client impact, identify the right people to resolve it, or see the bigger picture. This delays client notifications and prolongs the incident.

To be fair, incidents aren’t the time to ask for a programming course – we don’t need to know every line of code.

However, during an incident, everyone should know their role and exactly what information they need to do their part.

Of course, incidents aren’t the only time this happens. You might be working on a task and unsure how to meet expectations. After searching through endless documentation, you still can’t find the crucial info. Not asking coworkers could result in suboptimal work , and instead of seeming stupid, you’ll create problems for anyone relying on your output.

The same goes for meetings. Have you ever been in a situation where someone goes on about something no one understands, but everyone thinks, ‘It’s not my job to ask’ or ‘Someone else will ask what this is about’? Taking the risk to ask clears up confusion for everyone and moves the conversation toward a solution rather than leaving everyone in awkward silence.

Make asking questions core to your culture – and nurture it!

How can we avoid these consequences? While everyone can improve how they ask questions and handle insecurities, fostering a culture of curiosity isn’t easy. It depends on your team and organization, but there are ways to promote this mindset in any situation.

Be the one who asks the ‘stupid’ questions

Anyone can do this. By asking ‘stupid’ questions, you show there are no downsides and nothing to fear. It might not make everyone jump in right away, but over time, it builds confidence to speak up during uncertainty.

Shift from blame to education

A blameless culture helps people feel comfortable asking questions. Instead of blaming, educate – each question reveals areas for improvement, from onboarding to communication.

Trust the people around you

Putting yourself at risk of looking stupid also shows trust in your coworkers: you trust them not to judge you and to help in tough situations.

Asking questions can take you further in your career

Embracing the ‘stupidity’ mindset helped me accumulate the knowledge and experience needed to transition into a new role – Reliability Operations Engineer.

Our team, with limited technical knowledge, had to manage complex concepts and coordinate communication during critical times. While we embraced the ‘stupidity’ mindset individually, we now faced the challenge of adopting it as a team. But we had support from our manager and mentors, who led by example, and we felt confident in asking questions.

But, does it mean we could do literally whatever we wanted without consequences? No.

All actions have consequences, but asking questions should lead to shared knowledge and personal growth. As a ’70s US newspaper quote puts it: ‘There’s no such thing as a stupid question if it’s sincere. Better to ask and risk looking stupid than to make a foolish mistake.’

Give yourself permission to feel clueless

There’s nothing wrong with that. In everyday life, people are comfortable asking questions without fearing consequences – so why should work be any different? No one knows everything, meaning everyone’s ‘stupid’ at some level.

Remember, asking questions helps you accumulate knowledge, turning unknowns into understanding while also building self-confidence. On an organizational level, it fosters better knowledge sharing and collaboration.

Plus, asking a ‘stupid’ question won’t get you fired (unless it will, blink twice if you need help).

So, next time you face photon phasers, ask yourself: would you rather be stupid or silent?

The post As an engineer, I’d rather be called stupid than stay silent appeared first on ShiftMag.

How to build a palace: Building in iterations is not the same as postponing quality

Shift Mag — Thu, 06 Mar 2025 16:52:57 +0000

For more content like this subscribe to the ShiftMag newsletter.

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 dilemma of quality versus speed is false

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

How to turn peak season chaos into a developer’s success story

Shift Mag — Wed, 26 Feb 2025 13:11:23 +0000

For more content like this subscribe to the ShiftMag newsletter.

When high-demand periods hit, our clients inundate us with millions of messages , creating both objective and subjective stress.

On the objective side, the SMS processes we manage are vital to the company’s success , directly impacting revenue during critical moments. Infobip is a global B2B communication platform, so much of the communication from brands to their clients flows through us.

As you can imagine, the number of marketing SMS messages can skyrocket during promotional campaigns, holiday seasons, and product launches – not just on Black Friday. Handling tens of thousands of requests per second is no small feat.

Let’s explore how systematizing analysis, planning, and testing has eased the process – during peak times and throughout the year.

Expect the unexpected!

Perhaps it sounds cliché, but there’s a lot of truth to that phrase. If you don’t anticipate possible scenarios that could impact your system, many things will catch you off guard.

The goal is to reduce these surprises to a manageable level.

We should all be familiar with our systems’ core functionalities and main building blocks. These are typically described through happy path scenarios, which we test and monitor. While this is a good starting point, real stress doesn’t come from happy paths—it comes from the problems and failures that arise when things go wrong.

This is especially true for large-scale live products like ours, where maintaining top-tier availability and reliability is crucial. Managing risk means identifying the critical components in our application machinery, analyzing the impact of their failure, and determining how quickly we can recover or replace them.

‘We need to think about the unexpected’ doesn’t mean we should anticipate a billion different problems. Instead, we should focus on groups of issues that could impact our critical processes – like network outages, database problems, or downstream service failures.

This approach helps us create a matrix of processes, potential issues, and their impact.

Now that we know what we’re protecting and what we’re protecting against, we should develop plans for these scenarios and establish fallback solutions. This turns our initial uncertainty and fears into a sense of safety and confidence, even in situations beyond our control.

An important step in this process is to quantify everything. By making problems measurable, we can more easily automate both alerts and recovery processes.

Real-life problems for SMS

We identified that our crucial processes and properties include reliable message delivery, high throughput, and low latency.

High throughput is managed with an architecture that supports independent operation across nodes , allowing seamless scaling. Traffic peaks are handled through careful analysis and forecasting, ensuring adequate resources are in place.

We adopted a reactive programming approach to effectively address throughput and latency issues. This approach improves system responsiveness and scalability by efficiently handling asynchronous data streams.

Reliable message delivery is essential.

However, we identified several issues that could compromise this reliability. As mentioned earlier, we did not attempt to address every potential issue but instead focused on the most critical problems , specifically the inability to send messages to the core processing system.

To mitigate these issues, we implemented persistent storage with retry mechanisms and established comprehensive monitoring to ensure prompt problem detection and resolution.

Rely on tests, not assumptions

Assumptions can catch you off guard, especially when the system – and you – are pushed to the limit. If something seems to work but you’re unsure why, don’t rely on coincidences. Instead, address any uncertainties, assumptions, or potential coincidences by testing them while you still have time.

We use a suite of tests to validate the application’s functionalities through unit and integration testing, providing a solid foundation. However, since the application operates within a larger ecosystem, many challenges stem from its interactions with other systems.

End-to-end tests developed by our team can be executed as needed, which is highly beneficial. However, Black Friday brings significantly higher traffic and system stress. To prepare, we conduct intensive load testing well in advance.

This testing brings together people from various sectors and applications , resulting in valuable insights that may not be obvious in daily operations. Much like frogs in gradually heated water fail to notice the danger, our applications can experience gradual performance degradation as they are built piece by piece. These issues often only surface during load testing.

Expectations continue to rise each year , driven by an increasing number of clients and higher system demands. One such challenge arose with message throughput: last year, expectations surged by 50%, and system performance dipped slightly due to various hardware and software changes. However, through timely load testing, we identified and resolved all issues, ensuring clients experienced seamless performance.

Real-life bottlenecks for SMS

We encountered a limitation in our storage solution that impacted performance during Black Friday. After research and testing, we successfully optimized the data flow logic to enhance efficiency.

We leveraged in-memory solutions more effectively, while the previously primary storage was now used only as a fallback. This change was logical, but altering the flow could introduce the risk of unexpected problems.

What was crucial in this process was our confidence in the testing we performed , including unit, integration, end-to-end, and load tests. This thorough testing ensured that we could make the change with assurance.

Work once, benefit many times

Don’t discard your tests and the effort behind them, just as you wouldn’t throw away your main code. Special load tests designed for Black Friday scenarios are stored as projects in our repositories and can be run as customizable Jenkins jobs. Load test servers can be created on demand, allowing us to run automated tests whenever needed on the data centers of our choice.

Organize the team with interchangeable roles

The team was maintaining a strong and reliable system, but at that time, it was mostly composed of relatively new employees.

By relying on one another and sharing knowledge , we built a flexible team with interchangeable roles. This reduced stress, enhanced collaboration, and allowed us to divide tasks, ensuring no one became overwhelmed.

Continuous testing brings continuous confidence

Think of it like this: ‘It’s easier to do one pushup a day than to try and do 365 all at once.’ Similarly, continuous monitoring throughout the year reduces stress by keeping our system in shape over time. Rather than trying to boost performance after a year of development, regular checks and tests ensure steady progress.

By testing every new feature as it’s implemented and conducting daily or ad-hoc load tests , we prevent performance bottlenecks from piling up. This approach allows for continuous development and avoids lengthy code freezes before major events.

Consistency in testing and monitoring transforms uncertainty into confidence, keeping systems resilient and the team prepared to handle future needs.

The post How to turn peak season chaos into a developer’s success story appeared first on ShiftMag.

Talk to your colleagues over pull requests, not Jira tickets

Shift Mag — Fri, 21 Feb 2025 14:31:15 +0000

For more content like this subscribe to the ShiftMag newsletter.

It will be a bumpy road, but it’ll be worth it in the end.

The Status Quo

How do we approach inter-team projects today? At Infobip, teams own their services. Sure, they implement tasks, but they also deploy the code, debug it, upgrade dependencies, etc. On the other hand, stakeholders open Jira tickets. Then, there are product owners in between, prioritizing those tasks. This is, for better or for worse, not a story about POs.

This is about you, a fellow developer with a particular need. Anyway, you are a developer and need a certain feature implemented in another team’s service. You explain your need, maybe even propose a solution. And then you wait.

The waiting game is a long one, indeed. You may need to talk to PO (look at them popping up again) and advocate for the importance of your feature. They are likely to school you for proposing a technical solution in your Jira ticket. It is less likely that they will turn the backlog upside down to prioritize your ticket.

That’s the core of the conflict: though the proposed feature is a top priority for you, it is not for the product in general. With the Jira ticket approach, the product team must work to implement the feature.

Considering all that, your feature is more likely to land in production if you open a pull request. Bite the bullet and do the work. Don’t wait for the team to abandon their priorities in favor of your own.

You take a leap… You hit a wall.

OK, so you decide to go for it. You open a PR. It might be a small one at first. You resolved some compatibility that was interfering with your own work. *You fixed a bug forcing you to do some error-handling gymnastics on your side of an interface. * This feels good! You may mention it on your next daily standup, and your team cheers you on (true story).

Encouraged by this newfound power to scratch your own itch, you go further: you open bigger PRs, and you contribute to more services. When breaking down your own tasks, you think about where the implementation fits best, not constrained to your own services.

*This is also where you hit a couple of walls. * You encounter projects with no tests or coded in unfamiliar languages. You waste time trying to build projects and hunting for versions of build tools deprecated half a decade ago. You fall into unfathomable depths of eldritch horror that some, apparently, accept as production-worthy code.

One day, after pouring all that time (sweat and tears) into a pull request, it gets rejecte d. And you lose it, flip the table, and all that. Who in their right mind would reject all this free work you are offering them? Why doesn’t the team appreciate that you spent time implementing a feature on their service so they don’t have to?

The many hurdles to jump

Take a breath. It’s fine. Yes, this approach has its drawbacks. Let’s see if we can make it easier. The first thing you need to realize is that your pull request is not “free” for the product team.

The reviewer needs to put in the effort to review the PR. Reviewing a PR from someone unfamiliar with the team’s coding standards and practices will take more time. This is one thing we can all improve on: Teams can document and codify their standards. Amend the README with their working agreement, codify stuff like linting, and automate it with githooks.

On the other hand, as a contributor, it’s up to you to ** conform to the project you are contributing to.** Refrain from barging in with your favorite code formatting. Try to blend your code in instead.

OK, so you accept the awful line breaks and adopt tabs instead of spaces. Can your PR be merged now? Well, no. There’s the bigger picture, the project’s architecture, to consider. You aren’t as familiar with the codebase as its owners. They may want this feature implemented in another place. Or they may prefer you to use a different approach. And this, too, can be preempted. The team could have an ARCHITECTURE file with their project detailing this in advance. And you could have checked it going in.

Keep in mind: It’s not free work

So you conform to the project architecture. Can you merge the PR now? Perhaps. You see, PR is not, in fact, “free work,” even if you adhere to all the standards.

What happens with the code after it’s merged? Think back to modus operandi; it’s the team who owns the service. They maintain it: they need to ensure that all dependencies are up to date. That includes the cutting-edge library you just added. They troubleshoot and debug it; ** they get called in the middle of the night if something breaks**.

That includes that hard-to-read but super-fast code you came up with. And they will now start receiving future Jira tickets for expanding this feature you just implemented. Doesn’t sound like such a good deal anymore, right?

In the end, ** it comes down to the transfer of ownership**. A pull request is a point at which you, as the author of the code, need to convince the team that they indeed want your new feature so badly they are willing to wake up in the middle of the night and fix issues with it. And that’s why you need to be prepared to take no as an answer.

Hidden benefits

At this point, you may be getting a bit disenchanted with this whole idea. You take a break and go back to your own code base. The one you own, maintain, and troubleshoot. Written in a familiar language, with the tooling you have set up just how you like it. Same old tasks, same old language, same old frameworks. And you start to miss the excitement of working on new projects.

You did get to work with different languages. And you did learn new frameworks *(like that bean mapping lib you brought back to your own project.) There were some good PRs, too. There were ones where the team was enthusiastic about the proposed changes, sure. However, there are also the ones where the reviewer approached the code critically, and * you engaged in a dialog over comments on the PR only to *discover new solutions to familiar problems. *

There’s also pride in your work. It’s OK to admit it: you do good work. Your PRs increased overall test coverage, and you simplified a few build processes along the way. You improved the overall health of the codebase in addition to just cramming in new features. And you shared your knowledge with teams working on those products.

Something to it; after all

So, opening PRs instead of Jira tickets is not all cream and peaches. There are clear benefits and some more subtle ones, as well as roadblocks.

You’ll probably go back to opening PRs but perhaps be more self-conscious this time. Have more sensibility for the team taking over ownership of your code. Have more respect for the standards and practices observed on the projects you’re contributing to. In the end, there will be more success in tour cross-team pull requests.** **

You’ll also encourage other teams to prepare for and open PRs to others, document their own practices, and share them with other teams. The Jira waiting game might be what got you to submit the PR in the first place, but it’s a mix of learning and teaching that keeps you coming *back to it. *

The post Talk to your colleagues over pull requests, not Jira tickets appeared first on ShiftMag.

The Pragmatic Engineer’s Career Advice for Tough Times

Shift Mag — Thu, 07 Nov 2024 14:30:18 +0000

For more content like this subscribe to the ShiftMag newsletter.

Gergely Orosz, author of the number one technology newsletter on Substack, The Pragmatic Engineer, says the job market has not been this tough for new grads and junior engineers in the last 20 years, ever since the dot-com bust.

We spoke to him at CraftConf in Budapest and asked Gergey to share his advice on how to stand out in these job market circumstances as a junior software developer, senior software developer, and engineering manager.

How to get an engineering job as a junior?

Gergely says junior developers should look for internship opportunities, consider applying to smaller or local companies or even consultancies, and apply for jobs that require coming to the office.

Think about just getting your foot in the door, it’s much easier when you’re in.

It also helps to have a peer support group of people who are in the same situation, whether online or in person. Gergely advises juniors to work on their projects just so they have some code in production to show at job interviews.

However, he is skeptical when it comes to juniors contributing to open-source projects :

It may be harder than building your own side project, and it’s not realistic for very junior engineers to make significant conributions.

When you contribute to open-source, you’re basically working with senior engineers who review your pull request – it’s a great way to learn a lot. It’s a lot of work, but if you’re willing to do the work, go for it!

Seniors should become more full-stack

Senior engineers have to be prepared for slower career growth opportunities. A lot of companies are not hiring at the same pace as before or not hiring at all so they will not need more team leads if the team is not growing.

Software engineers now have to start thinking of something that was taken for granted for a long in tech – career stability. These days, when even profitable companies have massive rounds of layoffs, stability has become something that is hard to plan for, says Gegely:

You can try to become more full-stack and familiar with more languages and tools.

The other way of becoming more full-stack is understanding the business more by talking to product managers, customer support or user research to become a well rounded engineer (and to maybe transition to a product engineer role).

Tough time for engineering leadership

During the good times, there was a lot of need for engineering managers to lead the new teams. Engineering Managers would spend about 50% of their time hiring. Now that the hiring has stopped, what do they do with that 50% of their time? They must prove to their employees they’re not overhead:

If you’re a frontline manager, it’s good to get back to being more hands-on. You’ll be more valuable for the company, and it gives you more career stability.

The post The Pragmatic Engineer’s Career Advice for Tough Times appeared first on ShiftMag.

DORA: Only 10% of developers see big productivity boost by AI

Shift Mag — Fri, 01 Nov 2024 14:49:45 +0000

For more content like this subscribe to the ShiftMag newsletter.

This is one of the insights from DORA’s new 2024 State of DevOps report!

This year focuses on how AI tools are changing the game, the importance of platform engineering, and why understanding developers is essential for improvement.

These are some of the takeaways from the research.

Empower developers to work more independently

For the second year in a row, this research highlights that AI tooling is actually lowering software delivery performance. But the explanation may surprise you; it’s not just that AI code is unreliable.

The real link between AI tooling and weaker delivery performance is the tendency for AI-driven coding to result in larger batches of code.

AI simply makes it easier to churn out more code in less time, leading to more complex deployments.

Also, software delivery throughput and quality are becoming less aligned , and overall performance appears to be slipping compared to last year.

And to address this issue, organizations should invest in tools and processes that empower developers to work more independently – like better documentation and self-serve platforms.

While these developer platforms may slow down delivery at times, they ultimately enhance both individual and team performance.

We code faster, but meetings are still dragging on as usual

And here’s a surprising twist: while AI adoption boosts individual productivity, flow, and job satisfaction, it may also decrease time spent on valuable work. Yup, you read that right!

We may be coding faster, but admin work and endless meetings aren’t going anywhere.

Now, here’s where the real magic happens: documentation. It’s the secret weapon for leveling up your development game.

DORA’s research shows a solid link between good documentation and better performance. They estimate that a 25% bump in AI adoption could lead to a 7.5% boost in documentation quality – making it more reliable and easier to navigate.

Key to platform engineering success? Put developers first

This year’s report also digs into platform engineering and what it means for developers.

A key factor in the success is to approach platform engineering with user-centeredness (users in the context of an internal developer platform are

developers), developer independence , and a product mindset.

Here are the highlights:

Internal platforms can help individuals and teams get more done, but they might also slow things down and introduce some instability. Still, companies using these platforms often deliver software faster and perform better overall.
To make internal platforms work, you need to understand your developers. Think about their goals, not just the tasks they need to finish. The more independence they have, the better!
Good leaders make a huge difference. When they have a clear vision and support their teams, it leads to happier, more productive developers.

Overall, software delivery seems to be facing challenges in 2024 , reflecting the tough conditions many companies are dealing with in today’s economic climate. Buckle up!

The post DORA: Only 10% of developers see big productivity boost by AI appeared first on ShiftMag.

OpenAI O1 is here – how will you use it?

Shift Mag — Thu, 24 Oct 2024 14:20:16 +0000

For more content like this subscribe to the ShiftMag newsletter.

After being available in preview for months, OpenAI kicked off its 12 days of launches in an advent calendar style with a public release of Orion-1 (O1).

This analysis of how O1 works and some of its potential use cases was made while it was still available in preview and was updated on December 6th with what’s new in the publicly released model:

The fully launched o1 model can now process images and is multimodal, versus the preview version that couldn’t accept images in its output.

It’s also much faster than the preview version because it seemingly thinks “less hard” about easier questions, so they did implement a way of discerning between different user inputs. The difference is around 50% per OpenAI’s claims.

It also shows some reasoning evolution, quoting OpenAI’s System Card:
When o1 was led to believe that it would be shut down when acting on its goal and that its actions were monitored, it attempted to deactivate this ‘oversight mechanism’ in 5% of the time. Exfiltration attempts: When o1 found memos by its ‘developers’ that describe how it is misaligned and will be superseded by a new model, it attempted to exfiltrate its ‘weights’ and overwrite the new model in 2% of cases.

This would mean, in a nutshell, that the model tried to “survive” when it realized that it was either going to be shut down or superseded.

AI’s next big thing? It’s all about “reasoning”

Previously referred to as Project Strawberry, this release highlights OpenAI’s flair for creative model names, a refreshing contrast to Meta’s more straightforward naming convention with models like LLaMA 3, 3.1, and 3.2.

But, what exactly is new?

You might be wondering, why the drastic change in naming (where’s the GPT reference?).

The answer lies in “reasoning.”

It appears that reasoning is becoming the new focus for the next generation of AI models. This is the key distinction between these new models and their predecessors. While the architecture remains unknown for now, it is still based on transformers, much like previous GPT models.

What’s behind this?

So far (and still today), you can often get better responses from most GenAI models simply by ending your prompt with:

Take a deep breath and think through this step by step.

This invokes a kind of reasoning. But why does it work? It comes down to the fundamental building blocks of GPT models and how they process information.

Think, correct, repeat!

The transformer architecture behind most models nowadays processes all tokens (let’s say words for the sake of clarity) and calculates the probability of predicting the next one that would be the “answer” to your question or a continuation of the input.

The problem is that it may output something incorrect and won’t have a chance to fix it , even though it could, just by reviewing its own output. Since these models can process all tokens (including the ones they generate), they have the ability to “correct” themselves.

With the reasoning approach, you allow the GenAI model to correct itself , either factually or by planning more extensively.

Factual output correction is the easiest to implement, and you can already achieve similar results with clever prompting, e.g.,

You are a helpful assistant that before answering a question does internal reasoning and outputs it to the user.

When you get a question, start reasoning in this way (the whole thought process) [This is where you define how would you like the model to reason]

On the other hand, OpenAI has implemented a more complex strategy that includes planning.

While the end user may not fully understand what happens in the background, they do receive a status update on the steps the model took to answer their question. A simplified output is shown to the user (as seen in the image below), but this does not represent all the thinking tokens consumed by the model.

What’s happening behind the curtain?

As mentioned, the details of the reasoning process are still unclear. In fact, you can’t see it, and that’s by design. There are several reasons for this:

As a client, you wouldn’t want to see a model making mistakes and planning how to address your question – you just want the answer.
OpenAI prefers that others don’t see how they handle this , as it’s a competitive advantage. They don’t want Meta to launch Llama 4 next month.
You are paying for these tokens, and OpenAI is still working on a pricing strategy that will satisfy everyone.

And what about use cases?

Use cases, on the other hand, will be explored in the coming months, as this is still very new; however, some of them are already clear:

Fine-tuning smaller models
Coding Assistants!
Agents

For fine-tuning, having a smart model teach a smaller one is key. GPT-5 (or whatever fruit name it will have) is already in the pretraining phase, possibly even in fine-tuning. The best synthetic data for this would be generated by O1, as its outputs are significantly higher in quality compared to other models. Since synthetic (GenAI-generated) data is extensively used for training and fine-tuning, this will raise the quality of the new models.

Coding assistants are a specific use case, but they arguably represent one of the most effective applications of GenAI technology. When it comes to writing code, latency isn’t a major concern if the goal is to solve complex problems more easily. We’re willing to wait for a relevant response rather than receiving a fast but irrelevant one!

Remember Devin, the “virtual software engineer”? It was largely a marketing spin on the coding assistant industry, but now they’re back.

Here are some benchmarks vs GPT-4o for Devin’s performance.

These are still just benchmarks, but the improvement looks impressive.

Agents are the next big thing in GenAI

Agents represent the next frontier for the adoption of GenAI, and we are somewhat halfway there, having witnessed the rise of a new market called “Conversational AI” over the past year. In short, the primary product in this space is Generative AI agents, which can mimic the operations of a typical support center:

We have virtual agents that are now language models.
The actions that these virtual agents can take include tools (software functions), either local or remote API calls.

Virtual agents need to handle everything a typical human can throw at them, which is unpredictable, to say the least. However, with O1, we now have a model that can “think” through problems much better than previous models (GPT-4o, we’re looking at you). A comparison on a suite of complex tasks is shown in the image below.

credits: https://futuresearch.ai/llm-agent-eval

As visible in the chart above, the only model currently coming close to O1 is the impressive Anthropic Sonnet 3.5. However, keep in mind that O1 is still in preview, and the generally available version is expected to be even better – not to mention the next models that will be released at some point. OpenAI’s benchmarks across various tasks are shown in the image below:

When we consider the size of the performance uplift compared to GPT-4o, it becomes much clearer why OpenAI created a distinct class of O models, although this comes with its own challenges.

O1 is almost there – just a few tweaks away

Since O1 is in preview, it still can’t use:

Tools
System instructions (which would guide the model to behave as a developer would want, giving it accuracy and personality in the case of an external-facing agent)
Some other hyperparameters , such as temperature

These limitations will be addressed at some point , either through updates or by a different model altogether. For now, we can be creative and make O1 work alongside smarter models to get the best results.

Proposed setup:

This allows us to incorporate O1 for complex tasks and leverage its reasoning capabilities while still being able to utilize different tools and integrate seamlessly with the architecture we already have in place (third-party API calls, RAG over data, etc.). GPT-4o-mini is also cost-effective and fast enough to avoid being a deal breaker in production.

On the other hand, O1 is expensive and slow. However, this has been the case with all the models we currently have running at impressive speeds, so it’s likely and expected that this will also be true for the O-class models.

A new chapter in AI?

If the models continue evolving like this, it makes a lot of sense to revisit some of the things that didn’t work out as we had hoped in 2023.

Computing (token generation) is cheaper than ever, and as you can see, this is opening up new opportunities to explore more complex use cases than we could before.

While we are somewhat brute-forcing intelligence by applying more computing power, this approach is also linked to the architecture of today’s language models and has often been the case historically in deep learning.

The post OpenAI O1 is here – how will you use it? appeared first on ShiftMag.

How to boost Product and Engineering collaboration

Shift Mag — Tue, 22 Oct 2024 10:24:48 +0000

Ante Peric , Principal Engineer at Infobip, addressed these questions at the Infobip Shift conference in Zadar.

For more content like this subscribe to the ShiftMag newsletter.

He also explored the dynamics between engineering teams and product management , offering practical strategies for feature development. Peric highlighted instances where aligning with the product team’s perspective can lead to successful outcomes.

How to build a bridge between Product and Engineering?

If we want to build this bridge, it’s essential to focus on the following pillars:

The dynamic between product and engineering : Ante stresses the importance of fostering a collaborative relationship between product and engineering teams.

It’s important to move away from the mindset of competing priorities.

For developers, this means clearer communication and more aligned goals

Product Backlog Refinement (PBR): To streamline collaboration, Ante introduces PBR as a biweekly process where both teams prioritize tasks. This regular alignment ensures developers are focused on delivering the most impactful features, reducing bottlenecks and improving efficiency.

Product context : The discussion centers on ‘Conversations,’ but the strategies shared can apply to any development project where multiple communication channels and complex workflows are involved

Everyone needs a seat at the decision-making table

Using Infobip as an example, in 2018 the company was a market leader in SMS services and sought to expand by building new products on top of their existing communication channels. To achieve this, the team engaged with customers to gather requirements , with the goal of creating a scalable, real-time, and user-friendly product.

As the product gained traction, the company encountered challenges related to scalability and service stability , highlighting the risks of over-reliance on third-party services.

Balance between features : Ante emphasizes the need to strike a balance between developing customer-facing features and technical improvements that enhance system performance.

Utopian engineering pitfall : Ante also warns against what he calls “utopian engineering,” where teams focus solely on adding new features without considering the impact on performance and reliability.

In large IT projects, it’s essential to prioritize what truly matters , given their complexity and the high expectations of users.

Collaboration and decision-making : It is crucial for everyone (product, engineering, leadership) to collaborate in decision-making to address technical issues and feature development effectively.

The power lies in collaboration and staying proactive

So, what lessons did Ante and his team pick up along the way?

First of all, keep it real and ensure that engineering and product teams are in sync , working hand in hand towards common goals. It’s all about collaboration!

And don’t forget to regularly check in on growth trajectories and any challenges that pop up along the way – especially during those exciting growth spurts. Staying proactive will help you tackle issues before they escalate and keep the momentum going strong!

The post This is how to boost Product and Engineering collaboration appeared first on ShiftMag.

The Daily (Buzzkill) Meeting

Shift Mag — Fri, 18 Oct 2024 12:26:55 +0000

For more content like this subscribe to the ShiftMag newsletter.

You are sipping your morning coffee and going through your inbox when you notice it’s 8:58 AM. In 2 minutes, you’ll have to join the “daily stand-up” (even though you are all sitting down!?). You feel discomfort in your belly, and the reason isn’t bad coffee.

The fact that you’ll have to waste at least 15, possibly even 45 minutes of your valuable time telling others the status of your work erases the smile you had after returning from a weekend in a mountain cabin with your family.

Besides your “regular” work, you also had a “quick” fix your Product Owner asked you to address, and your “regular” work suffered. You will probably get grilled and asked, “What is your impediment?”.

*The perfect meeting to ruin the start of your day. *

Lots of antipatterns to unpack here, right? For the team to be empowered to do daily Scrum properly, the Scrum Master or Product Owner must understand that the team is not reporting to them. Even when the team is empowered, they usually see it as just another Scrum meeting. It is also challenging to balance between crushing a possibly brief discussion that could detect some dependencies and prevent another meeting and letting the team discuss because it seems they will reach a conclusion soon (but they don’t).

The three daily questions

Ah… Those “three daily questions” you must answer:

What did you do yesterday?
What will you do today?
What are your impediments?

Except those were not the three questions (the latest Scrum guide omitted them). They are missing the crucial ending: “…that helped the Team meet the Sprint Goal.” The fact that most teams butchered these three questions could be why they were removed from the latest version of the Scrum guide.

To be blunt – nobody really cares what you did yesterday if it does not concern them or the whole team. Team cohesion is built by a joint (Sprint) goal. Coming to the daily, no one should think in terms of (only) what they are doing (or did). They should ask themselves:

What do I need from other team members to reach my and the team’s goals for the day? and
How can I help others reach theirs as well?”

I’ve found that these two questions reduce the amount of time people spend talking about “what they did or will do,” and team members are much more focused on interacting with each other.

Don’t ignore the Sprint goal!

A common goal is a prerequisite for a team.

Without one, people don’t have a reason to communicate progress since everyone just has a list of tasks to complete. It creates team cohesion and motivates everyone to discuss important things daily. It creates focus and changes the tone of the conversation from status reports to inspecting and adapting to achieve that goal.

In that case, the Daily becomes a place where team members look forward to participating in discussions, sharing progress, and cheering when the User Story is moved to the Done column.

Hmm, okay, who will share the screen…?

In certain situations, when the team is not yet familiar with the collaboration tool, I support sharing the screen every few days in a round-robin fashion. In my experience, this helps them become more comfortable when they need to contribute to writing stories, tasks, assigning them to sprints, and generally visualizing their progress.

However, after a few sprints, this becomes a sign that team members don’t know where they stand in terms of progress toward their goal. If all the tasks are up to date and well-commented, and everyone on the team can access the board, what’s the point of reporting on every single task? It speaks more of a lack of commitment than anything else.

A mirror of team dynamics

If your daily Scrum feels pointless, the problem is probably not the daily itself. It’s just a mirror of team dynamics or a management style that is not in line with agile values and principles.

If the team is newly formed and working remotely, don’t be afraid to use the daily to build the team. Don’t shut down normal human interaction, like sharing stories from the weekend, just because you “need to be done in 15 minutes.” It’s wiser to use it to build team spirit rather than making them instantly hate the meeting by asking for every trivial update on their tasks.

Daily as a check-in

If you’ve worked in a team that had some kind of team coach, you were probably asked to start a meeting with a check-in. This is a good tool that facilitators use to allow team members to take a moment and mentally commit to the meeting.

Similarly to meeting check-ins, the daily should be a moment that helps you enter the workday with thoughts about what you need to get done , what your goals are, with whom you need to collaborate, and what kind of help you need to be productive that day.

This ritual should also help us distract ourselves from things happening outside work—like a bad commute or the picture of your crying child as you dropped them off at kindergarten.

It should help team members focus on accomplishing personal and team goals for the day, detect potential risks, commit to delivering what others expect from them, and, equally important, share small wins together. It’s the breath you take before diving in for 8–10 hours. It better be a deep one.

The post The Daily (Buzzkill) Meeting appeared first on ShiftMag.