You're not a software engineer, sorry, but that's okay

You're not a software engineer, sorry, but that's okay.

I know, it can be hard to hear. But I'm sure you have other qualities.

If you found this article by yourself, you may not be the target. On the other hand, if I sent it to you personally, you should probably read it and take a moment to think about it.

Also, this article is focused on web development and related fields. I won't talk about other areas of software engineering like embedded systems or data science.

Before going further, how do we get there and what are we discussing?

I'm facing a real challenge here. As code becomes more and more accessible, people tend to think that they can just jump in and start building complex systems without any knowledge, that software developers are just a financial hole without any real value. I'm just tired of explaining my job, again and again. I have the freedom to write my thoughts once and for all in a clear way, and share them with anyone who thinks they can do my job. So here we are.

In today's world, more and more people are writing code. The whole society is becoming digitalized. This means that there's never been a greater need to write software.

Some people saw an opportunity to make money. What about telling people that they can become rich easily, from a chair in an office, just by learning for 2 to 6 months by selling a training? Great idea! Bootcamps were born.

This was a scam.

Learning code is much harder and takes way more time than 2 to 6 months. Also, only good developers can make a lot of money. You won't become rich. And even worse, you won't have a job because the market has been saturated with inexperienced junior developers, hoping to find a well-paid job.

But the story doesn't end here.

This movement came before LLMs. With AI assistants like ChatGPT or Claude Code, and AI builders like Loveable, V0 or Bolt.new, coding has never been more accessible than it is today, and that's terrible.

Absolutely everyone can now write code. The exact sentence should be "Absolutely everyone can ask a LLM to generate code for them." The barrier to entry was already low with languages like Python. Now, with AI, barriers are gone.

Don't get me wrong. If this can create a vocation, or allow individuals to express themselves through code without having to deal with all the complexity, it's a good thing.

The truth is, writing code is the easiest part of the job. If you find it difficult, it's probably because you're on the early days of your journey. If you think you're a software engineer by having followed a bootcamp or by using AI tools, you should take a step back, and continue reading. I'm writing this article for you.

The real world, the adult world, is much more complex than a frontend todo list written with HTML and CSS.

Companies have specific business requirements. Most of the time, they find it difficult to express them clearly. People who have a need aren't from this domain; they don't understand what we're doing. That's ok, but as a software engineer, your role is to bridge the gap.

One of your challenges is to extract the need, to understand it, to challenge it, and build a clear and coherent vision from it. Then, you have to design an appropriate solution. This is part of the engineering job implied by the title "software engineer."

AI assistants and AI builders won't magically do that alone. Of course, they can help you, but they won't understand the whole business because there is a lot of implicit knowledge and context that only a human can grasp.

Now we all have the history in mind. Let's have a closer look at the "software engineer" title.

From the Wikipedia definition, software engineering is a branch of both computer science and engineering focused on designing, developing, testing, and maintaining software applications. It involves applying engineering principles and computer programming expertise to develop software systems that meet user needs. The terms programmer and coder overlap with software engineer, but they imply only the construction aspect of a typical software engineer workload.

I really love that definition because it says absolutely everything about the job.

Building software involves science, both theoretical and practical. It's not just about chance or intuition. It's about understanding, analyzing, and solving problems. Also, four tasks are highlighted: designing, developing, testing, and maintaining. When I said earlier that writing code is the easiest part of the job, it's because it's only one of the four tasks, despite being the most visible one. And compared to the other tasks, writing code is a no-brainer.

And don't forget that all of this must be done to solve a real user need. Otherwise, you're just writing code for the sake of writing code, which is useless. By using AI tools to write most of your code, and by only focusing on the code, there is a high probability that you're more of a programmer or a coder than a software engineer.

A while ago, I wrote about testing. You should read it to have a first appreciation of the topic, because it's not AI builders who will ensure the quality of your code and testing is truly difficult.

I won't go deeper into the designing and maintaining aspects, but if you're trying to sell me a NoSQL database in a microservices architecture, I hope you have a solid understanding of the trade-offs involved, and you're not just trying to follow a trend or reciting to me some buzzwords that you've heard on a merchant of complexity blog.

Making wrong assumptions and poor understanding of the ecosystem leads to poor design decisions. This creates what we call technical debt. And like every debt, you'll have to pay it back one day, and the more you accumulate, the harder it becomes to manage. By trying to build software without the required knowledge, you become a generator of technical debt. Nothing more.

In a personal context, that's not a problem. It's your sandbox, play with it. You can throw away your code or rewrite it. In a business context, the stakes are much higher. Poor design decisions can lead to project failures, wasted resources, and lost opportunities. It's crucial to take the time to make informed decisions.

If you're still reading, I hope convinced you how more complex the role of a software developer is. If that's not the case, let me show you something.

Modern applications are not simple from an external point of view and depending on the scale you're working, the complexity can quickly escalate. For this part, let's imagine a pretty standard application with manageable traffic. (i.e. not Facebook, Uber or Twitter scale)

Your application has a frontend. With this frontend, written using HTML, CSS, certainly with a framework like Tailwind CSS or Panda CSS, and JavaScript. For the JavaScript, you can use a library like Alpine, Unpoly, HTMX, Hotwire or Livewire if you're using Laravel. But you may decide to use a more robust framework like React, Vue.js, Angular, Svelte, etc. You may also prefer to use a meta-framework like Next, React Router, Nuxt, SvelteKit. But we're far from being done. The frontend provides a user interface to deliver a user experience to a user, a real person that has a real need. So you may need to consider accessibility, performance, responsiveness. This requires you to spend some time thinking about the user interface (UI) and the user experience (UX). Honestly, it's a lot of work so you may consider picking a component library, or building your own based on the design system of your company. If you're using Vue, you may choose Nuxt UI, PrimeVue, Quasar, Vuetify, Reka UI, Shadcn-vue, Native UI, Volt UI, Daisy UI, Flowbite Vue, Element Plus, Ant Design Vue, Ark UI or Vuestic UI. Maybe I should also mention that depending on the architecture, you may need a data fetching layer like TanStack Query, and if you're building a lot of tables, TanStack Tables. I'll spare you store management libraries and animation libraries, you could be overwhelmed.

That's just the frontend, and I haven't mentioned Vite. Yes, that's already a lot.

Now, imagine the backend, with all the different languages and frameworks available, the database systems with SQL, NoSQL, TimeSeries, Graph databases and each flavor for each, the queue systems like RabbitMQ, Kafka, or a simple database table, caching systems like Redis or Memcached, all the managed versions provided by the cloud providers, the different techniques used to test, build, and deploy your application, using a CI/CD pipeline, Docker, Compose, Swarm, or Kubernetes, with a staging environment, and all the repository management. There is so much to consider, so much to learn, and so much new stuff every day that if you don't keep up, you're instantly behind.

Have I mentioned security, observability, high-availability, scalability, elasticity or deployment? Because it's also part of the job.

Honestly, you don't have to know how to use everything I mentioned. But if 90% of the words sound unfamiliar, then trying to pretend that you know what you're doing is a terrible idea. For you, for your team, and for the whole company you're working for.

Technical debt is real. Saying "I don't know" is an honest and comprehensive answer.

Computing has become infrastructure, but it doesn’t work like infrastructure.

This article is also worth reading:

Programmers: Stop Calling Yourselves Engineers

And this video worth watching:

Building High-Trust Environments by John Drexler

If you want to start a career as a software engineer or a software developer, I must inform you that it requires sacrifice and dedication. Like a lot of other professions, you won't become good just by reading or watching a video or by listening to a professor for a couple of hours. You won't become the best without immersing yourself completely in the field.

Maybe, by seeing a software developer at work, everything may seem simple. It's probably because it knows its work without having to sell you complexity to justify its existence.

It's hard to sell simple, because simple looks easy, and who wants to pay for that? From Merchants of Complexity by David Heinemeier Hansson