I have written about engineering being the practical art of tradeoffs. Here’s a sentence I heard recently when talking about costs (paraphrasing): It is very good to use <technology X> when we need to query the data during the development. My caveat was that the sentence was incomplete and should be stated like this: It is very good to use <technology X> when we need to query the data during the development and it’s worth us spending <a non trivial amount of money annually>"

I started to program very early - it was the most entertaining thing that I had going at 13 years old (well that and reading SF of course). And I honed my skills and learned many things very early. As an example, still very vivid in my mind, my TurboC compiler broke at some point and suddenly started refusing to compile a source file. It was a large file (too large: at the time I have not yet formed a good taste on what’s “just right” source file size for me) with a lot of macros use.

In programming, there is no compliance. In programming, there are no cost overruns. In programming, there is no lack of resources (as long as you make sure you have enough memory ;) In programming, there are no business needs. In programming, there are no communication costs. It’s just you, the editor and the compiler. And it can be a heart of the product but it doesn’t scale into a product on its own.

A colleague asked me which Prettier configuration to use so I told him to use the one from that we have used elsewhere and invented the following principle right on the spot: The Principle of Minimization of Small Differences (with a hat tip to Narcissism of Small Differences) What programmer has not been through the discussions on use of parenthesis, brackets, tabs vs spaces, camelCase vs PascalCase, file naming vs type naming, and so on and on and on.

Respect your fellow engineers, programmers, how ever you want to call them: When you stumble on a piece of code that looks bad or just sad, recall that you have no idea under what circumstances it was built. When you are making changes to a module, play within the (often just implied) conventions of naming and formatting. Make your code fit seamlessly - that will make both code review and future reading easier, less jarring.

My father passed away almost exactly one year ago. I wish I had written a longer (longest?) post on this when it was more fresh but maybe some day as I still have a lot of thoughts about him and his life and his end. But right now I want to talk about another thing: a product idea. I had trouble going back to sleep last night and used Headspace to try to sleep.

Imagine you are building a software platform and you have two paths. Down one path you can take on yourself to add every feature you can ever think of. You will have total control over the features and also total responsibility for each of its defects (and there will be defects). The testing matrix of the features grows obviously with every such features and it’s all on you to test it and make sure it’s all compatible with one another.

War is too important to be left to the generals. Georges Clemenceau, upon learning of another military failure during World War I I say this with utmost respect for the engineering profession, to which I have dedicated my professional life. But the idea that “engineers know best” is so foolhardy that I feel I must speak against it, over and over again. An anecdote from years ago: company I was working for acquired another company.

I recently gave a small internal talk about “Don’t be a Blocker” value. This is actually flipped in my mind to “always be unblocking” which is action oriented. This is a brief summary of the talk. To me there are two constituencies to unblock: Unblocking others Three things stand out: Communicating proactively - don’t leave others in the dark Timely decisions and responses - decisions must be made without perfect information Propose alternatives and contribute solutions Regarding this last one, it’s easy to be a roadblock but it’s hard to build roads.

I grew up in an environment where “being the most intelligent” was the most important thing but the way to prove that was in mostly verbal skills of ~bullshitting~ demagoguery. The environment was full of qualifications of being stupid for not knowing something or being stupid for having different opinions - that sort of thing. Everybody was stupid, children especially. Once I realized, much later, in my late 20s, early 30s, that “being the most intelligent” in that sense was holding me back, not allowing me to easily admit mistakes which in turn meant that some mistakes took way too long to be corrected, I started working hard on caring less about “being the most intelligent”.