Si vis pacem, para bellum

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

Aequam memento rebus in arduis servare mentem

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

Mens sana in corpore sano

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

Divide et impera

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

Ad praesens ova cras pullis sunt meliora

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

Bene vixit,  bene qui latuit

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

Discere faciendo

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

Panem et circenes

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

Cessante causa, cessante effectus

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

Verba volant, littera scripta manent

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

Periculum in mora

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

Historia est magistra vitae

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

Non omnia possumus omnes

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

Omnium enim rerum principia parva sunt

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

Pacta sunt servanda

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

Vinum bonum, pax in domum

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

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

As of the beginning of 2025, the estimated global developer population is over 47 million, according to a market research study by SlashData.

The number of professional developers increased from 21.8 million to 36.5 million, whereas the amateur developer population declined by over 1 million in the last year.

That’s 50% more software developers than in Q1 2022. The growth rate has varied, with a 15% increase from 2022 to 2023 and a 21% spike from 2023 to 2024, attributed to post-pandemic investments and demand for digital services.

However, growth has decelerated to 10% in the last 12 months, indicating a shift towards a plateau in the developer ecosystem.

The population estimates are derived using SlashData’s independent bottom-up methodology, which is based on reliable measurements from various sources. Data sources include the number of GitHub and Stack Overflow accounts, along with employment statistics from the USA and the European Union.

The methodology also incorporates data from their global developer survey, which has run 29 waves and reached over 10,000 developers globally in each wave, said Costas Korakitis, the director of research at SlashData.

Professional and Amateur Developers

The professional developer population has grown significantly by 70% from 2022 to 2025, while the amateur developer segment has begun to contract. The number of professional developers has increased from 21.8 million to 36.5 million, while the amateur developer population experienced a decline of over 1 million in the last year.

This trend indicates that professionals remain in the field longer, while the traditional entry-level population is shrinking.

Developer Population is Ageing

The demographic profile of developers is gradually aging, with a decline in the percentage of developers aged 18 to 24 from 33% in early 2022 to 23% in early 2025.

At the same time, the share of developers aged 35 to 44 has increased from 22% to 26% during the same period.

Western Europe and North America continue to dominate the global developer population, each with approximately 9.5 million developers. However, significant growth is happening in other regions, particularly in South Asia, which has nearly doubled its developer population from 4 million in 2022 to 7.5 million in 2025.

Greater China has experienced explosive growth, tripling its developer population from 2.4 million to 5.8 million, driven by investments in education and local platforms. South America has also seen growth, increasing from 1.7 million to 3.4 million developers, with countries like Brazil and Argentina emerging as tech outsourcing hubs.

More Backend and AI, Less Mobile Developers

Web development remains the most popular application area, with over 23 million developers engaged in front-end and back-end applications.

Backend services and data science/ML/AI applications are also significant focus areas for developers. At the same time, emerging sectors include the development of applications for third-party ecosystems and embedded software, which have experienced substantial growth since 2022.

Mobile app development and desktop applications have declined, possibly due to market saturation and rising acquisition costs.

28 million JavaScript Developers

JavaScript remains the most widely used programming language, with around 28 million users, followed closely by Java and Python, each with approximately 23 million users. Rust has emerged as the fastest-growing language, more than doubling its user base since 2022, driven by its focus on safety and performance.

Developer preferences are diversifying, with many using multiple languages depending on project requirements, indicating a shift towards selecting the right tools for specific tasks.

The post There are 47 Million Developers in the World appeared first on ShiftMag.

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

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

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

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

Expect the unexpected!

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

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

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

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

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

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

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

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

Real-life problems for SMS

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

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

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

Reliable message delivery is essential.

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

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

Rely on tests, not assumptions

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

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

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

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

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

Real-life bottlenecks for SMS

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

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

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

Work once, benefit many times

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

Organize the team with interchangeable roles

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

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

Continuous testing brings continuous confidence

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

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

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

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

Working on it didn’t make me hate legacy projects any less; it did help me get a deeper understanding of the processes and practices we use today. 

I am proud that I am a part of a team that uses most of the best practices: 

• Writing clean code and automated tests 
• Participating in pull requests and tasks reviews 
• The app is in production within the same day of merging into the master branch 
• Agile is well-adopted 

 It’s not perfect. Pull requests sometimes contain trivial suggestions and discussions. The ops team usually messes something up (or at least that’s what we devs like to think). Our product owner occasionally wants us to fast-track some ‘easy’ features… again. But all in all, things are pretty good. 

A trip to the Ant museum 

Since our team was performing well, our velocity was borrowed to another product, managed by another part of our company. We weren’t thrilled about it since the project uses an older version of Java, and the code wasn’t written the way we would do it.  

The job was to add a few metrics – simple ones, like whether the app is running and for how long, is it processing data (fast enough). The project itself was in maintenance mode, and no new features had been added in a while. Since we are accustomed to adding metrics, this should have been a piece of cake. 

Rolling up our sleeves, we first noticed that the project had been built using something very old - Ant  build files. They are big XML files that contain every piece of information on how to build the project in question. For example, you need to specify that the project needs to be compiled, tested, and packaged. All details like source, target, and resource location must be explicitly configured within those files. This used to be pretty common for many programming languages. You wrote a build file once, copied it on each new project, and then changed it until it worked for the new project.  

Here’s what an Ant build file for a Hello World project would look like:

There must be a more convenient way to manage that, right? Well, that’s why the idea of convention over configuration came to life, suggesting that developers only need to specify unconventional aspects of the application. Modern build tools have adopted this paradigm by providing developers with defaults that can be overridden if needed. That’s why most java source files are in src/main/java source, while the compiled classes are in the target folder—no need to specify this over and over. 

That got us thinking about whether this approach would be helpful in our current projects. We had a huge application properties file, with most values having the same value (e.g., application port). Could we apply the same principle to our application properties? Most properties could have defaults, and our properties file wouldn’t be as large. 

Things we take for granted

Back to our legacy project – we managed to build and package our application! The tedious part was behind us, and we could start coding. But how do we embed our metrics component into the legacy code base? We took this for granted because our application framework usually handled it.  

Now, what would be the best way to inject our metric components into various parts of the legacy code? Singletons! Well, it seemed the easiest way, at least, but the community considers them anti-patterns. Why? Isn’t our beloved XY framework relying on singletons? If not, what does it use? What is dependency injection? How does it function under the hood? 

These questions got us thinking about basic concepts that we took for granted. Using singletons wasn’t exactly a bad idea in this case since most of the code wasn’t covered with unit tests. Nevertheless, we couldn’t have a good night’s sleep unless the code was immaculate. We tried a different approach and ended up with decent and simple code – no singletons, no new abstractions. 

The limited role of developers 

The only thing left was to deploy it so that we could test it. This was a problem, of course—in this case, we were not the ones deploying or testing it. Deploying had to be done by the ops team, and testing by the test team. Why couldn’t we, as developers, manage the whole feature from start to production instead of opening tickets and waiting for other teams before we could close our task?

Firstly, we couldn’t avoid manual testing since much of the code wasn’t covered with tests. We also couldn’t deploy the application ourselves since the infrastructure didn’t allow us to.  

This had us thinking about the reasons behind the separation of duties and how our current approach is better. Seeing that our lead and cycle time on this project was significantly higher than usual (it took us weeks to deliver something we usually deliver in several days), the evidence was strongly in favor of that.

Learn outdated practices to understand current ones

At the end of the day month, our metrics were up and running in production. My feelings about legacy projects haven’t changed – I still hate them, and I am not expecting you to hate them any less.  

We couldn’t change the project we were assigned to, and these were the cards that we were dealt. What we could change is our attitude towards the legacy project. Instead of feeling resigned, we saw it as a place to ask questions and learn.  

It taught us how things were done before and why they are done differently now. Instead of just knowing the best practices, we gained first-hand experience with the history behind them.  

Once you start having this deep-rooted knowledge, other developers will recognize this and trust your knowledge and expertise. If you want to be that person, you better be ready to dig into some legacy projects. 

The post You’re not a senior engineer until you’ve worked on a legacy project appeared first on ShiftMag.