HN’s most controversial topic

In this piece I’m staking out an ambitious challenge in trying to unprovactively examine a topic that has thus far always proven provacative. I know in even broaching the subject, which for many is a sore topic, maybe one that they don’t believe can be resolved through sincerity anymore, I am pitting myself against both the misunderstanding and the entrenched cynicism of all past failures. Nonetheless, I have a point worth making.


Do you really want to read this?

Before we begin, a thought: I’ll be taking a controversial issue, one you likely have strong opinions on, and illustrating its depth. You should ask yourself if you really want to read this, considering what you’ll be losing. By accepting the nuance and grey in an issue you forfeit up the simple joy of conviction, of being the Good Side crusading against the Bad Side. If you’re investment in that joy is something you depend on, this piece will simply be an irritating conflict to you.

What I ask of you:

If you think you do, then prove it to myself and yourself — I ask you to say this outloud, right now, “I want to understand this issue and I’m open to considering the possibility that the people I disagree with are both intelligent and trying to make the world better.”  If you cannot even say that to yourself now, yes outloud, then do not bother reading on.


Now that that’s taken care of I should finally tell you the most controversial topic of news.ycombinator. And that topic has three faces: gender, political-correctness, and truth. It encompasses Damore, but in many ways has roots that spread much further.

Two friends

I’ve interviewed two of my most respected friends — friends who are both intelligent, rational, well-intentioned, and have come to opposite sides of this issue. I expect that they can’t convince you, after all they conflict each other, but my hope is that you, as I, will find an intellectual and moral respect for them as people and finally understand how a clear-thinking person could come to such opposite conclusions.


Bill, who describes himself as “pro-Damore,” has an interesting perspective. In college he volunteered with autistic kids, and spent the better part of a semester trying to teach one young boy to say “ah,” among other developmental steps. “I only got him to do it once the whole time. It was pretty crushing. It was very clear to me that sometimes the progress is so slow it can feel pretty helpless. I have a lot of respect for the women who volunteered there [he was the only male volunteer].”

I bring this up not because it makes him look like a stereotypical “goodguy,” but because I think it informs his larger worldview. When I ask him what his outlook is on autism he says, “Well it’s unclear. Personally, I suspect it’s increasing, even though the data is ambiguous. One in 68 having autism sounds high to me. Were 1 in 68 children autistic in the Roman days? But ultimately I think it’ll get cured, along with most conditions, through science. Probably not just in my lifetime”

My theory is that to Bill, the problems of this world, or at least one problem, is a biological fact that can be solved only through science.  When I ask him why he described himself is roughly pro-Damore he said ultimately for him he feels antagonistic to the attitudes of political correctness.

“I get that political correctness means well. But there has to be a line. Take something super controversial for example, like race and IQ. If you’re too PC to ever even do research, you’re actually going to fail at helping the world. For example, lead poisoning is known to decrease IQ and has been suspected to relate to violent crime. There are still tons of homes that have lead pipes! Even Flint, they never even got rid of the fucking lead pipes there! Because it’s allegedly too expensive. So my point with all of this is that, there may very well be certain patterns in IQ or violence in poor demographic areas, and quite possibly due to something like lead, and this poor area may also predominantly be a minority. But if we immediately assume that every time the words race and IQ come up in the same sentence that somebody’s intent is to argue racial superiority then we’ll never actually fix the biological problem– we’ll HURT the world by try to prove how sophisticated we are.”

I’m not exactly clear how this ties back to Damore, maybe it doesn’t. I ask him about it. “Well look, people said he was sexist for saying the average neuroticism across the group of women is higher than in men. I think the only important question is is it true. If you refuse to believe something that’s true because you wish it weren’t, you’re gonna hurt the world. Problems get fixed with science, and science requires honesty.

When I ask him why he’s so sure about the neuroticism thing he says he read it on wikipedia. I don’t know how I feel about that, but one thing I will say for sure is that I know Bill, his opinions are coming from a place of trying to help the world.



I have a lot of respect for Sam, I’ve always found him to be well spoken. His clarity-of-thought counts for so much actually getting people to understand his perspective. I respect that because it’s easy to get emotional, easy to be passionate, but not so easy to run all the angles and do the due diligence on having a logically consistent perspective.

“No, I wouldn’t describe myself as a Damore supporter, but I also think that there aren’t just two sides to this issue.”

I want to pose Bill’s perspective to Sam, but it’s hard because I’m not exactly clear on Bill’s perspective. I instead ask “Why do you think think Damore was such a contentious topic?”

“Well I think there’s a fundamental disagreement on the power of words. From a legal perspective we’re all entitled to our opinions, but from a social perspective we have pretty strong norms about what can be said. And this is good, because words are actually really powerful.” I ask for clarification. “For an extreme case, what do you think would harm somebody more. Having 20 people tell the person that they are unlikable, or tripping and falling on their face?”

I see Sam has a point, but not really how it relates. I ask what the connection is. “I read Damore’s entire manifesto and he doesn’t say anything sexist. But that doesn’t mean he doesn’t violate norms. Ultimately he made a lot of people uncomfortable.”

I challenge this — “Sure, but sometimes the truth is uncomfortable, surely saying things that make people uncomfortable isn’t reason in-and-of-itself for punishment. Particularly if those things are true.”

He smiles at this. “Well, yes and no. It’s true sometimes an uncomfortable truth must be said. But those who think nothing true can be offensive are kidding themselves. What if a girl at google wrote a piece suggesting male engineers are more likely to be on the autism spectrum (allegedly in support of some HR point)? It may be true, but deliberately rocking the boat like that does have real emotional effects on people and just may get punished.”

I change gears and ask him about whether political correctness can go too far, and mask issues that need correction as Bill feared. He answers, “I suppose that could happen. But I guess I personally don’t see that as a very realistic concern. At least from a broader historical perspective about historical attitudes toward Native Americans and blacks the facts actually didn’t matter that much. At the end of the day the slave owners didn’t care if their slaves were their intellectual equals, it was the social reality they subscribed to let them do what they did. It was the culture and the words. Even if the average intellect of a slave was higher than a slave owner I don’t think that would have prevented the injustices of racism.”

I ask him if he understands how somebody could see it another way, and worry that biological things like lead poisoning could be a larger problem than social things. He says, “Yes.”

Just for get a better picture, I ask him what he thinks of men’s right movements. “I think they really get the short end of the stick. I think that will change though. It’s just easy to associate a group with its most belligerent or intense members and that can put a negative face on a group– it happened with feminists in the 90’s and atheists too.”




Some topics become more clear as you understand them, some topics get less clear as you understand them. I think this is the latter. I cannot say how to compare the ills of social problems against scientific problems, I can’t say whether they are at odds at all.

What I can say, though, is that both Bill and Sam are good people, and I like them both.

disclaimer: I lied, both Bill and sam are actually me. All right reserved.

My Brainf Quine

A quine is something simple to describe yet surprisingly challenging to implement– a program which outputs exactly its own source-code. It is something of a rite-of-passage for an engineering afficianado. For those that consider ourselves one level beyond afficianado we always are looking to up the ante. I took two years exploratory years off after high school, and remember them fondly. Those were the days I could explore anything I wanted. Time was so abundant and problems were so scarce that I’d take on challenges like quines recreationally.

It’s a magical place to be in, when you any path feels possible and no obligations feels mandatory. It’s a time when one’s world-view is fully open, and interesting opportunities seem everywhere. It’s a time before traditional adulthood, where one can feel exhausted by unending obligations (cable bill, health insurance, change my oil, arrange my 401k, excercise more, sleep more, read more, relax more, setup dentist appointment, pickup groceries, return that item, answer those emails to those family members).

Once we’re in the “real world” it can be a challenge to remember that initial feeling of possibility. Once the lionshare of our time is spoken for, one may switch modes from expanding exploration to reduction. A mode where we filter our world into a functional place of checklists and routines to optimize staying afloat when our time, attention, and concern run short and we must ration them.

Anyways, I reminisce. But back in that era, one thing my friends and I would do is make coding challenges for each other. After a friend introduced me to “brainfuck,” a language with only 6 commands all represented as single characters, I challenged him to write a quine in brainfuck. I can see by googling that many other people like us are out there, who, like us, have been to that place where we are hungry for the next challenge to create for ourselves.

Recently I found my quine from back then it brought back memories.




Sopping Wet — Today’s Software Ecosystem Isn’t DRY [and nobody seems to understand or care]

Tl; Dr:

  • Everyone seems to understand DRY is good at the program level, but they don’t seem to understand it at the community level.
  • Examples of useless duplication include many programming languages, libraries, package managers, data-stores, tools
  • This community duplication reduces interoperability and slows productivity across the board

Section 1: Some examples

1. Why is there more than one unix/linux package manager? Do we really need a different package manager with the same commands but renamed for each programming language? Do we really need a distinct package manager for each distro? Rhetorical question — No. We don’t.

2. Nobody seems to admit it, but Php, Ruby, Python, and Javascript are the same language, with a little sugar added here or there and different libraries.  I’m okay if not everybody wants to use curly braces but would rather indent for typing, but I’m not okay with every library for every functionality (date parsing, database connectivity, html parsing, regex, etc) being rewritten as a distinct library for every language when those languages have almost no significant differences.

This leads to a scenario where “learning a language” is more about learning the library than anything else (e.g. “How do timezones work again in PHP?”)

3. MongoDB never should have existedMongoDB should be a storage engine. The concept of a datastore that adapts its schema on-the-fly and drops relations for speed is okay, but there’s no reason the entire data-storage technology has to be reinvented to allow this. There’s no reason the entire query syntax has to be reinvented. There’s no reason the security policy has to be reinvented and all the DB drivers. There’s no reason all the tools to get visibility (sql pro) and backup the database need to be reinvented. Plus, if it were just a storage engine, migrating tables to InnoDB would be easier.

The same point holds for cassandra (which is basically mysql with sharding built in), elastic search, and even kafka (basically just WAL of mysql without columns). For example, a kafka topic could be seen as a table with the columns: offset, value. Remember storage engines can process different variations on SQL to handle any special functionality or performance characteristics as-needed.

4. Overly-specialized technologies should not exist (unless built directly around a general technology). You ever see a fancy dinner-set, where for “convenience” people are offered 5 forks and spoons, each one meant to be used slightly differently for a slightly different task? That’s how I feel about overly-specialized technologies. For example, people seem to love job queues. All job queues should be built on top of a SQL backend so that engineers get the normal benefits

  1. engineers know how to diagnose the system if it fails because it’s a common one (e.g. performance issues, permissions)
  2. engineers can always query the system to see what’s happening because it’s using a standardized query language
  3. engineers can modify the system if necessary because it provides visibility into its workings
  4. engineers can use existing backup, replication, and other technologies to store/distribute the queue (giving interoperability)

Section 2: What’s the result of all this?

  • Senior Engineers are all set back years relative to junior ones (which is bad for senior engineers, good for junior engineers)
  • The ecosystem is set back as a whole (all tools, libraries that interact with the old technology are rebuilt for the new one)
  • The company is placed in a precarious position because it now only has junior engineers in the given technology. Did I tell you that time the place I worked accidentally lost most of their customers phone numbers, because their PHP driver for mongo would convert numeric strings to numbers, and phone numbers would overflow the default integer, resulting in no fatal errors but simply negative phone numbers?
  • The company runs the risk of being saddled with a technology that will be dropped (e.g. couchdb, backbone) and will require a rewrite back to a standard technology or be perceived as behind-the-times.
  • Slow-learning / part-time engineers must keep pace with the changing landscape or face irrelevance. Those that can’t learn 10 technologies a year (a storage technology, a build tool, a package manager, a scripting language, data-monitoring tool, 2 infrastructure tools,  5 libraries, etc) will stumble.
  • Fast paced-engineers will lose half of their learning capacity on trivialities and gotchas of each technology’s idiosyncrasies (e.g. why can’t apache configs and nginx configs bare any resemblance to each other?). Once these technologies are phased out, all of that memorization is for naught. It’s a treadmill effect – engineers have to sprint (keep learning new technologies) to move forward at all, walk just to stay in place, and if you can’t keep pace with the treadmill you get thrown off the machine.


Section 3: The exceptions

There are a few exceptions I can think of when a complete rebuild from scratch was an improvement. One would be Git. In a few months, one of the most prominent software geniuses of our era invented a source-control system so superior to everything else that it has been adopted universally in a few years, despite the intimidating interface.

The times a rebuild is justified seem to be when many of these criteria apply:

  • You’re a known and well-respected name that people trust so much the community might standardize on what you make (e.g. Linus Torvalds, Google)
  • The existing systems are all awful in fundamental ways, not simple in easily-patchable ways. You’ve got the ability, time [and we’re talking at least a decade of support], money to dedicate yourself to this project (git, aws, gmail, jquery in 2006)
  • You can make your system backward compatible (e.g. C++ allows C, C allows assembler, Scala allows Java, many game systems and storage devices can read previous-generation media) and thus can reuse existing knowledge, libraries, and tools
  • You’re so smart and not-average that your system isn’t going to have the myriad of unanticipated flaws that most software systems you want to replace will. For example, angular, backbone, nosql, are all community fails. I theorize Go, Clojure, Haskell, Ruby, and several other high-buzz languages will evaporate.
  • Your system is already built-in-to or easily-integrated-with existing systems (e.g. JSON being interpretable in all browsers automatically, moving your service to the web where it will work cross-platform and be accessible without installation)

Section 4: What can one do?

  1. Learn the technologies that have stood the test of time: linux cli, c++/java, javascript, sql
  2. Wait years before adopting a technology in professional use for a major use-case– let other companies be the guinea pig
  3. Roll your eyes the next time somebody tells you about a new sexy technology. For whatever reason, it’s culturally “cool” to know about the “next big thing,” but professionals need to rise above such fads
  4. Next time you have a brilliant idea, instead of thinking “How great it would be if the entire dev ecosystem adapted itself to use my invention” think “Is there any open-source project out there that can be minimally adapted to accomplish my goal?”

Our obligation as leadership

The talk of importance of values is one irony of the San Francisco scene, if not human nature. The same values are discussed everywhere; so why then is it that these same values seem to be applied nowhere?

Could it simply be that it’s much easier to see the mistakes of others than our own? Perhaps those of us in positions of power often subjected to less scrutiny? Yes, to both of these. And so it becomes our own greatest personal challenge to remain true to our goals when nobody else is checking.

Let’s consider the value of ownership. What does this mean for us? It’s easy to look at the engineers who report to us and think about the times they didn’t take a personal investment in what they were doing, and how that harmed the company.

But for us to be good at our job, we must challenge ourselves to hold ownership, because it’s rare somebody will tell us when we’re not.

So what does ownership actually mean? Well, if an engineer is taking ownership of a project that to me means that she takes personal and emotional accountability for doing the best feasible job she can at it. If it’s broken on production, she is treating the lost revenue like her own.

But what does ownership look like in a manager? To me ownership is no less of an obligation. In fact we have more obligation because we have more influence. We should hold ourselves personally accountable for accurately assessing the merits of our direct reports. If a great manager screws up, he should lay awake at night until he fixes it, just as a great engineer would wake up to fix a production issue. A great manager won’t “good enough” it and wait until the next review cycle to compensate. Us not admitting to an error to save face is no less excusable than an engineer covering up when he breaks the app (which is to say absolutely inexcusable).

Ownership is about caring about the job getting done correctly, at a core level, above-and-beyond what is immediately asked of you. If you see a problem that nobody else sees, ownership is taking it up and ensuring that it gets resolved, regardless of how it reflects on you. Ownership is helping the company and the customer, even if it costs you your job (be that whistle-blowing, disagreeing with an incorrect authority, refusing to do something immoral/illegal).

If you institute an initiative that is clearly ineffective, then you should admit it and withdraw the initiative. Your self-promotion is not a contribution to the company. If you are a great manager, you won’t make it your direct reports’ job to convince you they are great; you will make it your job, your contribution to ensure everyone beneath you is being used to the best of their ability. And if your manager is great, she won’t expect you bring donuts, wear a tie, show up early, or flatter; because it will be her contribution to the company to accurately evaluate your work (and not how much she loves or hates you).

And if, when you hear this, you find it mildly irritating that anybody would ask so much of you… then don’t be surprised when those you lead act as do and not as you say. Your attitude is the irony of the SF tech scene.

Solving rush-hour

For those who’ve been inspired by last programming challenge, I thought I’d give annotations on a programming exercise I’ve created.

The challenge: code an AI to solve Rush Hour, you can play Rush Hour online if you aren’t familiar with how the game works. If you want to follow along, you can find my solution on github.

The game of Rush Hour
The game of Rush Hour(tm) – The objective is to get the red car to the exit. The above picture illustrates one possible board.

Let me start with the high-level thought process.

How to solve it?

The most naive approach is a brute-force solution, trying every move, filtering out backtracking. Some simple math will let us rule this possibility in or out.

The only state in Rush Hour the positions of the cars. Thus the number of possible game states is equal to the number of possible arrangements of cars. We can approximate an upper bound of the latter by multiplying the number of possible spaces each car could move to (this ignores cars being on top of each other, hence upper-bound). In the above board we see 8 vehicles, and each vehicle can only ever occupy 4 or 5 squares [they can’t turn ever] depending if their size). Some boards have more vehicles, so if we estimate 10 vehicles at 5 positions that’s 5^10 < 10 million.  So yes, brute force is in.

The general solution:

Because “brute force” is such a general mechanism, there really is a lot of reusable code in the solution. In my solution I’ve pulled out the reusable logic into genericSearch.js. The idea is that a whole host of puzzles follow the same form: Given an Initial state try to get to End State.

The docblock below is the interface to genericSearch that is used by the solver, but this same search function could be used by any number of puzzles (triangle peg game, sudoku, etc).

Any brute-force can be represented with only these params.

Thus, to write the program (after having written genericSearch.js) all I must do is to make those 5 parameters [and any helpers to go along].

Initial state – Brain Dead Simple

I know a lot of engineers who would be tempted to represent the game of rush hour with at least a half dozen classes (“so we have vehicle base class, which has car or truck subclasses, and we’d need a class for the board and legal moves”).

And that is a valid way to go about it. I went with a minimalist solution– a nested array 36 characters. Brain dead simple.




It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away. — Antoine de Saint Exupéry

Because every car is at least 2 in size, this string notation suffices to convey both the position and bearing of vehicles, everything we need. Since the exit is always in the same spot, that needn’t be represented in state. Adjacent characters of the same value represent the same car.

We have our first parameter, initial state. However, we have skimped in our state, by not defining what a vehicle is or orientation in the state object we’ll have to define that logic later.

Some of the advantages of representing the board state as an array of characters:

  • It’s trivial to serialize. Serialization is key to making sure we don’t backtrack when searching for solutions.
  • It’s very easy to input.
  • It’s very easy to output and debug. At the end to see the solution found I can simply “play” the states and watch the characters move.
  • At any given moment it’s trivial to determine if a space is vacant of any vehicles.
  • Certain impossible board-states are prevented automatically (e.g. a misconfigured initial state could not result in overlapping vehicles).

Some of the disadvantages:

  • We must determine every car on the board and which direction it’s facing. This is non-trivial (let’s call “trivial” something that I code correctly on my first try).
  • Moving a vehicle is kind of “dirty.” By moving vehicles by overwriting the board state it’d be easy make bugs that create weird board states (vehicle with size one).
  • Certain impossible board-states are prevented automatically (e.g. a misconfigured board state could not result in a vehicle with no bearing)
Parameter 2 – Possible moves

Each vehicle may move forward, or backward (assuming its path is unobstructed). To keep things simple, we can say a vehicle can only move 1 square at a time and represent longer travels as multiple moves.

Get all possible moves from this state
Get all possible moves from this state

This definition introduces a few more functions (getVehicles, canGoForward, canGoBackward), which I won’t put into the post. See the full code for that. The reason I exclude them is because I don’t have any particularly elegant solution to those tasks.

Parameter 3 – Apply move

Again I have no magic to work on this one so I won’t show the 15 lines. In fact, it feels like the least dry piece of the code to me, and it makes me want to refactor the most. The number of occurrences of -1 are too numerous (6) and speak to casual coding.

So don’t get me wrong, I don’t want to say anybody should hold this code up as an amazing example of good code. What I hoped to illustrate is how a problem that seems daunting can actually be broken down into 19 functions, the longest being 23 lines.

The Gimmes

I have two functions left. One is how to uniquely represent the state as a string. The other is win condition. The former is easy: JSON.stringify. The latter is easy as well.


And we’re done! Now I’ve left our the genericSearch.js, which honestly was perhaps the most fun, but this post is long enough. If your thirst isn’t quenched try playing around with it yourself.

  • Keep the pure & reusable code in a separate file (or separate function) from your 1-time, implementation-dependent code
  • Maybe 2 classes would have come in handy. Despite being small, the code doesn’t seem as friendly as I’d want. If I had kept state as an object of objects I would never have to define string -> state mapping.
  • Unit tests would have been a good way to allow such a refactoring to be less painful.

Don’t be an Architecture Hipster – A guide

One of my more popular HN comments was a teardown of an all-too-common engineering subculture. The article in question sought to teach “Software Architecture,” but ultimately annoyed me and many other HN readers.

Tl; dr:
Software architecture discussions are so polluted by software-hipsters that the majority of software engineers are disinclined to discuss and study architecture at all.

Know-it-all / hipster

  • Probably studied philosophy, english, film-studies, or engineering.
  • Lurks around discussions, hoping to overhear a mistake, any mistake. 
  • Uses an unnecessarily complex vocabulary
  • Has a self-righteous and loud tone of voice, especially when correcting people.
  • Enjoys correcting people, even on minor/irrelevant points.
  • If asked him a question you can be sure of two things:
    1) he will never admit he doesn’t know
    2) he will answer with so many niche terms that you will end up more confused than when you began
  • He may be likened to Dwight Shrute, or the comic-book guy.

Architecture  Hipster

  • Loves UML making diagrams. Gladly presents them without a legend to people who don’t know how to read UML diagrams.
  • Love creating new unintuitive names for very simple ideas (e.g “Broker topology”). Proceeds to use these niche names in discussions and judges other people for not knowing what a “Broker Topology” is.
  • Gets really into programming fads that are hailed as panaceas but later get tossed out for a new panacea (e.g. microservices, Layered Architecture, REST).
  • Gets very emotionally attached to programming decisions, even if they will have no effect on the user.
  • Loves engineering around unlikely “what ifs…”.
  • Prefers creating abstraction through classes instead of functions, even if no state is needed.
  • Is bored by “practical details” like logging, debugging, convenience, fail-safes, and delivering quickly.
  • Maximizes the number and obscurity of patterns used, leading to classes named things like EventLoopListenerFactory.
  • Only cares about performance if obscure (e.g. tail-call optimization)
  • Isn’t actually very capable creating software (hasn’t won any coding competitions, has trouble with git reset, hasn’t written any software that people enjoy using)


Know-it-all / hipster
 = Architecture  Hipster 
+ software architecture 

I don’t dislike architecture. Architecture is a beautiful study. However, the complexity of the discipline makes an fertile ground for phonies; a space for phonies to use miscommunication as a tool to create an illusion of their own competence.

The “Hello” World

Have you ever been searching for a song on your favorite music service and scrolled through all the songs that matched your search. All of them?

For example, top of the pop billboards at the time of this writing is Adele’s “Hello.” I scrolled for a while and got to at least 1,962 songs named “Hello,” before I stopped scrolling.

It feels like looking into the grand canyon.

A few things are immediately apparent-

  1. All comes to pass. To illustrate, Madonna too is in the Hello list, but her Hello didn’t last; I can’t see why Adele’s would.
  2. The top dog takes it all. Adele’s variant has 250 million spotify listens. Most of the Hellos have < 2,000 listens. Adele’s Hello very well may have more (spotify) listens than all of the other 2 thousand combined.
  3. It’s  harder than it seems. When all the songs you know of are big hits, it can be hard to realize just how many unpopular songs are out there.
  4. This goes deeper than “Hello.” I just picked the top song on the billboard at the moment, but it could have been any songs. Or any poem, or book, blog, or famous person.

And a few things are less obvious-

  1. Why does the top dog take it all? Why do 99% of songs never reach the radio? Are most of these songs just bad? Is it simply that it’s ten times easier to write a bad song than a good one? Or is it that the music industry builds pop celebrities for profit, and radios buy in? Or is it that audiences don’t want so much choice, that we only like a song the 3rd time we hear it so we focus on a few new ones?
  2. So two thousand people chose the same word for their title. Is unique art only a fantasy? From the pool of a million english words, two thousand artists all picked the same one as the title of their song. I know this because I searched by title. How many of these songs share the same key chords? How many of these songs are about the same thing? Artists, like the rest of us, like to think they are doing the unique, but maybe the pool of possibilities split among all of humanity isn’t big enough to allow us each a distinctly unique idea, song title, or life story.
  3. So where do they all end up? There must be at least 80 hours of “Hello,” on spotify. Which makes me think there must be enough music on spotify that I couldn’t listen to it all if I dedicated the rest of my waking life to it. And people are still writing music. Is it just a never-ending cycle of new genres with a small fraction surviving into each new generation with the vast musical history resting in peace at the bottom of our searches? Or do we someday exhaust the unique musical possibilities?



Readable Code: Name Everything

Consider the following code samples.

// Specimen A 

if ($forceClose !== ' ' && $forceClose !== NULL && $issues['forcedClose'] && $forceClose > 0) 
     $this->saveAttrForUser($user, 'forced_close', $forceClose);
     if ($forceClose == '1') 
         Log::saveWrite("App killed");
// Specimen B
// note the prefix 'b' indicates type Boolean, the prefix 's' indicates type String
$bGotValidMessageFromClient = !($sForceClose !== ' ' && $sForceClose !== NULL);
$bAppPassedExitMessage = $aIssues['forcedClose']; 
$bExitWasForceful = ( (int)$sForceClose > 0);
$bAppWasForceClosed = $bExitWasForceful && $bGotValidMessageFromClient && $bAppPassedExistMessage;

if ($bAppWasForceClosed) 
     // A comment here that would mean something...
     $this->saveAttrForUser($sUserId, 'forced_close', $sForceClose);
     $bForceCloseWasAKill = ($sForceClose == '1');
     if ($bForceCloseWasAKill) 
         Log::saveWrite("App killed");
These two samples contain the exact same logic. The former is more direct, essentially it inlines all of the variables in the latter. And that is why it is worse. A variable serves as a unit of abstraction, and a well-named variable is a comment; thus having more variables is better. In fact, all if conditions should the form if ($bSomeVariable) {, that is, never put a complex expression within the parentheses of the if. If the logic is particularly complex then use multiple variables, as seen in the sample above.

All if conditions should the form if ($bSomeVariable) {

At first glance, the bottom example is longer and may look intimidating. But it is superior because it exposes its internal logic. Try deciding what the top code does, and what ‘1’ indicates in that code. Then consider the bottom code. The top is an actual code sample.

And while we’re adding in these extra variables, let’s name our variables clearly. Programmers seem to have some unspoken assumption that variable names need to be less than 10 characters and not have prepositions… Maybe this made sense when you had an 80 character wide monochromatic screen with no form of autocomplete, but technology has made that trend obsolete.  I suspect most people would try to turn the variable name $sLinkToUniversalDownloadPage into something like $sUniversalDownloadLink which is inferior because it is ambiguous (is the link universal or the download universal?).

Or, for example, what would a function named “OpenFileLock” do? Is it opening a lock on a file? Is it filing a lock (in some kind of lock registry)? Is it locking an open file? Each of the three words in the title can be read as a multiple parts of speech (i.e. verb, noun, adjective, etc). Or perhaps FileLock is an existing class in this codebase. Prepositions here would make all of the difference.

Name everything; name it well.

Death By Metrics

‘A little knowledge is a dangerous thing’ – Alexander Pope


TL;DR – Graphs, dashboards, and metrics give a psychological illusion of control and understanding which is usually false and can be worse than no information at all.

Why is it so easy to fall subject to crappy metrics? Let’s consider a story. You’re a project manager and you just got yelled at because the engineering project you manage is already 2 sprints behind. You feel helpless. You asks the engineers why everything is taking longer and they give technical explanations about unknowns that you can’t see at all. You really don’t know anything.

Then something magical happens: you discover you can look at the engineers’ pull requests, and see how many PRs they make each day and how many diffs are in them. You start to look at these and start to notice patterns. Maybe less PRs get done on work from home Mondays… are they slacking off? When all you have is a nail, everything looks like a hammer.

And you just ruined the company. Suddenly you’re wondering why Bob has the fewest commits, why there are fewer PRs on work-from-home Mondays, why there has been a decrease in number of PRs last month. The answers respectively are: Bob is the only one to comment  his code so everybody except him is sped up because of it, sprints start on Mondays and fewer PRs have 1 day turn-around so this biases your results. Everything your one tool might lead you to assume has been entirely incorrect.

Or worse, you decide to evaluate engineers based on their Jira tickets. You have engineers estimate their tickets and then see if they can meet their goals on time. Suddenly you have incentivized your engineers to overestimate tickets, play “hot potato” with responsibilities (“Not really a bug! Ticket Closed!”), not help each other (teaching time just makes you look slower), and not invest in long-term architectural improvements that won’t show immediate benefits.

Or you judge the success of a UI change based on a funnel. In an attempt to get the best open-rate for your marketing email you have somebody come up with various subject lines and pick whichever has the highest open-rate. This is an A/B test. Suddenly you’re sending out emails with link-bait titles like “See what your friend posted about you,” that get a high open-rate but immediately get deleted for being deceitful once opened. Or your new button placement gets tons of clicks because it’s too close to the scrollbar.

Or worse yet, you decide to judge the success of your company based on Monthly Active Users. 
You have your awesome facebook game and have 30 million MAUs. You force all of your users to send out invites to all of their friends and Viola 31 million MAUs! You change your code so that every one of your users must send invites to friends every week. Now you have 32 MAUs. The graphs look pretty convincing, you get promoted. And you wrecked the company. A year later facebook changes the rights to your app so that you can’t spam its users, your users have been pressured by their friends to stop spamming invites, your entire company has become a laughing stock in the gaming industry and is now lampooned everywhere for the rest of its existence.

The common pattern here is  individuals trying to substitute a simplistic chart in place of deep industry experience. It is people with finance degrees changing videogame experiences, MBAs insisting on multiple A/B tests to change an icon, or a non-technical hiring manager not calling a Bill Gates for an interview because he doesn’t have a CS degree.