This article looks at those five individual-contributor levels. It uses Netflix job descriptions, the company’s culture and compensation policies, and reported pay data from Levels.fyi to show the kind of work associated with each level. Those hiring examples should not be treated as Netflix’s internal promotion criteria.

Engineering levels and compensation

Levels.fyi labels L3 through L7 as Engineer, Engineer II, Senior Engineer, Staff Engineer, and Principal Engineer. Netflix’s recruiting titles vary, sometimes using only a number. The examples below describe particular advertised roles; they are not a uniform specification for every engineer at that level.

Based on the last information checked on October 9, 2026, the individual US level pages on Levels.fyi displayed average annual total compensation of approximately $214K at L3, $321K at L4, $509K at L5, $704K at L6, and $1.14M at L7.

Separately, the company overview reported a median of $430K across US software engineer submissions. What should be noted is these are reported compensation figures, not Netflix’s official pay bands or a representative census of its employees.

Netflix’s engineering listings generally describe annual compensation without a separate bonus. Its Work Life Philosophy says eligible employees choose each year how much compensation to receive as salary or stock options. Under its Personal Top of Market approach, the company assesses an individual’s market value rather than defining the market through fixed bands and grades. The advertised ranges still depend on the role and can vary by location.

For example, the L4 DevOps listing specifies $250K to $413K, and the L6 Developer Productivity listing specifies $600K to $1.066M. The published L7 Growth Engineering description gives a range of $240K to $1.2M. Such overlapping ranges are a reason to check the specific role and offer: they cannot be used as a standard salary schedule for L4, L6, or L7.

L3 and L4 Experience requirements and project ownership

Netflix has a dedicated US new-graduate program that includes technical roles, onboarding, and training. Its careers page says new-graduate openings typically appear in September or October, depending on hiring needs. Levels.fyi identifies L3 as entry level, but that does not mean every Software Engineer 3 vacancy is suitable for someone straight out of university.

The Software Engineer 3 role at Ink, for example, asks for three to five years of software engineering experience, preferably in animation production. It involves working with senior colleagues on tools and platforms for AI-assisted production. That is a specific hiring requirement for a specialist role, not a universal experience threshold for L3.

Speaking about L4, the DevOps and CI/CD posting asks for at least four years of professional experience or equivalent practical experience. It describes work on defined parts of larger platform initiatives, with guidance from senior engineers and a manager. An Android L4 posting expects ownership from project scoping through delivery, while still stressing the importance of team support.

Together, those examples suggest increasing independence at L4, with the amount of guidance depending on the role. Project ownership and support from more experienced colleagues appear together in these descriptions.

L5 Senior engineering and system ownership

Globally popular streaming platform has advertised Senior Software Engineer positions at L5. A useful example is its Analysis role in the Experimentation Platform team, which combines responsibility for production systems with input into architecture and the team’s roadmap.

The archived Analysis listing describes workflows processing billions of events each day. Its responsibilities include developing experiment-analysis tooling, responding to incidents, improving reliability, and agreeing data and API contracts with other teams. The engineer is also expected to understand how product teams use experiments. These details show that the job extends beyond implementing a predefined feature.

In this role, senior responsibility includes accounting for the operational consequences of a design and the needs of the teams using it. Netflix’s emphasis on independent judgment provides context for that work, but the Culture Memo applies across the company rather than defining separate expectations for L5.

L6 Staff engineering across teams

At L6, Netflix explicitly advertises Staff Software Engineer roles. The AIMS Platform Systems examples make the wider scope concrete: the engineer works on infrastructure used by other engineering and research teams.

The Developer Productivity role covers development environments, build and test systems, CI/CD, and tools used to move research into production experiments. It also calls for measuring build times and iteration speed, supporting adoption, and setting shared technical standards.

The Staff ML role focuses on observability, infrastructure cost, and reliability, alongside contributing to architecture and migration planning with other teams.

These examples suggest that Staff responsibility includes getting shared systems adopted and making them useful across AIMS. The developer productivity posting makes that test concrete: the tools need to improve how other teams build and run experiments. The work combines hands-on engineering with coordination across teams.

L7 Technical direction across an organization

Levels.fyi calls Netflix L7 Principal Engineer, while the Growth Engineering job description uses Software Engineer L7. Its responsibilities are defined around the Growth Engineering organization, so the scope is more informative than the title alone.

The published role reports to a Senior Director and asks for at least 15 years of professional software development experience as an individual contributor. It includes setting architectural direction across Growth Engineering, connecting business goals to technology investments, and working with senior leaders and other L7 engineers. The experience requirement belongs to this vacancy, not to a published rule for every L7 role.

The remit is broad technical leadership within Growth Engineering. It combines architectural decisions with continued expertise in production systems and mentoring other engineers, including helping managers support their teams’ development.

Comparing level names across companies

Level numbers are company-specific. Levels.fyi places Google’s Senior Software Engineer title at L5 and Staff at L6, while Amazon uses L6 for Senior SDE and L7 for Principal SDE. Meta uses E-level labels in the same database. These naming conventions can help a candidate navigate vacancies, but they do not establish equivalent responsibilities or hiring standards.

The distinction matters most above Senior. For example, Google’s L7 is Senior Staff and its Principal title appears at L8, whereas Levels.fyi labels Netflix L7 Principal. A shared title or similar number does not show where an engineer would be placed after changing companies. The role’s technical remit and the employer’s assessment remain necessary context.

How culture affects engineering work

Netflix’s Culture Memo highlights judgment, candid feedback, and giving employees enough context to make decisions. It also expects managers to stay involved and coach their teams. Autonomy should therefore not be mistaken for an absence of support, nor treated as a benefit reserved for senior levels.

The keeper test is part of that performance culture. Managers are asked whether they would try to retain someone or choose to hire them again. If the answer is no, Netflix says it favors ending the employment relationship promptly. The memo also says to assess a person’s overall record, discuss performance regularly, and support employees through short-term setbacks.

For a candidate, the practical next step is to ask how the hiring team defines scope at the advertised level, what support is available, and how progression is assessed. Public postings can help frame that conversation. They cannot supply a guaranteed promotion timetable or the terms of an individual offer.

The post Netflix Engineering Levels Explained: L3 to L7 Career Ladder, Scope, and Pay appeared first on ShiftMag.

AI makes ad hoc operational work so easy that we stop building the tools around it.

Why write a script when you can just ask Claude or Copilot to restart the canary? Why build a dashboard when ChatGPT can summarize today’s deploy status in 15 seconds?

Because that 15-second conversation, repeated by 50 engineers 20 times a day, stops being convenience and starts becoming a tax.

Conversation-driven operations have a hidden cost

Let’s walk through a real example: restarting a canary deployment.

Manual AI-assisted workflow:

1. You: “Check the health of the canary deployment for payment-service”
2. AI: calls monitoring API, returns data (~800 tokens)
3. You: “It looks unhealthy, restart it”
4. AI: calls deployment API, confirms restart (~600 tokens)
5. You: “Monitor it for the next 5 minutes and confirm if it stabilizes”
6. AI: polls metrics, returns confirmation (~900 tokens)

That’s ~2,300 tokens per restart. Three restarts a day across a team = ~200k tokens/month. For a task that takes one CLI command.

Now compare:

/canary-restart payment-service

One message, zero AI tokens. The bot routes the intent to an internal tool that handles health checks, restart logic, and confirmation, all without an LLM in the loop.

Use AI to build the tool once, so you don’t keep paying for the conversation.

Why Slack?

Because that’s where the work already happens.

Incidents get declared in Slack. Deploy notifications land in Slack. Someone pings you in Slack asking “is prod healthy?” The response to that message shouldn’t require opening a terminal, switching to a dashboard, or navigating to another tool.

Your team already works in Slack, so your commands, context, and decisions should live there too, directly connected to the machines.

The alternative is telling every engineer: “When something breaks, leave the place where your team is coordinating, open a different tool, figure out what command to run, then come back here to tell everyone what happened.” We’ve been doing that for years and it’s never been good. We just didn’t have a better option.

The bot is there to connect, not to decide

This is where most Slack bot projects go off track: they pack business logic directly into the bot itself. Message handlers start calling APIs, transforming data, and handling retries, and before long the bot turns into a monolith.

The Slack bot should be thin. It does exactly three things:

1. Parse the incoming command or message
2. Route it to the right internal service
3. Format the response back to the user

No business logic, no database queries, no retry loops, and no secret management.

The actual work lives in your internal tools and services. The same ones your GUI calls, your MCP server exposes, your CLI wraps, your CI/CD pipeline triggers. The Slack bot is just one connector among many.

The tool service owns the business logic. Every connector, GUI, MCP, Slack, CLI, is a thin shell that calls the same service. Write the logic once, expose it everywhere.

Choose configuration over code for adding tools

If adding a new Slack command requires a PR, a deploy, and someone from the platform team to review it, you’ve already lost. It won’t get done.

Adding a tool should be a configuration change:

tools:
  - name: canary-restart
    description: "Restart a canary deployment"
    endpoint: http://tool-service/internal/canary/restart
    parameters:
      - name: service
        type: string
        required: true
    acl:
      - platform-team
      - oncall

  - name: feature-flag
    description: "Toggle a feature flag"
    endpoint: http://tool-service/internal/feature-flags/toggle
    parameters:
      - name: flag-name
        type: string
        required: true
      - name: environment
        type: string
        default: staging
    acl:
      - developers

The bot reads this config, registers the slash commands, and routes them. The tool service behind those endpoints can be built and deployed independently, by any team, in any language, on any cadence.

This separation means:

• The ops team owns tool-service deployments and logic
• The platform team owns the bot and routing config
• Any engineer can propose a new tool by opening a config PR
• No one ever modifies bot code to add a capability

The bot becomes part of the infrastructure (quiet, reliable, and rarely changed). The tools behind it keep moving forward.

This is what it looks like in practice

Incident response, today without a bot:

Alert fires, someone opens PagerDuty, 5 people join a Slack huddle, one person shares their screen navigating dashboards, someone else runs CLI commands, results copy-pasted back to the thread.

Incident response with a bot connector:

Alert fires, /incident declare payment-service-health-check-failing, bot creates incident channel, rolls back the canary, posts the deploy diff, pings the on-call, everyone joins the channel with full context already there.

Feature flag management, today:

“Can someone toggle the new checkout flow to 10% in staging?”, wait for platform team to wake up, ticket, CLI command, “done”.

Feature flag management with a bot connector:

/feature-flag new-checkout-flow --env staging --rollout 10, bot calls the feature-flag service, responds with confirmation, done in 3 seconds.

None of these Slack commands contain business logic. They all call the same internal services your MCP server, admin GUI, and CLI already use. The bot is just the most accessible surface.

Practical takeaways

Put operational logic in internal services, not Slack bots or CLIs

This isn’t about Slack bots, MCP servers, GUIs, or CLIs. They’re all just ways to connect things. What really changes is this:

Stop scattering operational logic across interfaces. Centralize it in internal services. Then build whatever connector makes sense for the context. Slack for incident coordination, MCP for AI agents, GUI for exploratory work, CLI for automation.

And when someone asks “can we add that to the bot?”, the answer should be yes, and it should take 5 minutes and a config change, not a sprint. If it can’t, the architecture is wrong.

The post You Should Bring Your Ops to Slack appeared first on ShiftMag.

We played “Truth or Dare” with developers again, truth only, with no option to dodge the answer by doing push-ups.

Developers from different parts of the industry spoke about how they survive tight deadlines, tension inside engineering teams, and the subtle, protective lies they use to get through the week.

There’s a pressure to sound confident

In engineering teams, pressure, shifting priorities, and the need to move quickly shape communication. In that environment, “truth” is more about signaling confidence, alignment, and forward progress than precision.

Weekly meetings, fast delivery cycles, and constantly changing priorities push developers to learn that how they communicate can matter as much as the work itself.

That is why we asked how developers manage expectations. The phrase “it will be done” often appears early, sometimes before anyone fully understands the scope of the task. Under pressure, estimates tend to be optimistic, and reality usually forces adjustments as the work moves forward.

At the same time, developers handle that pressure in different ways – some narrow their focus and push through tight deadlines, while others start by asking whether those deadlines even make sense.

The truth about deadlines

Deadlines sound like a nightmare for an engineering mind, so we asked our developers how they deal with them.

Some described how short deadlines increase focus and force prioritization. Others questioned whether extreme deadlines reflect process problems rather than urgency.

Hrvoje Rančić, Senior Software Engineer, described how constant pressure can indicate systemic misalignment rather than effective planning:

I realized that deadlines can sometimes be a mechanism of manipulation. If there are too many short deadlines, something is wrong in the process. Either people are making unrealistic promises, expectations are unrealistic, or there is poor communication between product and engineering.

At the same time, other participants admitted that deadlines can help with focus and discipline, but only when they are based on a realistic scope of work, not on constant escalation of pressure.

The point is not that deadlines are bad, but that misaligned and unrealistic deadlines often point to deeper organizational issues.

Engineering is often about people, not just code

The stereotype of the isolated, antisocial engineer still exists, even though modern software development is highly collaborative. That misconception often clashes with the reality of teamwork, where communication, negotiation, and constant alignment are a key part of the job.

Kristina Valjak, Engineering Lead, summarized it:

Some people think engineers are introverts who don’t socialize, who sit in basements and stare at screens all day. Maybe it’s true that we’re not social enough, but in reality, everyone is smart.

The irony is that engineering work is rarely isolated. Most of the tension developers describe does not come from code, but from coordination between them, the product teams, and management.

How developers smooth over the truth at work

Developers often tell small, strategic lies to keep work flowing smoothly. These are not dramatic deceptions, but everyday adjustments such as overconfidence in estimates, downplaying uncertainty, or agreeing in meetings while problems are resolved in the background.

Emin Mulaimović, Junior AI Engineer, reflected on this broader communication culture, recalling an anecdote from his first job:

At my first job they told me not to say I was happy at work, so I kept complaining all the time. I think that’s the only lie I tell. I don’t tell them how much fun I actually have working there and how much I enjoy the job.

In another example, a developer described solving an issue during a break and returning to the meeting without interrupting the flow of discussion. In other cases, developers admitted to deliberately inflating estimates or simplifying status reports to avoid unnecessary tension.

This behavior is not so much about deception as it is about reducing “noise” in systems that are already complex enough.

Want to hear more? Check out the video.

Special thanks to our fellow colleagues at Infobip, the publisher of ShiftMag!

The post The Small Lies Developers Tell to Keep Work Moving appeared first on ShiftMag.

This May, I spoke with a CTO who truly understands the spirit of the moment and brings a grounded, realistic view of the current wave of AI expansion. He applies that perspective across a team of roughly 1,000 developers.

That is Izabel Jelenić, CTO of Infobip, first Croatian unicorn. As a co-founder, he has been there since the very beginning, when two university friends started a small startup that later grew into a billion-dollar global organization. Over the past 20 years, this veteran tech leader has navigated every major technological shift while helping scale the company worldwide.

The conversation comes at a moment when we are in the middle of the agentic AI era, where AI systems move beyond answering questions and begin executing tasks, supporting and automating real workflows. At Infobip, this shift has been embraced early and deliberately through an AI-first transformation that extends across the entire organization, engaging not only developers but employees in every function.

Developers should adopt AI gradually

I asked Izabel to explain what AI-first means and how the idea of shifting to an AI-first mindset emerged.

What followed was a comprehensive breakdown of its evolution, core principles, and practical execution. With over two decades in the tech industry, my interlocutor emphasizes that he has never witnessed a technological shift this monumental, signaling clear proof that AI is rapidly moving from mere hype into everyday utility.

That makes mastering these capabilities and maximizing their potential absolutely crucial. A common pitfall, however, is assuming AI belongs solely to developers, which completely misses the mark given the technology’s universal transformative power:

That is why Infobip promotes a mindset in which all technical and non-technical employees embrace curiosity toward AI so they can be part of the new business and technological order instead of letting it overtake them. That is the AI-first shift the company has chosen as its business philosophy for the future.

While technical teams naturally adopt new tools faster and more efficiently, he believes those outside software engineering shouldn’t be left behind. Providing non-technical employees with the right resources and training allows them to leverage AI agents as personal assistants, ultimately making their daily work both easier and faster.

When it comes to software developers, the Infobip CTO sees two extremes:

1. Some cling tightly to writing code and represent the anti-AI camp.
2. Others rely fully on AI and embrace vibe coding.

In his view, neither approach is correct.

Because technological development has not yet reached the “dark factory” stage (where systems run entirely automated and unassisted), rushing into a full AI concept remains premature. Instead, this direction serves as a north star—a long-term guide rather than an immediate reality. While it remains uncertain if a fully autonomous state is entirely achievable, forcing such an approach today is clearly unwise.

Developers should adopt AI gradually. They should understand which tools suit them best, such as coding, review, and testing.

If you are a bad developer, AI can’t help you

From the CTO’s perspective, Infobip developers have adopted an AI-first mindset naturally and with little friction, though overdoing it remains a risk. There is a critical need to retain ownership and maintain a strong architecture, especially since AI often acts as an amplifier, scaling both good practices and underlying flaws:

If you are a bad developer, AI will not help you write good code. If you are a good developer, AI can help you a lot in terms of speed. But you have to know how to guide it and recognize its mistakes, because it can be very convincing.

He explains that an AI-first mindset changes how organizations operate. AI speeds up processes by automating everything that can be automated. People can master this technology by adopting engineering logic, and they gain a strong advantage for the future.

By ignoring AI, a person pushes themselves out of the industry. Izabel finds it surprising that some smaller companies do not adopt AI faster. They are in a growth phase where AI could make a huge difference. They could implement it quickly because teams are small and compact. Despite this, adoption remains low.

The Infobip co-founder sees a common misconception that AI is mainly for developers. The biggest impact actually appears in GTM because AI automates business processes extremely well. Hyper-personalization becomes fast, advanced, and efficient. It can significantly help business scaling:

You can automatically analyze the market, get a list of potential clients, identify use cases that clients need, and do outreach. With hyper-personalization, you can prepare content in a way that immediately helps a person understand what a company sells, but from their perspective.

AI will reshape roles in tech companies

Even though AI can quickly improve business organization, he notices that people mostly focus on coding. Coding has never been the biggest problem in IT businesses, the real bottlenecks usually appear in sales.

This is where AI transforms work, making processes more efficient and cost-effective. Far from replacing client relationships or removing the human element, the goal is simply to automate repetitive operational tasks, leading to a much more streamlined workflow:

People need to get on the AI train. If they do not use AI, new companies will emerge that are AI-native. They start with two people and AI. Their approach will feel more natural and much faster than those who use AI only for software development.

When asked to describe what an AI-first transformation looks like from the inside (using Infobip as an example) and whether the company will abandon certain processes or redistribute roles, the answer is far from black and white. This transition will happen gradually, marking the most significant technological shift in over two decades.

Ultimately, enthusiastic professionals eager to learn will be the ones expanding their roles by actively implementing these new technologies:

People experienced in one specialization can now work much more broadly. They can keep their core role, but they can accomplish much more. Someone who used to be only a backend developer can now work with databases or frontend. They may not reach the level of an experienced database engineer, but they can handle simple tasks. They do not need to wait for anyone.

The concept of Agentic AI is another major focal point, pointing toward a future where everyone operates with multiple digital assistants. By helping manage core business tasks faster and more efficiently, these agents streamline daily operations while actively expanding a professional’s overall skill set.

AI agents are still nothing without people

As part of its AI-first mindset, Infobip is building its own Model Context Protocol (MCP), integrations, enabling AI agents to easily consume and interact with Infobip services. CTO believes this is vital because AI agents will soon be everywhere, embedded in business systems, running on personal devices, practically on anything you can imagine:

Once it became clear that AI agents are the primary means of interacting with the outside world, adoption accelerated rapidly. Companies realized how easy it is to connect these agents to external systems and services. The key point is that AI agents can now perform real-world tasks by consuming various APIs, especially those available on platforms like MCP. This capability makes them an integral part of business operations, and it’s why we believe their presence will become ubiquitous in the near future.

However, he stresses the importance of human involvement. It should not disappear:

Communication must continue to exist. We cannot fully hand it over to AI agents. They can help, but communication becomes even more important because everyone becomes more productive. Without alignment, you can end up with many generated tools that no one understands.

There is also a clear warning regarding hyperproduction, which can easily spiral into chaos if teams begin operating without proper coordination.

There are fewer junior developers, but they are still valuable

I also wanted to ask an experienced professional what will happen to junior developers. Demand for them has decreased globally. AI now generates much of the code that juniors used to write.

At the same time, a generational shift could lead to a talent shortage. Looking back at the end of the pandemic when the IT sector saw a massive influx of talent, Izabel notes that many recent layoffs in US companies are likely happening under the cover of AI:

They use AI as an excuse for inflated numbers and inflated costs. That is why fewer juniors get hired. I think balance is returning. We will not see excessive hiring from before, but there will still be a need for young, smart people who bring new ideas and fresh energy into processes.

To combat these talent gaps, Infobip runs targeted internships and collaborates closely with universities, frequently transitioning these students into permanent roles. In CTO’s experience, these fresh perspectives bring genuine value and innovative ideas to the team.

AI plays a pivotal role in this onboarding process by granting immediate access to learning resources, allowing junior engineers to upskill rapidly. By leveraging AI as a 24/7 virtual mentor alongside human guidance, juniors can accelerate their professional growth and secure key positions within the company much faster

Experienced developers face an identity crisis because of AI

Skepticism among experienced developers toward AI, in the view of Infobip’s co-founder, stems from a natural feeling of disappointment and an ego hit that is not easy to accept. At the same time, he points out that over twenty years, workflows, frameworks, programming languages, and machines have all continually evolved:

You spend 20 years writing code as a developer, refining it, running it, seeing how it works, writing tests, and then suddenly you stop looking at the code and start talking to a tool. You experience an identity crisis because you used to identify with the code you wrote.

My interlocutor views these feelings as entirely legitimate, but encourages professionals to expand their scope and boost productivity. Ultimate purpose does not need to remain locked within a single job description when fulfillment can be found in wider responsibilities.

This adaptation is admittedly difficult, but as he points out, once people move past the “this is useless” phase, they position themselves for rapid growth by embracing the new reality.

Speaking from his experience as a CTO for 20 years, Izabel describes the transition to an AI-first mindset:

These changes are quite painful. We also went through turbulence, but at some point you see that AI brings value and you have to use it. Claims about AI being prohibitively expensive often serve as mere excuses. Open-source models can already run locally on standard laptops, completely bypassing the need for intensive training in many scenarios. Ultimately, running a model and training one are two entirely different concepts. Today, hardware capabilities and overall quality are night and day compared to what was available just a few years ago.

The question may be how good an LLM you use, but you will not be able to work without it. The technology is here to stay. It is important to understand its strengths and weaknesses and use it as soon as possible.

The future is uncertain but exciting

Finally, when asked what the next twenty years of Infobip will look like, the answer was a candid “I don’t know.” Just as no one could have predicted the current shift, no one can definitively predict the next. Still, one thing is certain: there is immense excitement about this change.

Within Infobip, both technical and non-technical teams are fully embracing AI. Another deep reshaping is underway, business as usual no longer exists. Instead, the industry is witnessing a real transformation:

Twenty years ago we said “We are just starting”, and now we are in the same situation again. That will probably continue for the next 20 years. Our best people keep learning new things that drive them forward instead of standing still.

This mindset feels humble, but also necessary in a time of major technological transformation. It reflects the Socratic idea that true wisdom begins with understanding how little we know.

Infobip is the publisher of ShiftMag, recognizing the need for high-quality content for developers.

The post 20 Year Old Unicorn Goes AI-First Without Mass AI Layoffs appeared first on ShiftMag.

Ask anyone outside the industry why people go into software engineering and they’ll say: good money, remote work. Talk to the developers themselves and you get a different story.

For most of the 20 of our Infobip colleagues we interviewed, it started with genuine curiosity – a need to understand how things work, then build their own. Some caught the bug in childhood, others through gaming. But the thread running through nearly every story is the same: they fell in love with the craft long before they ever thought about the salary.

Josip Antoliš, Senior Principal Engineer, captures this sentiment:

It felt like playing with Lego, just for older kids. It was really about building and experimenting.

If money is the only reason you want to become a developer, you won’t make it

Money is part of the equation, and some developers are honest about it – job security and solid pay were what first pointed them toward the field. There’s nothing wrong with that. But most will tell you it only gets you so far.

Engineering is demanding, constantly evolving, and unforgiving to those who are just going through the motions. The developers we spoke to largely agreed: without a genuine curiosity for the craft, the motivation eventually runs dry, no matter what’s in your bank account.

Olga Koroleva, Staff Software Engineer, explains:

For me, it was not money driven. I just naturally like learning new things.

Not everyone had a master plan. For some of the developers we spoke to, the path into software was less a calling and more a series of small, accidental steps like following friends into a computer science program, or stumbling onto coding in their twenties and realizing they had a knack for logical thinking and breaking problems apart.

What matters less, it turns out, is how you got in. What keeps people thriving is the willingness to keep learning and adapting in a field that never really stands still.

Among younger developers in particular, gaming played a surprisingly direct role – less a hobby, more an early window into how software actually works.

Edvin Teskeredžić, Senior AI Software Engineer, remembers his Counter-Strike days:

We used to play a lot of Counter-Strike, and to play together we had to set up servers. Later we started modifying the game, and only later realized we were actually programming.

In the end, whatever brought them to the field, most engineers find a way to grow into it. As Denis Kranjčec, Staff Engineer, puts it:

I started programming 40 years ago, and money was fine, but it was not the only thing.

The best things about being a developer

When asked what they love most about the job, the answers kept circling back to the same themes.

• Cracking a hard problem in a clean, elegant way
• Shipping something that actually makes life easier for people – knowing your code is quietly doing its job out in the world
• Those rarer moments when a tangle of complex systems finally clicks into place, and what was chaos becomes something that just works

Creativity and problem-solving remain central themes. As Teskeredžić puts it:

I like solving practical problems and applying creative solutions.

Beyond the work itself, the setup matters too – remote work, autonomy, and long uninterrupted stretches to actually think. But as Olga Koroleva puts it, what really keeps people around is simpler than any perk:

The best part is staying curious.

The not-so-good part of a developer’s career

Ask about the downsides and the answers get a lot shorter. One word came up more than any other: meetings. Pointless ones, mostly. The kind that could’ve been an email.

Beyond that, developers highlighted several systemic frustrations that disrupt deep focus:

• Constant context-switching takes a significant mental toll.
  
• Bureaucracy and tedious reporting often fracture the time dedicated to core engineering tasks.
  
• Navigating undocumented legacy code and parsing ambiguous logs slows development velocity.

There’s also the relentless pace of change. Kristina Valjak, Engineering Lead, puts it plainly:

The speed of change means you constantly have to learn. You have to sacrifice things. It is not a job you leave at the door.

And then there’s the physical reality: long hours at a screen, tight deadlines, pressure that doesn’t let up. Even in teams doing interesting work, that combination can wear you down.

Would they choose this career again? Absolutely.

When asked if they’d do it all over again, there was barely a pause. Absolutely. 100 percent.

More pros than cons. Almost without exception, these developers would make the same choice and most believe tech still offers something few other industries can match: genuine stability and room to keep growing.

Ivona Škorjanc, Software Engineer, remains highly optimistic:

I would still choose it. It is exciting and I see myself growing in it.

A few said they’d have invested more in the fundamentals early on – the theory, the computer science basics that tend to get skipped in the rush to learn frameworks and ship code. But that’s a minor footnote to a bigger conclusion: this field is hard, and most of them wouldn’t trade it for anything.

Teskeredžić offers a final, inspiring perspective on the profession:

To me, engineers are like real-world wizards. Advanced technology is like magic, and if you can be a wizard for a career, why not.

Even the ones who occasionally miss working with their hands come back to the same answer: they’d choose this path again.

Special thanks to our fellow colleagues at Infobip, the publisher of ShiftMag!

The post We Asked 20 Developers Why They Really Got Into Tech. It Wasn’t the Money. appeared first on ShiftMag.

Top experts from global tech leaders will share how they build and scale some of the world’s most complex systems, with real-world lessons from production environments.

Across multiple stages, the program features panels, workshops, and talks focused on deep technical insight and practical experience. Speakers include Katie Gamanji (Apple), Igor Dmochowski (NVIDIA), Sven Peters, Bette Lyon Delsordo, and many others.

You don’t need silicon valley for world-class tech

Igor Dmochowski, Head of Developer Relations for Central and Eastern Europe at NVIDIA, said that Infobip Shift is already internationally recognized, and added that he is especially excited to meet local developers whose potential is increasingly visible on the global stage:

Croatia has exceptional technological talent and a strong AI community, and I’m glad to be part of an event that puts this into a global context. True tech innovation comes from connecting people and ideas, and Shift has that energy.

On the other hand, Ivan Brezak Brkan, the Director of Developer Experience at Infobip, said that Infobip Shift is rightfully the largest tech conference in this part of Europe and one of the largest in the world.

You don’t have to, especially in today’s conditions, travel to the other side of the world to exchange experiences with people whose technological solutions power the world. If you want to advance your career not only through knowledge but also through connections, you need to be at Shift.

No professional speakers and marketing presentations

“Infobip Shift is built on two foundations: high-quality content and a relaxed atmosphere that encourages networking. We ensure strong content by carefully selecting speakers who share real-world experience from people actively working in the industry,” said Stipe Cigic, Director of the Infobip Shift, adding:

We avoid professional speakers, marketing-driven presentations, and topics overloaded with buzzwords and hype. That has become especially challenging today, when roughly every second submitted topic is somehow related to AI. Our speakers are real developers – people whose knowledge our audience truly values.

He also said the second foundation of Shift is its relaxed, laid-back atmosphere – a vibe the team aims to create each year. It can’t be forced, but they work to make the event feel light, summery, and welcoming. That kind of atmosphere makes networking more natural and fun.

Meeting new people is the biggest opportunity for attendees. I know at least 2 projects that started from casual chats at last year’s Shift. High-quality content plus a summer vibe, that’s what makes it memorable.

Knowledge gets you started, networking takes you further

With increasing reports of layoffs and disruption in the global IT industry, networking is becoming even more important. Stipe says the goal is for developers to leave Shift not only with new knowledge, but also with greater confidence and reassurance in their skills, value, and future in the industry.

I believe that, when it comes to networking and professional connections, Shift has no real competition in this part of Europe within the developer industry. A junior developer can casually grab a coffee with a senior engineer from companies like Netflix. The exchange of knowledge and experience in conversations like that is something our community rarely finds at nearby conferences.

Stipe concluded that Shift is a long-term platform developers can rely on, not just to meet peers, but also potential employers, clients, and partners. It offers many opportunities, whether for networking or simply enjoying great talks, food, and drinks under the Mediterranean sun.

Interested in Infobip Shift? Explore what we have planned!

The post Infobip Shift 2026 Returns to Zadar, Bringing Apple and Nvidia to the Stage appeared first on ShiftMag.

A field that, just a few years ago, felt stable and full of opportunity now comes with more uncertainty -breaking in is harder, and staying relevant takes constant effort.

We spoke with software engineers who have more than 10 years of experience to hear how they’re navigating these changes.

Thinking back on your career, what’s helped you stay relevant as technologies and trends kept evolving?

Denis: “I was always looking for ways to improve my workflow, so I could spend more time on the interesting, creative parts of the job and less on repetitive, routine tasks. I focused on really understanding problems and possible solutions, which meant building deeper knowledge rather than relying on quick fixes from the internet. I read books, followed blogs, attended both live and online conferences, and learned from experienced people in the industry to get different perspectives and form my own conclusions.

To stay relevant, I focused on real user use cases and the problems behind them, building solutions that create real value.

I also made a point of staying close to the products, users, and solutions over time to see what actually works and what doesn’t, regardless of hype or trends.

Working in teams and collaborating closely helped a lot, as there are always tough questions and healthy discussions that lead to better decisions in the end.”

Marina: “Staying relevant over the years came down to curiosity and hands‑on learning. I regularly read blogs and watch online conferences to keep up with new technologies, but I learned the most by trying things out through small POCs. Experimenting helped me understand problems more deeply and see what really worked.  

Changing teams also played a big role. Working with people who had different backgrounds and experiences exposed me to new ways of thinking and pushed me to grow.  

Finally, working on real products in production environments (especially in larger teams) taught me lessons you simply can’t learn alone. Collaboration, shared ownership, and learning from others helped me continuously adapt as the industry evolved.”

Marko: “For me it’s a combination of continuous learning and a strong focus on fundamentals. I always tried to explore new technologies and different domains, but with an emphasis on really understanding the core principles behind them. That way, the knowledge stays useful even if my career moves in a different direction, and it becomes much easier to build on top of it later.

Just like for the other guys, another important factor was working on real products running in serious production environments, especially in larger teams. Collaboration, communication, and learning from others in a shared codebase bring insights you simply can’t get when working alone. Those experiences helped me grow not only technically, but also in how I approach problems and make decisions in the long run.

I’d describe myself as a cautious early adopter. I enjoy experimenting with new technologies, but I try to understand the fundamentals behind them first, so I can evaluate where they truly make sense and how they contribute real value rather than just following hype.

Finally, self-reflection played a big role. Regularly asking myself what skills I’m missing, how I can contribute more to my team or company, and then actively working towards that has led to many good long-term career decisions.”

Mario: “Talking to other people, watching what others build, and experimenting myself plus exploring open source projects, YouTube videos, and Udemy courses on 2x speed to quickly understand what’s possible with unfamiliar tools. I also follow Hacker News and similar newsletters.

But staying relevant isn’t just about knowing what’s new; it’s about knowing what’s actually worth adopting – and when.

Understanding the high-level concepts and the problem I’m trying to solve is what allows me to pick something that looks like the right tool. After that, trying it out and getting first-hand experience: how it feels under the fingers, and whether it really solves my problem and makes my life easier – is mostly the deciding factor for me, but not the only one. If I’m doing a quick throwaway POC, I can try anything and really find the best tool.

But if I’m working in a team environment where cognitive load is already high, I’m careful not to introduce new technologies every other day just because it’s the new cool shiny thing – even if it actually is the best tool. It’s a tradeoff, and one that needs careful consideration. And sometimes the best isn’t even needed – something that works is good enough.”

In your opinion, is long-term success more about being a deep specialist or a broad generalist? Has your perspective changed over time?

Denis: For long-term success (whatever that is), it’s generally better to develop M-shaped skills. That will take some time, but only with great collaboration and multiple deep expertise areas can you be innovative and versatile, bringing measurable value and not be easily replaceable.

Marina: Earlier in my career, I believed that being a T‑shaped developer was the ideal path and I assumed that trying to learn more than one thing deeply would only lead to superficial knowledge and that focusing on a single specialization was the safest way to grow. Over time, my view changed.

Through real-world experience, I realized it’s possible to build strong, meaningful expertise in multiple areas without losing depth. As systems became more complex, having deeper knowledge across several domains helped me understand the bigger picture better, make better technical decisions, and collaborate more effectively with others.

Today, I believe long‑term success comes from combining depth with breadth – developing strong expertise in more than one area and continuously expanding that range as technology evolves. This flexibility has helped me stay relevant and adapt as roles and technologies have changed.

Mario: I wonder if it’s possible to be M-shaped For a long time, I was a firm believer that T-shaped is the way to go – a broad overview, but with at least one area of genuine deep expertise. And I still think that’s a solid foundation for any engineer.

But over 20+ years, curiosity kept pulling me in different directions: low-level Linux internals, networking, compilers, containers, orchestration, and large-scale distributed systems, working at different layers of the stack. And each time, I went deep enough to solve a real problem. That experience adds up over time.

Understanding the problem and figuring out which layer it needs to be solved in matters more than the technology layer itself, and then it’s about stitching everything together.

Do that long enough, across enough domains, and you naturally grow more spikes. So my view has evolved – I started as a T-shaped believer, and somewhere along the way I became something closer to M-shaped. Not by design, but by following the problems. And if you ask me what I’m an expert at specifically, I’d say solving problems, if that counts as expertise. That’s at least what I currently strive for.

Marko: Today, I’d describe myself as somewhere between T-shaped and M-shaped, maybe N-shaped, still evolving. Early in my career, the T-shaped model made perfect sense, broad knowledge with depth in one area. Over time, as access to knowledge became easier and technologies evolved faster, I realized how valuable it is to develop depth in multiple areas

What ties all of this together is problem-solving. Technologies change, but problems remain. Being able to learn continuously, adapt, and apply concepts from one domain to seemingly unrelated problems becomes incredibly valuable over the long term.

If I were to advise myself 10 years ago or to others today, it would be to stay curious, keep learning, and surround yourself with people you can both learn from and teach. Also, don’t be afraid to broaden your horizons, look for ways to contribute beyond your narrow specialization, pick up complementary skills, and take some risks. Growth often happens outside your comfort zone.

How do you see AI tools impacting long-term developer careers?

Mario: AI impact is real, especially in engineering. We’re much faster at writing code, and I can smart-search unfamiliar codebases and quickly understand how things work (something that used to take a huge effort).

But there’s a price.

The amount of generated code is huge, yet humans still need to review, understand, and own it. AI isn’t the one waking up when something breaks. Creating PRs with AI is easy, being responsible for them is another story.

Our role has shifted to making sure code that looks ok is actually ok – fits the intended architecture, the broader system, the business rules, all the things AI isn’t aware of. The value is the same: understanding whether the code works as intended and preventing it from degrading into a ball of mud nobody can understand or fix at 3am.

What’s changed is how much harder that challenge has become with code being generated at this speed. Young developers are in a tight spot – suddenly expected to skip writing code by hand but still have the same depth of understanding.

And I’m not sure you can skip that part. There’s something about writing code by hand, hitting a wall, debugging it yourself, and feeling the pain of it not working that builds intuition you can’t shortcut. Even if AI is faster and easier. The best advice is to learn the concepts, fundamentals, and engineering best practices that hold regardless of AI.

You need to be able to look at AI-generated code and know whether a for loop is acceptable or a dictionary lookup fits better, that’s software engineering 101. AI can generate the code, but we still need to understand whether it actually fits.

Write as much code by hand as you can. Use AI to review it, ask for other options, and have it challenge your approach, and then actually think through the answers. That way you learn faster while still building real understanding.

And don’t skip debugging AI-generated code step by step; I do it regularly. It’s how you move from just looking at code to actually feeling it. That difference becomes obvious once you try it.

You’ll often be surprised how much you miss just by reading – sometimes it’s “this is not how I thought it worked”, sometimes it’s “I did not expect this at all.” Both are valuable, and both come from actually stepping through it.

Marko: AI tools already have a huge impact on my daily work, from writing code and understanding codebases to reviews, idea generation, debugging, and learning new topics. Overall, I see AI as a strong positive force for developers. It significantly reduces the time spent on repetitive or low-value coding tasks and frees up more space for thinking about architecture, system design, and solving complex problems that truly matter in production.

That said, some things won’t disappear. Understanding the problem and broader context, making architectural trade-offs, communicating well, and taking ownership are still firmly human. When something breaks at 2 a.m., it’s still engineers who make decisions and take responsibility. AI is powerful, but only as effective as the person using it.

For junior developers, don’t skip the fundamentals. Expectations are higher than ever, but strong foundations are key for a sustainable career. The good news is that access to knowledge and AI tools is better than ever. Use AI to accelerate learning, not replace understanding. Give yourself time, build experience, and master the basics—that investment pays off for decades.

Marina: AI tools will significantly change how developers work, but I don’t see them replacing strong engineers. Instead, they will amplify those who understand what they are building. For younger developers, the key is to learn with AI, not just watch AI work.  

It’s important to question AI output, understand why it made certain changes, and how those changes affect the system. Treat AI as a learning partner rather than a shortcut. Blindly accepting generated code can limit growth, while actively analysing and improving it builds real expertise.  

Younger developers should also focus heavily on architecture and system design. When you understand how systems are structured, how components interact, and what trade‑offs exist, AI becomes far more powerful. It’s much easier to ask the right questions (and get useful results) when you already understand the problem space.

Denis: AI tools have made coding skills almost irrelevant. Still, other skills and practices related to quality, such as trunk-based development, TDD, continuous delivery, modularity, cohesion, DDD, etc., are more valuable than before.

AI tools are a powerful amplifier, and they need guidance, so software engineers with those skills will remain relevant and in demand for a long time. Understanding of the (business) problem and the solution shouldn’t be outsourced to the AI. Software engineers still need to understand trade-offs, architecture, and code. 

The post What 4 engineers with 10+ years of experience say about staying relevant in the AI era appeared first on ShiftMag.

In 2025, Sonar surveyed over 1.100 developers worldwide to see how software engineering is evolving. The findings show AI is now central to development – but it hasn’t made the job easier, only reshaped it.

Developers now write code faster than ever. At the same time, they spend more time questioning, reviewing, and validating what gets shipped. Productivity has increased. Confidence has not kept pace. This tension defines the current “State of Code” research.

AI is no longer experimental, it’s operational!

• 72% of developers who use AI coding tools rely on them daily
• Developers estimate that 42% of the code they commit is AI-assisted
• They expect that number to rise to 65% by 2027

AI-assisted coding has shifted from novelty to routine. Among developers who have tried AI tools, most now use them daily. Many estimate that more than 40% of the code they commit includes AI assistance. They expect that percentage to grow significantly in the next two years.

Developers use AI across the full spectrum of work: prototypes, internal tools, customer-facing products, and even business-critical systems. AI no longer supports side experiments. It participates directly in production workflows.

Instead of fighting the tool, rethink how you use it. How Uber engineers shifted from writing code with AI to assigning it work: a different approach to the productivity problem.

This level of integration signals a structural shift in software engineering. Teams no longer ask whether to use AI. They focus on how to use it responsibly.

Do developers trust AI?

• 58% use it in business-critical services
• 88% use AI for prototypes and proof-of-concept work
• 83% use it for internal production systems
• 73% integrate it into customer-facing applications

Developers consistently report that AI makes them faster. Most say AI helps them solve problems more efficiently and reduces time spent on repetitive tasks. Many even report increased job satisfaction because they can offload boilerplate and mechanical work.

However, speed does not equal certainty. Nearly all developers (96%) express doubts about the reliability of AI-generated code. They acknowledge that AI often produces output that looks correct at first glance but contains subtle errors or hidden flaws. This creates a trust deficit.

Despite this skepticism, not all developers consistently verify AI output before committing it. The pressure to ship features quickly often outweighs the discipline of thorough review. As a result, teams face a new bottleneck: verification.

Reviewing AI-generated code frequently demands more effort than reviewing human-written code. Developers must reconstruct intent, validate assumptions, and check edge cases without knowing how the model arrived at its solution. AI compresses the time spent writing code but expands the time required to evaluate it.

In this environment, confidence – not velocity – becomes the true measure of engineering maturity.

AI doesn’t remove toil, it changes it!

75% believe AI reduces toil. However, time allocation data reveals a more complex picture:

• Developers still spend roughly 23–25% of their work week on low-value or repetitive tasks
• This percentage remains consistent regardless of AI usage frequency

One of the promises of AI tools involved reducing developer toil: repetitive, frustrating tasks such as writing documentation, generating tests, or navigating poorly structured codebases. Many developers believe AI reduces certain kinds of toil. They report improvements in documentation quality, test coverage, and refactoring efficiency.

However, the overall proportion of time developers spend on low-value work has not meaningfully decreased. Instead, AI shifts the nature of toil. Developers now spend less time writing boilerplate and more time validating AI suggestions. They spend less time drafting documentation and more time correcting generated code. Traditional frustrations have not disappeared; they have transformed.

This dynamic challenges simplistic narratives about AI productivity gains. AI does not eliminate friction. It redistributes it.

Teams that recognize this reality can adapt workflows accordingly. Teams that assume AI automatically saves time risk underestimating the verification cost.

Technical debt: reduction and acceleration at once

Positive impact:

• 93% report at least one improvement related to technical debt
• 57% see better documentation
• 53% report improved testing or debugging
• Nearly half report easier refactoring

Negative impact:

• 88% report at least one negative consequence
• 53% say AI generates code that appears correct but is unreliable
• 40% say it produces unnecessary or duplicative code

AI influences technical debt in both directions. On the positive side, developers use AI to modernize legacy code, generate missing tests, improve documentation, and refactor inefficient structures. These activities reduce long-standing debt and improve maintainability.

On the negative side, AI sometimes generates redundant, overly verbose, or structurally weak code. Developers frequently encounter code that appears correct but introduces subtle reliability problems. When teams integrate such code without rigorous review, they create new debt.

AI therefore acts as both a debt reducer and a debt accelerator. Managing this tension requires deliberate governance. Teams must treat AI contributions as first-class code changes subject to the same standards as human-written code. Automated testing, static analysis, and clear architectural principles become even more critical in this environment.

Technical debt already ranks among developers’ top frustrations. Uncontrolled AI usage can amplify that burden rather than alleviate it.

What is shadow AI?

Most used tools:

• GitHub Copilot (75%)
• ChatGPT (74%)
• Claude (48%)
• Google Codey/Duet (37%)
• Cursor (31%)

GitHub Copilot and ChatGPT dominate AI-assisted coding usage, but developers rely on a growing ecosystem of tools. Many teams use multiple AI platforms simultaneously, selecting each for specific strengths. This fragmentation creates flexibility but introduces complexity.

A critical risk signal:

• 35% of developers use AI tools through personal accounts
• 52% of ChatGPT users access it outside company-managed environments
• 57% worry about exposing sensitive data

Developers often access AI tools through personal accounts rather than company-approved environments. This behavior reflects demand for productivity but introduces governance risks. When developers paste proprietary code into unmanaged AI systems, organizations lose visibility and control.

Security concerns rank among the most significant worries associated with AI adoption. Developers themselves recognize the risk of exposing sensitive data.

Organizations must respond pragmatically. Banning AI rarely works. Developers adopt tools that help them work faster. Instead, companies should provide secure, sanctioned AI environments and define clear usage guidelines. Enablement, not prohibition, produces safer outcomes.

The experience divide

Less experienced developers:

• Use AI for understanding codebases
• Rely more heavily on AI for implementation
• Estimate a higher percentage of AI-assisted code

Senior developers:

• Use AI more selectively
• Focus on review, optimization, and refactoring
• Express higher skepticism

AI does not affect all developers equally. Less-experienced developers tend to adopt new AI tools more aggressively. They use AI to understand unfamiliar codebases, generate implementations, and explore new frameworks. For them, AI functions as both assistant and tutor.

More experienced developers integrate AI differently. They rely on it to review code, optimize performance, and assist with maintenance tasks. Their experience enables them to identify flaws more quickly and apply AI selectively.

Junior developers often trust AI more readily. Senior developers approach it more cautiously. This difference does not reflect competence; it reflects perspective.

High-performing teams combine both approaches. Junior engineers introduce experimentation and speed. Senior engineers provide oversight and architectural discipline. Together, they mitigate risk while capturing gains.

What this means for engineering teams?

The State of Code 2025 reveals a profession in transition. AI increases output but raises the bar for validation. It reduces certain manual burdens while introducing new forms of cognitive load. It offers opportunities to address legacy debt while risking new complexity.

The central lesson does not concern speed. It concerns confidence. Developers must treat AI as a powerful collaborator that requires supervision. Engineering leaders must invest in testing infrastructure, review practices, and secure tooling environments. Organizations must acknowledge that productivity improvements depend on disciplined integration, not blind adoption.

Developers no longer compete on how quickly they can type code. They compete on how effectively they can evaluate, refine, and ship trustworthy systems.

The tools have changed. The responsibility has not. Teams that focus on clarity, code quality, and secure AI integration will thrive in this new environment. Teams that chase velocity without verification will accumulate invisible risk.

The post 42% of Code Is Now AI-Assisted! appeared first on ShiftMag.

Picture a team arguing over whether to keep a global Redux store or roll out a context-only solution for a new React component. Minutes later, someone pushes a change that breaks the whole test suite.

A week later, another debate erupts about whether the REST API should be versioned or use a graph-based approach. And there’s always that one Git rebase that turns a quiet sprint into a full-blown firefight.

The line between brilliant innovation and productivity meltdown is thinner than you think – and ego is often the culprit lurking behind every heated Slack thread and passive-aggressive code comment.

What is egoless development?

Egoless development is not about surrendering conviction or becoming passive. It’s about letting the problem drive the solution, not the other way around. Gerald Weinberg, in his seminal work The Psychology of Computer Programming, wrote: “The most powerful learning occurs when someone produces a better solution than you had imagined.” If your ego can’t digest a “better” or “different” answer, you have no business leading a software team.

In practice, egoless engineering means:

• Staying open to new ideas – even if they come from a junior teammate or an external library.
• Focusing on the product’s value – not on proving your own architectural choices.
• Accepting feedback without defensiveness – because every line of code is a hypothesis, not a manifesto.
• Separating self-worth from code quality – your value isn’t measured by how rarely your code needs revision.

How ego shows up and undermines everything

Ego erodes trust, inflates the perception of individual contribution, and turns collaboration into a zero-sum game. The consequences ripple outward: missed deadlines, higher bug counts, knowledge silos, and ultimately, a loss of team morale that drives your best people toward the exit.

The psychology behind code ownership

When we write code, our brains treat it as an extension of ourselves. Neuroscience research shows that criticism of our work activates the same neural pathways as physical threats. This is why a simple “This could be refactored” comment can feel like a personal attack.

Understanding this psychological reality helps us build better defenses:

• Recognize the feeling – When defensiveness arises, pause and acknowledge it
• Reframe criticism as collaboration – Someone improving your code is helping you, not attacking you
• Build emotional distance – Use phrases like “the code” instead of “my code”
• Practice receiving feedback – Like any skill, gracefully accepting criticism improves with practice

Real examples of ego at work

Linus Torvalds, creator of Linux, became known for a harsh communication style on the Linux Kernel Mailing List, often going beyond technical feedback.

In 2015, during the “Brain Damage” incident, he dismissed a developer’s security proposal as “mindless security theater” and called it “brain damaged.” The developer stopped contributing, and the security concern became a real exploit two years later.

The fallout? Talented contributors left, community diversity dropped, and valid concerns were ignored based on who raised them.

After years of this, Torvalds took a break and issued a public apology in 2018, acknowledging that his ego had harmed the project and committing to a Code of Conduct.

Even brilliant technical leaders can cause real damage when ego outweighs empathy – but egoless engineering is a conscious choice.

Now let’s see egoless communication in action

This is my own example. It was 2:37 PM when my code hit production. By 3:00 PM, our monitoring  tool sent alerts all over and showed 50 errors. New users couldn’t sign up. Existing users couldn’t complete their profiles.

This is where most teams spiral. Blame gets assigned. Confidence gets crushed. Someone becomes the cautionary tale.

Not this team.

The team lead’s first message: “Okay, let’s work the problem. Ivan, walk us through what happened – no judgment, just facts. Everyone else, what do we need to stabilize right now?”

My response: “I skipped the integration test because I thought it was just an isolated signup flow change. Clearly, I was wrong. I can roll back immediately, then we need to figure out why our CI didn’t catch this.”

Ten minutes later, production was stable. The retrospective didn’t focus on my mistake – it focused on the process gap. Why weren’t integration tests enforced for all changes? How could CI catch this automatically?

System got fixed and the whole team started advocating for comprehensive testing.

Lead with purpose, not ego

The antidote to ego-driven culture is a purpose-driven mindset. Put the team first: “Ship better products. Learn together. Celebrate collective wins.”

Adopt core values such as:

• Open collaboration – Everyone’s input matters, regardless of tenure or title.
• Continuous improvement – No single person owns the ship; we all keep it afloat.
• Shared ownership – Success is a team metric, not a résumé headline.
• Blameless culture – Focus on systems and processes, not individual fault.
• Intellectual humility – “I don’t know” is a strength, not a weakness.

These values create a safety net that lets people experiment, fail fast, and iterate without fear of ego-related retribution.

How to cultivate egoless teams?

1. Morning coffee feedback sessions

Schedule a quick, informal chat with each teammate once a month.

Purpose: Surface concerns early, show genuine interest, reinforce the “we” narrative.

Pro tip: Keep it casual – grab actual coffee, go for a walk, or just sit outside the usual meeting room environment.

2. Code review as conversation

Treat every PR as a dialogue, not a verdict.

Instead of: “Why did you do that?”
Try: “I’m curious about your approach to X – what tradeoffs did you consider?”

Key practices:

• Assume good intent always
• Ask questions before making statements
• Provide context for your suggestions
• Praise the good before noting improvements

3. Process-focused retrospectives

Avoid blame, focus on improving the workflow.

Outcome: The team learns to iterate on their own practices, identifying systemic issues rather than scapegoating individuals.

Framework to try: Use “What went well? What could be better? What will we try next?” instead of “Who caused the production incident?”

4. Celebrate team wins

Highlight milestones that benefited the whole product, not individual heroics.

Effect: Reinforces that value comes from collaboration. Consider a “Team Win Thursday” where you spotlight collaborative achievements in your all-hands.

5. Rotate responsibilities

Give everyone a chance to lead a sprint, own a component, or make architectural decisions.

Result: Empowers diverse viewpoints and reduces power-centered thinking. It also prevents knowledge silos and builds empathy for different roles.

6. Create a “learning debt” board

Just like technical debt, track what the team needs to learn.

How it works: Anyone can add skills or knowledge gaps. The team prioritizes learning together through lunch-and-learns, workshops, or dedicated study time. This normalizes not knowing everything.

Purpose-driven teams really excel

The data backs up the philosophy:

• Faster problem solving – Collective knowledge surfaces solutions faster.
• Higher-quality products – Diverse eyes catch more bugs; studies show pair programming can reduce bugs by 15-50%.
• Happier teams – People feel valued beyond ego metrics.
• Lower turnover – People stay when they feel part of something bigger; psychological safety is the #1 predictor of team success (Google’s Project Aristotle).
• Innovation acceleration – When failure isn’t punished, experimentation flourishes.

In our own team, we’ve seen the difference. The “Misfit Days” workshops we introduced – short, daily stand-ups where anyone can bring a friction point- have slashed bug-backlog time by 35% and doubled the rate of new feature delivery. More importantly, our employee satisfaction scores jumped 28 points in six months.

Warning signs your team has an ego problem

Watch for these red flags:

1. Pull requests sit for days because no one wants to critique the senior dev.
2. “I told you so” moments are celebrated instead of collective problem-solving.
3. Knowledge hoarding where individuals protect “their” domains.
4. Defensive Slack threads that spiral into 47-message arguments over syntax.
5. Silent meetings where juniors don’t speak up for fear of looking stupid.
6. Resume-driven development where tech choices prioritize personal branding.
7. Hero culture where all-nighters and firefighting are glorified over prevention.

If you recognize three or more of these in your team, it’s time to intervene.

What should I do?

Ego is a silent saboteur that thrives in the quiet corners of code reviews and pull-request comments. It whispers that your solution is the only solution, that criticism is an attack, that admitting uncertainty is weakness. But the best engineering teams know differently.

By embracing egoless engineering – focusing on shared purpose, valuing every voice, and making collaboration the default – we turn potential productivity meltdowns into engines of innovation. The code improves, the products ship faster, and most importantly, people actually enjoy coming to work.

Remember: The best code you’ll ever write is the code you wrote with others. The best solution you’ll ever implement is the one that made someone else’s idea better. And the best career move you’ll ever make is building a reputation as someone who makes everyone around them better.

Starting tomorrow:

• Implement a monthly open-feedback routine – Put it on the calendar now.
• Audit your code review comments – Are you asking questions or issuing verdicts?
• Celebrate a team win – Find one this week and make noise about it.
• Try one new strategy – Pick from the list above and experiment for a sprint.

Every idea is respected. Constructive feedback is not just welcome; it’s required. Success is measured by shared achievements, not individual credit.

The post Developers, your EGO is the real bug in the system appeared first on ShiftMag.

By the end of 2025, I had read a lot about people building entire apps with AI, going from an idea to a product in just weeks or even days. That made me ask myself: how are they doing this?

I have more than ten years of experience in enterprise backend development. Seeing these fast, AI-built apps sparked my curiosity. I use AI in my day-to-day work, but only for small tasks, nothing close to building a full product.

So I thought, why not try it myself and see if it’s really possible?

I started thinking about what I actually wanted to build, and it quickly became clear that it had to be something I’d use myself. I’m a runner and I work in enterprise, so the idea came pretty naturally: a running app, but with a twist – tracking fitness while mapping it onto a corporate-style career journey.

That’s how RunCorp came to life.

AI as a fast MVP builder and UI scaffold

My main stack is Java and Python, but I deliberately avoided what I know best. I wanted something familiar, yet still a bit uncomfortable. For the backend, I chose Laravel, since I’ve done some freelance work with it. For mobile, I picked Flutter, even though I had never built a mobile app before.

I bought a Claude Code subscription and started building. I quickly learned that you can’t just tell it to do something and expect a good result. That realization led me to throw away the very first thing it generated.

What really works is using plan mode. You let the AI analyze the problem, ask you questions, and create a plan. Only after you feel happy with the plan do you let it generate code. It feels more like collaborating with a teammate than typing commands at a tool.

The downside is that this approach burns through tokens. If you don’t want to pay for extra usage, you have to wait a few hours for the limit to reset. Even so, I managed to build a basic MVP in six days.

I started with just the UI and mocked data. By the end of the first day, I had an app with all the MVP screens in place. You could actually “use” the app – move from screen to screen and see something -even though real functionality didn’t exist yet. Everything ran on mocked data. For this kind of work, AI proved very effective at generating basic Flutter layouts like this:

class HomeScreen extends StatelessWidget { 
@override
Widget build(BuildContext context) {
return Scaffold(
 appBar: AppBar(title: Text('RunCorp')),
  body: ListView(
   padding: EdgeInsets.all(16), 
    children: [
     Text(
      'Welcome back',
     style: Theme.of(context).textTheme.headlineSmall,
    ),
    SizedBox(height: 16),
    Card(
     child: ListTile(
      title: Text('Current Level'), 
      subtitle: Text('Senior Runner'),
      ),
     ),
    ],
   ),
  );
 }
}

Nothing complex, but very fast. This is where AI clearly shines: it scaffolds the UI, wires screens together, and handles repetitive setup.

Outdated libraries and testing challenges

After that, I worked screen by screen, building front-end and back-end functionality together. I followed the same workflow every time: create a plan, answer AI questions, refine the plan, answer again, and generate code only after I felt satisfied with the plan.

Here’s the first big problem for someone without much experience: when you use plan mode, the AI asks questions you might not know how to answer. It asks things like: do you want to use OAuth? How do you want to encrypt passwords? Do you want a separate table for user profiles, or do you want everything in one table? You have to make these decisions early. Otherwise, the AI generates something that either doesn’t work or becomes hard to change later.

One concrete backend issue came up during the Strava integration. When I asked the AI for help with Strava authentication, it suggested an existing Laravel package.

At first glance, the suggestion looked reasonable. But after I checked it more closely, I realized the package hadn’t received updates for several years and didn’t support the current Laravel version. It relied on outdated dependencies and failed in a modern Laravel setup.

This example shows where AI falls short. It suggests known libraries, but it doesn’t judge whether teams still maintain them or whether they fit today’s ecosystem.

Instead of forcing the package into the project, I implemented the Strava OAuth flow directly using Laravel’s HTTP client. The core token exchange looked like this:

$response = Http::asForm()->post('https://www.strava.com/oauth/token', [.                                  
    'client_id'	=> config('services.strava.client_id'), 
    'client_secret' => config('services.strava.client_secret'),
    'code'	=> $request->get('code'),
    'grant_type'	=> 'authorization_code',
]);

$data = $response->json();

A similar issue appeared on the frontend. The AI generated Flutter UI that looked great on a large simulator. Once I tested it on smaller phones, problems started to show up. Text became barely readable, layouts overflowed, and some screens turned difficult to use. A typical example looked like this:

Text(
'Weekly Distance',
style: TextStyle(fontSize: 24),
);

Hardcoded font sizes worked fine on larger screens but failed badly on smaller ones. Fixing this required a shift toward responsive design. I improved the layout by switching to theme-based typography:

Text(
'Weekly Distance',
style: Theme.of(context).textTheme.titleMedium,
);
 
LayoutBuilder(
 builder: (context, constraints) { 
  return Text(
   'Weekly Distance', 
  style: TextStyle(
   fontSize: constraints.maxWidth < 360 ? 16 : 20,
   ),
  );
 },
);

The UI technically worked before – it just didn’t work well everywhere. Issues like this only show up when you test on real devices.

When AI-generated code meets real users

After six days, I had an app with enough functionality to be tested by someone. I asked people from my running club if they wanted to try it, and they said yes. I sent them a beta build, and 25 of them started using it. That’s when the real problems began to appear.

After just two days, people reported that the home screen took a long time to load and that the stats screen kept crashing. That was the moment I realized this was the end of just talking with AI. I had to do what I’ve been doing for years: actually debug and review all the code.

The AI-generated backend code looked clean. It passed basic tests and worked perfectly with small datasets, so I shipped it. But once real users arrived, reality hit hard. Requests were timing out, the stats and home pages barely loaded on mobile, database CPU spiked, and every request ran over 20 queries. Classic red flags.

These were problems that wouldn’t have made it to production if I had written the code myself from the start. Experience teaches you where bottlenecks usually hide. AI didn’t optimize anything; it just made things work.

Here’s what the AI-generated backend code got wrong all at once:

• No eager loading, causing N+1 queries
• Queries running inside loops
• Loading entire models into memory just to calculate aggregates
• No caching at all
• Missing database indexes
• Recalculating values that were already stored
• Doing heavy computation in PHP instead of letting the database handle it

None of these were bugs – they were experience problems.

At that point, I had to step in and do what I’ve been doing for years: rewrite the entire statistics pipeline. Some of the key fixes were:

Eager Loading Instead of N+1

$user = $request->user()->load('profile');

Aggressive Response Caching

return Cache::remember("user_stats:{$user->id}", now()->endOfDay(), 
function () {
    // heavy calculations

});

Query Consolidation (7 Queries → 1)

$stats = DB::table('activities')

    ->where('user_id', $userId)

    ->selectRaw("

         SUM(distance_meters) as total_distance, 
         COUNT(DISTINCT DATE(start_at)) as active_days,
 
         SUM(CASE WHEN start_at >= ? THEN distance_meters ELSE 0 END) as weekly_distance
", [$weekStart])

->first();

GROUP BY Instead of Query Loops

->groupBy('week_num')

Using Stored Values Instead of Recomputing

$longestStreak = $user->profile->highest_streak ?? 0;

Strategic Indexes

$table->index(['user_id', 'start_at', 'distance_meters']);

The results were immediate

After these changes, the app finally felt usable in real conditions. The home screen loaded instantly, the stats screen didn’t crash, and the database handled multiple users at the same time. Experience made the difference.

I shipped a working app quickly, but I still had to do a lot of work myself. Coding the basics – the tasks any junior developer can handle – is easy, and that’s exactly where AI excels. It can speed up development, but you need to know when to step in, what to change, what to ask, and how to plan everything properly.

Coding isn’t even the hardest part, at least for mobile apps. You can build the app fast, but you must deploy the backend, set up servers, configure domains, and prepare everything for the app stores.

Then comes the part no one talks about: Google Play beta testing, Apple App Store review, waiting for developer accounts and licenses to get approved, fixing small issues reviewers reject, and updating screenshots, descriptions, and privacy policies. None of this is hard, but all of it takes time.

From the moment I started building to the moment the app went public, the process took just over a month, still very fast.

I realized that today AI becomes incredibly powerful in the hands of someone who knows what they’re doing. For experienced engineers, it can provide a huge speed boost, almost like a superpower. AI acts like a team of juniors handling repetitive work while you focus on high-level decisions.

Someone with solid experience can now build projects that used to require a small team. Can a non-technical person build an app with AI? Yes, to some extent. They can create something that looks decent and runs, but most of the time it will start falling apart quickly.

The main takeaway: the basics still matter. Understanding how things work under the hood makes all the difference. AI doesn’t replace experience, but it amplifies it, and that’s where it delivers real value.

The post How I Built a Full-Stack App in 6 Days with the Help of AI appeared first on ShiftMag.