DEV Community: Viktor Vítovec

Why (not)learn programming.

Viktor Vítovec — Wed, 01 Jul 2026 16:57:28 +0000

A few years ago, programming felt like the default answer to: what should I learn if I want a valuable skill? And honestly, it made sense. If you knew Python, JavaScript, or TypeScript, you could suddenly build things that most people could only describe.

Today I would not tell someone: learn a programming language and you are set. Knowing syntax is not the main skill anymore. AI can produce a ridiculous amount of code in a day. Roughly the kind of volume a normal employed developer would write by hand over years. The exact number is not the point. The point is that writing lines of code became much cheaper.

That does not mean programming is useless. It means the reason to learn it changed.

Programming work changed

In the past, a big part of the value was simply being able to turn an idea into code. You knew how to write an endpoint, a component, a script, a database query, an API integration. That is still useful, but it is not as rare as it used to be.

If I have a fairly clear system in my head today, AI can write a large part of the implementation for me. Not perfectly. Not without review. But fast enough that typing code is usually not the bottleneck anymore.

The bottleneck is more like: do you know what should be built? Do you know where the boundary should be between frontend, backend, and database? Do you know when a simple script is enough and when you need a real app? Can you tell when AI wrote code that looks clean but will break in a month?

That is the new line, in my opinion.

A language is not enough

Learning Python or TypeScript is great. Really. I just would not expect it to automatically make you employable or make someone trust you with a real product.

A language is a tool. If you only know the language, you mostly know how to phrase instructions for a computer. But real software is not a language exam. It is decisions around data, users, errors, deployment, security, performance, UI, operations, and a thousand small details that tutorials often skip.

I know Python and JavaScript/TypeScript, but honestly, I barely write most code by hand anymore. Most of the useful work is deciding how the project should behave, how to split it up, what should stay simple, what needs to be robust, where it can fail, and how to verify it. On projects like my portfolio or internal tools, the main work is often the system, not the lines.

What I would learn instead of “just programming”

If I started from zero today, I would still learn coding basics. But I would treat them as the entry ticket, not the final goal.

I would learn product development first. How to take a messy problem and turn it into something someone actually uses. How to tell whether I am building the right thing. How to choose a small first version instead of a giant plan that never ships.

Then I would learn how programs are structured. Not necessarily writing every file manually, but understanding why a project has folders, modules, database models, API layers, tests, env vars, and a deployment pipeline. This is exactly where AI still needs a person holding the direction.

And I would learn problem solving. Reading errors. Finding causes. Figuring out whether the issue is in the database, cache, config, network, UI, or my own assumptions. AI helps a lot here, but it still needs someone who knows what to check next.

Why programming is still worth learning

I do not want this to sound like “do not learn code.” That would be stupid. If you do not understand code at all, you are completely dependent on whatever AI outputs. That is risky.

Programming basics let you judge whether AI output makes sense. You can see when a function does something different from what you asked. You understand why types do not match. You can spot a piece of code that bypasses security or a migration that might delete data.

You also ask better questions. When you use tools like OpenAI Codex or other coding agents, the result depends a lot on whether you can describe the problem precisely. “Build me an app” is not enough. You need to know the inputs, outputs, states, and constraints.

So yes, learn programming. Just do not treat it as the final destination.

The new value is orientation

I think the gap will grow between people who can write some code and people who can orient themselves inside software.

Orientation means you can open an unfamiliar project and slowly understand what is going on. You can find where a bug starts. You can build a mental map of the system. You know what to give AI, what to review manually, and when the better solution is to simplify instead of adding more code.

That is much stronger than memorizing syntax. AI can fill in syntax. But a bad product or architecture decision can be accelerated by AI too, which only makes it more expensive.

So: should you learn programming or not?

Yes, learn it. But not with the idea that knowing one language is a career by itself.

Learn programming so you understand what AI is doing. Learn to build small things from start to finish. Learn to read existing projects. Learn to structure work. Learn product thinking. Learn to verify, not only generate.

Writing code is cheaper than it used to be. Knowing what code should exist in the first place is more valuable than it used to be.

That is the better reason to learn programming now.

The barrier to entry into tech does not exist anymore.

Viktor Vítovec — Wed, 01 Jul 2026 16:57:26 +0000

Getting into tech is easier now than it has ever been. Not because programming, debugging, or building products suddenly became trivial. More because access to information is barely the blocker anymore.

Before, you had to find a book, a course, a smarter person, or dig through forums until something clicked. Then the internet and YouTube changed the game. Now AI pushes it even further, because you can keep asking questions in one thread until the thing finally makes sense.

That changes the entry point into tech more than a lot of people admit.

Curiosity is still the best teacher

I did not get into this through some serious plan like: now I will become a programmer. It started in a much more normal way. I was a gamer and I wanted to mess with things around games.

For a lot of people, that game is Minecraft. I still think it is one of the best games for pulling someone into technology, because it naturally rewards curiosity. You want to change something, add something, understand why something works the way it does. Suddenly you are not only playing a game anymore. You are dealing with files, servers, plugins, mods, commands, and eventually code.

That is a very good way in, because it does not feel like forced learning. It is not: here is a syllabus, now suffer. It is more like: I want this thing, I do not know how to do it, so I will try to figure it out.

The internet already broke most of the barrier

I never really built my learning around paid courses. Not because all paid courses are bad, but because for the way I learn, they were not necessary. There is so much information online that if you have some interest and patience, you can learn almost anything.

YouTube and the open web taught a lot of people things that school or formal courses never did. Not because school is useless, but because the internet is closer to real problems. Want to run a server, fix a React error, understand a database, write a script, set up domains, or automate emails? Someone already had that problem. Someone recorded a video, wrote an article, or argued about it in a forum.

That is a huge shift. Access used to be the problem. Now the harder part is choosing what to try first.

AI made learning feel like a conversation

In the last two years, this moved again. Before, you searched Google, opened ten tabs, read different answers, and tried to combine them into something that matched your exact problem.

With AI, it feels more like an ongoing conversation. You ask. You get an explanation. You do not understand it? Ask for a simpler version. Want an example? Ask for one. Do not know what to ask? Ask what you should ask.

For a beginner, this is extremely strong. They do not immediately need to be good at search keywords, filtering old answers, reading long documentation, or guessing whether a Stack Overflow thread from 2014 is still relevant. They can get a first map of the problem and move step by step.

And now it is not only about explanations. Tools like Codex or Claude Code can open a project, write code, edit files, set up config, run tests, and get something working. If you want to build almost anything practical - a website, automation, small internal tool, script, data import, or API connection - you often do not need to start from a blank editor anymore. You describe the outcome and an agent can build the first version for you.

Of course AI can be wrong. You still need to think, test things, and verify the result. But as a starting engine, it is ridiculously convenient. We moved from searching physical libraries, to searching the internet, to asking ChatGPT or a similar tool and continuing from there.

What is still hard

This does not mean everything is easy. It means the main obstacle changed.

Information is almost free. Tools are available. AI can suggest a plan, explain an error, write a first version, set up a project, and tell you what to try next. But it still cannot solve the most important part for you: wanting to do it.

Forced learning is much harder than starting from a hobby. When the thing itself interests you, you survive debugging, messy docs, bad tutorials, and the moment where something does not work for two hours because of one stupid mistake. When you only do it because you feel like you should, every blocker feels like the end.

The second hard part is finding an idea. Some people have a head full of problems they want to solve. Some stare at an empty editor and have nothing. But even that can be worked around. Look at your normal day and ask: what do I do manually, what slows me down, what could be faster, cleaner, or more fun?

That is usually better than trying to invent a startup.

A first project should be tiny

If I had to recommend a first project for this week, it would not be a huge app. It would be something small that solves one annoying problem from your own life.

If you are a gamer, try a tiny game tweak, config, simple mod, server script, or something around your community. If you have too many emails, try an automation that summarizes them and drafts a reply in your style. If you repeat some task at school, work, or home, try making it faster.

It does not need to be perfect. The point is being able to say: right now I do this manually, and I want to make it faster, cleaner, or more fun.

That is how small things naturally turn into real projects. For me it leads into websites, automations, internal tools, and the kind of work I show in my portfolio projects. But the principle stays the same: take a problem, build a small first version, break it, fix it, learn the next thing.

The barrier is low, but the work is still real

The biggest lie about tech now is that you need some special entry pass. You do not. You need curiosity, a bit of stubbornness, and the willingness to build small things before they look elegant.

AI and the internet will not create motivation for you. But if you already have the motivation, starting today is almost comically accessible.

That is good news. Not because everyone has to become a programmer. More because the less people are scared of technology, the more small annoying problems they can solve for themselves.

I Want to Build Things That Save Work

Viktor Vítovec — Wed, 01 Jul 2026 16:48:47 +0000

I have built a lot of websites. I still build them, and honestly, I think I have become pretty good at it. I still enjoy making a page feel fast, clear, polished, and useful.

But websites by themselves are not really the thing I want to spend my whole future doing.

I already wrote about this from a slightly different angle in Pretty Is Not a Website Strategy. A good website should not just look nice. It should solve something.

That is the part I care about most now: finding repeated work and turning it into a shorter process.

Websites are still fun, but they are not the whole point

I do not dislike websites. The opposite, actually. A website is still one of the fastest ways to build something visible, useful, and easy for people to access. I like the details: speed, layout, content, design, structure, and the overall product feeling.

What I do not like is the idea of making the same landing page over and over, changing the logo, colors, and text, and pretending it is a brand-new problem every time.

When I build a website, the best part is when it becomes more than a presentation. When it gets an admin system, a map, a calculator, data processing, automation, or some internal tool behind it.

EasyFlex made that clear early

One of the best examples is EasyFlex. My mom runs her own accounting and tax advisory business, and every month she spends a lot of time entering invoice data into ABRA Flexi, the accounting system she uses.

On paper, this does not sound dramatic. You open an invoice, read the amount, date, supplier, variable symbol, a few other fields, and enter it into the system. But when you do that again and again, every month, for multiple clients, it becomes a lot of work. Not hard work, just repetitive, slow, and annoying.

The first version of EasyFlex was not some perfect platform. It was more of a test: what if I could take an invoice, extract the useful data, and prepare it in a way that makes the accounting work much faster?

Over time I rebuilt parts of it, fixed things, and improved the flow. The result is much more interesting to me than a nice portfolio screenshot: the time my mom spends on that part of the work dropped by more than ten times.

That is the type of building I like. Not because it looks impressive in a mockup, but because it removes work someone would otherwise repeat again and again.

The best features make something easier

I feel the same way with websites. When I worked on Mostky, the most interesting part was not just making a page with text and photos. It was the interactive 2.5D parcel map, because it helps people understand what is for sale, where it is, and how the plots relate to each other much faster.

That is the kind of extra feature I enjoy. Not animation just because something should move. I like features that help someone understand the situation faster or make a decision with less effort.

At that point, the website is mostly the surface. The interesting work is underneath: data, logic, a simple interface, automation, and information flowing in the right order.

Optimization is not only a technical thing

When I say I like optimizing, I do not only mean shrinking a bundle or making an API endpoint faster. I like that too, but it is only one layer.

I mean looking for friction in normal work. Where someone clicks ten times when they should click once. Where someone manually copies data that already exists somewhere else. Where a human waits on a step a system could handle. Where the same small mistake happens every month because nobody built a better process.

That is much more interesting to me than just asking whether a page looks nice. It should look nice. But if it does not make anything faster, easier, or clearer, then it is mostly decoration.

Right now I want experience

I do not know exactly what I want my final “real job” to be. And I think that is fine. I am still at the stage where I want to try as much as possible: websites, automation, AI tools, internal systems, databases, self-hosting, product work, all of it.

But the direction is becoming pretty clear. I like building things that are not just nice, but useful. Things that take boring, slow, repeated work and make it faster.

So yes, I will keep building websites. I just increasingly want there to be something real behind them.

That is the work I find most interesting now: find a problem, understand it well enough, and build a tool that makes it easier to deal with.

Pretty Is Not a Website Strategy

Viktor Vítovec — Wed, 01 Jul 2026 16:48:45 +0000

A website can look really good and still do almost nothing. That is one of the most common traps with new websites: people spend a lot of energy on colors, animations, photos, and mood, but less on whether a visitor understands the offer in ten seconds.

Design matters. It is just not the whole product.

Design is the first impression, not the whole website

A good-looking website helps. When a page feels clean, modern, and trustworthy, people have less reason to close it immediately. That is real value, not some shallow detail.

The problem starts when visual design becomes the final goal. Then the website can become a nice screenshot for a portfolio, but a weak business tool. The visitor does not know where to start, what the company actually does, who it is for, why it is different, or what to do next.

Good visuals should support the message, not hide the lack of one.

Structure sells more than effects

A lot of website performance comes from the order of information. First, the offer needs to be clear. Then who it helps. Then why someone should trust it. Then the next step.

That sounds simple, but it breaks all the time. A homepage has a big slogan and a few nice sections, but no real logic. The visitor gets a few separate impressions, but never moves naturally from problem to solution.

When I build websites and landing pages, I try to understand the business, person, or product behind the page first. A local service needs a different website than a SaaS tool. A portfolio needs a different rhythm again. Using the same template for everyone is fast, but usually the wrong shortcut.

Copy is not filler

Copywriting is one of the most underrated parts of a website. Text is not something you paste in at the end after the design is finished. Text often decides whether the offer makes sense at all.

One clear sentence can replace three sections of explanation. One vague sentence can make a beautiful layout useless.

This is not about big marketing phrases. It is about precision. What do you do? Who is it for? What gets better? Why you? What should the visitor do next? If those answers are not visible quickly, design will not rescue the page.

Speed and SEO are not boring extras

A slow website loses people before they even see the pretty design. And a website that cannot be found properly is often dependent on manually sending people the link.

This does not need to become overcomplicated. The basics are fast pages, sensible images, a clean heading structure, useful metadata, and content that answers real questions. For practical performance guidance, web.dev is useful, and Google has an official SEO Starter Guide.

These things should not be treated as “later” work. They belong in the base of the website, the same way colors and typography do.

Launch is not the finish line

Another weak point is maintenance. A website launches, everyone is happy for a while, and then it starts getting old. The offer changes. New references appear. Something breaks. Nobody tests the form. The copy stops matching reality. The technology around it keeps moving.

A website is not a poster. It is a living system.

That is why I like building things in a more connected way: design, landing pages, web apps, automation, data, and sometimes the backend around it. In some projects, the website is not just a business card. It is the entrance into a real workflow. At that point, looking good is only the baseline.

How I think about it

When someone wants a new website, the best first question is not “what should it look like?”. A better one is: what should it change?

Should it bring leads? Explain a complicated service? Make sales easier? Build more trust? Save the team time? Show the work better than the old site?

Only then does style become useful. Style without direction is just decoration.

A pretty website is great. But a good website is pretty, clear, fast, maintained, and built around the people who actually use it. I have a short overview of how I build websites, or you can just reach out through contact.

That is basically it. Not every website needs to be a huge application. But almost no website should be just a nice picture with a menu.

I turned my old gaming PC into a Linux server

Viktor Vítovec — Wed, 01 Jul 2026 16:07:08 +0000

Sometimes an upgrade is not about buying something new. Sometimes the better move is taking the thing that is already sitting there and giving it a better job.

That is what happened to my old gaming PC. It used to be the center of my gaming setup. Now it is a small home server running databases, backends, and the kinds of things I do not want to pay for as another separate service.

Why I stopped using the desktop

I have been gaming on PC since I was very young, so that machine had a long run. But this year I bought a MacBook Air, and it slowly became my main computer for almost everything: work, personal projects, writing, Codex, and quick ideas away from the desk.

That changed more than I expected. I did not want to be tied to one setup anymore. I wanted to open the laptop on a train, at school, on a sofa, or wherever else and just continue.

So the desktop stayed powered off more and more. And when I want to play something now, GeForce NOW from the Mac is usually enough. The old PC was good for its time, but it was starting to hit performance walls as a gaming machine. As a server, it still made perfect sense.

I did not want every small idea to become a subscription

A lot of my projects need some backend, database, auth, or small internal tool. Managed services like Supabase are comfortable and absolutely have their place. But when I build lots of small things for fun, paying separately for every tiny project stops making sense.

This was not about saving money at all costs. It was more about removing a bad filter from the way I build: “Is this idea worth another monthly bill?” That is a bad question to put in front of creativity.

Now the server can hold small databases, test services, and backends for projects like EasyFlex, ABRA Flexi AI, and even the database side of this portfolio website. It also gives me space for more experiments that would otherwise stay in notes.

Installing Ubuntu was not exactly smooth

The setup itself was not some clean cinematic montage. It was more like a few failed boots, trying to hit the right boot-menu key, dealing with small annoying issues, and finally getting into the Ubuntu installer.

I kept the setup as minimal as possible. No unnecessary desktop environment, no giant experiment on day one. The goal was simple: the server should run, host things, and stay out of the way.

That matters. Home infrastructure can easily become another project that eats more time than it saves. I wanted the opposite.

Cloudflare Tunnel beat messing with my router

The next decision was networking. I did not want to expose my home router or deal with port forwarding, public IPs, NAT, and all the usual small traps. I used Cloudflare Tunnel instead.

That worked surprisingly well. The tunnel runs on the server, I map a service to a domain, and I do not have to open random things directly through the router. It is boring in exactly the right way.

Then I started moving hosted things over. Some apps needed different env vars. Some expected a different Node version. Some worked locally and then broke in a completely different way on the server. But that is the normal cost of owning more of the stack.

It became a server when I unplugged the monitor

Once the setup was stable enough, I unplugged the monitor. From that point it stopped feeling like “a computer under the desk” and started feeling like a server.

At first I accessed it through Tailscale, later mostly through SSH with public/private key auth. I also wanted to remove the GPU to save more idle power, but my Ryzen 5 3600 setup will not boot without it. So the GPU unfortunately stays.

It is not perfect. But it is still much better than letting the whole machine sit unused.

Codex became part of the server workflow

The next obvious step was installing Codex. Not only for working on projects, but also for managing the server itself.

These days I do not manually SSH into it nearly as much. In the Codex app on my Mac, I have a connection that lets the agent work directly on the Linux server. In AGENTS.md and a custom skill, I describe what the server is, where projects live, how it should behave, and what it can safely do.

I sometimes use Claude too, mostly when I want a different angle on UI or frontend work. But for normal server tasks, the interesting part is that Codex can work right next to the infrastructure.

In practice, that means I can ask it to help with things like:

moving a small service,
checking logs,
preparing a deployment,
cleaning up /srv/projects,
setting up a new database or backend quickly.

I still need to understand what is happening. That part does not disappear. But I do not have to copy the same commands again and again.

What I learned from it

I am not saying self-hosting is always better than managed services. It is not. If a project is critical, needs high uptime, has a team behind it, or requires quick support, a managed platform makes a lot of sense.

But for personal projects, prototypes, small databases, and things I want to build quickly without a small mental tax, having my own Linux server is great. It also fits parts of my portfolio and website work, where a small piece of infrastructure does not always need a large platform around it.

Mostly, I like that the old gaming PC did not become a dust collector. It used to give me performance for games. Now it gives me room to build small things without attaching another account to every idea.

That is a pretty good second career for an old PC.