Author: Ben Linders

Web accessibility ensures content is usable by people with disabilities. According to Joanna Falkowska it can give a competitive edge, improve SEO, and support basic human rights. She emphasizes using WCAG standard and making accessibility a shared team responsibility from the start of development, to prevent costly fixes later in the process.

Joanna Falkowska spoke about creating accessible websites at DEV: Challenge Accepted.

Web accessibility is about making web content available to users with disabilities. Falkowska suggested using the Web Content Accessibility Guidelines to improve accessibility and create an inclusive website.

Web accessibility should be considered a basic human right, said Falkowska. We should care about website accessibility because most of us either are affected by disability directly or have family members, friends or colleagues who have it, she added. Product accessibility can give you a competitive edge over other businesses.

Some companies consider accessibility as a natural consequence of their DEI policy and a basic human right. There are also those who care about accessibility primarily due to SEO results, as search engines prioritise accessible sites in their search results, Falkowska said.

Accessibility may be important for companies due to legislation. Many countries and institutions implement dedicated digital accessibility laws that concern specific institutions and/or businesses, Falkowska mentioned:

One of the most recent ones is the European Accessibility Act. It is an EU directive that will come into force in July 2025, addressing a wide range of services, among others: e-commerce, banking and transport.

The Web Content Accessibility Guidelines is a standard that is recognized worldwide. Any legal act that requires conformance with accessibility rules quotes WCAG as its reference point, Falkowska said. It is available on-line and completely free. There is also a thorough list of international accessibility policies available. Falkowska invited people to read it and adapt their web content according to its success criteria.

Falkowska suggested that team members should be fluent in accessibility standard, at least in relation to the success criteria that refer to their role:

For example, it is the role of the designer to address all of the colour contrast issues there may be but also, if the authoring team has some flexibility, they should be aware of the colour contrast rules they need to follow in order for the final content to be accessible.

Accessibility issues, just as any other type of bugs, tend to be more expensive to fix in the later stages of development, Falkowska said. Therefore, development teams who want to achieve and maintain an accessibility standard, need to make accessibility part of the earliest stages of development.

Falkowska suggested making it part of the process to discuss and add precise accessibility acceptance criteria to the ticket description while grooming new stories:

Many teams do not do it, and as a result, accessibility gets added either after the ticket is rejected in the testing phase or even later – when the accessibility audit is completed.

Accessibility is undeniably a team sport. If we want to integrate it with the development process, we need to address it at all of its steps, Falkowska concluded.

InfoQ interviewed Joanna Falkowska about developing accessible websites.

InfoQ: What’s your advice to developers who want to start with accessibility?

Joanna Falkowska: If you are new to the subject of accessibility, I would recommend taking the time to read and understand all of the success criteria WCAG provides. It may look overwhelming at first but you can learn them in chunks, according to subsequent sections (guidelines) or based on conformance levels (from A up to AAA).

The second thing would be learning how to use assistive technology, especially screen readers, but also simple things like navigating with a keyboard instead of a mouse.

Finally, once you learn all of that, the first thing to do is… make friends with and, if needed, educate the design team. Many accessibility issues would not pop up at the development stage if the designs were following WCAG standards right from the start.

InfoQ: What can be done to make accessibility an integral part of your development process?

Falkowska: Make sure that accessibility is not simply “outsourced” to an accessibility team from a different department or an external auditing company.

The accessibility team should be there to support you only in the issues that go beyond the basic scope, e.g. you are struggling to decide what order to implement for keyboard navigation and need someone to share the most convenient solution.

The auditing company should come only in the last stage of the development. They are there to certify your accessibility level rather than teaching you what should have been done at the beginning of the development. We all know that changing the designs while the app is running costs much more than designing the wireframes with accessibility in mind.

Suppose we want to integrate accessibility into the development process. In that case, the product owner should raise the topic of accessibility repeatedly: right at the design stage, before the development starts, and up until the testing phase.

If your team members do not know what to consider while developing an accessible solution, you may want to request an accessibility specialist to join your team and help you draft requirements with WCAG in mind, teaching everyone what to consider during grooming sessions.

Developing accessible solutions might bring more clients to your website. Adding accessibility skills to your personal portfolio will make you a more competitive employee on the IT market. Companies that are legally obliged to deliver accessible solutions will quickly learn that it is more cost-effective to employ team members that know what role they play in delivering accessible apps.

After being on an agile journey where practices have primarily been centered on IT, a company is now exploring ways to extend them beyond IT and scale their approach. At Agile Tampere, Ramya Sriram presented how they focus on continuous improvement through agile practices, feedback, and customized maturity assessments. Emphasizing flow metrics with a strong learning culture, they aim for efficiency and sustainable growth.

Sriram mentioned that their company has reached a strong position in its agile journey, and is reflecting on how they want to evolve and transform further:

This marks the beginning of what we’re calling Agile 2.0, where we are focusing on scaling and broadening our impact. Teams outside IT are also learning more about agile practices and we are also studying agile hardware to understand its full usage.

We’re proud of our current maturity level, but as part of our commitment to continuous improvement, we are always learning and adapting, Sriram said. Their next steps are guided by insights drawn from maturity assessments, interviews, and feedback, focusing on areas such as teamwork, agile practices, value delivery, learning and improvement, quality practices, customer satisfaction, organizational alignment, and delivery execution. Each of these areas presents both strengths and opportunities, which require ongoing evaluation and action, Sriram mentioned.

To support this evolution, Sriram mentioned that her company has initiated efforts to expand agile training and coaching, providing teams with the tools and knowledge they need to grow. They have also conducted bootcamps to collaboratively identify challenges, share best practices, and tackle impediments together. This collaborative approach is laying the foundation for a more integrated and impactful agile journey, Sriram said.

Sriram mentioned that they have been using flow metrics and maturity assessment tools to level up their agile practices. These tools have been game-changers for planning outcomes, boosting efficiency, and delivering products with more predictability and agility, she explained:

We started with the SAFe toolset, specifically the Facilitating SAFe Assessments framework, for our maturity assessments. But instead of a one-size-fits-all approach, we customize the templates to fit our unique needs. This helped us focus on what really mattered to our teams and stakeholders.

Their teams keep a close eye on their flow metrics. Sriram mentioned that they have been inspired by measure and grow from the Scaled Agile Framework. These metrics aren’t just numbers—they reveal bottlenecks, highlight challenges, and guide us toward better planning and smoother workflows, Sriram explained:

It’s all about finding balance. If teams only focus on technically completing requirements without considering real stakeholder needs, people aren’t happy. On the flip side, if teams take on too little work, stakeholders might feel like their priorities are constantly being pushed to the next quarter.

The sweet spot lies in balancing work intake with capacity while staying flexible enough to adapt to changing requirements—that’s what agility is all about, Sriram said.

In today’s era of digital transformation, with advancements like Artificial Intelligence, Machine Learning, and Generative AI, the question often arises—are these a boom or a bane? Regardless of the innovations, the cornerstone remains the same: continuous improvement and learning, Sriram said. These drive innovation and pave the way for sustainable progress, she concluded.

InfoQ interviewed Ramya Sriram about continuous improvement.

InfoQ: How do you use feedback from customers for improvement?

Ramya Sriram: Customer feedback plays a big role. Through surveys, retrospectives, and demos, we gather insights that help us continuously improve. Sometimes, it’s a big change, like tweaking release cycles. Other times, it’s small but impactful—like improving communication during a tribe demo, scheduling testers more effectively for UAT, or enhancing end-user documentation.

This continuous feedback loop keeps us aligned with what truly matters, helping us deliver better results while staying adaptable and grounded.

InfoQ: What’s your advice for sustainable improvement in software organizations?

Sriram: For me, the focus is on prioritizing quality over quantity while fostering strong feedback loops to continuously evolve, learn, and refine how we work. It’s crucial to nurture and even deepen our commitment to a culture of continuous learning and innovation. Breaking down silos and promoting cross-team collaboration is essential to this effort.

We must also keep a close eye on measuring and optimizing workflow by addressing bottlenecks and enhancing efficiency, all while emphasizing the importance of people and ensuring a culture of psychological safety.

Resilience helps individuals and organizations respond to challenges. According to Kathleen Vignos, personal resilience is built through adapting, technical resilience by mastering a variety of tools, and organizational resilience through flexibility and strong networks. In fast-changing software industries, recognizing tech shifts and fostering learning, flexibility, and collaboration, enhances resilience.

Kathleen Vignos gave a talk about cultivating a culture of resilience at QCon San Francisco.

Something that is resilient can bend without breaking. You find out how resilient something is once you’ve stretched, pushed, and tested it, Vignos said.

Personal resilience is built when things don’t go the way you planned, and you have to learn how to quickly adjust, Vignos mentioned. Technical resilience is built when you have to continually switch familiar tools with new ones, and organizational resilience is built along with your professional network so that if one organization fails, you have more options at hand, she added.

Any company on the edge of rapid innovation needs resilience to survive, as Vignos explained:

Few industries change as quickly as software. The skills and tools evolve, the players evolve, the funding evolves, and even the users evolve. Constant external factors influence the business and require nimble adjustments to roadmaps, org charts, and skill sets.

Technology evolves in waves and patterns, understanding these cycles can make us more resilient to change. Historically, we’ve seen major shifts such as the rise of the internet, mobile, cloud computing, and now AI, Vignos mentioned. Each wave follows a pattern: emergence, hype, disruption, maturity, and commoditization. Organizations and individuals that recognize these phases early can position themselves to be resilient to these shifts, she said.

To become more resilient to technology shifts, it helps to employ modular architectures with pluggable APIs, to keep abreast of emerging technology trends, and to inspire a culture of continuous learning, Vignos said.

To build a resilient culture in organizations, organizational leaders need to enable adaptability, learning, and sustained performance during periods of change within their organizations, Vignos mentioned. She recalled that from 2016-2018 many companies needed to respond to the General Data Protection Regulation (GDPR), set to be enforced in 2018. In order to operate in the EU, companies needed to comply with rules that gave users the right to access their data, erase their data, restrict the use of their data, and be informed about the use of their data:

At that time, I was involved in a company-wide project to prepare for GDPR. The teams and individuals most important to the success of the project exhibited curiosity and a growth mindset to learn how to protect users; a willingness to change processes and development lifecycles to adapt; and a collaborative spirit to join together with new teams and divisions to coordinate getting a massive amount of work done in a relatively short period of time. We avoided multi-hundred-million dollar fines and maintained the ability to serve tens of millions of users in the EU.

Promoting a growth mindset and experimentation, fostering autonomy, and strengthening cross-functional collaboration all contributed to a resilient culture, paving the way to compliance and ensuring the company’s ongoing financial survival, Vignos said.

Artificial intelligence can help enhance resilience, Vignos mentioned, enabling faster decision-making by analyzing large data sets, automating tedious tasks, and supplying predictive insights, helping organizations and employees adapt, recover, and thrive in the face of change.

Every hardship and challenge throughout my career has provided an opportunity for me to build resilience, Vignos said. I like the way Oprah says it: “Turn your wounds into wisdom”, she concluded.

InfoQ interviewed Kathleen Vignos about cultivating a culture of resilience.

InfoQ: Why does resilience matter for software companies?

Kathleen Vignos: As an example, I can remember when the Clubhouse app became popular in 2020. Suddenly tech entrepreneurs, venture capitalists and celebrities were chatting informally with each other and attracting large audiences. Meanwhile, at Twitter, we had acquired Periscope a few years before, and had used the technology internally to host all company meetings with thousands of users (and speaking of scaling, shoutout to the engineer who could spin up a new AWS region for Periscope with about 15 lines of code).

Clubhouse initially could not scale beyond 1000 listeners, creating a prime opportunity for Twitter to leverage Periscope technology to launch Twitter Spaces in just a few months. With massive scaling capabilities and the advantage of a network of over 300M monthly active users to draw upon for listeners, Twitter Spaces (and other platforms like Facebook Live Audio) contributed to Clubhouse’s decline.

This story captures a point in time when one company’s leaders, employees, and technology exhibited resilience and agility over another. The one best equipped to respond to change survived – at least for a couple more years.

InfoQ: How can software developers increase their personal resilience?

Vignos: I can think of several examples through my development career when I got partway through delivering a project, only to have the roadmap change. Whether it was because of funding changes, or a leadership change, or some other reason, it felt demotivating not to be able to finish the work I’d started and become invested in.

The advice is to hold the work lightly. For long projects, identify milestones that can give you a sense of shorter-term accomplishment, no matter the long-term outcome. Stay flexible to hand off work to others, and be able to shift to take on new work when those opportunities arise.

I used to be paid hourly as a freelance developer – so I reminded myself that I got paid even when the client changed their mind and scrapped the work. Let it go!

High performance and sustainability correlate; making software go faster by improving the efficiency of algorithms can reduce energy requirements, Holly Cummins said at QCon London. She suggested switching systems off when not in use to reduce the environmental footprint. Developers can achieve more by doing less, improving productivity, she said.

A high performance sustainable system should have a low memory footprint, high throughput, avoid excessive networking, and support elastic scaling. These are characteristics we already want for our software, Cummins said.

Building hardware has an environmental impact, both in terms of raw materials, and embodied carbon from the energy required, Cummins said. When the hardware reaches the end of its life, it ends up in landfills. E-waste, or electronic waste, takes up space, and puts non-renewable resources like copper, platinum, and cobalt out of circulation.

E-waste can pose health hazards to the people doing the recycling, so the best way to solve the problem is to just generate less of it, Cummins suggested.

Often, software has obsolete assumptions baked into its design. If we can identify those assumptions and update the design, we can improve performance, reduce latency, reduce costs, and save energy, Cummins explained:

Many Java frameworks make heavy use of reflection, which allows the behaviour to be updated dynamically. But for modern applications, that dynamism requirement isn’t there anymore. We don’t swap out application components at deploy-time or run-time. Applications are often deployed in containers, or the complete deployment package is generated by a CI/CD run.

To reduce the environmental footprint, Cummins suggested switching systems off when they’re not in use. Many organisations will run a batch job at the weekends, but keep the system doing the job up all week. Or they’ll keep staging systems running overnight, when no one is using them:

People are nervous about doing this because we’ve been burned in the past by systems that never behaved correctly again after being turned off. This fear of turning things off is kind of unique to computer systems. Nobody goes out of a room leaving the light on because it’s too risky and complicated to turn the light back on.

Boilerplate code- code that’s pretty much the same in every application- is a sign that the API design, or maybe even the language design, isn’t quite right. It’s a waste of time for developers to write code that isn’t really adding differentiated meaning, Cummins explained:

The solution to boilerplate is not to get AI to write the boilerplate; the solution is to design more expressive APIs.

Cummins mentioned that there’s evidence that we can achieve more per working hour if we work less, and achieve more overall:

Henry Ford moved his factories from a 48-hour, six-day working week to a 40-hour, five-day working week, after his research showed that the longer hours did not result in more output. More recently, a study found that companies experimenting with four-day weeks report 42% less attrition, which makes sense, and a 36% increase in revenue, which is perhaps more surprising.

At an individual level, studies find that switching off can improve productivity, Cummins said. One mechanism for this is the default mode network, an area of the brain that becomes more active when we’re not doing anything. The default mode network is involved in problem solving and creativity, which is why so many of us have great ideas in the shower, she said.

Cummins mentioned Jevon’s paradox, which says that increasing capacity increases demand. This is why widening highways doesn’t reduce travel times – more cars use the new, wider, road, and so traffic jams still happen. We can take advantage by leveraging an inverse Jevon’s manoeuvre. If we work shorter hours, the demands on our time become lower, and we can still achieve important things, she concluded.

InfoQ interviewed Holly Cummins about eliminating software waste and reducing the environmental footprint.

InfoQ: How can we eliminate software waste?

Holly Cummins: Dynamism has a cost; many Java applications are paying the dynamism tax, without getting a benefit. Quarkus fixes this by providing a framework which allows libraries to do more up-front, at build time. That shift to build time gives applications which have a smaller memory footprint, and run much faster.

Also, smaller, fine-tuned, generative AI models can sometimes give better results than big models, for a lower cost, and with lower latency. Or for more complex problems, linking a few smaller models together with an orchestration model can work great. It’s challenging the assumption that bigger is always better.

InfoQ: How can we build systems with a smaller environmental footprint?

Cummins: We should design systems to have a light-switch-like ease of turning them on and off. That means idempotency, resiliency, and infrastructure as code. That’s more or less what you need anyway if you’re designing cloud native systems. Once the systems support it, we can automate turning systems off when they’re not needed. I call the two of these together LightSwitchOps.

Just turning things off can generate pretty huge savings. For example, a Belgian school saved €12,000 a year with a script to shut computers off overnight, and a US company reduced their AWS bill by 30% by stopping instances out of working hours. Scripts don’t need to be home-rolled, either. For a more interactive solution, Daily Clean gives a nice UI for setting power schedules.

As a company grows, investing in custom developer tools may become necessary. Initially, standard tools suffice, but as the company scales in engineers, maturity, and complexity, industry tools may no longer meet needs, Carlos Arguelles said at QCon San Francisco. 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.

Carlos Arguelles gave a talk about Amazon’s inflection points in engineering productivity. When a company first starts, it doesn’t make sense for it to create its own developer tools, as there are plenty of excellent ones available in the industry, he said. But as a company grows (in number of engineers, in maturity, in customer adoption, in domains), investing in its own developer tools starts making sense:

An inflection point is when that investment in engineering productivity that didn’t make sense before now suddenly does. This could be because the industry tools do not scale, or because the internal tools can be optimized to integrate better with the rest of the ecosystem, as Arguelles explained.

A little papercut where each developer is wasting a couple of minutes per day in toil can add to hundreds of millions of dollars of lost productivity in a company like Amazon or Google.

The more obvious inflection point that made investments in engineering productivity become feasible is the number of engineers. Maybe it didn’t make sense for your company to have its own CI/CD proprietary tooling when there were 3000 engineers, but it does when there are 10,000 engineers, because the savings in developer productivity with a toolchain optimized for the ecosystem have a significant return on investment, Arguelles said.

He mentioned that the opposite is true as well. When your company is in hypergrowth it may make sense to have duplicate tools (each organization creating its bespoke tool so that it can independently move fast), but when the company stops growing (which is what happened in 2023 with all the big tech layoffs), it makes sense to consolidate tooling and defragment the world.

Arguelles gave some more examples of inflection points, like reaching a certain level of maturity where you need to raise the bar in terms of engineering or operational excellence can provide an inflection point or entering an entirely different and new market. Sometimes the inflection point is a crisis or even a single operational issue that could have been prevented with the right tooling:

For example, Amazon invested significantly in a number of load, stress, and chaos testing tools after the Prime Day incident of 2018 (where the Amazon Store was unavailable for hours during the busiest shopping day of the year). We had been talking about doing that for years, but that incident helped us sharpen our focus and build a solid case for funding those investments.

Inflections can also happen when an organization experiences hyper-growth:

I saw Amazon double in size every year, from 3000 engineers when I started in 2009, to 60k-70k in 2022. What this meant in practice is that we needed to be thinking about skating to where the puck was going to be, not where it currently was.

Scaling needs and security needs often meant sooner or later we needed to create our own developer tools, Arguelles said. Over time, they developed tools to scale source code repositories and built their own tools for code reviews and CI/CD (including testing and deployment):

Because of that hyperscale, we often found ourselves needing to re-think our architecture much sooner than we had envisioned. But it also provided ample opportunities to innovate and think differently!

Inflection points are inevitable and occur naturally in many situations: a company drastically increasing or shrinking in terms of number of engineers, a crisis, reaching a certain level of maturity where you need to raise the bar in terms of engineering or operational excellence, or entering an entirely different and new market, Arguelles said. He concluded that it is important to have your eyes open, recognize when these inflection points are around the corner, proactively shape your engineering productivity tooling for the future, and seize the opportunities.

Software development is much different today than it was at the beginning of the Space Shuttle era because of the tools that we have at our disposal, Darrel Raines mentioned in his talk about embedded software development for the Space Shuttle and the Orion MPCV at NDC Tech Town. But the art and practice of software engineering has not progressed that much since the early days of software development, he added.

Compilers are much better and faster, and debuggers are now integrated into our development tools, making the task of error detection much easier, as Raines explained:

There are now dedicated analysis tools that allow us to detect certain types of issues. Examples are static code analyzers and unit test frameworks. We have configuration management systems like “git” to make our day to day work much easier.

Raines argued that many things are the same today as they were when they started writing software for the Space Shuttle. One of the best ways to detect software problems is still with a thorough code review performed by experienced software engineers, he said. Many defects will remain latent in the developed code until we hit just the right combination of factors that allow the defect to show itself. It is imperative to use all the different testing methods available to us to find bugs and defects before we fly, he added.

Raines mentioned that there is one important thing about their software that is very different than most other embedded software:

We cannot easily debug and fix software that is deployed in space! We continually remind ourselves that any testing and debugging that we do on the ground could potentially save a crew when we get to space.

He mentioned that software developers engage with astronauts at many levels during their work. They discuss requirements with astronauts, and talk about how much of a workload they want and how much they can handle. This evaluation allows them to decide on the level of autonomy that the software will have, as Raines explained:

We spend time thinking about how astronauts would recover from various faults. We determine how the harsh environment of space may affect our software in ways that we don’t even have to think about with ground computers.

The hardware used for the major programs is very often generations behind what we have on our phones and on our home computers, Raines said. The software has to be very efficient because they continually struggle with the CPU being saturated. They also run into problems with the onboard networks running out of bandwidth.

C/C++ is the most common computer language used because of its efficiency. Modern compilers help make C code relatively easy to write and debug, Raines said. Since C has been around for a long time, it is well understood and highly optimized on most platforms. There are also spacecrafts that have used Fortran (Space Shuttle flight computers) and Ada (Space Station onboard computers).

The impact of what language is used is a major factor in how to develop and test the code. C/C++ will allow you to do “dangerous” things within the code, as Raines explained:

Null pointers are a constant worry since we have to use them sometimes instead of references.

The most noticeable impact on development is that they need to perform multiple levels of testing on their code, Raines said. They start with unit tests, followed by unit integration tests, then full integration testing, and finally formal verification tests. Each level of testing tends to find different kinds of defects in the software, Raines mentioned.

The impact of failed code can sometimes be a loss of crew or a loss of mission, Raines said. This will weigh heavily on our decisions about how much testing to do and how stringently to perform those tests, he concluded,

InfoQ interviewed Darrel Raines about software development at NASA.

InfoQ: How have changes in the way software development is being developed impacted the work?

Darrel Raines: All of the tools that are available these days make it much easier to concentrate on the important task of making the code work the way we intend it to work.

The adage that the “more things change, the more they stay the same” is an important concept in my job. I am always willing to try new technology as a way of advancing my ability to develop software. But I remain skeptical that the “next big thing” will really make a big difference in my work.

What usually happens is that we make gradual changes over the years that improve our ability to do our work, but we remain consistent with the principles and techniques that have worked for us in the past.

InfoQ: What makes spacecraft software special?

Raines: One example I use with my team is this: if my computer locks up on my desktop, I can just reset the computer and start again. If we lose a computer due to a radiation upset in space, we may not be able to reestablish our current state unless we plan to have that information stored in non-volatile memory. It is a very different environment.

The astronauts, as educated and trained as they are, cannot debug our software during a flight. So we have to be as close to perfect as we can prior to launching the vehicle.

It may mean the difference between a crew coming home and losing them. This difference is what makes spacecraft software special. This is what makes it challenging.

A rigid hierarchical dynamic between senior and junior software engineers can stifle innovation, discourage fresh perspectives, and create barriers to collaboration. According to Beth Anderson, senior engineers can actively learn from their junior counterparts. She suggests creating an environment of mutual growth, psychological safety, and continuous learning.

Beth Anderson spoke about how senior software engineers can learn from juniors at QCon London.

Often power dynamics focus on senior engineers passing information to more junior engineers, expecting them to approach engineering tasks similarly as they do, Anderson said. Passing information along is a potentially missed opportunity for a more meaningful conversation between senior and junior engineers, where senior engineers can learn new approaches and consider issues and solutions from juniors:

A high power distance can create an environment in which junior engineers are afraid of speaking up when they see an issue that causes a much larger problem, where junior engineers aren’t listened to and don’t feel valued.

Seniors can learn from junior engineers, who are often very highly motivated, and have a fresh perspective and an up-to-date set of skills. We shouldn’t have a fixed idea of who we can learn from, based on a hierarchy or on seniority, but instead celebrate curiosity and create an environment where seniors focuses on supporting junior engineers, not controlling them or shutting them down, Anderson said.

To cultivate an inclusive engineering culture, Anderson suggested active listening, amplifying people’s voices, and valuing their input. Senior engineers need to constantly be aware of how they’re interacting with junior engineers and ensuring they lift them up, not keep them down:

Curating a place of psychological safety in which junior engineers feel comfortable and empowered to speak up and ask questions is critical.

To create an environment where engineers can learn and grow, and feel psychological safety, Anderson suggested implementing “reverse feedback”, allowing junior engineers to speak up and provide feedback about how the senior engineer is communicating with them.

She mentioned asking junior engineers how they prefer to learn and communicate and listen to their ideas with an open and willing mind.

It’s more difficult for junior engineers to affect culture in an organization, although being open with how you prefer to learn is a good way to start, Anderson suggested:

Juniors can ask to review senior engineers’ code and/or pull requests as a learning tool, providing feedback to senior engineers.

Anderson advised junior engineers to be mindful of behaviors they’ve learned from others, and avoid repeating the ones they found difficult as juniors. Seniority isn’t about power, it’s an opportunity to create positive change.

Regardless of their level of work experience, each person has a unique insight and something to teach you if you’re prepared to listen actively and give them an environment in which they feel comfortable and valued. Junior engineers are the perfect people to ask why things are done the way they are, and for senior engineers to take that as an opportunity to reflect, Anderson concluded.

InfoQ interviewed Beth Anderson about learning from junior engineers.

InfoQ: What issues can arise from a high power distance between engineers?

Beth Anderson: At my first company, I remember making a mistake and being berated by a senior engineer. At the time I felt like I’d failed, although there was no way I could have known how to do it differently.

Had the senior engineer understood our different experiences, the outcome could have been a positive learning exercise.

InfoQ: How can we cultivate an empowering engineering culture?

Anderson: Think back to our early days as engineers and remember how we had ideas but looked for some help implementing them. A bad senior engineer would dismiss ideas whereas a great senior engineer would listen, value, and empower that junior colleague.

While I have learned from every senior engineer I’ve worked with, the engineers who have helped me improve the most have been people who listened to what I had to say with an open and willing mind.

Quality Assurance Engineers can evolve into artificial intelligence (AI) strategists, guiding AI-driven test execution while focusing on strategic decisions. According to Victor Ionascu, rather than replacing testing roles, AI can enhance them by predicting defects, automating test maintenance, and refining risk-based testing. This human-AI collaboration is crucial for maintaining quality in increasingly complex software systems.

Victor Ionascu gave a talk about the role of artificial intelligence in quality assurance and software testing at QA Challenge Accepted.

QA professionals are increasingly turning to AI to address the growing complexities of software testing, Ionascu said. AI-driven automation can improve test coverage, reduce test cycle times, and enhance the accuracy of results, leading to faster software releases with higher quality, as he explained in the InfoQ article Exploring AI’s Role in Automating Software Testing.

Ionascu mentioned that he’s using AI tools like GitHub Copilot, Amazon CodeWhisperer, and ChatGPT. One of the key benefits, once you understand how to use AI effectively, is a noticeable improvement in efficiency, as he explained:

For example, with Copilot, instead of manually searching for whether a particular class or function exists, the AI automatically suggests relevant code snippets in real-time. This accelerates the development process and helps me focus more on refining and improving the logic behind the tests.

Tools like ChatGPT have proven to be invaluable for general research and guidance, Ionascu said. Instead of spending time searching through multiple sources, he uses it as a powerful assistant that provides quick insights and suggestions during the automation process. It helps reduce the time needed for researching complex testing scenarios or frameworks, which ultimately speeds up the development of robust test scripts, he mentioned.

While AI offers tremendous potential, Ionascu stressed that AI is not without limitations. It lacks the contextual understanding and human intuition required for tasks like exploratory testing and non-functional testing (e.g., performance and security), he mentioned.

The future of testing with AI will see QA professionals evolving into AI strategists, where AI tools will handle much of the execution and maintenance of automated tests, Ionascu said. AI will enable adaptive, self-healing tests that evolve with the application, reducing the overhead for QA teams, he added.

Ionascu expects AI to also improve in areas like predictive defect detection:

AI can analyze historical data to identify high-risk areas before they become critical issues.

In the long term, AI will not replace QA roles but will augment human capabilities, allowing teams to focus on strategic, high-value tasks like quality strategy, exploratory testing, and risk-based testing, Ionascu said. The key will be the partnership between AI and human oversight, where AI handles execution, and humans drive creativity and strategy, he concluded.

InfoQ interviewed Victor Ionascu about applying AI for software testing.

InfoQ: What are the limitations of AI in testing?

Victor Ionascu: While it excels at automating repetitive tasks, AI still struggles with contextual understanding of complex, domain-specific workflows. AI-generated tests may require manual refinement to ensure completeness and accuracy, especially for non-functional requirements like performance and security testing. And AI lacks human intuition, which is crucial for exploratory testing and discovering edge cases that are difficult to automate.

InfoQ: Can you give an example of a test case where human intuition made the difference?

Ionascu: An example of an edge case would be testing invisible or zero-width characters in passwords.

Scenario: A user enters a password that appears valid but contains zero-width spaces or non-printable Unicode characters (e.g., U+200B Zero Width Space, U+200C Zero Width Non-Joiner).

The example password input (User Perspective): P@ssw0rd (Looks normal)

The actual password (Hidden Characters): P​@ssw0rd (Contains a zero-width space between P and @)

Automation using AI will miss this, because:

• Automated tests typically check for length, required characters, and structure but may not detect hidden characters.
• Most test automation frameworks treat these as valid input since they don’t visually alter the string.
• Traditional regex-based validation rules fail unless explicitly checking for invisible Unicode characters

Humans using AI can discover this in two ways:

• Human Tester Insight: Manually pasting a password copied from an external document (e.g., Google Docs, emails) can reveal login failures due to hidden characters.
• AI-Assisted Detection: AI-powered anomaly detection can compare expected login behavior with failed attempts where passwords “look correct” but fail

Testing this has a significant impact. Users may struggle with login failures without understanding why. It can also be exploited for phishing attacks (e.g., registering P​assword123 and tricking users into thinking it’s Password123).

As their organization grew, Thiago Ghisi’s work as director of engineering shifted from being hands-on in emergencies to designing frameworks and delegating decisions. He suggested treating changes as experiments, documenting reorganizations, and using a wave-based communication approach to gather feedback, ensuring people feel heard and invested. This iterative process helps create sustainable growth and fosters buy-in from the team.

Thiago Ghisi presented lessons learned from growing an engineering organization at QCon London.

Ghisi explained how the growth of his organization impacted his work as director of engineering:

When we were around 30 engineers, I could still be in all the crucial standups, help new managers fill gaps, and solve emergencies directly in Slack. But once we passed 50, that just didn’t scale. My role switched from “heroic firefighting” to shaping frameworks and delegating crucial decisions to develop the leadership team.

Ghisi mentioned that he had to stop being the go-to “person” for everything and start being the designer of their broader system, so teams could operate autonomously without waiting for him to approve every move. That shift was challenging but ultimately unlocked more sustainable growth, he added.

Approaching 100 engineers, success is all about designing an environment where others can operate effectively without his constant involvement, Ghisi stated. It is all about building organizational resilience.

Ghisi mentioned that organizations evolve like living organisms. Even if nothing’s “on fire,” a small structural adjustment can be the difference between merely functioning (treading water) and truly flourishing (innovating), he said.

A big part of getting changes to stick is treating them as experiments first in a subtle way, not final mandates, as Ghisi explained:

For instance, I’ll often spin up a “temporary” or “interim” task force before making it official, exactly like when a leader appoints someone as interim manager to see how it goes.

In parallel, once the most senior leaders in our organization agree on a rough plan, we bring in waves of staff engineers and engineering managers to stress-test it, Ghisi said. They surface hidden corner cases or improvements that the core leadership group might have missed, and they get to feel like true co-creators of the new setup rather than mere recipients of a top-down organization chart.

This wave-based approach helps everyone feel heard, which makes them more invested, Ghisi said. He suggested to let people know reorganizations aren’t set in stone:

If something sparks more trouble than it solves, we iterate again. Linking every change back to our short- and long-term priorities helps them see the “why,” not just the “what.”

When leaders demonstrate they’re actively listening and adjusting, people are far more willing to adopt the new structure or process and give feedback, Ghisi concluded.

InfoQ interviewed Thiago Ghisi about what he learned from scaling up.

InfoQ: What is your approach for reorganizing and scaling up?

Thiago Ghisi: I always start with a simple one-pager that spells out motivations and goals: maybe we’re addressing overlapping ownership, or maybe a historically underfunded team is now mission-critical, or maybe staffing a new team for a new scope.

From there, I use an iterative approach:

1. Create a Draft (in writing): Outline reasons, high-level roadmap, and potential outcomes.
2. Whiteboard new Organization Structure: Share the draft with a small leadership circle (ideally your senior leadership team) for initial feedback.
3. People Managers’ Feedback: They’re closest to day-to-day pain points—factor in their corner cases.
4. Staff-Plus Review: Let senior ICs stress-test the plan. They’ll spot hidden risks. Iterate and incorporate their suggestions.
5. Leadership Sync: Bring senior leadership team + managers + staff engineers together for one final pass, refining and locking the structure.
6. Comms Plan: Announce changes in waves—people directly impacted first, next indirectly impacted, then the broader org, finally a town hall for Q&A and reiterate the same message that was shared in writing.
7. Roll Out & Monitor: If the new structure truly reduces friction or speeds up a key OKR, we keep it. If issues arise, we iterate fast instead of waiting for a “next-year meltdown.”

By treating reorganizations as iterative design—rather than a once-a-year monolith—we keep them from becoming dreaded events. It’s less “big bang” and more continuous improvement, validated by how smoothly teams deliver or how much friction we eliminate along the way.

InfoQ: What have you learned?

Ghisi: Some of the things that I have learned are:

• Managerial cost is real: You can’t just form a new squad on paper; you need a dedicated manager or lead who can truly own it.
• Structured communication plan: Rolling changes out in at least two or three waves is critical to avoid chaos.
• Your own leadership must evolve: Doing everything yourself at 30 engineers might work, but by 60 or 100, it will collapse. You need to empower a leadership bench, focus on system design, and let go of old “hero” behaviors.

In short, scaling to 100+ has less to do with adding headcount and more to do with systematically building leadership, designing topologies, and iterating on my own role. Every doubling of team size demands a doubling of leadership maturity.

Age-related discrimination assumes older programmers are less capable or unwilling to learn. Kate Gregory stresses that inclusive, age-friendly workplaces benefit all employees. She advises staying open to new experiences, learning, and building connections to maintain a fulfilling career and well-being as we age.

Kate Gregory gave a talk about continuing to program as people age at NDC Tech Town.

Trouble seeing, pain, and stiffness are some of the things that can make it harder to program as you age. But they aren’t inevitable, and some solutions can help, as Gregory explained in the InfoQ article What Developers Can Do to Continue to Program as They Age. She gave examples of solutions, like changing fonts, using glasses, and rearranging the office layout.

Gregory did a survey to explore ageing for programmers as part of preparing her talk, and hundreds of developers, of all ages, responded.

Gregory mentioned that older people sometimes face age discrimination. She gave an example where people assume an older person “wouldn’t want to learn that”, or “doesn’t know how to use these new cool things”, or say that someone won’t be a culture fit. Without checking, they exclude the person based on assumptions, she said.

When people meet an older programmer they sometimes think (or even say!) things like, “I guess you weren’t good enough to get promoted to management yet”, Gregory said. The good news is it doesn’t happen everywhere, so if this happens to you, you should find an environment where you’re valued, she argued:

Some places have learned that offering a welcoming workplace gets them some amazing talent.

Most people who replied to her survey said they did occasionally assume older people couldn’t do something or wouldn’t want to, despite trying to remember we all age differently, as Gregory explained:

It’s actually in your own interests to educate yourself about the positive realities of aging, because studies show that people with negative attitudes towards old age and old people are more likely to be hospitalized or have a heart attack or stroke.

Improving the working conditions for programmers is not just about age, Gregory said. When employers stop assuming that everyone is the same, and build a more inclusive environment, that helps everyone, she mentioned. It could be having adjustable lighting, or flexible work hours, or not having a rigid dress code — all of these can make a big difference to some people as they age, or to younger people who have physical needs that are not the same as everyone else’s, she added.

Most of us don’t actually struggle with being able to keep up with new stuff as we are getting older. After several decades you know how to learn, you’ve seen ten different source control systems, or job tracking systems, or whatever, and you can pick up another one easily enough, Gregory said.

Gregory advised to make friends, and don’t stop making new friends all of your life. Try new things too – as life goes on there will be losses, and the only cure for loss is gain, so you have to give new hobbies, new foods, and new entertainment a chance. Some of them will work out wonderfully, she said.

No matter how young you are, it’s never too soon to start working towards the kind of old age you want. And the good news is, it’s also never too late, Gregory concluded.

InfoQ interviewed Kate Gregory about continuing to program as people age.

InfoQ: What’s your suggestion for keeping up with new stuff when we’re getting older?

Kate Gregory: It’s mostly a matter of wanting to keep up. Sometimes we’re just fed up, or unimpressed by the benefits that everyone says the new system will bring, and don’t feel like learning it for that reason. Or we’ve tied our identity to a particular programming language or operating system, and feel like switching to a new one would mean saying we were wrong.

If we can set that aside and focus on the purpose of our work more than the tools we use, picking up a new tool is not beyond any of us.

InfoQ: What’s your advice for a long and happy old age?

Gregory: Embrace exercising, both in the form of active hobbies and active commutes and such, but also in deliberate “twenty minutes of stretching” kind of exercise.

Save money starting young, so that you will be relaxed and comfortable when you reach retirement age. Build up other resources too — surround yourself with nice people, for example, and learn skills like how to talk to people when the stakes are very high, such as during a family medical emergency, so that you get the information and help you need.

Eat well, sleep well, and care for your body. It’s not your enemy, it’s you. Plan for your retirement and work towards that plan now — if you want to paint or sail or golf a lot, learn how to do it now so you can evaluate it and get at least some of that enjoyment without waiting decades.