mlthoughts2018

There’s no such thing as “uninvited criticism” in FOSS (or open mic night). Merely by exposing your project to be acquirable by end users, you have invited criticism. And if you go further and promote the project, give talks about it, recommend it, seek sponsorship, seek contributors, then you’ve invited criticism even more so.

Of course you can ignore that criticism - that was never in doubt. But users are fully justified to make the criticism and it would be rude and wildly unreasonable to reply by saying, “if you don’t like it, leave.”

> “ If you think the maintainer isn't doing a good job working on the right issues or maintaining the project, that's not the maintainer's problem. That's your problem.”

This is backwards. The maintainer is expecting attention and users. By alerting the maintainer to issues, I would be helping them (using my own extra effort, eg bug reports, feature requests).

The nuclear option for a user is to just throw their hands up, not even try to lobby the maintainer to make better choices, and quit using the project. The nuclear option for a maintainer is to completely ignore the user base whose attention they need and whose efforts on bug reports or whose frustrations give them free labor to understand their projects fault points and fix them, and instead say, “you’re not paying me with money, only with attention, time and effort, so I owe you nothing” (as if owing was any part of any of it) and ignore their feedback.

Either side can go for the nuclear option. But wouldn’t we hope the social contract in FOSS has a higher standard and people try to both give and receive reasonable feedback, and people try, at least, to consider users’ needs after users have invested attention, word of mouth review, effort on bug reports, etc. before “going nuclear” and gainsaying everything with “you don’t pay me in the form of currency so I owe you nothing.”

Your analogy is extremely specious. A better analogy is an unheard of band playing an open mic night. The audience is doing the band a favor, by giving attention, possibly giving word of mouth reviews, not the other way around. The audience has every right to give feedback and help the band understand they don’t sound good. The band can ignore that feedback if they want, but they sure have no justification to look down on the audience for saying it, or saying, “play your own music if you don’t like it.”

Giving my attention to your FOSS project is compensation. In fact, FOSS is so over-saturated with options that giving my attention is high compensation. Project maintainers are lucky to have an audience of users and should value their feedback and create solutions for them, if they want the attention to continue or they want compensation to increase.

What doesn’t make sense is to treat users like they don’t matter, ignore critical bug fixes or feature requests to prioritize dabbling or recreational features, and disingenuously turn around and claim users are rude or should be shadow banned for stating justified frustration over this, all under the false pretense that just because the compensation is in the form of attention and engagement (similar to currying “likes” or “votes” on social media), and not currency, this somehow means there is zero social contract between maintainers and users.

If users are kind enough to express frustration in bug reports or feature requests, it means they are making an extra effort to hopefully not have to leave your project and stop using it. It’s an attempt at a constructive solution by letting the maintainer know there’s a social obligation problem happening. That seems way, way more positive and reasonable than a disgruntled maintainer immediately shrugging it off and going straight for the nuclear option of, “well if you don’t like it, leave.”

In my experience this is usually a recipe for unhappiness, similar to choosing a college major by “following your passion.”

If you want to enjoy working on FOSS, choose to solve a problem that lots of users need solved, the more mundane the better, then make your whole backlog focused on what the user tells you.

FOSS needs product / market (of attention) fit like anything else. Unless you are your own user for a real use case, you need other real users to be the sole driver.

Or, politely object, raise issues & frustrations and lobby the maintainers to make different choices.

Sure, but that doesn’t mean I have to view it as an acceptable choice if a maintainer leverages a large user base for notoriety and then fails to prioritize that user base’s needs. They can do that, and I can express frustration that it’s an unacceptably poor failure if they do, in more ways than just declining to use their software.

On the flip side though, lots of FOSS project maintainers want a large user base for fame and glory but also want to omit support for that large user base to instead pursue whatever interests the maintainers, as opposed to what is evidently needed, all under the disingenuous guise that not being directly compensated entitles any arbitrary planning policy.

While users have no justification for being rude or insulting, they absolutely do have justification to be frustrated if you want to have your cake (compensation in the form of notoriety due in large part to the willingness of others to actually use your FOSS project) and eat it too (not prioritize plans, bug fixes, or features in accordance with what that user base needs & requests, over and above what you prefer).

I’m not saying this applies to you specifically, but it does apply to many FOSS projects, and arguments of infinite entitlement to strand users who bring your project notoriety because the compensation isn’t in currency format are totally specious and deserve to be met with (polite) frustrated pushback.

Greenwald is unrecognizable from the Snowden era. It’s like a dementia victim morphing into a completely different person. Very sad to see him like this. The Hunter Biden article fiasco is embarrassing for him, and this makes it appear he is just doubling down in tabloid garbage right-leaning-for-attention nonsense.

Yeesh, Greenwald has become a full on shill for the hard right just because he is so sore against Democrats after the 2016 DNC leaks.

This is like watching someone with dementia slowly morph into a completely different person.

No aspect of what made early journalist Greenwald a champion for democracy is recognizable in this whatsoever.

It’s full on Republicanized befuddlement.

I think you are wrong. For a company like Apple, prioritization might work that way. But for many other companies you really do have to put effort into two mediocre solutions, for all kinds of reasons.

It’s not visionary or smart to apply a priority scheme cargo culted from a massive outlier (Apple) and claim it’s appropriate in all kinds of other situations. Especially without evidence.

It’s just a glib platitude for someone to sound smart.

I find the compiler an annoyance in Haskell just as much as C++ - it just forces me to write more code (more liability) and leads to overly rigid type system designs, like modeling behavior with classes or traits/type classes. I’ve only found these ways of writing software to be universally worse than simple module-oriented programming, writing C-like code in languages like Python or Ruby and only selectively using C extensions for isolated cases where speed provably matters.

Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).

Just a reminder to all the product managers and budding executives who will read this: you are not Apple.

You don’t have a world class consumer computer business, mobile device business, entertainment products business, app store business, etc. etc. to fall back on when you decide to do the bare minimum.

The difference between average & bare minimum for you is the difference between going bust vs. holding steady, or the difference between mass layoffs vs. hiring freeze, or the difference between giving raises and not.

Don’t go off thinking you are a maverick tastemaking Steve Jobs who can toss out “do the bare minimum” as some savant-like wisdom.

I guess we need data to back this up - I’m not buying it without more data. Even the top, top valued sports franchises only have estimated market caps in the range of $5 billion.

In other words, for small cap companies, yes, the ROI of athletes to their franchises is relatively higher than engineers to their companies. But for most of the SP500 this is not true, and there are lots of software-heavy companies with much higher market cap to the extent that even with 10k or 100k employees, I doubt an athlete’s ROI for a small sports franchise is proportional to the ROI of employees in the large company.

For example, virtually any engineer at a FAANG company should be making top pro athlete money (not considering endorsements). There are literally thousands of engineers at Amazon and hundreds at Netflix that have this ROI on the soaring revenues of these megacorps, to a much greater degree than athletes have on their teams.

Exactly, the users are not doing well because they’re expecting to be able to misuse Vue and demand special case features, while Vue itself is doing good by resisting this and sticking to the plan in terms of framework design.

I use Vue and haven’t found it hinders me from doing this myself. Are you suggesting Vue should not just release a framework but also solve every user’s special case? Your comment isn’t making sense to me.

I’m exclusively drawing the comparison with high demand actors / athletes. Perhaps athletes has the better clarity - many NBA players are paid more than their head coach, and even those paid less are still paid much more competitively to their revenue contribution than engineers by comparison.

Nowhere did I suggest executives shouldn’t be paid more than engineers.

If a user felt that way, it would make no sense for them to choose Vue. Vue’s up-front, stated design goal is omit special cases or edge features intentionally and directly assert that’s not a good way to design a framework.

Vue may be right or wrong, but nobody wishing for special case features can claim to be surprised. If you picked Vue knowing you need a bunch of special case features, that’s on you.

Pay is nowhere remotely close to being proportional to impact on revenue though. Many engineers are much more offended by unmeritocratic pay than by absolute value of pay being low - hence why you can convince amazing engineers to work for peanuts at start-ups.

I want the greatest share of the returns of my own labor I can get. If that results in very high salary, great, it’s earned. If I take a risk at a place where that translates to much lower salary, that’s fine too - as long as it’s very objectively meritocratic.

If I am making $200k per year as a top, top performer, while my employer is paying far more mediocre performers $175k (perhaps based of geolocation), or where both of us are bringing in ~ millions of revenue, that’s super unacceptable.

As time goes on, the surplus of my labor productivity that a big corporate employer can capture beyond my total compensation should be decreasing heavily - and expert software labor is one class that has the negotiation power to actually push that issue.

So I’d flip your question on its head. Why do we pretend that rent-seeking executives deserve the surplus revenue generated by rare talented engineers? Why (with complete sincerity) aren’t many, many, many more software engineers paid on the order of what Hollywood actors are making, while executive salaries simply have to come way, way down in these lines of business?

The first thing you have to realize is that the hiring apparatus in the company is bureaucratic. They aren’t scared, mad, judgmental, whatever. They are going to be thinking more about what’s for lunch and whether they can cut out early next Friday than about your candidate profile or negotiation.

As long as you are polite but firm, they aren’t likely to think anything. They’ll just figure they either like your profile and want to work with you, or they’ll figure they know they can’t meet your requests.

Always present flexibility even if you aren’t actually flexible. In theory, if they cannot give a severance package, maybe they can give a much higher sign on bonus, or something else you want. Let them know what’s important to you, but that if there are other ways to address what you’re looking for, you’re open to hear it and think about it.

Once you’re at the stage of making concrete requests, don’t be vague and don’t accept vague alternatives. Always ask for concrete alternatives and once it is stated, always take time to think about it offline, always. That way if you decide you’re not actually flexible, you have breathing room to process your decision and respond.

You should also project confidence about your worth and why you are asking for something.

For example, for negotiating a severance package, you should be very clear about it. In my case, that mattered to me because I was relocating to a new area and at the same time I was switching from individual contributor to manager. I felt the risk of the local job market for an inexperienced manager was high, so if the company I was joining would have restructuring or sudden cuts and I am laid off, the money to float myself in the new region would be high. To feel comfortable about this, I just wanted to know for sure if that kind of change was coming, I would have X months of salary as a cushion.

If a recruiter or hiring manager is too immature to appreciate this as a sincere concern / request of a candidate, and would punish me just for asking either by acting like severance is a taboo way to protect insecurities of being fired or acting like I’m a prima donna, well that makes the decision to walk away pretty obvious for me.

The main thing is just remember they don’t owe you any special features in a job offer and they absolutely won’t offer them unless you ask and make it clear it matters to you.

But you also don’t owe them anything either, certainly not any expectation about being “too fussy” or “scaring” them. Nobody’s going to look out for what you want as a candidate except you.

As long as you’re polite but firm, and you make clear asks and require clear commitments, you should feel completely confident asking for anything you want. Whether you’re willing to compromise or you need to say “no,” you’ll be doing yourself a big favor.

I think this is a good thing generally, Vue has consistently been one of the best engineered and most effectively designed pieces of software in the Javascript world, largely due to uncompromising enforcement of the design opinions and aesthetics it asserts.

As long as the maintainers are responsive to bug fixes and key feature requirements (since they aren’t accepting of outside contributors adding them), then this is fine, possibly even optimal in terms of quality.

The trouble comes in if they both don’t allow many outside contributions and at the same time they pull the same unjustified complaint of a lot of OSS and say because they aren’t paid for their time, they will prioritize what interests them rather than what resolves painpoints or missing features users need. You definitely can’t have it both ways.

When I have pushed back on the same topic, it usually is met with negativity. I believe recruiting and hiring staff have some incentives to treat you like you’re crazy if you want special provisions or need clarification on complex terms.

In my career, I’ve negotiated

- a severance package in my offer letter from a company that said, “we don’t offer severance packages as a matter of policy.”

- a sign on bonus from a company that said, “we don’t offer sign-on bonuses as a matter of policy.”

- a longer expiration period for startup options, as well as partial acceleration of vesting in the case of a significant liquidity event, from a company that said, “we can’t modify our standard equity agreement papers.”

- immediate full vesting of matched 401(k) contributions from a company that said, “our policy is that matched contributions only vest after 1 year.”

- ability to expense my own Linux workstation, which I could keep, in the offer letter, from a company that said employees are only allowed to be issued Mac laptops.

- explicit extra section in the offer letter stating that any IP created by me using only my personal equipment and personal time was my sole property and was explicitly not subject to any part of the employee handbook dealing with ownership of IP.

In all these cases, the conversation usually started out with me being gaslit about all this being impossible or my expectations being crazy. But after sticking to my requirements, eventually it normalized out into a sincere discussion.

I should add, all these examples came from very large companies except for the case of the options expiry and acceleration.

I also gave a hard “no” to many companies over the years that wouldn’t negotiate on topics like these, and I can say I don’t regret it one bit. There’s never been a case where I said no to a job offer over inflexibility on all these topics and then later regretted it.

> “ We value freedom of speech." (proceed to literally ban the president, wrong opinions and alternative apps like Parler)”

Saying this is not open-mindedness or support for free speech.

The president and Parler both have acted as direct, unequivocal instruments of fomenting and directing violence, especially with racist and fascist nature.

Banning them from any platforms is in no way connected to free speech whatsoever. President Trump’s Twitter account and Free Speech are two completely disconnected, unrelated concepts.

It requires fascism-sympathizing and racism-sympathizing to even suggest otherwise.

At this point, anything of the vein like, “Banning Trump from Twitter is unfair censorship” or “Banning Parler from app stores is unfair censorship” is just hate speech disguised as if it’s an attempt to uphold freedom.

Some of the best product strategy in my org has consistently come bottom up from junior and mid level engineers. Some of the most out of touch product strategy has come from principal / staff engineers and senior product managers.

All engineers, whether junior or senior, need lots of autonomy to propose and try plans. No engineers needs to be “taught to follow the plan” - that is career death.

Meanwhile, the risk of political motives and malicious intent or self-preservation is much higher among senior staff, especially as they become ex-technical.

Finally, many products need teams of specialists in various areas, and their team structures don’t resemble fungible full-stack wishful thinking. A good leader tries much harder to give them what they need instead of imposing the fiction they are fungible.

So, overall the leader of this post is

- overly reductionist

- failing to protect autonomy

- failing to protect specialization

- failing to deal with reality

- mentally representing “senior” vs “junior” as “creates orders” vs “follows orders” which puts political authority as a central cultural value.

These are all classic, well-known leadership mistakes.

I guarantee the company in this example is full of under-appreciated engineers treated like cogs.

Even the overall premise of the layoffs is suspect. Nowhere does the article even ask the question of why the critical project failed in the first place. Why was staffing preemptively overallocated?

If you fire these people, will you have to hire and retrain new people later when things change again? How costly would that be relative to retaining them now?

Why aren’t there senior leaders being fired? The failure of a project with such wide spread ramifications surely isn’t down to a bunch of little guys.

Here’s what happened:

Using the same overly reductionist, chain of command failed ideas described in this post, other leaders pursued a bad strategy and allocated resources poorly. Now, to avoid being punished and paying the consequences of their failed strategy, i.e. actually firing executives and senior leaders who caused this problem, they need to scapegoat it as an IT downsizing and they need some inexperienced twerp (this CTO) to spas out pretending like some critical calculus was applied to make the heartbreaking least-bad fewest cuts they could.

It’s disingenuous to the core. Absolutely this is shitty, low-accountability leadership.

> There are broadly 3 experience levels:

> Senior: creates the plan. > Mid-level: follows the plan. > Junior: needs to be taught to follow the plan.

This person is a horrible leader and failure if they think this way.

This tells you all you need to know about the rest of the article.

And indeed:

> “The ideal team would be one that has all disciplines covered at a senior level with multidisciplinary people working in just one team, and with enough overlap to avoid a bus factor of one. Additional people will bring additional capacity.”

It’s just the tired old foolish mirage of fungible full-stack teams where there’s no such thing as specialization of labor.

This article is basically a farce of bureaucratic management mediocrity.

It is not possible to downvote this comment and also be a good human being. Any downvoter of this should be sick with themselves over such shameful behavior.

The best I could hope is that it’s some sick-minded person downvoting just to troll. The idea that a right-minded HN viewer seriously down votes this is absolutely unconscionable and completely beyond the pale.

It’s literally the same as downvoting a comment that says “racist murder is wrong.” Literally!

I think back to the people doing mental gymnastics to defend that crazy convoy in Texas that tried to intimidate the Biden campaign bus off the highway.

Shameful. Just truly shameful. Sick and disgusting.

Is it surprising that when fascists and racists are muzzled, they lash out to try to maintain the power to hurt others? No, it’s not surprising, and the lack of surprise is not part of any of the newsworthy stories of the last several days.

I opposed static typing because I favor safety, not oppose it. Type system designs prevent solving those problems.

Most of my career has been focused on helping large companies use Python to achieve as-fast-as-C performance with extremely little code and extremely safety-focused non-OOP software architectures, including in high frequency trading (where I built a company’s entire core trading platform in Cython).

The idea that static typing leads to safety is false. Static typing adds more code, more code is more liability. The cost of that liability is not recouped with any offsetting benefits.

This sounds like a good thing for Coinbase IMO. An instinct to reach for low-level data structures and static typing to solve ambiguous or fast-changing business problems is usually a red flag for premature abstraction and sometimes also correlates with attitudes of superiority or looking down on other possible technology choices.

I don’t know if they treated you fairly or not, but the policy at least of appraising an instinctual reach for low level C++ as a negative sounds correct to me and should be a much more widely used heuristic in software hiring.