Every time I learn a new vim keybind it feels like I have a new superpower, even after 20 years.

In general, I’ve paid a lot of attention to “durability” as a metric. How long is the shelf life of the skill? Text editor shortcuts, shell shortcuts and scripting for one-liners, vim, awk, sed, zsh, fuzzy finding tools like sk that I have shell shortcuts for piping results into vim.

The things that have helped me to be a better programmer are the things that have let me better understand the things I build. It doesn’t matter how fast I can churn out garbage. It doesn’t matter how pretty code is if it wakes somebody up at night, so tools related to learning about operational characteristics of my programs are the ones that have made me a better programmer because a program is the thing that ultimately runs somewhere:

• quickcheck paired with fault injection for deterministically replayable machine-generated tests that can avoid some of the assumptions I make while writing the code. avoids the pesticide paradox, so my code never becomes fully immune to my tests. for distributed systems, I pair this with a simulator. I hate writing tests so I really prefer to let a machine generate millions of them for me while I lazily just specify what the program is supposed to do. without a doubt this is the main tool that has improved the quality of my software the most. most bugs are in your error handling code.
• linux internals. kernels are virtual machines and we write far better systems when we’re aware of what the VM underneath our programs is going to do to translate our use of memory, files, sockets and threads into things that happen in hardware.
• gdb, lldb, but especially rr with chaos mode for time traveling debugging of concurrent code. shell shortcuts like this for dumping the stacks of a running process:

  stacktrace () {
    gdb --batch -ex "t a a bt" -p `pgrep $1`
  }
  

• massif visualized through massif visualizer for understanding memory characteristics of a program
• dhat visualized with the built-in web viewer for finding short-lived allocations that could have happened on the stack
• perf for getting stats about instructions, cache misses, branch mispredictions and correlating it back to lines of code, paired with perf report, flamegraph and hotspot for visualization. Be wary of metrics that don’t actually make your important metrics better. More instructions is sometimes still faster due to fewer branch mispredictions. Often the most interesting metrics are max latency per request, minimum throughput for some time period, peak memory usage etc… because they have significant capacity planning implications.
• dstat for visualizing where my system’s high-level resources are being consumed by my programs

The mindset that has helped me to improve my skills is that you should always just roll up your sleeves and look at the running process and its code rather than wasting more than 5 minutes searching for help or pouring over documentation that’s out of date and never correct. Put a short time cap on the time you spend doing that, and then just put on your explorer hat and pull out your scary toolkit to hunt that thing down.

Destroying the notion of “fighting the compiler” was one of my biggest steps forward. I started to view the type checker as a pair programming buddy. One that doesn’t get tired, only states facts based on information it has, and will always update its assumptions based on new information, unlike most of us. ;)

So basically “type systems”, but only after a necessary perspective shift. Well, that and being exposed to what modern type systems can actually do. Instead of the limited assumption that they only catch errors like: “That’s not an Int!”.

I think vim and then later emacs+evil. It’s not often I actually need all the bells and whistles that are not available in emacs, or vim, and when I do I can reach for them, but for the rest of the time I find that vim and even more so emacs are superior environments to work in because I’m allowed to define the environment exactly to my pleasing - which allows a great amount of freedom and creativity - in ways no other development environments I have tried do. It’s a bit like working in your own wood and metal shop at home was being employed somewhere and working in their shop. The latter is just very limiting to me.

Karabiner for me by far. I have access to over 500 actions/hotkeys without moving my fingers at all. Caps lock is too far so is return key. i.e. my return key is mapped to s+f. That is I press s key, then f key. My control key is a key. Most map control to caps lock but why map it to caps lock when you always hover over a key already.

It’s pretty powerful stuff. My config. https://github.com/nikitavoloboev/dotfiles/blob/master/karabiner/karabiner.edn

Probably i3 and/or tmux

I believe iteration speed is a huge factor for programming productivity.

Innermost feedback loop while typing code. An IDE can show me syntax and even some semantic or linting errors immediately. I don’t need to execute something manually. The more checks the better, but it must maintain the “immediately” feeling.

Next feedback loop is building/compiling (if applicable). Fast compilers like D or Go improve productivity here and C++ is one of the worst ones (this is open ended though).

Next feedback loop is unit tests. I find it hilarious that some people skip this step and prefer much slower tests (manual/integration/whatever) instead.

Optimizing these three loops is essential. Ideally, I want this to be one button to press and results within ~2 seconds. Switching tools can help here but what concrete tools does not matter that much.

Disclaimer: Programming is only a part of software development and usually not the most important one to optimize.

1.) Stepping away from an IDE. Being force to learn how to manually execute commands to convert a bunch of text to get run as an executable program shows you so many doors of opportunity to let your curiosity go wild. Going back to an IDE a bit and knowing what’s going on behind the scenes helped me troubleshoot and gave me techniques not available in my IDE.

2.) Forcing myself to use Linux as my only OS at college (around 2008-2009). It sucked at first, but having the doors flung open to OS internals and lots of documentation and command lines (coming from Windows) taught me a lot about how computers work and helped with (1). Important: GNU tools (binutils, coreutils), ctags.

3.) A text editor you can use on limited environments (pick vim or emacs). It helps when all you have to a development server is an ssh connection.

4.) Version control (git). Learning to use git really well helps prevent losing work and allows you to experiment.

Notepad. It’s what I started with, and it’s absolute trash, but that’s why it’s so worthwhile. I’d say that I learnt more using Notepad than I have since, relatively. Not having syntax highlighting, indentation, or anything else made me focus more on the code, as far as I can tell.

Man. Actually reading man pages rather than searching stuff. It’s made me more efficient and made me understand stuff more than I did when I just did a copy and paste.

I think not using an IDE, just using an editor with syntax highlight, made me a better programmer actually. I got used to search and read documentation, instead of just waiting for something to popup in the autocomplete. This process lead to understand how languages/APIs/programs were structured, calling conventions, patterns, etc. Of course, now I use vim and vscode (with vim plugin) but I already have most stuff I need burned into my head.

Version control, even a local repo, it doesn’t mind if it’s git, hg, fossil. Viewing your code history is a great process to learn from mistakes and see how you improve.

It’s good to have some database viewer/browser at hand, sometimes you just need to peek values without having to remember specific database backend quirks (specially when debugging some random error in a system you didn’t write).

Linters are good to keep the code formatted.

A web browser to read other’s code :)

There’s no magic tool to make you a better programmer, everyone has it’s own preference and that won’t make you neither good or bad.

Google and StackOverflow. I remember having stacks of technical books and parsing through results from Altavista + Hotbot + Yahoo! and the various product specific forums I used to have to read. It was not pleasant.

Meetups and other avenues that forced me outside of whatever industry I was working in.

20 years of experience. I am where I am now because I’ve kept learning and failing.

Doubling down on improving communication and mentoring skills. I am where I am now because I can understand what has to happen, communicate complicated issues to non-technical folks and also delegate out small stuff to let me focus on big stuff.

Clojure, Spacemacs, CIDER and emacs for sure.

I have become skeptic as to whether tools have much effect on how good I am at programming. Since I discovered pen and paper, nothing significantly better has come along. Playing with tools is fun, though, which might improve morale slightly.

There’s a single thing, which is not really a tool, that I think made me immediately and permanently a better programmer. When I started dabble in the python community around 2000, there was a strong unit test culture. I’m convinced that unit tests are a silver bullet. Not only is my code significantly better because of them, but I have met many problems that I don’t believe I would have solved at all without a TDD approach. Being more talented would work too, but that’s not something I can really change by my own will.

edit Also, another tool that’s not really a tool is the Inbox methodology of GTD. That is, offloading everything that you don’t need to keep in your head into a trusted system. I never managed/bothered to implement rest of GTD, but that part is a solid and easy one. I could name drop what I use currently, but I tend to change tools around this thing somewhat often, so I cannot yet say I’m married to any tool for this.

Curiosity

i3

spaceship prompt

intellij

Now without these I would be way less structured and productive than I am. It’s not just about velocity of execution, but about abstracting away more complex common operations. Without these tools I wouldn’t have been able to identify such patterns and understand that they were worth their own abstractions.

In a similar vein, also Talon Voice did the same, even though I don’t use it full-time but only when I have an RSI flare

Shell scripting, find, parallel, rsync, awk and sed, as well as their structured-data counterparts like jq and xsv, have allowed me to prototype and explore processing pipelines for data extremely quickly and effectively, even for very large amounts of data. This has come in surprisingly handy surprisingly often.

Next step is having the wisdom to know when to give up on them and write a Real Processing Pipeline with numpy or something.

Edit: Having a basic knowledge and familiarity with relational databases such as PostgreSQL is similar. I’m far from an expert but being able to at least consider a problem and say “Oh, this is a job for a relational database” or “this is definitely NOT a job for a relational database” is very useful.

Vim, tmux, bash, Linux and the whole set of GNU/Unix commands. Maybe not better, but definitely faster and more efficient.

Also, the Rust programming language gave me great insight into deeper/lower level parts of coding.

I’ve been willing to write a blog on this but here’s a short summary

1. Python shell - I’ve been using ptpython and xonsh shells to quickly implement custom data processing pipes as I do a lot of data programming but even if you don’t, python as a shell language is amazing.
   Having access to real time play environment is huge boon for productivity.
   I also migrated to invoke instead of make which is really awesome.
2. Bin - all of the tiny live scripts you sometimes write or your occasional workflows can be optimized and saved. There are a lot of great CLI libraries that make writing CLI scripts a complete breeze so set up your ~/bin with some CLI scripts. Putting yourself in the battle rather than using some mystic one liners from stackoverflow is a brilliant exercise and keeps you in shape.
3. Vim - people talked about this already but editor is really important. Try neovim, kokoune or emacs. A lot of software like Jetbrains IDE’s have vim emulations too!
4. Task managers - you can be an amazing programmer but if you’re unorganized you’ll end up wasting a lot of time. Efficiency is not a swear word your boss uses but your own personal respect for your limited time. I find TaskWarrior to be a brilliant tool for micro tasks. You can do really advanced stuff with it but you can also simple fire it up as micro tasks, see my full blog post on that
5. Debugger and Tests - stop debugging with print statements. Take a weekend to learn your debugger. Personally I really recommend Pycharm’s debugger. On the other end writing tests and code linters can teach you a lot valuable programming info you otherwise wouldn’t stumble upon. I use pytest, flake8, pylint and mypy for python.
6. Your Desktop - finally you need to be comfortable in your machine. Try different desktop environments or even window managers. Keyboard driven window managers like (i3, awesome, qtile) can really boost your navigation. Combine that with rofi as app launcher/context swittcher and a dropdown terminal and you can really feel like flash when you peek at your colleagues with windows or macos environments.

I think those would be my top 6 tips but this is a bit of a blackhole subjects. Soon you start reading about philosophy, psychology and micro-dosing psychedelics, so it’s important to remember not to get lost here :D

tmux is the one for me. It really changed the game for me. Multiplexing terminals has been so crucial in delineating my work. I wear a few different hats at work so its nice to just switch between terminals with ease.

AutoHotKey. I wrote about some of my experiences with it here.

[Comment removed by author]

JetBrains CLion and this Video: Refactoring C++ Code by Arne Mertz

• Various C/C++ sanitizers: ASan, UBSan, etc
• Earlier than Sanitizers: Valgrind (not working on recent macOS due to restrictions incorporated by Apple, but works on Linux)
• Fuzzers: libfuzzer, honggfuzz

I think those are the most influential tools for me, they’ve shown me that it’s nearly impossible for me to write safe code using C++ or especially C, as well as there is no such thing as easy file format parsing code ;)

This question, like others of its kind, depends largely on what you mean by the word ‘better’ and ‘programmer’.

Going by the definition of programmer as somebody who uses computators to solve problems, and that he does so by thinking really hard, and then translate his thoughts into instructions, I would say the most powerful tools are programming languages.

Formal modeling and simulation, especially simple techniques like decision tables, will improve your productivity and also extend value to your customers in the form of reliable, correct software.

my personal IDE is tmux, zsh, clang-format, grep, and vim. I avoid code generation and all those fancy indexing tools. I liken it to walking through a neighbourhood rather than driving past one because you really get a different feel for everything if you slow down and build a working knowledge.

Mastery of the unix tooling is super important. Learn your way around strace, wireshark, gdb, valgrind, netcat, htop, …

Strict type systems, I took a break from PHP around the time 7.0 came out to work on projects with C++, Java and C#. I now primarily program in PHP 7.4, Golang and occasionally Rust and will never go back to a dynamic type system if I can help it.

With extension to this, having an IDE with live Static Analysis helped catch far more bugs that I care to admit.