In this article I will try to detail a bit the choices I made in terms of programming tools and procedures. Those apply to either a pro activity or hobby. Every opinion expressed here is personal, might be entirely wrong. Any valuable input is greatly appreciated. This what works for me, find what works for you. I feel compelled to share this because there are so many tools out there and so many ways to do things that it’s easy to get lost and not get anything done.

About programming languages

Understanding the logic that makes software and having a firm understanding of best practices and design patterns is way more important than the nature of the language you are currently using. I :heart: Ruby but it’s not relevant.

Which text editor is the best?

The battle for the best editor is still raging and many of the contestants have some very strong arguments. Here is an overview of the editors I tried so far:

the oldschool choice for purists and minimalists. It offers the best typing experience one can ask for. This editor is ubiquitous, it’s installed natively on most Linux/UNIX based servers/personal computers thus making it a really safe choice. It requires dedication over time and a willingness to lose productivity temporarily. Also it is the opposite of an Omakase editor: it comes out barebones and one needs to furnish it with a shit-ton of plugins to do even the simple things.

:white_check_mark: Nerd cred ++, powerfullest, everywhere, cool as fuck

:no_entry_sign: Balls hard to master, kinda weird, RSI

is a sibling of VIM. Has a lot of similar good sides but is not as ubiquitous as far as I know.

:no_entry_sign: Also balls hard but not ubiquitous

is a noob-friendly barebones editor which comes with many UNIX systems.

:white_check_mark: Neat name

:no_entry_sign: Feature set very limited, cool factor ~ 0 %

used to be the gold standard of user-friendly text editors because it offers right out of the box a very good typing experience with helpful shortcuts and a clean UI. Sublime Text is written in C++ which makes it pretty fast and reliable. Think of this editor as the father of Atom. The Sublime ecosystem is mature and has a lot of good plugins. It is not as customizable as Atom though.

:white_check_mark: Fast, simple, kinda noob friendly

:no_entry_sign: Not free

the latest contestant on the market and the brainchild of the infamous Github. It took all the right elements of Sublime Text and improved some of those. It feels fresher, comes with a lot of good plugins right-out-the-box and is fully customizable. Keep in mind that Atom is a bit slow on older hardware and can choke very easily on large files.

:white_check_mark: Noob friendly, cool, slick, free

:no_entry_sign: Sometimes Most of the times slow, no workspace settings

built by new-school Microsoft which is nowadays a very good sign. This open-source editor takes all the good characteristics of Atom and gets rid off the speed inconvenience.

:white_check_mark: Noob friendly, cool fast, slick, free

:no_entry_sign: :smirk:

Whatever the editor you decide to go with learn how to use it because it has amazing features that will make your life simpler.

Which shell for your terminal application?

The most ubiquitous shell is obviously Bash. It’s everywhere and offers a lot of things right out of the box. But it’s very outdated and misses a lot of new improvements. To me the best alternative to Bash right now is Zsh which stays close to his ancestors but brings a lot of improvements out of the box.

This is what my screen looks like when I’m working. I like to have my console along my editor which I split because having two shells (or 24) is convenient.

Pragmatic approach to project management

It’s sometimes best to try to go directly to the ‘making’ step and skip the ‘blueprint’ step. The blueprint step is most of the time useless if you’re working alone or in a very small team (<=2). Don’t get me wrong: when > 2 persons are involved in a project then project management tools and blueprints become necessary and it can work great if done right. But for small personal projects just make the first iteration and then adjust your shot, really. My rule of thumb is: if the priority of this project is about agreeing on a common interface (example: API design) then its best to work from the outwards in but on the other hand if this is not the priority then it is way smarter to work from the inside out (ie: start implementing and see where it leads).

This is how 99,99% of side projects die:

  • you’re talking with a friend, drinking :coffee: or :beer:
  • you have a great idea
  • you get excited :tada:
  • you start seeing in your mind how great it could become
  • you start making sketches
  • you start planning features
  • you see the insane potential of this things
  • you start thinking too big and too distant :telescope:
  • you leave the coffeeshop the mind full of stars and extremely pumped (same for your buddy) :star:
  • life goes on :walking:
  • the thing you planned is too complicated even on first step
  • you never do it or postpone so called ‘project sessions’
  • you don’t see results hence the willingness to achieve it dies off
  • your friend experiences the same feelings and gets bored
  • 1 month passes
  • project status: :skull:

Solution: think as small as possible first, don’t overshoot, think short (while keeping an eye on the big picture), make something out of it before it fades away, iterate, iterate, iterate. Also I think the best ‘todo’ list application out there is a simple calendar: enter your tasks in a timeslot so as to make sure it gets done (with a notification), in my experience dedicated todo lists tend to become procrastination cesspools.

“Make it work, make it fast, then make it pretty… and it isn’t finished until it is pretty!” -SQL MVP Jeff Moden (RedGate’s 2011 Exceptional DBA of the Year)

Are code linters necessary?

Writing code is a very tedious activity (programming sucks) and an awkward thing to do, software that monitors what you write and gives you hints on the proper syntax is highly beneficial. For example in the Ruby ecosystem one good linter is Rubocop which enforces a few style rules.

Tests are (sometimes) awesome

Any change (even the smallest) to your codebase as the potential to wreck the whole thing. Having a test suite will save you a lot of time if you plan to make gradual improvements to the project. If it’s a one shot don’t even bother writing one single test.

Prioritizing is the biggest :key:

To be somewhat efficient at what you’re doing you have to prioritize some items over others. It sounds really stupid but it’s easier said than done for some people including me.


Use VIM if you want to dedicate your life to file editing. Use whatever makes you comfortable if not. If you’re a total noob: use Atom Visual Studio Code. Don’t lose yourself in project planning which is just cruft in most cases. Get your hands dirty, do it. Don’t overthink. Within all aforementioned categories the plethora of possibilities is mainly there for distraction, the best tools are the ones you’re comfortable with. What matters is what’s there and how much of it actually works. :hammer: