EtCepeyd

>> 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

I tend to disagree.

- 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.

> and perhaps for good reasons

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.

This resonates a lot with me.

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.

> finally they are telling me they are doing a task so I know we are going in the right direction

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.

Yes, but NATO members are not bound by contracts that classify them into superiors and subordinates. Whereas at work, you'll have some form of contract in which you agree to taking -- and usually: soliciting -- direction from your superior or client. Silence procedure works between equals, where each party is required, from the get-go, to (a) announce their intent to the shared message bus, (b) diligently listen to the shared message bus, and take action whenever necessary. The communication pattern between manager and report is totally different; the parties are not equals there.

> but they can just as easily say "hold up, don't do that until I get a chance to look at it"

This still requires them to take notice of your query, within the deadline of your choice; and that may not be a given.

The advice refers to situations where you, the report, are both able and (well-informedly) willing to take full responsibility. "Ability" here means that, if your decision backfires, you can revert it, and/or contain the damage otherwise. Otherwise, you may be willing to take responsibility, but are unable to. In other words, this piece of advice applies to things that are ultimately under your control.

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.

> Management (in my opinion at least) is primarily for resource allocation, career growth, and shielding the team from endless meetings and acting as a point of contact for upper management

Agreed! (And we can also call "resource allocation" "setting priorities".)

Nice; instead of burdening your boss with a decision, now you're burdening them with a ultimatum, with a deadline. I guess, as a manager, I wouldn't love anything more than a report saddling me with an arbitrary deadline, one I'd have to schedule along with the rest.

One of my managers used to tell me this, instead: ask for forgiveness, not permission. That one seems way saner to me.

> smart humans learned how to hide behind systems to avoid accountability

And "systems" is more general in this sense than just technology. Consider stoning, and firing squads. Both were invented to remove individual responsibility.