Entries Tagged 'wetware' ↓

Don't ask if a monorepo is good for you – ask if you're good enough for a monorepo

This is inspired by Dan Luu's post on the advantages of a single big repository over many small ones. That post is fairly old, and I confess that I'm hardly up to date on the state of tooling, both for managing multiple repos and for dealing with one big one. But I'm going to make an argument which I think mostly works regardless of the state of tooling on any given day:

  • Monorepo is great if you're really good, but absolutely terrible if you're not that good.
  • Multiple repos, on the other hand, are passable for everyone – they're never great, but they're never truly terrible, either.

If you agree with the above, the choice is up to your personal philosophy. To me, for instance, it's a no-brainer – I'll choose the passable thing which successfully withstands contact with apathetic mediocrity over the greater thing which falls apart upon such contact in a heartbeat.

You might be different – you might believe in Good – and then you'll choose a monorepo, like Google, the ultimate force for Good in technology (which is why they safeguard your personal data; you wouldn't want someone evil to have it – luckily, Google can do no evil.) And I'm almost not kidding: the superpower which lets Google maintain the grassroots bureaucracy which I find necessary to make monorepos work well is actually the same trait making you sufficiently delusional to chant, or at least to have chanted "Don't Be Evil" entirely seriously. I don't have that. I am, to a first approximation, evil. Worse is Better.

But that's me – I'm not saying you/your org are Not So Good, or Evil. I'm only saying that you should be open to the possibility, and that I don't see the implications of being Not So Good discussed as much as they deserve.

Why are monorepos terrible if you're not that good? Three reasons:

  1. Branching in
  2. Modularity out
  3. Tooling strained

Let's discuss them in some detail.

Branching: getting forked by your worst programmer

In a Good team, you don't have multiple concurrent branches from which actual product deliveries are produced, and/or where most people get to maintain these branches simultaneously for a long time. And you certainly can't have branching due to outright atrocities, like someone adding a feature by killing a feature – for example, making the app work on Android, but destroying the ability to build for iOS in the process.

But in a not-so-good team… you get the idea.

What do you do when you have a branch working on Android and another branch working on iOS and you have deliveries on both platforms? You postpone the merge, and keep the fork. For how long do you postpone the merge? For as long as is necessary for the dumbass who caused the fork to fix their handiwork, in parallel with delivering more features (which likely results in digging a deeper hole to climb out of afterwards.) And the dumbass might take months, years, or forever.

The question then becomes, what was forked?

In a multi-repo world, the repo maintained by the team with the dumbass on it got forked. In a monorepo world, the entire code base got forked, and the entire org is now held hostage by the dumbass. And you might think that this will result in a lot of pressure to fix the problem, and you'd be wrong, for the same reasons that high murder rates don't cure themselves by people putting pressure on whomever to lower them to some equilibrium level common to all human societies.

Some places have higher than average murder rates, and some places have have higher than average fork rates. And I argue that a lot of places have fork rates which combine into a complete disaster with a monorepo. And you might not even realize how bad the fork rate is at your place, because multiple repos largely shield you from the consequences. Or, more tragically, you might not realize how bad your fork rate is because your monorepo is in its first couple of years, and you're sowing what you'll reap in its next couple of years, when you'll have more code, more deliveries and more dumbasses.

With multiple repos, if you have your shit under control, and your repos have a single release branch with a single timeline, all you have to do is to test against both of the dumbass's branches. But with a monorepo, you need to maintain your code in 2 branches, with a growing share of everybody else's code morphing incompatibly in those branches, simply because they exist. And very soon it will be more than 2 because there's more than a single dumbass, and good luck to you.

Modularity: demoted from a norm to an ideal

Norms are mundane, but they are what is. Ideals are lofty, but they are merely what should be (and typically isn't.) If you want to actually have something, you don't want it to be an ideal, like altruism – you want it to be a norm, like wiping one's ass. If something is demoted from ass-wiping to altruism, that something will scarcely be found in the wild.

With multiple repos, modularity is the norm. It's not a must - you technically can have a repo depending on umpteen other repos. But your teammates expect to be able to work with their repo with a minimal set of dependencies. They don't like to have to clone lots of other repos, and to then worry about their versions (in part because the tooling support for this might be less than great).

In fact, a common multi-repo failure mode is that people expect too few dependencies and make too many repos which are too small to host a useful self-contained system. Note that this failure mode is not lethal. It kinda sucks to have this over-modularity with benefits of independence which turn out to be imaginary upon a closer look, and to have people treat what essentially are internal APIs with way too much reverence, just because two modules which are extremely tightly coupled conceptually are independent technically, in terms of cloning/building/testing. But it doesn't kill you.

With a monorepo, modularity is a mere ideal. Everybody clones the whole thing. You're not supposed to add gratuitous dependencies, but it's very easy to add such a dependency in terms of cloning, building and versioning, and nobody objects to the dependency being added the way they would if they needed to clone more repos.

Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies. In a not-so-good team, your monorepo will grow into a single giant ball of circular dependencies. Note that adding dependencies is infinitely easier than untangling them, much like forking is easier than merging, with the difference that the gut-felt urgency to merge ("I can't maintain all your damned branches any longer!!") is far greater and far more backed by simple self-interest than the urgency to improve the dependency structure.

Tooling: is yours better than the standard?

This part might age worse than the others, and might not be particularly up to date even now – what "standard" tools are capable of changes over time. But generally speaking, a growing monorepo is likely to outgrow the standard version management tools and methods, as well as other tools and methods dealing with your revision controlled code.

Google used to have a FUSE driver to avoid copying hundreds of millions of source lines at a time, and instead getting the files on demand, when a directory is cd'd into. Facebook used to hack on hg to make it fast on its large monorepo. Maybe already today, or some day, a growing number of off-the-shelf tools will scale to infinite monorepos without such investments. But it sounds reasonable that there will always be tools and workflows which you will struggle to make work with a large monorepo (starting with some script doing find/grep.)

With a bunch of small monorepos, you work with a small overall number of source files in your working directory, so you don't need to tell your tools, "don't try to deal with the whole thing – instead only search this subset, or use this index etc. etc." And you have tools these days which kinda sorta let you manage the revisions of multiple repositories (for instance, there's Google's Repo.) And I think the result is very, very far from a great experience potentially afforded by a large monorepo. But it also never breaks down as badly as a large monorepo outgrowing the abilities of tools, as well as the ability of your local toolsmiths to find creative workarounds for these growth pains.

Summary

Don't ask if a monorepo is good for you – ask if you're good enough for a monorepo. Personally, I don't have the guts to bet on the supply of Goodness in a given org to remain sufficiently large over time to consistently avert the potential disasters of monorepos. But that's just my personal outlook; if you want to compliment me, don't call me "smart," and definitely don't call me "good" – I know my limits in these areas, and I take far more pride in knowing these limits than in the limits themselves; so, to compliment me, call me "pragmatic." Yet a culture worthy of a monorepo absolutely can exist – just make sure yours actually is one of those, and don't mistake your ideals for your norms.

Things want to work, not punish errors

For better or worse, things want to work.

Consider driving at night on unlit, curvy mountain roads, at a speed about twice the limit, zigzagging between cars, including oncoming ones. Obviously dangerous, and yet many do this, and survive. How?

  • Roads and cars are built with big safety margins
  • Other drivers don't want to die and help you get through
  • Practice makes perfect, so you get good at this bad thing

The road, the car, you, other drivers, and their cars all want this to work. So for a long while, it does, until it finally doesn't. I know 3-4 people who drive like this habitually. At least 2 of them totaled cars. All think they're excellent drivers. All have high IQs, making you wonder just what this renowned benchmark of human brains really tells us.

Now consider a terribly managed project with an insane deadline, and a team and budget too small. All too often, this too works out. How?

  • Unless it physically cannot exist, a solution wants you to find it. You carve out a piece and the next piece suggests itself. Even if management fails to think how the pieces fit together, the pieces often come out such that they can be made to fit with modest extra effort.
  • And then the people who make the pieces want them to fit. Even if the process is totally mismanaged, many people will talk to each other and find out what to do to make parts work together.
  • The project was approved because a customer was persuaded. At this point, the customer wants the project to succeed. A little bit of schedule slippage will not make them change their minds, nor will a somewhat less impressive result. More slack for you.
  • The vendor, too wants the project to succeed, and will tolerate a little bit of budget overrun. More slack.
  • Most often, when things fail, they fail visibly. It's as if things wanted you to see that they fail, so that you fix them.

The fact is that by cutting features, having a few non-terminal bugs, and being somewhat late and over budget, most projects can be salvaged. In fact, when they say that "most projects fail," the PMI (*) defines "failure" as being a bit late or over budget. If "failure" is defined as outright cancellation, I conjecture that most projects "succeed."

Which projects are least likely to be canceled? In other words, where is being late, over budget and off the original spec most tolerable? Obviously, when the overall delivered value is the highest, both in absolute terms and relatively to the cost. In other words, reality punishes bad management the least in the most impactful cases.

What is the biggest problem with bad management? Same as crazy driving: risk. The problem in both cases is you risk high-cost, low-probability events. It's terrible things that tend not to happen. And people are pretty bad at learning from mistakes they never had to pay for.

Wannabe racecar drivers fail to learn from driving into risky situations which their own eyes tell them are risky. For managers, learning is harder – the risks accumulated through bad management are abstract, instead of viscerally scary. In fact, a lot of the risks are never understood by management, or even fully reported. There's just too much risk to sweep under various rugs to make it all ingrained in institutional memory.

In fact, it's even worse, because risk-taking is actually rewarding as long as the downside doesn't materialize. The crazy driver gets there 10 minutes earlier. Similarly, non-obviously hazardous management often delivers at an obviously small cost. And while driving is not actually competitive, except in the inflamed minds of the zigzagging few, most projects are delivered in very competitive environments indeed. And competition can make even small rewards for risk decisive – as it can with any other smallish factor large enough to make a difference between victory and defeat.

Things want to work more than they want to punish us for our errors. The punishment may be very cruel and unusual alright, but it's rare. It seems that the universe, at least The Universe of Deliverables, is Beckerian. It delivers optimal punishment for rational agents correctly estimating probabilities. Sadly, humans are bad at probability.

And thus crazy drivers and bad managers alike (often the same people, BTW) march from one insane adventure to the next, gaining more and more confidence in their brilliance.

(*) PMI (The Project Management Institute) is a con, where they sell you "PMBOK" (Project Management Body of Knowledge, a thick book you can use as a monitor stand) and "PMP" (Project Management Professional, a certification required by PMI's conscious or unwitting accomplices in dark corners of the industry.) A variety of more elaborate cons targeted at narrower audiences incorporate PMI's core body of cargo cult practices.

Fun won't get it done

OK, published at 3:30 AM. That's a first!

So. Got something you want to do over the coarse of a year? Here's a motivation woefully insufficient to pull it off:

  • It's fun!

What could give you enough drive to finish the job? Anything with a reward in the future, once you're done:

  • Millions of fans will adore me.
  • It will be the ugliest thing on the planet.
  • I will finally understand quantum neural rockets.
  • We will see who the loser is, Todd!
  • I will help humanity.
  • I will destroy humanity.

It doesn't matter how noble or ignoble your goal is. What matters is delaying gratification. Because even your favorite thing in the world will have shitty bits if you chew on a big enough chunk of it. A few months or years worth of work are always a big enough chunk, so there will be shitty bits. Unfortunately, it's also the minimum-sized chunk to do anything of significance.

This is where many brilliant talents drown. Having known the joy of true inspiration, it's hard to settle for less, which you must to have any impact. Meanwhile, their thicker peers happily butcher task after task. Before you know it, these tasks add up to an impactful result.

In hindsight, I was really lucky in that I chose a profession for money instead of love. Why? Stamina. Money is a reward in the future that lets you ignore the shittier bits of the present.

Loving every moment of it, on the other hand, carries you until that moment which you hate, and then you need a new sort of fuel. Believe me, I know. I love drawing and animation, and you won't believe how many times I started and stopped doing it.

But the animation teacher who taught me 3D said he was happy to put textures on toilet seat models when he started out. That's the kind of appetite you need – and very few people naturally feel that sort of attraction to toilet seats. You need a big reward in the future, like "I'm going to become a pro," to pull it off.

But I don't want to become a pro. I don't want to work in the Israeli animation market where there's scarcely a feature film made. I don't even want to work for a big overseas animation studio. I want to make something, erm, something beautiful that I love, which is a piece of shit of a goal.

Because you know where I made most progress picking up actual skills? In an evening animation school, where I had a perfectly good goal: survive. It's good because it's a simple, binary thing which doesn't give a rat's ass about your mood. You either drop out or you don't. But "something I love" is fluid, and depends a lot on the mood. And when you hate this thing you're making, as you sometimes will, it's hard to imagine loving it later.

Conversely, imagining how I don't drop out is easy. This is what I was imagining when sculpting this bust, which 90% of the time I hated with a passion because it looked like crap. But I thought, "I'm not quitting, I'm not quitting, I'm not quitting, hey, I get the point of re-topology in Mudbox, I'm not quitting, I'm not quitting, hey, I guess I see what the specular map does, I'm not quitting… Guess I'm done!"

And now let's talk about beauty for a moment.

I'm a programmer. I like to think that I'm not the thickest, butcherest programmer, in that I understand the role of beauty in it. For the trained eye, programs can be beautiful as much as math, physics or chess, and a beautiful program is better for business than the needlessly uglier program. (Ever tried pitching the value of beauty to someone businessy? Loads of fun.)

But you know why beauty is your enemy? Because it sucks the fun out of things. How? Because you're making this thing and chances are, it's not beautiful according to your own standard. The trap is, your taste for beauty is usually ahead of your creative ability. In any area, and then in any sub-area of that area, ad infinitum, you can tell ugly from beautiful long before you can make something beautiful yourself. And even if you can satisfy your own taste, often the final thing is beautiful, but not the states it goes through.

So the passionate, sensitive soul is hit twice:

  1. You're driven by fun and inspiration because you've once experienced it and now you covet it.
  2. Your sense of beauty, frustrated by the state of your creation, kills all the fun – that very fun which you insist must be your only fuel.

Life is easier if you want a yacht. I think you can buy a decent one for $300K, and certainly for $1M. Now all you need to do is make that money, doing doesn't matter what – imagining that yacht will help you do anything well! If you want beauty, however, I do not envy you.

How do I cope with my desire for beauty? The first step is acknowledging the problem, which I do. The fact is that my worst failures in programming came when I insisted on beauty the most. The second step is shunning beauty as a goal, and making it into a means and a side-effect.

I need a program doing at least X, taking at most Y seconds, at a date not later than Z. I'll keep ugliness to a minimum because ugly programs work badly. And if it comes out particularly nicely, that's great. But beauty is not a goal, and enjoying the beauty of this program as I write it is not why I write it.

And if you think it's true for commercial work but not open source software, look at, I dunno, Linux. Read some Torvalds:

Realistically, every single release, most of it is just driver work. Which is kind of boring in the sense there is nothing fundamentally interesting in a driver, it's just support for yet another chipset or something, and at the same time that's kind of the bread and butter of the kernel. More than half of the kernel is just drivers, and so all the big exciting smart things we do, in the end it pales when compared to all the work we just do to support new hardware.

Boring bits. Boring bits that must be done to make something of value.

Does this transfer to art or poetry or any of those things whose whole point is beauty? Well, yeah, I think it does, because no, beauty is not the whole point:

  • The most important thing about a drawing is that it's done. Now it exists, and people can see it, and you can make another one. Practice. They will not come out very well if they don't come out.
  • Often people like your subject. There's a continuum between "it's beautiful in a way that words cannot convey" and "I love how this song expresses my favorite political philosophy." To the extent that a work of art tells a story, or even sets up a mood, its beauty does become a means to an end.
  • Just because the end result is beautiful to the observer, and even if that's the only point, doesn't mean every step making it was an orgy of beauty for whomever made it. Part of what goes into it is boring, technical work.

So here, too I'm trying to make beauty a non-goal. Instead my goals are "make a point" and "keep going," and you try to add beauty, or remove ugliness, as you go.

For example, I didn't do a graduation project in the evening school, but I animated a short on my own in the same timeframe, and I published it, even though it's not the beautiful thing I always dreamed about making. And I'm not sure anyone gets the joke except me. (I'm not sure I get it anymore, either.)

Now my goal is "make another one." It's a good goal, because it's easy to imagine making another one. It's proper delayed gratification.

And if you've enjoyed programming 20 years ago and are trying to reignite the passion, I suggest that you find a goal as worthy for you as "fun" or "beauty", but as clear and binary as a yacht. And you can settle for less worthy, but not for less clear and binary. Because everything they told you about "extrinsic motivation" being inferior to "intrinsic motivation" is one big lie. And this lie will fall apart the moment you sink your teeth into a bunch of shit, as will always happen if you're trying to accomplish anything.

Follow me on Twitter to receive pearls of wisdom such as the following sample:

 

Evil tip: avoid "easy" things

Now you see that evil will always triumph, because good is dumb.

Dark Helmet

Evildoers live longer and feel better.

Myself

My writing has recently prompted an anonymous commenter to declare that people like me are what's wrong with the world. Oh joy! – finally, after all these years of doing evil, some recognition! Excited, I decided to share one of my battle-tested evil tips, which never ever failed evil me.

Don't work on "easy" things

An easy thing is a heads they win, tails you lose situation. Failing at easy things is shameful; succeeding is unremarkable. Much better to work on hard things – heads you win, tails they lose. Failure is unfortunate but expected; success makes you a hero.

Treat this seriously, because it snowballs. The guy working on the "hard" thing gets a lot of help and resources, making it easier to succeed – and easier to move on to the next "hard" thing. The guy doing the "easy" tasks gets no help, so it's harder to succeed.

Quotation marks all over the place, because of course what counts is perception, not how hard or easy it really is. The worst thing to work on is the hard one that's perceived as easy – the hard "easy" thing. The best thing is the easy "hard" one. My years-long preference for low-level programming results, in part, from its reputation of a very hard field, when in practice, it takes a little knowledge and a lot of discipline – but not any outstanding skills.

(Why then do many people fear low-level programming? Only because of how hard it bites you the first few times. People who felt that pain and recoiled respect those who've moved past it and reached productivity. Now you know why people take shit from the likes of Ken Thompson and Linus Torvalds, and then beg for more.)

The point where this gets really evil is not when a heroic doer of hard things decides to behave like a Torvalds. That's more stupid than evil. You'll get away with being a Torvalds, but it always costs some goodwill and hence, ultimately, money. So the goal-oriented evildoer always tries to be on their best behavior.

No, the point where this gets really evil is when you let them fail. When they come to you thinking that it's easy, and you know it's actually very hard, and you turn them down, and you let them fail a few times, and you wait until they come back with a readjusted attitude - that's evil.

Here, the evildoer needs to strike a delicate balance, keeping in mind The Evildoer's Golden Rule:

  • You can only sustain that much do-gooding; however,
  • Your environment can only take that much evildoing, and you need your environment.

Here's the rule applied to our situation:

  • Working on the hard "easy" thing – all trouble, no credit – is going to be terrible for you. You'll get a taste of a do-gooder's short, miserable life.
  • However, if this thing is so important that a failure would endanger the org, maybe you should be the do-gooder and save them from their misconceptions at your own expense. Maybe. And maybe not. Be sure to think about it.

The upshot is, sometimes the evildoer gets to be the do-gooder, but you should know that it's hazardous to your health.

Making easy things into hard ones: the postponing gambit

Sometimes you can't weasel out of doing something "easy." An interesting gambit for these cases is to postpone the easy thing until it becomes urgent. This accomplishes two things at a time:

  • Urgent things automatically become harder, a person in a hurry more important. The later it's done, the easier it is to get help (while retaining the status of "the" hero in the center of it all who made it happen.)
  • Under time pressure, the scope shrinks, making the formerly "easy" and now officially "hard" thing genuinely easier. This is particularly useful for the really disgusting, but unavoidable work.

But it is a gambit, because postponing things until they become urgent is openly evil. (Avoiding easy things is not – why, it's patriotic and heroic to look for the harder work!) To get away with postponing, you need an excuse:

  • other supposedly urgent work;
  • whoever needing this thing not having reminded you;
  • or even you having sincerely underestimated the difficulty and hence, regrettably, having postponed it too much – you're so sorry. (This last excuse has the drawback of you having to admit an error. But to the extent that urgency will make the scope smaller, the error will become smaller, too.)

One thing you want to prevent is people learning to remind you earlier. The way to accomplish it is being very nice when they come late. If people feel punished for reminding too late, they'll come earlier next time, and in a vengeful mood, so with more needless tasks. But if they're late and you eagerly "try to do the best under the circumstances", not only do you put yourself under the spotlight as a patriotic hero, you move the forgetful culprit out of the spotlight. So they'll form a rosy memory of the incident, and not learn the value of coming earlier – precisely what we want.

One thing making the postponing gambit relatively safe is that management is shocked by the very thought of people playing it, as can be seen in the following real-life conversation:

Babbling management consultant: A lot of organizations have a problem where they only work on urgent things at the expense of important, but less urgent ones.

Low-ranking evildoer manager (in a momentary lapse of reason): Why, of course! I actually postpone things to get priority around here.

Higher-ranking manager (in disbelief): You aren't serious, of course.

Low-ranking evildoer (apparently still out to lunch): I am.

Higher-ranking manager (firmly): I know you aren't.

Low-ranking evildoer finally shuts his mouth.

See? Sometimes they won't believe it if you say to their face. So they're unlikely to suspect you. (Do people reporting to me play the postponing gambit? Sometimes they do, and I don't resent them for it; their priorities aren't mine. But at the worst case, you should expect a lot of resentment – it's practically high treason – so you should have plausible deniability.)

Conclusion

To a very large extent, your productivity is a result of what you choose to work on. Keep things perceived as easy out of that list. When you can't, postponing an "easy" thing can make it both "harder" and smaller.

Happy evildoing, and follow me on Twitter!

 

Love thy coworker; thy work, not necessarily

The whole "passionate about work" attitude irks me out; save your passion for the bedroom. This is not to say that I'd rather be ridiculed for being a nerd who works too hard.

In fact, personally I'm in a strange position of a certified programming nerd with a blog and code on github, who nonetheless does it strictly for the money (I'd be a lawyer or an i-banker if I thought I could.) I'm thus on both sides of this, kinda.

So, in today's quest to change society through blogging, what am I asking society for, if neither passion nor scorn for work please me? Well, I'd rather society neither encourage nor discourage the love of work, and leave it to the individual's discretion.

From a moral angle, I base my belief on the Biblical commandment, "love thy neighbor", which I think does not dovetail into "love thy work" for a reason. From a practical angle, again I think that one's attitude to coworkers (also managers, customers and other people) is a better predictor of productivity than one's attitude to work.

People talk a lot about intrinsic vs extrinsic motivation – passion vs money - but I think they're actually very similar, and the more important distinction is personal vs social motivation.

Why? Because whether I work for fun or for the money, it's a means to my own personal end, which in itself precludes neither negligence nor fraud on my behalf. What makes you do the bits of work that are neither fun nor strictly necessary to get paid is that other people need it done, and you don't want to fail them.

Perhaps you disagree with my ideas on motivation. If so, here's an idea on boundaries that I hope is uncontroversial. Telling me how I should feel about my job infringes on my boundaries, which is to say that it's none of your business. If however I do a shoddy job and it becomes your problem, then I'm infringing on your boundaries, so you're absolutely entitled to complain about it. Here again requiring respect for coworkers is sensible, while requiring this or that attitude towards the work itself is not.

So:

  • Someone's attitude towards work does not predict the quality of their work
  • Inquiring reports and potential hires about their attitude towards work is a minor but unpleasant harassment
  • A corporate culture of "we're doing this thing together" beats both "we're passionate to change the world by advancing the state of the art in blah blah" and "we're laser-focused on fulfilling customers' requirements on time and within budget"

P.S. Which kind of culture do managers typically want? Often they're schizophrenic on this. They want "passionate" workers, hoping that they'll accept less money. On the other hand, the same person often doesn't care about the actual work in the worst way (he sucks at it and not having to do it anymore is management's biggest perk to him.) But what he cares about is deadlines, etc. - so he encourages a culture of shipping shit in the hope that it sorts itself out somehow (these are the people that the term "technical debt" was invented for, of course nobody is convinced by this pseudo-businessy term if they weren't already convinced about the underlying idea of "shipping shit is bad.") Of course a truly passionate worker is going to suffer mightily in the kind of culture created by the same manager who thinks he wanted this worker.

People can read their manager's mind

The fish rots from the head down.

– A beaten saying

People generally don't do what they're told, but what they expect to be rewarded for. Managers often say they'll reward something – perhaps they even believe it. But then they proceed to reward different things.

I think people are fairly good at predicting this discrepancy. The more productive they are, the better they tend to be at predicting it. Consequently, management's stated goals will tend to go unfulfilled whenever deep down, management doesn't value the sort of work that goes into achieving these goals.

So not only is paying lip service to these goals worthless, but so is lying to oneself and genuinely convincing oneself. When time comes to reward people, it is the gut feeling of whose work is truly remarkable that matters. And what you usually convince yourself of is that the goal is important – but not that achieving it is remarkable. In fact, often someone pursuing what you think are unimportant goals in a way that you admire will impress you more than someone doing "important grunt work" (in your eyes.)

You then live happily with this compartmentalization – an important goal to be achieved by unremarkable people. However, nobody is fooled except you. The people whose compensation depends on your opinion have ample time to remember and analyze your past words and decisions – more time than you, in fact, and a stronger incentive. And so their mental model of you is often much better than your own. So they ignore your requests and become valued, instead of following them and sinking into obscurity.

Examples:

  • A manager truly appreciates original mathematical ideas. The manager requests to rid the code of crash-causing bugs, because customers resent crashes. The most confident people ignore him and spend time coming up with original math. The less confident people spend time chasing bugs, are upset by the lack of recognition, and eventually leave for greener pastures. At any given moment, the code base is ridden by crash-causing bugs.
  • A manager enjoys "software architecture", design patterns, and language lawyer type of knowledge. The manager requests to cooperate better with neighboring teams who are upset by missing functionality in the beautifully architected software. People will tend to keep designing more patterns into the program.
  • A highly influential figure enjoys hacking on their machine. The influential figure points out the importance of solid, highly-available infrastructure to support development. The department responsible for said infrastructure will guarantee that he gets as much bandwidth, RAM, screen pixels and other goodies as they can supply, knowing that the infrastructure he really cares about is that which enables the happy hacking on his machine. The rest of the org might well remain stuck with a turd of an infrastructure.
  • A manager loathes spending money. The manager requires to build highly-available infrastructure to support development. People responsible for infrastructure will build a piece of shit out of yesteryear's scraps purchased at nearby failing companies for peanuts, knowing that they'll be rewarded.
  • A manager is all about timely delivery, and he did very little code maintenance in his life. The manager nominally realizes that a lot of code is used in multiple shipping products; that it takes some time to make a change compatible with all the client code; and that branching the entire code base is a quick way to do the work for this delivery, but you'll pay for the shortcut many times over in each of your future deliveries. People will fork the code base for every shipping product. (I've seen it and heard about it more times than the luckier readers would believe.)

And so it goes. If something is rotten in an org, the root cause is a manager who doesn't value the work needed to fix it. They might value it being fixed, but of course no sane employee gives a shit about that. A sane employee cares whether they are valued. Three corollaries follow:

Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things. Especially someone who spends their own political capital, hard earned doing things management truly values, on doing work they don't truly value – such a person can keep fighting for a long time. Some people manage to make a career out of it by persisting until management truly changes their mind and rewards them. Whatever the odds of that, the average person cannot comprehend the motivation of someone attempting such a feat.

Corollary 2. When does the fish un-rot from the top? When a manager is taught by experience that (1) neglecting this thing is harmful and (2) it's actually hard to get it right (that is, the manager himself, or someone he considers smart, tried and failed.) But that takes managers admitting mistakes and learning from them. Such managers exist; to be called one of them would exceed my dreams.

Corollary 3. Managers who can't make themselves value all important work should at least realize this: their goals do not automatically become their employees' goals. On the contrary, much or most of a manager's job is to align these goals – and if it were that easy, perhaps they wouldn't pay managers that much, now would they? I find it a blessing to be able to tell a manager, "you don't really value this work so it won't get done." In fact, it's a blessing even if they ignore me. That they can hear this sort of thing without exploding means they can be reasoned with. To be considered such a manger is the apex of my ambitions.

Finally, don't expect people to enlighten you and tell you what your blind spots are. Becoming a manager means losing the privilege of being told what's what. It's a trap to think of oneself as just the same reasonable guy and why wouldn't they want to talk to me. The right question is, why would they? Is the risk worth it for them? Only if they take your org's problem very personally, which most people quite sensibly don't. Someone telling me what's what is a thing to thank for, but not to count on.

The safe assumption is, they read your mind like an open book, and perhaps they read it out loud to each other – but not to you. The only way to deal with the problems I cause is an honest journey into the depths of my own rotten mind.

P.S. As it often happens, I wanted to write this for years (the working title was "people know their true KPIs"), but I didn't. I was prompted to finally write it by reading Dan Luu's excellent "How Completely Messed Up Practices Become Normal", where he says, among other things, "It’s sort of funny that this ends up being a problem about incentives. As an industry, we spend a lot of time thinking about how to incentivize consumers into doing what we want. But then we set up incentive systems that are generally agreed upon as incentivizing us to do the wrong things…" I guess this is my take on the incentives issue – real incentives vs stated incentives; I believe people often break rules put in place to achieve a stated goal in order to do the kind of work that is truly valued (even regardless of whether that work's goal is valued.) It's funny how I effectively comment on Dan's blog two times in a row, his blog having become easily my favorite "tech blog", while my own is kinda fading away as I spend my free time learning to animate.

 

Stock options: a balanced approach

…or at least an attempt at a balanced approach.

Do your own math

Dan Luu has recently published a great piece arguing that working for a big company will on average net you more money than working for a startup. If his math makes sense for you, so does his conclusion.

For me personally the math is different. I live in Israel, where a programmer's salary is very unlikely to surpass $150K/year, and $100K/year is pretty good. On top of that, taxes are higher, while prices aren't much lower overall, AFAIK. Based on Dan's numbers, a senior engineer working for Google at their Mountain View site might be able to save $3M in 10-12 years. His colleague at the Tel Aviv site might take 30 years to save that amount. And while a startup might pay less than Google, the difference will be much less than 2x, and nothing near the 3x-5x multiples mentioned in Dan's post.

Beyond math

Did I land at a startup because I figured the stock options were valuable? No, definitely not. In fact, while I was granted some laughable amount of stock options, I had no idea how it all worked – strike price, vesting, I didn't even know those words. How did I end up with the job then? I'll tell you how.

At the time nobody, and I mean nobody, would hire me. In hindsight, the reason was as obvious as it was misguided. They wouldn't hire me because I projected a large degree of mental imbalance. They were misguided because in terms of performance/price, I was solid gold. I'd work as hard as you can imagine for peanuts, and, nuttiness of youth aside, I knew my shit. I often wonder if today's me would hire then's me. I know I should, but I'm not sure I would.

6 months passed, and not a single job offer. To cheer myself up, I'd send SMSes to friends which supposedly parodied my missives to potential employers, along the lines of "Hi, my name is Shitface McArsefuck. Do you happen to be in need of a programmer?" And so it went from bad to worse, until EB called.

EB was among the tiny number of people I "networked" with in the university. I originally contacted him to get advice on building a 3D scanner from a commodity camera and clever software that reconstructs 3D geometry from images. (He immediately explained why it wouldn't work. Then I somehow convinced him to spend the next 3 months on a failed attempt to do this.)

And now he recommended me to this startup which he just joined. And I passed the interview, nuttiness and all, no doubt because of that recommendation.

My point being, maybe you just happened to land at a startup because it so transpired. Maybe you didn't pass the interviews at the big companies for some transient reason, maybe you'd pass them a year later but right now you didn't. Maybe the startup is right near your home and your friends work there. Whatever the reason, right now you're there.

The question now is, should you ignore the equity part of your compensation? And the answer, of course, is…

Do your own math

Here are some points to consider:

  • A lot of the problems with equity are solved by getting more equity. It doesn't help if the stock ends up completely worthless. But dilution, a long time spent waiting for the IPO, a high strike price, and, in some scenarios, liquidation preferences – all of these problems are helped a lot by having more equity.
  • They call stock options a lottery ticket. I call it insurance. It sucks to have worked at a startup which did make it big and to not have made anything off it. Incidentally, I know quite a lot of people who either forfeited their stock options or sold them very cheaply, on the theory that equity is worthless. Trust me, if you're working for a startup, this is the one accident you want to be insured against.
  • Who has invested in this company at the latest round? VCs often lose their entire investment. On the other hand, investment banks like Goldman Sachs tend to make money, and so do investment management firms like BlackRock. Sounds obvious – and yet I knew people with more financial literacy than myself who'd say "how much more can this stock go up?" after GS or BlackRock invested in the company. The right answer is that now it will most definitely go up, albeit perhaps by a smaller percentage than in previous rounds. Which brings us to the next point:
  • Percentages are not absolute amounts, and you care about the latter. If the stock goes from $1 to $10 (a "large" 900% increase), you get $9 when you exercise the option. If it goes from $50 to $70 (a "small" 40% increase), you get $20. Sounds obvious – and yet I knew people who're way better at math than me, who preferred tiny cash raises to sizable stock options grants, right after an investment round involving firms which rarely lose money, on the theory that "the stock is too expensive already."
  • These days it takes companies a lot of time to go public. As an employee, it largely works to your advantage. It gives you time to become valuable and to then ask for more equity. To a private company, even one with serious late-stage investors, equity is still pretty cheap, and there are few enough employees for some to have gained significant bargaining power. So it might be sensible to initially ignore equity and mainly ask for cash raises – the company is too likely to tank at this stage, while your bargaining position isn't good enough to get enough equity for it to matter anyway. Later on, when your salary gets closer to the ceiling, and the stock becomes more valuable, and you will have become more valuable to the company, ask for equity. (The downside of asking later, of course, is that they give increasingly less of their increasingly more valuable stock over time. But the difference in bargaining position might be larger than this unfortunate effect.)
  • To actually negotiate more equity, to a first approximation, you must be ready to leave over this point. Leaving might mean losing whatever stock options you already have. This is where the advice of people who tell you to ignore equity paradoxically comes in handy! (I do know people who managed to find an outside investor who helped them buy their stock options; whether you can legally do this in your particular case is a question to a lawyer.)
  • The variance in options-based compensation is vastly larger than the variance in salary. One reason is that stock options are very cheap for private companies, and it's therefore their preferred way to motivate their favorite employees. I suspect that another reason is, you getting 10x my salary tends to piss me off much more than you getting 10x the stock options. Right now you can't spend the stock options, so there will be no changes to your lifestyle signaling to me that you're better off than me, and then even if I knew, I might not care as much about stock options, which might, after all, be worthless. The upshot is, if you want to increase inequality in the world by getting an outsized compensation for your supposedly outsized contribution, stock options are your #1 route.

One point on equity negotiations

All the usual advice on negotiation, of which I'm hardly a good source, applies here. But on top of that there's one specific point when it comes to equity and it's this.

Suppose the party line is, this company will be worth $50B, but you think it'll be worth $20B (right now it's valued at $10B.) And let's say you want to ask for enough stock options to net you $1M.

The wrong thing to do is argue that the company will be worth $20B, and ask for an amount netting you $1M on that theory. They'll tell you that you're wrong, that it'll be worth $50B, and here's 1/4th of what you ask for, and it'll net you your $1M.

The right thing to do is tell them you want to end up with $4M (or better yet, $8M) and ask for an amount netting you that, according to their $50B theory – in the hope of getting half of what you asked for, and then 1/4th the capital gain they predict, overall $1M.

Why? Because it's much, much easier to argue that your contribution is worth $8M and that you can make it elsewhere than it is to argue that the company isn't worth what they tell everyone it's worth. Of course your common sense cries foul at this: "but you can't make $8M elsewhere! And the company might end up worthless, for all we know! Surely arguing that it's not worth $50B is more sensible than arguing that you are worth $8M, because it isn't, and you aren't!"

Well, common sense is wrong, because common sense is not a salesman (in fact, it's a salesman's worst enemy.) "We're both unusually valuable" simply sells better than "neither of us is". So do go for the former.

Expiration dates

Stock options have expiration dates. With the time it takes companies to file an IPO these days, yours might expire earlier. Don't miss that moment, and make sure they extend the date (a private company can easily do it.) Make sure to ask for the extension as early as possible – you never know what things will look like at a later date. While all is well, it's a trivial request. But not all is well at all times.

From competent programmers to terrible investors

It might well be that, having worked your ass off, and having negotiated a nice chunk of equity, you'll sell it at some early liquidity event for a fraction of the IPO price or some such. With this shit, trading skills/luck might dwarf the rest of your skills. A bit depressing, that. But don't get depressed. Here, I'll cheer you up. My name is Shitface McArsefuck. Do you happen to be in need of a programmer?

There are many schools of thought with respect to trading strategy. I recommend the following method:

  • When you can, sell enough to get a sum of money that buys you something important. Something so important that, if you won't buy it now, and you won't get another chance, you will have a hard time forgiving yourself. That something can be a house, or enough money for some crazy trip you dream about, or enough money for "financial independence" according to your definition, whatever.
  • If you're left with stock and selling it does not buy you something important, keep it, or sell in little bits, so that you spread out the selling of the whole amount over a long period of time.
  • Try to not be fully vested at all times (your employer should be willing to help you with it), so that these rules don't result in the selling of everything at what in hindsight is a low price.

The point of this approach is to think hard about what you really want, and not miss a chance to get it. I expect it to net worse results on average than a strategy aiming at maximizing the mean profit, because it does not try to maximize the mean profit. What it does attempt to do is minimize regrets, and unlike maximizing strategies, it takes your personal priorities into account.

(Incidentally, the differences in personal priorities might make the best strategy for me a terrible strategy for you. The question isn't where the price will go – and BTW nobody can answer that, anyway – but what you need the money for. I wish I understood that before giving people what in hindsight was bad trading advice.)

I strongly recommend to refrain from selling everything upon the first opportunity under the assumption that diversified risk is always better than concentrated risk. People who understand the "rationality" of this argument should also understand that it's somewhat rational to spread the selling over some period of time, because stock prices tend to be volatile and you're rather likely to have sold at a bad moment.

More importantly, people underestimate their own irrationality. Yes, it's crazy to put a large amount of money in a single stock, but it does not follow that it's equally crazy to hold that stock. Stock analysts understand this, which is why they have a Hold rating – don't buy this stock, but if you already have it, don't sell it. Holding a position that you wouldn't buy makes perfect sense for a human, because a human tends to get very upset if they sell it and then the price goes way up. I say, unless selling it all right now is your way to buy something that you absolutely must buy, don't.

Are stock options worth it for employers?

Absolutely. It does nothing to motivate most but it does wonders to motivate some, and then it's really cheap for the employer.

Conclusion

Overall, if you're at a startup and there's no compelling reason to leave (as there might be if you can make $3M in 10 years at a big company, or start your own business, whatever), make sure to maximize your equity. From a regret minimization perspective, it's not a lottery ticket, but an insurance policy. If the company makes it, you will not be the one who came out with nothing. If it doesn't make it, at least you took a shot.

A manager's pitfall: striving to "add value"

There's this guy I work with who has a head the size of a small planet. In that head, dozens of design decisions big and small are made every day. Hundreds of options clash in his mind: which gives us the best trade-off between 3 different desirable things? Or 5 things, or 12, as the case may be?

And the thing about this guy is, he'll always make the decision, because you must, because deadlines. So not the kind of guy who just gets stuck in the multitude of possibilities, nope, not him. BUT he's normally unhappy with the decision, because you see, there wasn't time to REALLY evaluate it PROPERLY.

So we've been working with this guy, and he'd often ask me to help decide something at his end.

At first I'd ask about the details, and I'd propose solutions. And he didn't seem very happy with that, and eventually he got seriously pissed off. That was when I asked for a really big new feature, and he said it wasn't doable, "forget it."

So I said, "let's see though, what makes this so hard? Because I'm willing to throw a lot of it out and do just the most bare-bones version. Maybe then it'd be doable." So I was helping him, I was willing to ask for less, right? So I sure didn't expect the outcome, which was, he rather forcefully said he couldn't work like that any longer, with no stable specs and no real schedule and it's just him doing this after all AND…

At this point I sorta gathered from the form and substance of his speech that I should back off, RIGHT NOW. I said, "look, if you add this, all I can say is, the whole thing will be much better. But if it can't be done, fine, we can live without it. It's entirely your call and I have nothing to add."

And then he did it. Not some bare-bones, half-assed version, mind you, he did a pretty impressive full-blown thing. Then he redid it to make it better still.

So clever me thinks to myself, aha! I see, so what annoyed him wasn't how I asked for this huge feature in itself. What annoyed him was me demanding him to tell why it was hard, so I could break it up into parts, and tweak it, and basically solve this myself. He didn't really mind solving it if he did it, provided that

  • It was a request and not a "requirement" – because someone like me who doesn't really understand what goes into it has no right to just require it. You're not entitled to things you can't even comprehend, asshole!
  • …and I wouldn't try to "help" him by attempting to remedy my ignorance at his expense, questioning him on the details and then hastily "making it easier" for him, without thinking deeply enough whether making it easier was even NEEDED, and so  tricking him into making some pale no-good version of it! And then HE, because of ME, because of my impatient superficial "help", will have done a bad job! No, he doesn't want it easy, he wants it done right, so take a hike and give him time to decide what the right trade-off is, where to work harder and get more done and where to do less.

OK, so that's how it's gonna work from now on, I thought. From then on, if he wanted me to help him decide something, I'd just ask him what options he had in mind, regardless of what I could come up with myself. And I'd say this one sounds good.

This sort of worked, but he still didn't seem quite happy. And at one point he got pissed off and demanded explanations why I thought his option A was better than his option B. And I gave my explanations, and he thought they were shit. And I said, you know, A and B are both alright. Pick whichever you like better. "What?! So why did you just say that A was better?" "I dunno, I was wrong, you convinced me, it's a tough call."

Now I finally got it! So the way it works is, he thinks something through, for hours and days. If it's still a close call, he comes to me, whom he genuinely respects, and who's got the nominally higher seniority. What he comes to me for is superior wisdom. What he doesn't realize, out of excessive humility, is that there's no way I'll be better at deciding it than him, because he's better at it than me, and he's been thinking about it for so much longer.

And he only comes to me with what to him are the hardest things, guaranteeing that I won't be able to help, not really. So trying will just piss him off because I'll necessarily be suggesting some pretty dumb and superficial decision procedure, which is like helping Michelangelo with a sculpture by lending him a sledgehammer to just remove all that big chunk of stone over there.

So from then on I'd listen to his doubts, and agree that it's hard because of this thing we can't measure and that other thing we can't know, and say optimistically that either way I think it'll come out alright but it's his call, really. And he appeared very happy with my careful supervision of his work.

Bottom line for me was, I did very little hard thinking and a pretty cool project got done, I think, and the guy was happy, at least as much as he can be in this imperfect world. What's not to like?

The thing many of us managers don't like in such cases is, we seem to have added no value. Where's my chunk of value?

"He who does not work doesn't get to eat", they taught me in the USSR. "To capture value, add value" would be the translation of this slogan into MBA-speak. "By the sweat of your brow you will eat your food", says the Holy Bible. None of this prepares you for a managerial role, where not doing shit is usually better than trying too hard.

A manager on a mission to add value usually thinks that it's his job to have all the good and important ideas. Corollary: someone else having many of the good and important ideas means you, the manager, are bad at your job. Will you accept this and suffer silently, or will you convince yourself that the report's ideas aren't that good? You don't want to find out. I say, don't put yourself in this situation in the first place, don't try hard to have the good ideas, look at your ability to not do shit in return for a nice compensation as both your new virtue and your immense luck, and relax.

If you're really addicted to making tangible contributions, I suggest to do what I've been doing in managerial roles – do some of the work yourself. Now, this is, without doubt, terribly irresponsible, because it makes me unavailable at unpredictable moments. When shit hits the fan and I must attend to it in my contributor's role, it prevents me from attending to the never-ending fan-hitting shit that the people I manage deal with.

There's also an advantage, and that is that I know how much things really suck in the trenches. And that's good, and anyone overseeing less than 50-100 people should stay current that way, I think. But don't "stay current" by working on urgent mission-critical shit (as I often do, because I suck.) Pick something unimportant instead.

Anyway, working myself is immensely better than trying to have the good ideas myself, I believe. This can result in not being there when they need me, but it never results in being there when they don't, which is worse.

If it's not the deep thinking, then what do managers do, except for sitting on their asses? I started putting it down, and it didn't come out very well, and the reason ought to be that, well, I don't really get it at this point. I'm a middling manager, whose main skill is attracting strong people and then taking credit for their work. And this one managerial skill compensates for the underdevelopment of the rest so well that they, unfortunately, remain underdeveloped.

So until my understanding of the managerial role improves, the one thing I will say here is, many people actually don't do shit most of the time and it's fine – say, lifeguards. Why do you need them? Just in case. So that's one way I think about myself - I'm like a lifeguard, except for the physique. Maybe I should use the time freed up by not having to do deep thinking to work on my pectoral muscles, so that one day I could star in "Programmer Watch", a "Baywatch" rip-off about R&D management. But I keep my hopes low on that one.

I say, quit "adding value", fellow managers. Just sit back and take credit for others' work. They'll thank you for it.

P.S. angry hamster – this one's for you.

"Information asymmetry" cuts both ways

They pretend to pay us, and we pretend to work.

 – A Soviet-era political joke according to Wikipedia, though I've only seen it in an English text describing the C++ object model

Having been born in the USSR, #talkpay – people disclosing their compensation on May 1 - put a series of smiles on my face, expressing emotions that I myself don't quite understand.

The numbers certainly left me pleased with the state of the oppressed proletariat (web designers, computer programmers, etc.) in the rotting capitalist society. I do hope that the $125K/year proletarian will not feel resentment towards the $128K/year guy in the next cubicle. I hope as well that the second guy's manager won't deny him a promotion so as to avoid further offending the first guy.

"Hope", yes; "count on" – no, which is why I won't be tweeting about my compensation. Because my numbers are almost certainly either lower or higher than yours, and why needlessly strain our excellent relationship – am I right, dear reader? (The other reason is having no Twitter account.)

So, yeah, a series of smiles and a range of emotions. But today I want to focus on one particular bit – the one mentioned by Patrick McKenzie:

Compensation negotiations are presently like a stock exchange where only your counterparty can see the ticker and order book. You’d never send an order to that exchange — it would be an invitation to be fleeced. “I happen to have a share of Google and want to sell it. What’s it go for?” “Oh, $200 or so.” “Really? That feels low.” “Alright, $205 then, but don’t be greedy.”

The spot price of Google when I write this is $535. Someone offering $205 for GOOG would shock the conscience. …folks have received and accepted employment offers much worse than that, relative to reasonably achievable market rates.

All very true, except that with a share of Google, they're all the same and you arguably know what you're buying, and with an employee's services, they aren't and you don't.

There seems to have been a string of Nobel Prize-winning economists who founded "X economics" – such as "behavioral economics" or "information economics." The common thing between "X economists" is, they all (correctly) tell me that I'm irrational and misinformed. But then they conclude that it's them and not me who should manage my money. I believe the latter does not follow from the former. But I'll save that discussion for another day.

In particular, Stiglitz, the information economics guy, opened his Nobel Prize lecture with an explanation of his superiority over other economists. This state of things arose, according to him, due to having grown up in a small town in Indiana, where things didn't work as predicted by standard economic models. Specifically, the proletariat got shafted, prompting Stiglitz to come up with formulas predicting how badly one can be swindled due to his ignorance of the market conditions.

Which is probably very true and relevant, but it cuts both ways. A guy paying me to work on a conveyor belt could measure my productivity perfectly, and probably knew the market for my labor better than I did – clearly he had an advantage. A guy paying me to program, however, might know more about wages than I do. But he certainly doesn't have the foggiest idea what I'm doing in return for his money, even if he's a better programmer than I am.

Basically the "knowledge worker's" contract is something like this:

We'll give you a precisely defined salary and a benefits package. In return, we request that you handle some problems that we're told we're having. We hope that you'll solve them well enough to prevent us from having to know what they were in the first place. Please help us maintain the feeling that we own an asset similar to land or gold or something. Please keep the realization that we're more like the operator of a flying circus than a landowner from disturbing us. And certainly, never, ever ask us what to do with any of the moving pieces of this flying circus, because we seriously have no idea.

Of course, most people have a direct manager overseeing their work in the flying circus who knows more about it than the owner. But, ya know… "…then for the next 45 minutes I just space out", as the quote from Office Space goes. Seriously, it's bloody hard to tell if you're only working at half your ability – the only guy who knows is you. And this information asymmetry seems to me kind of symmetrical with that other asymmetry – employers being better at tracking the labor market, negotiating, etc. So, see the "Soviet" joke at the top of the page…

(Of course it's much better with an actual market for labor – I'm just saying that it's still far from perfect, and it'll get increasingly farther from "perfect" as the knowledge becomes more widely dispersed and you basically just have to trust experts at every step. An economy of dishonest experts – now that's a bloody nightmare. And by the way I actually think we now have enough newfangled technology together with ages-old fallibility to get there. AAA-rated MBSs is just the beginning.)

For a closing remark, I think it's fitting to mention all those bozos saying how "higher compensation does not increase motivation." (A management consultant saying something else might not get his management consulting gig, so I understand where they're coming from.)

To that I say: for me, at least, higher compensation leads to higher awareness of "spacing out" and such – call it "guilt" if you like. Pay me enough and I will think things like, "I'd really like to ignore this here shit, and it's SO ugly, and nobody will ever know. But, sheesh, they paid me all this money, just like they promised. And I sorta promised that I'll take care of the flying circus in return. And so it's seriously not OK to leave this here shit unattended. I better tell someone, and what's more, this here patch is definitely mine to clean, so here goes."

One danger in underpaying someone is it might prevent those thoughts from entering their minds. So, employers – caveat emptor. 'Cause goodness knows that the easiest way to raise one's compensation in the knowledge economy is to simply space out more while getting paid the same.

#talkpay…

Capital vs labor: who risks more?

AFAIK, in the developed world, the income tax rate is often higher than the capital gains tax. In particular, income is taxed "progressively", meaning that higher income results in a higher rate – which doesn't always happen with capital gains. (It looks like it does happen in the US, but income appears to be taxed "more progressively".)

One justification for this is that investors risk losing much or all of their capital. Workers, on the other hand, are guaranteed their wages. To some extent, the difference in the tax rates compensates for the difference in the risks.

To me this is sensible at first glance but completely harebrained on second thought:

  • The worker's big risk is choosing the profession. Higher-income professions often require a more expensive education. If the demand for the skills drops in the future, the income might fail to cover the worker's investment into acquiring these skills. Assuming that learning ability drops with age, the risk increases proportionately.
  • Moreover, this risk is not diversified. Even a small-time investor can spread his risk using some sort of index fund, betting on many stocks at a time. For a worker, on the other hand, there's no conceivable way to be 25% lawyer, 25% carpenter, 25% programmer and 25% neurosurgeon.

The latter point may not interest utilitarian economists focused on GDP "the greatest good for the greatest number" – for society as a whole, risk is always diversified, even if Joe Shmoe is stuck with the crummiest profession that looked really promising when he chose it. Moreover, an efficient market would provide a way to insure against the risk of poorly choosing your occupation. (I don't think real-life markets did provide such a thing, though I might be mistaken.)

But the first point – that the risk exists, and that it's more likely than not to be proportionate to the projected income – by itself kinda erodes the ground underneath an income tax higher than the capital gains tax, not? I mean, regardless of the motivation, it seems internally inconsistent. Unless the risks are all quantified and it all magically cancels out.

It's not that I'm complaining – unlike most professionals, we programmers get stock options. (Speaking of which - central bankers of the world, The Programmers' Guild says thanks a bunch for QE and ZIRP! Remind us to send some flowers.) I just honestly don't get it.

Econ-savvy readers: what do I miss?

(Please don't accuse me of failing to use the Google. Maybe I did so badly, but I did try using the Google. The Google told me, for instance, that the optimal capital gains tax is zero, because "you can't transfer from capitalists to workers", because the transfer depletes the capital pool or something. But I didn't understand how it accounts for the case where the workers are also capitalists because they invest their savings; and what if there's a progressive tax on capital gains? Is it, or is it not possible to "transfer from capitalists to workers" the flesh and blood people, as opposed to abstract categories, regardless of whether you'd want to? Or if that's all nonsense – then is the optimal income tax also zero, because, hey, you're actually taxing human capital gains? Bringing us back a couple hundred years ago where we just have a sales tax? And again, not that I'd complain, I just don't quite follow the logic.)

(Also from the Google there's the claim that since nominal capital gains are taxed, the tax rate is actually higher than it looks because of inflation. But then the solution would be to tax inflation-adjusted gains, not to lower the rate arbitrarily, not? Also, wages are AFAIK the last set of prices to rise upon inflation – the "stickiest" – so workers' investment in their skills is continuously nibbled at by inflation as well. And the point made about "discouraging savings" – well, a high income tax discourages costly education and the subsequent ongoing investment in one's skills, which is a form of investment/savings/call it what you like. Same diff.)

I think it's pretty obvious that workers risk much more than investors. Whether this should lower their taxes I don't know, but it sort of makes sense to me.