DEV Community: Sergei Vorniches

Vibe Coding? Yeah, I've Been Doing It for Two Years

Sergei Vorniches — Fri, 14 Mar 2025 11:56:45 +0000

Not long ago, I stumbled across the term "vibe coding" and was kinda blown away. Turns out, the way I've been slapping together my apps for the last two years – with minimal hand-written code and maximum automation via neural networks – now has a trendy name. In this post, I'll share my tools for pair programming with AI and some thoughts on where this whole thing is heading.

So, what's the vibe? While some folks are still gawking, others are timidly dipping their toes in, and a third group is furiously bashing it, I'm just sitting here thinking, "Seriously?". From the first day I saw modern neural nets in action, I started using them – not to flood the web with AI-baked memes, but for real work. And now some dude from Tesla's gone and called it "vibe coding".

A little over two years ago, like everyone else, I was fed up with writing the same old boilerplate for projects, dragging code snippets between files, and googling the same thing every week. Back in August 2022, the original GitHub Copilot hit open beta. There was some buzz like "whoa, the future's here", but I tried it and thought, "Meh, just advanced autocomplete". It wasn't great at generating stuff back then, especially if the task went beyond "write a function". Even now, Copilot in VS Code is hands-down the worst tool for coding with AI.

They started to suspect something

Then, in November of that year, ChatGPT 3.5 dropped. That's when I got seriously impressed. This wasn't just a code generator – it was a legit talking computer.

I scribbled a note back then under the impression:

For me, ChatGPT passed a reverse Turing Test.

In the original Turing Test, a machine has to convince you it's human. With ChatGPT, the answers themselves, their structure, make you feel like you're not just talking to a machine – even though you know damn well it's a neural net.

I burned through request limits non-stop, plugging gaps in my Computer Science knowledge left by skipped uni lectures. An introvert like me, terrified of asking "dumb" questions on Stack Overflow or anywhere else, finally had the perfect way to learn – like interviewing a professor who never gets tired of explaining. The code it wrote back then was garbage, but I kept trying anyway.

At some point, I got sick of copy-pasting file contents into the chat to give it context. So, with the help of that same ChatGPT, I hacked together a simple console tool that "snaps" an entire project into a single text file. Toss that into the chat – bam, the AI instantly sees the structure, files, everything it needs. That was step one.

Then, with ChatGPT 4's release, I realized: with the right tools, coding with AI gets genuinely smooth. Python with its ecosystem, Django as the backbone, Tailwind for UI layouts instead of messing with BEM – it all clicked perfectly into this concept. That's how I started: minimal manual work, maximum "hey, AI, build me a bot".

My first fully AI-written project was WebInsights – a wrapper over the OpenAI API for analyzing JS code, robots.txt, and sitemaps. I even tried launching it as a SaaS, put it on ProductHunt, got some buzz, but eventually shut it down. Traffic was weak, sales were nonexistent, just losses on DigitalOcean server costs. Still, the experience? Priceless. Since then, I've gone full freelance, cranking out parsers, bots, and other stuff on Django, containerizing them with Docker right off the bat. For two years now, I write maybe 10% of the code myself – AI handles the rest.

Prototype and snap2txt – My Vibe Coding Backbone

Over these two years, I've built up my own toolkit that's become the core of my approach. Meet Prototype and snap2txt – two things I don't start a project without.

Prototype: Fast Starts With No Headache

Prototype is my quick-start kit for Django projects in a Docker container. Why Docker over venv? Because it gives full environment isolation and guarantees that whatever runs on my machine will run on a server – be it Railway.app, DigitalOcean, or wherever. Inside, you've got a Dockerfile, docker-compose with basic settings, a helper for the OpenAI API, and a shell script that fires everything up with one command. Clone the repo, name your project, run ./setup.sh – and in a couple seconds, you've got a working Django container on localhost.

snap2txt: Instant Project Context

I built this utility a year and a half ago and use it almost daily. It's dead simple: takes a project, merges all the relevant files into one text file, and skips junk like node_modules or .git via an ignore list similar to .gitignore. There's a whitelist too, if you only want specific files. Then you just tell the AI what to do and roll with it.

How's it work? Say you've got a Django project. Run snap2txt --il, get a project_contents.txt, throw it into Cursor Composer or any AI chat – and the neural net instantly groks the whole structure. Write a prompt, one or two requests – done. Without snap2txt, I'd still be manually drag code chunks around, like an animal.

Why's It Handy?

These tools save a ton of time. Prototype kills the hassle of environment setup, snap2txt cuts the headache of passing context. Toss in Cursor (my favorite since you don't even need to create files) or any chat model like Claude, DeepSeek, or ChatGPT – and you can slap together a working prototype in an hour that'd normally take a week or two. Whip up a Telegram bot, a data parser, or a self-hosted Telegra.ph on markdown in three minutes:

The Future's Coming: AI Codes, We Do What?

All this time, I've been wondering: where's this headed? Two years ago, I couldn't imagine 90% of my project code wouldn't need to be written. Now it's real. And if Zuckerberg's to be believed – promising that by 2025, mid-level code at Facebook will come from AI assistants – we're just getting started.

AI Code – The New Shitcode?

Serious Folks™ are already grumbling that vibe coding's just a fancy way to pile up technical debt. They're not entirely wrong. AI-generated code can sometimes look like "it works, don't ask how". You'll get something, stare at it, and wonder, "Where's the XSS hiding?" Or it runs fine on your machine but crashes on the server because the AI forgot about Debug = True. Left unchecked, it's a ticking time bomb.

But I think that's temporary. Systems are getting smarter. In a couple years, we might not need to dig into the details at all. AI will write, test, and deploy; auto-monitoring will monitor; and coders will turn into operators. You sit, watch the screen, occasionally slap the AI's wrist, and hit the "red button" if shit hits the fan.

What Skills Stick Around?

If we don't need to write code, then what? I reckon the future belongs to those who can ask the right questions. Not "how do I write this function", but "what do I even want to build". Design skills, architecture know-how, breaking tasks into chunks, and explaining them to AI – that's what'll matter. Plus enough basics to spot decent code from trash. Vibe coding isn't about ditching programming; it's about shifting from grunt work to ideas.

A quick aside on "demand". With more programmers around lately, demand for software hasn't dropped – it's grown. What happens when an average coder paired with AI pumps out 10x more software? We'll need even more software. Not 100% sure, but that's the vibe I'm picking up, if you will.

Good or Bad?

Honestly – no clue. Nobody knows. But for me, these two years with AI have been a straight shot of knowledge. I've grown more as a programmer than in the previous eight years combined. All without forums, awkward Q&A site questions – just chatting with a neural net. For an introvert like me, it's perfect. For the industry? Maybe we're heading toward a world where coding's not done by programmers, but by those who can "vibe" with AI. And that's not some far-off future – we're damn near there already.

Self-hosted Telegra.ph in 1 prompt and 3 minutes

Sergei Vorniches — Mon, 03 Feb 2025 13:56:17 +0000

For the past two years, I’ve barely written any code myself. Perhaps only about 10% of the code in my personal and commercial projects is hand-written – everything else is generated by AI. Over that time, I’ve developed a specific approach to building projects and assembled a set of tools that I now use for this purpose. That’s what I want to share with you in this post.

Since 2022, a lot has changed. First, the original GitHub Copilot appeared in open beta, followed by early models from OpenAI – messy, losing context, and unable to deliver coherent results over longer spans. But in recent years, neural nets have evolved beyond advanced autocomplete; they’re now fully capable tools for solving tasks. The key is to frame those tasks correctly. And here, as I’ve noticed, even experienced programmers sometimes struggle with and question the very idea of using AI to write code. That’s what prompted me to write this post.

This post will be especially useful for beginners – those who, like me once, are more interested in “making things” than in writing code line by line. I’ll show you how to create a self-hosted solution similar to Telegra.ph, but with a Markdown editor, using my own tools.

The approach I describe below works with various models: ChatGPT, Claude, DeepSeek, even the free version of GitHub Copilot in its current form (although it’s the most inconvenient to work with). I recently shared my experience with Copilot on dev.to – honestly, it’s more torture than actual work.

I recommend using Cursor, which you can try in its Pro version for two weeks right now. It currently provides the most pleasant and seamless experience for programming with AI that I’ve encountered so far. I’ll be describing my work with it from here on.

System Requirements

To work on this project you’ll need:

Python version 3.10 or higher
Pip for installing dependencies
Git to manage the repository
Docker Desktop (free plan)
Cursor, or access to any AI chat tool
The snap2txt utility, installable via pip install snap2txt
Prototype (project base)

Working on the Project

I want this section to be as clear as possible for beginners, so I’ll explain some things in detail.

1. Create the Project from the Prototype Repository

First, I copy the git clone command with the address of the base project repository (Prototype) and create a new project named tapnote in my working folder.

Prototype is a quick-start kit for Django projects running in Docker containers. I prefer Docker over venv or virtualenv because Docker provides complete OS-level isolation and guarantees an identical environment on every machine. This is convenient for fast deployments on platforms like Railway.app or DigitalOcean. The Prototype includes a Dockerfile and docker-compose with the basic settings, a helper for working with the OpenAI API, and a shell script to launch everything with a single command.

To run setup.sh, I change into the new directory with cd tapnote and execute ./setup.sh. In a few seconds, everything is ready.

2. Verify the Container is Running

A new container with the project’s name will appear in Docker Desktop. If it’s running successfully, you can open the 'web' tab and check the logs for errors. Also, navigating to localhost:9009 in your browser should display Django’s default start page.

3. Open the Project in Cursor and Perform Initial Setup

By "initial setup," I mean both initializing Git and creating the project’s working context. For this, I run git init and make the first commit. In this project, there will be just two commits – before and after the prompt. To create the context, I use the snap2txt tool with the --il parameter.

snap2txt is a Python utility that condenses the entire project into a single text file. I built it about a year and a half ago and use it almost daily. It’s necessary to create a context file for the project, which is then fed to the AI along with the task description. This way, the AI immediately has access to the full context of the project – the directory structure and all files. The --il and --wl parameters refer to using an ignore list or white list, respectively—these are separate files at the root of the utility that specify which files to include or exclude in the context. The --il flag works similarly to .gitignore, while --wl does the opposite.

Now that the context file is created, I open the Composer panel inside the editor and double-click on project_contents.txt to add the project context to Composer.

4. Detail the Task, Accept the Files, and Run the Necessary Commands

Here I’ve taken a small shortcut by inserting a pre-prepared prompt into the Composer chat. My goal was to demonstrate creating a project in one prompt, so I refined it while preparing this article. For simpler projects, a plain description without prior preparation will suffice. For a project like this, you might need 2–3 iterations to fix details you didn’t consider at first. However, with good planning, you can create a complex project in one go.

Working in Cursor versus an external chat requires different query configurations. Cursor interacts directly with the project files, so it needs fewer explanations regarding file structure and response formatting. The external chat, however, only generates instructions to create files in the right directories and their contents. Also, each model has its quirks—for example, reasoning models like o1 often handle large tasks better but tend to "smear" code and comments across the response, reducing readability. You can handle this behavior with additional instructions, but I won’t go into those details here.

The ideal prompt for this project didn’t materialize immediately; the structure of the description played a major role. I broke it into three large groups with detailed descriptions of the required changes to the base project:

**FUNCTIONAL**

- A general description of the project’s functionality and the names of the apps (for Django).
- A description of the homepage’s functionality.
- A description of the publishing workflow.
- A description of the details of Markdown rendering.
- A description of the mechanism for editing published posts.
- A description of additional pages, in this case the 404 page.

---

**STYLING**

- A general description of the desired appearance:
  - Details on colors, spacing, and button styles.
  - Specific CSS requirements (for example, no outlines).
- A description of how Markdown elements should look after rendering: header sizes, code appearance, etc.
- The desired font, which for simplicity is linked directly.
- A note on the necessity of using Tailwind, which is also linked directly in the base template for convenience.

---

**NOTES**

- Additional instructions for editing files.
- A reiteration of details that are important not to overlook (as an extra precaution, optional).
- Specific requests for rendering certain elements (for example, adding `target="_blank"` to links).

And here's the building prompt itself:

**FUNCTIONAL**

- Create a simple, minimalistic, Telegraph-like blog app named **'TapNote'**.
- The homepage will function as a simplistic text editor:
  - Contains only a **textarea** with the placeholder text: *'write in markdown'*.
  - Includes a **'Publish'** button located on the right side of the textarea.
- **Publishing workflow**:
  - When the author fills the textarea and presses the 'Publish' button, the note becomes available via a unique link: `domain/hashcode`.
  - The `hashcode` is a randomly generated string (long enough to handle billions of notes) and must be unique for each note; visually resembles an API key.
  - When a user opens the link, they see the **rendered version** of the Markdown note saved in the database.
- Markdown rendering details:
  - Render Markdown elements into **proper HTML** with visually distinguishable styling:
    - Headers (`#`, `##`, etc.) should be styled with different font sizes and weights.
    - Code snippets should appear in a distinct, styled block; code inside the snippet must be properly rendered, all indents are saved correctly.
    - Ensure all Markdown elements are properly rendered with clear and intuitive styling.
  - **Links and image rendering**:
    - Links in Markdown (e.g., `[text](https://example.com)`) should be rendered as clickable HTML `<a>` elements with target="_blank" – Important!. Confirm during implementation that this functionality is applied consistently to all links in the rendered Markdown.
    - Image links in Markdown (e.g., `![alt text](https://example.com/image.png)`) should display the referenced image.
    - Ensure that both links and images are sanitized during rendering to prevent XSS vulnerabilities.
- **Editing functionality**:
  - When a note is published, generate a unique **edit token** and store it in a browser cookie.
  - Allow the original author to see an **Edit** button when accessing their post if the cookie token matches the database token.
  - Clicking the **Edit** button opens the Markdown editor, pre-filled with the note's existing content.
  - Include a backup edit link (`domain/hashcode/edit?token=unique_token`) for users who clear cookies or switch devices.
  - Ensure that tokens are securely handled to prevent unauthorized access.
  - **404 error handling**:
  - Create a custom 404 page with a minimalistic template displaying only "404" as the title of the page.
  - Explicitly override Django's default 404 behavior by using a custom error view in `urls.py` that renders this template.
  - Ensure the custom 404 page is applied globally across the app.

---

**STYLING**

- The overall design should be **light and minimalistic**:
  - Use only **black and white**— strictly avoid outlines, no grey color, **no borders in text area** , except for buttons and code snippet.
  - Rendered elements should have visible padding
  - Rendered code snippet should have a light gray background
  - Choose the font **Space Mono** for the entire project.
  - Buttons should:
    - Be rounded.
    - Have a light border, no background color.
- Markdown rendering specifics:
  - Titles and headers must have distinct font sizes and weights.
  - Code blocks should appear styled as readable snippets.
  - Ensure all Markdown content looks clean and consistent when rendered.
- Frontend framework: **TailwindCSS**:
  - Integrate Tailwind by linking it via a <script> tag in the header template.

---

**NOTES**

- **Docker restrictions**:
  - Do not modify Docker-related files or scripts.
  - Work only within the **Django codebase**.
- Create all necessary Django apps to support the required functionality.
- Provide all updated and newly created files.
- Follow standard Django project layout
- New apps should be created at the project root level
- Include **commands** needed for maintaining the app (e.g., migrations) in a format suitable for execution inside the Docker container (not on the host machine). Commands must be provided in this chat, not in a separate file.
- **MARKDOWN RENDERING REQUIREMENTS**
  - All links must open in new tabs using target="_blank"
  - Add rel="noopener noreferrer" to all links for security
  - Process both regular links and image tags appropriately
  - Use string replacement after markdown rendering to ensure consistent link behavior
  - Avoid using complex markdown extensions that might cause compatibility issues
– **404 PAGE REQUIREMENTS**
  - Must work in production (DEBUG=False in settings.py) environment
  - Should take over the entire viewport with fixed positioning
  - Must override Django's default 404 page

After sending the task to the Composer chat, wait a few seconds while it creates and populates the necessary files. Then, save them by clicking "Accept" in the file list window at the bottom of the chat, and run the necessary commands.

I want to emphasize the commands. For some reason, Composer periodically gets these wrong. Sometimes it provides commands ready to run in the container’s terminal – in this case, simply click "Run" in the commands window, and they’ll execute. Other times, there are comments in the commands window, and if you try to run them via the button, they won’t execute because the comments get fed into the terminal. In that case, copy the commands one by one and execute them manually. Occasionally, the commands appear without docker-compose and are meant for execution in a virtual environment. In that case, open the container in Docker Desktop, copy and run these commands one by one in the 'Exec' tab.

5. Refresh the Browser Page and Create a Test Note

After executing the commands—and assuming all migrations have been successfully created—go back to the web interface. You can refresh the default Django page if it’s still open, or reopen the site at localhost:9009. You should now see a <textarea> for Markdown and a "Publish" button. Fill in a test note and publish it. All the elements described in the prompt should render as expected, with code and images displaying correctly. In this project, images aren’t stored on disk; they’re pulled from the specified source – in this case, from the demo page of a WordPress template.

Test the editing functionality and wrap up the work on the project.

6. Final Commit

Now that everything is set, you can make the second, final commit. From project initialization to a finished prototype took about three minutes in real time. You can view the project state described in this post here.

During the preparation of this post the Markdown editor underwent some changes and now supports extended markup, even rendering YouTube videos within a post. This project is maintained in a separate repository with detailed instructions for usage and self-deployment.

The project I’ve demonstrated here is just a simple example, showing how quickly you can go from idea to a working solution if you make the most of modern tools. If you’ve long wanted to build your own project but kept postponing it due to the need to get into implementation details – perhaps now is the perfect time to give it a try.

When I think back to just over two years ago, it was unimaginable to consider such an approach to development – back then, copilot-AI could only generate boilerplate functions. It’s breathtaking to see how far we’ve come; and after all, we're only at the beginning of this journey. So when Zuckerberg says that in 2025, mid-level code in Facebook will be prepared by AI assistants, I completely believe it. Because it’s almost here.

Building Telegram Bot with Copilot: Fear and Loathing

Sergei Vorniches — Sun, 19 Jan 2025 23:09:05 +0000

This is a submission for the GitHub Copilot Challenge : New Beginnings

What I Built

My idea was to create a small Telegram bot using Copilot, similar to the many AI-powered bots I've built over the past year. The concept for the bot was inspired by the theme of the competition, "New Beginnings." The bot itself was designed as a generic assistant to help users train and improve their personal growth with AI.

Demo

The bot is available at this link:
https://t.me/motivat1vation_bot

Keep in mind, though, that it's running in a Docker container on my laptop, so it might be offline if my laptop (or I) is asleep. It's better to build your own instance using the repository on GitHub.

Repo

https://github.com/vorniches/motivation-bot/

Copilot Experience

I've been coding alongside AI since the release of original GitHub's Copilot, which predated all the ChatGPT hype. Back then, it was essentially an advanced autocomplete – though it often produced nonsense. That was during the early days of its public beta in late August 2022. At the time, there was nothing like it, and Copilot felt revolutionary.

Then, in late November 2022, ChatGPT 3.5 became publicly available. It was quirky and unpredictable – those early days of testing are unforgettable for anyone who was there. Later, ChatGPT 4 came out, API access followed, and working with AI steadily became more exciting and productive.

By the time GPT-4o arrived, I was writing 90% of my code by simply tasking the AI. It had become a natural way to create software for me, and with the introduction of o1 models, this approach was solidified. Coding became intuitive and almost effortless – but it wasn't always this way.

Looking back to the GPT-4 era, I remember spending hours trying to get the AI to generate something reasonably coherent. I wasted time on tasks that could have been debugged in minutes by reviewing the code myself. Unfortunately, the modern Copilot feels like a return to those days.

If you're planning to try coding with Copilot, your choice of models is limited – either GPT-4 or the better, but still far from perfect, Claude 3.5 Sonnet. With the latter, you can (albeit awkwardly) produce functional code directly in VS Code, but for some reason, it refuses to interact with project files if you start it up there first.

The main advantage of Copilot is that it can edit files.

While it doesn’t always do this perfectly, it’s a significant improvement over ChatGPT, which lacks full integration with the project environment. Unfortunately, that’s where the advantages end.

Debug feels good though

Coding with Copilot often feels like a step back to the "bad old days." Its output seems unpredictably dependent on various factors, and you can’t rely on it to provide a reasonable response to a simple request. You often have to layer instructions on top of instructions just to stop it from modifying files it shouldn’t touch.

What’s most surprising is how inconsistent its behavior can be – what worked perfectly 10 minutes ago might yield a radically different response now. At times, I had to switch from Copilot Edits to Chat mode because it started replacing existing files or behaving erratically.

Conclusion

In conclusion, Copilot offers limited model options, operates inconsistently at the level of a code editor assistant, and provides a user experience that is more frustrating than positive. A year ago, this level of functionality might have been a game-changer. Today, it feels like something you'd rather forget, like a nightmare.

Starting from Scratch in IT in 2024: Things you shouldn't worry about

Sergei Vorniches — Mon, 17 Jun 2024 10:38:23 +0000

Intense competition among juniors, AI taking over jobs, and ongoing crises – why these shouldn’t deter you if you’ve decided that IT is your path, and how hard work and self-belief aren’t just Disney thinking.

In the comments on my previous post about career lessons, many people recognized themselves. However, there were also some reasonable concerns from other experienced developers who had tough experiences on their way. I want to address these and some other concerns that I’ve encountered from people starting a new path as IT specialists.

On Competition

The first concern is the high level of competition. Yes, there are many juniors, and there always have been more candidates than job openings! I was rejected from jobs 100 times more than I was accepted. This is normal and expected. However, what’s truly lacking are adequate people. There’s a global crisis of adequate people. If you can realistically assess your skills and abilities, are willing to learn, and don’t give up, you will find your place in any profession and location. The key is consistency and a willingness to learn. If you don’t get the job but learn from the experience, you improve and increase your chances for successful interviews in the future.

Don’t chase money. While working for free isn’t ideal, if you have an internship with the potential for a job or can stretch your current savings or work part-time, it’s worth trying. Even if you don’t land the job, it’s still valuable experience. Use it wisely to increase your chances.

My first job in test automation paid around $300 a month. This was much less than my previous income from web development, and I searched for it for six months, facing rejections and being ignored along the way. However, I got an offer for my next testing job in just three days, and my earnings nearly quadrupled. This isn’t a universal "success" formula, but sometimes, when you’re on the right path, such things happen.

Yes, competition is high, but adequate people who can learn, adapt, and stay positive will always find their place in the market. Don’t fear rejections – use them as opportunities for growth and to increase your chances of future success.

AI is Your Friend, Not Your Enemy

I understand the concerns about AI in programming, especially from those who haven’t used it. Headlines might make it seem like AI will soon replace everyone. Artists are already being replaced, and coders are next (haha).

Seriously, the most significant change with AI in programming in the near future is that it will become a standard part of the workspace. For example, officially provided by employers, in code editors, and with paid access to services like ChatGPT. This won’t reduce the number of jobs, but being able to work with AI can become a competitive advantage.

As a junior or potential junior, AI can be a great mentor at the beginning. It can guide you on starting projects from scratch, what to do when stuck, help write code, and debug errors. For beginners, if used correctly, AI can accelerate learning tenfold; for experienced developers, it can boost productivity tenfold. Of course, you can’t rely on it 100%, but over time, AI becomes smarter, less buggy, and more useful. I speak from experience. When GitHub released the Copilot beta, even before ChatGPT, I used it. When ChatGPT-3 appeared, I was among the first users. What the latest version, ChatGPT-4o, can do today is astonishing. The key is to communicate with it correctly, and if you lack experience, verify what it provides. Use traditional search and even a second opinion from another AI, like using ChatGPT as the main tool and verifying with Perplexity.ai.

If you’re stuck, don’t know what to do next, and don’t want or can’t talk to real people, AI is your best friend.

What About the Crisis?

When wasn’t there a crisis? There were a few relatively calm years, especially in IT, but that’s over. Overall, crises are beyond your control. What can you do? Focus on what you can change – your life and profession if that’s what you desire.

Many companies hired extensively during the Covid, now, mass layoffs are happening. But there was a shortage in skilled professionals, is it changed globally? No. There's still a significant deficit of skilled professionals, particularly those who are truly capable. Businesses are finding it hard to fill positions with qualified individuals. This shortage of adequate talent means that those who can learn, adapt, and stay positive are in high demand. There are still plenty of opportunities for those who are ready to work hard and develop their skills. Learn, gain experience, go to interviews, and seize opportunities. This isn’t Disney thinking – it’s a principle of development in life. You either develop, improve, and find your place, or give up, make excuses, and change nothing.

If it takes four years to change your profession, what would be better for you – achieving the life you want in four years or remaining the same person in four years, having done nothing? This is life, and you need to take control where you can and not worry about what you can’t influence.

A Little Life Example

If you don't speak russian, the message on the screenshot is from my friend Vlad (name changed), and in this message, Vlad shares with me the joy of successfully completing his probation period at his first job in IT.

Vlad started exploring what he could do in IT just over two years before I received his message in February 2024. Vlad chose a direction and persistently pursued it. Sometimes he doubted himself, sometimes he worried about failing, but advice and words of support from someone who had been through it helped him not give up and keep going.

He studied, went to interviews, faced rejections or was ignored. He learned from this experience and got better until he finally became the person for the job he got. Is this a happy ending? Oh no, it’s the beginning of a new stage, new challenges, and a new path. Only now, Vlad is learning not between shifts at a factory (this is not a figure of speech), but at the job he dreamed of – a Java backend developer in a major enterprise. I don’t know how he knew this was his calling from the start and not frontend like I might have suggested, but that only increases my respect and pride for him.

I, too, tried to get entry-level positions many times and was often rejected. I kept learning until I started getting positions slightly above entry-level. In some ways, it’s even easier for you today – you have AI. AI has concentrated experience and can greatly assist you, providing guidance if you ask the right questions.

Don’t fear competition, AI, or the crisis. The main thing is to be adequate, learn, and not give up. There’s always a place in the world for those willing to work hard and develop.

I’ve worked in IT for over 10 years. Here are 5 things I wish I knew when I started

Sergei Vorniches — Sun, 09 Jun 2024 12:22:22 +0000

Hello, dear Dev.to community. I need to get some things off my chest, so here I am, hoping to share something useful with young IT professionals. Over my career, I’ve gone through freelancing, internships, corporate jobs, career changes, and even launching my own SaaS (a story for another time…). I’ve made countless mistakes and learned some painful lessons. Here are 5 important things I wish I had known 10 years ago.

1. Consistency is Key

There was a time when I doubted everything I did – quality, choices, from direction to tech stack. I switched between technologies, considered quitting what I was doing, and changing careers again. This led to a lack of confidence in my skills, and I often felt deeply demotivated. Add freelancing income and general introversion to the mix – I didn’t even have anyone more experienced to consult to gauge my progress. It was tough – at that time, I mainly built WordPress sites. If I had spent the time wasted on doubts and indecision focusing on one career path, I would have achieved much more, much faster. Choose a path and stick to it – it will yield more results than a broad spectrum of mediocrely developed skills, especially at the start.

This also applies to finding your first job. If you can’t land your dream job or any IT job at first, it’s not the end. Yes, it might take months – even years! But if you feel that IT is your place – keep digging in that spot. Find temporary work to stay afloat. Find cheaper housing, live with your parents if you have to. Buy inexpensive and healthy food (hint: the more protein you eat, the less hungry you feel throughout the day). If you systematically dedicate time to development and job hunting – you will succeed.

2. You will struggle and not understand things – and that’s normal (and it will get better over time, but not completely)

Over time, it will get easier, but the struggle never fully disappears. I skipped classes in university, leaving gaps in my fundamental knowledge of computer science that experience didn’t fill. But that’s not the most important thing. The most important thing is that in your work, you will have gaps in knowledge. Maybe not in a specific job, role, or project – you can learn a project thoroughly, especially if you work on it long enough. But it’s normal not to know certain things about your profession in general. You don’t need to know every processor architecture ever created; a system architect doesn’t need to know specific testing tools. You don’t need to know every Amazon service inside out to create a robust testing system. It’s normal.

3. Don’t cling to a Bad Job

Sometimes you end up in a bad job. Recognizing a bad job is simple – at the end of the day, you want to wrap yourself in a blanket and hide in a corner, and most importantly, there’s no one at work you can talk to about improving the situation. Bad jobs can have various causes – sometimes it’s the team, sometimes the management, sometimes it’s you – not a fit for the role, a hiring mistake, and that’s okay. What’s not okay is clinging to that job. There can be many reasons – no safety net, no suitable alternative, no confidence that a new job will come… and you decide to wait. Wait, endure, drag it out until you burn out completely or are explicitly shown the door, despite your efforts. This can happen at any stage of your career, and you must never let it reach the extreme. If you feel something is wrong, you’re probably right. If you feel a burning desire not to go to work – something is wrong. Cut those ties, or you’ll burn out or grow roots in a bad place for weeks, months, even years, without the strength to change anything. And when the breaking point comes, you’ll face it even more depleted.

4. Frequently changing jobs can be beneficial, but not for everyone

I still see recommendations for beginner programmers: change jobs more often. This way, they say, you’ll gain more experience. A year here, six months there, and in three or four years, you’re as experienced as a senior. This can work. But it’s not for everyone.

People differ in how they can concentrate and maintain attention. If you don’t have focus issues, you can easily work for several years in one place and learn all the processes thoroughly – this will increase your value in the current company and give you stories to tell in future interviews. People underestimate deep understanding, but many positions and companies value it.

Job hopping is also useful, but it can be beneficial for people who struggle to maintain attention when the task is understood. For these people, when surprises at work run out or nearly run out, the job becomes routine, and they might start sabotaging it. If you feel something like this – it might be your case, and you need to jump from the familiar to the unknown. Again and again. Over time, such people become super adaptive specialists, for whom neither a new language nor a new field is a hindrance.

It’s important to recognize in time what suits you personally.

5. Don’t miss opportunities, even if they seem small or insignificant

A career in test automation changed my life for the better. This opportunity was always in front of me. I thought about trying it more than once, even started learning something but dropped it – I thought testing wasn’t serious, and it was bad idea to switch to testing after several years of web development (haha). It turned out I could build a serious career in this field without significant effort. Switching from bar work to web development was a much bigger effort for me.

The same goes for jobs to support yourself. My first web development job earned me $50. I made two WordPress sites – one for $30 and one for $20. It was not bad since I was learning from scratch. All my previous work experience was mostly behind a bar. Though I positioned myself (mostly in my head) as a web developer, I took any job – from writing texts to editing images. My largest single earnings in the first 2-3 years of freelancing were Photoshop editing several thousand movie posters. Three days and three sleepless nights of almost nonstop work earned me $500 – a fantastic result for those times.

And one more thing: Jargon and Abstractions

Much of what you read, listen to, and do can be so confusing and complicated that it becomes white noise. Sometimes one incomprehensible thing flows into another, leaving an unpleasant mark and a sense of limitation. But that’s normal! Once you start untangling the knots of abstractions and realizing what lies behind the terms and jargon, everything quickly falls into place. It may seem like this tangle has no end, but it doesn’t – sooner or later, you’ll understand everything (or almost everything).

Practically, programming forums and technical podcasts helped me a lot. I just read and listened to everything, googling every unknown word and term. At some point, this leads to dozens and hundreds of tabs in browsers on your phone and computer, but eventually, this flow starts to shrink. With each new read tab, you become smarter and more confident in your knowledge, even if it doesn’t seem so for a long time.

I hope this note will be helpful and inspire someone not to fear changes, to seek their place, and not to give up at the first difficulties. Remember, every path is unique, and it’s important to find your own, following your interests, aspirations, and paying attention to your feelings. Everything will work out, but still, good luck.