Today I'm sharing a short, yet highly trending article about vibe coding. Let's consider whether software development has been fully democratized? Can anyone produce a piece of software, sell it, and make their life easier without significant expense? Or perhaps lay off employees and do it all themselves as a founder? We'll observe interesting trends and try to more loosely assess the impact of vibe coding on the market and on us as programmers.

My previous article on the overall impact of AI on the IT market will provide a good backdrop for this post. Vibe Coding is a small part of this, with quite a significant impact. Be warned, the article is quite long, as the issue isn't simple or easy to discuss.

Definition of Vibe Coding

The concept was introduced about a year ago, when people stopped writing code by hand. It appears to have been conceived by Andrej Karpathy, a neural networks specialist and owner of network-related companies and content creators. He was, among other positions, the Director of AI at Tesla. He is undoubtedly an authority in the industry.

The meaning of this concept actually focuses on 4 aspects:

• Natural-Language-Driven Development - instead of writing code by hand, the coder just gives commands to tools like Claude Code or Cursor.ai
• Changed workflow - from now on, vibe-coder is no longer a coder but more of a project manager
• Fast iterations - during one session we are able to close many tasks and quickly check the effects of our (and the agent's) work in production
• High complexity beyond our sight - we no longer need to understand every class or method, we focus on the overall view, we do not need to know the implementation details of a given component or even the entire service

The main challenges of coding this way are debugging issues, production risks, security risks, and managing agent context and skills.

Levels (environments) for Vibe Coding

We see several sectors/levels of software development in the market, as described above. The first, most popular among non-technical users, involves using natural language software development applications such as Lovable, Replit , Base44 , and Bolt. All of these tools are typically used by people without coding skills. They market themselves as tools for "everyone." There are some differences between them, but they essentially do the same thing: create applications, deploy, and debug based on prompts.

Another type of tool is an IDE, or console tool, which allows us to view and interact with code in an editor on our computer. These tools communicate with LLM providers (OpenAI, Anthropic, Google, etc.) via APIs to exchange information and receive responses to commands entered in the chat window. These tools offer slightly more control over the code, allowing for agent organization, technical specifications, and so on. This tool is currently used by developers. According to a 2025 GitHub survey, only a quarter of developers use AI for vibe coding. Examples of such tools include Cursor.ai, Kiro, Windsurf, Kiro, Antigravity from Google, and a slightly different, more technical Claude Code console-based interface.

Today, we'll focus primarily on the first type of vibe-coding mentioned, as it primarily expands the developer pool to include existing non-programmers. This is where hundreds of thousands of applications are created every day. I'm not mistaken – hundreds of thousands of users create and implement their software ideas there. Lovable is valued at $6.6 billion (Series B). I think $200 million in ARR fully reflects the number of paying users, considering that the Swedish company was founded just over two years ago.

Trends

Let's look at Google search trends:

We're seeing skyrocketing searches for local coding tools, along with a steady, gradual increase in interest in pure vibe-coding tools. This shows that society is gradually moving from casual programmers who don't write code to full-blown programmers. In my opinion (which is impossible to measure), these may be different target groups. Vibe-coding is more for founders, managers, and individuals with ambitions to publish their ideas, while AI IDE and Claude Code are for those closer to the technology than the end product - software that works.

Now let's take a look at the number of published (analyzed on X.com) and, most importantly, downloaded mobile applications in the last year based on the great website ittransition.com.

We're limiting ourselves to the US here, but there's a clear correlation between the boom in coding apps in general (early 2025) and the number of apps published. Now let's take a look at the number of app downloads during that same period:

Consider the United States in the table above. We have 12.6 billion downloads in 2025. This represents a 2.3% decline from 2024. Consider that the US has a population of approximately 350 million, eliminating the 10-15% who don't use mobile apps at all, and in a negative scenario, the 15% figure, leaving approximately 300 million active users. This translates to approximately 30-35 app downloads per user. Consider the following:

• people often have a new phone every year
• some people have 2 or more devices for work/life use

This amounts to between 20 and 30 apps per device downloaded from marketplaces. I have about 50 apps on my phone, most of which I don't use; they're installed as needed for infrequent purposes, like booking a hair appointment or shipping a package.

This raises one question: if I have 30 apps on my phone, why would I download another one? I think this is a question that customers of today's vibe coders are asking themselves as well. There's a clear disconnect between the number of apps published and the number of app downloads.

So maybe the problem isn’t the cost of building software anymore. Maybe the problem is…
why anyone would want another piece of software at all.

It's worth noting that we've moved almost all our daily activities to our phones: from alarm clocks, payments, communication, childcare, cooking/catering, and even apps for monitoring and improving sleep quality. We wake up and fall asleep with our phones next to our heads or in our hands. So, I ask: what else can we cram into them?

This means that most of the money spent on app development (tokens aren't free) goes towards producing a flop that doesn't deliver value to the end user. Mobile apps have become incredibly easy to publish, and the publishing itself isn't free, and developer subscriptions also cost money. This means that almost all of the capital "invested" in vibe-coding goes to model providers, with some remaining in the hands of apps like Lovable (assuming a 40-60% margin), and some flowing to corporations (Google and Apple for developer fees – vibe coder fees), and then further from model providers to:

• silicon and graphics card manufacturers
• server room owners
• energy producers

Assuming that desktop applications, video games, and web applications replicate this trend in the mobile world, capital flows are directed towards NASDAQ companies - technology companies and energy producers. Let's see how this plays out in terms of valuations and market sentiment:

We're seeing a divergence of -40% between the SaaS index and the top 100 companies listed on Nasdaq. It's astonishing how successful giants like Alphabet, NVIDIA, Apple, and Microsoft are in this scenario (well, maybe less so after recent declines), and consequently, their investors. Who would have expected this? :D Apparently, SaaS companies are on the defensive, or the investor market simply underestimates their chances of AI production by existing SaaS customers.

Technical possibilities of Vibe Coding

Okay, we've discussed the definition and trends, but what about the actual capabilities of these tools? I've tested them a bit, and my personal feeling is that as a programmer, I would have written them better locally with tools from the second group. However, it's undeniable that they can create quite an efficient application in terms of functionality. I'll leave the design to your judgment; one thing is certain: you can easily spot the somewhat standard UX and color scheme of each tool, which is quite repetitive. However, this is probably a matter of additional styling prompts.

Scaling

What about scaling applications in the cloud? This is also possible; most applications offer not only coding but also testing, deployment, reporting, monitoring, and so on. It's essentially a mini software house that writes and delivers software to a given website. Of course, scaling requires a fee, and here, once again, Cloud operators benefit twice: at the code development stage and at the software or application publishing stage. The market clearly directs money toward the big players.

Security

Since cybersecurity isn't my area of ​​expertise, I'll be relying on other people's opinions. I encourage you to watch the video below or similar ones:

The author highlights common security issues with Vibe Coding. This is worth noting. What I wanted to emphasize is that threats exist, and many vibe coders could harm themselves by publishing blindly. Although the author's material demonstrates coding in an IDE, it's important to remember that underneath lies the same model used by the typical online tools mentioned earlier.

Code quality

Note that I've listed quality as the last technical aspect because, from a non-technical vibe coder's perspective, it's of relatively minor importance. What matters is that the product is ready for publication and sale. The quality itself isn't impressive, although it's difficult to assess. In my experience, the code produced by comprehensive application builders is redundant, complex, difficult to read, and riddled with runtime errors. I'm waiting for a study on this, but I personally rate the level as Junior+. I'll stop there.

Application development costs

You might ask, "How much does it cost, Mr. Manager?" It's quite difficult to answer. Pricing for Vibe Coding tools is similar across the board, with a limited number of tokens available at $20/$30/$100 per month. Once you reach the limit, you have to wait or pay extra for overuse.

That's just a simple estimate of the cost of software development. We should add maintenance costs to this. This includes hosting, scaling, monitoring, bug fixes (they always appear), domain, and communication with external APIs (e.g., LLMs). However, this will differ slightly from traditional software development. I developed the table based on my own experience, LLMs' help, and various sources. It's safe to say that this is an approximate cost in each case, highly dependent on the domain, specifications, the accuracy of the requirements, and so on.

We can clearly see that Vibe Coding is not only a lot of fun for developers, but also cheaper and less time-consuming – which is very important than traditional outsourcing of programming to companies or freelancers. In this process, we bypass the human element that had to spend time on concept, design, implementation, testing, and so on. Is this a good thing? I don't know, but I suspect it's very good news for founders. And so we move smoothly on to the next aspect, the psychological aspect.

Psychological aspect

Let us remember that for the last 50 years the manufacturing process has been similar:

• we employ a team or delegate it to an external company
• we get a quote
• negotiation/acceptance
• then we wait for the people in the basement to produce the code
• testing phase
• payment
• publish and/or sell

Previously, this process could take several years! Today, we see the same thing happen in a week or two, or even a single day!

This creates the illusion of being fast, cheap, bypassing human problems (laziness, dragging, illness, communication) and I do it all myself, exactly.

Iterative marketing, rapid dopamine shots in the head

I'm not a neuroscientist; I'm describing this from the perspective of a programmer with 10 years of experience. In programming, dopamine hits clearly play a significant role in productivity. You know that feeling when something starts working after hours spent working on a problem? Or when a sprint ends and you've completed a large chunk of code? Many people (including me) find these hits motivating and energizing. They make us want to finish a given stage of work, even despite exhaustion. The brain loves that feeling: Wow! It's finally working. I can confidently say it's addictive, just like social media or video games. Substance addictions are also based on similar mechanisms, but I would classify what I'm describing in a different category. The sources I've found call them behavioral addictions (source).

I have the impression that the speed of the tools only fuels this. You can go very far. While attending a meeting for Vibe Coders recently, I noticed that the speakers seemed to be in a trance, excited, like, "Oh, look how quickly this started working for me, how cool!" It was funny from the perspective of someone who understands how this mechanism works for programmers.

This is definitely fueling the hype surrounding Vibe Coding. I'll touch on this further in my summary. For now, I'd also like to address the issue of the rampant drive and drive for training, webinars, courses, etc. by Vibe Coding gurus. Everyone, of course, has the right to sell whatever they want. However, this cannot be ignored in the context of FOMO, aggressive advertising, and their impact on our psyche.

Any non-technical person who sees this might feel like they're missing out. If they don't try and learn to code, they could miss out on a huge opportunity to get rich or launch a product. It's a huge temptation, one that, as herd animals, we can't easily avoid and shut out all communication.

Taking the above into account, I can confidently predict further increases in usage, greater market adoption, and a growing no-code or low-code market in the Vibe Coding format. One might ask, "Are we all programming junkies these days?" Ad voce the title question. However, I'm far from that conclusion at this point. It's still a niche market, but it's worth monitoring.

Summary and conclusions

Are we all programmers today?

Technically, perhaps. Practically, not yet. Business-wise, definitely not.

Vibe Coding is a real change. It's not a passing fad like the successive JS frameworks that come and go. It's a transformation in the way software is developed. Code is no longer the goal; it becomes a side effect of a conversation with a machine. That's a huge difference.

On the one hand, we have complete democratization. A person without a technical background can now create a working app, publish it, and test it in the market in a week. This was previously nearly impossible without capital or a team. This is a huge opportunity.

On the other hand, the app market is saturated. Phones aren't made of rubber. Users don't have infinite attention spans. Most new products don't solve a real problem; they simply replicate existing solutions. Production is growing faster than demand.

Capital also flows in a very specific direction. Tokens → models → cloud → silicon → energy. The winners are infrastructure providers. Not every vibe-coder.

Technically
You can build a lot. Sometimes a surprising amount. But debugging, security, scaling, and maintenance still require understanding the system. And here, a developer's experience is still incredibly valuable.

Psychologically
This is the most fascinating aspect. Vibe Coding gives you quick dopamine hits. You create. You act. You publish. You iterate. It's addictive. Hype breeds hype. And FOMO sells courses. Is that bad? No. Does it need to be understood? Absolutely.

In my opinion, the future belongs neither to "pure" vibe coders nor to programmers who ignore AI. The winners will be those who:

• understand the fundamentals of engineering,
• are able to think systematically,
• they use AI as an amplifier, not as a prosthesis,
• they understand business, not just code.

Programming isn't going away. Its operational layer is changing. Less and less class writing, more and more decision-making. So perhaps the question isn't, "Are we all programmers today?" But rather, "Are we all product builders today?" Because code has become cheaper. User attention hasn't. And attention, as always, will be the ultimate currency.

Additionally, we need a strategy. Today, the question isn't how many applications we'll create, but whether it's worth delving into a given problem and choosing from a long list of ideas those that actually solve market problems. Creating for the sake of creating isn't likely to lead to a bright future.

I'm waiting for your comments! Thanks!

I've been listening to the opinions of various players in the IT market: large companies, tech giants, small businesses employing 1-5 people, recruiters, employees, subcontractors, freelancers, AI influencers, and trainers on AI and its impact on the job market. In my opinion, each of them is twisting reality to suit their own interests.

Input data

My opinion on this topic is unfortunately harsh on some parts of the market. To delve deeper into this topic, we need several perspectives and input data. Based on the following components, we will attempt to realistically assess the state of the market environment in which we find ourselves.

1. Employee Perspective (Freelancers, Specialists, Beginners)

2. Employer perspective (owners, shareholders, managers)

3. Software vendor perspective

4. Employment Research

5. My perspective and conclusions

Let's go through the individual points, and at the end we will make a summary, which will also include my personal opinion about the market.

Employee Perspective

In 2025, StackOverflow conducted a survey. Approximately 20,000-60,000 IT professionals participated. The numbers vary depending on the question. The most interesting one in the context of our discussion is: https://survey.stackoverflow.co/2025/ai/. AI tools in the development process are used daily by 47%. Only 16% of all developers declare they do not plan to use AI in software development.

Tools in the development process

This is very interesting, but it paints a clear picture: approximately 84% of respondents have a positive attitude toward AI tools. However, "tools" is a very general term, encompassing chatting, vibe-coding, syntax suggestion, content generation, and so on. This isn't strictly a software-related activity, but rather everyday use for various purposes.

Sentiment

Another interesting trend is sentiment, which has fallen from 70% and above in 2023 and 2024 to around 60% today (late 2025). You can see the details below.

As we use tools more than in previous years, some of us are noticing imperfections or failures to meet our needs. The hype pervasive in the media, particularly on LinkedIn, builds high expectations for these tools. In practice, if we can't "talk" to AI, we won't be able to solve many problems.

Intended use

We see further interesting answers in the question: "Which parts of your development workflow are you currently integrating into AI or using AI tools to accomplish or plan to use AI to accomplish over the next 3 - 5 years? Please select one for each scenario."

Writing code is definitely not the dominant reason for using AI. We mostly use models for content generation, research, and education. I personally ask a lot of questions in GPT chat; I'm able to learn specific topics in a short period of time. You no longer need to read an entire book or complete a 50-hour course to gain information. It's a matter of asking the right questions and directing the conversation toward the goal of obtaining and visualizing the information you're looking for.

Accuracy

We'll move on to the next section of the survey, LLM ACCURACY. The chart below shows that confidence in the accuracy of AI results leaves much to be desired. People are rather skeptical about this benchmark.

Moreover, almost half of the respondents expressed distrust. Frankly, I didn't expect such negative responses. I myself notice distortions and hallucinations, but I wouldn't say with a high degree of certainty that I distrust the answers the models generate. As the saying goes: trust, but verify!

Frustrations

Following this negative trend discussed in the "Accuracy" chapter, let's take a look at where AI causes frustration for users:

The biggest sources of frustration are:

• "AI solutions that are almost right, but not quite"
• "Debugging AI-generated code is more time-consuming"

Both reasons are understandable. We want our productivity to increase, which is why we reach for various tools. If we have to learn how to use agents, chats, or generators, we expect a return on this investment in the form of time saved later on performing our tasks. As we can see, people dissatisfied with working with AI don't see a real impact on ROI. On a personal level, this leads to greater frustration, but for companies, it will have a real impact on finances and business efficiency.

Vibe coding

Let's start by explaining what vibe-coding actually is. In 2025, Karpathy coined the term "vibe-coding" to describe this method of collaboration with coding agents. This practice involves developing software without actually writing the code yourself, but simply communicating with an agent based on various LLM models. A survey shows that only 25% of respondents, out of over 20,000, use agents in this way.

This is also surprising. It suggests that the vibe-coding trend hasn't yet developed enough to dominate programmers' work methodology.

AI Agents Usage

The next question concerns the purpose for which AI agents are used. The vast majority (83.5%) use them for software engineering. This question may be somewhat biased given the characteristics of the respondents, as most of them work in this area. Nevertheless, we see a significant correlation between software development and the use of AI agents.

LLMs are very good at coding. This is because, as the name suggests, learning language, semantics, and syntax is, one might say, a narrow specialization of language models.

Perception of model intelligence

We often confuse the perception of a person and their intelligence with their language skills. In programming, writing code itself seems to be a problem solved by LLMs. However, this doesn't mean that a programmer's work ceases to be meaningful. On the contrary, we can now focus on things that LLMs aren't best at, such as design, modeling, architecture, UX, and so on. The actual writing of code—the final phase of code production—can be safely delegated to agents, subject to certain rigors and constraints.

On the other hand, we see frustration and dissatisfaction with AI's performance in other areas. Where we need high precision, freedom from hallucinations, and precise planning, AI still falls short, as expressed by a significant number of respondents.

My Subcontractor Perspective

From the perspective of a contractor or employee, I see the downsides of using AI. At the same time, I believe that in the coming years we will develop several frameworks for working with agents (Claude Code is already doing this, and so are competitors). The goal will be to minimize hallucinations and, in a sense, force agents to replicate our work or even produce higher-quality code.

I'm also trying to develop my own methodology and describe it in my repos, for example here. I don't know if I'll develop this idea intensively, but several such methodologies or frameworks have already been created, and I think it's something we can't avoid.

It's impossible to manage LLMs without a specific methodology and documentation. By throwing in ad-hoc prompts, we expose ourselves to significant difficulties in understanding the code, debugging it, developing it, and performing code reviews. The market is already recognizing this, which is why there's been a lot of talk lately about SDD (Spec Driven Development), where we provide relevant artifacts before assigning code writing. This is very similar to my CLAP methodology – I develop mine so that validation and bootstrapping of ideas are inexpensive and can be reduced to a few sessions with agents. However, that's a topic for a separate post. I'll try to describe it in the near future.

Key issue: real impact on efficiency

The final survey question will address the use of agents in work and their impact on efficiency. It's easy to see that only in the areas of team communication/collaboration does the use of AI agents have a neutral-negative impact from a developer's perspective.

The most important chart: "AI agents have increased my productivity" confirms that over 65% of respondents confirm that their productivity has increased. Despite mistakes and hallucinations, the process of writing code (tapping on the keyboard) itself takes a lot of time, and LLMs are excellent at it.

Previously, we used tools like the InteliSense IDE, and later language models to suggest syntax, complete lines of code, or autocomplete entire files. Today, we know that an LLM (specifically trained for coding) can write decent code faster than we, trained specialists, can produce it. However, writing itself is only a fraction of the entire process, and we must remember this. A good coder! = a good software engineer.

OpenAI and similar companies are indeed making statements (e.g., from Dario Amodei of Anthropic and Sam Altman of OpenAI) suggesting that AI will write more and more code and that the role of programmers will change. But this is more of a prediction than a declaration that "we don't code anymore." Internally, these companies employ thousands of engineers who write intensive code—but increasingly with the help of AI.

Employer's perspective

I'll briefly outline this chapter. It's important to remember that hiring programmers over the past 20 years has been costly. It's a simple matter of supply and demand. The infrastructure built during the dot-comm bubble in the 2000s has enabled us to digitize most of our lives, from health-related matters to financial management to childcare. As a result, the growing demand for people who "can talk to machines" has steadily increased, and the population hasn't kept pace with labor production. I discussed this topic in the context of the Polish market here.

The difficulty of programming lies primarily in abstract thinking and recognizing patterns that should be applied. Software archetypes, design patterns, methodologies, and abstraction are also present. Added to this is the difficulty of finding a local development environment. AI is now solving all these problems, as it can understand code at a human-like level. But what impact does this have on employers?

It's important to realize and understand that for most companies, programmers represent a significant expense. In companies where software is a significant part of the process, developers are the most expensive. Therefore, any savings without a reduction in quality seem tempting. Here's some data from the largest technology companies:

Layoffs at Google and layoff plans at other technology companies indicate a trend: downsizing in software development. However, we can't definitively determine whether AI contributed to this. Perhaps companies have overinvested in AI and LLM development, and their creation also requires engineers. Perhaps AI is facilitating downsizing due to increased productivity. We'll have to wait a while for specific data.

Employers, however, often boast that they've reduced their workforce due to automation and AI. However, this isn't happening in engineering departments. Customer service and departments with more repetitive work are most often the first to be cut. Consider Salesforce and Klarna, for example. In Klarna's case, this move proved to be a mistake. We see that replacing an employee with an LLM is no easy feat.

A recent article from December 22, 2025, shows the impact of AI on the US labor market. It also reports layoffs, primarily at Microsoft, where a significant portion of the workforce are programmers. However, this isn't due to the automation of the software development process itself, but rather to a shift in the profile of the business from software development to creating AI-based tools (Machine Learning, Data Scientists, Mathematicians).

I haven't seen a case study anywhere of software workers being replaced purely by AI, or more specifically, coding agents. LLMs remain merely tools in the hands of employees, not independent workers.

Summary of the employers perspective

From the employers' perspective, it would be best to lay off all employees, paying only for electricity and tokens. However, no one has yet been able to prove that such an investment (yes, it's massive change management, which is expensive and risky – that's why I called it an investment) can pay off in a reasonable time. Laying off employees also means losing know-how and SOPs, which aren't always documented. In fact, in most companies, this isn't documented, and knowledge is dispersed among employees. Then there's the interpersonal politics in corporations, where who you know matters more than what you know. All of this significantly complicates work parameterization, structuring, and, consequently, replacing building blocks (people) with other, less expensive ones.

Well, it's unclear whether these new building blocks are cheaper, and secondly, whether they even meet the requirements currently placed on employees. Klarna learned this the hard way, laying off and then rehiring people. It's not as simple as it might seem, despite employers playing a bit of a trickster, thus undermining programmers' negotiating power (the shrinking market is a fact, but more on that shortly) during job interviews.

Demand will certainly change, but I wouldn't say it has already happened. We're also inundated with signals, and it's very difficult to determine whether a company has actually reduced its workforce because it has AI or because it's cash-strapped and needs to demonstrate to shareholders that it will maintain profitability. This is a very difficult issue. Furthermore, the labor market isn't uniform. The workload is different in startups and small organizations, where testing AI as an employee has a greater impact on financial results and is also easier to implement. The situation is different in corporations, where laying off and replacing employees can be a process that's not worth the gamble. I still see a lot of uncertainty and ambiguity in the market. We'll have to wait another year or two before the bubble bursts and we'll see what AI can actually offer and whether it's suitable for implementation in place of programmers. The situation is similar in other professions. Only time will tell whether these are pipe dreams or a real substitute for humans.

Software vendor perspective

This topic is very broad; I'll start by highlighting the sentiment in the SaaS market. Let's take a look at the stock market and the shares of software companies today. I recommend reading the article discussing software vendors (especially SaaS) from the perspective of an investor looking at companies as a potential source of profit.

The tone is rather negative, but not unequivocal. This is a very interesting analysis. Let's take a look at the charts:

The above ETFs focus on technology companies from the software sector. Most of them are SaaS or other software providers. The significant decline and return to pre-summer 2025 levels demonstrates decidedly negative investor sentiment. Investor opinions are important because they determine where the money will flow. Both individual and institutional investors are betting and hoping for profit. It seems they're saying "I'm checking" today, expecting proof that SaaS still has a legitimacy in the markets. However, this doesn't mean their concerns are justified. Software producers have a full range of opportunities to demonstrate the superiority of their solutions over homegrown, ad-hoc vibe-coded applications developed by in-house teams.

Perhaps the scenario will turn out badly for SaaS companies. It is hard to say. One thing is certain: AI will affect both the companies themselves and their employees. If it turns out that SaaS is no longer needed, many developers and specialists working around software development will simply lose their jobs. The money will flow to vibe-coding tools and model providers.

Personally, I don't pay much attention to what's happening with individual company shares. I try to look at market trends. Here, we can clearly see a downward trend or correction. It's not clear yet. However, it's clear how the narrative surrounding software development is influencing investors. This doesn't necessarily mean imminent company failure or mass layoffs. However, it is a powerful indicator. Investors are voting with their wallets, selling shares in companies whose revenue will be drained—or at least, those they say it is. In this case, it will be drained to energy suppliers, graphics cards, servers, and, to a lesser extent, companies like OpenAI, Anthropic, or ElevenLabs.

I'll also touch on the profitability of the companies mentioned above. OpenAI predicts a $14 billion loss in 2026 in its own forecast.

Anthropic is still not profitable and won't be until at least 2028. The article doesn't provide specific numbers, but it's clear that it's still a long way from being profitable.

ElevenLabs, a company with Polish roots (founded by Poles), seems to be in a slightly better position. The press materials don't disclose profitability figures, but the article clearly indicates an $11 billion valuation in the next financing round. However, I expect that after the IPO, we'll learn that of these three players, they are the ones performing the best.

However, these are providers of models and services directly related to them. They own the IP, have people, control the infrastructure, and have investor money. At this level, however, the prices these providers offer may be too low to further develop their products without external financing.

Andrew Ng recently said that the problems LLMs solve have been solved only through scaling for several years. Since the publication, we have been relying on the same family of solutions (architecture). The technology itself doesn't make leaps; it's just the result of the increasing number of hardware and nodes processing massive amounts of data. Thanks to the transformer architecture, we can scale and increase the accuracy of models at a rate resembling a logarithmic function, without a clear asymptote (they look like an increasing arc) but also without any significant leaps.

BTW, I recommend his lectures, they are great if we want to introduce ourselves to the world of ML.

Returning to the topic, at some point, if the business model doesn't change, the largest vendors will have to raise prices, and therefore their solutions will still be cheaper than human labor, but the difference won't be that significant (x20, x30, etc.). At that point, it may no longer be profitable for the company to develop software in-house.

The risk incurred by developing solutions in-house can overwhelm existing SaaS customers. Furthermore, if a company is agile, it will require a significant amount of change. If it doesn't find a methodology that truly allows for software development without external companies, it will be forced to use SaaS. The diversity of these companies must also be considered. Small SaaS solutions for simple calculations, analysis, and so on can be easily replaced, while large ERP, SAP, and generally enterprise software solutions may be inconvenient for SaaS customers.

The golden rule seems to be hiring a one-man army, who with extensive knowledge and AI agents can work wonders. Unfortunately, this isn't great news for people with narrow specializations. More and more small organizations are talking about looking for so-called generalists or AI-driven developers. For now, these are just market rumors. Offers for traditional developers are still circulating on job boards. The processes are still ongoing. I myself recently participated in them. It seems something is brewing, but for now, the market is operating as usual.

I need to address the issue of social media here. YouTube, LinkedIn, Instagram, Facebook. All these portals are flooded with posts about AI and automation. There are even more training courses on AI programming, automation, and the use of LLMs for various purposes, both in life and in the workplace. Now I'm wondering: how can you train on something that was only created two years ago, and some tools change overnight? What value does such training bring? Who buys these courses? I've noticed a trend where well-known people are using their five minutes of free time by tapping into the keyword "AI." It's like: everyone's talking about it, so let's do a training course about it. I'll stop here because I don't want this post to get any longer.

Employment Research

Research indicates that AI is impacting the labor market in the US, Europe, and the UK by automating routine tasks while creating new opportunities in technology sectors. In the US, there has been a decline in office job offers by approximately 17-27% in non-technology industries, but a 68% increase in AI jobs. In Europe and the UK, employees express mixed sentiment—around 34% see improved working conditions thanks to AI, although many fear the loss of junior positions. I'll now break this down into three regions, as they differ in both labor law and market conditions.

USA

Employee productivity has increased by 7.2% since ChatGPT's 2022 debut, fueled by AI, as confirmed by a February 2026 report. Davos 2026 research highlights the lack of mass unemployment, despite forecasts of half of junior positions being eliminated. MIT estimates potential savings of $1.2 trillion, with 11.7-27% of the workforce exposed, according to sources.

Europe and UK

Trends similar to the US: job offers with "AI agents" have increased by 1587% according to Randstad (January 2026), with Generation Z the most concerned. In Poland and Europe, AI is transforming white-collar roles, with concerns about 20% of office workers needing retraining. The UK, as part of the data, is seeing growth in tech and finance, but a reduction in routine positions.

For comparison, let's make a table that Perplexity prepared for me:

As we can see, productivity growth is a fact. The role of junior and repetitive office work, known as "paper shuffling," is also being minimized. There's a huge hype surrounding agent systems in Europe. In the general labor market, fluctuations are evident, but this hasn't yet been reflected in unemployment rates.

There are slight increases in the US, but I wouldn't attribute this solely to the use of AI. The chart shows normal, gradual increases of around 1 percentage point. This isn't happening yet. It's more about psychology and sentiment than actual job cuts. In Europe, on the other hand, we've seen a steady decline in the unemployment rate for years, to levels around 10% and around 6% in December 2025.

This is global data, but we'll focus on the IT market. Let's first take a look at the list of layoffs in IT-related companies. Reuters recently published a very informative article. It describes the number of jobs lost. The most disturbing thing is the layoff of 16,000 people around the world.

Only two companies clearly declared that the layoffs were caused to some extent by the use of AI:

When it comes to IT offers, an excellent website for monitoring the IT market (especially in Poland) is: https://czyjesteldorado.pl/raport-rynku-pracy-it, where you will find a report from February 9, 2026.

We've seen steady increases since the beginning of 2025. The steady increase continues, with rates remaining stable. There doesn't seem to be much cause for concern.

In the US, job offers are clearly shifting towards ML/AI. Publication clearly indicates that the IT job market is no longer the "automatically hot" it once was, but it still offers solid growth and significant opportunities for those with the right specialized skills, particularly in AI, data science, and cybersecurity. Continuous acquisition of new skills is key, as companies struggle to find qualified employees. The number of job offers has significantly decreased (around -36%) compared to previous years.

Similar to the Polish market (5% of offers are for juniors), beginners struggle to find work after or during their graduation from universities or private courses. On the other hand, 2025 was a year full of mass layoffs, which slightly slowed down the job market.

Comparing the data, the US tech market is still looking for talent, but technical skills are key to getting through the slowdown. In Poland, on the other hand, the market is active and stable, with a large number of job offers and good salary ranges, but the pace of salary growth and the recruitment boom no longer resemble the "Eldorado" of years past.

But is this a result of the AI ​​revolution? All indications are that demand for specific specializations fluctuates between them, but the market, both locally and globally, is not entirely inaccessible to a skilled specialist. Beginners are in a worse position, and AI may have some impact here.

Summary and my conclusions

Since this post turned out to be much longer than I expected, I will try to summarize it efficiently and draw the right conclusions. AI is truly changing the way software is developed, but it hasn't killed the IT market. At least not in 2026. Instead of a "here and now" revolution, we have a slow, uneven transformation in which winners and losers are clearly distinguished.

Below are the 8 most important conclusions from the above considerations and data.

Productivity is growing, but not linearly

• Over 60–65% of programmers declare increased productivity thanks to AI.
• The profit is mainly related to writing code, research, and learning – not the entire engineering process.
• Design, architecture, domain modeling, and business decisions still require humans.

AI is a tool, not an employee

• There are no credible case studies of mass replacement of engineering teams by AI.
• Most often, repetitive and supporting roles (support, back-office) are reduced, not core engineering.
• Companies that tried to "cut corners" (e.g. Klarna) ended up getting hurt.

AI's biggest problem isn't a lack of power, but a lack of methodology.

• Hallucinations, “almost good” solutions, and difficult debugging are major sources of frustration.
• Ad-hoc prompting does not scale in real projects.
• The market is naturally moving towards Spec / Structure / Methodology Driven Development

Vibe-coding is a niche, not a standard

• Only about 25% of respondents use agents fully "without writing code".
• Hybrid work models dominate: human + AI, not AI instead of humans.

Juniors and narrow specializations are most at risk

• Entering the industry is more difficult today than it was 5-10 years ago.
• AI raises the “minimum threshold of competence.”
• There is a growing demand for generalists, systems engineers and people who connect technology with the business context.

The IT job market hasn't collapsed – its shape has changed

• In Poland: stable number of offers, reasonable ranges, no panic.
• In the US: shifting the focus towards AI/ML/Data, less "classic CRUD" dev.
• Decrease in offers ≠ mass unemployment – ​​this is more of a correction after years of overheating.

SaaSs are not dying, but they have to defend themselves

• Investors are skeptical, sentiment is weak.
• Small, simple SaaS are potentially replaceable by in-house + AI.
• Large systems (ERP, enterprise, compliance, mission-critical) still have a huge advantage.

The narrative on social media is much more radical than reality

• AI-hype is used to sell courses, training and outreach.
• The real market moves slower, more cautiously and much more pragmatically.

My point of view

I hope the above summary adequately summarizes the content of the article. However, I'd like to add a few of my own thoughts. The game is multidimensional - its image is neither two-dimensional nor even five-dimensional. There are many players in the market: different company segments, diverse goals of market actors, investors, and the speculative bubble. So much is happening at once, and it's difficult to draw simple, clear-cut conclusions.

From my perspective - as someone who actively participates in the market, who has recently been intensively looking for new challenges and taking part in many recruitment processes in parallel - two things caught my eye the most.

First, very strict technical requirements are set during technical interviews. The market no longer rewards narrow competencies or the "safe middle class." What's expected is genuine independence, a comprehensive understanding of systems, and responsibility for technical decisions.

Secondly, there's considerable uncertainty in the approach to AI. Some companies proudly speak of their active use of tools like Claude Code or coding agents. Others, however, limit themselves to statements like, "We're using AI, but we don't yet have clear boundaries or methodologies." This is a clear signal that the market is in a transitional phase – tool adoption has outpaced process maturity.

Additionally, there's significant uncertainty surrounding the approach to AI. It's becoming increasingly clear that the market is becoming more challenging and requires versatility. In my opinion, this will lead to a model in which companies prefer to employ a few very strong, cross-functional units rather than maintaining extensive teams that struggle to coordinate their work.

This is how I see the job market in a few years:

• strong focus on AI/ML,
• a natural connection with the areas of Big Data and Cloud,
• high value of people combining several specializations at the same time.

My vision is that companies will gradually reduce their reliance on external software development services. Instead, they will acquire top talent from the market - people capable of independently designing, implementing, and developing systems, often acting as "managers unto themselves," working directly with the product manager or owner.

This isn't good news for everyone. However, it is very good news for those who can combine technology, business context, and the conscious use of AI as a tool, not a prosthesis.

I wish all readers a lot of enthusiasm for learning, because it will certainly come in handy, and the only recipe for career success is: creating your own products or quickly adapting to the surrounding IT employment market. I'd love to read your thoughts and opinions on this topic.

Thanks and see you next time!

In strategic Domain-Driven Design (DDD), we distinguish several key elements. One of them is Context Mapping. Bounded Contexts can and even must communicate with each other. This is an integral part of software system design. Today, we will explore the types of mappings and describe them with real-world examples.

Embedding in DDD

When it comes to DDD, we divide it into two components. Strategic DDD deals with high-level decisions, defining contexts, ubiquitous language, and communication between components (bounded contexts). Tactical DDD, on the other hand, breaks down the elements located within the bounded contexts into their constituent parts. This is a significant simplification, but for the purposes of this blog post, we can assume that this is sufficient information to understand the context of Context Mapping within this overall framework.

Sources

The literature that is helpful on this topic includes primarily the so-called "blue book" by Eric Evans and "DDD Distilled" written by Vaughn Vernon. As a supplement, we can use the DDD Crew repository.

I could end the article by simply linking to these sources. However, I want to expand on the definitions with examples from real-world business. This is precisely the most difficult part of educating oneself and others about DDD. Few companies share their practices, and we mostly rely on theoretical examples proposed by educators. Today, we will try to break this pattern and discuss Context Mapping in a more practical way.

Open / Host Service

This situation involves one Bounded Context opening its API and allowing dependent services/modules to use it based on the API documentation (usually), exposing the language of its context externally but not reacting to the specific requirements of its clients. This is the most common model, especially in microservice applications, where Bounded Contexts communicate with each other via REST API.

A real-world example could be the Spotify application or another streaming platform. Let's assume that one Bounded Context is the Catalog, and the other is the Player. In this situation, the Catalog exposes its API or Facade (if it's a monolith). This is a typical scenario where the Player can use the data provided by the Catalog in any way it sees fit on its side, but only through the public API contract. This is particularly useful when we want a part of our system to be publicly accessible.

Conformist

In this type of mapping, we are dealing with an upstream->downstream relationship. It closely links the conformist part of the system (BC) with the upstream. It can be said that decisions made by the upstream can disrupt everything in the downstream BC that is based on the contract with the upstream. The downstream does not have its own domain model in this area and directly adopts the upstream model, accepting the risk of its changes.

A real-world example could be any application that uses Amazon's API. Amazon makes changes to its API? It breaks backward compatibility? You have to adapt. In this case, clear and predictable behavior from the API provider is essential to keep up with changes in the upstream system.

However, this involves communication with an external module. To better illustrate this with an example of a provider within our organization, let's consider any product company. Let the upstream be BC User Management, owned by the central platform team. The model should contain basic entities: User, Role, Permission, and the Value Object Status. Let's also assume that the team responsible for this BC has a strong position in the company, or its Tech Lead is a close collaborator of the management.

In this example, let's use a Bounded Context called Billing as the downstream service. Billing needs information about users as a client; it doesn't own the user identity and doesn't have the budget or mandate to create its own model (for example, due to staffing shortages).

In practice, this will mean that the Billing module will import DTOs from User Management and use them directly. In this case, fields such as user_id, role, or status (or many others) will be stored in exactly the same form. There is no mapping or translation involved.

If, one day, BC User Management changes statuses by name, alters the semantics of roles, or removes a field from the model, the Billing model will, in common parlance, "break down." Importantly, this is acceptable in this type of mapping. This is usually because the cost of isolation would be greater than the cost of adaptation. It also indicates that the Billing team has less influence on the company's overall strategy.

ACL (Anti-Corruption Layer)

An ACL (Anti-Corruption Layer) acts as an intermediary layer between two Bounded Contexts. Its purpose is to protect the downstream model from being contaminated by the language used in the upstream context and to provide resilience against changes, although this resilience is still limited.

Compared to the Conformist model described above, the main differences, besides the larger investment required during downstream BC implementation, are:

• Downstream does not accept the upstream model
• Downstream has its own domain-specific language
• Integration is achieved through translation, not direct use of the models

A real-world example is a system that handles subscription billing and uses a payment gateway or payment systems such as Stripe. The typical data structure in such systems includes: Customer, Invoice, PaymentIntent, and Subscription. The API changes relatively frequently, and the terminology is also subject to significant variations.

Our Bounded Context, which we'll call Billing, might use completely different terminology, for example: Payer, Charge, BillingPeriod, Settlement. In this case, the Billing team doesn't want the semantics and naming conventions to leak into their model (because if we change payment providers, we might have a problem, and the change would leak into our model).

We then create an ACL, which is a layer that maps data from the payment system. The class using the API could then be called, for example, BillingPaymentAdapter, and we add a PaymentMapper to it, which acts as our ACL. For clarity, I'll include a diagram:

As we can see above, our downstream model is completely independent of Stripe or any other provider. Here's a good example of the implementation: the ACL (Anti Corruption Layer) should reside in the infrastructure layer if we are using a Hexagonal architecture or its equivalent in other approaches. According to good practices (SOLID principles), dependencies should only flow in one direction (the domain should not be aware that the ACL translates from an external system). For example, creating a dependency like domain -> infrastructure or domain -> Stripe SDK is not allowed. The domain in our code should only contain information about the ACL class interface (for example, PaymentProviderPort).

Shared Kernel

In some situations, we want the common parts of Bounded Contexts and their model to be deliberately separated, limited, and shared by both modules. The key characteristics are that the code in the shared kernel should be kept to a minimum, and it requires coordination on both sides of the relationship (there is no upstream-downstream relationship, but rather a more balanced one).

This mapping makes sense when both Bounded Contexts truly share the same concept and definitions, the cost of duplication and synchronization is greater than the cost of sharing, and the teams on both sides are aware that changes must be coordinated collaboratively.

As an example, consider a business application containing the following modules: Identity and Audit. The Identity module is responsible for users, roles, permissions, and access policies – typical functionality in many B2B platforms. The Audit module will maintain a log of events, recording who performed a given action and when, as well as fulfilling any legal requirements such as ISO or SOC2.

In both contexts, UserId and TenantId will be common concepts. This means that validation rules, semantics, and Value Objects will be shared – for example, a Value Object named Permission. In the shared-kernel (if it's a modular monolith), we can place the following classes:

shared-kernel/
    identity/
        TenantId
        UserId
    security/
        Permission
    time/
        Clock 

In the code above, we see that the common parts of both models will be controlled by both teams. Any change to TenantId must undergo review from both sides, and contract tests must be written to ensure compatibility from both sides of the relationship.

Shared Kernel is recommended in cases where the organization has a high level of organizational maturity, including shared code reviews, shared testing, and a clear division of responsibilities. Furthermore, the teams must collaborate closely, share common business goals, and be able to agree on changes to the Shared Kernel. Imagine a Money class. If changes are made to it, they will likely affect the entire organization globally, thus the sensitivity to change is balanced across all teams.

However, care must be taken not to overload the Shared Kernel with too many things. It should have limited responsibility, reduced to a minimum, and the issues it covers should be marginal to the Bounded Contexts that use it. Ideally, the Shared Kernel should be small, slow-changing, and contain Value Objects rather than complex processes or entities. It's also good if it doesn't have dependencies on infrastructure – this significantly simplifies design and coding. When a divergence in definitions is more dangerous than coupling, we use a Shared Kernel. In other cases, other types of mappings should be considered.

Published Language

It must be admitted that this form of mapping has sometimes much in common with Open/Host Service. I'm referring primarily to the form of collaboration between teams. One team opens up a space with documentation, which other Bounded Contexts access to obtain information about naming conventions, interaction documentation, and some details about the processes the API provides. Let's look at great example of the difference.

OHS without PL: The bank provides an API for transfers. The /transfers endpoint accepts JSON with the fields sender_account_id, recipient_account_id, amount_in_cents, and currency_code. This is OHS - the API is open and documented. But if, in 6 months, the bank changes amount_in_cents to amount_minor_units, all clients will have to adapt. Each downstream system translates this data into its own domain language.

OHS + PL: The same bank, but it implements the ISO 20022 standard for payments. It uses precisely defined types such as CreditorAccount, InstructedAmount, and PaymentIdentification from the XML/JSON schema defined by an international committee. Now the semantics are common and stable. When Visa, Mastercard, and SWIFT use the same ISO 20022, everyone speaks the same language. A change would require ratification of a new version of the standard by the committee.

To summarize the diffs:
Open Host Service operates at the integration architecture level (HOW we expose services: REST, gRPC, access policy), while Published Language operates at the domain semantics level (WHAT the data means: vocabulary standardisation, contract governance). These are not "patterns used in combination," but orthogonal dimensions - you can have an open API with your own dialect (OHS without PL) or a closed ISO 20022 standard only for partners (PL without OHS).

Let's look at the visualisation:

The concept is therefore very simple. Let's take, for example, applications that use OAuth2 for authenticating/authorizing their users. When you log in to an application using your Google account, the OAuth Published Language is at work:

• access_token - access token
• refresh_token - refresh token
• scope - scope of permissions

This language is published as a standard, and everyone understands it the same way – whether it's Facebook, Google, or GitHub. Therefore, with an open API, we can connect directly to the services mentioned above thanks to this language, which is published as a universally known standard.

Separate Ways

This mapping format assumes that integration between components (BC) is not needed or, in some cases, will even be impossible. In this scenario, for the purposes of a given context, we can freely duplicate the ubiquitous language, write our own solutions, processes, and algorithms because another team has no insight into or interest in seeing the changes and assumptions that our project implements.

Sometimes it's easier to write your own package/module than to integrate with an internal or external business component. An example of this would be an ERP system for a manufacturing company.

Context 1: Production Planning

• Manages the production schedule
• Assigns machines and operators
• It tracks the progress of production orders
• It has its own definition of "Order" = a production order with dates and machines.

Context 2: Quality Control

• It has its own definition of "Order" = a batch of products to be inspected
• It conducts product inspections
• It records defects and non-conformities.
• It generates quality reports.

In this case, the order is something completely different, and production planning is not closely linked to Quality Control. The reasons for this separation can vary: for example, the current solution "works, so we don't touch it," different teams, different legacy systems: Production Planning uses an old SAP module from 2005, while Quality Control has its own system purchased from a different vendor in 2018, different data models, or different work rhythms of the Bounded Contexts.

Let's assume the cost of writing the integration is 200,000 PLN. Let's say this represents 7 months of work for one programmer working on a B2B contract - based on average senior developer salaries – I encourage you to read my previous article discussing the situation in the Polish IT market.

The question to ask in these types of problems is: is it worth integrating two services if the only benefit is some nice diagrams from the architects at the end of the day? Of course, this is an oversimplification, but in this particular case, there's no point in integrating something that naturally operates completely independently in the business. I hope this illustrates the use cases somewhat.

Big ball of mud (rather antipattern)

Oh, I could write for hours about this. In my 10-year career, this is the type of mapping I've encountered most often. The results of modeling Bounded Contexts in this way are usually mediocre, if not downright terrible. It leads to mixed aggregates, excessive coupling, a large amount of knowledge hidden in the developers' heads, and difficulties in obtaining testable code.

This is actually just a simplified overview. It's important to remember that most business or B2B applications will have subsystems built in this way. Very often, the code within these subsystems will be crucial to the application's functionality. To solve the problem encountered with this mapping, it's necessary to break down the large "ball of mud" into smaller, more understandable Bounded Contexts whenever possible. Sometimes, the only way is to create new Bounded Contexts for new features and separate them from the "Big Ball of Mud" using the ACL (Anti-Corruption Layer) discussed above.

I think I'll discuss the topic of the "Big Ball of Mud" in another article dedicated to legacy systems and ways to modernize them. So I invite you to follow the blog; many interesting stories based on real-world examples (anonymized, of course) from my previous projects may appear here.

Not all topics were covered

In the sources mentioned in the introduction, we can observe some ambiguity surrounding Bounded Contexts and a slight confusion between this concept and team relationship types. To provide more structure, I created my own diagram that separates the dependency of Bounded Contexts from team relationships. The concepts are very closely related, but I feel that this distinction hasn't been clearly made in the books and materials I've read. This is simply my interpretation of the available literature. Let's look at the image below:

As you can see, I didn't cover two variations in the post:

• Customer-Supplier
• Partnership

I did this intentionally. In my understanding of Context Mapping, the Customer-Supplier and Partnership relationships refer more to communication between teams than to the technical conditions under which they connect. I believe they are self-explanatory from their names and there's no need to go into more detail. I will address the issue of communication between teams in a separate article, where I will include the above-mentioned points and discuss the red blocks from the diagram in more detail.

Another element from the legend is the arrow, which describes the communication overhead between teams. This quite accurately reflects how much you need to coordinate with the team maintaining the neighboring business component and how many meetings/communications you will need to exchange with them. In some cases, this will be a significant criterion, for example, in situations where communication is not well-developed.

When we look at my visualization, we see that the green area is nested inside the red one. This also describes a certain hierarchy in the division of tasks. First, from a higher level, we look at communication between teams (or, if one team is responsible for multiple business capabilities, communication within that team), and only then do we go down to the level of mappings. That's how I see it and that's how I organize it in my mind.

Summary

I hope I have described the topic of Context Mapping in a reasonably clear way. From the perspective of strategic DDD, it is a very important element of system-level design. Many sources, presentations, and books describe context mapping in a very general way. I tried to break away from that and show examples of applications and systems that we encounter in our daily work or everyday life.

It's important to remember, however, that at the enterprise level, Context Mapping is not just a technical exercise, but above all a powerful political tool. Every line on the map - whether Customer-Supplier or Conformist - reveals the actual power dynamics within the organization and the flow of decision-making. As architects, we must be aware that the choice of pattern often stems not from the elegance of the code, but from budgetary hierarchies or the willingness of teams to cooperate. Context mapping allows us to name these tensions explicitly, transforming architecture from a theoretical diagram into a real strategy for navigating the power structure within the company.

If you disagree with my arguments, notice any imperfections, or would like to discuss the topic further, please feel free to comment. We learn the most through exchanging ideas. Nothing is set in stone. Methodologies and concepts can change, and it's important to keep up with market changes and adapt definitions to the world around us – never the other way around!

See you next time!

This is the third and final installment in the series "Why Janek Doesn't Program?". After four years, we revisit the issue, examine what has changed over time, and examine the current situation of the titular Janek. We'll try to present the situation of entry-level users and try to find good advice and guidance for them. I invite you to summarize the series and share your thoughts.

A quick recap of the previous two parts

In the first part we approached the topic:

A 2022 article examines why there are so few programmers in Poland (only 0.66% of the population, compared to 1.73% in Sweden and 1.21% in the US), despite the market then seeking around 100,000 specialists annually and the lure of excellent salaries. I debunk the myth that programming requires special talents – citing research showing that around 44% of people can create a mental model of simple programming instructions, even without prior experience.

The problem lies elsewhere: primarily in the fear of the unknown and the belief that programming is incredibly difficult, which blocks people even before their first attempt at learning. Added to this is the paradox of the job market – 80-90% of offers are for specialists, and only 10% for juniors, so even if someone is learning, it's difficult for them to break into the industry. I announced that this is just the beginning of the analysis and that this topic will be continued.

In the second part, I lash out at Polish universities and demonstrate the absurdity of the system: every year, 35,000 students enter computer science, and only 13,000 graduate, meaning 60% drop out. But be warned – this isn't because programming is difficult, but because students are drowning in algebra, physics, and other science subjects, of which there are plenty, and programming itself only accounts for 20-30% of their study time. Of the 25 subjects in the first two years, only 5-6 are actual programming.

I criticized the fact that lecturers are mostly theoreticians with no commercial experience, teaching on outdated hardware and software from before 2010. This is why bootcamps are ruining universities, because even though they're shorter, their programs actually meet market needs. The only advantage of these programs is the internships, which actually help you enter the market. I conclude that the education system is completely out of step with IT, failing to prepare people for real jobs, and wasting potential programmers on unnecessary courses.

What has changed?

First and foremost, the situation for juniors has worsened. In my article from a week ago, where I analyze the current situation, a downward trend is clearly visible (only 5% of offers are directed at juniors), meaning there are twice as many junior offers – sick!

Programming schools have largely fallen into decline. The promise of entering IT is so distant that even touts and marketing magic can't convince a warehouse worker that they'll become a programmer in three months. A new trend has emerged: instead of promises of becoming a programmer, we have promises of becoming an AI DEV, which strongly captures the imagination of potential customers. Nevertheless, the reduction in the training market has been further exacerbated by AI. I'm linking to an article describing this phenomenon.

The labor market is now an employers' market, so first of all:

• Junior has little say in the negotiation of the salary (as if it matters, since even getting an interview is bordering on a miracle)
• The employer no longer has to worry that the mid will escape because the competition will give him +20% to the salary - there is no pressure to raise it, we can also see this in the mentioned article.

It is not difficult to guess that these changes are rather negative for people who want to be in IT.

What hasn't changed?

The way universities operate hasn't changed much. Syllabi have been slightly adjusted to accommodate AI and ML, but generally speaking, higher education in Poland, especially public education, isn't eager to pivot and change directions quickly. The problem lies with the faculty, which stalled 10 years ago. And the world is rushing forward inexorably. Even for me, someone who tracks trends and observes the market daily, it's difficult to grasp certain aspects cognitively. It's no wonder, then, that those unfamiliar with the market struggle to keep up.

Private universities are meeting these expectations, offering programs more aligned with market needs. The general situation on the Polish labor market (high minimum wage, decline in two-person households, rising living costs in job-providing centers) is a kind of impediment to private education. Few will take out loans for the illusion of a future job in the Eldorado that, from a courier's or salesperson's perspective, is IT. I personally believe that IT is one of the best markets for financial development. However, the entry barrier is so high that it requires difficult decisions and a great deal of determination to achieve success.

AI tools and the situation of juniors

A very hot topic, i.e. AI in IT, should be viewed from two angles:

1. AI/ML subdomain in the job market
2. AI support in everyday work (AI clients as I say)

AI/ML

When it comes to AI/ML, a significant number of companies are migrating their software solutions to those based on language models, machine learning in general, and data processing. This supports the natural evolution of companies to become AI-driven. This also happened at my current company. The entire software team was laid off, leaving a handful of people to replicate certain functionalities using the data platform and AI/ML. I personally stayed at the company, as described in the article.

Unfortunately, there's no good news for juniors here. Their skillset and lack of experience make it impossible to start in AI/ML or even the data industry. They require solid experience and the ability to think in design and system terms, not just solve individual small problems. That's why, for me, it's easier for a programmer to change development directions than for someone who doesn't exist in the market and has no experience.

AI Clients

The news here is encouraging. You no longer need to know everything to code well. Coding assistants like Codex, Claude Code, Antigravity, and finally Cursor (arguably the most affordable in terms of both price and usability) make it completely easier:

• Completing homework assignments in recruitment
• Learning the issues point by point
• Writing a portfolio on Github or other media
• Creating applications that are alive and allow for micro-founding
• Employer perspective: Junior + AI == Mid for a much lower rate (average -50% salary)

AI will empower the smart but weaken the stupid (sorry :()

I have a theory that AI makes the stupid even more stupid and helps the smart. Now you can make a 100% difference by investing less than 100% more. With AI, you can accelerate the learning process, shorten the learning curve, and deliver value to the business at a much lower rate. From a non-technical perspective, it doesn't matter whether it's a junior or mid-level; what matters is the result. Intelligent and clever people will be able to use this to their advantage.

The rest, however (I don't want to name anyone here; I'm not here to judge others; I was young myself and I know that mindsets change over time; that's the nature of youth) have a big problem. If you're not using AI to increase your chances in the market, you're making a huge mistake. It's impossible to catch up with your competitors today without AI, because anyone with a better mind will do it. This also applies to people who want to change industries.

The answer to the title question in 2026

Let's check the official data and compare the number of programmers with 2022. The latest reports show a significant increase from 250,000 to (numbers vary) approximately 300,000-350,000 professional programmers. These figures indicate a growth of approximately 30%. While these figures are imprecise, as IT is a broad term and programmers should typically account for 70% of jobs, this is a very rough estimate. Most data points to the broader IT market, not specifically programmers.
I obtained the data from several sources:

https://forsal.pl/praca/wynagrodzenia/artykuly/9527794,mamy-juz-w-polsce-ponad-400-tys-specjalistow-it-ale-prostsze-zadania.html
https://stormit.pl/raport-o-programistach-2025/
https://www.otoprzetargi.pl/news/w-polsce-brakuje-ok-50-tys-specjalistow-it-a-w-ue-ponad-270-tys

On average, the percentage of Poles coding has increased as we are currently going through a crisis and the number of our citizens is decreasing year by year. This increases the percentage. Therefore, we have approximately 0.8-0.9% of the total population. It appears that the progress of digitization and generational renewal in the labor market is bringing us closer to more advanced economies such as Germany and Sweden.

Janek is programming after all! But he's having trouble with the work

As our baseline metrics have improved compared to 2022, we must deny the notion that Poles aren't programming professionally. This has changed, the market is becoming increasingly saturated, and this is causing problems at the entry level. We won't overcome this without a change in the mindset of employers.

In my opinion, we should value individuals and take a closer look at them, rather than filtering them out because they have less than X years of hands-on experience. This is a very difficult issue because assessing someone requires knowledge of people and a certain sensitivity, an instinct for detecting potential. Companies are willing to pay significant amounts of money to talent acquisition companies to bring in high-potential specialists. But when it comes to juniors, the market isn't yet ripe for large-scale hiring.

Yeah, maybe that's a business idea: creating a junior farm, giving them all the AI ​​tools available, and helping them apply for positions from junior to mid-level? I'll have to think about it. Anyway.

What I'm trying to convey here is that, in my opinion, recruitment processes shouldn't be based solely on experience, but also on individual predispositions to adapt and adapt to a given industry. The market isn't ready for this yet, but I believe technological advances and the deteriorating macroeconomic conditions in Poland will force employers to seek solutions. And this is where juniors come in, all dressed up, who, for low wages (also due to the zero-tax relief for under-26s and the government's threats to eliminate free B2B contracts – tax preferences), can achieve 90% of the results of someone earning 50% more for less. That's how I see it; I don't know if anyone agrees. Ultimately, everyone is entitled to their own perspective.

I'm curious how you assess the situation in the Polish IT market and what solutions you have for the problems facing both employees and employers. You already know my perspective. Thank you for reading this far!

This article was previously published in Polish, but I thought I'd post it to give you the information you need four years later. Please share the article from 2026, which will be published soon.
In the first part of this article, we learned the numbers that describe the shortage of programmers in the Polish IT job market. We also learned how many active programmers currently work in the industry and what the situation is like in other countries. Today, we'll expand on the topic of universities and their impact on the current situation.

This is the second part of the series, I invite you to follow it in its entirety

If you are reading part 2 and haven't managed to read part 1 of the series, be sure to check it out here: link to part 1 of the series.

Higher education in numbers

According to official data from the Central Statistical Office (GUS), universities in Poland produce approximately 13,000 computer science graduates each year. Not all of them are future programmers, but it's safe to assume that at least half will pursue this field. After completing programming and database courses and completing internships (if the university offers them), computer science graduates can look for their first job.

Many students can program before entering university. However, we must distinguish between the ability to work on commercial projects and programming skills, which alone don't guarantee a job or starting a business and fulfilling contracts. Furthermore, in some cases, companies hiring Junior Developers require a computer science degree.

Surprisingly, however, every year we have at least 35,000 IT graduates (source), (source2) who choose an academic path. What happens to the 60% of students who don't complete their program? The answer is simple: they enter the job market directly (not necessarily in IT) or other fields of study and continue their education. There is no other option, if we take into account that unemployment in Poland is only 5-6% (GUS).

Is programming too difficult?

The thesis from the first part seems to be confirmed: programming, or computer science in general, seems too difficult or uninteresting for IT aspirants. After the first year of education, most candidates leave university.

Nothing could be further from the truth, and this is precisely where the problem lies. At universities, when we review the so-called syllabi, we discover that among the approximately 25 subjects in the first two years of study, there are only 5-6 subjects closely related to programming.

Overwhelmed by algebra or physics, students drop out or are expelled from universities, even if their aptitude for learning programming is sufficient. Potentially promising programmers are not profiled specifically for programming; instead, they possess extensive knowledge of the sciences.

On the other hand, it could be said that this tests a student's ability to learn. If they learn differentiation, they will certainly be able to grasp the abstraction that constantly occurs in programming.

I'll leave the above counterargument open to debate. Do we need this much time spent on math and physics? Personally, I think the basics of math and physics would be perfectly sufficient. Meanwhile, in my first four semesters, I studied five mathematics subjects alone: ​​two semesters of calculus, algebra, statistics, and discrete mathematics. Did this help me learn programming? I'm not convinced.

Programming schools are crushing public universities

This is precisely why programming schools are developing so rapidly. They are unrivaled in the public sector when it comes to programming instruction. They claim to deliver better results in a shorter time compared to their educational competitors. I'll leave the actual effectiveness of bootcamps for discussion – that's a topic for a separate article. The focus is solely on their assumptions. Higher education in Poland is not prepared for the enormous need to "produce" programmers.

I haven't found a higher education institution in Poland that focuses directly on programming. Typically, programs are general in nature, with the option of specializing in the final semesters and writing an engineering thesis related to programming.

If computer science degree programs covered what well-formed bootcamp curricula do today, there would certainly be many more people willing to complete them.

Let's fantasize!

Imagine a programming course extended fivefold. And it was free. How many portfolio projects could we create during such a course? How extensively could we cover algorithms and data structures? How many tools like Scrum, version control systems, or software engineering topics could we learn in depth enough to launch us into the job market?

Programming schools aren't perfect either; they overpromise their clients. Their curricula, however, align much better with market demands in IT. This means we have bootcamps and courses that are too short to adequately explore certain topics, and, on the other hand, programs overloaded with unnecessary topics.

Personally, if I had to choose now, I'd still go to full-time studies (or part-time if I could afford it), but I'd learn programming on my own and look for a job after four or five semesters. As a result, I'd probably have to switch to part-time studies. This is the advice I give to high school graduates who want to become programmers.

Archaic technologies only make the situation worse

Higher education is lagging behind the technical demands placed on candidates in the job market. Programming instruction in higher education often boils down to learning a low-level language and a few object-oriented languages. Over the course of four years, approximately 20-30% of subjects are strictly programming-related. This is insufficient. Furthermore, the software versions used in laboratories date back to pre-2010.

Higher education faculty are often theoreticians who haven't worked in commercial settings. In my case, programming classes were taught by very polite lecturers, but unfortunately, most of them graduated a dozen or so years ago. They weren't up to date.

If universities sought programming trainers available commercially, students would gain knowledge directly from the place they ultimately end up. The curricula themselves would also be more responsive to the market, which, as we know, is changing rapidly.

The only advantage, a major advantage, is the internships that most universities offer to their students. In my case, like many other candidates, the internship proved to be a milestone that propelled me into the job market. After landing my first job, it became increasingly easier with each passing year to negotiate terms and seek new projects and employers.

Summary

In this article, I bluntly criticize higher education. Our education doesn't adequately prepare students for programming and market needs. Many students also abandon computer science studies due to difficulties with science subjects. The problem is exacerbated by the lack of appropriate faculty. Nevertheless, internships are undoubtedly a plus, making technical studies worthwhile. However, this isn't enough.

Fortunately, programming has been a key pillar of extracurricular activities in primary schools for some time now. Hopefully, secondary schools dedicated to programming, which are also slowly emerging, will also set the pace for universities. In the coming years, we will see the popularization of programming, which should have positive effects on the IT market in Poland.

This article was previously published in Polish, but I thought I'd post it to give you the information you need four years later. Please share the article from 2026, which will be published soon.

Programming is considered particularly difficult. Job advertisements show how highly the market values ​​programmers' skills. Compared to other industries, such as trade, manufacturing, or even marketing, a programmer can earn significantly more based on their knowledge, skills, and experience. Why are so few people able to become programmers? Why, despite high demand, does such a small percentage of our population decide to begin their programming journey and then seek their first IT job?

Data is the basis for analysis

To analyze the problem, we'll first look at the real numbers. In Karol Bednarz's article: How many programmers are there in the world and how many in Europe?" [2022], which was published half a year ago (relatively fresh data) we will check how many programmers there are in Europe in individual countries.

Poland:

Number of developers: 250 000 
Number of inhabitants of Poland (source: Central Statistical Office): approx. 37 767 mln
The share of programmers in our population is only: 0,66 %

Comparison with other European countries:
Germany: 901 000 programmers, the country has 83.2 million inhabitants -  1,08 %
Sweden: 180 000 programmers, the country has 10.42 million inhabitants -  1,73 %
Ukraine: 212 500 programmers, the country has 43.79 million inhabitants -  0,49 %
UK: 408 000 programmers, the country has 67.33 million inhabitants -  0,61 %

And USA:
4 000 000 programmers (4.3 million across North America) (https://www.bairesdev.com/blog/how-many-software-developers-in-the-world/), the country has 331.9 million inhabitants -  1,21 %

*data regarding the number of inhabitants comes from Google.com as of February 13, 2023.

The above data should now be compared with the demand on the IT labor market in Poland:

The number of jobs sought in the first quarter of 2022 was: 26,121.

An article on Prawo.pl perfectly describes these numbers from the first quarter of 2022:

That's just one quarter. If we multiply that by four, we'll find that the market was looking for about 100,000 programmers annually in 2022. If the entire demand were met (and we already know it hasn't), we would have about 350,000 programmers in Poland, which brings us closer to the desired 1% of the population.

To confirm this number, we can also look at the 2022 IT Salary Report published by justjoin.it. The report shows that job offers for programmers have exceeded 100,000. Source: https://raport.justjoin.it

Compared to developed countries (excluding the UK), we lag behind in terms of the percentage of programmers in society as a whole. This isn't due to the low number of companies looking for programmers.

The problem, however, lies mainly with Kowalski, who does not start learning programming or does not reach a level that will allow him to successfully enter the IT market.

Additionally, the employment structure in IT is characterized by the fact that 80-90% of job offers are for specialists, not beginners. According to data that annually raises alarming concerns about the IT workforce shortage, companies will have to change their hiring tactics and train entry-level employees, or more precisely, start hiring more juniors.

So why, in this context, are we unable to catch up with other countries? We will attempt to answer this question later in this article.

Programming has long been considered difficult

A 2002 paper by Dan Bricklin, describes how a programmer constructs instructions for a computer and how he can correctly predict the results, and how this can affect the acceptance of the system.

The article inspired me to write this one, and its message can be summarized as follows: some people can learn programming faster. There are also people who find the syntax of languages ​​too difficult. Excerpt from the article:

"Programming languages ​​like Assembler, FORTRAN, C, and Java are the least widely accepted. Their syntax is very unforgiving."

After several years of experience in the industry as a programmer, I maintain that programming isn't difficult. It's a craft that virtually anyone with the right amount of motivation can learn. It's also not syntax, but the way we think and analyze specific problems that brings us closer to becoming a programmer. The conclusions from the above article are unfounded.

I don't think motivation is the problem here, either. High salaries, remote work, numerous benefits, team-building events, modern equipment and offices. Who wouldn't want to work in such conditions?

Are some people born to program?

To answer this question, I will use another publication from 2006 by Jeff Atwood, co-founder of Stack Overflow: “Separating Programming Sheep from Non-Programming Goats”

This article refers to a study (link to the study) that was essentially intended to answer the question: what are the differences between people who program and people who don't program? Literally translated:

“a way to separate the programming sheep from the non-programming goats in computer science classes”

The results of the study are very interesting. Using basic programming instructions such as assignment, iteration, recursion, and conditional, responses were collected from individuals who had never had any experience with programming. These were computer science students, a small group among the population largely focused on programming.

The test used in the study can be downloaded here.

In terms of the basic instructions we will encounter during learning, the results showed that:

1. 44% of students created a coherent mental model of how the task works (even if it's incorrect!).
2. 39% of students never created a coherent mental model of how the task works.
3. 8% of students ignored the task and left the answers blank.

The conclusion presented in the study:

“To write a computer program, you have to come to terms with it, accept that whatever you want the program to do, the machine will blindly follow its own nonsensical rules and come to some nonsensical conclusion”

This study also showed that approximately half of the students participating in the study would not have passed a pre-test constructed according to the above principles. Is this high entry threshold the answer to the title question?

Let me pose another thesis: Learning programming seems alien and difficult for the average person who has no prior experience with coding. This is the main reason why even the slightest attempt is not made. But how is it that even students with lower "predispositions" graduate from IT programs and become specialists who easily find jobs and develop their careers? It all depends on:

• the amount of work that needs to be done when learning programming
• No concerns about the high entry threshold – this argument may have been valid 50 years ago, when programming was done using punch cards and floppy disks. Today, anyone who knows how to use a computer can learn programming to a greater or lesser extent.
• other factors that we will discuss in subsequent articles in the series “Why doesn’t Janek program?”

One article is not enough for complete conclusions

Throughout this article, we learned about the challenges faced by beginning programmers and whether special skills are required to learn programming quickly or at all. This is largely due to the fear of the unknown nature of programming, which is a common theme for the vast majority of the population (over 95%).

The IT market should focus on training and employing juniors, contrary to the current trend, according to which offers for juniors constitute only 10% (!!!) of all offers.

The problem is very broad, and its analysis is fascinating. One article is definitely not enough to delve into the topic, so I invite you to read the next in the series, which will appear on it-leaders.pl in the coming weeks.

To make sure you don't miss anything, I recommend subscribing to the newsletter; you'll receive an email notification about new publications that may interest you.

In today's world, many companies struggle with data analysis. Data is a key element in making business decisions (or at least it should be). To effectively present this data, we must first model it appropriately. In today's post, we will try to "promote" a solution that makes our team's daily work with data easier. I invite you to read the article and share your thoughts in the comments.

Data acquisition

For the purpose of this blog post, we will assume that data can flow into S3 (AWS's data storage service) from many different sources in many different formats. Let's look at the graphic below to get a general understanding of how this works from a data acquisition perspective.

Communication between S3 and Snowflake

This is a crucial part of the entire ecosystem. This element automates and relieves you of the responsibility for the smooth flow of data from S3 to Snowflake. Let's delve a little deeper into this element and the best way to configure it. Since Snowflake runs on AWS infrastructure, configuration and communication between the services is simplified. Snowflake supports this in a very clever way. Below, I will show a flow diagram that illustrates this nicely. This will explain the magic behind this setup, which I personally really like and use in both personal and commercial projects.

A brief comment on the diagram above: We start from the moment the file is physically placed in our file system. In S3, we have the option of sending messages to an SQS queue when a specific event occurs: file added, file deleted, file modified, etc. This allows us to create the foundations of a reactive system.

The next step is to transpose the messages in the SQS queue into notifications in SNS. Amazon SNS (Simple Notification Service) is an AWS cloud service that allows applications to send notifications to multiple recipients simultaneously. It works by publishing messages to "topics" and then delivering them to multiple subscribers. SNS can send notifications through various channels, such as: Lambda functions, SMS messages, emails, push notifications to mobile applications, HTTP/HTTPS requests, and SQS queues.

Snowpipe as the golden solution

Thanks to Snowpipes, we can define what we listen for and what we do with that information. I don't like talking without an example, so let's look at the code right away:

CREATE OR REPLACE PIPE pipe_data_source_data_provider_domain_table
AUTO_INGEST = TRUE
AWS_SNS_TOPIC = 'arn:aws:sns:us-east-1:2472837483:name_of_the_sns_service'
AS
COPY INTO data_source_data_provider_domain_table (
data,
filename,
file_row_number,
file_last_modified
)
FROM (
SELECT
$1,
METADATA$FILENAME,
METADATA$FILE_ROW_NUMBER,
METADATA$FILE_LAST_MODIFIED
FROM @your_bucket/provider/prod/
)
FILE_FORMAT = (type = 'PARQUET')
PATTERN = '*_domain_.*/.*table/.*';

The code is quite simple. It's a definition of a PIPE, which has several key elements.

• Name - the name of the Snowpipe, which should define, by convention, where the data is coming from and where it is going.
• SNS Topic - the address of the topic we are listening to - important: we must have the necessary permissions granted to the Snowflake instance - this is done in the role configuration in SNS. I won't show this in this post as it's a standard procedure and many examples can be found online; the Snowflake documentation also describes it well.
• The COPY statement is part of the definition that specifies what we are copying, in what format, and from where; it also has its own sub-elements:
  • INTO - which table the data is inserted into
  • FROM - which path should we listen to (SNS message filtering) - try to narrow down the FROM path as much as possible to save on S3 scanning costs with Snowpipe.
  • FILE FORMAT - what type of files are we looking for during the monitoring process?
  • PATTERN - the file path pattern we expect.

All these elements form a living entity, whose existence we can verify and whose history we can also examine through queries:

DESCRIBE PIPE XXX;

and

SELECT * FROM TABLE(INFORMATION_SCHEMA.PIPE_USAGE_HISTORY( PIPE_NAME => 'MY_PIPE' ));

There are many ways to monitor the operation and status of Snowpipes, but we will dedicate a separate post to that. I think the concept is clear, and we can move on.

Raw in the table!

The result of the above actions is the creation of rows in the target table, which we call RAW.name_of_the_table. This will be the lowest layer in our Snowflake instance. It will serve as the foundation from which our tables at the DBT level (or other data analysis tool) will read data.

When a row is inserted into the RAW table, we can trigger GitHub Actions, either according to a schedule or via a trigger, which then performs the transformation step in our ELT process. The diagram below illustrates how to model the data at a high level:

A quick explanation: We don't necessarily have to use the methodology I presented: stg->int->mart. It's a matter of convention, and there are many solutions, such as medallion or bronze->silver->gold. You can choose from many options. We won't go into that level of detail today, but we've shown a simple example of how this data can be modeled.

The data is modeled

Once the data is ready to be read, we can easily proceed to reading it at a higher level. In our solution, we use Power BI, but you can use other tools for reporting, such as: Tableau, Looker, Qlik Sense, Metabase, Apache Superset, Sisense, Domo. There are many such tools on the market today. It all depends on the needs and capabilities of your organization.

For better security, access should be tunneled. Ideally, this should be configured in such a way that there is an intermediary between the Power BI instance and Snowflake that controls data traffic between the platforms. This is important and can be solved in many ways. To implement IP whitelisting, for example, you can configure an API Gateway that will act as our guardian.

Of course, this slightly complicates the process of creating reports, because the team needs to be prepared for this, and their local computers must be configured to connect via VPN, and access must be managed through login/password (which expire) or SSO. This always creates maintenance challenges, but in return we have a very secure and airtight system. I will describe more details in another article. Today, we are discussing this topic at a very high level, and I don't want to write a whole book on security here. Besides, it's not entirely my area of ​​expertise, so I need to educate myself further.

Finally, the reports

At the end of this path, we always have a layer that presents the data. This is the most enjoyable part for the business, because from their perspective, our system is Power BI. They don't need to, and SHOULDN'T, be aware of the technical details. It's our problem and responsibility as a technical team to hide these implementation details from them.

For businesses, we can create systems of reports, analyses, and applications that will help them with their daily operational activities and decision-making. Our goal is not to create a technical monstrosity, but to provide value to the business. If the stakeholders are using our solutions, we should be satisfied. If not, then we have a long road ahead of us to solve this problem. I'll write more about this sometime, because it's a vast topic.

Summary

If you've made it to the end, that's great! That's all for today. I hope the above diagram has clarified the goal and the means we intend to use. It should also explain the specific problems we are solving and why this solution is very attractive and doesn't require significant investment. In this project, three of us created a data platform consisting of over 600 tables and over 50 reports. It's amazing that we only needed a few months to do this. There was a tremendous amount of work, but the satisfaction from the completed job was immense. I encourage you to familiarize yourself with the details and look forward to further articles related to the individual elements of the above solution. This article is just an introduction. Stay tuned for more!

The end of the year is often a time for summaries and conclusions. Since various companies are now publishing reports on the IT market situation in 2025, I decided to take a look at one of these reports. As I am currently looking for new challenges and trying to find my place in the market, I considered this to be valuable content, both for publication and for my own reading. I invite you to read it.

Data source

As our source, we will use the report from the largest Polish job board for IT positions in Poland.

Justjoin.it currently publishes 15,110 job offers (January 14, 2026). This makes them not only a Polish but also a European leader in terms of the volume of job postings. Based on this, I assume that the results of the report they publish are based on a sufficiently large sample and represent a reliable, averaged picture of the job market as of today.

You can find the report on their website at the following address:
https://justjoin.it/salary-report/

The report is divided into several sections: Job offer statistics, salaries by category, working conditions in the tech industry, and salary statistics. I reviewed each section in turn and will share my thoughts on them with you.

Job offer statistics

The number of job postings broken down by month is quite revealing. There is a clear difference between the months and a certain seasonality is evident.

Finding a job is definitely most difficult during the summer and holiday season. Firstly, because there are fewer job openings, and secondly, because recruiters and teams in general are less active.

In terms of technologies, the clear leaders are: Data, JS, and Java.

This doesn't surprise me at all. These technologies and categories have been the most sought-after for years. The data shows a clear upward trend. This is largely due to the development of LLMs (Large Language Models). Companies need to process clean, structured data and want to analyze it with the help of AI. That's why the number of job openings for Data Engineers and Data Analysts continues to grow.

I'm still a bit surprised by the large number of JavaScript job postings. LLMs code the frontend layer quite efficiently, perhaps thanks to Node.js, whose ecosystem has developed significantly recently. From my perspective, Claude Code or Cursor can write JavaScript code at a much better level than I, as a native backend developer, can manage using examples from the internet and documentation. We need to ask the frontend developers how they manage to avoid being made redundant and how they demonstrate their value to the company. Perhaps there are certain aspects that could be mapped to other areas of software development!

Nobody needs Juniors

That's sad and difficult for people who have hope for a better life thanks to working in IT. I once wrote an article about entering the market and how the entry barrier to IT is getting higher and higher. I see that this hasn't changed at all, as the number of job offers for beginners (Juniors) remains close to 5%.

My perspective on this issue is quite controversial. From an employer's point of view, I think I would hire more junior developers today. Thanks to AI, the learning process is much faster now. If we want to invest in human resources, hiring several juniors (e.g., 3) and one senior is more cost-effective in the long run than hiring two seniors. Although the financial cost might be similar, a senior developer might leave soon, while we have a better chance of retaining a junior developer for a longer period. Especially as the market is slowly transforming into an employer's market, there's less risk of the junior employee quickly leaving. I just wonder when employers will understand this. The market seeks immediate returns, which is provided by hiring mid-level and senior developers – they don't need training. However, in my opinion, this is a mistake.

Remote work

Many companies are now offering hybrid work instead of fully remote work, with the option or requirement to meet team members face-to-face at least once a week. As a remote work enthusiast and a bit of a homebody, I definitely don't like this change! But seriously, hybrid work is, in my opinion, the golden mean. Especially since we schedule meetings at the office on a specific day. Many problems can be solved better in a specific environment. In my opinion, this trend will continue in the coming years.

A chart showing the ratio of remote, hybrid, and in-office work. Is a return to the office becoming visible?

Types of contracts

The B2B contract market is quite significant. This is due to substantial tax breaks for sole proprietors in Poland. The effective tax rate decreases from approximately 60% for employees on standard employment contracts (the highest tax bracket already affects mid-level earners) to around 25% for self-employed individuals. This is a considerable relief for household budgets.

Companies, in turn, benefit from this by having an easier way to manage their workforce and are not burdened as much by regulations stemming from labor law, employee rights, collective bargaining agreements, etc.

Salaries

You can find the full range of technologies and specializations here: https://justjoin.it/salary-report/category-statistics. I will only present the most interesting aspects and my opinion.

BOTTOM 3 LOSERS (decrease or smallest increase):

1. Support - -4.93% (UoP)
   • The biggest decline in the industry.
   • Average: 11,250 PLN (employment contract), previously 11,833 PLN
   • The lowest salaries in IT
2. Net (.NET) - -1.61% (B2B)
   • Decline in B2B contracts
   • Average: 17,140 PLN (B2B), previously 17,420 PLN
3. C - -1.91% (B2B)
   • A slight decrease
   • Average: 17,530 PLN (B2B), previously 17,871 PLN

TOP 3 WINNERS (highest growth):

1. Scala - +58.83% (employment contract)
   • The biggest growth in the entire IT industry.
   • Average: 22,025 PLN (employment contract), previously 13,867 PLN
2. Go (Golang) - +35.67% (employment contract)
   • The second largest increase
   • Average: 22,250 PLN (employment contract), previously 16,400 PLN
   • The highest average salary in the industry!
3. ERP - +14.88% (B2B)
   • The biggest increase was in B2B contracts.
   • Average: 20,927 PLN (B2B), previously 18,217 PLN

Losers

As we can see above, .NET developers working under B2B contracts are definitely the least satisfied. Those on traditional employment contracts saw a small increase of 3.13%, which is also not very encouraging. Could the .NET sector already have a fully saturated market? The Support sector recorded the same, or even worse, results, making it the lowest-paid sector in IT. Additionally, due to automation and the implementation of AI in many company processes, we are seeing both a decrease in the number of job offers and lower salaries (due to the low entry barrier to IT Support compared to other sectors). Nevertheless, the salaries there are still quite decent.

Support's market share of job postings fell from 3.1% to approximately 2.4%. A strong correlation is evident here.

Winners

Among the languages ​​experiencing growth, Scala and Go stand out, followed to a lesser extent by ERP. The increase in salaries for these "newer" and presumably less mature programming languages ​​is astonishing. The market hasn't yet had time to properly value the skills of these programmers, or perhaps the demand is so high that it distorts and strongly influences the pricing of services (urgency, the need for rapid implementation).

It should be added that Scala accounts for only 0.4% of all job postings, so the volume may also slightly influence the dynamics of wage growth.

Where can you earn the most money?

Regarding the highest salaries recorded on justjoin.it, the case of at least one offer is particularly interesting: 99,490 PLN - WOW, earning 100k a month - that would be something! I probably don't need to mention that the demand for neural network models and AI specialists is constantly growing, and such incredibly high salaries are the best proof of this, in my opinion.

Generally, we earn the best average salaries in the following areas:

TOP 3 - Highest average earnings (on B2B contracts):

Security - PLN 20,465

Scala - 21,487 PLN

ERP - 20,927 PLN

We see that 2 out of the 3 highest-paying categories are the same ones that are showing an upward trend year-on-year. I'm a little surprised by the absence of AI/ML-related specializations in this ranking. Perhaps it's still too early. I'm very curious to see how average salaries in the AI ​​sector will change in what I consider to be the crucial year of 2026.

Summary

2026 will certainly be a year of change. The AI ​​revolution is slowly making its presence felt in the job market. Coding tools are becoming more mature and reliable. From my perspective (the PHP bubble), the market is becoming more professional; interviews require more than before, and there are many more applicants for each position. The quality of these candidates is another matter, but unfortunately, that's beyond my control since I don't personally hire anyone (and don't intend to in the near future).

Outside of my immediate circle, it's difficult to assess the situation definitively. The market is certainly stabilizing and the dynamics and growth are no longer as strong as they were during the 2015-2022 period. In terms of hard data, the market has been slowly stabilizing for the past three years. For more information, I encourage you to read the full report. I'm sharing the link again: https://justjoin.it/salary-report/.

I'm also curious about your opinion on this report: does it reflect what you see in your circles? And to answer the question in the title: No, the Eldorado is not over yet, but I have a feeling that technological changes may give it more momentum. Then it could really go in two directions: either the market will need more hands to meet the demand for software, or part of the market will be absorbed by AI tools. Everything is in the hands of the owners of technologies related to LLMs and the owners of capital – after all, they are the ones who decide every day whether Damian from Gdańsk or Janek from Gliwice will have something to do.

I hope that new technological capabilities will allow us to create faster and better. However, it's possible that customers (individual consumers) will be able to solve many problems without the need for a programmer. In that case, it's best to have a plan B. And do I have a plan B? Of course I do. I see my opportunities in the areas of Data and Architecture. That's probably where the profit margin disappearing from the programming market will go, if such a phenomenon occurs.

On the other hand, I recommend that everyone learn about AI tools and try to keep up with the market. The ability to learn and an open mind will always give us an advantage in the market. If only the strongest survive in the jungle, then that strength will certainly be the ability to work with the help of AI in the coming years.

I wish all readers good luck on this path and professional fulfillment, regardless of the technology or sector. After all, at the end of the day, it's just a job, and it's important to first and foremost earn a living from it, and secondly, to have at least some fun doing what we do. The only certainty is change, and that's the thought I'd like to leave you with.

Thanks!

Today we'll touch on a topic that's been on my to-do list for a while. I've recently watched a lot of videos on domain modeling in DDD. Unfortunately, many of them discuss trivial or well-known issues. Below, I'll describe a problem you've certainly never encountered before (and neither have I). We'll try to break it down, first at a high level and then by constructing a deep domain model. Join me!

Problem description (brief)

• The system settles shared expenses incurred within a single location (apartment, office, property).
• Settlements are calculated in defined settlement periods, typically monthly.
• Each period may have a variable number of participants.
• A participant may join or leave during a settlement period.
• Cost responsibility is based on actual participation time, unless a cost defines a different rule.
• Each cost has a monetary amount, date, category, and an associated allocation rule.
• Costs may be recurring, consumption-based, or one-off.
• A cost may apply to:
  • all participants,
  • a selected subset,
  • participants with explicit exclusions or limits.
• The system supports multiple cost allocation rules, including:
  • equal split,
  • proportional split using predefined weights,
  • time-based (prorated) split,
  • consumption-based split,
  • combinations of multiple rules.
• Allocation rules may change over time.
• Cost allocation may produce rounding differences, which must be handled according to a defined policy.
• Costs may be added after a settlement period has ended.
• Cost corrections affect future settlements according to predefined correction rules.
• A settlement period may be closed, after which results are considered final.
• For each participant, the system calculates either:
  • an amount owed, or
  • a credit balance.
• Settlement results must be transparent and traceable, allowing each participant’s amount to be explained down to individual cost items.

Defining model components

To begin designing the model, let's draw its components. The model will consist primarily of Settlements. In our system, this is synonymous with the word "obligations." We also have resource users. In our contextual language, this would be "participant."

This is a basic understanding of components. Notice that there are no relationships or fields yet, as this isn't an ERD (Entity Relationship Diagram). Let's visualize the problem. Let's illustrate it from a different perspective—a temporal perspective:

This chart better illustrates the flow over time. Our timeframe is "Period X." During this period, participants (A, B, C) incur costs. We can tentatively assume that these are people renting space in the open-plan space. I think this is a pretty good use case that will help us visualize the problem.

Our software is therefore designed to manage the rental of a given resource between participants (lessors). As we can see, the beginning and end of the commitment for each participant are determined individually (there are periods when someone incurs no costs, but there are periods when the rental is continuous. Let's imagine that one person comes to the office for 20 days out of 20 working days, another comes in on a break, etc.

Event storming - one of the techniques for learning about the problem

Let's try to break it down using sticky notes. Alberto Brandolini, the creator of ES, came up with a way to explore problems during software design. You can find more details here. I'm no expert in this technique, but I know the basic concepts and will try to prepare an ES board at the Problem Exploration (Big Picture) level.

This is what a list of domain events would look like. We can:

• open the period
• add cost
• participant can join
• the participant may leave
• the period may end
• the period can be settled (closed)
• liabilities can be converted
• an invoice can be sent to participants

Types of cost allocation

The event timeline helps us identify the most important events during the billing period. This gives us an overview of what happens during the billing period. Now let's look at how to solve allocation rules, one of the key elements of billing:

• equal split - costs are divided equally between participants

• proportional split using predefined weights - each participant has its own weight assigned to a given cost type

• time-based (prorated) split - division between participants depending on the time each of them used a given resource

• consumption-based split - division based on the proportional consumption of the resource by participants (regardless of the time of use)

• combinations of multiple rules - the most difficult - although from a high-level level it doesn't matter that much

When implementing the model, we'll need to implement an appropriate solution to this problem, but this isn't a problem we'll address in this article; implementation will be covered in a separate post. Let's just get this out of the way for now.

Cost structure

The cost should consist of several components:

• Monetary amount - value written as number + currency

• Date - the date on which the cost was charged

• Category - expense category (electricity bill, desk use, microwave use, etc.)

• Allocation rule - known above - includes the method of dividing the cost between participants

I think we've created our first Domain Entity this way. The next one will definitely be the Participant. A Participant will be a simple entity composed of a Name, Email Address, and ID. For this module, we don't need anything more. Each participant will also have their own account, where their billing history will be saved. Let's call this the Participant Account.

The next entity will likely be the Settlement Period. This will represent a time period (specifically, settlement months). Its properties include the start and end of the period, as well as its status (open/closed).

After this basic recognition, we can freely draw the supposed shape of the entity.

I've intentionally marked the Invoice entity in a different color. It's not included in the requirements, but it's a natural consequence of the application's operation. Let's now try to describe the entity's components and the relationships between them in more detail. This sketch is intended only to outline and sequence the subsequent building blocks. Even at this stage, it's clear that the Invoice entity definitely doesn't fit in with the rest because:

1. It refers to events after the closing of the billing period.
2. It can be issued independently of other events; it is a consequence but not part of the process.

However, do not discard the Invoice until we are sure it is a different Bounded Context.

Pseudo ERD

Below you'll find the next stage of design: designing entities and their relationships, which we can tentatively call "Pseudo ERD." Entity Relationship Diagram (ERD) – this concept is associated with databases, but note that so far we haven't mentioned the persistence layer. I haven't mentioned any database engine, framework, or ORM, as that's not the modeling cue. Technical decisions will come later. So let's look at the ERD:

Here we see a more detailed view. We also see that all entities are dependent on the Settlement Period to some extent. Let's now look at the central entity, the Shared Expense. This is a central location in the schema because it contains:

• cost types
• cost allocation types between participants
• the divisible amount (SharedAmount)
• SettlementPeriodId - a reference to our AggregateRoot.

Building blocks from DDD

I'm starting to use concepts strictly related to DDD, so I think it's worth briefly describing the basic building blocks in tactical DDD (yes, we're already on the borderline of tactics - the only strategic decision we have is whether to include Invoice in our context or whether Invoicing will be another one).

Entity

An object with an identity that is more important than its current state. It may change attributes over time, but it remains the "same" entity.

Example of meaning: order, user, subscription.

Value Object

An object without identity, defined solely by its values. It is immutable and compared by value equality.

Example of meaning: amount of money, date range, email address.

Aggregate

A consistent transaction boundary grouping entities and value objects. Protects business invariants.

Aggregate Root

The only gateway to the interior of the unit. Only through it can the unit's status be modified.

From the outside, you never operate on internal entities directly.

Repository

Abstraction for accessing aggregates.

It mimics an in-memory collection, not a DAO or Active Record.

It retrieves and stores Aggregate Roots, not random entities.

Domain Service

Domain logic that:

• does not naturally fit into a single entity
• operates on multiple aggregates
• does not maintain state

It's still a domain, not infrastructure.

Domain Event

An event describing something that has already happened in a domain. It is used for communication and response to state changes.

It is not a command or a request.

Factory

It's responsible for creating complex aggregates. It hides complex initialization logic and monitors invariants from the start.

Specification/Policy

It encapsulates a business rule or condition. It can be used for validation, filtering, and decision-making.

A clear way to write complex conditional logic.

Module (Package)

Logical grouping of domain elements.
Helps maintain model consistency and readability.

Not to be confused with bounded context—that's a level below.

The model is incomplete

I feel that the direct relationship between SettlementPeriod, SharedExpense, and Participant could be encapsulated in a mini-aggregate called ParticipantExpense, which would act as a bridge between a single cost participant and the entire settlement period. Furthermore, since we don't have any reference to the shared resource, it would be worthwhile to group this into ParticipantExpense. The next iteration of our model would look like this:

A lot has changed. First, the (C) notation appeared, which stands for collections of objects. From a relational perspective, one entity contains a collection of other entities. I also added (VO) – Value Object. This is one of the DDD building blocks described above.

Moving up, I also marked the scope of our aggregate: a coherence unit that aggregates multiple entities and ensures coherence during business operations. I also marked the Aggregate Root, which in our case is SettlementPeriod. The aggregate can only be accessed from the outside by accessing the Aggregate Root. This is very useful for preventing logic from spilling over, and it helps ensure encapsulation. There was something about this in college back in the day, right? :) I also removed Participant and Facility from the aggregate.

Our model should only contain references to them, but it doesn't operate strictly on participants or the Facility. A different BC or even a different module will likely be dedicated to user management, and a separate aggregate will certainly ensure its coherence. The same applies to Facility – we only want the essential elements in our aggregate; a reference to FacilityID is sufficient; we shouldn't care where the Facility is located or what it's called. From the perspective of our model, this isn't important.

I went a step further and also added a framework for Bounded Context, which I called Settlements. I decided not to include Invoice in it – after analysis and a short modeling session, I already know it will be a separate BC. Perhaps even a separate module. Who knows?

Everything is fine, but how do we code it now?

As I've noticed, our model is now complete, or at least it seems so. I won't show the implementation in this article. I'll devote the entire second part to that, but as a sort of introduction, I'll offer a UML class diagram. So far, we've focused on nouns—entities. Now, to make it more functional, we'll add verbs to UML, meaning processes and actions—class behaviors.

Note also that we're missing the so-called input state. Another BC will be responsible for its formulation: Facility Management, where you can add Resources to Facilities and Participants to Facilities. This will likely be a standard CRUD with adding, editing, and deleting. We can imagine it as an administration panel for managers where they can enter all this data. Our module will only respond to DomainEvents such as:

• SharedExpenseCorrected
• ParticipantJoined
• ParticipantLeft
• SettlementPeriodStarted
• SettlementPeriodClosed

In our context, we assume that such a connection already exists and we only read it (Read Model) to construct our aggregate and manage its behavior and consistency.

The diagram above is just a sketch; once I start coding, a lot of it will probably change. Expect the second part of this post soon. In the meantime, I'll leave you with these conclusions and encourage you to share your thoughts in the comments.

The problem initially seemed quite trivial, but the deeper we go, the more complicated it becomes. In reality, we're still a long way from writing the code. We have a concept, we have diagrams, but the code has to work. Maybe creating an application that solves this problem would be a good idea. I don't know, I'll see how it develops in the coming days. For now, I think we've figured out the model itself quite well. But as is often the case with programming, the devil is in the details.

Today we'll talk about metrics in software development. I'll start by showing a cool graphic I found on the LeaderShip Failed Successfully podcast channel. This graphic will serve as the basis for discussing each metric and assessing who needs them and why.

Let me start with the video that prompted me to discuss this topic:

I was particularly interested in the report the guys showed in the video:

Metric groups

We see four groups of the most popular metrics. Before delving deeper into the topic, I'd heard a lot about DORA. I was also asked about it during a recent job interview. Let's start with DORA.

DORA - DevOps Research and Assessment

It consists of 4 metrics (according to the video's authors, a 5th metric has been added - I've verified this and will include it in the description below). The metrics are intended to measure the speed of delivery and the security of the change.

Deployment Frequency (DF)
How often does the team implement changes into production?
→ measures the team's ability to quickly deliver value.

Lead Time for Changes - Cycle Time (LT)
Time from commit/merge to launching a change in production
→ measures the efficiency of the delivery process

Change Failure Rate (CFR)
Percentage of deployments causing incidents, rollbacks, or hotfixes
→ measures the quality and stability of changes

Mean Time to Recovery (MTTR)
Mean Time to Restore
→ measures the resilience of the system and team

Reliability
measures how well the system actually meets user expectations in terms of:

• SLO/SLA compliance.
• availability,
• stability,
• operational correctness
  

Let's look at the table

If we look at the graphic, we'll notice that the best (elite) teams are able to deploy code (Deployment Frequency )on average every day. This means that at least one version of the code (new feature, functionality) is released into production every day. The same applies to the Lead Time for Changes (Cycle Time). From the moment a change is committed, it should take approximately one day for that change to be deployed to production.

Change Failure Rate - this is a very important metric and according to the report, the number of problematic implementations should be lower than 1% - what's more, there are teams that deliver such results.

Another metric from the report is MTTR – the ability to respond to bugs/incidents in production. Recovery time is crucial – we don't want our customers/users to be stuck with a broken application. The best teams can resolve these issues in less than 6 hours.

Dora - good for starters but too general for programmers

My conclusion for delving into the topic is simple - DORA helps the entire team, but especially the DevOps team, maintain the smoothness and stability of the system at a good level.

Another group of metrics, DevEx, comes to the rescue:

We have several elements here:

• Coding Time (hours) - Coding time is what we like best - top teams need on average less than an hour to code a solution.
• Pickup Time (hours/minutes) - Pickup time - The time it takes a programmer to start a task and change its status to in-progress. The best teams need less than 75 minutes to do this.
• Approve Time (hours) - the amount of time needed to receive approval for deployment to production; <10 hours is already an excellent result according to the table above.
• Merge Time (hours) - the number of hours between completing a CR and merging changes to the main branch. Elite teams can do this in 2 hours (on average).
• Review Time (hours) - how long a code review takes. The best teams can do it in less than 3 hours.
• Deploy Time (hours) - how many hours it takes to deploy after merging to the main branch. Elite teams can do it in less than 6 hours. This reflects Lead Time for Changes from DORA.
• Merge Frequency (per dev/week) - how many PRs per developer are merged per week. The best teams can maintain this metric at >2.25 PRs per week.
• PR Maturity - a very important metric that indicates the percentage of PRs that are immediately useful for Implementations without post-code review fixes. Top teams maintain this at >91%

Other metrics. Do we need them?

I will answer this question briefly: NO. In my opinion, DORA + DevEX is more than enough to observe and draw conclusions. However, if you're interested in learning about Predictability and PM Hygiene, I encourage you to watch the video or at least take a look at the graphic I've shared above.

Summary

In conclusion, I'd like to remind you that metrics aren't meant to put pressure on us as developers or DevOps teams, but rather to help us continuously improve our performance and identify bottlenecks in the software development process. If you want to implement metrics gradually, I suggest starting with DORA, then adding (perhaps not even all) the DevEx elements. This should be enough to test the metrics in your environment and select the ones you can influence.

I hope this article has been encouraging. After all, it's all about becoming better professionals. And what if you want to be better at something you don't measure? Metrics are just measurable tools for continuous process improvement, and I'd like to leave you with that thought today. I'd appreciate any comments and sharing experiences. Thanks!

Have you ever wondered how companies manage to turn vast oceans of raw data into actionable insights? Data engineering is the hidden engine that powers this transformation. From enabling real-time analytics to supporting groundbreaking machine learning models, data engineering shapes the digital landscape.

This field ensures that businesses can rely on clean, accessible, and secure data to thrive in today’s competitive world. Let’s explore how this fascinating domain forms the backbone of modern technology.

What is Data Engineering?

• Managing large datasets: It facilitates the processing of massive amounts of information quickly and efficiently.
• Integrating data: Combines data from various sources such as databases, APIs, or files.
• Preparing data for analysis: Cleans and transforms data into a suitable format for analytical processes.
• Automating processes: Develops pipelines – automated data processing workflows that minimize human error and speed up data processing.
• Ensuring data security: Protects data from loss and unauthorized access while complying with legal regulations.

The Role of a Data Engineer in an IT Team

A data engineer is a crucial member of teams managing information. They collaborate with various departments, including data scientists, business analysts, and developers. Their main responsibilities include:

• Designing and building data infrastructure: Creating data warehouses, databases, and processing systems.
• Implementing data pipelines: Developing ETL (Extract, Transform, Load) or ELT processes for efficient data processing.
• Monitoring data quality: Deploying tools for validation and cleaning of data.
• Ensuring scalability: Adapting systems to handle growing amounts of data.
• Supporting analytical teams: Providing consistent and ready-to-use data in real-time.
  

Skills Required for a Data Engineer

A Data Engineer’s job demands a wide range of skills, including:

• Database expertise: Knowledge of both relational (SQL) and non-relational (NoSQL, e.g., MongoDB) databases.
• Programming skills: Proficiency in languages like Python, Scala, Java, or R.
• Data processing tools: Familiarity with Hadoop, Apache Spark, Kafka.
• Analytical abilities: Understanding data modeling and statistics.
• Cloud knowledge: Experience with AWS, Google Cloud, or Azure for data processing support.
  

Why is Data Engineering crucial nowadays?

Modern businesses base their decisions on data analysis. Without data engineering, this would be impossible as data would remain scattered, inconsistent, or inaccessible. Thanks to the work of data engineers, organizations can:

• Make fact-based decisions instead of relying on intuition.
• Optimize business processes.
• Develop advanced predictive models.
• Ensure compliance with data protection regulations.

Data engineering lies at the heart of modern information systems and is key to success in the digital economy.

Why did I switch to Data Engineering?

In fact I pivoted from clean Software Engineering to Data Engineering mixed with SE. I will share more insight why I did make it 2 years ago.

After 7 years of working as a Junior, then Mid, and finally Senior Software Engineer, I suddenly found myself at a crossroads. My entire team was dissolved — we had been building an e-commerce logistics tool — and I had to choose between two options:

a) Leave the company just a few months after joining (right after I had finally ramped up) and start looking for another job in a similar role.

b) Stay and help build a brand-new team whose goal would be to create a data platform for most departments in the company — a platform that would support their day-to-day decision-making.

Since I’ve been working with technology for a long time, I knew one thing: tools like Databricks, Snowflake, DBT, or PySpark are just tools. Learning them is basically a normal day at the office for someone with my background. What I didn’t know was whether working with data would actually be interesting.

A bit uncertain, I chose option b. I figured I’d give myself a chance to explore new technologies — maybe it would help me grow. Even though I had only heard about those tools or barely touched them before, I decided to learn them on the job. No courses, no trainings — I was thrown straight into the deep end, and honestly, I loved it. I enjoy working under pressure; that’s when I feel the most productive.

After around three months, I knew I wanted to keep going in this direction. And more tools showed up on my path — PowerBI, MCP (Model Context Protocol), and others. Working with data turned out to be a perfect match for me. I love charts, correlations, tables, forecasting, analysis, and telling stories with data. My role expanded from Data Engineering into the entire spectrum — from Software Engineering to BI Specialist.

I built dozens of dashboards that are still used in the company today and bring real value. Presentation skills could’ve been better — that’s something I know I need to improve. In the tech world you can build incredible things, but if you can’t present them well, your work might never get the attention it deserves.

My coding background also came in handy. Data often had to be collected from somewhere, and quick integrations with external APIs allowed us to expand our data sources at an impressive pace.

This is my story in a nutshell. I don’t want to bore you with all the details, but I do want to share a message: career pivots — especially in IT — will be happening all the time now. Technology has accelerated dramatically. Coding alone is no longer a unique skill. Honestly, even my uncle from a family party could probably build a mobile app now using LLMs (okay, maybe I’m exaggerating a bit).

Developers who never made the jump toward Solution or Software Architecture are facing tough times. Looking back, I think my decision to pivot was risky, but absolutely worth it. Two years ago we didn’t know how much LLMs would change the job market. Today we do — and pure programming isn’t enough anymore. Data engineering, on the other hand, does minimize some of that risk.

In the future, I plan to grow further in Project Management (I already have some experience) and in Solution Architecture. My goal is to become a one-man army — someone who can lead a project with a few AI agents or junior developers. I believe this kind of profile will be the most valuable over the next decade. In short:

• Programming
• Testing
• Data engineering & analysis
• IT Project Management
• Solution & Software Architecture (mostly cloud-based)

If you look at my CV, it’s heading exactly in that direction. And even though I’m once again on the job market, I’m not worried. I know where I’m going, and I know where I came from. And I got here only thanks to hard work and persistence.

The post is getting a bit too personal, so I’ll wrap it up here.

My message to the world? Don’t be afraid to take risks. Sometimes you need to take a step back to move forward — and that step might be exactly what you needed.

Good luck!

The number of programmers in the world is still growing, but unfortunately, few offer high quality. What prevents a developer from delivering good quality services? It is usually tied to mistakes. Below you will find a condensed list addressing this issue.

1. Thinking You Are Irreplaceable

Many average programmers believe they are amazing developers. I thought the same. After a few years, I realized that there are plenty of people who are truly amazing, better than me, and I was simply too confident.

The moment I told myself that I had many areas to improve and I wasn’t as incredible as I assumed, my outlook changed. I started learning new things and improving day by day. The desire to learn and the belief that you still have much to improve will take you far. This applies not only to programming but also to any other life skill.

2. Working Without Estimation and Compensating with Overtime

Many programmers write code without considering the time needed to complete the work. They pour into overtime, take family time on weekends, reduce sleep, working late into the night, and so on. This happens because you don't set a deadline for completing a task.

For example, if you are building a module, you must decide, “I will finish this in 3 hours, with 1 hour of extra buffer.” If you don’t finish within 4 hours, you move on to something else. When you miss the deadline, you stretch it endlessly. Since you know you will cover it by working overtime, you won’t try to improve your task estimation skills.

Set a specific time to close your laptop and only open it the next day. Trust me, it will force you to prioritize and improve, making you a better programmer.

3. Hesitating to Participate in Hackathons and Coding Challenges

Programmers are often afraid to try their hand at coding challenges on websites like TopCoder, Coderbyte. The reason is usually the fear of feeling bad about exposing their weaknesses.

Don't be a coward! You will only improve your skills if you are willing to see where you stand, repeatedly fail, and face setbacks. You lose nothing, and no one will know if you fail. While you shy away from such tasks, other programmers are improving, leaving you behind.

At the same time, be cautious about some coding challenges. Some have ridiculously short time limits, which can lead to bad coding habits. They may also present weird problems that don't help improve your skills. Don’t criticize yourself if you struggle with these challenges. Over time, you will be able to distinguish between good and bad coding tasks.

4. Not Using Optimal Environment, Tools, and Devices

Many programmers believe they can code lying in bed with a laptop on their chest. Sure, you can, but your skills will match your laziness.

Moreover, whoever told you that working on a laptop touchpad/keyboard is as fast as working with a mouse/keyboard has not worked with a mouse/keyboard long enough. The combination of a mouse and keyboard is faster, period.

Having worked on various laptops, desktop setups, and all kinds of peripherals, I can guarantee that coding while sitting at a desk, using a larger screen with a mouse and keyboard, significantly speeds up programming.

5. Not Trying to Code Faster

Programming is also about speed. Although people tell you that writing good code is important, don’t ignore speed. In today’s world, time is money. You must challenge yourself to code faster, type faster, and use your editor’s shortcuts. You need to make a conscious effort to increase speed.

Note: I’m not saying you should increase speed at the cost of code quality. Writing good and efficient code is more important than coding faster. Your primary goal should be writing code that produces the correct results. But in the process, look for opportunities to get things done faster. In most cases, you can boost speed without losing quality. But you will never achieve maximum speed with the best quality point without challenging yourself. Increasing speed doesn’t just mean typing faster. You can improve your programming speed by challenging yourself to solve coding tasks faster than usual.

6. Blindly Copying Code

Without a doubt, we all use code from the internet, from sites like StackOverflow or the recently popular ChatGPT. In fact, not using code at all isn’t the smartest idea. But do you paste code blindly every time and see if it works? Well, if so, you’re missing out on a learning opportunity. It’s not enough to just understand if the code you pasted can be written better than suggested in the answer.

The reason you searched for code is that you either didn’t know how to do it or wanted to save time. Try to understand the code you used at least at a high level. You don’t have to understand the code line by line, but at least grasp the approach used.

7. Doing Things the Same Way Without Improving Skills

If you started with PHP, you can still build any functionality using what you learned in your first year. If you only write code you already know or have written before, you will stagnate.

Move forward with new technologies and challenge yourself. Try a different programming language, new frameworks, learn new algorithms, and try best practices. Constantly improve yourself.

Think about it this way – 10 years later, if you’re doing the same thing, why should anyone pay you more than a programmer with 1-2 years of experience?

Summary

The above article is based on my experiences and the experiences of people with a similar mindset. I would greatly appreciate it if you could expand this list with your suggestions in the comments

If you manage to eliminate even one point, you’ve already succeeded. I wish you good luck in creating a better IT world because that’s what it’s all about.

Programming is the skill of creating computer software using specialized languages and tools. It can be applied to develop games, applications, websites, operating systems, and much more. Programming is fascinating and useful because it allows you to solve problems, express creativity, and build valuable products. If you are considering becoming a programmer, you might be wondering – where do you begin?

1. Choose Your Path

Before diving in, it's important to decide what area of programming interests you the most. Some common fields include:

• Web Development – Building websites and web applications.
• App Development – Creating mobile or desktop applications.
• Game Development – Designing and programming video games.
• Data Science – Analyzing data to extract meaningful insights.
• AI and Machine Learning – Developing intelligent systems that learn from data.

Understanding which field excites you can guide your learning journey.

2. Select a Programming Language

There are many programming languages, each suited to different tasks. Here are a few popular ones for beginners:

• Python – Great for beginners due to its simplicity and versatility. Used in web development, data science, and automation.
• JavaScript – Essential for web development and adding interactivity to websites.
• Java – Commonly used for building mobile apps and large-scale applications.
• C# – Popular for game development and Windows applications.
• C++ – Ideal for systems programming and high-performance applications.

3. Learn the Basics

Start by learning fundamental concepts that apply to all programming languages:

• Variables and Data Types – Storing and managing information.
• Control Structures – Writing loops and conditional statements.
• Functions and Methods – Creating reusable blocks of code.
• Algorithms and Data Structures – Understanding how to efficiently process and store data.

There are plenty of free and paid resources, such as online tutorials, coding bootcamps, and university courses. Platforms like Codecademy, Udemy, and freeCodeCamp are excellent places to start.

4. Practice with Projects

The best way to learn programming is by doing. Start small by creating basic projects such as:

• A personal website
• A to-do list app
• A simple game
• Data analysis scripts

As you gain confidence, take on more complex projects. Contributing to open-source projects is also a great way to learn and collaborate with experienced developers.

5. Stay Consistent and Curious

Programming is a skill that improves with time and practice. Set aside regular time for learning and stay curious. Don’t be afraid to make mistakes – they are part of the learning process.

Conclusion

Starting programming may seem overwhelming at first, but by choosing a path, learning a language, and practicing regularly, you’ll gradually develop the skills needed to succeed. Whether you want to build your own applications or pursue a career in tech, programming opens endless possibilities.