Author: Ben Linders

Carlos Arguelles spoke about Amazon’s inflection points in engineering productivity at QCon San Francisco, where he explained that shift testing left can help catch issues early. He suggested using guardrails such as code reviews and coverage checks. Your repo strategy, monorepo or multirepo, will impact the guardrails that need to be in place.

When a company is new, it has to move fast, so there are very few guardrails in place. It’s also generally small enough where you know all the people touching a codebase, Arguelles said. As your customer base grows and more and more people depend on your product, it becomes increasingly important to adopt best practices and ensure everybody adheres to them, he added. Those guardrails don’t come for free: they add friction and reduce your ability to move fast in places, so there’s often a tradeoff here.

As a company grows, investing in custom developer tools may become necessary, as Arguelles explained in Inflection Points in Engineering Productivity:

Initially, standard tools suffice, but as the company scales in engineers, maturity, and complexity, industry tools may no longer meet needs. Inflection points, such as a crisis, hyper-growth, or reaching a new market, often trigger these investments, providing opportunities for improving productivity and operational excellence.

The software development life cycle at Amazon starts with an inner developer loop, where an engineer iterates on a piece of code in their own workspace. By default, engineers run unit tests, gather and gate on code coverage and execute various linters every time they create a build, Arguelles said. When they submit a code review, the code review tool runs a number of additional tests on that code.

When those validations pass and the engineer has thumbs up from their reviewer, the code gets pushed to a repo and CI/CD shepherds that code change through various testing stages and increasingly exhaustive tests, including load and performance tests, before finally pushing to production, Arguelles explained:

We expect most of our code changes to reach production within hours of checkin, as all the guardrails should be automated. Once they reach production, canaries further validate the changes.

Finding issues earlier is always better, Arguelles mentioned. And shifting testing left so that you can catch issues in the inner developer loop (pre-submit), and not in the outer developer loop (post-submit) becomes more and more important as your codebase grows:

This is because if a bad piece of code is submitted and merged, it now blocks N developers around you until it’s rolled back or fixed, and as your system grows, so does N.

Shifting testing left is non-trivial because in order for you to effectively and reliably run end-to-end integration tests against unreleased code you need to invest in ephemeral, hermetic test environments, Arguelles said.

One critical decision that Amazon made is that they operate in a multi-repo world, meaning every team has their own micro-repo. This is in contrast with other companies that have gone the route of a monorepo for the entire company (like Google).

Google uses a monorepo where ~100k engineers use a single repo with no branches. Everybody has to be committed to the health of the repo, because the blast radius of a bad code checkin is enormous; you could literally block thousands of people, Arguelles said. Pre-submit end-to-end testing is not just “nice-to-have,” but business-critical.

Amazon, on the other hand, chose to go the route of multirepos, with every team having essentially their own repo, Arguelles mentioned. This acts as a natural blast-radius reduction mechanism: a bad checkin can break an individual microrepo, but there are more guardrails in place to prevent it from cascading into other team’s microrepos.

Arguelles mentioned that there’s unavoidable complexity in large systems. How you choose to do your development determines where in the software development lifecycle you need to deal with that complexity. Neither company was able to avoid it, but they’re tackling it either pre- or post- submit, he concluded.

InfoQ interviewed Carlos Arguelles about guardrails and micro vs mono repo.

InfoQ: How do guardrails at Amazon look?

Carlos Arguelles: For example, when Amazon was a much smaller company in 2009, you could quickly ssh to a production host to investigate an issue, tail logs, etc. Any manual interaction is inherently a dangerous thing to do – imagine you type the wrong command or accidentally press an extra “0” and bring down that host or cause data loss. So we put guardrails such that if you want to run a command on a production host, it needs to be code reviewed and there’s an auditable record of your action.

Another example is you cannot submit code directly to a repo without going through code review and having a thumbs up from another person. Or we now gate on code coverage drops to ensure all code going to production meets a minimum test coverage bar. Tooling like this provides scalable ways to encode and enforce best practices.

InfoQ: What are the implications of working with micro repos compared to monorepo?

Arguelles: This is a place where the two places where I worked, Amazon and Google, differed significantly because of a foundational decision made by both companies decades ago: Google using a monorepo and Amazon micro repos.

This decision impacts guardrails that need to be in place. For Amazon, end-to-end pre-submit testing was “nice-to-have,” but it was not business-critical.

The decision to have micro repos at Amazon did not come for free, though. In a monorepo, every service is naturally integrated, whereas in a multirepo world, you need to coordinate how changes safely cascade from repo to repo.

Inclusion isn’t something you do once; it should be woven into everything, from how you make decisions to how you structure teams and run meetings.. When people feel seen and heard, they contribute more fully and meaningfully, which sustains long-term success. Matthew Card gave a presentation about leading with an inclusive-first mindset at Qcon London.

Inclusive leadership is the ongoing effort to create and maintain an environment where people feel comfortable bringing their authentic selves to a professional setting, Card explained:

An environment where everyone feels fulfilled, empowered to succeed, and genuinely enjoys coming to work.

Working environments can be tricky to navigate, especially as we continue bringing together more diverse individuals and asking them to lead, work, and create software collaboratively. That’s why it’s so important to lead with an inclusive-first mindset, Card said, as even seemingly routine team decisions can have a significant impact on the culture you’re trying to build and on how your team grows:

From who runs and facilitates meetings, to how implementation decisions are made, all the way up to tech stack selections, interview processes, and hiring choices, I have made a conscious choice to optimise for engineers who have great communication skills, and we are reaping the benefits now.

You’re not always going to get it right, and some things will be outside of your control, Card said. It’s a continuous effort. It’s about balance and constant adjustment. At the core, it’s about having fundamental respect and respecting each other’s differences, Card mentioned.

Something that worked last month might not be right or relevant three months later, and that’s okay. When you think about it, this actually mirrors the nature of the tech world with agile development, Card explained:

I continue to believe that we in tech have unrealised potential. The processes and approaches we use every day could be adapted to create real impact far beyond technology. We just need the courage to step outside our comfort zones and apply our ways of working to new challenges. As a leader, courage is of utmost importance.

Card mentioned that the way to build a culture that sustains long-term success is to embed it within your team so that it grows from within. This allows you to support and nurture it over time.

There are many ways to do this. Card mentioned two guiding principles that he leads by:

• How you make decisions shapes your culture
• Culture is defined by the worst behaviour you’re willing to tolerate

Decisions are crucial, and how you make them matters even more, as Card explained:

• Individually, as a leader, it’s about being fair and staying true to your values. That helps guide you in making the best possible decisions—not necessarily the “right” ones. We can only decide based on the information available at the time. I rely on an honest, self-aware, and pragmatic approach.
• Collectively, it’s about how your team makes decisions together. Embedding inclusive, transparent decision-making at the group level helps reinforce trust and psychological safety, which are essential for a strong, resilient culture.

When it comes to behaviour, Card suggested setting clear standards and modeling them consistently. Culture is reinforced by what we reward, what we challenge, and where we hold the line, he said. At the same time, lead with empathy, and help people grow when they fall short. Leverage allies within the team to raise the bar and support a culture of accountability and continuous improvement, Card suggested.

Look for people who demonstrate the qualities and behaviours you want to see in your culture, and use them as examples of what good looks like, Card said. Bringing them along with you to build and shape your department or area can be effective, he concluded.

InfoQ interviewed Matthew Card about inclusive leadership and long-term success.

InfoQ: How do you practice inclusive leadership?

Matthew Card: My approach is to lead with an inclusive-first mindset, meaning that every aspect of my role involves Diversity, Equity, and Inclusion (DE&I).

Personally, I always strive to build as many meaningful, trust-based relationships as I can, by reaching out, connecting, and taking the time to show I genuinely care.

The key to doing this without burning out? Be real. Be you. Authenticity makes the connection sustainable.

InfoQ: How can leaders create a culture that sustains long-term success?

Card: For me, the foundation that underpins a culture capable of sustaining long-term success, and what I am truly passionate about, is motivation and resilience.

Being able to appreciate that you can’t always get it right immediately, and being comfortable with that, is key. Having mechanisms and processes in place to learn from the moments when things don’t go as planned is a major part of becoming more resilient.

This concept carries through all levels of the team. For those on the ground who are coding day to day, failing fast is critical to delivering quality code. For team leads and senior leadership, where the feedback loop is much longer, it’s imperative to have multiple strategies in place to deal with problems and issues that will surely arise in the middle of executing your plan.

Security can clash with development efficiency. Focusing on minimizing breach impact can be more effective than prevention. Dorota Parad argues for flexibility in compliance and collaborating with security teams to define practical protections. Limiting blast radius and using automation can boost security with minimal productivity loss.

At QCon San Francisco, Dorota Parad presented how to build secure software without sacrificing productivity.

Security can be at odds with a fast and efficient development process. Focusing on minimizing the impact of breaches can be more effective than trying to prevent the breach in the first place. In Ensuring Security without Harming Software Development Productivity, Dorota Parad explored creating a foundation for security without negatively impacting engineering productivity.

Parad suggested pushing back on security mandates, as they can hinder productivity. This starts with understanding where those mandates are coming from:

The job of a CISO and your security team is very rarely about security; they are there to ensure compliance. Contrary to popular opinion, compliance doesn’t just mean mindlessly ticking checkboxes, the checkboxes are just (one) means to an end.

It all boils down to crafting a narrative that will convince third-party stakeholders – auditors, regulators, insurance companies – that your company does a good enough job minimizing security risks, Parad said.

None of the security certifications or regulations are prescriptive; it is up to your company to define the scope, means, and implementation, Parad said. It can be a daunting task, so it may be tempting to optimize for the ease of audits and do something like force invasive MDM (mobile device management) software without considering how it will affect engineers’ productivity, she added.

If you want to get rid of some of the more annoying mandates, you need to start a dialog with your security team and help them craft that convincing narrative they’re after, Parad suggested. This means documenting how you think about risks in your area, what you’re doing to reduce the blast radius of breaches, what levels of protection you have in place, and how you’re minimizing the impact of incidents.

Parad explored what can be done to minimize the impact of security breaches. She gave the example of a common threat: a malicious actor getting their hands on one of our engineer’s cloud account credentials:

What’s the worst that can happen here? If we applied the principle of bulkheads, then those credentials are limited in scope to a single cloud account, which may or may not host our production environment.

Parad mentioned that if we utilize modern software development practices, the access would be limited to read-only and innocuous configuration changes, since resource creation and deletion would be automated and only permitted as part of CI/CD pipeline.

If that account includes access to a database containing user data, and if we applied proper encryption, the data is effectively useless to the attacker, Parad added.

Trying to prevent the incident would be a prohibitively costly endeavor, involving multiple remediations to account for all the different attack vectors, Parad said. Limiting the impact is a holistic solution that doesn’t take as much effort or cost, and often comes with additional benefits of increased robustness, she concluded.

InfoQ interviewed Dorota Parad about how security and engineering productivity can go together.

InfoQ: What’s your approach to pushing back on security mandates that hinder productivity?

Dorota Parad: You can only push back on mandates if you have an alternative way to minimize security risks. This is where the BLISS framework (bulkheads, levels, impact, simplicity, and pit of success) helps, by offering an alternative that doesn’t get in your engineers’ way. With Bliss, you can make your security strategy almost invisible to the engineers while embedding it deep into the culture at the same time, Parad said

InfoQ: Can a CI/CD pipeline be considered a security practice?

Parad: This sometimes raises eyebrows among security folks, but yes, I consider a CI/CD pipeline a security tool. Implemented properly, it severely reduces the risk of malicious code ending up in your production.

A typical build/deployment pipeline involves increasingly strict levels of protection the closer to production the code gets – we start with git access controls to make a commit, then developer credentials to create a pull request, we have automated testing that may catch some issues, and finally a second set of credentials and a human review to merge. That’s a very powerful way to minimize security risks.

InfoQ: How can we increase security with a CI/CD pipeline?

Parad: Every single piece of code needs to go through that pipeline in order to reach production, no exceptions. No manual tinkering to push the build through, no bypassing of steps, no logging onto the servers to copy files or run some scripts.

The only way to achieve that in practice is by keeping your CI/CD pipelines healthy and robust, so that they only fail when something is truly wrong. Flaky pipelines are the enemy of both security and productivity.

Ola Hast and Asgaut Mjølne Söderbom gave a talk about continuous delivery with pair programming at QCon London. Their team uses pair and mob programming with TDD; there are no solo tasks or separate code reviews. This approach boosts code quality, reduces waste, and enables the sharing of knowledge. Frequent breaks help to maintain focus and flow.

The team does code reviews together, rather than sending pull requests back and forth, Mjølne Söderbom explained:

When Ola and I started on the same team in 2021, we decided to work together on everything. Not all agreed, so some of the team still worked alone, but if Ola or I were involved, they had no option – then it was pair programming.

Mjølne Söderbom mentioned that it is very powerful to have at least two team members who want to do pair programming. It can be difficult to try to convince a whole team by yourself. They also use pair programming heavily in the onboarding of team members. After a while, everyone understood this was the way to go, he said.

All tasks are suitable for working together, and no one ever sits alone with responsibility for a given task, Mjølne Söderbom said. A task always has at least two persons involved. If one is unavailable, the other can code alone, and then we just sync together again (for instance, if one person has to go to a meeting).

There are four developers in his team, a perfect size according to Mjølne Söderbom. If all four are available, they split into two pairs. Sometimes they do a mob with all four, if they are working on something new, or where they need to make bigger decisions. This way, they can spread knowledge before splitting up. If there are three, they always work as a mob, he said.

Mjølne Söderbom explained that they switch driver and navigator every 7 minutes, and every 10 minutes when in pairs:

When we are in the office, we use a cheap kitchen timer to keep track of the time. A few other teams on our floor have bought the same timer now, so it’s kind of funny when you hear the timer go off all the time! We also pair program when someone is remote, usually just with screen sharing in MS Teams.

If they have to switch machines when changing driver, they have a few aliases to quickly commit and push to git, Mjølne Söderbom said. They all have different keyboards and keymap setups, and sometimes it is just easier to move to another desk when switching. Aliases over the github cli also help us quickly create and approve/merge a pull request when they are done, he mentioned.

They do TDD on everything, and they love it, Mjølne Söderbom said. They spend no additional time on review since it is all done as part of the process. Since they pair and do TDD on absolutely all code, they do all review and architecture decisions as they go, he explained:

Some still claim that pair programming is only suitable for certain, often complex tasks. We learned that this is not the case; all tasks are suitable for working together on. In the long run, this drives speed and knowledge sharing in a completely different manner than before.

He has always been interested in clean code and code quality, and pair programming goes hand in hand with this, Mjølne Söderbom said. He cannot think of any other methods or tools that provide higher quality than working together, he concluded.

InfoQ interviewed Ola Hast and Asgaut Mjølne Söderbom about how they work in their team.

InfoQ: What’s your approach for measuring and reducing waste?

Ola Hast: The thing about working together with pairing is that when things like builds or processes take time, one starts talking about it. The first time is often fine, but when something takes time several times in a row, then it becomes a problem. We then start talking about solutions and workarounds.

Very often, what takes too long is a gut feeling, and handovers are often not noticed until you experience them firsthand. If you cannot do a repeating task without involving someone outside of the team, or if a specific task in the team requires a specific person, then this is a problem that causes delays and waste.

When people are working alone, we see a much higher acceptance of waiting, slow builds, and so forth. Working together really pushes us naturally to reduce this waste.

InfoQ: Does code need to be approved before it goes into production?

Asgaut Mjølne Söderbom: All forms of working in isolation (alone) mean that you have someone else to review and approve your code. Most companies have reviews as a compliance requirement. When pair programming, this is already done as part development.

InfoQ: How important is it to take breaks?

Hast: Working together, especially when you are really focused, is quite intense. So taking proper breaks where you are away from screens and keyboards is important.

Go for a walk around the block, get some fresh air. Whatever you do, don’t try to do other stuff, like checking email or Slack.

Artificial intelligence excels at refining language and processing large text volumes, but lacks human-like contextual reasoning and emotional intelligence, Avraham Poupko said. Many human traits come into play when doing software architecture. As an architect, he suggests using AI for exploring tradeoffs and refining language with clarity and precision.

Avraham Poupko shared his experiences from using artificial intelligence in his daily work as a software architect at OOP conference.

Software architects and system architects will not be replaced anytime soon by generative artificial intelligence (AI) or large language models (LLMs), Poupko explained in How a Software Architect Uses Artificial Intelligence in His Daily Work. They will be replaced by software architects who know how to leverage generative AI and LLMs, and just as importantly, know how NOT to use generative AI.

AI is helpful when exploring tradeoffs, or when trying to find the right way to say something with precise language as in using the correct word and sentence structure, Poupko mentioned. As a language model, AI is very helpful and provides a great deal of clarity:

As an experiment, I provided Gemini with the above paragraph and asked it to suggest an alternate wording. The result is:

Gemini>>”While AI cannot yet replace human architects due to the deep system, domain, and organizational knowledge required for effective design, it’s a valuable tool for exploring tradeoffs and refining language, providing clarity and precision in documentation.”

While the paragraph provided by Gemini might be more concise, it still needs some work. For example, notice the word “yet” that Gemini added to the sentence. “I do not think it belongs there at all,” Poupko said. If one can be offended by an LLM, he is offended by that, he added.

As humans, we are very good at “Contextual Reasoning”. That means that we are good at taking a great deal of context as well as previous experiences and considering optimal behaviour, Poupko explained:

We know how to read a situation, body language and gauge appropriate behaviour. That is an area where AI is currently very poor at.

AI is most useful in tasks that involve written language. When it comes to reading a large amount of text and using the knowledge encoded in those texts, we might find that AIs are better than humans, Poupko said.

As an architect, he has learned that so many of his human traits come into play when he does software architecture, Poupko explained:

I learned about the importance of my ability to communicate. I learned about the importance of my Theory of Mind, meaning my ability to create a mental representation of other people’s mental model.

AI has made it clear to me that true “understanding” goes beyond understanding texts and technology. It is about understanding context and people, Poupko concluded.

InfoQ interviewed Avraham Poupko about using AI as a software architect.

InfoQ: How can we leverage our human strengths in a world enhanced by AI?

Avraham Poupko: Where AI is good at encoding knowledge from a large amount, humans are better at contextual reasoning.

For example, I provided the following prompt to Gemini:

Avraham>> I am building a web based AI agent. That knows how to take a problem or challenge from the user and use AI to ask clarifying questions, and then use AI to respond. Can you provide some system requirements for me to get started with?

The answer I got from Gemini was useful, and it can be seen that it collected a great deal of knowledge from a great deal of sources:

Gemini>>

Choose a simple framework: Start with a lightweight frontend framework like React or Vue.js, and a backend framework like Flask.

Select pre-trained models: Utilize pre-trained models for NLP tasks from Hugging Face Transformers or other libraries.

Build a basic API: Create a simple API endpoint to handle user input and return basic responses.

Develop a basic UI: Create a basic web page with input and output fields.

Iterate and improve: Gradually add more features, refine the user interface, and improve the AI capabilities over time.

These are all good and helpful answers that are certainly appropriate.

When I asked the same question to a good friend who knows me well, she answered quite differently:

Friend>>Avraham, you know, that is an interesting idea that touches on the relationship between humans and LLMs. I think a good place for you to start would be to clarify to yourself exactly what will your "agent" do and what the LLM will do. I think you should start on your local PC. Don’t do any development. Spend a lot of time investigating how you can get the LLMs to ask provoking questions that will clarify your own thinking. If you can do some of that before OOP in Munich that would be cool. You can present findings in the talk, and maybe get some good feedback or partnerships. By the way - is the word "agent" the right word here? Maybe use something cool like "pre-thinker" or something.

Between my friend’s answer and the AI’s answer, I was able to have a really interesting conversation about the practical and theoretical aspects of using LLMs and what the role of an agent might be in the interaction.

InfoQ: What have you learned about generative AI’s abilities and limitations?

Poupko: I learned that AI is constantly able to surprise me. That AI is sometimes astonishingly good at gathering and articulating known information and applying it to a new situation.

However, conversing with AI is not the same as conversing with a human. AI is not curious about the world, and will never be my “friend” in the sense that we can share a common sense of value or of purpose.

Artificial intelligence’s (AI) energy and water consumption has become a growing concern in the tech industry, particularly for large-scale machine learning models and data centers. Sustainable AI focuses on making AI technology more environmentally friendly and socially responsible.

Zorina Alliata and Hara Gavriliadi gave a talk about sustainable AI at OOP Conference.

The energy and water usage depend on the particular AI system, its size, and deployment method, as Gavriliadi explained:

Estimates from Gartner suggest that AI and data centers account for 2-3% of global electricity use, which can rise dramatically in the coming years.

AI’s water usage for cooling is significant, with a single AI conversation potentially using up to 500ml of water.

This rapid growth in resource consumption highlights the need for more sustainable AI practices, energy-efficient technologies, and improved resource management in the tech sector, Gavriliadi mentioned.

Alliata mentioned that model complexity requires more computational power and energy to train and operate these models. She said the data center expansions and requirements for cooling contribute significantly to their overall energy usage and water consumption. As AI tools and applications become more integrated into everyday online experiences and business operations, the cumulative energy demand increases substantially, she added.

Sustainable AI focuses on the long-term effects of AI, including environmental and societal effects, Gavriliadi said. She mentioned that techniques such as sparse modeling, hardware optimization, and responsible AI practices are crucial in achieving this balance between technological advancement and environmental stewardship.

There are cutting-edge methods for lowering AI’s energy footprint, Alliata explained:

The development of more energy-efficient chips and cooling systems is essential for hardware optimization, as it lowers the power consumption of the actual AI infrastructure components.

We now study quantum and neuromorphic architectures, photonic systems, and high-performance computing clusters of servers that process information differently, to speed up the compute power significantly.

Simplifying the computational procedures and algorithmic advancements, such as developing more effective training and inference algorithms, can lower energy consumption, Alliata said. She mentioned algorithm enhancements such as transfer learning, which uses pre-trained models to reduce training time and, consequently, the overall energy demand, and model distillation, which shrinks the size of AI models without significantly reducing performance. Modularity is also crucial, she said; the use of interchangeable parts makes upgrades and repairs simple, prolonging hardware life and cutting down on waste.

Alliata mentioned that creating biodegradable AI with organic electronics and environmentally friendly packaging reduces waste, and incorporating green energy by using renewable sources to power AI infrastructure is crucial for sustainability in general.

Gavriliadi said there are several tools for estimating the environmental impact of AI solutions. These include carbon calculators that estimate emissions based on energy consumption and location-specific grid data, energy profilers that monitor and analyze energy consumption patterns during AI model execution, and offset estimators that calculate the number of trees needed to offset AI-related carbon emissions:

AWS offers a way to measure the carbon footprint of your workload, and optimize workloads on their platform which can lower the carbon footprint by up to 99%.

Sustainable IT requires a cultural and mindset shift, Gavriliadi said. She advised developing a strategy for AI applications across business, technology, and sustainability, to set, monitor, and assess progress with metrics to calculate carbon intensity and check power usage effectiveness, and train and educate employees on sustainable IT practices, she concluded.

InfoQ interviewed Zorina Alliata and Hara Gavriliadi about sustainable AI.

InfoQ: How much energy and water does artificial intelligence consume?

Zorina Alliata: AI training and inference calls for significant computational capability with high energy consumption. A 2019 study, for instance, calculated that training a single AI model can emit as much carbon as five cars in their lifetimes. In another study, the International Energy Agency estimated that AI training consumed as much energy as a small country.

The development of the OPT-175B model resulted in an estimated 75 tCO2e, which doubled to 150 tCO2e when including baselines and downtime.

According to carbon emissions and large neural network training, GPT-3 has used an estimated 552 tCO2e or 1,287 MWh in energy consumption. This is equivalent to the electricity consumed by 121 U.S. households in an entire year.

Hara Gavriliadi: Data centers also require a lot of water for cooling systems. According to the 2023 Amazon sustainability report, AWS data centers use 0.18 liters of water per kilowatt-hour. In a blog post about its commitment to climate-conscious data center cooling, Google said that 4.3 billion gallons of water were used worldwide in its data centers for 2021. This number reflects their whole activities, not only artificial intelligence, but also provides an idea of the magnitude of the issue.

InfoQ: What’s your advice to companies that want to work toward sustainable IT?

Gavriliadi: Companies that want to work toward sustainable IT should first align their IT purchasing with their sustainability goals. They should then focus on measuring, predicting, and reducing carbon emissions associated with their IT infrastructure and cloud workloads. Companies should also implement environmental best practices for cloud computing.

At AWS, using the “Sustainability Pillar” of the Well-Architected Framework can help guide these efforts. Companies can also benefit from using digital tools and data analytics to analyze and optimize their energy consumption.

To grow their career, Bruno Rey suggests that software engineers should develop ambition, increase their capacity, and seek opportunities. He advises being proactive, broadening your influence by learning from peers, and stepping outside your comfort zone. Software engineers can keep a brag doc to ensure that their work is visible and plan their growth with realistic long-term goals.

Bruno Rey spoke about how software engineers can grow their careers at QCon San Francisco.

Rey mentioned three factors that drive the personal growth of software engineers: ambition, capacity, and opportunity. Ambition for him means understanding that making an extra effort to become a better version of ourselves will pay off. Capacity is the ability to perform the tasks that are expected of an employee one level above you, or at the very least, the ability to learn it quickly. But even a perfect employee can find difficulties in climbing the ladder if they don’t find a good opportunity, Rey said.

As an individual, if you’re having trouble maintaining ambition consistently, the underlying factor might be a lack of motivation, and you should evaluate why you’re going through that, Rey suggested.

Employers and mentors should look for signs of ambition during recruiting. If you have someone working at the company who is a good worker but fails to show ambition, try to make an extra effort to explain the benefits and maybe make them see examples in real life, Rey said.

Rey suggested that software engineers have to take agency to grow personally:

Some people prefer the approach of victim-player, some call it “high-agency”, others use the term “proactive”; they’re all similar. This was made very popular with the famous “7 habits…” book by Covey, with “be proactive” being the very first habit.

We all have an area of influence, Rey said. There are things we can change and things we can’t. What happens in most cases is that engineers think that their area of influence is smaller than it actually is, and move around in the small subsection of their comfort zone:

If you’re willing to take a few uncomfortable steps, you can probably start broadening your influence by a lot. You may take a few false steps as part of this process, but if done in good spirit and with judgment, any healthy work environment should forgive those.

To broaden their influence, software engineers can talk to their manager or to a superior peer, Rey suggested. See what they do and how they operate. Try to take some tasks off their plate and do them yourself. If you don’t know how to do it, train that muscle and learn, he mentioned.

Saying “teach me how to do this” sometimes sounds lazy, so it’s better to learn as much as you can on your own and then coming to them with some specific questions or for validation that your understanding is correct, Rey said. Make sure you don’t step on their toes and don’t make your work public before getting validation from them.

To plan their career growth at a sustainable pace, software engineers should develop a long term vision:

Where do you see yourself in 3 years? And in 5 years? Make sure it’s achievable. Then trace your way back and propose intermediate goals: what do you need at the end of this year in order to achieve that 5y goal? Again, make it achievable. Discuss them with your superiors.

When planning your career, understand that things won’t always go smoothly; there will be setbacks and delays outside of your control. Just like project planning, make room to accommodate for that, Rey concluded.

InfoQ interviewed Bruno Rey about how software engineers can broaden their influence and ensure that their work is recognized.

InfoQ: How can software engineers broaden their influence?

Bruno Rey: Opportunities to broaden your influence are easier to come by in smaller companies or startups where responsibilities aren’t so segmented, and sometimes everybody does everything.

Back in 2013, I was working as a developer in one such company and would normally step out of my role and do tasks that were more associated with Ops: parse logs, restart servers/processes, or gather information about bugs. I was not afraid to just do what needed to be done, even if formally it was someone else’s task. My superiors saw this as a great trait; luckily this type of behavior was encouraged at that company.

InfoQ: What can software engineers do to ensure that their work is recognized?

Rey: Nobody gets a promotion by doing a lot of invisible work. If you want to show ambition you have to be sure that you’re vocal about the work you’re doing, even if that isn’t something that comes to you naturally.

In my case I tend to favor long tenure in jobs, and try to stay in the same company for many years to have a relevant impact. Over the years I found that a brag doc was completely necessary. Especially if you stay in the same place longer than your manager, as this helps a new manager gain context quickly on how you work and in which areas you shine.

A couple of good articles on this are Get your work recognized: write a brag document by Julia Evans and Publishing your work increases your luck by Aaron Francis.

Leadership observability means observing yourself as you lead. Alex Schladebeck shared at OOP conference how narrating thoughts, using mind maps, asking questions, and identifying patterns helped her as a leader to explain decisions, check bias, support others, and understand her actions and challenges.

Employees and other leaders around you want to understand what leads to your decisions, Schladebeck said. Leadership observability is treating oneself as the system that is under observation, she explained:

It’s being able to ask questions and get meaningful answers because “my brain” is capable of telling me why I acted / reacted / communicated / decided the way I did.

Heuristics give us our “gut feeling”. And that’s useful, but it’s better if we’re able to take a step back and get explicit about how we got to that gut feeling, Schladebeck mentioned. If we categorise and label things and explain what experiences lead us to our gut feeling, then we have the option of checking our bias and assumptions, and can help others to develop the thinking structures to make their own decisions, she explained:

I had a colleague who had to decide which of their team to put forward for a customer project. I was able to share my context of assessing the person on their technical skills and their ability to represent the company.

Schladebeck recommends that leaders narrate their thoughts to reflect on, and describe their own work to the ones they are leading. They can do this by asking themselves questions like, “Why do I think that?”, “What assumptions am I basing this on?”, “What context factors am I taking into account?” Look for patterns, categories, and specific activities, she advised, and then you can try to explain these things to others around you.

To visualize her thinking as a leader, Schladebeck uses mind maps. She groups things and experiences together, and makes different branches for different topics:

I categorise the mindmap branches with categories of what I’m doing, such as “making decisions”, “dealing with conflict”, “managing time and tasks&rquot;. Then I collect activities within them like “collecting options”, “pros and cons”, “personal preference”. And then I add examples as they happen.

Schladebeck also describes general continuums of thought, such as “planning versus exploring” and “directing versus letting others lead”. Using these things, she tries to make her inner workings clearer for others.

Observing her self-confidence as a leader, Schladebeck found out how she increases it:

I try to remind myself that I’ve managed all my hard days and tasks so far. I call my coach or my friends if I need extra support. And a look at the world stage reminds me that there are people in much higher jobs with much lower qualifications than me!

She also observed how she deals with conflicts, which is something that she is still working on to further improve it:

At the moment my focus is to listen carefully and ask for the facts / concrete examples on both sides. Based on those, we can start conversations.

Schladebeck mentioned that by observing how she leads, she has learned which activities are hard for her (like “keeping quiet and letting others decide!” and “interacting to understand when I disagree”) – and, more importantly, why they are hard. Once she can identify why she doesn’t manage a specific thing very well, she can choose to work specifically on those aspects. It helps her to be aware of “what I’m doing” on a daily basis:

Being able to link your current activity back to a higher goal is very important in leadership work!

InfoQ interviewed Alex Schladebeck about what she learned from observing how she leads.

InfoQ: How do you balance making decisions versus having other people decide?

Alex Schladebeck: I’m still working on this! I’m currently trying to leave a gap, some seconds, before I jump into the conversation with my input. This leaves room for others, and for my brain to catch up to the situation and think about whether my input is needed right now.

InfoQ: What if a decision may disappoint people, how would you handle it?

Schladebeck: It’s not often that absolutely no one is disappointed! This is why being clear and explicit about how and why you make decisions is important. What is the context? What are the risks or opportunities?

And – of course we’re going to disappoint people, and it’s ok that they are disappointed. I don’t try to convince them otherwise. Accepting the feeling doesn’t mean that you’ll change the decision. It does mean you understand the human who is affected.

InfoQ: Has there been an observation that surprised you?

Schladebeck: When my then-boss would cancel a meeting at short notice, I would wonder why he did that. It didn’t feel respectful. And then I was the proud owner of the manager-level calendar when my role changed… I realised that short-term management of your calendar is necessary. Sometimes you have three meetings planned in parallel! And only really on the day do you find out which ones are really happening.

On the other hand, if you try to clear your calendar weeks in advance to make sure you only have one meeting at a time, the effort is often wasted. By the time the week in question rolls around you have three again!

I’ve also become a short-term calendar manager. What I try to do though is be very clear about how and why that happens. And if I have people who really don’t like it, then I make sure their meetings don’t get moved at short notice. That, however, does mean that they might get moved more.

Becoming a principal engineer requires more than technical skill, it’s about influence, communication, and strategy. Success means enabling teams by shaping culture, Sophie Weston said. In her talk at QCon London, she suggested developing deep skills in multiple domains, with general, collaborative skills. Skills from life outside work, like sports, volunteering, or gaming, can add valuable perspective and build leadership potential.

Principal engineer is often the highest level of the individual contributor path. Getting there needs more than just having deep technical expertise, as Weston explained:

It’s about influence, communication, and strategy. It’s about understanding that your career isn’t just about climbing; it’s about navigating, adapting, and growing in ways that matter to you.

Principal engineers focus less on what teams build and more on how they build, Weston said. It’s helping teams do great work, creating an environment where people thrive. By reducing friction, they help teams and the wider organisation move faster, avoid unnecessary obstacles, and stay on track.

According to Weston, engineering leadership consists of:

• Setting technical direction. This is about guiding teams and helping them to make smart architectural and technical choices.
• Driving good engineering practices. Helping teams build software efficiently and deliver real value – both to the business and its customers.
• Shaping culture. Mentoring, coaching, and making the organisation a place where engineers thrive.

Weston mentioned that as a principal engineer, she’s passionate about creating a good engineering culture that is good both for the organisation to deliver value effectively and efficiently and for the people working in it:

We want to have impressive DORA metrics, but not at the expense of burning people out.

Engineers need to broaden their skill set if they want to advance towards engineering leadership. Technical knowledge, no matter how deep, no matter how impressive, is not going to be enough, Weston said. She suggested developing deep skills in multiple domains, with general, collaborative skills as well:

Being Pi-shaped is valuable, but leadership demands more breadth. You need to become a “broken comb”—someone with expertise in multiple areas and the ability to connect insights across domains.

As a “broken comb”, you don’t just have expertise in multiple areas; you have varying depths of knowledge to bridge gaps, connect ideas, and solve problems creatively, Weston said.

Weston argued that people should bring their whole selves to work. She mentioned things that people do outside of their job, where they can learn and practice useful leadership skills:

If you’re part of a sports team, you will be building skills in team working and resilience. If you do volunteering, say in a youth group for example, you’ll develop skills in coaching and problem-solving. Maybe gaming is your thing, in which case you are likely to have strong skills in strategic thinking and adaptability.

Getting involved in the tech community and helping to organise events is a fantastic way to learn and practice new skills, Weston mentioned.

Don’t undervalue skills that you learn in other parts of your life and how they can help you in your career journey. We often talk about the importance of psychological safety and the need for people to be able to bring their whole selves to work and be themselves at work, this applies in a wider career context too, Weston said.

The skills you learn outside of work are equally valuable as the ones you learn through actually doing your job, Weston said. Sometimes they are more valuable because they represent more teeth on your “broken comb”. It’s not just the skills themselves that are valuable, but the additional perspective you have from having acquired them in a different setting, Weston concluded.

Today’s software professionals navigate a maze of technical, business, and social complexity. According to Xin Yao, thriving in this environment requires more than just technical and business expertise. We need fluency in decoupling systems for maintainability, reconnecting them for business value, and working with the messiness of organizational dynamics. At the OOP Conference, Yao explored how sociotechnical design helps us deal with these challenges.

One of the biggest challenges in software is the need to decouple and connect at the same time, as Yao explained:

Developers are expected to break systems into modular, independent parts while also understanding how to reconnect them to create business value. A well-structured API, a message queue, or a data contract may work today, but as the business need evolves, so must those connections be revisited.

As software ages and business contexts evolve, the necessary changes – refactoring, re-architecting, or rethinking system boundaries – are often not held back by technical difficulty alone, but by the social complexity of teams, decision-making structures as well as role boundaries and organisational dynamics, Yao argued.

Software exists within human systems, and yet many development practices assume that the human aspects of software work, like communication, understanding, decision-making, and collaboration, can be neatly structured and controlled like code. But social complexity is emergent, unpredictable, and full of contradictions, Yao said.

Misaligned incentives, rigid team structures, power dynamics, and change fatigue often create barriers to sustainable architecture, Yao mentioned. Many teams lack the necessary conditions for open, reflective conversations, leading to superficial solutions that don’t address underlying social constraints, and thus brittle designs, she added.

Yao mentioned that beyond technical excellence, sociotechnical fitness is key. She mentioned the ability to engage in deep collaboration, reflective conversations, and participatory decision-making:

Skills like facilitation, surfacing questions, active listening, and collaborative modeling help teams navigate uncertainty and align software with human needs.

A prerequisite of sociotechnical fitness is sociotechnical awareness, to see our work with software as a system of systems. Yao argued that it’s essential to design relationships between software, business needs, and the humans behind both:

Developers and architects who recognize this aren’t just building software—they’re cultivating an environment where good software can emerge through trust, shared language, and continuous negotiation of meaning.

Software doesn’t exist alongside the social system, it is embedded within it, Yao said. Our work is a complex social system with complicated technical subsystems as parts. Being embedded, a technical subsystem isn’t an isolated machine we can optimize independently; it grows, shifts, and entangles itself with human decisions, workflows, and power structures:

Every piece of code carries traces of the conversations, misunderstandings, constraints, and compromises that shaped it.

This embeddedness makes software inherently more complex than just a collection of technical parts. The same piece of code can function differently depending on who is using it, how teams interpret requirements, or how decision-making authority is distributed, Yao said.

Software is not pure unpredictability. Practices like DDD, CI/CD, containerization, and TDD bring predictability to the technical realm, Yao said. But this predictability breaks down at the level of human interaction:

The challenge is knowing when to lean on predictability, and when to embrace emergence. That’s the shift from software design to sociotechnical design.

Instead of jumping to solutions, we need to engage with the deeper questions shaping our whole sociotechnical systems – questions of meaning, relationships, and power dynamics, Yao suggested. By doing so, we avoid premature convergence and create solutions that reflect the true complexity of the business domain and the human system.

InfoQ interviewed Xin Yao about dealing with sociotechnical complexity.

InfoQ: What are the key pitfalls to avoid when trying to align architecture with organizational structures?

Xin Yao: Many organizations aim to implement the Inverse Conway Maneuver but struggle in practice. A major pitfall is assuming that simply changing team structures will fix architectural issues. It’s more effective to iteratively adjust boundaries based on how teams naturally collaborate and evolve.

Complexity calls for collaboration. Big bang divide-and-conquer of social complexity (aka. reorganizations or transformation) is not a panacea to decoupling and connecting software.

InfoQ: What’s the role of storytelling in navigating sociotechnical complexity?

Yao: Stories help make abstract complexity tangible. They enable teams to surface assumptions, build shared understanding, foster psychological safety, and engage in productive dialogue.