This is great. I particularly liked this observation:
> Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
A lot of the ideas in here resonated with me a lot. This is the kind of article I wish I'd read before I spent a few years leading an engineering team at a medium-sized tech company!
Ya, I think this is a great insight. In today's world, code is not released as a versioned artifact sold on a disc or downloaded. The idea of "shipping" is fuzzy. You might be 100% in production with some change and it could still leave edge case, deficiencies, etc. You can decide to address them now or later. And it's all just perception. You can say it's good enough, we shipped, let's forget about this whole thing and move to another. Or you can keep ironing out the quirks.
I've "shipped" things in the past that were turned on to less than 1% of the time, and we left it at that, and moved on to other things. It was considered "shipped". Everyone was worried to increase it to beyond 1%, so we all patted ourselves in the back for the great launch and went to work on other things.
There was always something intensely satisfying about walking into some retail store and seeing boxes on the shelf containing CDs with software I'd written.
(On the flip side, there was that one time we had to destroy 5,000 CDs because they had a Quicktime Autostart virus on them...)
Sometimes it’s odd to realize there’s people that can say this while simultaneously not being my grandfather. There’s a whole period of computer history I skipped.
This is the reality. And if you happen to be in an environment with less cooperative folks, get your requirements to ship in writing, agreed upon, and as up front as possible. Hold them to it. Otherwise, it just opens you up for nitpicking, and in some cases goalkeeping, by folks whom end up delaying your shipping.
Yes but otoh that might be more of a “I refuse to accept a culture of optics on principle” kinda situation, rather than not understanding it. I liked the post because it’s honest and doesn’t put a value judgment on things, just explains how it works. It’s up to each and everyone to act accordingly, and one of those actions is to not participate in the lunacy that often arises in the higher echelons. Many people are fine keeping their integrity, mostly left alone to code, avoiding social deception games at the expense of not being promoted out of what they fell in love with in the first place. People are just different.
Refusing to accept a culture of optics is tantamount to not understanding optics though. The reality is that if you work on any kind of product, optics do matter - the perception of something working is often just as important as it actually working.
It can't possibly be "just as important" - in some cases, I will accept "almost as important", but any situation where the optics are "it works" and the reality is "it doesn't work" is eventually going to come crashing down on someone's head.
If it doesn't need to work, then it doesn't matter and the optics also don't matter. Of course, it might be more important for your promotion that the optics are correct, no matter what the ground reality is, and the crash could come down on someone else's head instead of yours, but in this scenario someone who is against a culture of optics rather has a point.
If you shipped and nobody important enough knows, then you haven't shipped in the eyes of the most important people.
I'm the first person to agree with you that it sucks that optics are important. But they are. You can definitely ship shit with great optics and get a promotion and be far away before that shit hits the fan.
But if you ship the greatest thing since sliced bread and nobody notices, then you might as well not have shipped at all.
Lots of things are popularity contests. It’s very difficult to escape when you’re in it, but they always fizzle out, leaving remarkably little behind. Your promotion at Enron has no meaning today, but at least the little string parsing library you wrote may still be in use and someone is happy about it, decades later.
The point is that your impact isn’t defined by a McKinsey trained head of HR who gamified a career ladder for you, or the opinion of “important people”. In fact, what impact means depends on where and (crucially) when you measure it.
Some professions have longer reward cycles than a human lifetime. Great writers, artists and thinkers are often recognized posthumously. Doesn’t mean everyone should write poems, but we shouldn’t exacerbate a culture where you’re useless if you can’t charm your closest mediocre middle manager. Life is more.
Oh absolutely agreed on lots of things being popularity contests. And I don't like that fact either.
It's still important unfortunately.
Your promotion at Enron still has meaning today because it bumped you up the career ladder early on in your career and your next job after that was a step up from that etc. 20 years of elevated salary because you climbed the career ladder early adds up to real dollars in your investment accounts.
Do I like it? Absolutely not and I am trying to stay at the level I'm at right now for as long as I possibly can, because my job is not entirely a popularity contest and still has real good software engineering and actually building software that real people use and love in it. If I "climbed" any further all day every day would be a popularity contest. But I do recognize that being allowed to continue building that software requires (as in "it's important") to take part in some of these popularity contests.
(talking paid work wise here - if you're OK to live in a basement doing meaningful open source work that will outlive you for the rest of your life and it makes you happy, then power to you - not most people's reality)
I see your point, and I agree. I think it comes down to weighing strategy, tactics and values. Values can really only have impact once you have some form of influence. And tactics can be necessary to establish yourself, even more so in a world increasingly governed by micro-algorithmic engagement and short termism. But it can also be dangerous in the sense of perpetuating values you don’t agree with, not least within yourself - a tactical win but a strategic failure. Some people pull it off - like Dave Chappelle, getting “fuck you money” early and staying real.
"Appreciate" is a weird word. At least for me (not an English speaker) it has a positive connotation so with that in mind I sure hope nobody appreciates the importance of optics. The concept is dumb but it is important and we have to play the game to achieve anything.
Why did you read that as 2 though? Is there a context clue I'm missing or is there some grammar rule I don't know of? Honest question, I'm Polish.
For me there's a huge gap between 1 and 2 so it might cause misunderstandings when used in a sentence. I despise a lot of things I fully understand and if I said I "appreciate" them - sounds weird.
It's heuristics, not grammar. You usually appreciate a noun or noun phrase in a transitive sentence (X appreciates Y).
Case 1: If it's something useful (e.g. 'your help', 'what you did') then it's more likely about being thankful.
This use of 'appreciate' is also a social action. You say it to make someone feel good for helping.
Case 2: If it's an abstract thing (e.g. 'the importance of', 'the difficulty of') then it's more likely you're talking about understanding.
Usually when you talk about this usage it's because the _fact_ of understanding is important to the speech act. If someone explains the law of gravity you don't say "I appreciate that", you say "I understand that". But if you fell from a height and hurt yourself you can say "I didn't appreciate the law of gravity".
Case 3: If it's intransitive and it's about money ('the car appreciated in value', 'the house appreciated in value').
It's a pity that heuristics are not mentioned in most language books or dictionaries. At least I wasn't taught any in school (10+ years ago). This should be next to the word definition.
Similar is "enjoy", which is almost always possible but sometimes can be used in a more... detached sense? "Perspectives in nature we rarely enjoy" as seen in The Far Side here, for instance.
Optics are not dumb. Corporates are very noisy. It is difficult to extract the signal from the noise if you're not working on a project full-time (as most people are, except for you, the tech lead), and it will definitely not happen by accident. That's why you need to manage optics.
I agree that they are very important but I still call it dumb in a "it's stupid that we have to do this because we suck as a human species" kind of way.
I think that's what the word "appreciate" is hinting at in the phrase: "most engineers..don't appreciate the importance of optics."
Optics is subjective and often superficial, a performative illusion for the sake of whoever is looking at you. But that doesn't mean it's not valuable or useful in a social context.
Here, I read the word "appreciate" to mean, to recognize the value of a thing even if you disagree with it.
For example, someone could be a pacifist and still appreciate the need for weapons for national defense. They may not agree with the means but still admit it has value and effect.
Weirdly, optics have never mattered at all in small or startup companies. And they manage to do pretty well, ship a lot of product and become large companies.
Maybe the problem isn’t the engineers, but the need for optics…
It definitely gets worse as the organisation grows. There isn't much room to hide in a five person company whereas it's hard to be seen in a 5000 person organisation.
It's a matter of scale. "Optics" (as a separate concern) don't matter at orgs that are small enough that everyone can see everything (and/or has full trust in the people who do). Visibility and trust don't scale, hence the necessary evil of pageantry
It's a term that has been adopted to sound more professional than "keeping up appearances" which is an age-old concept. It is about how things are/will be perceived by others, rather than the truth of the matter.
The emotional perception of the quality of you, the worker, in the eyes of the leadership who pays you. It is distinct from your true value and contributions. It is maximized by you optimizing the visibility of things that boost reputation and minimizing the visibility of embarrassing things.
There is a tendency here to pattern match the advice in this article with frustrating experiences about office politics. But I dont see this as a post about politics.
Rather, what I got was that the spec is an incomplete description and there needs to be more inquiry into how the software is going to be used. This can require a little bit of 'going up the stack' to see how business need relates to the software requirement(single enterprise customer with a precise requirement, acquisition of new customer, software for some internal vision of CEO etc). Compare with a startup where one doesn't even have a spec and one is trying to find a product-market fit or when developers take sales calls and find new insights on how the software is actually being used.
A completely broken spec is indeed a failure in management process. But, in general, it helps a library developer to think beyond a library spec and see how it is being used.
Yes. Unfortunately, it comes with a side effect, you will see leadership use this to kill projects they don't like by not never mentioning them until people think it's a failure.
If you are working on something the people deciding on the size of your paycheck want to kill, time to find a new project or a new company. Why fight a battle you're sure to lose?
If only you could figure that out ahead of time. I've been on projects that were killed with no notice anyone could see even in hindsight. I've been on important projects that senior leaders decided to out source my job to China and my boss was forced to let me go. I've seen budgets run dry many times and important projects got killed/cut with no notice (sometimes there are signs that but you think your project is important enough to escape the cuts until it isn't). Sometimes you are doing working everyone tells you is critical the day before they show you out the door.
I've also seen people make careers out of taking over projects cut for the above reasons as customers still demand support. I've seen many downturns where my project was important enough to not be cut.
I've seen many downturns where my project had massive cuts, but I personally was not the person cut. Most often projects are not killed outright, instead they go through a long down spiral (not always, but typically) and you can make a lot of money being the expert on a product that is making money if you are able to hang on. Someone needs to leave as there isn't the budget to pay everyone, but that someone need not be you. Often these projects pay very nicely for working 9-5 with no pressure to do overtime.
> Sometimes you are doing working everyone tells you is critical the day before they show you out the door.
I know this may appear so but the signs are there. We only want this to be true so we do not see it.
I've been in a similar situation where all we were seeing was high pressure to deliver something. This made it appear that is because the project is important. But the underlying reason was that if we didn't, the project would be dropped. Which they did.
A project may be critical but even more so is to be in a certain time frame and budget, otherwise the project doesn't have a reason to exist any more. But until that moment is still very important because, at the very least because there was a lot of investment into it.
Note that it can get trickier than it sounds. (Well, I don't know about big tech, but at least for medium and smaller.)
You need to figure out who the "important people" are, and somehow make sure that they understand and buy into the product definition, delivery dates, etc.
Even if they're 3 levels up from you, and you can't normally interface directly with them, try to find a way to double-check that all the "important people" are on the same page.
Organizational dysfunction happens, and you have to succeed despite that possibility.
In my experience, most things in large companies are social constructs. Good things are good because they were decided to be good, bad things are bad because they were decided to be bad. Very rarely are they driven by actual metrics.
> Shipping is a social construct within a company. Concretely, that means that a project is shipped when the important people at your company believe it is shipped.
A lot of the ideas in here resonated with me a lot. This is the kind of article I wish I'd read before I spent a few years leading an engineering team at a medium-sized tech company!