Getting your Trinity Audio player ready…

A Thursday night in mid-July. Emails keep landing in my inbox, one after another, and each one says the same thing: pipeline failed. I open the logs and read them line by line, trying to understand what went wrong. I commit a fix, and it fails. I despair a little, commit again, and it fails again. So I go back to the logs. Then one commit finally goes through: the icon on GitHub turns green and the changes reach production. Phew!

Starting again, not from scratch

In April, there was nothing to deploy yet. That was when I joined the Women Go Tech Acceleration Program as a mentee. The program is designed to help women grow their careers in tech. That wasn’t quite my case. I’d been in tech since 2017, but two years ago I quit my job as a frontend engineer because of burnout (a word that doesn’t quite cover what it’s like to rebuild your life in a new country as a war refugee: you try, you fail, you try again).

That doesn’t mean I quit programming, though. Last year I finished a Python basics course at the Polish-Japanese Academy of Information Technology (PJATK). I also built a couple of side projects: a Bluesky bot that shares images from Europeana’s Blue Gallery, and mavka, a script that gathers the latest publications from websites I trust into my Notion. I was ready to grow my career in tech again. I just wanted to do it my way.

A map for people who read

For me, that meant building something I would actually use. In my first years in Warsaw, book clubs and reading together helped me feel at home in the city. Reading is private, but it also connects people, and I wanted those places to be easier to find. That’s how Bogorm started: an interactive map of bookshops, book clubs, and literary events in Warsaw. It was also my chance to take what I’d learned in the Python course and use it on something bigger than exercises. I chose Python / Django for the backend and Vue / Nuxt / TypeScript for the frontend.

My mentor, Ieva Astašauskė, suggested not waiting until the project was completely ready: deploy early and add features one by one. The first version went live in early June: just a Leaflet map of Warsaw with pins for places. From there, Bogorm grew one feature at a time. In July, it got user accounts. By the end of summer, it could show events in a sidebar and let people save bookmarks. Now I’m working on translations, so people who don’t speak Polish can use the map too. Next come a mobile-friendly layout and accessibility. The backlog keeps growing, which means my work on Bogorm won’t end with the program.

Here’s how it works today. Say you’ve just moved to Warsaw and want to find people who read. You open Bogorm and see pins all over the city: bookshops, book clubs, places where people meet around books. You click on one near you and check the upcoming events in the sidebar. If something looks interesting, you save it to your bookmarks. Soon, you’ll also be able to add notes and comments.

Building is not understanding

A lot of Bogorm’s code was written with Claude. It’s great for prototyping, and it helps a lot when you work in a language you don’t know well yet. You ask, and it delivers: a model, an endpoint, a working feature. But building is not the same as understanding. Code smells showed up quickly, and so did the need to refactor.

Ieva suggested I step back and read some theory on Django architecture. Her first recommendation was A Philosophy of Software Design by John Ousterhout. The book described what was happening to my code almost too well. As Bogorm grew, it got more complicated, with dependencies I wasn’t always aware of. Ousterhout explains why: the hardest part of writing software is understanding what you’ve built. Each new feature adds subtle links between parts of the system. Complexity piles up, and soon you can’t keep it all in your head. Then come the bugs, and they slow you down even more.

AI delivers, but it can’t do the practice for me. Without practice, I see only a wall of code, not the idea behind it. Ousterhout writes that students learn best “by writing code, making mistakes, and then seeing how their mistakes and the subsequent fixes relate to the principles.”

That’s why code review matters. Ieva’s comments always made me stop, look again at what I’d written, and try to fix it. As Ousterhout puts it, “the initial design for a system or component is almost never the best one; experience inevitably shows better ways to do things.” In my case, that experience was often Ieva’s.

Why six months matter

When I started programming, getting into tech felt easier. There were so many communities for women: Django Girls (I went to one of their workshops in Kharkiv in 2017), Angular Girls, Frontend Foxes for Vue, Vona Tech Community. Some of them are gone now, and others have changed. Over the years, I’ve been both a mentee and a mentor. Looking back, Women Go Tech gave me the most, and brought me the most joy. A big part of that was a perfect match with Ieva. It also helped that I came prepared, with a clear plan for the program. And then there’s the length: six months is no joke. It takes commitment, but it pays off.

During the program, I also built resheto, an interactive data story about whose books get translated into Polish and whose voices never reach Polish readers. I showed it at work, and now I get data visualization tasks.

So if you’re thinking about applying, do it. And don’t be afraid to try, fail, and try again. That’s how pipelines turn green.

Explore Bogorm:

Let’s connect: