Starting a Second Career in Backend Engineering

About eight or nine months ago, I began taking my goal of moving into technology more seriously after years of peripheral training. I started with Python, and as I became more comfortable with programming, my interests gradually became clearer. I found myself increasingly drawn to backend engineering, databases, data systems, and the infrastructure that makes applications work beyond what users see on the screen. Due to the fact that I had this as the beginning of a second career for me, I approached the process with a strong desire to understand what I was doing rather than simply move quickly through a list of technologies.

At first, most of my attention was focused on learning. I studied Python syntax, functions, classes, modules, data structures, error handling, APIs, relational databases, frameworks, database concepts, and some foundations in data engineering and artificial intelligence. I worked through tutorials, documentation, exercises, and small projects. The more I learned, however, the more aware I became of what I did not know. Every new concept seemed to reveal three more areas that I needed to understand. That awareness was useful because it helped me identify my weaknesses, but it also created a feeling that I needed to learn much more before I was ready to build anything substantial.

For a while, I thought this was the responsible way to learn. I believed that if I studied enough, I would eventually reach a point where I would feel prepared to build confidently. What I gradually realised was that such a point might never arrive. There would always be another concept to understand, another course to complete, another library to explore, another framework to learn, or another project I could watch someone else build before attempting my own. I could continue preparing indefinitely and still feel like a beginner.

That realisation changed the way I approached learning. At some point, I had to stop treating learning as something that happened before building and allow building to become part of the learning process itself. Instead of waiting until I understood everything I thought I needed to know, I began working on projects that forced me to confront the gaps in my knowledge directly. That shift has probably been one of the most important lessons of the past eight months. I am still early in backend engineering and data systems, and there is a great deal that I do not yet know, but building has changed what I think it means to learn software engineering. 

A programming language gives you tools, but backend engineering forces you to think about how those tools should be organised into a system. My questions gradually moved beyond whether a piece of Python code was syntactically correct. I started thinking about where application logic should live, how data should move through an application, what information belonged in a database, what an API should expose, where validation should happen, how failures should be handled, and how different parts of an application should depend on one another. I also started thinking about whether important behaviour could be tested independently and what would happen to the structure of an application as it became larger.

These questions made software engineering feel much bigger than writing code that worked. I began to understand that the challenge was not simply producing the expected output. It was also deciding how responsibilities should be separated, how data should be represented, and how a system could remain understandable as it changed. Concepts such as architecture, modularity, testing, and separation of concerns began to feel less like abstract terminology and more like practical responses to problems that appear when software grows.

Bringing My Previous Work Into Engineering

Backend engineering is a second career for me, but I am not beginning it without another intellectual life behind me. My background in philosophy and research continues to influence the way I approach technical work. I naturally ask questions about concepts, assumptions, judgment, responsibility, evidence, and why one decision follows from another. Increasingly, I see those habits appearing in how I think about software systems.

Software development involves judgment constantly. Why should a particular responsibility live in one part of the application rather than another? Why should data be modelled in one way rather than another? What assumptions does a system make about its users? What happens when it fails? Which decisions should be automated, and which should remain meaningfully under human control? These questions are part of the thinking behind Responsibility Lens, but they are also becoming part of how I approach technology more generally. I am learning how systems work technically while continuing to think about the human decisions surrounding them. I do not yet know exactly where those paths will eventually meet, but that intersection is one of the areas I hope to explore through Aderayo Dev Notes.