What I didn't learn in bootcamp

by Maxence Robinet
bootcamplearningdebuggingtesting

After several years in tech-and having gone through a bootcamp myself 3 years ago, I know the gap between what they promise, what they teach and the reality of being a developer is huge. Of course, it’s hard to do better in a few months. But I thought a list of things I had to learn by myself these last years to become a more competent and autonomous developer could be useful.

Become a developer

Bootcamps teach you one language, one framework and one approach. You build CRUD apps, maybe deploy them, and check the box. In my case, I was learning Ruby on Rails. But the real world is messier than a rails new.

Here are some of the things I’ve been confronted with after the bootcamp

  • Performance optimization
  • Security concerns in production
  • Observability
  • Dealing with technical debt
  • Comparing multiple solutions to the same problem
  • Making architectural decisions
  • And so on…

This is normal and this is the core of the job. Here’s what helped me to level up as soon as I finished the bootcamp:

  • Understand the Architecture. I stopped treating frameworks as black boxes. I studied how they actually work by going deep into Rails and Ruby. Once I grasp a bit of the internals, everything else made more sense-routing, state, lifecycles, even debugging. The same goes for the internet itself: if you’re a web developer, learn how it actually works.
  • Build Stuff from Scratch. The best way to learn was to build something in the languages I learned. I built two libraries, one in Ruby and one in Node.js. This forced me to think about API design, error handling, configuration, documentation and how other developers might use my code. Years later, I found out one of them is still being used (strapi_ruby). Would I build it differently today? Of course. But it worked, and I learned a ton. Going back to the project recently to update it, I was happy to find there some tests and a CI pipeline - which helped me to continue working on it.
  • Deploy Everything. My rule was simple: every project had to solve a real problem and had to be deployed. I come from the music industry: I built a tool to help music makers and labels to adjust find the perfect distribution of tracks on a vinyl. I built a collection and wantlist explorer for my girlfriend’s Discogs vinyl collection. This killed tutorial hell and taught me about like how to host, monitor, maintain and actually finish things.
  • Own Your Infrastructure. I quickly bought a VPS. I secured it. I deployed projects manually. Then I learned Docker. If you’re a web developer and have never done this-even once-you’re missing out. It taught me more about the full lifecycle than any tutorial ever could. And it’s more economic!
  • Master the Command Line. Learning Bash and Linux commands unlocked a new level of productivity. Yes, we have Cursor, Warp, and Copilot now, but knowing your way around a shell is still a superpower. You won’t have those when ssh-ing into production.
  • Explore Metaprogramming. It’s a rabbit hole, but exploring metaprogramming taught me how languages really work. I wouldn’t recommend it for production code-simplicity usually win but it stretched my thinking and made me more flexible as a developer.
  • Follow the influencers. Go to meetups, workshops, conferences and find influent and knowloedgeable people and follow them. They will help you to learn by sharing amazing resources. Recently, in the Node.js community I’ve been following Matteo Collina and people from the Fastify ecosystem. This is a great way to learn and to get inspired.
  • Don’t get discouraged. It’s really an emotional rollercoaster. You go from the high of having understood something to being confronted with a new problem and thinking it’s impossible, there’s too much to learn. It’s normal. Don’t get discouraged. Take your time. Everybody goes through this.

Debugging: Your Most Valuable Skill

Bootcamps teach you to write code, not fix it. But in real life? Debugging is a big part of our day.

What changed everything for me:

  • Strategic Debugging.Print statements are underrated. So is isolating code, rewriting bugs in simpler environments, or temporarily exposing a route just to test one weird edge case. Don’t be a victim of the codebase - break it apart if you need to. Writing code to reproduce the problem will take you less time than trying to reproduce the problem.
  • Understand the Environment. One of the biggest lightbulbs for me was this: Where is my code actually running? Dev server? CI? Production container? Browser? Knowing this helped me catch dozens of mysterious bugs. Always ask yourself this question.
  • Read More Than You Ask. Instead of asking for help right away, I started reading other people’s code. My reading speed improved. I became way more self-sufficient.
  • Learn to Use a Debugger. Setting breakpoints, stepping through code, inspecting variables -these turned debugging from guesswork into process. Especially useful when debugging tests I wrote myself.

I recommend this little zine by Julia Evans on the subject.

Testing: Treated Like an Afterthought (But Isn’t)

Bootcamps often skip testing, or treat it as optional. But writing testable code makes your entire codebase better. Here’s what helped me:

  • Write tests consistently. Don’t wait until you “know how.” Learn by doing. It’s painful for everyone, don’t think there is a secret path. There are techniques but you need to practice them.
  • Separate concerns. Your business logic is what matters. Test the branching, the edge cases, the validations. Don’t test implementation details like repositories or services. Most important, don’t test your fakers.
  • Use factories. Once I learned how to set up, arrange, and assert data in tests, test factories became my best friend. You want clean, easy-to-write tests and you want set this up in a way that is easy to maintain and as early as possible.

Learning How to Learn

After my bootcamp, I tried to learn everything fast. New languages (Go), new frameworks (Svelte, Astro…), new databases… It was a bit chaotic and mostly useless.

What worked better:

  • Just-in-time learning. Only learn new tech when you need it for a project. Don’t hesitate to try new tools but don’t overdo it and don’t overthink it.
  • Focus on connections. Don’t memorize every syntax quirk: understand how things relate (frameworks, libraries, databases, systems).
  • Zoom out. If you don’t understand the big picture, the details will bury you.
  • AI Tools: Use Them Wisely. AI is now part of my learning process. I use Cursor to experiment with code, pattern suggestions, and in parallel I have Claude / ChatGPT for explanations and discussions or architecture ideas. On my terminal, I use Warp to quickly come up with commands I forget about. Whenever I don’t understand something, I ask AI. If the answer confuses me, I ask again. You always should be able to justify your choices and explain why made you take this decision.

The Professional Skills Gap

Here’s where most people hit a wall: being a developer is only partially about code.

You’ll also need to learn:

  • Collaboration. Explain your decisions. Talk to product managers. Sync with designers. This isn’t just “soft skills”: it’s core to the job.
  • Planning and Estimation. You’ll be asked “How long will this take?”, “What are the tradeoffs?”, “How should we break this down?” You’ll have also to learn how to say “No”.
  • Working in Teams. Code reviews, technical debates, team decisions-you’ll need to play nice, make your case, and know when to let go of the perfect solution for the right one. Also, don’t overestimate the mental burden it is for a team to accept a change in their workflow, the architecture, the codebase, etc. The most important thing is the mental model you share with them: software design is knowledge building as pointed out by Facundo Olano.
  • Documenting Your Work. Your code needs to be understood by other humans. Writing down your decisions, context, and architecture is how teams scale. Don’t explain what you’re doing, but why you do it.
  • Managing Priorities. You’ll juggle bugs, features, meetings, tech debt, and production issues, all while trying to write clean code. Time management is part of the game.
  • Don’t burn out. It’s a marathon, not a sprint. You’ll have to learn how to manage your time, your energy and your mental health. No one will do it for you. Also you can give your time and energy at 200% on a project but ask yourself : does this really bring value? Best case, you realize you could have shipped it at 60% of your satisfaction and could have move on to the next project: there won’t be any reward for the 40% left. Worst case, it will just go unnoticed. This was maybe the most difficult lesson I had to learn, being a bit of a perfectionist. Don’t be a perfectionist, be a pragmatist.

Final Thought: Bootcamp Is Just the Start

Bootcamps give you a foundation. But the real learning starts when you build projects that matter, break things, fix them, and keep going. Don’t be afraid to break things, it’s part of the learning process.

You’re not expected to know everything. No one does. But you are expected to learn systematically. Keep showing up, be curious, and treat every bug, feature, and fire as a chance to level up. Surround yourself with a team that pushes you to become better.

Further Reading