> then you read the room and go with the layer of abstraction needed.
Finding the right layer of abstraction is orthogonal to the write-speak axis. When speaking to my colleagues, I use technical jargon that no layman could understand. None of the topics are simple, or strongly abstracted. The issue of write vs. speak is more about the sentence structure, sentence length, and breadth of vocabulary.
But I generally agree that carefully crafted written language can capture and transport thoughts much, MUCH more effectively.
Slightly off topic: What's with HN and the word "orthogonal"?
I'm not a native English speaker, but I read a lot in English and it seems like the word is extremely common on HN compared to anywhere else.
Isn't usually "unrelated" a more descriptive and even a more precise word in most HN discussions? (The parent comment here does seem to make a point using axes, so maybe it is more appropriate here?)
Orthogonal does not mean unrelated. Take two vectors in the plane. Them being orthogonal means that they have a 90 degree angle between them, so if you know the direction of one of them, the direction of the other one is severely restricted to two choices. So these vectors are very much RELATED. It's just that they are related in a way that makes them maximally different in a certain sense.
So if you want to say that two things are maximally different in a certain sense, you use orthogonal. If you want to say that one thing has no influence whatsoever on what the other thing is, and the other way around, you use unrelated.
For example, if you randomly choose a point in the plane, then its x and y coordinates will be unrelated, but not orthogonal. The vectors [x 0] and [0 y] are not unrelated, but certainly orthogonal.
I understand that orthogonal and unrelated have different meanings. What I'm wondering is: Isn't "orthogonal" much more common on HN (18388 matches in search) than in other places?
I suspect that "orthogonal" is a word programmers fall in love with during some CS class and then overuse because it sounds sciency.
I think that orthogonal is a more visual word than unrelated. It invokes the image of axes pointing into different directions. I suspect many programmers just like this aspect of the word, while unrelated is somewhat bland, and also usually wrong.
Unrelated means two things are not related in any sense. Orthogonal means two things are unrelated with respect to a specific property.
Unrelated is more general, and less precise. Orthogonal restricts the "unrelatedness" to the specific property being discussed. It's also a very visual and intuitive word.
She's doing everything in her power to become famous/viral.
Look at the amount of work she puts into SEO and her own Wikipedia page. She's a Wikipedia editor that edits her own page. Can't get more self-absorbed than that.
Without interruptions, I would not be able to finish meetings on time. EVER.
Information exchange is always the bottleneck in larger organizations, so efficiency of meetings is really important.
I will interrupt someone if I understood their point, and we have different, more pressing items on the agenda. It's not a power play, not psychological warfare or bullying. I just want to get shit done on time.
Companies with a waiting culture get things done on time. You might perceive interrupting as being more efficient but interrupting has its own set of inefficiencies.
Ok, next time an engineer on my team can't stop himself from talking about his SIMD lock-free distributed queue, I'll just keep listening. Maybe I get to sleep in the office too.
Both modes are subject to failures. Waiting is subject to live locks and interrupting is subject to thrashing. The socially maladroit or power tripper will misuse or abuse either system.
Yes, of course there is no silver bullet. The point is that the parent comment thinks only an interupting culture can work which anyone who has worked in a functional waiting culture knows is false.
There are pros and cons to both approaches. My personal experience has been that waiting cultures are more efficient at communication and get more work done. It would be interesting to see what actual instead of anecdotal data would show.
Could you tell me more about your experiences with effective waiting culture?
I'm having a hard time believing that a e.g. a high-level manager/exec with 20 meetings per day, and a 60 hour work week is able to be on time with a purely waiting approach.
There are so many people that you need to align with this culture. If it worked for you, wherever you are, I respect that a lot.
The detail it deserves doesn't fit in an HN comment. But I'll drop some observations here. You really need to experience it to get it though. Body language and so many other nuances all come into play in any communication style.
I'll suggest that it's the interruption culture itself that is motivating the tendency for monologues.
When an executive regularly says "John please let Mary finish, I wanted to hear the rest of her thoughts" it sends at least two signals:
1. The obvious that interrupting is not welcome here.
2. The less obvious but easy enough to figure out that listening is valued. The vast majority of folks are smart enough to figure out that a monologue is just as unwelcome as interruptions in a culture where listening is valued.
At the the end of the day what everyone wants is a dialog. In a non-interupting culture folks tend to pass the baton far quicker which takes the place that interruptions used to serve. Once people understand that they will get uninterrupted time to speak, they relax and aren't so desperate to get everything out all at once before someone interrupts and shuts them down.
Imagine a manager who tells you that she can give you 30m max, no interruptions. That's a lot of trust and responsibility they've put on you. You pretty quickly figure out how to make effective use of that time, and it's for sure not a monologue.
And it's also manageable over a series of meetings. It's easy enough for a manager to start a meeting with "Kevin, please hold off your thoughts until the end of the meeting because we heard mostly from you last meeting".
People catch on very quickly if it's coming from the top. Which it almost always has to.
If only my fraternity brothers understood this during our meetings. So many hours wasted on off-topic ranting or the entire chapter discussing issues that should’ve been settled in committee (or one malcontent stalling the committee’s report)
I think this was well prioritized; they struggled with the issue at times, found a temporary workaround, but when that workaround stöd being efficient and the bug hit them everyday, they decided to track down the source. Then they reported upstream, it was reproduced, and someone patched it, and rolled out new, fixed kernels.
That is a perfect example of how things works and should work. They contributed to the community. I think it was a great prioritization.
I'm certain there were lots of other people hitting this bug and killing processes or rebooting to get around it. The troubleshooting and reporting done here, silently saved a lot of of other people a lot of efforts - now and in the future. I don't think they were after it to be heroes; they just shared their story, which I'm sure will encourage others to maybe do the same one day.
[Author here] Your comment resonates with me. Indeed, we had been working around the issue for a number of years before we decided to tackle it head-on and even then we set a deadline for debugging and had a fallback plan as well: if we didn't manage to figure something out in a couple of days, we would switch transports or ditch rsync altogether.
In the end I believe we struck a good balance between time spent and result achieved: we gathered enough information for someone more familiar with the code to identify and fix the root cause without the need for a reproducer. We could have spent more time trying to patch it ourselves (and to be honest I would probably have gone down that route 10 years ago), but it would be higher risk in terms of both, time invested and patch quality.
Finally, I'm always encouraging our teams to contribute upstream whenever possible, for three reasons:
a) minimizing the delta vs upstream pays off the moment you upgrade without having to rebase a bunch of local patches
b) doing a good write-up and getting feedback on a fix/patch/PR from people who are more familiar with the code will help you understand the problem at hand better (and usually makes you a better engineer)
c) everyone gets to benefit from it, the same way we benefit from patches submitted by others
This opinion is a popular one these days (particularly since it complements the demands of business nicely by maximizing personal/company profit), but it is a big part of the reason why the majority of software these days is so unreliable and buggy. It results in hacks on top of hacks to paper over problems in the lower levels of the abstraction tower that is modern software, and it results in tons of "WTF" bugs that are just accepted and never fixed.
It's popular because these war stories you find in blog posts are pure survivorship bias.
If I'd let every fucking team member go on an exploratory bug hunt whenever they feel like it (hint: that would be always) we would never get anything done.
What if they don't find anything? Is this issue really worth 2 weeks of dev time? That's 15k down the drain for a senior engineer, if not more.
From a short-term business perspective, sure, it doesn't make financial sense.
As a user of software, though, I want someone to fix the bug. I want software that doesn't have bugs. So let me repeat my original statement. We need more like this that are willing to spend engineer time fixing bugs, even upstream bugs in open source projects. Instead of prioritizing shoving half-baked features out the door for next week's press release.
[Author here] Even from a short-term business perspective, it actually might make sense to fix things and contribute upstream. When you face a problem with something you built using FOSS, essentially you have three choices:
- Work around it, most likely creating technical debt inside your organization in the process
- Invest the time to fix it yourself
- Pay someone else to fix it for you (e.g. the original authors via a support contract)
None of these options is for free, and which one is the most cost-effective depends largely on the complexity of the issue at hand, the skillset and availability of the people involved and the criticality of the impacted system.
In my experience, the “oh it fails randomly sometimes” bugs are often in some random dull legacy infrastructure component where there is zero attention or celebration for fixing them, and so engineers tend to tolerate losing a bit of time once a week due to them for years rather than someone spending half a day to fix it for everyone.
GP’s comment is also odd because the article notes they took your approach. They documented the problem when they first noticed it happening infrequently and moved on to higher priorities. When it started happening every single day it became mission critical to investigate.
This _is_ the meaningful stuff. Engineers might have the urge, but most don’t have the opportunity, because they need to focus on the currently fashionable framework.
A good rule of thumb regarding meaningful battles is to ignore everything promoted by companies like Google or Facebook - everything they do is either going to be abandoned in five years, or makes sense only in the context of solving problems nobody else have.
seems like something an engineer might fix on their own time if they were feeling feisty about the matter. Something tells me if it went on for 20 years it was an edge case that only very rarely came up and was mostly a non-issue.
I suspect it was definitely an issue, it’s just that most companies like Google don’t care about reliability, only availability, and it might just not show up in their stats.
I think it reveals a deep naïveté about the author that they can simply boil things down to “Marxism bad”. However, they do seem to be learning that there is value in not being a STEMLord.
Proper STEMlord doctrine holds that Marxism is not even wrong. Also, obviously, the views/ideas of Marx turned out to be correct (well supported by empiricism) are just part of economics and sociology.
> then you read the room and go with the layer of abstraction needed.
Finding the right layer of abstraction is orthogonal to the write-speak axis. When speaking to my colleagues, I use technical jargon that no layman could understand. None of the topics are simple, or strongly abstracted. The issue of write vs. speak is more about the sentence structure, sentence length, and breadth of vocabulary.
But I generally agree that carefully crafted written language can capture and transport thoughts much, MUCH more effectively.