When I first started the 42 Piscine, I was thrown into an entirely new development environment. Coming from a web/mobile background, where I was used to modern editors like VS Code, the transition to Vim felt like going back in time—except no one gave me a guide on how to survive in the past. I had to learn everything from scratch, including C programming, algorithms, and problem-solving.
Struggles and Initial Frustration
Unlike traditional editors, Vim operates in different modes—normal, insert, visual, and command. Since I was coming from VS Code, instinctively tried to save my work with ctrl+s, only to be met with what I thought was a frozen editor. Turns out, in many terminal environments, Ctrl+s doesn’t save but pauses terminal output. Who knew saving a file could be an adventure? Luckily, I discovered that pressing Ctrl+q would "unfreeze" my terminal, and from that moment, I became slightly less terrified of Vim.
Transition from Modern Editors to Vim
However, as I persisted, I started uncovering the power of Vim, and my workflow improved dramatically. At first, I played around with different modes, especially visual mode, but eventually, I settled into a set of commands that made my life easier.
Basic commands
- yy / dd - Yank (copy) / Delete line
- p / P - Put (paste) after / before cursor
- cc - Change (replace) entire line
- Ctrl+r - Redo
- u - Undo
Once I felt comfortable with the basics, I started adding more commands to my list.
My Most-Used Commands
- Everything above, plus:
- G / gg - Move to the bottom or start of the file
- ciw - Change (replace) entire word
- vsp / sp - Open a new file in a new buffer and split window
- :/search_word > cgn > Esc > . - This sequence will replace the next occurrence of the "search__word" word with the replace one
- . - Repeat the last command
- Mastering Visual and Command mode to make bulk edits easy
Debugging in C
One of the biggest challenges of the Piscine was debugging C code. Printf debugging was my best friend, but at some point, I needed a more powerful tool—GDB (GNU Debugger). Learning GDB made a huge difference when tackling segmentation faults and weird logic bugs. Here are some of the commands I found most useful:
- Starting gdb:
gdb ./a.out(after compiling with cc/gcc -g to include debugging symbols) - Running the program:
run(executes the program inside gdb) - Setting breakpoints:
b function_name(stops execution at function__name function) - Stepping through code:
s(executes the next line of code, stepping into functions) - Printing values:
p variable_name(displays the value of a variable) - Continuing execution:
c(resumes the program after hitting a breakpoint)
Using gdb allowed me to visualize how my program executed step by step, making debugging less of a nightmare and more of a puzzle.
Exam Tips
The 42 Piscine exams were tough—you're working under strict time constraints, with no Stack Overflow lifeline. Here are a few things that helped me survive:
- Mastering Vim shortcuts to quickly edit and navigate files.
- Using
manpages to quickly check function documentation. - Debugging efficiently with gdb to track down issues.
- Practicing past exam exercises to get familiar with common problems.
Conclusion
At first, Vim felt like an ancient relic that should've stayed in the past. But after some (frustrating) trial and error, I realized why so many developers swear by it. The speed, the efficiency, and the muscle memory you develop make Vim an incredibly powerful tool.
If you're struggling with Vim, my advice is simple: embrace the chaos, take it one command at a time, and trust that eventually, it will all make sense.