Engineering principles

What I've Learned

Here is a brief list of engineering principles that guide my work

  1. Magic is bad: Today, most of the software development stands in libraries shoulders, everything is shifting to write business logic and import A or B library to solve a problem. But there be dragons inside those libraries. It is ok to use a library to solve a specific problem when it is atomic, replaceable and easy to understand. But some libraries treat you as they know you the whole life and take a lot of decisions and uses a lot of conventions you don't know. They do black magic, black because -often- it is hidden.

    Magic is a feature with non-compositional semantics that succeeds in making the common case easy, at the cost of making the uncommon cases surprising, impossible, or ridiculously complex. Original tweet

    Magic is bad; magic leads you to crazy bugs and a hard to fix and debug code.

  2. Fix the broken window: It is winter, somebody throws a rock and break your window. You don't continue as it didn't happen, you go and fix it, at least with a wood table. But you do something. Broken window principle is an excellent analogy on how software projects lets technical debt take control of their day to day. If you start to solve something and you cross with something fishy, clean the mess.

  3. Duplication is cheaper than the wrong abstraction: Often, abstractions become too complicated and start heading in a wrong direction. It is better to introduce duplication instead of incorrect abstraction, which will save us time and cost. The cost of maintaining a wrong abstraction comes from maintaining the abstraction itself, the workarounds of the code that uses it, and the cognitive barrier that it generates WTF does this function do?.

  4. Consistency: Imagine a brand without consistency in the design. Using one font here, anoter font there, changing brand colors from one page to another. It is difficult to recognize this brand, to remember it. It even looks messy from the outside.

    Now imagine a programming language where there are 7 ways of doing the same thing. i.e: a lambda function in C++. You have to learn a ton of weird syntactical and semantical rules. Only to know which one you have to write to make it work. It adds unnecessary cognitive overhead.

    Consistency in design, in products, in teams make things smoother, easier. 1

    If you have consistent patterns in the UI of a product, adding new features or even new verticals will be easier. The users will no need to learn much more new things, you are only repeating patterns they already know.

    A team that is consistent in the way they work, in the way decisions are made, will become an effective team. It becomes predictable, how would you feel if I offer you to work with a predictable team? And with an erratic one?

  1. The Power of Predictability Howard H. Stevenson, Mihnea C. Moldoveanu, HBR, 1996