As a developer in 2016, you need to learn Emacs (or Vi)

by Sebastien le gall, at 15 July 2016, category : Emacs Vi

How to improve your productivity writing code and force yourself to think twice.

This post is not another Emacs vs Vi troll. My point is to explain why (deeply) learning to use a low level text editor is one of the first things any software engineer should do. I have personally chose Emacs because I found common shortcuts easier to memorize. As you will see later, it doesn't matter which one of those editors you like to use, as long as you have learned to use it.

Editors like Emacs may seems old but they have been thought to be productive tools. Shortcuts are optimized with your hands place on the keyboard and the most used key. They let you do your work as quickly as you can think about it but still, they force you to think about what you're doing. Not only they let you learn how to be more productive, they make you understand what you do instead of writing code with crappy CRLF.

Master your working environment.

I often meet developers working on a software or a web application development trying to master the programming language and the framework they use. This is a good idea, for sure. It let you being more productive with time. But, at some point, programming a new feature in your development environment is not enough to get things done. More effective and more comfortable you become with the software code, more features you should be able to design, code, and make run into production. And yet, most of the time, this doesn't go as well as you expected. There could be thousands of management and technical reasons which explain why you don't succeed at getting things done. Obviously, if your company culture is that only one of the lead developers is in charge of pushing new features into production, your possible improvement is limited (And you probably should think about quitting you job). However, most of the time, this is not the reason why you can't push the feature you just get reviewed and validated into production. Most of the time, you just don't want to work (or people don't want you to work..) on the production environment because you don't master it.

So, as (not) expected, mastering your working environment doesn't mean mastering MS Windows. It means, however, mastering your VCS, mastering the deployment tools you use, mastering the server configuration (such as Apache or Nginx), mastering the programming language configuration, mastering Linux configuration and the Linux logging system.

As you probably know, all those tools configuration is made trough text files you need to edit directly on the server. At this point, no chance to open any of the graphical text editors you use everyday. Here is where comes Emacs (or Vi).


read more

Estimation des projets au forfait : la contractualisation itérative, une piste de réflexion

by Sebastien le gall, at 09 June 2015, category : Scrum Agility

L'état des projets informatiques en 2015

Le rapport Big Bang Boom publié en 2014 par le Standish Group met en exergue de façon très pragmatique la principale cause de l'échec d'un projet informatique :

A Big Bang theory for software and information technology projects is that everything needs to come together at once to have a working solution that is universal to all stakeholders.

Il explique, notamment, que sur un panel représentatif de projet IT :

  • 42% échouent purement et simplement;
  • 52% ne répondent pas aux contraintes imposées (coût, délais, qualité, périmètre, etc.);
  • 6% seulement réussissent.

Par ailleurs, ce même institut fait une analyse plus globale de l'évolution des projets IT au fil du temps dans son fameux Chaos report.


On y constate que la réussite d'un projet informatique est un challenge que peu d'entreprises réussissent.

read more