To me, the number 1 thing that predicts a tech lead’s success by a far margin is her ability to discern, negotiate, and clarify the goal. There is no point building anything if you are not building the right thing. People waste a lot more time building the wrong thing or to the wrong goal than they do on bad technical decisions.

A good PM will make this go a lot easier, but it’s an absolute must that the tech lead fully internalizes and understands the goals. Understanding the goal fully allows you to make good decisions technically and is key to velocity because you will have less communication overhead from constant need for additional context beyond the immediate task. I also believe it is the largest predictor of success because to truly get this right implies lots of qualities that are also critical for successes at the later stages in a project.

Following that, the next most important thing a tech lead can do is propose a sensible path of execution that hits that goal. Note: goal, not deliverable — because a goal can be fulfilled in many different ways.

A tech lead has the responsibility to propose the simplest path forward to a problem, but that doesn’t always mean the shortest path forward. Sometimes that path will seem slightly longer because it takes additional measures to incrementally release to the users for feedback or to guarantee a safer release by having parallel paths of executions — but the point is that taking those additional steps will mitigate the risks of your path spiralling out of control into a detour to the zoo because you didn’t build the right thing or you have all this technical clean up to deal with because you really screwed something up.

A path of execution cannot be viewed as a 100% weighted probability of a single path, single outcome — it’s instead more like a wave of probabilities that is constantly fluctuating. The job at this stage is to sum the weighted probabilities sensibly so you take the measures to minimize that detour to the zoo.

After all that then comes a host of things that are important that people typically talk about when they talk about tech leading. It has to do with how to most effectively follow through on the path that you proposed. It has everything to do with leveraging your team effectively, understanding technical tradeoffs and design for flexibility, recalibrating risks and plans as new information and understanding of the world comes in.

The straight line that you hoped to be a straight line or maybe even does look like a straight line from far away is more like a collection of tiny zigzags. The art of walking that path and leading others through it is also not easy — maybe a post for another time. That sum of weighted probabilities never goes away — it is not a static measurement and is instead a live calculation that you must keep tuning in your head.

A tech lead (in my current job) is not always a senior engineer, but it is a leadership position that requires maturity, discipline, and pattern recognition. If you love thinking about things like this, you would probably also enjoy one of my favorite posts of all times: http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/

What I talk about when I talk about tech leading was originally published in write or wrong on Medium, where people are continuing the conversation by highlighting and responding to this story.

If quantum mechanics allows new kinds of computation, why did physicists ever worry that the theory would limit scientific progress? The answer goes back to the formative days of the theory.

Erwin Schrödinger, who discovered quantum theory’s defining equation, once warned a lecture audience that what he was about to say might be considered insane. He went on to explain that when his famous equation describes different histories of a particles, those are “not alternatives but all really happen simultaneously.”…

How could such an apparently innocuous claim ever have been considered outlandish? It was because the majority of physicists have succumbed to bad philosophy: philosophical doctrine that actively hindered the acquisition of other knowledge. Philosophy and fundamental physics are so closely connected — despite numerous claims to the contrary from both fields…

The culprits were doctrines such as logical positivism (“If it’s not verifiable by experiment, it’s meaningless”), instrumentalism (“if the predictions work, why worry about what brings them about?”), and philosophical relativism (“Statements can’t be objectively true or false, only legitimized or delegitimized by a particular culture.”)

This sent a mini shock wave through me when I read it, because I recalled how much we studied these various schools of thought that were lauded as ushering in a new era of rationality and progress. I thought about how:

1. Even philosophies that once signaled progress can outlive their usefulness and become dangerous. Once anything is cemented as not just a useful, guiding principle, but a paradigm that demands (implicit) right or wrong, acceptable or not acceptable, you are at risk of not progressing to discover the next big understanding that will change your world
2. You have to try damn hard to always leave the things you are comfortable with behind— whatever truths or knowledge you have worked so hard to internalize, glean, systematize, or evangelize — Don’t be afraid to be wrong or outdated. Be afraid that you are one step further away from the truth of that moment or reality, or the next level of understanding that will alter your point of view.

It’s disorienting to grow, but it’s scarier to not at all.

Strong convictions, weakly held was originally published in write or wrong on Medium, where people are continuing the conversation by highlighting and responding to this story.

Data is more than bits on a disk that we wrangle. Data is a representation of someone’s life, and in our case as their insurance provider, the very intimate and sometimes vulnerable narrative of their health.

Healthcare data has a tough reputation rooted in legacy systems and byzantine standards, so much so that there are O’Reilly books written about it.

Pervasive archaic, non-intuitive (and often broken) standards, fragmented sources, rigorous regulatory standards — combined with unpredictable human errors throughout — all make this industry’s data require non-trivial effort to transform and integrate.

It’s easy to get lost in all that messiness. As data platform engineers at Clover, our goal is to, instead, take that mess and turn it into something useful. We set out to simplify that complexity and make information easily accessible, usable, and semantically richer for important operational decisions. In other words, we want to turn sequences of symbols and letters, into something that looks more like: “We know a member has this medical condition, because of this electronic health record that we received from this provider on this particular date, and we knew this as of this date in our system and used this piece of knowledge for this derived insight”.

Each piece of this data is a valuable signal we can use to improve the lives of our members. By freeing data from relic systems and creating rich connections between data points we can provide them a smoother experience, reduce administrative burden for staff and doctors, and provide targeted care management.

This is fundamentally different from how traditional insurance companies operate, who treat this data predominantly as transactions that are trapped in organizational and technological silos. At Clover, we want to treat turn these transactions into signals that feed into a larger, holistic narrative about our members’ health. We sometimes describe data as the blood that flows through everything we do: from operations, to product, to data science, to engineering. Within Clover, data is a public good that the data platform team strives to make better.

We do this in a multitude of ways. We work cross-functionally (stay tuned for more on how we do that!) with data science, analytics, and applications engineering. We work hard to model data in intuitive ways. We also build transforms and pipeline abstractions, data tooling, and interfaces to scale that effort.

What are the data challenges that excite us?

The biggest facet about data that excites us is always its immediate and tangible impact on someone’s health experience, and what more we can do to enable that. But hidden in that simple purpose statement is a myriad of complex technical challenges that require creative and rigorous problem solving. Here are some of the biggest technical themes that we face, how we are thinking about them, and snippets of what we’ve done so far to address them.

Complexity of data (because of life!)

Our biggest bottleneck (as of now) is not scale. Instead, it’s the complexity that is inherent in the delayed transmission between a real life event/concept and its entry into our digital systems. Because a health event ultimately originates outside of a digital system (and often, its first entry is into someone else’s digital system), many complications can arise.

Dealing with time robustly (multi-temporality)

Much of our data is an approximation or best-guess of what we believe to be true in real life (like an electronic record about someone’s diagnoses, or a membership record about someone’s low-income status). Much of our data, unlike data that is directly generated by a web application, also changes through many hands (the doctor, Centers for Medicare & Medicaid Services, our claims processor). This means that a view of some event in real life, does not always translate to how and when we know about it in our system.

What we know about a member’s doctor visits in April 2015 when we look at the data in April 2015 could be radically different from about what we know about the same time period when we look at the data again in July 2015. In order to accurately understand our analyses about some events in April 2015, we have to track not just what happened in real life, but also our evolving understanding of it.

We do this by giving our data richer temporal dimensions and frameworks to work with that in SQLAlchemy (a Python ORM library). For more details, check out our talk about it at DataEngConf!

Incorporating a framework for conflicting information

Because the data is a lagging indicator of a real life understanding, you can have situations where several different sources of data are supposedly pointing to the same real-life concept, but report different values. Say, for example, somebody’s address that is coming in from different membership and clinical records (Martin Fowler also has a great articulation of this facet). We have to allow for this phenomenon in our data modeling so that we can both capture the fullest context and make a best-guess of the truth.

This is especially tricky when dealing with attributes that have to do with someone’s identity (names, address, date of birth, Medicare identifiers), because it can change how we resolve the member identity associated with our other records. This also gains another dimension of complexity when we start overriding our understanding of external records through our own workflows.

Mapping digital signals to real life

Like Plato’s allegory of the cave, a lot of our data is ultimately like shadows of the real thing. In order to infer who a lab result is really pointing to (entity resolution), or to figure out what combination of signals in a claim (or a series of claims) indicate an ER visit, we have to deduce through pattern matching. This requires a solid understanding of the domain and its complicated real life entities, events, and associations (enabled by working with our operations and our formidable Data Science team) that we have to map into data transforms that add additional attributes or pull out useful concepts that we want.

Integrating and modernizing healthcare

Then, of course, working in an industry with antiquated, fragmented systems and highly regulated standards also brings its unique set of challenges — and, opportunities!

Integrating with archaic formats and interfaces

Healthcare has some not so fun data formats and not particularly sophisticated ways of sharing data. We have invested heavily in our data ingest layer to deal with the various phenomena and tragedies that can happen there (zip files containing more zip files, etc).

This is the layer that requires some of the most creative and rigorous problem solving and abstractions. We need to delineate the problem clearly — decouple the simple functional part of the problem (parsing data out of files) from the semantic interpretation of the data (it’s always tempting to excessively clean up and interpret the data) and the gnarly edge cases that come with the unpredictable nature of these data integrations (Did the vendor drop a file? Was it the filename pattern we expected? Did a file spec change unexpectedly?).

Meaningful data testing in the face of HIPAA

Healthcare data is sensitive and deserves treatment with serious respect and protection of privacy. We have strict policies around the restricted access and usage of Protected Health Information.

Healthcare data is also extremely multi-faceted, networked, and nuanced in nature. We ingest over 100 sources of data that have complicated entities and entity relationships. Our transforms often fail on data formats, values, or associations they did not expect. To be able to do testing and development well, we need forms of fake data and data testing that can easily scale with the varied sources and representation.

On top of that, we want to produce fake data that is not just structurally compatible, but semantically useful. To that end, we have to figure out a strategy to obfuscate or mimic our data in a way that still preserves some fidelity of what it means (as well all of its associations). That is hard (but we have started working on it).

Democratizing the data

Data, its access and delivery, as a public good

In some organizations with a data warehouse data is treated as a thing that is carefully architected and curated, that is served on a tidy, well-defined platter (the reality is of course always not so ideal, but such is the process). This implies gated access to who can define data schemas and deploy pipelines.

That’s not the world that we want to be in. We strongly believe that purposeful data access (that gives someone’s ability to do their job better — not simply any access) makes our data better, more meaningful — and multiplies the impact of everyone’s decisions.

We aim to make pipelines accessible to everyone on the tech team that needs to move and transform data. This means building tooling foundations that can support that. A specific example of this is building base abstractions (specifically in our case, through Airflow) that can generate pipelines programmatically through configuration.

We also want to make the data more discoverable. Someone should be able to ask a question about: “What do we know about someone’s clinical conditions, and where did this understanding originate from?” — and know easily where to find that, and it was last updated. We are rigorously tracking the data lineage and other metadata of our data artifacts that are the foundations of a catalog of all the data (original or transformed) that we know about.

Building a system that integrate the best of people & machines

Constructing a system with only computers is sometimes hard and exciting, but constructing a system with computers and people(!!!) as a holistic system is even harder and more exciting. As Clover data platform engineer Grant Wu best puts it, Clover staff are our eyes and ears; they are the “immediate sensory input” of Clover. We need their input to enrich the overall understanding of our members’ health. We also need their input to resolve nuanced data failures that have implications on data integrity (and hence, our understanding of the truth). For example: when two records about the same member come in with different Medicare identifiers — which one is actually valid? Building a data system at Clover means not just connecting computer systems, it means building interfaces that link the best of human judgment and machine prowess.

Having been at Clover for a year and a half now I am still constantly amazed by the depth of interesting technical problems we get to solve, the level of semantic richness that our data offers as a window into the world, and the immediate impact that our systems get to have on such a pivotal part of someone’s life. It has taught me to look at data through a totally different lens — less as a commodity that signifies throwaway actions originating from a screen — and more as the echoing signals of a sacred narrative about someone’s life. And we are just at the start of our learning journey.


*Big shoutout to Grant Wu for letting me use some of his words and ideas for inspiration on this post

Transforming Healthcare, Starting with Its Data was originally published in Clover Health on Medium, where people are continuing the conversation by highlighting and responding to this story.

jazz on Twitter

Personal goal in NY is to say more things that might be wrong instead of worrying being wrong, then get to learn from that.

I almost forgot about this, but I guess what one chooses to declare to the world on Twitter might actually be pretty salient because I don’t typically make internet proclamations (anymore, since my xanga days circa 18 years old). 16 months and a whirlwind first year at Clover Health later, I am actually on track to feeling like “Oh yeah, I think I did do more of that”.

I have said things that I have later changed my own mind on (usually in a 180 degrees fashion) or discovered that it was frankly factually erroneous. I have pitched things as hypotheses and opinions. I say “I don’t know” a lot more readily. I ask, “Tell me more about that,” or “Can I grab you later to talk through this?”

In various forms of uncertainty, I have made myself feel a lot more comfortable with sharing first draft ideas and not worry too much about always presenting perfectly.

I let the uncomfortable feelings of somewhere between total ignorance, to embarrassment, to a blank neutrality slide past — and instead poke around the edges of what I do know until they form deeper contours of knowledge. I ask “What do you mean?” directly instead of save up the words to google later, because it’s faster and between learning about healthcare and being in a startup and diving through unfamiliar engineering domains I really do not have enough time to pretend like I know things that I don’t, and I don’t have time to not short-cut that learning path.

So, in that same spirit, I am starting this new adventure — not just saying more first-draft thoughts, but also writing them down to sift through, to record my own change of mind — vacillations towards discovering a more durable truth.

Write! Even if wrong was originally published in write or wrong on Medium, where people are continuing the conversation by highlighting and responding to this story.

A wise friend once told me — there is no such thing as the platonic ideal of a job. What is a “job,” really, other than a collection of people trying their best to make something happen — caring about what they are striving for and each other in between? It’s always full of hope and imperfections: a group of people, smart but fallible, learning to do things a little better each time.

A year ago, I chose to join Clover Health because of its clear commitment to be self-reflective about what it means to build a good team — engineering and beyond. And now, a year out, we’ve gathered some of the most thoughtful people I’ve had the privilege to work with, even as there are many things that we still need to figure out.

We talk a lot about what our values are as an engineering team, but the truth is they are best manifested by the myriad of voices that make up Clover Engineering thus far: there’s so much incredible richness, complexity, and “oomph” that I could never give justice to as a summary. So, instead, I want to give a glimpse to the humans — eager, smart, full of heart — that make up Clover Engineering, in their own words:

What brought you to Clover?

I sought a small organization where I could do a variety of things and iterate on my mistakes. There are a number of those, but not all of them employ such a high concentration of admirable people, and not all of them are tackling unsolved problems that are also, to me, worth solving. — Grant Wu

My last job was at a company doing social media advertising. Among other reasons, I took the job because I wanted to try something new. I gained a totally new perspective on social media — I pick and choose my friends on Facebook carefully so I don’t see a lot of ugliness, but as an engineer you see everything that goes on. I realized that doing something for the greater good was more important to me than being part of a trendy industry …I decided my next job would be in either education or healthcare. My ailing grandparents and seeing how much my mom has to do to take care of them is what pushed me more towards healthcare… And here I am. — Diego Argueta

Before I came to Clover, I came across a lot of different companies that had an amazing culture but I just couldn’t get on board with the products they were building. I want to be proud of what I do at work and Clover not only has a real mission but a great model on how to accomplish that mission. Clover lets you have the best of both worlds — work with passionate and brilliant people while you build something that makes a real difference in people’s lives. — Saba Naqvi

I’ve struggled my entire career with reconciling my ethical and moral values with my profession. A big part of information and communications software is automating away the details of life. To a certain extent, that’s dehumanizing. We don’t necessarily care about the life story of the person selling us our coffee, for instance. Transactionalizing human interaction is a consequence of what we do — much like Walmart (the high cost of low prices). The fact that Clover is actively grappling with our moral imperative — targeting an at-risk population (not just elderly or disabled, but actively serving the low income portion) — is really important to me. — Alyssa Kwan

What does it mean to you to be an engineer?

Being an engineer means using technology to help solve problems for people. That’s a vague description, and so the important thing is defining what kind of problems you like to solve. I’ve grown into an engineer that wants to apply technology to problems that are meaningful to me. Rather than technology for it’s own sake. — Marco Rogers

I like puzzles. I used to sit in the basement of my house for hours doing 1000 piece puzzles. I also really like crafts (sewing, knitting, glueing pieces of paper together to make little airplanes etc). To me, being an engineer is a bit of both. It’s about solving a puzzle and building something that works-ish, but at the same time, honing your skills so you can challenge yourself to build something a little more refined each time. — Eve Shum

An engineer:
- solves problems, and
- makes things
in that order. — Sara Packman

What is your favorite virtue?

My favorite virtue is cooperation: ‘To associate with another or others for mutual benefit/to achieve a shared goal.”
It’s possible to do good work by yourself, but *great* work comes from teams of people with complimentary skills. I think this is especially true for technology projects. The first thing that came into my mind when reflecting on cooperation was the video of the Mars Lander team celebrating: I could watch that video 1000 times :) — Dan Lee

Kindness, because (1) it’s great, (2) it tends to imply other stuff I also like about people, and (3) it’s usually a choice. — Grant Wu

Persistence. Engineering is hard. Healthcare is confusing. Giving up results in a mess of unsolved problems and half solutions. Getting angry and frustrated results in wasted energy, which leads to premature exhaustion, which leads to giving up.

Persistence to me means patience to wait for the definition of the problem to become clear, faith that a solution exists, and constant effort to find and implement that solution. — Sara Packman

Responsibility. Especially in the form of the moral imperative. As an engineer, if I build something, I take responsibility for it. If a bridge collapses, who is responsible? More subtly, if a bridge decays earlier than budgeted, and taxpayers spend more money than should have been required to shore it up, who is responsible? As an engineer, I see my vocation, my calling, as three things: 1) does what I build and deliver do what I say it does? 2) have I informed my stakeholders on what it does not do, so that they make informed decisions? and 3) have I educated my stakeholders on the limits of what I have built, such that they know not to use it in ways that will have unexpected outcomes? That’s my sacred responsibility. — Alyssa Kwan

Your idea of happiness?

Mai Tais and boardgames. — George Leslie-Waksman

Relaxing with the life forms that I love. — Dan Lee

Shopping and eating all day, then watching TV/playing PAD/cross-stitching in my pajamas at night. — Eve Shum

Beauty found in nature, good tea, good chocolate, good music, good books, and good friends, although maybe not all at the same time. — Sara Packman

Your most memorable engineering win/fail

WIN: When I left a former position, I gave 2 month’s notice; I was taken off critical projects and mostly left to my own devices; in that time I wrote a program that automated much of my job out of existence

FAIL: I used to have a 1993 Ford Explorer, which I did all the repairs on myself. For a while I was running experiments with fuel additives and driving styles to improve its abysmal fuel efficiency. It turns out acetone melts rubber gaskets and causes fuel tanks to leak. The vehicle was ruined but, luckily, early discovery meant nobody was injured. — George Leslie-Waksman

WIN: I was once locked out of my house in NJ b/c I was bad at carrying my keys outside the house. I stood on a garbage can, picked up a rock, and sawed through the window screen. I then “sewed” the screen back together with plastic thread. Does this count as engineering?? — Eve Shum

FAIL: here was that one time when I thought I had destroyed all of Yammer’s source code….

I was trying to move code from one git repository to another, while preserving its history, by using a git command called `filter-branch`. I was fairly new to git at the time, so when I hit <enter> on my filter-branch command, and saw output like this, I damn-near fainted:

`removing origin/master`

`removing origin/branch1`

<Similar scary messages for every branch that ever existed>

As I frantically hit ctrl-c, I was *sure* of two things:

1) I had deleted most of Yammer’s source code.

2) I was fired.

It turned out that neither of those things were true. `filter-branch` was only operating on the local copies of those branches, and my manager agreed to keep my panicked reaction a secret between us :) — Dan Lee

WIN: One summer I was with my Boy Scout troop and we found a large pile of scrap wood — planks, plywood sheets, parts of a bench, etc. — behind the VFW lodge where we were based. Being Boy Scouts, we went home, came back with a bunch of tools, and proceeded to build the jankiest raft you’ve ever seen out of empty cement buckets, rope, twine, nails, you name it. It even had a sail we made out of a tarp. In retrospect it was terribly done, but hey — we made a raft that actually floated! Ish.

FAIL: Accidentally DOS-ing the Library of Congress and knocking their servers offline for like half an hour. I was trying to build a database of ISBN numbers/titles/authors etc. for a project and decided the easiest way would be to brute-force generate every valid ISBN, query their site, and scrape the results out of the returned webpage. Apparently their servers can’t handle a single multithreaded application running on a mid-tier laptop. — Diego Argueta

WIN: I know nothing about cars. I put gas in them and drive them, and that’s about it. So when my husband’s car lost its side mirror in a collision with a support column, our first thought was to take it to a garage to have it repaired. The owner told us he would only charge us for parts and that the bill would come to somewhere between $300 and $400. My husband checked the price of a sideview mirror on amazon right there in the mechanic’s office, saw that it was about $50, and told the mechanic we’d think about it get back to him. Instead, we ordered the mirror on amazon. I watched a bunch of youtube videos, learned how to remove the interior door panel and rewire the cables that ran to the turn signal. I also taught my husband what needed to be done so he could help disassemble and reassemble the door panels. (cars are not among his areas of expertise, either) Together, we replaced the mirror and saved about $300. — Sara Packman

Many people ask us: if the Clover Health business model is so obviously well-aligned, why hasn’t anyone else done it yet? The answer is it takes depths of hard work to reimagine and execute a whole new insurance/ health care paradigm from the ground up. The complexity of the industry itself, as well as the technical and human systems that must be engineered to enable this premise, are not the same as building your typical web-application as a service.

All of us are working hard day-to-day to figure out what this company should ultimately look like and do: aspiring, strategizing, but also recalibrating every step of the way. And that imperfect but earnest and tenacious effort is at the heart of this team we are building.

Engineering Healthcare at Clover was originally published in Clover Health on Medium, where people are continuing the conversation by highlighting and responding to this story.

Toxicity is a big, alarming word. This is why I was hesistant to use it for a long time. It seems to suggest a baseline of cuss words, blatant discrimination, negligence or incompetence. It also seems like a particularly big accusation; after all, the word “toxic” has such an electrifying edge to it. But I’ve come to believe that it is actually nonetheless possible to have toxicity breed among a perfectly otherwise nice, reasonable group of people.

That’s the most important thing I’ve learned with regards to toxicity thus far: it doesn’t need to imply great evil or even utterly apparent dysfunction in a team. It most certainly does not have to mean that the people involved are fundamentally a*sholes. Although all of the above can be true too, at its most innocuous it simply needs a certain level of carelessness and apathy to thrive.

First, let’s define toxicity. We could try to define this with examples, but that’s boundless and not instructive. To me, toxicity is apparent when an environment regularly takes away your energy to be productive or enthusiastic. This could come from fear, but it doesn’t even have to. We do not need to quantify “just how much” energy it takes away. The bottom line is: if you regularly feel more sapped than energized by your environment, it is probably somewhat toxic.

A lot of toxicity, especially in the tech & engineering world, comes from social factors through gender or race discrimination/micro-aggressions, whether or not intentional. Those are big and real things, but not the issues I want to discuss here because they can fill a whole other post of their own. Instead, what I want to talk about is the core friction and conflicts that arise from doing engineering work.

Hypothesis on why toxicity arises

There is a particular kind of pain (and perhaps, joy, to not be so cynical) that is only known to software engineers: the inevitability of having to work on someone else’s code (whose design you disagree with very much), and to have your code eventually be worked on by others (who will almost certainly disagree with you on something). That is the price of being able to do something cool: to be able to build solutions that replicate themselves and run for an extended period of time.

There is almost no other profession like it. Many professions’ “final-products” are more or less expected to be in a fixed state, whose process and source are treated as disposable after the product communicates its value. Think about all the emails that you wrote which proceeded promptly to heaven.

But not engineering. Not only are you expected to build something complex in a present state, you should also, to at least an immediately protective extent, anticipate the complexity in the future. Working in a codebase is like being mired in a time machine, having to battle mistakes of the past, deal with constraints of the present, and also intelligently mitigate the future. Trying to build this “intellectual fortress” can be challenging work that sometimes feels impossible, and probably is impossible to “get right”.

That kind of mental anguish/taxation, I believe, lends a stage to much of the precursors of toxicity. All of which I have taken part in, one way or another. First — there is the pride that creeps up simply because you have devoted much time and thought to it. It takes conscious effort to battle that when it does not always manifest itself consciously. The effect of pride is both an event and a cumulative process. Over time, it can teach one to believe, falsely, that they are always likely to be more correct than others. Second, there is the impetus of that frustration which lends itself to quick and “justified”-feeling responses, however unjustified that may be. Both of these instincts are easily riddled with insecurity.

What does innocuous toxicity look like?

Again, overtly toxic behavior is terrible, but I almost think that those things are easier to pick up and label as “wrong”. That is not to say it’s always easy to stand up against them, especially if you are in an organization that is poorly managed and riddled with fundamentally misaligned beliefs.

But what I really want to talk about is the insidious stuff: the stuff that you feel like you can’t quite put your fingers on. The stuff that you feel like isn’t quite right but you feel like you might be pesky just for bringing it up, or that you feel like you should almost let it slide because it seems utterly human and therefore should be forgotten.

I’ve come to believe otherwise. “Innocuous” toxicity is just as toxic, especially over time — it differs from the truly horrible stuff because it offers no mechanism of dissociation. It feels hard to simply write a certain person or behavior off because “it just doesn’t seem bad enough”. Yet in the mean time, it is taking away just as much of your energy and preventing your growth.

I am talking about: the casual eyerolls when someone mentions “some bad code somewhere”, or the mention of a person’s name whom for some reason the team has agreed as “having a certain style” (code for bad); the talking behind someone’s back about the code they wrote; the quick equating of someone’s ability as a competent engineer to solely their code; the quickness to point fingers at someone almost as a victory when something breaks; the public shaming when you disagree with someone or believe that they are doing something wrong.

These things often feel like you are doing the right thing: you are the guardian of quality! the loud advocate of correctness! But in fact you are just doing the easy thing. It is easier and feels gratifying to point out someone else’s mistake; it is seriously debatable whether that gesture can count as “teaching” and will result in better code over time. In fact, as a result of fear many people are much more likely to stop really asking the questions they need to ask to grow.

All of these things are not exclusive to engineering. They can happen just as much elsewhere. Other forms of toxicity are endemic to other industries. Still, none of that negates the fact that we have some work to do.

How to battle the seeds of toxicity?

First, stop doing these things yourself. I will be the first to admit that I’ve probably done many of those things, because it made me feel like I got to be part of a club. I felt such an inherent anxiety of being judged (and feeling the high probability of so given what I had witnessed) that I sought to gain a false feeling of protection by judging others. In the end, it really only made me a terrible person, and delayed my own growth because it reinforced my fear in failing. Except for those that I know very consciously try to mitigate this impulse, I have seen engineers at almost every level do this. It’s a thing people really like to do.

Strive for a truly blameless culture. Not just blameless postmortems when things go wrong, but blameless day-to-day. If you are worried about that leading to laxness, I say that humans are more intelligent than that and there should be a way of instilling caution in people without demoralizing fear. If you feel like something could be better, please take the time to teach other people and explain it. I believe that a team should be collectively responsible for each other. There should be a clear sense that growing as a team as a whole shifts the whole curve up.

It’s good but not enough to be simply “blameless” — that can just easily become an interpretation of utter apathy. The pillar of that blamelessness is support. Support via teaching. Support via active mentoring. Support via actually being supportive and generous in your tone and approach. Support via showing that you are willing to invest in someone’s long-term technical and career development. When you hire someone, start with the assumption that they are wildly competent rather than making them prove so; answer their questions without penalizing them.

Get there by playing your part: being a person that doesn’t casually roll the eyes or point fingers victoriously, a person that believes teaching others is what pushes both you and them beyond the local maxima. If you are a leadership figure, take the extra time to voice those values to your team; find out how your team is really feeling, especially because these things can be so difficult to pick up. So much of blame is a habit, often of insecurity. Find out why your team feels a certain way, find out why you feel this way.

I am a tried-and-true supporter of open coursewares. They enabled the first steps of my becoming a software engineer. So much of my knowledge today is indebted to people who have graciously shared theirs on the internet. Even more of my belief in the possibility of a new path is indebted to this generous ethos of enabling access to worlds you did not previously know.

But anyone that has actually studied with online open courseware knows it is terribly lonely and difficult, even for very motivated learners. When I was studying from Stanford’s online introductory computer science class in Taiwan, I had no access to people that could help me when I got stuck. The only thing that lessened this loneliness was the writing of a girl in San Francisco that had already self-studied through one the classes. When I absolutely needed some hints on how to progress forward, I consulted her blog’s solutions for quick and limited hints. Often, it was for trivial but bottlenecking questions like how to incorporate certain libraries. To me, lifting her solutions wholesale (or “cheating”) had no value. If I didn’t do as much of it as possible myself, the knowledge was not mine.

When I started looking for jobs as a software engineer, I put up my completed assignments as part of my portfolio on Github to demonstrate that I had studied fundamental data structures. After all, I have invested close to 300 hours for the two introductory courses and I wanted to showcase this in lieu of a formal CS education. An added benefit of that was a few people similarly self-studying had now subscribed to the repository. It’s perhaps a falsely romantic sentiment—but it really uplifted me in a small way to know that there are people all over the world wanting to learn more of their own volition; I felt connected to them.

My experience is not a rare one. Many aspects of it, especially the knowledge sharing, are common among people who have self-studied their way to life-changing paths.

This is why I was genuinely surprised when I received an email request from a Stanford CS instructor to remove my solutions from Github. He claimed that the availability of my solutions could seriously jeopardize the academic futures of the current students, as many of them had no self-control over cheating or willfully cheat because they simply did not care about learning the material. It was my responsibility to remove this “temptation” out of their way.

When I asked him if I was violating some actual legal rule of sharing these solutions (perhaps there was an honor code that I was not aware of), he confirmed that I was not. Since I was not in violation of any known rule and I wanted to uphold my principles, I declined his request. At this point, I no longer needed the material for my portfolio but still shared them for other self-learners. Understanding that cheating is a very serious offense for Stanford students, I offered to add some disclaimers/warnings to remind anybody consulting the solutions that Stanford students should not reference these assignments. Unfortunately, this proposal was considered insufficient by him—he deemed that I “could not be reasoned with” and that the availability of my solutions to be against the spirit with which such material are shared.

This was in spite the fact that the FAQ page for this open courseware clearly states that in lieu of faculty support, it hopes that students can self-form communities online to help each other for assignments without solutions and that such “support should be obtainable via a quick web search”.

While I still believed in the soundness of my motivations, his insistence got me to reflect on the unspoken paradoxes between a closed, formal education and its simultaneous attempt to be “open”. For what it’s worth, I think this instructor must care about his students an extraordinary amount to do something like this—they are really very lucky to have him. I also don’t think that his request necessarily represents the official perspective of the school (it may, it may not).

Some things to reflect on, without absolute answers.

1. How does a school reconcile the consequences of making a course open?

When the school shared their courses online, did they not predict that solutions would also be shared? Despite the instructor’s claim that he had emailed the handful of people with posted solutions and they had complied, a quick Google search showed me dozens of other solutions still posted, including solutions from the girl that had first helped me. Why did the school continue to use unmodified assignments for its own closed course?

As generous as it is to post course material, learning on your own could be extremely difficult without a reference to solutions. The articulated hope of self-forming learning communities for online classes is impossible without the allowance of sharing and discussing answers freely. It is not worth much for a school to claim to embrace open education when it cannot fully embrace the consequences of openly shared knowledge.

Coursera, which is different in nature in that students have access to TA’s and also have the potential to be certified, has a clear honor code that forbids the sharing of solutions (even so, this is the internet and a quick search reveals that solutions are everywhere). While I believe that the effectiveness of open coursewares without TA support would greatly decrease if solution sharing is forbidden, this should be spelt out in the guidelines if its is a legitimate concern. Such logistics need to be coordinated more thoroughly to defend against potential paradoxes.

2. Should a school rethink its policy on cheating?

The primary argument that the instructor gave me was that even if a student has “inadvertently” cheated through an initially casual reference, the consequence was large and irrevocable. A student did not simply get a zero, but could be suspended or expelled—forming an indelible mark on the academic record.

It troubles me deeply that a school and its instructor still act more like authoritarian parents even at the university level. What does it say about our education system when young adults could not be trusted to make their own decisions and take advantage of the world-class resources around them? What does it say about our relationship of trust for each other when we do not permit young adults to rebound from casual mistakes? Are we simply ruling them by fear?

3. Should a school reflect upon the nature of its assignments?

Of all the troubling implications, the worst was the symbolic disconnect between completing an assignment and how work is done in the real world. In the working world, knowledge is constantly augmented through open source sharing, consulting of previous experiences, and working collaboratively. This enables us to advance our collective intelligence as a whole. So little of this is evident in how we expect students to exercise their knowledge.

Cheating, in the sense of “copying”, can be simultaneously worthless and worth a lot. Copying without thought means you cannot internalize the knowledge and at some point you will be caught at a dead end. On the other hand, copying in fragments with the thought to emulate and internalize can be a way of improving—when you mimic patterns better than your own.

Should schools give more thought on how to test mastery without forbidding references to other material? There are assignments that are brittle to cheating, and others that can promote referencing and building upon existing knowledge that still require exercising your intellectual originality. Many of the coding bootcamps’ free-form projects for career day are such examples.

———

I accept that this is a topic rife with ambiguity and relative ethical grounds. (With the exception of Stanford students who cheat with no contrition, I have limited sympathy for students privileged with world-class resources that intentionally fail to take advantage of them).

In the end, I removed the solutions because I respected the teacher going out of his way to try to construct an “effective” learning environment for his students, even if such construction is a bubble. My initial refusal seemed to seriously pain him, and I do not enjoy emotionally traumatizing someone whose heart is in a good place.

It took me a long time after graduating from an Ivy League school to fully grasp the true value of knowledge without the presence of grades (I had never cheated, but the specter of grades always loomed larger in a school than learning for its own sake). Access to knowledge and the subsequent mastery of it is such a precious and beautiful thing, but it could only be truly appreciated when you are trusted as an individual to utilize it for purposes larger than impressing an artificial system.