Remember when back in November I wrote about starting to learn Java? November was indeed my month of Java, Spring, and Spring Boot. The months that followed were marked less by Java specifically — there was a bit less of it — but by intensive learning across a wide range of topics useful for a developer: from building a product concept from scratch all the way to devSecOps.
If someone had told me upfront how much work I'd need to put in just to keep up with the course requirements and actually get through the material, I might have thought twice about whether I had enough in me to join the program and study that intensively... But the training was underway, and my only options were to sink into doubt or try to fill the gaps in my knowledge.
It didn't help that I was still working as a freelancer at the time...
The Reality of Freelance Work
Freelance developer work can look very different depending on the situation. Usually the only common thread is the employment structure — running your own business, self-employment. You can still be a freelancer who works for a single company, where the preferred arrangement — for the company, the developer, or both — is B2B cooperation. Or you can be a true free agent, picking up multi-month contracts across different projects. In both cases, you'll typically be working on larger projects, varied application architectures, and cloud-based solutions. That kind of work lets you develop a lot of skills that are useful not just on the project itself, but also in any future job search.
Then there's working on smaller projects — ones that technically earn you the same title of "freelance developer," but offer little in terms of growth. The reason is simple: these projects have budgets too small for advanced solutions. You build a working website, maybe optimize something here and there — and that's it. You could stay with that kind of work indefinitely. But if growth is what you're after, building new skills becomes difficult when the time outside of projects has to go toward finding new clients.
Finding new clients and new gigs isn't always straightforward — especially for people with personality traits that don't make the business side of things easier. And I'm not talking about client conversations about the project itself, but about everything around it: lead generation, responding to inquiries, and often some unpleasant adventures with invoices — where an unpaid invoice isn't even the biggest problem.
It won't come as a surprise that the rise of AI and low-code/no-code solutions has also changed the freelance market. It's not that work has disappeared — more that its nature has shifted. Many people who would have once hired a freelancer now turn to these tools instead, with varying degrees of success. They'll reach out to a professional when the language models can't solve the problem for them. Or they won't reach out at all — they'll just tear down the existing solution and start over from scratch. There's still plenty of work, but those with more experience and an established market position are in a much stronger position to take advantage of it.
My sense is that right now, success requires either aggressive marketing (which I organically detest) or a very strong network that you know how to maintain and actively grow (handling which is overwhelming and overstimulating). There's also the option of some innovative project — but not everyone has the creative reserves and resilience to build a startup from the ground up.
Having seen freelance work from the inside, I've come to realize it's not the kind of work that suits me right now. Especially since my goal is to make the leap toward a different type of project.
Between Banging Out Code and Real Projects
The era of "just banging out code" projects is slowly fading. AI can generate code faster and often better. And yet, without the experience that comes from those simpler coding gigs, it's often hard to land a spot on a more serious project. It's not about the superiority of writing code by hand — it's about the value of experience across various projects, simpler ones, but ones where real challenges appeared and priceless experience was gained. Projects where you had to solve a problem, design a data flow from scratch, come up with the architecture of a new solution, choose the right technologies. Projects where a whole team works on the solution together, fostering the exchange of ideas. And that kind of experience is what you accumulate when you're partly a "code grunt" — the person handling the simpler things — in other words, an intern or junior developer.
So if individual clients are gravitating toward low-code/no-code, and large companies are investing in AI for simpler tasks, the gap between "practice projects," pet projects, small commercial gigs, and actual software engineering work keeps growing wider. And acquiring the missing knowledge to make that leap requires serious commitment.
And those last few months of mine were defined by exactly that commitment. The time was filled with intensive learning and moments of cutting myself off from everything — just to not trip and fall under the weight of everything on my plate. My mind was geared toward weekly material reviews, quizzes, writing essays on one technical topic after another, coding applications — not to mention the regular evening lectures and workshops.
My weeks were pretty packed, and it often happened that I only got to certain tasks over the weekend. I'm not sure where I found the strength to keep grinding through assignment after assignment. Let's just say there were weekends that passed under the sign of mounting anxiety about not getting my work submitted on time. I think only once or twice during that whole period did I submit homework after 10 PM with deadline at midnight. The intensive learning and the extra stress I was carrying put me into survival mode — focused on finishing the training and squeezing out as much knowledge and experience as I could.
Despite the exhaustion, I could see my knowledge growing significantly. And in the areas I cared most about — areas that are hard for a beginner developer to access. There's a massive difference between working on a small monorepo and operating in a monorepo with microservices or a polyrepo setup. Testing on a little project with a few subpages looks completely different from testing on a project where you need to ensure proper communication between services and maintain a full test pyramid to avoid spending hours debugging errors...
The Space for Creativity
Throughout that time, my mind was busy absorbing one technical concept after another. You could say my internal processor and RAM had a full queue of tasks to process one by one — until the shutdown: sleep. In those conditions, where boredom becomes an abstract concept, it's hard to let inner creativity or spontaneity have a voice. Everything is subordinated to queued processes — digesting content, translating it into your own internal language, and connecting it to concepts already in your head. The only place where some creativity might surface is writing essays — but those demand technical focus more than creative expression.
That kind of soil is great for the plants that feed on knowledge acquisition. Not so great for the ones that need space to reflect on something other than the benefits of using Docker or microservices security concerns. And those second-type plants are the ones that bear fruit like the Tea with a Dragon podcast, blog posts, or handcrafts.
I noticed that when I'm short on rest and hyper-focused on a specific goal — subordinating everything to achieving it — it becomes genuinely hard to be creative, even with the best intentions. My mind doesn't have the space for it, and at the same time it longs for the space to create. You can survive like that for a few months when a meaningful goal is on the horizon. But at some point, starting to study gets harder and harder, daily tasks feel heavier. The goal gets accomplished — but at the cost of things that matter just as much.
Saying No to Burnout
It might not be burnout yet, but the state I found myself in was dangerously close to it. It's still exhaustion — the kind that eases when more space for rest appears. But recent experience has made clear that it's not enough to first floor the accelerator in learning mode and then switch to equally intense rest. The mind doesn't have a fast-charging port. The body and nervous system have their own pace of recovery. For the organism, less is more. Less — meaning perhaps slightly shorter rests, but regular ones. Daily. Not once a week or once every few weeks when I'm deep in intensive study mode.
And that focus on learning doesn't have to feel like "punishment", "obligation," or situational necessity. Learning to code is usually something I genuinely enjoy, and the end results are deeply satisfying. That can be deceptive in the long run. When fatigue sits on one side of the scale and satisfaction, enjoyment, and fulfillment sit on the other, it's easy to find a little more energy just to feel more of those pleasant sensations. And yes, they usually charge our mental batteries — but they're not the only fuel those batteries need. There are other kinds.
Like mindfulness — being here, in the present moment. Movement, the feeling of tired muscles. Tuning into sensations from the body. Processing content that moves you — whether through reading, listening to an audiobook, or watching a film. Sometimes sports emotions, sometimes crocheting or repotting plants. The brain needs a range of sensations, varied stimuli, diversified fuel — much like the body needs varied nutrients as part of a well-balanced diet.
These activities help maintain wellbeing. They're also the remedy for times when the exhaustion from prolonged learning makes it harder and harder to look at the next lesson, the next snippet of code — when the satisfaction from learning starts to evaporate. When — whether out of curiosity or out of goals we've set ourselves — we've significantly depleted our mental battery. When the battery indicator is dangerously approaching zero, that's exactly when we need to focus even more on wellbeing — on replenishing the energy deficit.
Coming Back to Things — On Recharging Mental Batteries
So my time came too — time to rest for a while. The crochet projects put on hold "for later" are taking shape. When I have the capacity, I go back to working through courses that got shelved for a few months. I'm starting to tidy up a room that accumulated several new geological layers from months of telling myself "that's a problem for after the course." I'm hoping to find a beloved pen that disappeared somewhere between one pile of papers and another, rushed packing for a conference or some other outing — during a time when the immediate demands made it genuinely hard to focus on calmly putting things away. Reactivity won out — the need of the moment, a quiz, a feature or essay to write, designing a new architecture, fixing bugs in the application. Small things like unpacking a backpack would slip from my mind and not come back until the backpack was needed again.
That period was very fruitful, and I think I'll still write a summary of it. Someday. I hope. The list of ideas keeps growing again. For now, I'm trying to take care of myself — to get through the Hordes of the Underdark campaign in the Neverwinter Nights, repot the plants, sew my first patchwork, finish the Easter decorations. There are also other educational projects simmering in the background that I should finish too — some more time-constrained, others less so.
But I still carry in the back of my mind a lesson I keep working on — trying with each iteration to take better care of myself: the lesson of resting. Even of planning rest, so I don't neglect the basic needs of both body and mind — and of something else, something more undefined, that keeps asking for a little more mystery and magic in everyday life.
And the lesson goes like this: rest is not something you have to earn through work, hours of study, or achievements. It's not just my right — it's my obligation, a commitment to myself. Yes, I can temporarily reduce engagement in favor of rest to achieve goals that are crucial to improving my quality of life. There are situations where you have to tap even into reserve energy to reach a goal. But you need to have a plan in the back of your mind for replenishing those reserves — and then rebuilding resources — and follow through on it with the same consistency that once characterized your pursuit of the goal.
Appreciating Yourself and Refueling for the Road Ahead
Rest after success tastes completely different from rest after a project that gave a lot but didn't offer what you needed most in that moment, or didn't end with the expected success. And that's a story for a completely different post. But even in situations where not all goals were achieved, it's worth appreciating yourself for the effort and giving yourself permission to rest.
After all, the absence of success doesn't mean we weren't engaged, that we didn't invest time and energy toward the goal. The same goes for achieving only part of the goals we set. Regardless of the outcome, we expended significant resources that need to be renewed to take on new tasks, create new goals, and work toward future successes.
Appreciating what went well, giving yourself a pat on the back for the small wins that let you learn something along the way — that will help you go further the next time. At the same time, it's worth remembering that when the fuel runs out, you won't be able to make another attempt at the goal. You need to secure that fuel — before the gauge hits zero. By then, finding fuel becomes much harder and far more demanding.
