Ruby Line Noise

Ruby is a nice language but it shares many of the failings of Perl. One of these is with all the symbols it often reads like line noise to someone not fully familiar with the language. This is bad because for a script in the enterprise, pretty much every reader bar the author isn't going to be that familiar with the language. There's just too many choices of language and so the knowledge base is very fragmented.

The absolute worse decision along these lines was the symbolic operator overloading done in the container classes. Now, symbolic operating overloading may be fine as a general language feature to allow for well targeted use cases. You dont really want to be doing "new BigDecimal(5,6).plus(new BigDecimal(1,1))". But if you put shit like "|=" and "<<" in your basic Array class, it only encourages the dimwitted masses who follow to do similar. And because they are dimwitted, they won't pay enough attention to getting the semantics consistent with expectations, they probably won't even write a comment or a unit test, and you end up in a unreadable, unmaintainable mess. But hey, at least its a concise mess, right?

The simple rule here is: favor general readability over conciseness understood only by experts.

Pro Static Typing Argument 1

When you are writing code you are making what seems like one hundred decisions simultaneously on a whole variety of levels, from what algorithm to use to what data structures to use all the way down to what to name variables to make them consistent with the rest of the code base. I think even the best engineers can only keep a handful of these in the front of their brain at any time as "rational decisions", the rest are just taken care of by intuition and habit. Most of the time this works fine, but every so often the habitual or short circuited intuition decision is a bad one. Thus an important criteria of which tools and languages you use are ones that have very slow cost in exposing these errors. I think static typing is one of these tools.

Performance Reviews are not about Reviewing Performance

Annual performance reviews are not about reviewing, rewarding or appreciating every employees relative performance. This is impossible as basically every employee thinks they have performed relatively above average. Rather, they are about shaking out the marginal employees who would quit in the next year if they don't get some status recognition, deciding if the company really wants to keep those employees, and if so giving them a plum. Everyone else gets turnips.

Databases and Refactoring

Perfectly normalized database schemas are an anathema to having well factored code in the long term. The problem is even a simple refactoring like "Rename Column" is a tremendous amount of operational risk, and simultaneous work in all dependent services. The more I have worked in cases like this, the more I favor storing any field which doesn't need to queried on as part of a JSON blob. These are structured, human readable, easily read from almost any type of client, and much easy to put in policies to do with versioning and deprecation without risking an outage.

Dysfunctional Communication

It is often overlooked that dysfunctional team communication can go two ways. Sure, you can communicate too little. But you can also communicate too much and get stuck in a quagmire trying to rank competing intuitions rather than getting things done. You need a "gray space of trust" where individuals can get their part done without needing to fully justify their intuitions.

How Code Is Produced

Naive programmers believe that when they program they are using their "logical proof" part of their brain - the code is a "proof" that can be verified by inspection. In reality they are using their "intuitive pattern solving" part - just building up an imperative map from input to expected output. This is why unit tests are so important. Code without tests is just a hypothesis with no experimental evidence.

Functional Programming

People generally think best in terms of recipes, the imperative. Machines reason best about declarations. Functional programming is based upon the notion that if you limit humans to express themselves to terms favored by machines, then better software will result. This seems misguided.

Fragments Are The Only Form I Trust

The contents here are going to be short and pithy. No stories or anecdotes for comfortable consumption. Because they are short they are going to generalizations, and as such they are going to be something short of the truth. The hope is they contain some truth. They are certainly not nothing.