NPM and other Node.js package managers happily deduplicate dependencies are compatible within the specified version constraints. So if 3 different modules in your build specifies `foo^2` and two other modules specify `foo^3`, in general you will have two copies of `foo` loaded.
But like OP pointed out, "reputed" could also mean
> generally believed to exist or be something specified, but not definitely the case. "a reputed budget of $165 million"
For now I've replaced it with the less ambiguous word ("reputable") to remove any confusion and will pick a better way to phrase this the next time we iterate on the landing page.
> To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab.
Java had some magic classloader ideas back in the day. OSGi, I think it was? I don't remember them using the term shading, but I also don't remember ever liking how that went. Usually very confusing for all involved. (Unless you were on the happy path, I think.)
> Hours worked is the #1 driver of any worker’s output: use your right to monitor.
I don't think hours behind a screen have ever had much of a correlation with productivity for me. Autonomy, stress, being tasked with solutions that actually make long-term sense, etc. must have a much stronger correlation. The enormous erosion of trust that having my hours monitored would have would certainly impact my output.
Yes, it’s terrible advice if applied to engineering teams at least.
The number of hours that an individual spent staring at the IDE or punching commands into the CLI have no meaningful correlation with the organization’s long-term goals.
A manager who spends their time monitoring engineers’ screens is like a web developer who writes a CRUD back-end in x86 assembly. It’s the wrong level of abstraction for performing the job.
People join forces in a Business, rather than working alone for ex, because they believe the collective sum of resources = inputs will produce greater collective sum of outputs. Responsible businesses are those who maximise the outputs. Otherwise, it is a waste of resources that are extracted from collectivity ($, labor, natural resources, infrastructure, etc).
Inversely, that is also why the standard business forms are not best suited for artists to thrive.
So, as business is about maximizing output: no matter how much is your productivity, which is a ratio, if you apply it to one more hour of work, then you will produce more output. So there are 2 ways to go here for high-productivity workers:
a) you are paid equal for same output, and allowed to work less.
b) you work as much as others, then produce more, then are paid more.
There is plenty of science that proves that choosing option a) is a shot in own's foot on the long run.
Note: 80% of harvard professors thing their students would rate them in the Upper half best professors. which is of course statistically impossible. Same for how anybody = we, self evaluate ourselves in anything: how good a driver, a parent, ... a worker we are.
How much hours one puts in is a fundamental parameter of how much one produces. Stays true even with diminishing returns, as long as productivity is >0.
There is this say, pardon my french: an idiot who walks will still gets further than a sitting genius.
This is the weirdest sentiment out of the entire article. "Only hire A-players" and "monitor them". I know exactly 0 A-hire engineers who would tolerate being monitored. Why wouldn't they leave to go to one of the many companies that would love to have them and where they won't have someone breathing down their neck?
Perhaps it's a take on how bad the job market is right now, but I still disagree. There are far fewer job prospects out there but way more than 0.
It also changes the focus: “what is good for the company” -> “what makes me look good and not get fired”. Following Elons antics I bet twitter LOC count is growing very fast!
The problem is that you can only later tell what made sense long-term, who was able to handle autonomy etc.
I work for a company (as a contractor) that doesn't monitor hours worked for their employees and the team is incredibly unproductive. It feels like some have a second job while others are playing games. I'm sure you could get rid of 75% if the remaining people worked full-time for their full-time salaries.
You'd think so but if people are playing video games or not working, adding monitoring won't increase your productivity, people will just do pointless busywork instead.
Cutting down the number of people will make everyone else more productive because they need to pick up the slack, but that doesn't mean the output will be higher quality, it will very likely be worse quality since you've taken a bunch of relaxed people and made them highly stressed.
To me it sounds like a failure of management and/or processes. The people are not motivated and their tasks are not being defined appropriately.
If someone is doing pointless busywork, they might as well do real work, they're often similarly annoying.
People in bureaucracies aren't famously slow because their tasks aren't well defined, they're slow because it's tolerated. When you stop tolerating it, they either improve their attitude or get filtered out. I've found that to apply to all organizations past some head count. People settle in and do less and less. That's not a problem while the money is flowing in like water during a flood, but it becomes a problem when that changes.
I don't know how it is where you work (I guess working as a contractor skews things) but where I work this is how things go:
- some tasks are estimated
- a resource bound is set per sprint/per person
- tasks are picked for a sprint such that the resource bounds aren't exceeded.
- people work on those tasks until the next sprint.
Now, software engineering is notoriously hard to estimate. Hard to predict you can't work for 2 days because someone updated a package that totally follows semver except not really and it takes 3 days of debugging.
So tasks get estimated with a lot of slack because hitting the sprint targets is more important than doing more work. That's a process problem.
Even then what mostly happens is that some tasks end up wildly overestimated while others wildly underestimated, to the point they end up shifted to the next sprint (at which point one must question the whole exercise).
This all assumes the requirements for the tasks were in any way clear, often they aren't.
Either way, the outcome is that some weeks there simply isn't enough work assigned, while others there's too much. Sometimes there's an issue that's on someone to fix and everyone else is waiting for that before they can do their work.
What should they be doing with their time? Improve the tests? The docs? I guess, but unmotivated people doing boring work always ends up with a shitty output regardless of how many hours they dedicate to it.
Much better to trust people to get the job done, given them a reason why they do what they do, and set processes that let them work at a consistent pace. That's what Agile was originally all about.
(I know you’re a contractor so you don’t get to choose but:) stop working in artificial sprints. In some cases they’re useful(external client stuff) but mostly they can be replaced with just working down a continuous backlog. Then you don’t have this weird artificial feast and famine game.
I think from your last sentence you agree.
It's a shortcut because measuring output is too hard for any sufficiently complex work.
It's easy when you have a well-defined task that you know the average complexity for, e.g. first level support ticket responses. It's very different for e.g. the developer who looks into a ticket to find out why. Might be just 60 seconds because technical understanding + experience give you the ability to see what customer + support agents have missed. Might be 6 hours for a complicated bug and fix, might turn into a huge deal that takes days.
How do you handle that and accurately predict how much time that should take?
Basically you have just given reasoning for why there is a job description „engineering manager“.
I am actually all for monitored work hours and I clock in an clock out of my unionized 35h work contract. But frankly i expect from a sw eng Organisation more insight into their own development processes
It looks to me like those clients were removed due to trademark infringement (having "Signal" in their name), I don't think they were taken down because their code connects to OWS' servers (would GitHub or Google ever honour a takedown request like that?).
Sending messages to authors of third party clients that you are not ok with their use of your servers (literally the exact comment the link I and other posters shared):
> I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.
> If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.
Yes, they mention both trademarks _and_ servers, and yes, if there was not a trademark issue, github and google would not remove the repo just for connecting to Signal's servers against Moxie's wishes.
However, the act of informing third party client developers that they are not allowed use the official servers is itself an act of enforcement - maybe one with not much teeth behind it unless he follows up with a legal complaint, but still nonetheless enforcement.
I see what you mean, I guess the mix-up here is that we have different working definitions of "enforcement".
For example, I would argue that Moxie's desire for unofficial clients to not use the word "Signal" in their project name is a statement of policy, whereas the takedown requests to remove the projects from GitHub and the Play Store are examples of enforcement of that policy.
That said I think I can be convinced that directly informing a violator of your policy of said policy is a type of enforcement in itself.
