If you are a programmer you are probably using an IDE to do your work. This usually comes at no surprise since it provides super helpful features like.

• Code assist
• Easy navigation
• API support for your language
• etc

Yet I am here to make a case that you should also master a text editor. When I say text editor I mean the likes of VIM, Emacs, Sublime, NOT Notepad, gedit, nano etc

Personally I am a VIM user as such all my examples will be in VIM.

The reasons are as many as there are developers so I will just give you my top reasons.

Some up points

Shortcuts

Text editors have shortcuts for practically everything you need to do. An example would be ViM which provides not one but three modes: Visual, Command Mode, Normal Mode. Each of them with their own set of shortcuts. You literally never have to use the mouse if you can master its many features.

Avoid Repetitive Strain Injury

In general developers spend thousands of hours every year typing away at their keyboards. Savings of even 10% on time spend means hundreds of hours saved. This hours can mean the difference between healthy wrists and Carpal Tunnel Syndrome

Light

Most text editors have a serious weight problems. But mostly of the good kind. That is they are tend to use modest amounts of the system resources. This makes them quite ideal to use on remote machines. Actually vi a predecessor of VIM is installed on practically all UNIX machines as default package. This means that you can edit files even on machines with small capacity like Raspberry.

Cross Platform

Now I know you probably would argue with this point since most IDEs are also cross platform. But there is always that 10% difference in funcionality. For text editors this is usually not the case.

Not nuanced

Almost all IDEs are custom made for a specific programming language with other languages, if any, added as an after thought. ie PHPStorm for PHP Netbeans for JAVA etc. Text editors are not. Now this may not seem like an advantage, however you are more likely than not working with different language sets and if you are now, you never know if you will be in your next project. Also at times you may need to write plain text. mvc. In such cases a text editor really shines.

Scriptable

No doubt most IDEs provide some form of macro functionality, but they are limited at best. Editors tend to have their own scripting languange vimscript and for editors that run in the terminal, they provide you with full access to the underlying shell. This means you could write a custom bash script to say sort out your csv files

1,$!sort -t',' -k2

This VIM Ex command would sort a CSV document based on the second column.

Look up `man sort

Geek Points

I know this sounds superficial. However anyone who has taken the time to master a text editor is probably a good developer.

Some Downpoints

It would not be fair to say that text editors are perfect, infact they do have quite a number of downsides.

Steep Learning Curve

There literally are 400 page books on some of the most commonly used editors. If you are embarking on learning one, expect to use as much energy as you would use to learn a new programming language.

Not nuanced

Now I know I mentioned this in the advantages but it is also a disadvantage. Typically from PHPStorm application I can start a debugger inspect classes, profile them and so much more that would be a pain in the behind to do on VIM.

Little Syntax Help

This is usually not a problem once you are used to the platform but before then it may make more sense to invest in a good IDE. For pure OOP language like JAVA this may be the only option.

No Templates

Typically IDEs come bundled with all manner of templates for your language. This can help you speed up development and minimize errors. For text editors you are pretty much on your own.

More configuration

I know some hardcore VIM/Emacs users are already critical of the downsides I have provided. So yes to make things clear you can setup quite a comfy environment with syntax highlighting, autocompleting and all other goodies usually reserved for IDEs but it would not be easy at all. Vanilla installation of VIM is practically useless as a primary development platform you need to tinker with your *.vimrc” file before you even write your first line of code!.

Conclusion

Choose a text editor and master it. If nothing else, you will have another tool in your toolbox.

It is our sworn duty as software developers to make sure that our software is accompanied by good documentation.

One of the challenges attached to this task is that the said documentation is needed in different formats. Ie

• HTML for web
• Docs for business guys
• PDF for clients/consumers
• Latex Scientific community etc.

A common solution to this problem is simply to write the Docs in word and paste it to all the other formats. This however goes against the DRY (Don’t Repeat Yourselfy) principle.

Thank fully a well known OOP pattern comes to mind. Specifically MVC (Model View Controller).

Now I bet you never think of MVC over and beyond frameworks however it is actually quite a useful pattern. In our case the documentation is our model the various output formats is our views. For the controller part we have to introduce a new piece of software. Pandoc.

Pandoc is a utility that can be used to convert files from one format to another. See Pandoc

With our swiss knife of conversion we are faced with a storage problem. That is how can we store the documentation. While this is something that can vary based on your own preference, I strongly recommend markdown. This is because markdown provides you with formatting tools without tying you down to any particular enterprise and even more importantly it is very easy to write and read.

Assuming that you have followed my advice, now you only need to write your documentation once in markdown and then run a convert to get all other formats.

pandoc documentation.md -f markdown -t html -s -o out/documentation.html
pandoc documentation.md -f markdown -t docx -s -o out/documentation.docx
pandoc documentation.md -f markdown -t pdf -s -o out/documentation.pdf

Now whenever you make a change all you need to do is update the markdown file, documentation.md and then run the conversions.

Happy documentation.