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.
> Spatial memory is a very useful and important part of navigation.
Oh yes! And so under appreciated. Things that have their place is absolutely crucial. Imagine if your menu bar sorted based on how often you used “edit” vs “file”. Or why not have the keys on the keyboard change based on frequency? I’d argue we should leverage spatial- and muscle memory much more in UX and design.
Yes, and memory palaces work this way. People remember 20-50 items (or cards) at once by simply placing them at a familiar location. “A racoon sits near a red vase at the entry with his legs crossed and a rhino spilled half the bath on the floor”.
It’s strange that UX overlooks space so badly and uses same-{shape,color,font} elements everywhere. I guess it’s due to that Bob meme, what else.
There’s “Raskin”, but it also isn’t perfect in this regard.
All languages have these problems. Even Go with famously excellent std has many rough spots that either were not available (such as context) or was just a bit poorly designed.
The most important job of std is not (contrary to popular belief) to provide a “bag of useful high quality things” but rather providing interfaces and types that 3p packages can use without coordinating with each other. I’d argue that http.Handler, io.Reader/Writer/Closer are providing the most value and they are just single method signatures.
When there’s universal agreement of what shape different common “things” have, it unlocks interop which just turbo charges the whole ecosystem. Some of those are language, but a lot more is std and that’s why I always rant about people over focusing on languages.
No dog in the fight here, but this reads like FUD, at least given the context of this post. There is a range between hype and skepticism in debate which is healthy, and that range would naturally be larger within a domain that is so poorly understood as gen AIs emergent properties. If this is “fringe nutjob” levels of skepticism, then what would be reasonable?
> when a company puts completely different projects together inside a single repo.
This is google3. It was absolutely loved by the majority of devs. If you change a line of code, all dependencies are type checked and tested and also a bunch of other things. It keeps so many versioning issues out.
One of the big reasons why the JS ecosystem is so fragmented compared to Go or even Rust is the leftpad-sized packages with 10 config files that are out of date. Not to mention our friend peerDependencies, who needs no introduction.
Not to mention when you need to make cross repo changes in development, and you have to set up a whole web of local repointing in package manifests. Repo is a hard boundary. Sometimes you need one. But to create a boundary when you don’t have to, on things that are deeply interconnected and have nowhere near a stable api? Utter madness imo.
To add to this: the built in go race detector is very good at catching data races. It’s a runtime, but I’ve never had a race that couldn’t be reproduced in the race detector trivially.
But yes, in theory Go has a memory safety problem because of it. In practice though, it’s that people don’t use the race detector, which is ridiculously easy to do.
Of course. But this will be true for OpenAI and all other AI players as well. During the honeymoon phase user needs matter, that’s how they get you. Comparing a company in the free-money phase with one in the value extraction phase is apples to oranges.
It’s not the right approach. Structural engineers shouldn’t let management fiddle with their safety standards to increase speed. They will still blame you when things fail. In software, you can’t just throw in yolo projects with much lower “carefulness” than the rest of the product, everything has maintenance. The TL in this case needs to establish a certain set of standards and practices. That’s not a choice you give away to another team on a per-feature basis.
It’s also a ridiculous low bar for engineering managers to not even understand the most fundamental of tradeoffs in software. Of course they want things done faster, but then they can go escalate to the common boss/director and argue about prioritization against other things on the agenda. Not just “work faster”. Then they can go manage those whose work output is proportional to stress, not programmers.
Management decides whether they build a cheap wooden building, a brick one, or a steel skyscraper. These all have different risk profiles.
Safety is a business/management decision, even in structural engineering. A pedestrian bridge could be constructed to support tanks and withstand nuclear explosions, but why. Many engineered structures are actually extremely dangerous - for example mountain climbing trails.
Also yes, you have many opportunities to just YOLO without significant consequences in software. A hackathon is a good example - I love them, always great to see the incredible projects at the end. The last one I visited was sponsored by a corporation and they straight up incorporated a startup next day with the winning team.
If management intends expected use to be a low-load-quick-and-dirty-temporary-use prototype to be delivered in days, it seems the engineers are not doing their job if they calibrate their safety process to a heavy-duty-life-critical application. And vice versa.
Making the decision about the levels of use, durability, reuse-ability, scalability, AND RISK is all management. Implementing those decisions as decided by management is on engineering. It is not on engineering to fix a bad-trade-off management decision beyond what is reasonably possible (if you can, great, but go look to work someplace less exploitative).
What you wrote didn’t really refute my point either.
If management allocates time and resources only for a quick-&-dirty prototype not for public use, then releases it to the public with bad consequences, they will definitely ask the engineers about it. If the engineers properly covered their paper trail, i.e., kept receipts for when management refused their requests for resources to build-in greater safety, then engineering will be not responsible. Ethically, this is the correct model.
But if he & you are saying that management will try to exploit engineering and then blame failures on engineering when it was really bad management, yup, you should expect that kind of ethical failure from management. Yes, there are exceptions, but the structure definitely encourages such unethical management behaviors.
"Management" is generally a bunch of morons bikeshedding to try to distract everyone from the fact that their jobs are utterly worthless. The fewer decisions management makes, the better. If management feels like they need to make a decision, throw something in there they can tell you to remove later. It's a tried and tested method of getting those imbeciles off your back. Then build the damn thing that actually needs building. Management will take the credit, of course. But they'll be happy. Everyone wins.
Think about it this way: the person who suffers the consequences of the decision should be making the decision. That's not management; they will never, ever accept any level of blame for anything. They'll immediately pass that buck right on to you. So that makes it your decision. Fuck management; build what needs building instead.
Look at what happened when "management" started making decisions at Boeing about risk, instead of engineers making the decisions.
Building the wrong thing is exactly what happens when you listen to management too much. Talk to the client yourself. Learn the subject. Get the textbook. Read the materials. That's how you build the right thing.
> They are required because building the wrong thing is worse than not building anything at all
And yet, "manager" is usually[1] only responsible for ensuring the boards get carried from the truck to the construction site and that two workers don't shoot at each other with nail guns, not "we, collectively, are building the right house."
I freely admit that my cynicism is based on working in startups, where who knows what the right thing actually is, but my life experience is that managers for sure do not: they're just having meetings to ensure the workers are executing on the plan that the manager heard in their meeting
1: I am also 1000000% open to the fact that I fall into the camp of not having seen this mythical "competent manager" you started with
Even if you don’t care about chemicals, plastic does in my experience absorb a lot of “burnt/old” coffee flavor, especially if it goes through rubber/plastic/silicone tubing.
I can recommend porcelain pour over and paper filters. I fill up around 1L in the morning with hot water from the boiler. It’s very boring and non-fancy, takes about as much time as a coffee maker (pouring is slower but cleaning is faster). Use a thermos if you want it hot for longer. Great flavor for non-snobs.
