As a general rule, I'm skeptical of personality typing systems. I badly want them to work, but for most of them, I'm not persuaded that they provide any more insight into your personality than looking up your zodiac sign.

But I admit I found this book... intriguing.

In short, her thesis is that there are two types of motivation: Internal Motivation and External Motivation. People broadly fall into 4 categories: Those who respond to Internal Expectations, those who respond to External Expectations, those who respond to both, or those who respond to neither. Which category you fall in is a big part of your personality, and very influential in how you go about accomplishing your goals

I suspect that a lot of the Personality Types she builds around them are bogus, but I still think there's something to that dichotomy of motivation. It's something which I've found helpful in understanding myself and the people around me.

For example, she talks about how, if you respond to external motivation, its important to have accountability in order to achieve your goals.

"Accountability" is a weird idea to me. I genuinely don't understand what it means, and I privately doubt that it is a meaningful concept at all.

I understand "Responsibility". I think its hard to underestimate how important Responsibility is. But when people talk about "Being accountable for this deadline" or say things like, "We need to hold each other accountable", I mentally replace "Accountable" with "Afraid of being punished"

And yet, many people around me seem to consider Accountability a positive thing, a thing they embrace and that helps them achieve their goals, in way that means something much more positive than "I need to be afraid that somebody will punish me if I fail before I can be motivated"

Come to think of it, "Motivation" is similarly weird to me. I don't think I've ever even experienced this thing called "Motivation", and again, I privately doubt that its a real thing at all. I simply do.... what I want to do. If there's something I set out to do, and then don't do it, I assume it was because I didn't really want to. I examine my reasons for not wanting to, and ask myself in hindsight if they were good reasons, and whether I should re-evaluate my priorities next time. (I admit, the reasons I want to do things aren't just momentary impulses. I also want to hit long-term goals and want to honor the obligations of love and gratitude to the people around me)

And yet, motivation appears to be a very important thing to many people, and a huge component of what drives them towards their highest purposes.

I feel like Gretchen Ruben's system gives me a key to understanding these odd concepts. People who value things like accountability and motivation are those who respond strongest to external expectations.

It's just a quiet little increase in my understanding. It's a reminder that ideas which don't seem useful to me might provide a great deal of value to someone else.

I think that made the book worth reading.

In conclusion:

The Motivation

As a favor to Amy, I put together my best investigation of the question: Are there any legitimate safety concerns around the COVID vaccine, especially for women who are either pregnant or hoping to become pregnant (sorry, no news yet but... pray for us!). I thought the investigation might be of interest to other people in my circle

Everything around COVID has gotten so political that it's become hard to find non-partisan information. There's a big contingent in my own circle (Orthodox Catholic, red-tribe leaning) which is very concerned about the safety, effectiveness, and ethics of the vaccine. Do they have a point? It's awfully hard to tell, and its not made any easier by how the blue tribe seems to prefer ham-fisted propaganda and assertions of "Trust Science!" rather than making actual arguments based on numbers.

So, this is my best, honest attempt to weight the arguments for and against the safety of the vaccine across the internet. Note, I'm limiting the scope of this to the safety of the vaccine, with an emphasis on the safety for soon-to-be mothers and their developing babies. I know there are another set of worries about the effectiveness of the vaccine on the internet, and I'm not addressing those, at least not in this article

The Evidence For

It seems that the main source of hesitancy about getting the vaccine while pregnant came from the initial months the vaccine was available. The CDC held off recommending it for pregnant women because there was no data yet on how it affected pregnancy. Pregnant women were excluded from the initial trials, because it wouldn’t be ethical to give the most vulnerable people an as-yet unproven medication.

However, lots of pregnant women did choose to get the vaccine as soon as it became available! And the data from following them looks pretty positive.

https://jamanetwork.com/journals/jama/fullarticle/2784193

This one just scanned medical records systems, and was able to track 105 446 women in the first 20 weeks of pregnancy. The key finding, best I read it, is that of the women who miscarried, 8.6% had received the vaccine during the period they watched compared to 8.0% of those who didn’t miscarry. At first, this looks like a small but significant risk of miscarriage. However, the population which received the vaccine was older on average, and once they adjusted for that, the risk disappeared.

Zuache et al: https://www.nejm.org/doi/full/10.1056/NEJMc2113891

Shimabukuro et al: https://www.nejm.org/doi/full/10.1056/nejmoa2104983

The next two draw on data from the CDC’s v-safe program. It appears to be a program where, after receiving the vaccine, you could volunteer to track your health by filling out a daily health questionnaire via an app , and the CDC has monitored this to look for side effects that didn’t show up in the initial trials. V-safe has included several thousand pregnant volunteers, a high percentage of whom were healthcare workers.

The Zauche study was was particularly looking for information regarding miscarriages between week 6 and week 20, and found a 14.1% miscarriage rate, across the 2456 women in the study. This came down to a 12.8% rate after adjusting for maternal age. They say that’s very much in line with what you’d consider the normal miscarriage rate (11% to 22% of pregnancies, depending on exactly how you count it).

The Shimabukuro study looks at 3958 women across all stages of pregnancy. They only found an 8.5% miscarriage rate, but it looks like they included a lot of women who weren’t in the study all the way from the beginning to week 20. Probably a better indicator is the ratio of live births to miscarriages: 13.9%, very much in line with Zauche. They also looked for other adverse outcomes, such as preterm birth, low birth weight, any abnormalities, and concluded “Preliminary findings did not show obvious safety signals among pregnant persons who received mRNA Covid-19 vaccines”

University of Minnesota article that summarizes several of these studies:

Now, you’ll notice that most of these don’t have proper control groups. Best I can tell, this is par for the course. Once a treatment is shown to be as effective as the COVID vaccine, it’s considered unethical to give some patients a placebo.

It seems like largely based on these studies, the CDC began recommending the vaccine for pregnant women as well.

The Concerns

I scanned the internet to see if I could get an answer to “What are the concerns about the vaccine on the orthodox Catholic side”?

It’s kind of a confusing hodgepodge. I was surprised to discover that there’s not much in the way of formal “studies” that people are concerned about - more, it’s a bunch of Facebook posts, reshares, memes, tweets, interviews, live-streamed talks, and anecdotes. There’s also not one health concern they focus on - it seems to be more a scattering of “Maybe the vaccine causes X” with all sorts of different values for X. My best bet for trying to get a sense of them is this page from LifeSiteNews:

https://lifefacts.lifesitenews.com/covid-19/covid-19-vaccine/

It’s their own curated list of articles on why they don’t like the vaccine, and I supplemented it with my own google searching.

The one which involves a study, which I see come up the most, is:
https://www.pro-memoria.info/wp/wp-content/uploads/Aborto-vaccini-Covid_-Researchers-bury-data-showing-82-miscarriage-rate-in-vaccinated-women-LifeSiteNews.pdf

It’s based off of the Shimabukuro study I put in the “pro” column. Analysis here: http://darwincatholic.blogspot.com/2021/07/no-covid-vaccines-are-not-causing-first.html In short, it appears that somebody took a study which indicated the vaccine was safe during pregnancy… and then copy-pasted various numbers from from it to tell an entirely made-up story about the vaccine causing miscarriages, then linked to the study to give it a scientific veneer, and hoped people would like and share without reading further than a quick Ctrl-F to confirm that those numbers came from the study. It’s a case of outright deception.

To be fair, LifeSiteNews took down the original article, but it seems to remain the source of much of the concern about miscarriages

There are some claims like “Miscarriage rate quadruples in England after vaccine approved” (seen in a Facebook comment, can’t find an article for that one) or “Vaccine causes 5 times as many deaths as COVID” https://www.lifesitenews.com/news/covid-jabs-came-from-bioterrorism/?utm_source=lifefacts

Which are easily falsifiable from public data.

There’s also a lot of FUD and speculation - things like, “It's new and experimental”, “We don’t have years-long studies proving that there are no negative effects years later”. “The spike proteins produced by the vaccine are small enough that they might be able to cross the blood-brain barrier and then get into your brain and cause Alzheimers!”.

Certainly we don't have years-long studies proving that there are no booby-trap side-effects that only manifest years later, but that's true of virtually every food and medicine. I've never seen this put in so many words, but the impression I get from reading a bunch of medical folks discussing the issue is that, side effects that only manifest years later just aren't something they worry too much about. Your body has trouble getting rid of heavy metals, but aside from that, foreign substances don't stick around.

Within a few days, either you metabolise them (break them down), or pee them out, or your immune system attacks them. If they're going to injure you, the injury happens right away. Even for carcinogens, the problem is accumulated cell damage from repeated, heavy exposure.

There’s one article expressing some general anxieties about how it might affect fertility: https://www.lifesitenews.com/news/stop-the-shot-conference-doctors-pregnant-women-should-never-take-the-vaccine/?utm_source=lifefacts
It seems the biggest claim of the article is:

nanoparticles, used in mRNA jab technology, “can disrupt the levels of secreted hormones, causing changes in sexual behavior,” since the nanoparticles “can pass through the blood-testis barrier, placental barrier, and epithelial barrier, which protect reproductive tissues.” …… The report “shows very clearly that the lipid nanoparticles accumulate at least twenty-fold [in the ovaries] compared with other tissues,” Yeadon said.

But I also found this discussion here, with a link to the original study: https://www.bbc.com/news/health-57552527

It really doesn’t look too alarming. Basically, they gave rats a dose of the vaccine 1000x higher than what they give to people, watched how it processed through their bodies, and looked for adverse side effects. They noted that traces of the fatty shell around the RNA could be detected in the Rat’s ovaries and adrenal glands 48 hours later, but didn’t seem to carry any of the genetic material. Best I can tell, they didn’t find any toxicity.

Some concerns about an increase in cardiac events following the vaccine… but it looks like LifeSiteNews cherry-picks https://www.lifesitenews.com/news/covid-shots-linked-to-2-million-injuries-21766-deaths-in-europe-eu-reports/ numbers to try to paint the most alarming story, and the more responsible reactions are “There’s a tiny risk, but it’s much smaller than the risk of similar cardiac events as complications of COVID”

There are also some genuine concerns about allergic reactions. In this study https://www.cdc.gov/mmwr/volumes/70/wr/mm7002e1.htm?s_cid=mm7002e1_w , the CDC noted that out of a sample of 1,893,360 people receiving the vaccine, 104 people reported allergic reactions, 21 of which were anaphylactic. Most of the anaphylactic reactions took place within 15 minutes of receiving the vaccine, so they started recommending that you wait around for 15 minutes of monitoring after receiving the shot. Having allergies to other things seemed to be a risk factor for having a reaction to the vaccine, but still not enough to make it very likely

There is also legitimate evidence of some women having a heavier-than-normal period after receiving the vaccine, but it seems like this is a known side-effect of several vaccines, and hasn’t seemed to cause any long-term harm https://www.bbc.com/news/health-56901353

For me, one thing I was concerned enough to look into, was, there’s evidence that fighting an infection in pregnancy raises the risk of the baby developing autism, so there might be a tiny risk from receiving the vaccine during first trimester. But on further investigation that seems very unlikely - the infection-autism link has only come up either for severe bacterial infections (sepsis, pneumonia) or, interestingly, urinary tract infections

Ethics

Now, all of the LifeSiteNews arguments strike me as motivated reasoning. Like, the thought process isn’t “We encountered some anomalous evidence which makes us concerned about the vaccine”; rather its “We’ve decided beforehand that we don’t like the vaccine, and we’re digging for evidence to back that up (and we’re so eager to find it that we're prone to making things up where we can’t find evidence)”

It seems like some of it comes from a sincere ethical concern about tissue from aborted babies used in medical research.

Best I can tell, the story goes something like this:

A common tool for microbiology research is immortal cell lines. These are derived from isolating a cancerous cell from a person, and letting it divide and divide ad infinitum. You can share bits of tissue from a cell line, and run experiments all around the world using identical cells. There are several cell lines which have been dividing, virtually unchanged for over 40 years. They are extraordinarily well characterized from years of research, and allow apples-to-apples comparisons across new research.

And many of the most widely used ones were first derived under ethically doubtful circumstances. There are two common ones which were derived from aborted (or don’t know for certain but probably aborted) babies, and others taken from poor minority patients without their consent.

The Johnson&Johnson vaccine and the AstraZeneca vaccine are produced with the help of cells from one of these lines from an aborted baby

To my understanding, it’s not that the research and production couldn’t be done with non-fetal cell lines, but that they’re a little more convenient.

Now, the Pfizer/Moderna mRNA vaccines are NOT produced using tissue from abortion-derived cell lines. In the course of developing them, researchers did some testing against mice who had been given human-like immune systems by injecting them with cells from one of these fetal lines. But such tests have (unfortunately) been performed for any drug you can name, from Ivermectin to Tylenol. We should certainly advocate for performing these tests without using abortion-derived cells, but it becomes absurd to reject any substance for which such testing has ever been performed. https://www.patheos.com/blogs/throughcatholiclenses/2021/01/if-any-drug-tested-on-hek-293-is-immoral-goodbye-modern-medicine/

Some Bishops advocate that its preferable to use the mRNA vaccines where they're available, but generally agree that in either case, the cooperation with the one abortion from decades ago is remote enough, and the need severe enough, to make receiving the vaccine commendable.

https://www.nebraskamed.com/COVID/you-asked-we-answered-do-the-covid-19-vaccines-contain-aborted-fetal-cells

https://mocatholic.org/sites/missouricc/files/messenger_1_21_for_web_pages.pdf

https://www.usccb.org/moral-considerations-covid-vaccines

https://www.catholicnews.com/vatican-without-alternatives-current-covid-19-vaccines-are-morally-acceptable/

Recently I've been trying to read through the highlights reel of the best-regarded business books out there, and I intend to post occasional reviews. First...

Like most business books, it's got a lot of padding. It could have been a 50 page pamphlet and lost nothing -- its only a 300+ page book because we have a social convention that books ought to be a certain yea-thick rectangular shape, and we feel gypped if we paid full price and didn't get enough book for our money.

But I credit it with driving home two big points, which I've found amazingly useful.

The first is: A whole lot of management is aimed at trying to fix people's weaknesses. This isn't something any manager can do.

I hold that it IS possible to change your personality, and to fix your flaws... a little bit. I know I have in the last ten years of our marriage, because I love my wife and it was important to our marriage. I know she's done the same for me. It's a years-long process with much groaning, false starts, and ten-steps-forward-but-nine-steps-back, and even then, its really just upgrading that characteristic from a two out of ten to a five out of ten.

That's worth doing for a marriage you intend to last fifty years. It's not worthwhile for a job which will last five. Even if it was worthwhile, its not possible within the time scope of just a couple years. Even if it was possible, it has to come from the inside -- It can't be imposed from the outside by a manager.

The conclusion is that its a waste of time for a manager to try to fix people's weaknesses. All they can do is train missing skills in people who are willing and able to learn, and try to set their people up in circumstances which play to their strengths, and minimize damage from their weaknesses.

The second point: The main thesis of the book is that authors found, through careful experimentation, a survey of 12 simple yes-or-no questions which was an extraordinarily good predictor of employee engagement

I reproduce the questions here:

1. Do I know what is expected of me at work?
   

2. Do I have the materials and equipment I need to do my work right?
   

3. At work, do I have the opportunity to do what I do best every day?
   

4. In the last seven days, have I received recognition or praise for doing good work?
   

5. Does my supervisor, or someone at work, seem to care about me as a person?
   

6. Is there someone at work who encourages my development?
   

7. At work, do my opinions seem to count?
   

8. Does the mission/purpose of my company make me feel my job is important?
   

9. Are my co-workers committed to doing quality work?
   

10. Do I have a best friend at work?
    

11. In the last six months, has someone at work talked to me about my progress?
    

12. This last year, have I had opportunities at work to learn and grow?
    

Really, it seems to me that these can be distilled even further, to 2 fundamental needs of each employee:

• He needs to know unambiguously what he's supposed to be doing when he comes to work each day, and have confidence that his work is valued.

• He needs somebody at work, preferably in a supervisory role, who gives a shit about him: who cares about whether he's doing alright, what he thinks about things, whether he's learning and growing.

THOSE two fundamental needs are something that every manager is capable of addressing. Where I am now, not in a managerial role but a Technical Lead, mentoring sort of role, I'M capable of addressing those needs for the people under me.

It convinces me that the most valuable thing I can do for the people I'm responsible for is:

• Genuinely care about them, and engage with them often enough so that they know I care and I appreciate their work. Carefully listen to what they're saying, and do my best to find them opportunities for growth if they're feeling bored or stagnant, or respite if they're overwhelmed

• Make sure they have a prioritized queue of tasks lined up which are a good match for what they want to be doing, and if they're feeling stuck or don't know how to proceed, take time to sit down with them and get them unstuck.

I know I don't get this right all the time, but I certainly strive towards it. This gives me confidence that with practice, I could succeed in other leadership roles. Those two rules seem very common sense, but it's surprising to me the number of managers who don't do those things. Rather, it seems the default approach for a manager is to divide his employees up into "People who have a problem" and "People I don't need to worry about". He will spend a lot of his time trying to fix the people who have a problem, and ignore the other ones until he needs something from them. It's the classic "squeaky wheel gets the grease" approach to life, but it seems like its the opposite of how to lead effectively.

Even I will admit that Javascript an ugly duckling, and I love Javascript. Just about every other language out there has coalesced around a set of stylistic conventions for how code is supposed to be formatted. It's a tribute to the weirdness of Javascript that this hasn't happened. Every style out there has genuine trade-offs between readability and consistency, and thus even style guides and the linters that enforce them are Balkanized into different camps. In my travels, I've noticed 3 camps

The Javanados (The ESLint camp^[1])

When I'm explaining what I do to recruiters and family members, one of the conversations I have most often is the one that goes, "I write mostly Javascript these days! No, no relation to Java. The names sound the same, but they're totally different. Yeah, I know it's confusing."

There's some historical reason for the naming. Back when the most popular programming language in the world was Visual Basic, Microsoft created a simplified version called VBScript that could run inside of Internet Explorer. In reaction, Brendan Eich whipped up a language on behalf of Netscape to do the same thing, but that wouldn't be controlled by Microsoft. Since Java was rising up as the great competitor to Visual Basic, Brendan gave the language a Java-like patina, and Netscape worked out a deal with Sun to call it .... Javascript!

While the two languages are not really all that related, folks in the Javanado camp believe that Javascript should be styled to look as much like Java as reasonably possible. Thus:

• While Javascript makes no distinction between single- and double-quoted strings, It's better to always use double-quoted strings, because that's what Java uses.
• While ending lines in semicolons is not strictly necessary in Javascript (more on that later), they are necessary in Java, so they should be used in Javascript as well
• Lines ought to be indented with 4 spaces, because that's customary in Java.
• Functions that create objects ought to be invoked using Javascript's "new" syntax where possible, because that's what Java object creation looks like.

Let me explain that last point. Unlike Java, Javascript has no built-in notion of a "class". It simply has functions and objects. Rather than calling a constructor, you initialize an object like:

function buildDog(name, age) {
	return {
		age: age
		name: name
		bark: function() {
			alert('woof')
		}
	}
}

var fido = buildDog('fido', 7)

However, Javascript also supports a syntax which resembles the Java syntax for calling a constructor. It looks like this

function Dog(name, age) {
	this.name = name
	this.age = age
}

Dog.prototype.bark = function() {
		alert('woof')
	}

var fido = new Dog('fido', 7)

There's a few more nuances, but essentially, by calling the function with the "new" keyword, it's invoked as:

function Dog(name, age) {
	this = (object that references Dog.prototype) //implicitly added when function invoked with 'new' keyword
	this.name = name
	this.age = age
	return this  //implicitly added when function invoked with 'new' keyword
}

There's various back and forth on these two styles. On one hand, the simple buildDog function is a lot more intuitive and just as powerful. On the other hand, the fido = new Dog('fido', 7) syntax for actually creating a dog is a little more explicit in what it's doing.

The Crockfordians (the JSLint camp)

In the early days, there was a sense that Javascript wasn't a real programming language. It was a toy suitable for children and managers. It was for writing form validations and sparkling hover effects. Douglas
Crockford changed this with his seminal book, "Javascript: the Good Parts".

He brought it to the public attention that underneath the quirks and weirdnesses of javascript, it also had some very, very powerful features. He argued that with its functional closures and prototypal inheritance, it is the closest thing to a mainstream Lisp we were going to get.

In addition to advocating for the power of Javascript, Crockford advocated for a strict Javascript coding style to minimize the quirkiness. Javascript will do some strange preprocessing things to your code. Take for example, variable hoisting

If you write code that looks like this:

function printSomeNumbers {
	var x = 0;
	console.log(x);
	var y = 3;
	console.log(y);
}

Javascript will "hoist" all the variable definitions to the beginning of the function. It will rewrite this code as

function printSomeNumbers {
	var x, y = undefined;
	x = 0;
	console.log(x);
	y = 3;
	console.log(y);
}

From a little browsing around the internet, it appears that nobody is entirely sure what purpose this behavior was intended to accomplish. Most likely, Brendan Eich was really going after function hoisting (ie, all functions get hoisted to the top, so you never accidentally invoke a function that isn't declared yet). It was just easier to make every variable behave like this. It's mostly harmless, it just means that you can reference a variable before its declaration, and rather than not existing, it will exist with a value of undefined

Crockford believed that you shouldn't give javascript the opportunity to do this kind of implicit code rearranging. You should preempt it declaring all your local variables in the first line of your function, like:

function printSomeNumbers {
	var x = 0, y = 3; 
	console.log(x);
	console.log(y);
}

By the same reasoning the Crockfordians believe it is always better to use plain ol' functions for creating objects, and avoid the "new" keyword entirely, since new implicitly adds extra behavior to the function

The Lazy ones (the standard.js camp):

Possibly the weirdest quirk of Javascript is its automatic semicolon insertion (ASI). The rule goes something like this

• Javascript (like Java and C) requires that each line end in a semicolon
• However! If you forget the semicolons, javascript will automatically insert them for you before running your code
• It works like this. As the javascript engine goes through parsing your code, when it encounters a new line, it first tries to run the next line as a continuation of the previous line. If it finds that this doesn't result in valid javascript, it goes back to the newline character and inserts a semicolon right before it.

For example:

var a = 1
var b = 2;

The javascript parser first tries to run this as var a = 1 var b = 2;. This is not valid javascript, so the parser inserts a semicolon before the new line, ie

var a = 1;
var b = 2;

However, in the case of

var a = 1 +
3;

the parser will first try to run it as var a = 1 + 3;. This is valid, so no semicolon gets inserted.

According to the Crockfordians, this is javascript mutating your code in quirky, unexpected ways, and thus it should always be rejected. To the Javanados, Java and C have a semicolon at the end of each line, so Javascript should do the same.

However, to lazy Python and Ruby fans, this is all wrong. There is no reason to pepper your code with a bunch of unsightly semicolons, and that goes double in a language that doesn't even really need them.

Ah, but this style has a disadvantage: There is one situation where Automatic Semicolon insertion can bite you in the britches. If you begin a new line with a [, (, or `, it can sometimes be a valid continuation of the previous line in ways you wouldn't expect.

Consider

var a = 1
var b = 2
var c = a + b
[a, b, c].forEach(function(a){console.log(a)})

The javascript parser will NOT do what you think it should do here. Instead, it will try running the last 2 lines together:

var c = a + b[a, b, c].forEach(function(a){console.log(a)})

THIS IS SYNTACTICALLY VALID JAVASCRIPT, though it will throw a runtime error.
So, rather than warning you that you missed a semicolon at the end of each line, the Standard.js linter needs to warn you that you need a semicolon every time you begin a line with a "[", "(" or "`" character.

var a = 1
var b = 2
var c = a + b
;[a, b, c].forEach(function(a){console.log(a)})  // works as expected

In reality such situations are rare, but if you aren't aware of them or don't have a linter to catch them they can be real head-scratchers. The Crockfordians and Javanados would argue that even the possibility of such mistakes is enough reason to just write the semicolons.

In general, the Standard.js linter follows a philosophy of minimalism. Semicolons should be left to ASI unless necessary. Indents ought to be two spaces, because that's more compact. Strings ought to be single-quoted, because it saves your pinkie a stretch to the "Shift" key.

With the advent of ES6/ES2015/ES7 etc, most of the distinctive bugbears of the Crockfordian school are moot points. In ES6, variables are declared with the let keyword, which avoids the variable-hoisting behavior. ES6 also introduces a genuine class syntax, which is usually preferable to both the old styles. As a result, the Crockfordian school seems to have more or less fallen off the map.

I admit for myself, I slightly prefer the aesthetics of standard.js, but I realize I'm in the minority, and wasting time trying to argue it against the Javanado style is the worst sort of bikeshedding.

More than any linter, I think the true game-changer for code styling is prettier. This is the library that doesn't just complain you about formatting your code, it automatically rewrites it to make the style corrections, while guaranteeing the same behavior.

I find that the better way is to just have my environment set up so that it runs prettier on my files after every save. It makes nitpicking about semicolons and single quotes in code review a moot point.

There's a tired genre of books called the "Business Fable".

Best known by way of the classic "Who Moved my Cheese?", its a story of a bizarre fictional society which is a transparent analogy for a corporation.

source

If I ever publish a business fable, it will be a crossover business fable / horror story

See, one of the most fun developments I've had with adulthood is that I now love scary movies. It's a genre that's rich in symbolism. In a really great monster story, the monster can't just be a monster. It has to tap into some deep-seated fear we share, and use the monster as a metaphor to examine and interpret that fear, and maybe even bring it to a point of understanding, of catharsis.

This would be the story of a strange island, where the inhabitants live in fear of a monster that stalks at night. The islanders first hear the rumor of this monster from a castaway, who tells a story of how it devoured his entire village. At first they laugh it off. But then, just to be safe, they stop leaving the village at night. Then a couple eerie incidents later, they decide its not safe to go out alone during the day either. They leave their village less and less often, and then only in big war parties. Eventually even the war parties become less frequent, for as the fear grows they need to spend more and more time sharpening their spears before they dare to venture out. Eventually all the islanders starve to death locked inside their village, and we're left wondering: Was there ever a monster outside? Or was the fear itself the real monster all along?????

Does this sound silly? It's a common trap for software companies to fall into.

Back when the whole company was less than a dozen people, with only one or two developers, things moved fast. They cranked out features in days which would take larger companies months. Sure they had problems: the UI was ugly, and it would freeze up with no explanation if you tried submitting the form without entering your date of birth. But it didn't matter, things were moving so fast. The developers had an intimate knowledge of every aspect of the software, and if there was ever a bug that really bothered customers, they could have it patched within hours.

It was a useful piece of software, and that usefulness brought growth: Now, there's a whole team of developers, many more features, and more customers who have come to rely on it.

And one day, they release a bug into production. And all hell breaks loose.
Customer support's phones are blowing up, the rollback procedure fails to fix it, and the next 24 hours are a frantic scramble to patch Humpty-Dumpty back together. When the dust settles, an angry executive summons a meeting with the engineers. "Look," he says, with a visible effort to contain his frustration. "I'm not interested in pointing fingers. I just want to know what we can do to ensure this never happens again."

As embarrassing as the bug is for engineers, its worse for the executive

He's the one who has to personally apologize to the customers. He's the one who gets a sick feeling in the pit of his stomach as he adds up how much those 24 hours with the whole site out of commission cost the company. And he feels profoundly frustrated with how little control he has over the whole thing. When the engineers try to even explain what went wrong, all that comes out is a bunch of excuses and technical gobbledygook. Best he can tell, it adds up to the programmer's equivalent of locking your keys in your car. A silly mistake; we're sorry; we'll try not to do it again.

There are solid strategies available to reduce the risk of deploying bugs like this. But the executive's first instinct is to seek safety by grasping for more of a sense of control. "We can't just release features willy-nilly like we have in the past," he says. "We need some documented procedures. We need a system of manager signoffs on any feature that goes into production, and an auditable paper trail attached to each. We need a formalized code review strategy and a written test plan, not just the developers kicking the tires a little and saying 'Looks good to me'"

All of these things ease the manager's anxiety

They give him a greater sense of control, and they sound like responsible things to do. There's a problem, though: most of these strategies are poor at catching bugs. They act like a security blanket, increasing the feeling of safety without increasing actual safety. They can even make the bug situation worse. They function mainly by making it harder to deploy any code at all, buggy or not. There's no longer an avenue to fix non-critical bugs, or to refactor code which is unstable but hasn't broken yet. Even where the fix is easy, the process to deploy the fix is so onerous that its not worth anybody's time.

The company can survive this. They already have a saleable piece of software, and it doesn't need to add a ton of new features to remain saleable. It's even possible these new rules will decrease the overall bug count, even if they only work by decreasing the amount of code that gets deployed at all.

But this approach to releases has the potential to spiral out of control

True disaster starts when every time the team the team deploys a bug or suffers another outage, new rules are imposed to prevent it from happening again. With a few cycles of this, the release process can grow to include things like

• All code must be reviewed by at least 2 people, and if any bugs slip through their review, those reviewers will be publicly reprimanded
• Code must be escalated through multiple testing environments, and tested by a different team of testers in each one
• Every line of code must be covered by unit tests
• An elaborate set of version control rules (including long-running branches), accompanied by an equally elaborate set of rules about who can merge into what
  
• Frequent code freezes, where no new code is allowed to be merged except fixes for identified bugs
• At each stage, documentation is required: Checklists of exactly which test cases were run, who reviewed what, which items are in which branch of source control
• and, worst of all: If any bugs are discovered along the way, or if any steps are performed incorrectly, the process must be restarted

The core problem here is that the complexity of the process becomes more than any individual can keep track of. The rate of mistakes goes up, not down, as more rules are added, and more mistakes lead to more rules. Inevitably:

Release schedules slip

People will begin to say things like, "There's no way we can get this through testing in time for the June 1 release. We need to postpone until July". This makes the problem worse, because:

Stiennon's 8th^[1] rule: The amount of effort needed to perform a release increases exponentially with the time since the last release.

There is now a logjamb of features which have been built to completion, but have to wait at the back of a long queue before they are allowed to be released. Code like this which is complete, but not released has a strange tendency to rot on the vine. Even the engineers who built it start to forget the details about it: How it works, which pieces needed more testing; how it integrates with the rest of the code.

The team experiences a brain drain

The best, most marketable engineers are under no obligation to put up with all this nonsense, and they leave for greener pastures. In addition to the normal pain of losing a strong contributor, each departure sets back the release, as that engineer takes with him knowledge which was necessary to get the release out the door

Blame

All that paper trail generated by the executive's process does little to prevent bugs, but its very useful in assigning blame when bugs are inevitably discovered. Most line-level employees aren't really incentivized to care whether or not the company is profitable or experiencing tremendous growth. But they will go to extremes to avoid being humiliated in front of their peers or fired. It becomes safer to look busy and do nothing than to do something and risk a reprimand.

The collective actions of the company come to resemble a man with obsessive-compulsive disorder, whose compulsive rituals grow to occupy 100% of his available time. Under the weight of all this process, it's possible for the company to lose the ability to deploy any new software whatsoever

That sounds awful! But is the only other option to have an unstable product?

There's a bunch of techniques which both minimize bugs, AND keep the company nimble. But in reality, they are all different aspects of one idea:

You must have short release cycles

Notice this is the opposite of what the executive in our horror story tried to do. In essence, releasing code made him anxious, and being anxious made him timid. Short release cycles take a surprising amount of courage. There's less paper trail and there's less checking and double-checking. It's charging into the danger, rather than following your instinct and running away from it. But nonetheless, they are the answer. They both decrease the number of bugs (It's less likely to have a deployment disaster with a few small changes made in the last week, than in a gigantic release containing months of work), and more importantly, they make bugs easier to fix.

Stiennon's 9th rule: It's more important to have an easy avenue to fix bugs, than it is to release without bugs^[2].

But there's another subtle benefit at play. Frequent releases give the team more practice doing releases. It's harder to make a critical mistake in the process of deploying code if it's a simple procedure you did last week, rather than a elaborate procedure which you haven't done in months. As the team gets familiar with doing many, small releases, they're able to improve the process a little each time. Each release brings a new opportunity to streamline the process, or to try out a new automation technique.

Automated releases

Way back in the early days, when there was only one developer, the actual steps to release code might have gone something like this: The developer compiled the code on his laptop. Then, he connected to the production server by remote desktop or SSH, and copy-pasted the new build files over the old ones. If he was being extra cautious, he would rename the old build directory to production_old_version rather than deleting it outright. Then, he connected to the database, copy-pasted the schema update scripts from his laptop, and hit the enter key to run them. If any dependencies changed since the last deploy, he made sure to install those on the production server. Finally, he found any config files he needed to change, opened them up, and typed in the new values.

This sounds barbaric, but remember: There are Fortune 500 companies that deploy code this way.

It should come as no surprise that this is error prone. It gets progressively more error prone as the team grows, as the engineer performing it is now deploying code that other people wrote; as he now needs to perform the release on multiple servers. No matter how thoroughly the code was tested prior to the release, its still easy for our engineer to introduce catastrophic bugs by making a small mistake while he's doing the equivalent of open-heart surgery on the production servers.

The solution to this is automated deployments. If the deployment is performed by a script, it will run exactly the same every time. There's no opening for clumsy mistakes. Just as important, the very fact that your environments have been reworked to accommodate automated deployments tends to reduce the subtle discrepancies between the production, staging and development environments. It allows you to have confidence that if a feature worked on the stage environment, it will work when deployed to production. It helps the processing of deploying to become fearless.

In the last decade, an ecosystem has emerged of devops technologies orbiting around docker, which make consistent, automated deployments worlds easier. Docker deserves a whole post of its own, which I intend to publish in the near future.

Professional testers, not test plans

In a growing company, the leadership can be surprisingly reluctant to hire testers. Good testers are quite technical, they command high salaries, and they produce no quantifiable product. Couldn't we just, you know, write up a really detailed test plan, and have everybody pitch in to run the test plan in the week leading up to the release? Or maybe just outsource testing to India?

The problem is that testing is much like development. It's skilled, intuitive work, and can't be reduced to a set of procedures. Good testers will have written plans, but they looks more like

• "Fill in the form with typical user data"
• "Fill in the form with a user with a very long name"

than

1. Insert the name 'John' into the first name field
2. Insert the name 'Smith' into the Last name field
3. type '987-654-3210' into the phone number field
   .....
4. Click the submit button.

They don't perform the test exactly the same every time, and that's precisely why they are effective. Most bug discovery doesn't look like "Test case #12-93-D failed". It involves the tester catching something out of the corner of his eye and thinking, "Huh. that looks a little funny. I'm going to see if I can make that happen again"

So how do you hire those great testers? That's a whole article in itself, and besides, Joel Spolsky has written it up better than I could

Automated regression tests

I almost hesitate to recommend this one, because its so easy to abuse. It's easy for software to become inflexible, to have bad early decisions become unchangeably baked into the design, by having too many automated tests or clumsily thought-out automated tests. Rules like, "All code must have at least 80% unit test coverage" are more likely to contribute to the death spiral than to stop it. But nonetheless, a small, carefully chosen suite of automated tests is an important part of being able to release fearlessly. They are no replacement for professional testers, but they can give a quick bit of feedback to assure you that the core features of the software aren't totally broken. They're not so good for proving that the car's AC keeps passengers comfortable, but they can demonstrate the the car still starts when you turn the key, goes when you push the gas, and stops when you hit the brakes.

Feature flagging

If your company has started to become mired by excessive process, you might at some point ask, "What's stopping us from doing it like we did back when the company was small? This would have taken a couple days then, why is it taking a month now?". The answer is that, back in those days, there weren't so many customers who would be affected by a problem. Most of the risk and anxiety around large deploys comes from how they affect every user at once. There's a simple way around this. Quietly release the feature, but have all the code for it wrapped inside of an if statement

There are tools to manage all this, but it can be something as simple as

if ('this_feature' in customer.features) {
	// New feature code
} else {
	// as things were before
}

Then, without doing a big release, just by altering your settings, you can flip on the feature for just a few customers. Big multi-national corporations take this further: They can deploy a feature to just a random .1% of customers, or only to New Zealand, and double check that their usage metrics don't fall off abruptly.

Demo early and often.

Ultimately, the executive from our story who tried to clamp down on bugs was barking up the wrong tree. Bugs and outages are certainly alarming. But in the end, most software products that fail don't fail because of bugs. They fail because the team built the wrong thing.

Even where the team is building the right thing, the majority of software problems aren't strictly "bugs": that is, cases where the software is obviously broken, freezing up or showing the infamous "Blue Screen of Death".

They are cases where the engineers built something which fulfills the requirements they were given, but it's still not quite right. It's unintuitive, or inconsistent, or it's just not a great approach to solving the problem at hand. The best remedy to all these issues is to have a constant feedback loop, which includes anybody with a stake in the software: managers, executives, sales, and marketing. This is really another aspect of releasing often, and can serve as a substitute when there are legitimate reasons to wait until a feature is more complete before literally putting it in front of customers.

This cannot be done effectively in a culture of anxiety over bugs, where everybody is trying to dodge the hot-potato of blame. If that's the case, engineers have an incentive to spend weeks or months tinkering and polishing before they demo, so they have a bulletproof case to prove they weren't negligent. This is the opposite of what you want. By demoing often, you get repeated opportunities to make the design of the software a little bit better. Features which sounded good on paper but don't work so well in reality can slough off, while new ideas can come from anywhere: Engineers can propose changes to the design, and the folks in Customer Support and Sales who interact with customers day in and day out can share their insights into what those customers are most likely to value.

Ultimately, though, these demos are second-best to the true test of software: feedback from actual customers. The truth is, as much as we plan and strategize, neither we nor the customers can know exactly which products are going to be hits, until those customers actually get their hands on it. This is the most valuable benefit of all of these short release cycles. It allows you to put more potential hits in front of customers, fast.

"What can we do to ensure this never happens again?" was always the wrong question.

Ask instead, "What are some ways we can limit the risk of critical bugs, while still remaining nimble?". Ultimately, those products that lose the ability to deploy new software, have discovered the only true way to ensure that bugs are never deployed in front of customers again.

I love remote work. If you've been following this blog, you probably know this. Around 2 years ago, I decided to bend all my professional ambition into landing a job which would allow me to perform the majority of it from my home.

Or, you know, anywhere else with internet access.

By the time the COVID rolled around, I had already been working 100% remote for well over a year. And now, we landed ourself in this strange situation where everybody is working remote. As the pandemic is running its course, lots of us are starting to settle in for the long haul, with plans to stay away from the office till 2021 and beyond.

I should put a caveat here: These are the things that have worked for me. I'm not a great sample of the general population. This is also drawing on my experience specifically of being a programmer while remote. Take it with a grain of salt, and of course, comment to let me know where I'm wrong!

The first thing is, I want to reassure you: These are tough times. Remote work is usually better than this.

So many of the things which make it fun and productive aren't available during the pandemic. With everybody else locked down alongside you, with schools closed, with your spouse needing to share the same workspace, its hard to quietly concentrate. For all the benefits and troubles of remote work I outline below, COVID makes all the troubles more troubling and all the benefits less beneficial.

All of this is to say, if you find remote work even tolerable right now; if you think "I love the flexibility, but (I never thought I'd say this) I wish I could go into the office at least once in a while" ...

When this COVID crisis is nothing but a memory, you're going to love remote work. Don't let go of the dream just because things are rough now.

How To Thrive when working remote

Embrace the flexibility

If you browse your news feed for articles on working from home, you will find yourself with an article from Business Insider or something, with some anodyne tips which more-or-less advise you to recreate the office in your home. They will have bullet points like "Don't let yourself get distracted by doing the laundry during work hours" or "Make sure you have a dedicated room which simulates your cubical in the office"

I think this is mistaken, and sacrifices one of the biggest benefits of remote work.

Remote work gives you enormous freedom. Do you need to a half-hour to head to the grocery store when its not overflowing with people? Keep the laundry moving between sprints of work? Go for a run mid-afternoon (and come back all stinky and sweaty in a way no office would tolerate)? Pick the kids up from school at 3, and then finish your workday later in the evening? You will love your job, and love your life more, if you take advantage of the freedom to do all those things.

Working remote adds an entire hour back to your day, which would normally be lost to a commute. Odds are, that hour you spent fighting traffic was the least pleasant of your day. You weren't enjoying yourself, you weren't resting, and you weren't doing anything useful. Take advantage of that extra time.

Here's a routine which has worked very well for me: When I worked in an office, I'd arrive at about 8:30, and leave at about 5:30, with an hour off for lunch in the middle. Then, there would be a half-hour of commuting on either end of that. Now that I'm remote, I roll the time I would have spent commuting into the work day. In other words, my hours are 8 to 6. But then, I take 2 hours off in middle of the day. This allows both time for lunch, and time for another substantial break. I'll use that break to exercise, or go for a long walk, or run an errand. Having those periods of rest helps me work with maximum energy, to my best self, throughout the day. I'm no longer exhausted by the end of the day, limping through the final hour before quitting time.

It's surprising how much discipline it takes to take breaks like this. It involves silencing that nagging worry "What if there's an emergency? What if my boss Slacks me while I'm out, and I'm not there?". Just take a reasonable amount of time, set your Slack to an away status to let your colleagues know when to expect you back. And go for it.

But create some space where you're not worrying about work

Flexibility comes with a downside. It brings with it a temptation always be "on". It's the temptation to never really disengage from work, to always be ready to respond to an email.

This is dangerous. It's not hard work that leads to burnout; it's that non-stop vigilance — the inability to ever really rest.

Here's the answer: Delete Slack from your phone. Set your phone up so that you can't use it to check your work email. If you absolutely must get notifications on your phone during the day, get a separate work phone, and make sure the work phone is turned off when you're not on call. Don't merely resist the temptation of checking Slack; arrange your situation such that Slack isn't even available, so you're not wasting energy avoiding the temptation. If you need to, keep a separate work computer and home computer. Put on a button-up shirt for the workday, and ceremoniously take it off at quitting time.

Because nobody has a right to demand your 24/7 participation. Nobody needs that. Nothing you're involved in is so critical it can't wait until tomorrow morning. In fact, by replying to an email after hours, you are placing a burden on whoever you're replying to. The ball's in her court now. She might receive a ding on her phone, which will break her concentration on something she was enjoying, which will cost her a whole hour of rest.

That was inconsiderate of you. None of that worrying you caused her is free. The piper will have his pay eventually, and he will extract it in the currency of exhaustion and burnout.

Move around

This is harder to do during this pandemic, but I find it's important to do it anyway. I thrive on being able to move throughout the day, to move with my laptop to different rooms in the house. In between sprints of work, I'll pace, do push-ups, mosey outside for ten minutes. Pre-pandemic, I would rely on wandering out to coffee shops and libraries, or just my apartment's common area. It's amazing to me how a change of scenery can turn an unproductive day into a productive one.

Here's a useful hack I've found, now that a lot of public spaces closed due to COVID. I have my phone set up to act as a wi-fi hotspot. Sometimes, I'll just drive to a park with a view of a lake. I'll keep the car idling and the air-conditioner blasting, tether my laptop to my phone, and just spend a couple peaceful hours working from my tiny little automotive office

Things that are tough when you're remote (and how to work around them)

I think if you had asked most managers pre-COVID why they don't want their people to work remote, they would have said something like,

"What? Nobody's going to get anything done if they're lazing around in their pajamas with the TV just a click away. They need to be in the office for accountability. Besides, we've got a very collaborative culture around here. If we want to figure something out together, we need to be able to just grab a conference room and work it out on a whiteboard"

I think we've discovered by now that most of those objections are baloney. You and your coworkers are professional adults, and you are perfectly capable of staying on task without the threat of the boss stalking the aisles and calling out anybody who doesn't look busy. Cube farms were never productive environments, and open-plan offices were even worse. They were uncomfortable, anxiety producing, and filled with distractions.

This pandemic makes it hard to have a comfortable work-from-home environment, with schools closed and with your spouse sharing the same workspace. But even so, you are likely finding that your home is a better environment for work than the office ever was.

Likewise, that thing about a collaborative culture. Do you remember those times back at the office, where you piled into a conference room, and something magical happened? Where the ideas flew like fireworks as you took turns drawing on the whiteboard -- some ideas fizzling out, but others joining together, building and building into something more than the sum of their parts; sometimes blossoming into entirely new products, concepts, opportunities? Where sometimes you would bump into a stranger in the hall from a whole different department, and your small talk would turn to talk about your different projects, the problems you're solving and their solutions, where sometimes your solutions would marry and their offspring would be an amazing new solution neither of you could ever have dreamed of alone?

Admit it. You never actually did any of that in your office. That's a stock photo from your company's sales brochure, not an actual experience you had.

The reality is a little more boring. You didn't really "collaborate" all that much. Programming is intensely individual work. Instead, you tended to reach out to people when you had a question, when you were lacking information necessary to complete your task at hand, or when you were unsure exactly what you were supposed to be doing. You would discuss a specific problem to try to reach a decision. You would also get sucked into a lot of meetings, some of which were necessary and some that were entirely useless.

Most of that is surprisingly well accomplished with Zoom. In fact, in some ways, Zoom works better than in-person meeting. Screen sharing can work better for getting two sets of eyes on a tough piece of code than having bunch of people craning over a monitor. Zooms are just enough extra effort that people seem a little less inclined to call useless Zoom calls than to call useless meetings.

And yet.... even so, there is something very critical lost when you never see your colleagues face-to-face.

The number 1 difficulty: It's hard to learn to like and trust people who you don't get to see face-to-face

It's not as simple as "People aren't communicating/collaborating while remote". This Harvard Business Review article seems to find that we collaborate very well...... with the small set of people who we're actively collaborating with. What we miss is the weaker connections. It's the smiling and waving "Hello!" in the hall to a guy who... I've seen him around, but I don't even know his name. It's the noticing the new guy a couple cubes over is struggling with some gnarly git issue, and taking ten minutes to show him how to solve it with an interactive rebase. He's on a whole different team -- We don't work on any of the same projects. If we were remote, I might not even have known he existed.

These tiny, routine bits of positivity add up. It's not that brilliant ideas spawn from them, its that the sum total of months of these interactions helps produce a feeling of belonging. It can give an office a sense of "This is a place where people smile when I walk by, where I know these people. This is my tribe."

I think we miss those small interactions even more with the people we do regularly collaborate with. Marriage counselor John Gottman found in his research that, for a happy marriage, positive interactions need to outnumber negative interactions by nearly 5 to 1. I believe this applies to all relationships, not just marriages. When everybody is remote, its easy to slip into a pattern of only communicating with people when there's some kind of a problem: Either a complaint about their work, or a frustration we want their help resolving.

I'm going to link to the same HBR article again, its that good. Pre-pandemic, we would have thought that Conscientious, Introverted people would be the ones who would thrive best while working remote. What these authors found instead is that the most useful personality traits are Agreeableness and a lack of Neuroticism. In other words, it the personality tendency to get along easily, and not to interpret things in a negative light, which makes the biggest difference

Maintaining strong relationships is the single biggest challenge of remote work even during normal times, and the pandemic makes it harder. Far and away the best antidote to this problem is to have real get-togethers. All the separated remote workers should travel to meet up together at least once a quarter. A couple days dedicated to spending time with each other can do more to build camaraderie than months of mumbling about the weather as you grab your coffee. It's hard to get really mad in an argument over javascript semicolons if you have the shared experience of winning the relay race at the company picnic, of getting lost trying to find your way back to the hotel after happy hour.

In COVID times, I've found the best thing I can do is to reach out to people when I don't need something from them. It's the art of giving people a call and asking about them, of being sincerely interested in what they're working on and what's going on in their lives.

I find it also helps to just put extra effort into being funny. On the shared team slack, keep making jokes. Keep the giphy's flying. Keep posting cute pet pictures (and especially cute baby pictures). Show up early to Zoom meetings, and take a little time to tell a funny story. Thank people for their hard work, and be generous with sharing credit. Build up the score of those small, positive interactions, so that when you do need to criticize, its a gentle correction from a friend, not an attack from a stranger.

Thing that's difficult #2: People are anxious.

Odds are, there's a pall of worry cast over your entire workplace. Everybody is worrying about their job security, about declining revenues. They're worried about their kids falling behind in school, and worried about the health of their parents. They're frustrated because they're not feeling as connected with their co-workers as they were a few months ago.

And its not just the people you work alongside. Things are even worse for managers. Remember, most of the purpose of an open-plan office is to to reassure managers that their people are busy and collaborative. They're dealing with all those normal human worries, and on top of that, they're worrying about their employees. Are they busy? Happy? Talking with each other? Are they getting anything done? If they are, is it the right thing?

Anxious people tend towards inaction, and inaction makes the frustration worse. Anxious people tend to interpret more things in a negative light, which makes it that much harder to strengthen relationships.

Thing that's difficult #3: Remote work isn't for everybody

I was home-schooled for most of high school. I remember it as one of the best experiences of my life. For the first few months, it didn't seem real. It felt too good to be true, like one day everyone would jump out and yell "April Fools!" and I would have to go back to school again. I spent the next 4 years just happily learning, making friends with other home-schoolers, being happier than I could ever remember being.

(This experience was one of the things that tipped me off that I might prosper as a remote worker)

My dear wife Amy, on the other hand, had a radically different experience. She was home-schooled for a few years in middle school, and she hated it. She was desperate to go back to a real school.

I think remote work is like this. Some people legitimately need the bustle and energy of an office in order to thrive. They feel stymied; despondent being away from it. Very competent professionals are going to have radically different reactions to the same experience

In most times, remote workers would be a self-selected group of the people who get the most out of remote work. Now, we're all thrust into it, whether we like it or not.

For both of these difficulties, the best advice I have to offer is not easy advice. It's to be generous to your colleagues. Try your hardest to give them the benefit of the doubt. If a manager is unclear or unavailable or short-tempered, assume he's extra-stressed figuring out how to manage a remote team, and he'll be back on track when the office eventually reopens. If a co-worker is struggling to explain her problem over Slack or Zoom, assume that she misses face-to-face, not that she's a bad communicator.

Patrick Rothfuss's "The Name of the Wind" was a remarkable work of fantasy when it came out in 2007.

It's the story of Kvothe, whose exploits have made him the subject of tales around every campfire, songs in every tavern across the land. But when we meet him, he seems to be a broken man, a shadow of his former self, living in hiding. The main body of the book consists of Kvothe narrating his life story to the King's Chronicler, over the course of three days. Most of "The Name of the Wind", then, consist of the first day of Kvothes narration.

It's an engaging book, constantly playing with stories within stories, with the nature of language, how meaning gets shifted and lost over the course of re-tellings. It's a book that rewards multiple readings. It's no wonder that it was an enormous success.

It's also has a narrative structure that practically promises a trilogy of books. And indeed, when he was promoting the original book in 2007, author Patrick Rothfuss promised that the remaining 2 books were already written, and would be published inside of a couple years.

That is not what happened.

Rather, after four excruciating years of revising, Rothfuss finally published the second book in his trilogy, "The Wise Man's Fear". Now, nine years later, no word has been heard of the third book, tentatively titled "The Doors of Stone"

I've got a pet theory. The book shall never be completed.

At the beginning of "The Name of the Wind", Kvothe compliments Chronicler on a previous work of his, "Mating habits of the common Draccus", a biological treatise on dragons. Chronicler replies

I set out to find a legend, and what I found instead was a lizard. An extraordinary lizard, but merely a lizard

Its a brief moment, but on a second reading I realized that its meant to be a metaphor for Kvothe himself, whose story Chronicler subsequently collects. He set out to find a legend, and instead what he finds is just a man: An extraordinary man, but merely a man

But the metaphor goes further. The climactic sequence of the book has Kvothe actually encountering a Draccus. The particular one he finds is gigantic, a living legend. However, it is brought low from its majesty because of a crippling addiction to Denner resin, a drug in this fantastic world which seems to have effects similar to methamphetamines. Its addiction drives it on a rampage, and Kvothe is only able to stop it with a scheme that... well, Kvothe knows the naturalistic explanation, but it appears to the townsfolk as if the dragon is directly struck down by God himself.

I suspect we have the key plot beats of "The Doors of Stone" foreshadowed right there.

Like the Draccus, Kvothe is meant to be a living legend, but with one, fatal, tragic flaw. As the Draccus was brought low by its addiction to Denner Resin, He will be brought low by his addiction to Denna, his sultry love interest. He will cause horrific destruction in pursuit of her, and then will eventually be struck down in a tussle with Tehlu himself (Who the book hints is not actually God, but a being of forgotten magic who people have come to equate with God).

That love between Kvothe and Denna is at the emotional center of the whole thing. It's meant to be an operatic tragedy, meant to move us with longing for what could have been. She's meant to be the Platonic form of the desirable woman: Beautiful beyond imagining, but just, always, out of reach.

But, that isn't the relationship that Rothfuss wrote.

Instead Denna comes off as a borderline personality, who treats Kvothe as the gay best friend she can always count on to help her bounce back from the lows of her tempestuous love life. Meanwhile, Kvothe dotes on her with the puppy love of nerdy teenager with his first crush.

At no point in the story was it romantic. But during the first book, when Kvothe really is an extraordinarily talented, nerdy teenager encountering women for the first time, it was at least queasily persuasive. In "The Wise Man's Fear", when Kvothe starts to mature, grows into his talents, and learns sexomancy from a primal lust goddess, it stopped even being believable.

Rothfuss appears to be consummate perfectionist, who revises his stories again and again for years until they feel just right. I suspect that he's written himself into a corner, and he knows it. The romance which seemed grandiose but tragically flawed when he started to write it more than 20 years ago now seems childish to his older self. It's a flaw at the core of the story that no amount of revising can fix. No matter how much he tinkers and rearranges, no matter how many scenes he adds or subtracts, he can never get his conclusion to feel emotionally satisfying.

Meanwhile, the greater literary world has moved on.

"The Name of the Wind" owes a great deal of its success to the perfect timing of its arrival. It appeared just as the kids who grew up on Harry Potter were entering college. Where Harry Potter is the story of life in a magical middle school and high school, "The Name of the Wind" smoothly picks up that baton to tell the story of a boy attending a magical college. "Wise Man's Fear" seemed to struggle desperately to have Kvothe's legend growing while keeping him in school for the entire length of the book.

The sheer number of pages devoted to the Magic University segments give me the impression that they were also Rothfuss's favorite parts to write. We might see a bit of art imitating life here, as Rothfuss was himself a perpetual student, who spent nine years working towards a bachelor's degree before he became a bestselling author. This is an approach which simply won't work for the final installment. The story requires Kvothe to DO amazing things, not just learn amazing things.

In short, with the wave of Harry Potter long past, the story no longer feels fresh and topical. A middle-aged Rothfuss no longer finds the romance at the core of the story compelling. And with the plot forced away from being a "Magical School" story, the piece of it he enjoyed most is over.

It is a story which will never be completed because it can't be completed, not in a way the author finds satisfying.

NOTE: Credit where credit is due. Renowned software blogger Steve Yegge made a very similar point several years ago

I've observed that there are two kinds of developers in the world.

One kind is of a basically lawful good alignment.

In their personal lives, they are people who make their bed crisply every morning. They like color-coding and todo lists.

They like static type systems, interfaces, and inheritance hierarchies. In general, they see organization and consistency as the highest virtues in code, and if code needs to be more verbose in order to be consistent and organized, then so be it. Their preferred languages are Java and C#. They love Angular, and believe that Typescript finally makes the frontend bearable to work with. They like Windows, Jira, IDEs, and XML, so long as it has a robust schema. They sincerely believe in the power of scrum.

They generally believe in Cathedrals. They think that the ideal software is the result of top-down planning. It should be an integrated whole, with a place for everything and everything in its place.

They look at the other kind of developers, and see them as not just technically incorrect, but morally deficient: a bunch of reckless cowboy-coders who give the profession a bad name, who need a responsible adult to come in and clean up their messes.

Then there is the other sort of developer, with a kind of chaotic neutral alignment.

These are people who hit the snooze button on their alarm each morning. Their closets have a few piles on the floor which are just "Miscellaneous".

They like functional programming, dynamic typing, and JSON. They consider conciseness and DRY to be the highest virtues in code and they are skeptical of any approach which adds more lines of code just for the sake of orderliness. On the frontend, they gravitate towards React or Vue, and feel like they ought to learn Typescript someday. On the backend, they prefer Ruby, Python, and Node, and if they're old enough, they remember Perl and Lisp with nostalgia. They like Linux and Vim, and roll their eyes at scrum.

They generally believe in Bazaars. They think that the best software arises organically by incremental improvements upon a Minimum Viable Product. The best approach is a toolbox filled with small, independent tools which each do one thing, and do it well.

They look at the other kind of developers, and see them as not just technically incorrect, but morally deficient: A bunch of stuffy bureaucrats who try to disguise their incompetence behind a shield of rules, process, and FUD.

What's most interesting to me about this divide is how most developer tools seem to be aimed squarely at one type or the other. If you have a Java and Angular app, most of the people who apply to work with you are going to be of a lawful-good temperment, and you'll end up with a mostly chaotic-neutral team if you buld your app with Node and React. I suspect this is the single most important consequence of the technology stack you choose, far outweighing the precise technical merits of the tools.

The idea of working remote has always appealed to me. But those times I've actually tried it, not only did I enjoy it, but I was genuinely surprised how much more productive it made me. Apparently, I'm not the only one. The words "work from home" carry a certain image of bathrobes and fuzzy slippers, of generally taking it easy. I found the truth was much different. Rather, like most developers, I enjoy programming, and want to do it well. Working remote brought tremendous freedom, and that included the freedom to do my job better

Freedom from a commute

Our time is the greatest thing of value; maybe the only thing of real value, that we possess. For most of us, commuting is the single biggest waste of time in our day. Time spent in commuter traffic is neither restful nor useful. I've often thought how much I could get done if I only had an extra hour each day. By saving me from the commute, working remote provided that extra hour. I found that when I was on a roll with work, I could just keep coding through the time I would normally spend commuting. Other days, it gave spare time to devote to continuing education. But I found that even if I devoted that extra hour to things which had nothing to do with work, it still helped my productivity, by letting me be better rested for the next day.

Freedom from distractions

Programming is a kind of work which requires deep concentration. We do our best work when entering a state of "flow", a mental state where everything except the project recedes into the background of our minds. It's not a state that we can just enter on command. The best we can do is to create a set of circumstances where it's likely to happen, and then do our best not to resist it. It's like falling asleep. And like sleep, it's easily broken by interruptions. Even a relatively private office space with high-walled cubicles is still filled with interruptions: Loud conversations a few cubicles over, unnecessary meetings, the noise of people passing in the hallway. In open-plan offices, the situation is much worse

Freedom from looking busy

In my experience, the best way to get into sprints of flow is to take genuine, totally disengaged breaks between sprints. This is difficult to do in an office environment. In a crowded office, there is always pressure to look busy.

With coworkers always watching and the boss walking by once in a while, I feel self-conscious even browsing the news for five minutes, or staring at the ceiling and thinking. By contrast, while working remote:

• I can go outside and exercise. In most corporate offices, there's not even much space to stand up or walk around, much less get down on the ground and do some pushups. During the project where I was working from home, I was surprised how often I could turn an unproductive day around by closing my computer and going for a run mid-afternoon.
• I can go for a change of scenery. Again, sometimes leaving my normal working space and heading out to a coffee shop or a library is just what I need to break out of a rut and get the creative juices flowing.
• I can lie down and take a nap for half an hour! Degenerate, you say? Maybe it is.... but... look, I don't stay up unreasonably late partying on work nights. But we all have those nights where sickness, or family needs, or plain old insomnia prevent us from getting a full night's rest. It's far, far better for my overall productivity to nap for half an hour and come back recharged then it is to lurch through the day, my flag flying at half-mast, my body doing little more than warming my office chair, trying to do the bare minimum of work to survive until 5 PM.

There's something all of these have in common. They boost my productivity for the day, but they fail to look busy. In other words, the need to look busy is an impediment to productivity.

Freedom of trust

I remember back in college, the least challenging classes were the ones which counted attendance as part of the grade. It makes complete sense. There are only a hundred points to go around, and every point which is counted towards something easy like attendance is a point NOT counted towards something difficult like exams or projects. In a typical office role, the evaluation of an employee's performance might look like:

• 5%: Wears proper business attire
• 15%: Submits daily status reports that are detailed and prompt
• 20%: Is in his cube during core hours and beyond. He's there when you arrive at 8:30, and is still there when you stay until 6:00
• 20%: Looks earnest and business-y whenever the boss walks by. You never see him browsing Facebook, listening to music, or watching clips on Youtube
• 15%: Is polite and agreeable
• 20%: Meets deadlines
• 5%: Displays leadership

This unintentionally creates an environment where its possible to meet 80% of what it means to be a perfect employee without producing anything of value

Remote work places less emphasis on the appearance of being busy. Without that crutch to lean on, there's only one way to prove my value to the company: Actually getting stuff done. This sounds like it would be a lot of pressure. My experience has been the opposite: That it is tremendously liberating. The fact that I'm trusted simply to accomplish the project by whatever means I think best, gives a whole different perspective. It gives a greater sense of ownership, a feeling of confidence that my input into the project matters. If I'm trusted to use my time wisely without a manager checking in to see if I look busy enough, it gives me a desire to continue earning that trust.

The challenge of isolation

"Fine", you say. "I can see that working outside the office might be better for individual productivity. But what about collaboration?"

I think we've all been in this meeting before. You file into the conference room with the other attendees, all except for Ted, who's working from home today. When you arrive, you find the meeting organizer deep in concentration over the speaker phone in the center of the conference table. Finally, after 5 more minutes of false starts, amidst a couple suggestions that maybe she should just give it up and get started on the meeting, the connection goes through! There's an electronic beep, and everyone hears Ted's voice coming out of the speaker phone.

Well, after a fashion. You can make out what he's saying if you really concentrate, but the sound quality is not that great.

But now the meeting is underway. When Kim has a question for Ted, she leans into the phone and speaks with the loud, slow voice she would usually reserve for her hard-of-hearing great aunt. But after the meeting gets rolling, everyone more or less forgets about Ted. Despite their best efforts, he's really more of a bystander. It doesn't help that he has trouble hearing anyone who's more than a few feet away from the speaker phone.

In our business culture, "Phoning it in" has become stock phrase for half-hearted work. While Ted will still receive a full day's pay, the whole experience leaves everyone with a sense that it's kind of an easy day for him. He's probably taking care of his sick kid, or has some sort of doctor's appointment, so that his mind isn't totally engaged with work. If you need an in-depth discussion with him, its best to save it for Monday when he's back in the office.

I believe that even in an environment like this, it's still possible to thrive as a remote worker. The benefits of productivity still outweigh the difficulties of collaborating, if I go the extra mile to make myself present. It is still important to come into the office at least occasionally for meeting and socializing. I need to make myself gratuitously available via instant messenger, via phone, and particularly via video chat and screen sharing. There's also an educational component, of teaching my colleagues to be comfortable using these different media to communicate with me.

Remote First

But for a company to maximize the benefit of remote work, it's better if they create a remote-first culture. We discovered years ago that the way to make webpages work on smartphones isn't to start with a full-size web page and try to shrink it down. It's to design the mobile experience first, and add additional content as it scales up. In the same way, the best way to get the most out of remote workers is to design systems of collaboration with remote work as the default, and build out from there. Speaker phones for meetings have been around for 40 years. In this age of ubiquitous high-speed internet, with a high-definition camera embedded in every laptop and smartphone, we can do better. The best solution is to have all meetings take place over video conference by default.

At first glance, this sounds like a second-best to in-person meetings. I've found that, much the same way that designing webpages for mobile often makes the desktop experience better as well, remote-friendly meetings are usually better meetings. They tend to be more tightly focused. They make it easier to use visual aids via screen sharing. If you need to grab one person's attention for a quick question, you can do it via IM, rather than by taking the entire meeting off topic.

The best solution is to have all meetings take place over video conference by default.

IM tools like Slack allow people to keep in touch throughout the day, in a way which is less intrusive than dropping into their cubicle. For code review and collaborative programming, screen sharing technology has advanced by leaps and bounds in the last few years. Tools like Google Docs, Screenhero, Cloud9, or VS Code's Liveshare allow multiple people to edit the same document at the same time, by giving each person their own cursor.

Talent Pool

From the perspective of a business owner, I can see the pluses and minuses of remote work. Technology can go an awful long way in reducing the difficulty of collaborating, but there will still be times where it lacks something compared to sharing a room (Though I'd argue, being remote is always going to be better for collaboration than an open office where everyone hides between their noise-canceling headphones). On the other hand, the individual productivity gains are pretty undeniable. But there's one extra factor which ought to tip the scales for any software-oriented company that's considering remote work. Hiring is tight right now, especially for developers. Unless you are one of the FAANG technology companies, you are almost certainly having trouble finding and retaining talented people. Developers like working remote. Allowing remote work costs nothing, and it is so desirable that it puts your company in the running against the Facebooks and Googles of the world in the war for talent. It expands your hiring pool from your particular city to the entire English-speaking world. It takes courage for managers to relinquish control and allow their employees so much freedom, but those who do so will see tremendous payoff.

Personality-type systems carry a golden promise of increased understanding, both of myself and of the people around me. They are a staple of pop psychology which I find myself fascinated with.

The typical system involves taking a multiple-choice quiz, which identifies you as being weak or strong in a few key personality traits. It then uses that information to offer you a profile of your innermost self.

Let's look at an example! A particularly popular one is the Myers-Briggs system, which assigns you a personality based along 4 characteristics.

• Extroversion vs Introversion (E or I):
  Extroverts are energized by being around people. They come away from a parties feeling pumped, and are happy to go out with friends as a way to unwind after work. Introverts find their sense of energy drained by being around people, even people they enjoy. They need time alone to recharge.
• Sensing vs iNtuiting (S or N)
  Intuitive people tend to see the big picture, and prefer broad theories and abstract ideas. By contrast, Sensers are detail-oriented and prefer hands-on learning and concrete ideas.
• Thinking vs Feeling (T or F)
  Thinkers make decisions based mostly on logic and reasoning, whereas feelers make decisions based on consideration of human emotions.
• Judging or Perceiving (J or P)
  Judgers prefer an ordered life of lists and plans, whereas Perceivers prefer to keep their options open and delay making decisions until they have as much information as possible.

You take your letter from each trait, and combine them into a 4-letter personality type, like ESTJ. This maps to a description of a personality, which you will probably find is at least a pretty close description of who you are.

(Image source: https://www.16personalities.com/)

Its kinda cool. I encourage you to give it a try. My initial results were as an INFP, and I read the description and thought, "Yeah, that sounds like me!". But then I noticed something. If I read the the description for the neighboring personality type INFJ, I thought, "Yeah! That's even more me. Or at least I find it more flattering." I retook the quiz with that in mind, and, lo and behold, I was actually an INFJ.

I found that I could fall into any of Introverted-iNtuitive personalities, by taking a different quiz purporting to measure the same thing, or taking it on a different day, or in different mood. And really, I could find at least something of myself in all of personality descriptions associated with those. Maybe, then, I just have a strong preference for Introverted Intuition, and weak or no preference between the other two letters, and I fall somewhere amongst all the personality types outlined in that quadrant of the graph.

A little later, I found myself digging deeper, asking what the Thinking-Feeling dichotomy is really getting at. Best I can tell, I try to do both when I make decisions. I consider all sorts of factors, including the feelings of people involved, but I sometimes go with my gut over any logical reasoning that I can articulate. I think that's what most people do. It seems like a minority of people would fall strongly into one category or another: Either driven mostly by remorseless Vulcan logic, or driven mostly by passion and sentiment. I would bet, actually, that they are independent variables, and you can be strong in one, both, or neither. We feel like there ought to be a balance in the world: That the person who is intellectually weak ought to be filled with kindness and homespun wisdom, while the genius inventor ought to suffer from crippling social awkwardness. Rarely is the world fair like this. More often, the person who is talented in one thing is talented in many things.

As I think about if more, some of the distinctions between the categories are ambiguous. What distinguishes the detail-orientation that powers the list-making Judger, and the detail-orientation that underlies the Senser? What's the difference between decisions based on iNtuition and decisions based on Feeling? It seems like there's a good bit of fungibility between the last 3 letters of the type. They can all be taken as describing a preference for the concrete (Sensing, Thinking, Judging), vs the fuzzy and abstract (iNtuiting, Feeling, Perceiving). In practice, this gives a lot of wiggle-room to tilt yourself into whichever type you like best.

I also noticed that all the Myers-Briggs types made much more sense when I tried applying them to myself than when I tried applying them to other people. If you read the various descriptions, you don't come away thinking, "Oh yeah! I knew a guy who was exactly like that." When you compare two people who have the same type, they often don't seem to have much in common.

This led to a disappointing realization: All the personality descriptions associated with Myers-Briggs types have the same sort of flattering vagueness as personality descriptions associated with being a Scorpio, a Gemini, or a born in the year of the Dog. Many of the points they describe follow the pattern of, "Though they may seem {some trait} on the surface, friends who get to know them will realize that they really have a strong streak of {opposite trait}" Anybody who is a mix between {some trait} and {opposite trait}, which is everybody, will be able to identify with this.

I've ended up with similar impressions of other personality typing systems I've looked into. But in the end, I still enjoy them.

They can prompt interesting discussions, and illuminate personality traits and tendencies I hadn't even considered before. Where they fail is in trying to extrapolate a generalized personality type from a few specific traits. Being an ENTJ doesn't mean you match up with the fundamental human archetype of the Fieldmarshal, it just means you are extroverted and a have a particular combination of preferences between concrete and abstract ways of approaching the world. In this system, being someone who responds to internal motivation means you are someone who responds to internal motivation, but it doesn't mean you conform with the personality type of the Questioner.

Interestingly, there is one personality system, which DOES seem to reach a little deeper. I refer here to the Big Five personality traits, also known as OCEAN or the Five-Factor Model.

This system is less ambitious than say, the Myers-Briggs system. While Myers-Briggs is a popularization of Jungian psychological theory which purports to really get at the meat of how people think, Big 5 doesn't attach to any underlying theory about where its traits come from. It's more inductive. It's really just derived from psychologists asking people thousands of questions about their personality and preferences^[1][2]. When they do this, they notice a few big clumps of traits which have a tight statistical correlation with each other.

For example, it seems that one clump of attributes includes things like punctuality, responsibility, carefulness, orderliness, rule-following, thoroughness, focus on goals, self-discipline, and attention to detail. If you have one of these attributes, you are more likely to have others. Many studies indicate that this statistical clumping is pretty universal in human cultures around the world, and the degree to which individuals align with the clump tends to stay pretty constant over the course of their lives. Most people will also intuitively notice that all of these attributes seem interrelated. Psychologists theorize that there is one underlying trait which influences all of them. They give it a name which seems to capture the gestalt of those attributes: Conscientiousness.

There are four other traits they identify in the same manner. Together, they go by the acronym OCEAN. They are:

• Openness to Experience: The degree to which you appreciate new experiences. Associated with curiosity, creativity, imagination, and adventurousness
• Conscientiousness: The extent to which you feel compelled by duty and order.
• Extroversion: The extent to which you draw energy from being around other people. Associated with assertiveness, talkativeness, and enthusiasm.
• Agreeableness: The tendency to be considerate of the feelings of others, to cooperate, and to avoid conflict.
• Neuroticism: The tendency to experience negative emotions strongly, particularly stress and anxiety.

The Big 5 traits have gathered widespread acceptance among psychologists as a pretty decent measure of personality. They succeed in a number of things that popular personality systems fail at. The Big Five characteristics are fairly stable throughout our lives. Anecdotally, it does seem that if you meet two people who have a similar Big Five profile, you really do get a sense that they have pretty similar personalities. But nonetheless, The Big Five system has failed to capture the popular imagination the way the Myers-Briggs system has.

I can think of a few reasons for this. The Horoscope-like personalities that come out of a system like Myers-Briggs tend to be flattering, but also balanced. Sensing isn't better or worse than Intuiting. The two are like yin and yang; masculine and feminine; heads and tails. It takes both to make the world go 'round.

The Big Five system, by contrast, indicates something which we all knew but didn't want to admit: That some people just have better personalities than others. I think most people would look at someone who's Extroverted, Conscientious, and Agreeable, and say that's a preferable personality to being Closed-minded, Neurotic, and Disagreeable^[3]

Also, most personality systems give a solid sense of identity, of resolution, with their either-or dynamic. Even though both Big Five and Myers-Briggs recognizes Extroversion vs Introversion as being a key trait of personality, Myers-Briggs asserts that most people fundamentally fall into one category or the other. Big Five theory sees people as being distributed across a spectrum. Only a minority of people are going to be strongly extroverted or introverted. Most will be somewhere in the middle, with a moderate leaning one way or the other. It also seems to imply that having a personality which is too extreme towards one pole can lead to troubles, even for a generally positive trait like Conscientiousness (eg, becoming a rigid perfectionist or a workaholic).

Its interesting to me that the things which hurt the truthiness of the Myers-Briggs system are the very things that make it so compelling. What we really want is a personality inventory which gives us deep insight into what makes us all tick, not just a comparison of characteristics. And it seems that, much as we would wish for it, that's something which psychology has not yet produced.

Programmers hate corporate process.

We are constantly fighting to simplify it. But in the course of fighting it, we are tempted to lose sight of how excessive process is not fundamentally a technical problem, but a symptom of lack of trust within the organization.

I divide corporate processes into a few broad types

The Manual Process

This is the first thing you think of when you think "Corporate process". It is the bread and butter of any bureacracy. When you want to do something, it involves submitting some kind of form, and taking it through a list of prescribed steps. Do you want to get reimbursed for your business travel? Submit an expense report. Do you want to get paid for the week? Submit a timesheet to HR. Do you need to pay your taxes? The IRS has many, many forms to help with that.

The Automatic Process

If the "expense report" process above involves filling out a form by hand and faxing it, it could be much improved by emailing a Word document. That Word document could be replaced by a PDF template. The process could be further improved by replacing the pdf template with a form page on the company intranet. Then, whoever is responsible for reviewing expenses could approve it with a single click. There might be other automations that are possible: Some ability to automatically fill in the online form by scanning your credit card statement, or by taking a cell-phone photo or your receipts.

We developers love to do this sort of thing. For many of us, making these fusty bureaucratic processes more efficient is our calling in life. The goal is to eliminate any hand-copying of information from one place to another. Rather, it ought to be entered only once, and from there a computer can route it where it needs to go.

But, sometimes I fear that us developer are over-eager to attack these processes. Moving from a pencil-and-fax form to a pdf form might do away with 2/3 of the time spent on the process, and only take an afternoon to set up. If it was a half-hour process before, it would now only take about ten minutes. But getting a Web Form that automatically enters the expense report into the database might take a week of programmer time, and only shave the time spent on the process from ten minutes down to five. Getting that receipt scanner working could take months of programmer time, and only move the process from five minutes down to three. In other words, the return on investment from further automating the process falls off at an exponential rate.

Writing that receipt scanner could still be useful if there are 20000 people in the company who frequently submit expense reports, or if this "expense entry software" is a product you're developing to be sold around the world. But its simply not going to be worthwhile for smaller operations.

My even larger concern, though, is that focusing on improving manual processes is sometimes barking up the wrong tree. As boring and frustrating as they are, they are only scraping the surface of how inefficient corporate processes can become.

The Permissions Process

I'm a new employee starting at the company, and I ask around for how to submit an expense report. "Oh," I hear, "Fred's in charge of that sort of thing. His cubicle is up on the 4th floor. Here, I'll give you his email" This is the case where there is no mechanical process. Rather, there is a guy who is in charge of approving and dispensing travel reimbursements.

In some organizations, this can be alright. Sometimes Fred is a really helpful guy. He knows the system inside-out, and will even advocate for me, suggesting reimbursement for things which I hadn't even thought of, and waiving requirements for receipts I forgot to save. For something trivial like expense reports, this is still not very efficient, though it might be just fine if its a small company with only a couple people submitting expense reports in any given month. What took a half-hour when conveyed through a pencil-and-fax form is now closer to a round hour when you add up the time me and Fred spend on it. It's drastically worse if helpful-Fred is replaced by two-bit-tyrant-Fred, who rules over his tiny fiefdom of expense reports with an iron fist, who loves issuing opaque denials and haggling over trivial amounts of money in order to shew forth his power.

The Process by Committee

But my grousing over tyrant-Fred aside, sometimes this permissions process really is the best way to go. It's overkill in the case of expense reports, but there are other processes where in the course of them, some significant judgement call needs to be made. It might be something more along the lines of, "Our engineers have identified this list of bugs in our software, and we need to make a decision on which ones need to be fixed immediately, and which ones can be postponed" In these cases, having one person like Fred whose expertise and judgement is widely trusted, and giving him authority to make those calls, might be exactly the way to handle things.

But suppose there isn't one guy who is trusted to make the final call. Maybe there used to be, but there was one time, long ago, when Fred made a mistake. Fred's mistake caused some sort of embarrassment to the folks higher up the chain of command, and they decided that it couldn't be allowed to happen again. Maybe Fred left the company, and no one person could replace him. Whatever the cause, there is no longer a single individual who is entrusted with making the judgement calls.

If it's an expense report, there's no longer one "Fred" who I can take it to for approval. Rather, I'll be told, "Bring it up during the next Expense Request Approval Meeting."

This is the true ninth circle of corporate process.

A few common features of committee processes:

• There will be a meeting scheduled on a daily or weekly basis, whose purpose is to move a routine process forward
• In between meetings, committee members volley issues back and forth via long email chains
• Anybody in the committee can say "no", but it takes everybody to say "yes"
• If you observe the committee, you have a nagging feeling that the purpose of the whole thing is to dilute responsibility. It's less to prevent things going wrong, and more to make sure that when something does go wrong, no one person catches the blame.
• Whenever something goes wrong, the committee will add more steps to the process, to "ensure that it never happens again". This leads to greater complexity; to items such as a meta-process to manage the agenda for the daily committee meeting.

Due to that last point, the size of a committee process grows with time. Do you ever wonder how some bureacracies seem to have their expenses increase exponentially over time, but without improving the quality of their services? I credit Scott Alexander with giving it the name, "Cost Disease". It's a major social problem we have in sectors such as healthcare and higher education. I suspect one of the main causes of Cost Disease is that many, many things which should happen automatically are done by a system of individual permissions, and many, many things which ought to be decided by individual permission are decided by committee. I notice such a strong correlation between regulated industries and cost disease that I can't help but suspect that there's something about regulation that encourages organizations to seek safety from individual responsibility by burying it in committee-type processes

The Mu process

At the other end of the scale, there is a transcendent moment of enlightenment, where the process disappears. In the running example of expense reports, there would be no expense reports. If I travel, my boss just hands me a company credit card, with his full trust that I will use it responsibly. There is a pattern I notice here. The transcendent non-process can only occur in an organization which places high levels of trust in ordinary employees. By the same line of reasoning, excessive process is a sign that the managment of an organization does not trust employees to make reasonable judgements.

There's this article on quitting Google that was going around the web a few weeks ago.

My first thought reading it was, "Wow! It sounds like the promotion process at Google is a little broken".

But Google isn't dumb. On further consideration, (and also thanks to this enlightening article) I think their promotions process is working exactly as intended.

Let me explain with an example. I knew a guy once who worked in the IT department of Name of Giant Retail Corporation Redacted. Like most employees at Redacted, he was a contractor, and had been for several years. He was in the running for a promotion. The promotion would allow him to become a salaried employee rather than a contractor, and move his title up from senior developer to lead developer. The promotion process was arduous: He had to wear a suit and tie to sit for a panel interview. Once he passed that, he was given a trial project with a deadline in 4 weeks. It was a project far too large to be accomplished by one developer in that timeframe, no matter how good he was. To receive the promotion, he had to prove his leadership ability by recruiting fellow developers to help with the project, delegating pieces of it, and successfully pulling the whole thing together.

Now, this guy was a superb developer. Not only was he skilled at coding, he was one of those people who has such a genial temperment that he made any group he was in work better together. He didn't need to jump through all those hoops to get a better title, salaried benefits, or a raise. Plenty of other companies would have lined up outside his door step to beg him to accept such things.

But somehow, the very fact that the promotion was difficult to attain made it desireable. People who were salaried employees within the company (remember, a benefit that most companies give to everyone) wore it like a red badge of courage; something awarded to only the few and the proud. It literally involved receiving a different-colored access badge. It helped create a self-image of a company composed of only the top engineers: Either engineers who were competing for the highest honors, or intellectual giants who had obtained them.

In other words, the purpose of the arduous promotion process at Google and Redacted isn't to make sure that the senior engineers are a corps of the best of the best of the best. It's to give all engineers a brass ring to chase after. People who have plenty of opportunities elsewhere will stick around year after year trying to prove to the company (and even moreso, to themselves) that they are worthy of the big promotion. People who have earned that promotion will feel a mighty sense of achievement; both a feeling that they only made it into this elite club by the skin of their teeth and a little luck, and a feeling of pride that they were able to earn it. They will hesitate to relinquish that status by moving on to a different company.

I can't really criticize Google or Redacted for pulling these tricks. It seems a little manipulative, but I can't argue with its effectiveness. It certainly allowed Redacted to maintain a higher quality of engineering than they would have been able to otherwise, and without even paying extra for it. But for our own sake, I can't help but think that its better for us developers if we refuse to participate in these sorts of games.

We understand that American society today is divided into four broad social classes. But while we acknowledge the existence of different classes on an intellectual level, it isn't something we notice on a day-to-day basis. This isn't because class is unimportant, but more that we don't notice it in the same way we don't notice the air we breathe. Even though your class is only a third of the country's population, the odds are that you (yes, YOU) do not have any close friends who are part of a different class.

What divides these classes is something subtle. We often talk about class in terms of income levels, but I suspect that income is secondary to something deeper. The fundamental divide is a different set of attitudes towards work; a difference in your expectations of how you will make your living.

The Lower Class

The intermittent workers

If you are a member of this class, you probably did not graduate from High School. You rarely work a permanent job. Instead, you tend to patch together a living from part-time work, seasonal work, one-off gigs, and government benefits, and the hospitality of friends. If you are in a situation in life where you are working very hard, say, to support your children, you probably work multiple part-time jobs. Recreational drug use is common in your circle of acquaintance. You likely have no more savings than a couple week's pay, and are carrying debt.

The Blue Collar Class

(aka, working class)

If you are in this class, you expect to have a job. The pay might be less than a lower class person would achieve from multiple part-time jobs, or it might be more than most white collar people make. But there's a key difference: In the blue collar class, high pay is less important than high stability. You have a job, and you plan to do that job, ideally even for the same employer, through your whole working life. This job is the source of much of your identity, and much of your security in life. You probably have at least a GED, and might have an associate's degree, but the traits that help you succeed are ones that you learn in primary school: orderliness, timeliness, politeness, consistency, perseverance throughout the day, the 3 R's, and attention to detail.

The White Collar Class

(aka middle class)

This is my own class, and if you're reading this post, it's probably yours as well. Though it's often called the middle class, most people in it are above the median income. Only 30% of American adults hold bachelor's degrees, but they are the norm in the white collar class. This makes sense, because the traits that get you ahead in this class are the traits that colleges try to teach: perseverance in the face of failure, confidence, creativity, continuous self-education, initiative, and long-term planning

The key distinguisher is that white collar people don't identify themselves by their "job" the way a member of the blue collar class would. They identify themselves by their career. Your security does not come from your relationship with your employer, rather, it comes from a portable skillset that you are confident you can market to many different employers. Your concern is less with stability and more with growing that skillset, gaining more experience, and taking on increasing responsibility, and you will voluntarily change jobs to advance that concern.

Here's, I think, the fundamental divide: a blue collar person would be proud to say that he's worked at the same job at Acme for twenty years. A white collar person would be a little embarrassed.

The Upper Class

It appears to me that there exists another echelon above my own White collar class. I only get vague impressions of their existence even, so what follows involves a lot of conjecture.

The key distinguisher is that in the upper class, unlike the white collar class, you do not identify yourself by the contents of your resume. Your security, instead, comes from your reputation within a broad network of professional relationships.

It appears to me that the art of cultivating these relationships is something you can learn from your parents, and it gets taught in a few top-tier colleges. But more than college, it's something you learn in high school. Every big city has at least one elite high school which teaches students how to nurture professional relationships of the sort which upper class membership is built on. If you have acquired those skills by the time you're 18, you can spend your college career growing your network at any modestly prestigious university.

I think some doctors and lawyers, many professors and journalists, and most corporate executives, Washington politicians, and successful entrepreneurs, are part of the upper class.

As white collar people don't worry about keeping a particular job as long as they have marketable skills, upper class people don't even seem to worry about keeping a particular income as long as they have strong relationships. It appears to me that early in their career, they manage to leverage their relationships from school to gain a valuable internship, or a position with a non-profit. It might pay next to nothing, but it lets them further grow their network of professional relationships. Based on those relationships, they have quite a few options. They will often advance to new positions of greater responsibility by being invited into them. They also have a solid platform to find investors and collaborators if they want to launch their own business: Even if it fails, the experience and contacts they gain will make it worthwhile.

Here, I think, is the fundamental divide: A white collar person's security is best summed up in his resume. An upper class person would tell you that if you got your job by submitting a job application and a resume, you're doing it wrong.

It's an odd quirk, but it seems to me that the upper class really has at least as much in common with the blue collar class as with the white collar class. In both classes:

• The key to your security is relationships. For blue collar people, its the deep-rooted relationships with your employer, boss, co-workers, and possibly your union.
• The formative years that prepare you for your career are your late teenage ones, while for the white collar class, it's your early twenties
• The white collar class is not really entrepreneurial, while both the upper class and blue collar class are. Most successful startup founders are members of the upper class, while for blue collar people, the highest form of career advancement is to own a successful small business.

Class Mobility

In a way, these classes display a lot of the effects of American egalitarianism. If you act like a member of the upper class or the white collar class, people will treat you as such, regardless of who your daddy is. The problem is that skillfully acting in the manner of a different class is very difficult to pick up if you haven't learned it in childhood.

If you're a blue collar person, the job hops that a white collar person takes as a matter of course in advancing his career look insanely risky and a little dishonest. You're giving up a stable job and proving yourself to be disloyal! Furthermore, it doesn't work if a blue collar person just says to himself, "So! The secret is to take huge risks and be disloyal? I'll give that a try!" He'll find himself trying to dance to a music he hasn't even learned how to hear.

Likewise, to a white collar person, the career moves that are par for the course in the upper class look insanely risky and a little dishonest. You're founding a startup which might never make a dime, and you're spending all your time schmoozing and bumping elbows! It also doesn't work for a white collar person to just say, "So! The secret is to take huge risks and schmooze? I'll give that a try!" I think to an upper class person, watching a white collar person try to "do networking" has a certain cringe factor, like a Parisian feels when listening to an American tourist try to Parlan Fransway. The elements are there, but they are executed so maladroitly that they do not produce good results.

Politics and the plight of the Blue Collar class

In the last few decades, the stable unionized manufacturing jobs which were the backbone of blue collar employment have been disappearing. The jobs that are replacing them... it's not necessarily that they pay less, but they lack the stability which is more important than money to the blue collar class. They are prone to layoffs. They might require extensive retraining or require moving away from your home in the town where you have built your life and have a deep social support network. Their health insurance and pension benefits range from stingy to nonexistent. In other words, they look more like lower-class jobs. The American blue collar class, as a whole, feels that it is being bulldozed into joining the lower class, and that nobody cares.

In the 2016 election, the blue collar class voted en masse for Donald Trump. It's not necessarily that Trump has a solution to their problems. These are difficult problems, and they are not amenable to easy political answers. The causes seem to have little to do with politics, and lots to do with how the world has changed: How technological advances have destabilized whole industries, and how the US is no longer the world's only economic powerhouse.

But at least Trump listened to the blue collar class. He acknowledged that their struggles are real, and promised to try to help. Democrats really didn't. My dear democrat-voting friends, I know this isn't what you think, in your heart of hearts. But your fellow democrat's reaction to the plight of the blue collar class often comes out sounding like, "Your skin is white and you are male, so by definition you are privileged. You don't have real problems. If you think you are struggling, that just means you're really a racist".

Where is this coming from, democrats? You were supposed to be the party of the working man, of the little guy. You're acting as the party of white-collar contempt for those dirty people in their flyover states.

Sources: Most of this is just my intuitions from watching people and reading newspapers. Take it with a grain of salt. Some of the perspective also comes from reading Charles Murray's Coming Apart Header image courtesy of Wikimedia commons

I generally market myself as a "Full-Stack" Developer.

It's an overused term, to the point that it risks falling into meaninglessness, like "Synergy". But I think there is an important distinction there, beneath the recruiting buzzword.

Web or web-connected applications (which is most software, these days), exist in a multi-layered stack of technologies.

In other words, there are distinct components, which use different libraries and even different programming languages. The user interacts with a "client" application on their device, usually either a mobile app or a web page. That client is in constant communication with a server over the internet, and that server communicates with a database to store and retrieve information.

For a team working on this kind of software, there are two common ways to divide up responsibility:

Specialist Teams

Developers work in teams which are specialized in one section of the stack. Frontend Developers take care of the user interface and client-side behavior, and Backend Developers take care of the server-side and database. Usually, they will not have any familiarity with each other's code.

In some large organizations, responibilities can be split even further. You can have User Experience Developers -> Frontend Developers -> Backend Developers -> Database Administrators, all owning distinct slices of the stack.

Generalist (Full Stack) Teams

On these teams, everybody is responsible for everything. This tends to be a more common system in small companies. If there's just one team of six developers in the whole company, it's not very practical to have frontend or backend specialists. If a project comes along which is mostly backend work, it's much better if any and all developers in the company are able to jump on it, rather than just the two backend guys. Generalist teams tend to have total ownership of a smaller number of projects.

Really, full-stack is a better description of team organization than of developer skills. While most Developers have a preference or a proclivity for one section or another, most of us are capable of doing work across the entire stack. We learn our craft by working on small, solo projects first, and solo projects are full-stack by definition.

Specialized teams have the advantage of deep knowledge. It's hard for one person to be both an expert in the latest javascript build tools and an Oracle maven at the same time. If your product is something as vast as say, Facebook, it's not feasible to have any one person be familiar with anything more than a small slice of it. For a product which never has more than a few hundred concurrent users, it's perfectly fine to use a vanilla database setup created by a non-specialist. A product with thousands or millions of users requires someone with deeper knowledge. He will need to make the database operate at maximum efficiency, and to coordinate between multiple instances.

I'm coming to suspect though, that specialized teams are at best a necessary evil.

Over-specialization is costly in terms of communication. A single feature typically spans the full stack: It will need a new page on the front end, which will need to contact a couple different API endpoints on the backend, which will require a new database table and new rows in several old tables. In a full stack team, this can be handled by a single person. On teams of specialists, it requires coordination between multiple people across organizational boundaries

Not only is this slower, it can lead to less than ideal designs. Database administrators will try to control as much of the application as possible by packing business logic into stored procedures. Backend Developers will try to render things server side which could be done much more efficiently on the client side, and frontend developers will sometimes store bits of data in local storage when they really ought to be persisted on the server.

It's sometimes a power play, and sometimes it's because when your only tool is a hammer, every problem looks like a nail.

But most often it's because it's the path of least resistance. If I'm on the frontend team, and I realize that I have one single solitary little counter which I'd like to store for later use, I might think, "It would be such a pain to get the backend team involved with this. It would mean meetings, and changing the requirements documents, and manager signoffs. It would be so much easier to just store it in the browser's local storage. That's not quite the proper way to do it, but it would work for 99% of users."

I think this illuminates the greater problem: That this division tends to make design of the software inflexible. If responsibility is split between a frontend team and a backend team, then neither team has the authority to make even simple changes in the design. It tends to give rise to an additional caste of architects and project managers, whose job is to coordinate between the frontend and backend teams. This creates yet another line of communication which has to be maintained.

I suspect that, even in fairly large-scale projects where it's necessary to have frontend or backend specialties, it's better for backend developers to have at least some familiarity with the frontend code, and vice-versa. The ideal, I think is for every individual to have a T-shaped distribution of skills: A little bit of everything, and deep knowledge of one thing.

My current employer has a very strange policy: They actually abide by most of their own rules.

Most large organizations I've been a part of have two sets of rules: There's the written rules in the big book o' rules. But there's another set of rules, rules which are never written down. Often, the unwritten rules are even unspoken rules. They're alluded to only indirectly by winks and shrugs, statments of the written rules but with an ironic arched eyebrow, or by plain monkey-see-monkey-do. Often, they indicate places where its forgiveable or even required to break the written rules.

One example I see in many large corporations is a written rule that only approved software can be installed on company computers. But at most of those companies, there was a shared understanding among the developers that they could really install any software they pleased. I have even worked at one company where several software packages which were critical to their infrastructure were not part of the official approved software list.

A Twofold path

It seems to me that to some extent, the twofold path of rules performs a valuable function in society. It can state an ideal which we strive towards, even though we only actually punish extreme aberrations. Consider many of our traffic laws: I've never known somebody to be arrested for jaywalking, but having a law against it sets things up so that if I get run over while jaywalking, it moves the presumption of innocence towards the driver. Likewise, we constantly break the legal speed limit in order to match pace with traffic, which the police usually tolerate. Within limits, it's simply a measure of sanity. No rulebook can possibly account for every real-life situation, and having a loose enforcement of less critical rules can be a mere acknowledgement of this reality.

But it seems to create a dangerous situation if the unwritten law and the written law diverge too far. In politics, it seems to form an easy path towards corruption. As I've read about recent difficulties in Venezuela and Myanmar, what struck me is that those countries aren't lawless because there aren't any laws. They are lawless because there are so many impossible, contradictory, rent-seeking regulations that it becomes impossible to run a business, to do much of anything in the public sphere, without breaking some kind of law. If the written law becomes a thicket of ambiguity and impossible demands, the only way to get anything done becomes to have friends who know their way around the unwritten law. Those friends can be acquired; all it takes is a few tokens of appreciation for their hard work as public servants...

Rule By Fear

I remember Toqueville pointed out that governments tend to impose disproportionately large penalties when they can't catch many of the guilty. In other words (think of the story of Robin Hood), if poaching the king's deer is a hanging offense, its a pretty good indicator that people are shooting the king's deer all the time. They are almost never caught, so on the rare occasion the king manages to catch one, he likes to "make an example of him". If everyone's guilty of breaking the laws, it's easy to find a pretext to string up anybody who makes trouble. Our constitution's prohibition of "cruel and unusual punishment" seems designed to prevent exactly these sorts of laws.

Having written rules which are never followed tends to make them even more Draconian. It seems like a quirk of human nature: Whenever you have a rule-giver or body of rule-givers who are not consulted as often as they feel they should be, on the rare occasion they are consulted they like to throw their weight around by saying "no". This makes people even less likely to consult them in the future. Since they are usually ignored anyway, there is little pushback against unreasonable new rules they create. In other words, if the written and the unwritten rules diverge too much, there seems to be an entropy that pushes them further apart.

In a corporation, I've seen an interesting danger arise: All it takes is for somebody in a position of influence to say, "I know we've been playing fast and loose with the rules for a while now. But that needs to stop. We are going to be following our rulebook to letter now, and enforcing compliance through audits" to completely shut the business down. Labor strikes can even take this form sometimes, where workers can effectively shut down the operation simply by following the rulebook to the letter. I've worked in one department which more-or-less garrotted itself this way. They got in trouble once for following the written rules too loosely. They decided to stop doing that, but their rules had become so onerous it made it impossible to get much of anything done.

In the End

At my current office, I'm certainly annoyed by some of the rules. We developers are fond of our tools. Most of us have a favorite way of setting up a computer for coding, which is unique to each individual. That company policy only allowing approved software means I have to make some compromises in how I set up my computer. It's a rule that could stand to be changed. But in the end, I can't help but approve of the philosophy of actually following their own rules.