Money or Truth? The Internet Endgame – An open question

I’m lucky to have had access to the internet for most of its maturation. From the era of geocities to present, quite a number of phases have unfolded.

[Point 1 – Financial incentive is a large part of why the internet is now garbage]

When internet was in its infancy, collaboration was okay. It was certainly slap-dash. You could generally trust what you found on the internet to be well-intentioned if not entirely accurate.

Unfortunately, a number of times money has come into the picture and made the experience palpably worse. The first wave I experienced first hand was the pop-up revolution. Swaths of the internet became borderline unusable (mostly the shadier sections) as ads for gambling, pornography, sweepstakes, etc would exponentially multiply. Technologically, it was easily defeated at the browser level, albeit slowly.

The next problem I remember was the spam revolution. At its worst I would receive nearly a dozen spam messages a day in my yahoo mail trying to sell me illicit medications or dubious products.

What’s interesting about these two is to think how much damage they did to the internet experience to make only a paltry amount (people would send thousands of spam messages for pennies).

The next victim was chat and internet forums. Around this time google’s pagerank algorithm had been publicized, and this lead to mass exploitation of the algorithm by posting unrelated links on all kinds of forums (before rel=nofollow) in order to try to gain influence. Though the other problems I have mentioned were all technologically fixed, to this very day I still get spam comments attempted on this blog.

Next were the “Nigerian Princes,” a whole array of scams executed out of Nigeria relying on the fact that banks couldn’t correctly identify bad checks, even though the necessary public-key-cryptography had existed for decades.

However, all of this pales in comparison to the next set of problems.

The next waves were commercialization of individuals by mass-tracking. Though this had been underway for a long time, it hadn’t hit its stride until at least 2010.

And conversely, hacking. Ransomware (SF Muni was hacked with ransomware, HBO was extorted, numerous individuals) for one. Bitcoin hacks. The influx of money drew an influx of parasites with nothing to lose.

But in my opinion the most insidious form in the one we’re just seeing now.

[Point 2 – a class of people are willing to sell their integrity by dishonestly promoting beliefs and brands without disclosing financial incentive]

Wikipedia has always been a gem of the internet to me. Considering the pool of inputs on the internet (based on the average set of unfiltered comments you’d see on a forum), to take only anonymous internet input and be able to distill and refine to a point of reputability, all without financial incentive, was an amazing concept.

Reddit (and HN, youtube, facebook), similarly, relies on a system of upvoting and downvoting from anonymous members to filter the popular, true, or funny ideas to the top.

Reddit has long been obsessed with idea of the “shill,” a corporate or political account sponsored to promote an opinion online. I think the most common response has been skepticism, most of all because the idea that what’s being said on reddit matters wasn’t really taken seriously.

However, it’s hard to deny now that the shill exists, in light of revelations about Monsanto’s “Let nothing go,” program. Monsanto hasn’t denied these accusations, and hopefully the relevant testimony is fully declassified soon.

 


In the prior cases of financial incentives wrecking the internet, the answer has mostly been technical, but increasingly complicated. The issue of paid dishonesty (false reviews, false claims on discussion sites, false outrage on twitter) seems most complicated of all. For bot accounts, a technological answer is certainly possible (captcha on every twitter login, retweet, like).

But with the Monsanto case, we’re hearing about paid individuals through a 3rd party. One answer might be to make such actions illegal, and offer financial incentives to those who whistle-blow corporate offers (but as a political solution rather than technical, it would be an order of magnitude more involved). The upside of this is it would also be applicable to undue influence on government offices, scientists, wikipedia editors, as well as individuals.

Another notion, if simplistic, is the idea that logic holds more sway than the bandwagon. Certainly not true for all communities, but a community shift away from emotion-laden narratives and just focus on facts could potentially undercut the ability for a community to be swayed. On the downside, it’s this very emotional attachment to news that motivates a lot of people to read it (“Biases confirmed, Knew it.”). Also, on the issue at hand of Monsanto, their are also numerous accusations that they tried to have an undue influence on the scientific research itself.

So the open question is this – is there a structure of forum that incentivizes individuals to approach the objective truth while at the same time resisting influence of an arbitrary number of antagonistic actors?

(To get hypothetical – If there were a truth serum, for example, a solution would be trivial, if impractical. Compel each post to be accompanied by a video of the author of that post drinking the serum and then saying what’s in their post)

 

What is the “Social Justice” Endgame?

With recent controversy over the objective and means of PC-culture, I think it’s time to try to understand the philosophies at play here. As somebody who has trouble making sense of the cultural moment, I’m inviting anybody to ask themselves these questions in forming a clear, consistent vision over how the world ought-to-be in their eyes.

I do this (which I view as the Socratic Method) with utmost sincerity and respect, because I think they are a prerequisite to any useful discussion.

  1. What constitutes a protected group? Some obvious examples may include: race, gender, and the disabled. But what about low physical attractiveness, low class, religious groups, hair color, neurodiversity, age, and all other categories? On what logical basis can one decide whether a trait is a protected group or not (e.g. do they actually need to be a minority? what if men started making less than women, would the social just cause try to reverse this and after how long?)- Follow up: If you stipulated that past oppression was relevant, please clarify how past oppression is to be measured (i.e. Half of the Jewish population was wiped out, does this make them a more protected group than another group? Are there levels?). Also please clarify how long you believe past-oppression is relevant for, and is it only past oppression in the US, or across all of history, or does it even go further back into evolution?
  2. For what careers should protected groups have an equal per-capita representation? We’ve seen a lot of tension about engineering, and there’s definitely a desire to get different protect groups into the presidency, but I sense no hurry to try to gender-balance auto-mechanics. What is the philosophy at play here? Do only protected groups deserve equal representation or are there cases where underrepresented unprotected groups deserve equal representation?
  3. Do you believe your social justice agenda is: A) Objectively fair, B) Subjectively fair, C) Fair isn’t the question ?
  4. Which of these statements should be punishable? Why? Is it the employers discretion?
    – “Statistically cats have lower IQs than people on average”
    – “Statistically, women are shorter than men on average”
    – “Statistically, Asians have a higher IQ than whites on average”
    – “Statistically, women are worse at basketball than men on average, because they are shorter on average”
    – “Statistically, people with down syndrome have lower IQs on average”
    – “Perhaps the reason we haven’t had a president with down syndrome isn’t because of systemic bias, but because statistically people with down syndrome are less qualified on average”
  5. Should left-leaning political statements and right-leaning political statements be equally punishable at work?
  6. Who gets to define who’s a “victim?” Who gets to define what’s “offensive?” Why have I not been included in this process?
  7. If I presented evidence of a group that was more oppressed than blacks and women (yet no less competent), would you consider it a mistake on your part that you hadn’t been advocating for that group?
  8. Should people who change their identification to join a minority group (e.g. become female, black, jewish) merit equal protection, greater protection, or lesser protection?
  9. If a remark may hurt somebody’s feelings, but is true, and relevant, is it protected? What is the philosophy over what is safe to say? Who came up with this philosophy, was it written anywhere, and why didn’t I get input? Is it fundamentally different to say something that is offends members of a protected group versus members of a non-protected-group?
  10. How would you recommend we coexist if I completely disagreed with the groups you identified as protected groups, but with complete sincerity and having put a lot of thought and research into it?
  11. If we took a majority vote, and your answers on all of these questions were found to be incredibly unpopular, would that make you question your beliefs? If not, on what basis do you hope to convince those who disagree with you?
  12. Is guilt, social pressure, and reducing work safety a fair way to drive social progress? If somebody has a contradictory notion of social progress to you, is it okay if they use guilt, social pressure, and reducing your work safety as a means to drive their agenda?

I bring up these questions because I see a lot of negative reaction to how the world is. But what is harder is presenting a superior alternative.

Dishonest interview questions

I’ve encountered my share bad interview questions before. But the one that keeps coming back is “Tell us about a time you made a mistake and how you handled it.”

What I dislike about this question is that it sets us on a path of mutual dishonesty. One my side, if I ever really had just plain pulled a bozo-level failure (e.g. rm -rf’d prod) I wouldn’t dream of mentioning this in an interview [and I can’t imagine anybody who would]. Instead I’d have a prepared response (or make something up on the spot loosely inspired by reality) about how one time I released a bug because it wasn’t reproducible on non-prod environments and how I made us have a post-mortem afterward but how I still feel like I screwed up.

Likewise, it’s dishonest on the employer’s part because they’re asking an indirect question. They’re asking a question about X when they really want to know about Y. They’re presumably actually trying to find out if you can’t admit that you’ve ever fucked up (i.e. some kind of god complex).

My issue with indirect questions is sometimes people who ask them like to play Sherlock. The problem with playing Sherlock is that the interviewee (if he has half a brain) knows you’re playing Sherlock, is going to guess what you’re trying to assess, and then is going feed you an answer you want to hear. So if I think you’re testing for God complex, I’m gonna be kinda harsh on myself over a small error, and insist I dropped the ball, and maybe try to sneak in another example (equally trivial).

It may turn out you’re trying to Sherlock something else (such as whether I am lying to you) and you may or may not be wrong about it. Or really anything else. But when the question is opaque and indirect, the candidate has no opportunity to correct your misinterpretations.

One might naively accuse me of some form of dishonesty here, but I think that can be dismissed easily. Is anybody truly asking an engineer to pick 1 random failure? Would an engineer truly ever do this unfiltered?

Ultimately, the question is filtering for good BS-ers, who can read the interviewer and fabricate a story that is both plausible and likable on the spot.

My Brainf Quine

A quine, a program that’s output is it’s own exact input is a rite-of-passage for an engineering afficianado. For those that consider ourselves one level above afficianado we always are looking to up the ante. I took two years off after high school, and remember them fondly. I could read wikipedia all day, program anything I wanted, explore freely.

It’s a magical place to be in, when you any path seems possible and nothing seems mandatory. It’s a time when our world-view is fully open, and interesting possibilities seem everywhere. It’s a time before we get overwhelmed by so many obligatory minutiae (cable bill, health insurance, change my oil, arrange my 401k, excercise more, sleep more, read more, relax more, pickup groceries, return that item, answer those emails to those family members) that we find ourselves overwhelmed and instead of branching out we try to reduce our world. It’s a time before we filter our world into a functional place of checklists and routines to optimize staying afloat, a time when we are so unencumbered that we needn’t even ration our attention or time, and thus can float through the trivial obstacles (traffic, distractions, unforeseen obligations) of life with an interest in these new challenges rather than a resentment at a ceaseless set of obligations.

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. There is too little code reuse in the software community.
  • Examples of useless duplication include many programming languages, libraries, package managers, data-stores, tools
  • This community duplication means engineers have to learn different interfaces to nearly identical systems and reduces interoperability of tools

Section 1: Some examples

1. Why is there more than one unix/linux package manager? Do we really need a package manager with the same commands but renamed for every 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 log part 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. Those that can learn say 20 technologies a year spend their time learning things about these technologies how their config files work, gotchas and bugs, how their performance scales, how to understand their logs, but then 75% of this progress gets undone as these particular technologies get phased out. It’s a treadmill effect – engineers have to run (keep learning new technologies) 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, 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 beta it for you and file all the bug reports.
  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.

Connect 4 – illustration of Matrix rotation in js

Once in an interview, I was asked to determine whether a somewhat filled in connect 4 board has a winner. Here’s an elegant solution using an arbitrary rotation function: Rotate the board 0°, 45°, 90°, 135°, and check for 4 in a row in each of those rotations.

Since I couldn’t find a good rotation solution online I decided to post a solution here (javascript):

var _ = require('underscore');

var rotateArray = function(array, degrees) {
    var radians = degrees * Math.PI / 180;
    var round = (f=>parseFloat(f.toFixed(13)));
    var coordinates = _.flatten(array.map((row,y) => row.map((value,x)=>({value,x,y}))));
    var translatedCoordinates = coordinates.map(spot=>({value: spot.value, x: round(spot.x*Math.cos(radians) - spot.y*Math.sin(radians)), y: round(spot.x*Math.sin(radians) + spot.y* Math.cos(radians)) }))
    var rows = _.chain(translatedCoordinates).groupBy(x=>x.y).values().sortBy(x=>parseFloat(x[0].y)).value();
    return rows.map(x=>_.pluck(x,"value"));
}

var hasFourInRow = function(array){
    var vectors = [0, 45, 90, 135];
    var matrixToString = (m => (m.map(r=>r.join("")).join("\n")));
    var versions = vectors.map(degrees => rotateArray(array, degrees)).map(matrixToString);
    return _.any(versions,(b=>b.indexOf("****")!==-1));
}

And to illustrate the use, here’s sample test cases:


var testCases = function(){
    var win1 = [['*','*','*','*'],
                [' ',' ',' ',' '],
                [' ',' ',' ',' '],
                [' ',' ',' ',' ']];
    var win2 = [['*',' ',' ',' '],
                ['*',' ',' ',' '],
                ['*',' ',' ',' '],
                ['*',' ',' ',' ']];
    var win3 = [['*',' ',' ',' '],
                [' ','*',' ',' '],
                [' ',' ','*',' '],
                [' ',' ',' ','*']];
    var win4 = [[' ',' ',' ','*'],
                [' ',' ','*',' '],
                [' ','*',' ',' '],
                ['*',' ',' ',' ']];
    var lose1 = [['*','*','*',' '],
                 ['*',' ','*','*'],
                 [' ','*','*','*'],
                 ['*','*',' ','*']];

    console.log([win1,win2,win3,win4, lose1].map(hasFourInRow));
    //outputs true, true, true, true, false
}

testCases();

Stories, and Meaning [at work]

Tl; Dr: All people are motivated by meaning of their work. The ability to shape the “stories” that we tell ourselves gives meaning and thus is an essential motivational tool. This meaning is also key for personal satisfaction.

Let’s consider a standard engineer. There are a lot of “outlooks” this engineer might have. I’ll go over 5 out of thousands of possibilities just to illustrate some variety:

  • I’m the star engineer here, and I’ll turn this place around. Others might not quite see it yet, but it’s only a matter of time.
  • I’m a great engineer but nobody appreciates my work. How come that other engineer got promoted, I don’t think their work is as good as mine. I should run the company, the CEO is only CEO because he has blue-blood 1% investor friends. The world is rigged against me.
  • I’m so excited to be an engineer. I earn multiple times the median household income and I get perks too, while my other friends are still paying off their college debt.
  • Work’s good. It’s just a job though.
  • Why am I always the one under pressure? Nobody ever thanks me no matter how hard I work. Why do I get mistreated? I’m such a victim. It’s not right.

What I’m proposing is that the same engineer having the same experiences could retell that same experience in any of the ways I listed above.

In fact, you’ll find that a lot of people gravitate towards common narratives. I have a friend, let’s call him Fry who always sees the same story: The big guy is mistreating the little guy. One thing I learned quickly was that he liked and actively chooses (if not entirely consciously) to see the world in these terms. And if I want his help, I can motivate him by giving him a rebel story he can play a part in.

For example, if I’m trying to create a new tool, I could tell it in a way that plays up the opposition, especially if it’s an entrenched “senior” group that’s cautious about new ideas, and it’ll make him want to help.

Everybody has a narrative or two that resonates with them. I have another coworker, Bender, who always promotes the story: People are stupid. I know not to try to change his story, because it’s a choice and likely inspired by some very frustrating life experience (I imagine those frustrations are valid, albeit rather long-lived). If I need him on a PR I can ask it in a way that implies I need his expertise. That way he act can out his fantasy of undoing the damage of incompetent/indifferent through the act of improving my code. A win/win.

Sometimes these narratives are just plain counterproductive. I can think of experiences when teammates were annoyed that some “undeserving” party “stole credit.” In these situations you can try to rewrite the narrative, though it takes a certain skill. One way to accomplish this is to bring up an opposing narrative like, “Yeah so his name was mentioned in a meeting big deal… I don’t do great work so some manager can mention my name, I do it because there are literally millions of users who are experiencing what I make and I think I’m lucky to be able to be in a position to help so many people. That’s something I can be proud of.” [And as an aside their is no duplicity in this. It is our choice whether to aim to “do good” or to accrue material. Each philosophy has its upsides.]

And the fact that people are choosing to live these stories is an important fact. For a long time, I would have thought doing this type of thing was “manipulative” or “tricking” people into work when I could instead explain to them why their underlying narrative was too black&white. But knowing that these narratives are choices, with symbolic importance, that give meaning to the individual who holds them, I see now that people choose to live these stories hoping to “play them out.”

And most importantly, we all have narratives. Mastering other peoples narratives is a great tool, but mastering your own is probably more important.

———

Part 2.

If you’re a leader in an organization, you need to be aware of the stories that occupy the minds you oversee. Do people see themselves as battling each other for recognition? Do they see themselves as allies against a great evil? Do they see themselves as victims of your rule?

People within the company all have their narratives, and those attitudes are contagious. Your actions will have a great role in deciding which attitude wins out.

I’ve seen organizations torn apart by leaders who were out-of-touch with the effects of their actions. The cultural effects you have are of supreme importance. Actions like requiring engineers start an hour earlier, for example, are incredibly dangerous, because they give room for the narrative “We are seen as code monkeys” to thrive.

To win this battle you must understand the narratives that you are battling against. You must truly understand them, you must know and appreciate the day-to-day of your workers. For example, you must know that your Office Manager Lela is frustrated, sleep-deprived, is wondering where her life is going, and is starting to feel like the “manager” in her title is meaningless. When you know the people you work with you’ll know what stories are compelling to them. When you understand, you will be capable of offering the service of arming them with a better story, a brighter story, a more compelling story. Because as bad as Lela’s life is, it’s better for everyone if she feels like her work matters at the end of the day.

This is your value.

The Professional Web Codebase

One of the major advantages of the high career mobility in SF … Cross pollination. Yet each new codebase I comes to seems to lack a few of the following. So I figured I’d list out the essentials that every web codebase should have.

  1. The Obvious: Git, IDE, MV*, relational DB, 3 environments that match production.
  2. Language regularization:Each language has its own idiosyncrasies. Learn your languages weakness and make helper functions to accommodate. In PHP, these weaknesses include single-threaded, bad undefined index default behavior.My preferred solution to PHP’s single-threaded limitations is to make use of a job queue. This will emulate additional threads for heavy tasks (e.g. sending emails to all of your user base) or high-latency tasks that ideally should be asynchronous (e.g. certain API calls). I’ve seen this done well, and I’ve seen it done poorly. From experience, I’d point out the following lessons: don’t use a message queue as a job queue and the DB is a great place to store a home-grown job queue [because it provides great visibility, resilience, can be controlled programatically, can be exported to disk, is atomic, etc].

    In PHP, out-of-bound reads on arrays return null and log a notification to the event log. As this is never the engineer’s intent, I always write two helper functions. One that looks up an key and returns a specific value if the key isn’t found (for cases where you’re using the array as a set). The other function looks up the key and returns an exception if the key is not found (for normal cases where the key should always be present).

    I strongly believe once you handle these edge cases most popular languages are pretty interchangeable (javascript, java, php, python, ruby).

  3. A powerful, generic staging environmentOne of the most impressive and useful technologies I saw was something we called humblebrag. It was a script that caught all requests to *.company.com/…. It then took the *, checked-out the corresponding git branch, and mapped the request to that particular branch. Thus in effect, we had a zero-effort way to have all branches usable simultaneously on a single server, even by non-engineers.Doing this can be a little harder in more complex environments with versioned services listening on ports, if you don’t plan for it early.
  4. A circuit breaker. Download one from github.
  5. An ability to do cross-server mutexes.
  6. A simple, generic read-through-caching function.
  7. A powerful logging system connected to an alerting system
  8. An A/B test system. Even if you’re not doing A/B tests on user-experience, it can be a great way to rollout to a small portion of users or internal-testers to ensure stability on a new environment.

 

 

Understanding engineers by understanding authors

I’ve written before about the challenge it can be for non-engineers to understand engineering work. I’m not the the first to observe that the non-technical need a metaphor to understand invisible and often abstract output an engineer creates. Traditionally, that metaphor has been physical engineering/construction. Others have already, and rightly, criticized the physical labor metaphor.

Instead of ridiculing the wrong metaphor, I offer a substitute. I posit this: To understand engineers, think of them like writers.

to understand engineers, think of them like writers.

Why is this a good analogy? It explains several aspects about engineering that otherwise seem downright unreasonable.

  1. Emotional attachment to work
    Like an author, many engineers see a work project as an opportunity to exercise their creativity and build something the take pride in. Like an author, engineers develop a sense of owning what they create. If the project gets cancelled, handed-off, or drastically changed (especially without notice), compromising their artistic vision, the engineer may experience frustration. But this is natural, how would an author feel in such situations?
  2. Difficulty in measuring progress and estimation.
    If software were physical construction, it might be reasonable to have an easily-predictable timeline. One might confidently answer “how far along are we?” But like writing, and unlike construction, everything one makes in software is new. And like writing, progress can’t merely be measured in the amount typed, refinement and reduction are actually an important and lengthy part of the process.
  3. Ambiguity and subjectivity of excellence
    Every week somebody writes a blog post on how to find out in an interview who’s a good engineer. And every week it gets (rightly) torn to pieces by commentators. The fact of the matter is that there are many independent components that comprise engineering talent and measuring them is very difficult. Even among the very best stylistic difference might mean two greats may not appreciate each others’ virtues, like Faulkner and Hemmingway.
  4. Challenges of collaboration
    And on that note, collaborating can be hard. Like writing, there are an indeterminate number of ways to write software, but each engineer has a style. I can tell you from personal experience that writing software with other people is hardBoth want a sense of ownership and freedom to express their creativity, but must now answer to the confines of the project itself as well as their partner (or team’s) creation. Imagine a group of professional writers trying to work together, of varying cultures, varying talents, varying dispositions, and varying skill-levels. With no objective answer to many issues, engineers reviewing one another’s code is a touchy topic.
  5. A need for freedom
    As a creative endeavor, software’s workflow can be unpredictable. A creative solution may come at any moment, often in the shower or a dream. Sometimes, when all the factors align, answers comes pouring out at a great pace. During such times, the absolute worst thing that could happen would be an interruption (or a required meeting). Compromising on artistic process will compromise the product.
  6. It’s not work
    One of the most persistent and most damaging misunderstandings I have witnessed is the erroneous perception that engineers will avoid work if they can “get away with it.” Perhaps those who feel this way think of engineering as labor, as if it were physical construction. But writing code, like other writing, is a passion that cannot be avoided. When I go on vacation from work I always end up recreationally writing code within a week. I can’t generalize for every engineer, nor every project. Like a writer, if an engineer really doesn’t believe in her work for moral reasons or is so constrained she has no space for creativity then she may lose motivation.
  7. Can we rewrite?
    Another commonality is that due to stylistic differences, every individual prefers their own way of writing things. (And to be clear, in software there is a lot of room for styles, styles that are often so unique that one can often tell who wrote code just by reading it). Each considers her own style clearer, cleaner, or better; often because it aligns so directly with her own thought process. Learning to compromise on this a key skill.
  8. Some produce more than 10 times another
    Is there any number of E.L. James that could produce the Great Gatsby? For specialized work (e.g. advanced problem solving, revolutionary user experiences) there’s just no substitute for a prodigy. On the other hand, if what you’re making is the software equivalent of a gossip magazine, having Shakespeare on your team might actually be a recipe for failure.

I want it to be clear that I’m not saying all engineers automatically deserve to have any project that they work on adapted to conform to their artistic whims. I am advising all to be sensitive to the pride and passion that people put into work.

But most of all I’m trying to help people understand engineers. It can be hard to relate to an engineer who expresses slight negativity about meetings, blows off people who check-in on them, never knows how long their work will take, doesn’t like standard schedules, might prefer to work alone, gets disappointed when their work is shifted, or thinks they’re amazing. So if you care to understand and relate, I’ve given you the tools.