In the original Bitcoin whitepaper titled “Bitcoin: A Peer-to-Peer Electronic Cash System” published by Satoshi Nakamoto in 2008, the following quote can be found:

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model.”

Some Spanish-speaking bosses, to get their employees to work harder use a phrase that transliterates into English as “Wear the (firm’s) shirt”. This is a way of asking employees to show their commitment to the firm in one of many ways including but not limited to working extra hours without retribution.

From my perspective, the end-goal of a Software Engineering Manager (or any other Software Engineering Leader) is that the team they serve becomes and remains motivated. My personal approach revolves around being a leader-servant supporting each and every member’s career growth and development. Throughout my career, I have identified three pre-requisites which need be satisfied before any motivational efforts could have a meaningful impact. It is for this reason that I call such pre-requisites, pillars. These are efficacy, efficiency, and vision.

In an age of ever-changing requirements, rapidly evolving technology, and discussions over tabs or spaces, never forget the importance of requirements gathering, framework design, and unit testing. These often involve many players: from the clichéd client who doesn’t know what he wants, the product manager who only budgeted for code production, the lead software development engineer who didn’t account for requirement changes, to the developer who feels unit testing is a waste of time and is eager to start writing code.

I have always striven to make my code maintainable by means of making its logical path obvious. I achieve this in big part by giving meaningful names to identifiers and making functions perform one thing only. Given this, I have always thought of in-code comments as unnecessary: if my code is readable, understandable, and obvious, wouldn’t comments just be redundant?. This is not to be confused with public interface documentation which, more often than not, comes in the form of large comment blocks preceding the definition of the unit to be documented.

The rise of modern high-level object oriented programming languages (e.g., Java, C#, Swift) brought with it the enforcement of single-parent hierarchy and, from my point of view, that was the right path.

Given a non-trivial task with many solution paths, a sensible Computer Scientist, would accomplish it through the path which offers the best time and space complexity balance. A seasoned Software Engineer would also understand that, getting the task done, is but half of the job; the resulting code must also be maintainable. One way to accomplish this is by making the source readable by others and it is thanks to the work of the former that the latter can spend most of its time designing a readable framework to perform a task without having to worry—at least too much—about macro-optimizing their programs.