>> When people find out I got a 30% improvement by doing 8+6+4+4+3+2+1.5+1.5
> What is this referring to?
30 = 8+6+4+4+3+2+1.5+1.5
78 karma · joined January 11, 2025
> What is this referring to?
30 = 8+6+4+4+3+2+1.5+1.5
- By "explicit mesh of peers", I referred to atomics, and the modern (C11 and later) memory model. The memory model, for example as written up in the C11 and later standards, is impenetrable. While the atomics interfaces do resemble a messaging passing system between threads, and therefore seem to match the underlying hardware closely, they are discomforting because their foundation, the memory model, is in fact laid out in the PhD dissertation of Mark John Batty, "The C11 and C++11 Concurrency Model" -- 400+ pages! <https://www.cl.cam.ac.uk/~pes20/papers/topic.c11.group_abstr...>
- By "leaky abstraction", I mean the stronger posix threads / standard C threads interfaces. They are more intuitive and safer, but are more distant from the hardware, so people sometimes frown at them for being expensive.
The latter course (a) was built on a mathematical formalism that had been developed at the university proper and not used anywhere else, (b) used PVM: <https://www.netlib.org/pvm3/>, <https://en.wikipedia.org/wiki/Parallel_Virtual_Machine>, for labs.
Since then, I've repeatedly felt that I've seriously benefited from my formal languages courses, while the same couldn't be said about my parallel programming studies. PVM is dead technology (I think it must have counted as "nearly dead" right when we were using it). And the only aspect I recall about the formal parallel stuff is that it resembles nothing that I've read or seen about distributed and/or concurrent programming ever since.
A funny old memory regarding PVM. (This was a time when we used landlines with 56 kbit/s modems and pppd to dial in to university servers.) I bought a cheap second computer just so I could actually "distribute" PVM over a "cluster". For connecting both machines, I used linux's PLIP implementation. I didn't have money for two ethernet cards. IIRC, PLIP allowed for 40 kbyte/s transfers! <https://en.wikipedia.org/wiki/Parallel_Line_Internet_Protoco...>
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
- You work on postgres: you have to deal with the transaction engine's internals.
- You work in enterprise application intergration (EAI): you have ten legacy systems that inevitably don't all interoperate with any one specific transaction manager product. Thus, you have to build adapters, message routing and propagation, gateways, at-least-once-but-idempotent delivery, and similar stuff, yourself. SQL business logic will be part of it, but it will not solve the hard problems, and you still have to dig through multiple log files on multiple servers, hoping that you can rely on unique request IDs end-to-end (and that the timestamps across those multiple servers won't be overly contradictory).
In other words: same challenges at either end of the spectrum.
For the very good reason that the underlying math is insanely complicated and tiresome for mere practitioners (which, although I have a background in math, I openly aim to be).
For example, even if you assume sequential consistency (which is an expensive assumption) in a C or C++ language multi-threaded program, reasoning about the program isn't easy. And once you consider barriers, atomics, load-acqire/store-release explicitly, the "SMP" (shared memory) proposition falls apart, and you can't avoid programming for a message passing system, with independent actors -- be those separate networked servers, or separate CPUs on a board. I claim that struggling with async messaging between independent peers as a baseline is not why most people get interested in programming.
Our systems (= normal motherboards on one and, and networked peer to peer systems on the other end) have become so concurrent that doing nearly anything efficiently nowadays requires us to think about messaging between peers, and that's very-very foreign to our traditional, sequential, imperative programming languages. (It's also foreign to how most of us think.)
Thus, I certainly don't want a simple (but leaky) software / programming abstraction that hides the underlying hardware complexity; instead, I want the hardware to be simple (as little internally-distributed as possible), so that the simplicity of the (sequential, imperative) programming language then reflect and match the hardware well. I think this can only be found in embedded nowadays (if at all), which is why I think many are drawn to embedded recently.
Distributed systems require insanely hard math at the bottom (paxos, raft, gossip, vector clocks, ...) It's not how the human brain works natively -- we can learn abstract thinking, but it's very hard. Embedded systems sometimes require the parallelization of some hot spots, but those are more like the exception AIUI, and you have a lot more control over things; everything is more local and sequential. Even data race free multi-threaded programming in modern C and C++ is incredibly annoying; I dislike dealing with both an explicit mesh of peers, and with a leaky abstraction that lies that threads are "symmetric" (as in SMP) while in reality there's a complicated messaging network underneath. Embedded is simpler, and it seems to require less that practitioners become advanced mathematicians for day to day work.
Yes, but. :)
Assume a high-profile open source project where your direct report is a maintainer. The higher-profile the project is, the more political it becomes, of course. Your report will not need your (= the manager's) input on technical decisions; instead, they will inform you (in the optimal case) of where things have been heading. However, if that maintainer also participates in community governance -- which is quite likely --, they won't be able to avoid decisions that are more political than technical in nature. And whatever they decide there may easily reflect on their employer or client, one way or another. That kind of stuff is something that they should consult you on, regardless of their technical seniority.
This still requires them to take notice of your query, within the deadline of your choice; and that may not be a given.
The background is that, even when something is (mostly) in your control, you may be tempted to ask for permission, in advance, just to distribute the responsibility to others (shift the blame, cover your ass). That delays things, and usually the manager will sense that they got burdened with the request-for-permission somewhat needlessly. In those cases, it's better to take initiative, and be accountable later on, because the latter is in your power, in the end.
(Of course, if you and your manager have dedicated time slots anyway, then bringing the topic up is prudent, as it will not require them to scramble for otherwise unallocated time.)
Conversely, if containing the potential damage is indeed not in your power, then you shouldn't go ahead without explicit permission. For things where you simply can't bear responsibility, a timeout from the approver is not a default "yes", but a default "no". If you can't bear responsibility, then you need explicit signoff from someone higher up that, should shit hit the fan, they will bear responsibility on your behalf -- and so a timeout is meaningless (it doesn't give you what you responsibly need).
Whenever you can afford to interpret a timeout whichever way you want, then you don't need to ask the question in the first place (--> don't ask for permission, just revert/contain the damage, if needed). Otherwise (--> the potential damage is beyond you), you need an explicit "yes" (which is the only case when you're off the hook).
The problem with your suggestion is that it assumes that you, as a report, are in a position to set deadlines for your superior(s); in other words, to allocate their time and priorities. Usually the exact opposite is true (by contract): it's your manager who sets your priorities. You can consider their (repeated?) failure to respond timely a true failure, but that doesn't give you the right to do whatever you want; it would be in bad faith / a form of vigilantism. Your option is to leave that manager.
Agreed! (And we can also call "resource allocation" "setting priorities".)
One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.
And "systems" is more general in this sense than just technology. Consider stoning, and firing squads. Both were invented to remove individual responsibility.
https://cacm.acm.org/opinion/i-was-wrong-about-the-ethics-cr...
Calling this a "falsehood" is utter bullshit.
> This, this, this, and this!!!
Except that time is a huge cost. Merely taking the photos is quick, but sorting through them is slow and mind-bogglingly boring. The more photos you take, the larger the chaos is (and the more space gets wasted). If you are the kind of person who diligently categorizes photos right after they are taken, then sure, go ahead spamming the trigger; otherwise you'll just end up with with exhausted storage, and less and less motivation (over time) to start sorting through that ever growing heap of manure.
Well said.
I'm reluctant to trust composability in these languages because of abstractions that were supposed to be composable, but turned out as non-composable. Separation of concerns, single responsibility etc are all good ideas, but code that is less explicit seems to make those things harder to verify. (I feel completely differently about composability in genuinely functional, managed programming languages.) In a way, C's qualms should have been mitigated by C++ already; but in fact, C++ has only replaced a small set of problems with a huge one.
> With "goto" I need to reconstruct what the arbitrary control flow means
I agree with your point in general (reading code means reconstructing the whole from the parts, which is more difficult than writing code, i.e., deconstructing the whole into parts) -- but not in this specific case. A proper cascade of gotos is very recognizable. And a broken cascade is fairly recognizable too.
> You don't need to know the order
My experience with C++ destructors (which I didn't write) suggests otherwise. "Trust, but verify"; and for that, explicit code is better. IMO.
> the desugarer should always be a click away
Source code should be readable without external tools, IMO.
You've worked at Microsoft and Google, and still say this? /smh
I've worked at a much smaller multi-national, and during their growth from ~6000 to ~23000, the internal spin-doctoring skyrocketed. Lying internally had become so important that they created new leadership positions for it.
> I think it's very human to extrapolate individual malaise to society as a whole [...] most people don't perceive society the same way a deeply depressed or burnt out person does
You're just confirming what the article says: "Those who haven't burned out / been broken have no way to understand the experience".
Meaninglessness at work is rampant. (Have you seen r/antiwork? or read David Graeber's Bullshit Jobs?) And society is wholly engineered to keep us busy, and to keep fleecing us, sheep.
The kind of job where you find enough meaning such that you deem society tolerable is the exception, not the norm.
haha, great metaphor! I'll steal it! :)
> for me, the low-trust "do the bare minimum to stay employed" approach didn't actually help me get out of burnout into fulfillment -- What helped was finding a work situation where I could give my all and not feel taken advantage of
What you just described (so vividly) is meaning, and (likely) "flow" too. Meaning must be there for everyone, in their efforts; the need for meaning is universal. (We can call it intrinsic motivation too.)
Some say that you can find meaning outside of work, and then can mostly ignore work; and it's also said (correctly I guess) that "psychological richness" (closely related to resilience) is important: drawing meaning & satisfaction from multiple sources.
Sure, but I have a practical problem with that: if you need to work 8 hrs/day to cover your family's needs, you don't have time, energy, or opportunity left to find meaning elsewhere.
And, as others have repeatedly said it here, if you are a full time employee making quite beyond your (family's) needs, and think about decreasing your working time (giving up excess money, but regaining much needed time & freedom), that is what is strictly forbidden by the runners of the Village of Happy People. You will find effectively no jobs that let you work (say) 5 hours per day, for 62.5% of your original salary. That way, you'd just not be a good slave, a good cog in the machine. Society is engineered such that you must not have free time.
Therefore the only practical option is to find (or create) work that provides meaning for you intrinsically. I see no other option. You can be an employee or run your own business, the same applies. And, unfortunately, this is unattainable for most of society.