The argument seems to be: don't promote/support good ideas or projects because if they're good they'll likely succeed without you, and then the initiator will be slightly more confident.
The message is that process is there to extract value from people with average skills and motivation. When you find someone very skilled and self motivated doing the right thing, don't let process hamper their way.
I wish the article actually said that in plain words instead of trying to foist it into that peculiar "wolf" analogy (or whatever it's trying to do). I found the article kind of confusing. Thanks for spelling it out.
I thought the message is “you might really want to find and encourage and promote and support your best programming talent though overt action, but such overt action might in fact have the inverse unintended outcome, often best to ensure you know such people are in the team and ensure traditional management does not get in their way or piss them off with traditional corporate thinking, which has zero idea what great programming talent looks like or is motivated by.”
Same. New ideas are like starting a fire. Piling too much on top or blowing too hard will stop it. You (together, however distributed across roles) do have to assess if you can handle one more fire, if it comes on top, replaces an old one etc. Getting to this decision in your specific setup is the tough and important part.
10x people can be like one-shot LLMs, your request is for sure wildly underspecified and what you get is 90% determined by the "smoothing term" applied by not you. This is why the right amount and frequency of interation is needed.
But did OP actually suggest their job is to “ensure traditional management does not get in their way”? I’m almost certain their point was not to interfere even at that level, which is why they didn’t hype it up the chain and let it land on its own.
Part of not hyping it up the chain is also that a lot of these projects are experiments. They may work, they may not, and some pivots may be required along the way. As soon as something is hyped to leadership, now there are feature lists, timelines, and expectations. All room for creativity and experimentation are gone.
I’ve gotten in the habit of not telling anyone about side efforts I’m working on until they’re done, and even then, I usually only tell the people who it might be of use to. I’ve been burned too many times by people trying to “help” or placing a lot of extra expectations and pressure on something. I don’t know if something will work until it works.
This is how I took it, and what I lived through. Both the supportive boss that let me do my thing without getting in the way, and those who tried to manage everything and make me shut down.
Why does this not use chisel? I assume you at least drop the bin dir? Although the presence of ncurses is super weird
I don't understand why one would go halfway and leave packages which are unneeded for services. The only executable in a hardened container image should be your application.
Thanks! but these are builder images, not the final runtime. Chisel only really makes sense after the binary is built and you know what it needs at runtime. Before that you are pulling in whole packages, which is why things like ncurses might show up, similar to chainguard's image. For a builder, it is just SBOM noise and not something the app ever executes. Its hard to identify what you need before running the application, and you can always find a library you don't need.
The “only your app should be executable” idea works for fully static binaries, but once you use glibc or CGO you already have other executables.
Zed is snappy in the same way that notepad ++ is snappy: If you don't support 10% of language features you can avoid the hard work. Unfortunately this means that non trivial projects have false positive errors everywhere.
>So never being offered a job because it doesn't exist doesn't lose you anything.
Ah well look, if the job posting was just to collect resumes with zero intention to actually hire, you did lose some things:
- actual time spent applying to a job that was never open
- emotional damage on focus to try to get this job
- loss of free market value of your data (company profited from this data, when you could have profited from it)
- damages for acquisition of your personal data under a fraudulent basis (when otherwise, maybe you did not want your data shared)
None of the things you mention are things I've seen in my union covered jobs in the UK.
I've never heard of union rules here. Employees are not required to be part of the union in order to get their benefits, the unions just negotiate with employers on behalf of all employees. I've also never heard of credentials/gatekeeping for unions in the companies I've worked in.
For reference, I was working as a software developer at a University on a research project: I got the benefits of the higher education university (nationally negotiated pay scales, holiday benefits, etc) but was not a member.
Pay was lower, yes, but that wasn't mandatory; that was just the budget of a research project.
Which is phrased as "not my job" for some reason.