What I regret not doing earlier as a programmer

Today, looking back, I clearly see three areas where I wasted time – or rather, didn't invest it where it truly pays off.

This isn't another article about how "you must learn the fundamentals". This is an honest reflection on what actually changed my career and what I regret discovering only after several years of programming.

1. Learning the fundamentals – but not the ones you think

For the first few years, I was a typical framework programmer. I knew Rails inside out – all the helpers, gems, conventions. I could set up CRUD for any resource in an hour. I felt competent. Until one day during code review, a senior asked me: "What happens when the server receives this request?"

I couldn't answer. I knew Rails, but I didn't understand HTTP. I knew how to write an AR query, but I didn't understand what happens in the database. I could use Sidekiq, but I didn't know how processes and threads work.

What I regret:

That for years I used ActiveRecord without understanding how database indexes work. Only when I had to optimize queries that took seconds did I understand how EXPLAIN works and why the order of columns in an index matters. If I had known this earlier, I would have avoided dozens of performance problems.

That I didn't understand the difference between processes and threads. When the company started scaling the application, I couldn't participate in architecture discussions because I didn't understand basic concepts. Puma, Sidekiq, memory bloat – it was all magic to me.

That I didn't know the basics of network protocols. HTTP, TCP/IP, DNS – it was all abstraction. When the application started having problems with timeouts and connections, I didn't know where to start debugging. I wasted time googling "Rails timeout error" instead of understanding at which level of the stack the problem occurs.

What changed my perspective:

One day I got a task to optimize an API endpoint that returned data in 8 seconds. My Rails code was clean and elegant. The problem was that I was generating N+1 queries, and when I fixed them, it turned out indexes were missing. I spent a week learning how PostgreSQL executes query plans.

That opened my eyes.

I started reading "Designing Data-Intensive Applications" by Martin Kleppmann. I read PostgreSQL documentation – not Rails gems, but the actual database. I began to understand that a framework is just a tool, but the fundamentals of computer science are universal.

Practical advice: Instead of learning another gem or framework, invest time in:

• Understanding how databases work (EXPLAIN, indexes, transactions, isolation)
• Network basics (HTTP, TCP/IP, load balancing)
• How Ruby works (GIL, garbage collection, memory management)
• Operating systems (processes, threads, I/O)

You don't have to be an expert, but understanding these fundamentals will make every framework and language much easier to master.

2. Sharing knowledge – the biggest growth catalyst

For the first 5 years of my career, I was absorbed in learning. I read blogs, watched tutorials, solved problems. And while I grew as a programmer, I felt something was missing. Only when I started sharing what I learned did my career gain momentum.

What I regret:

That I didn't write earlier. It doesn't have to be a blog – it can be notes on a company wiki, comments in pull requests, documentation for your own code. But for years I treated writing as "something for influencers". I was wrong. Writing forces you to structure your thoughts. You don't truly understand something until you can explain it.

That I avoided presentations and talks. When there was an opportunity at the company to give a lightning talk, I declined because I "didn't feel like an expert". If I had known then that you don't have to be an expert to show something – it's enough to know 10% more than your audience – I would have taken those opportunities much earlier.

That I didn't engage in code review actively enough. I reviewed code superficially, approved without deeper understanding. Only when I really started asking "why?" and leaving constructive comments did I begin learning from others' code.

What changed:

In 2019, I started running internal workshops at the company – once a month, a 30-minute session on a topic I was exploring. The first presentation was about how ActiveRecord works under the hood. I had to read Rails source code, understand Arel, prepare slides.

I learned more preparing that one presentation than during a month of daily coding.

Additionally, sharing knowledge gave me:

• Recognition in the team and company – suddenly people started coming to me with questions, which opened doors to more interesting projects
• A network of contacts – when I started writing blog posts, I met other Rails programmers, which resulted in job offers and collaborations
• Communication skills – I learned to explain technical concepts, which later helped me in conversations with product managers and clients

Practical advice:

• Start small – you don't have to write articles on Medium right away. You can start with detailed comments in code reviews, READMEs in your own projects, notes on company Confluence/Notion about what you learned
• Teach other juniors – it's the best investment in your knowledge. When you have to explain something, you understand it better yourself
• Document solutions – when you fix a difficult bug, write a post-mortem. When you implement a feature, describe architectural decisions

Remember: you don't have to be an expert to share. It's enough to be one step ahead of someone else.

3. Building your own projects – real learning starts outside work

This will be the most controversial part of this article, but I have to say it: working in a corporation won't teach you programming as well as your own project.

At work, you do what you're told. You fix bugs in legacy code, add features according to specifications, attend meetings. It's important and valuable, but it rarely forces you to deeply understand the entire system.

What I regret:

That for years I didn't build anything outside of work. I came home tired, turned on Netflix. I told myself "I code enough at work". The truth was that at work I coded according to others' decisions, in someone else's system, where most of the architecture was already decided.

That I didn't experiment with new technologies. At work I used the same stack: Rails 5, PostgreSQL, Redis, Sidekiq. It worked, so I had no reason to try something else. But because of that, when new challenges appeared (GraphQL, microservices, event sourcing), I felt lost.

That I didn't make my own mistakes. At work, most architectural decisions were already made. I didn't have to choose a database, design an API, decide on directory structure. And it's precisely those decisions – and the mistakes you make – that teach the most.

What changed:

In 2020, I built a simple habit tracking app. It wasn't rocket science – Rails API + React frontend. But for the first time I had to:

• Design the entire architecture from scratch
• Configure CI/CD (GitHub Actions)
• Deploy the application (Heroku, then Digital Ocean)
• Monitor errors (Sentry)
• Optimize costs (cache, CDN)
• Take care of security (HTTPS, CORS, rate limiting)

All these things existed at my work, but someone else handled them. DevOps configured CI/CD, senior architect designed the system, ops team monitored infrastructure.

Building my own project, I had to understand the entire stack.

And suddenly, things that were black magic at work became clear. I understood why deployment takes so long. I understood why certain architectural decisions were made. I understood the trade-offs.

Additional benefits:

• Portfolio – having a working project on GitHub, it was easier for me to pass recruitment. I could show code I can talk about for an hour
• Confidence – I knew I could build something from zero to production. This gave me courage to apply for senior positions
• Business perspective – when I was paying for hosting myself, I suddenly understood why product managers ask about infrastructure costs

Practical advice:

• Don't build "another TODO" – make something you'll actually use. For me it was a habit tracker, for you it can be anything: a recipe management tool, expense tracker, Discord bot
• Deploy the project to production – even if nobody but you uses it. Deployment, monitoring, maintenance – all this teaches more than code sitting on your local computer
• Experiment with technologies – using PostgreSQL at work? Try MongoDB. Using REST? Do GraphQL. Using Sidekiq? Try AWS SQS queues
• Document the process – write commit messages, maintain a CHANGELOG, create documentation. This will teach you good practices that are often lacking at work

It's not about building a startup or making money. It's about understanding the entire process of software creation.

Summary: What I Would Do Differently

If I could go back to 2013 and give myself some advice, I would say:

• Invest in fundamentals, not frameworks. Rails will change, but HTTP, SQL, and computer science basics will remain the same.
• Share knowledge from day one. Don't wait until you're an "expert". Teach someone who knows less than you.
• Build your own projects. Even small ones, even imperfect. It's the fastest path to true understanding.

These three things wouldn't just accelerate my career – they would make me a better programmer, more aware of my decisions and more confident.

You don't have to do everything at once. Start with one thing. Learn how a database index works. Write a blog post about something you learned. Build a small app and deploy it to production.

But above all: don't wait. Don't wait until you have more time. Don't wait until you're better. Don't wait for someone to give you permission.

Start today. Your future self will thank you.