Technical Manifest

different levels of abstractions that I apply, or people working with me should apply. They are points of views, strong or otherwise, that I personally have about lot of different topics, technical, code-level, architectural, design, process...

These WILL change overtime, and that’s maybe my first principle:

- Things change, a lot, I don’t care, I cannibalize myself many times to look for better software, to improve myself, to meet goals, to meet change. That’s flexibility. You don’t know how is it going to be in the future, so be prepared to rip it off, leverage what you can, and re-invent yourself.

- Don't feel bad if you break things, fix it learn, improve next time. If you don't break things enough, you are not pushing enough (I stole this from someone/somewhere, can’t remember)

- Naming things correctly is extremely important, very hard, but very important. I will spend all the time I need to find the right abstraction, to find the right name. If the name feels weird, don’t use it, it’s wrong.

- Versioning is of extreme importance, this goes beyond our code and bits. Label each deployed version in source and pinpoint that version somehow all the way down to our project planning in all areas. 

- Things should be simple, is easy to do complicated things, true challenge is doing it simple.

- Review UI deeply, get obsessed with it, get strong empathy with your user, show your UI to your mum, explain it to somebody, explain the decisions on the elements.

- Discipline is one of the best virtues to have. Disciplined processes are key to move fast. Processes don’t have to be complex, don’t have to be complicated, but we need a process. It may be on pen and paper, it may be one step, we don’t need to document it extensively, just agree on it and implement it with discipline.

- Documentation is important, forget about the bus hitting you, none wants that, but life changes, situation changes, and you may need to leave for some reason, give simple, important documentation.

- Documentation is not always UML and diagrams (but I love diagrams), on the contrary, the best documentation is well written code, readable, written for who will come after you. Always someone will come after you.

- Don’t take the company hostage, think that everybody can be replaced, but you will not be replaced by holding back stuffs, that prevents progress, you will not be replaced by doing an amazing job, and truly look after the success of the company beyond your own; your own success will come by gravity.

- Test seriously, if you are in the developers world, you are already wired in your mind to think of all possible cases; make your tradeoffs and test all possible cases yourself, don’t defer testing to our users.

- Don’t feel bad for bugs, it’s normal. If I get angry, is not about you, is about the fact that we miss it and some user of our product got affected.

- Sometimes is important to find who’s guilty, most of the time I don’t care, first: fix it, then see why it happens, and do not try immediately to create a mechanism to prevent it from happening in the future, this just adds more complexity and more bugs in the control mechanism.

- Reuse, please don’t copy paste, DON’T.

- Log, log a lot. Don’t debug in production, if logs don’t tell you what’s going on, write more logs.

- Be consistent, don't do everything using a new approach. Be architecturally consistent. But don’t be rigid, use the right architecture for the right problem. Architectures solves problems, don’t solve a problem you don’t have, solve a problem you envision if the certainty of happening is high.

- Spend as much time as you need building your infrastructure, think in terms of moving fast. What you need to build to move fast? you can build a horse carriage fast and you will get some speed, but you can build a plane very slow but get awesome speed, our situation will be somewhere in the middle; think about it and build the infrastructure you need for our case to move fast.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
- Abraham Lincoln

- Try to do the things right for the first time, don’t do it to come back later to fix it, it’s going to cost us more, keep the balance, but think first, think will be cheaper.

- Don’t do unplanned things unless they contribute directly to your infrastructure to move fast.

- Don’t "you have an error, I have an error" is "we have an error".

(…to be continued…)