The Art of Software
Embracing the creativity in software development
I have recently been thinking about my work as a software engineer and the role of creativity in it. I feel like software development is often misunderstood to be straightforward process of solving problems. This doesn't align with how I work at all, so I thought it makes sense to share my perspective on it.
My background
The way I approach software development might be different from many other people working the field. I never studied computer science in university or learned about all these theoretical and deeply technical concepts. I did have a few computer science courses in high school where we learned the basics about computers, networking, and programming, but that's pretty much it.
Nevertheless, I can confidently say that I'm pretty good at building software. For me building software was always about intuition. I remember when I built my first project in Python, I didn't start out reading about patterns or algorithms—I just started writing code until something worked. Every developer knows that deeply satisfying feeling when the software you are building actually starts working.
To this day that's exactly how I go about starting new projects. There is little planning involved. I have an idea in my head and just start building; everything else comes along the way.
"Vibe Coding"
The term "vibe coding" has taken over the software development world in 2025. It describes the process of creating software by relying purely on AI tools like chatbots to write the code. Advocates of it suggest that this way developers can forget about the code altogether and just focus on the vibe and feel of the product.
I think the term is extremely misleading. Using AI to write the code is probably the least vibe based approach I can think of. AI doesn't have emotions; it can't vibe. Even if we say that "vibe" refers to the end-result and not to the code, AI is inherently bad at creating stuff that people can actually relate with.
My way of writing software actually fits the term "vibe coding" much better as it is extremely dependent on my vibe and creativity. When I have a blockage or can't get into the right space of mind, I really can't do good work.
The Flow
Everybody knows the feeling of being in the flow. This is when remaining completely focused on a task feels effortless and the time just flies by.
For me it's the most effective way of working as I can immerse myself completely into a project without being distracted by anything else. Sadly this state is also very fragile and can't be forced. I find that large amounts of caffeine can definitely help, but it's also heavily dependent on the environment I'm in.
When I'm working on my own projects I find that there is no point in forcing me to work on something when I don't feel inspired. Yes, there are things that have to get done and I can force myself to do them, but usually it's more effective to follow the inspiration and work on things that I feel motivated to do. I will be magnitudes faster and do better work even if it means that the output quantity isn't constant.
I personally can only get into the flow when I'm alone for an extended amount of time and can decide myself when and on what I want to work.
Working Alone
I always liked being alone and this also applies to the way I work. I spend probably 80% of my work day without communicating with anyone and just working on my own. Obviously I don't write code the whole time; a lot of time is spent on thinking about problems and honestly also just distracting myself. But when the flow kicks that's when I do my best work.
There were times when I felt bad about this and thought working more with other people would yield better results. And in many ways it can! It definitely helps discussing problems with others to get other perspectives and find the right solution for problems.
It took me a while to realize that building software is an extremely creative process for me and it works best if I don't have other people interfering with that too often. That doesn't mean I don't like being part of a team, but I also don't want to discuss every decision I make.
I believe that's also one reason why larger teams move slower. Constant communication kills creativity and inspiration.
The Art in Software
In my experience the process of creating software can be very similar to creating other forms of art. Most artists do their work alone and don't rely on constant communication with others. Obviously inspiration often happens by getting input from outside, but the actual act of creating something new happens alone.
If you ask Michelangelo to paint the ceiling of your chapel, you are asking him to function as an artist; if you dictate to him the nature, coloration, size and relationship of the objects he will portray there, you are asking him to function as an engineer. [1]
Art is created in quiet places and when no rigid instructions are given. You can treat software development as engineering—the same you can treat painting as engineering—but at what price?
I don't want to frame myself as an artist or compare software development with other forms of art. There is some artistic part to it and ignoring that stops great work from happening.
"Problem Solvers"
I have seen many software developers call themselves problem solvers, and I think that's a valid description for parts of what software development is. I don't believe solving a problem is often the primary motivator though.
Yes, software is usually there to solve a problem and I think we all like doing that, but is that actually the primary motivation? Isn't it often just the act of creating something, even if it's completely useless to the rest of the world?
Some of my favorite projects weren't built to solve a problem; they just came out of interest and inspiration to create something. I think in a weird way software projects can be a way to express emotions, just like other art forms.
Treating Software like Engineering
For many years people have tried to squeeze the process of software development into rigid corporate structures to make things predictable and plannable.
These times are over and most companies have accepted that this isn't the right approach and doesn't align with the reality of software development. People have come up with so called "agile" frameworks like SCRUM that are supposed to be flexible enough while still maintaining control over the process.
Are these frameworks better than rigid structures? Yes. Are these frameworks good to foster creativity? No. Planning every single detail and having to communicate every step always hurts creativity and flow.
Does this apply to all software? Probably not. There is software where little creativity is involved and where this is the right approach.
The Role of AI
I believe when it comes to the creative act of developing software, AI can be a good tool. There is a thin line between using it as an assistant to do mundane tasks or letting it control the whole process. It's really easy to get used to tab-completion provided by Github-Copilot and similar AI integrations, but I personally try to avoid using more than that for projects that I actually care about.
In the end—just like a chainsaw for wood sculptor—AI is a tool in the toolbox that can make certain things easier. We should be careful to not let the chainsaw make the sculpture on its own though.
Embracing Creativity
Software encapsulates aspects of both engineering and art. It follows clearly defined rules and requires careful considerations, but the creative aspect is undeniable.
I think in that sense the job of a software developer is very similar to an architect. There are clear rules defined by the laws of physics that affect the design and construction of the building. In practice this is only the very base of the work and obviously expected from all architects. What really defines a good architect is not how well they understand physics, but how they incorporate that into the design.
I think we should embrace the creative aspects of software more and allow for the flow to kick in.