When debugging an object in Javascript, you usually do something like:

Or even:

It’s so tempting. We have a new idea, a new hobby that’s exciting and the first thing we do is buying something new. It seems necessary at the moment and it’s so easy.

Thirty days after sending my application to Buffer, in November of 2014, I received an email from our CTO back then, Sunil, asking me if I could have a call for the first interview. Two months later I attended my first Buffer retreat, in Sydney. From the interviews with Buffer until now, over four years later, I have the feeling that I work in a unique environment and I want to share here some lessons I’ve learnt so far.

Introduction We can visualize the knowledge about an application as an iceberg where the users will head down as they use it more and more and the UX experts should be in charge of guiding them step by step to deeper areas. This knowledge will allow them to perform actions quicker and more efficiently. On Gmail, for example, you can create a new mail by clicking on the “Compose” button or by pressing the key c.

Many times in our careers as software developers we tend to use the same known tools to do a completely new different project with new constraints. Why do we tend to choose the same tools with small changes over and over again if we have the chance? Abraham Kaplan wrote in 1964 [1]: I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.

After some years working as a software developer in different companies I have used many programs and utilities in *nix environments that I’d like to share. This is not an exhaustive tutorial about how to get the most of them, many options will be just ignored and I will list only how I use them on a daily basis. Text processing I use these utilities to get info from a log or to quickly change a config file on a server.