candu

To validate your gut feeling here, it is very strange for a manager to stop having 1:1s with their reports just because the team has a new lead.

As others have said, your best option is to do two things at once: look around, and voice your concerns. You clearly don't like the environment; even in this market, there are lots of other options; why not explore those options? Reach out to friends, ex-colleagues, whatever.

In the meantime, make it clear that you feel unsupported and unrecognised, and that these are dealbreakers for you if not fixed quickly and decisively. If your manager doesn't listen, set up a skip-level meeting. If your skip-level doesn't listen, well, that's an even better sign that you should be planning your exit. If either of them do listen, you have a strong chance of either a) getting a raise and renewed support or b) understanding the situation better (which, though it doesn't always solve the situation, can remove some stress / toxicity from it.)

If you feel you deserve the lead role, say that directly! Provide evidence to support your position - not just technical things you've built / shipped, but also (especially?) anything where you've helped organise work for others, or communicated changes outwards, or worked with Product / Design effectively, etc.

As a small counterpoint: if you feel that you've been doing an extraordinary amount of effort, and they just cut a bunch of people, it may be that the team does need an extra person! No one should be in the position of needing to put in extraordinary effort for 3 years. For the vast majority of people, that leads to burnout; this is especially true in the stressful environment of mass layoffs, where people are often asked to do extra work to cover for their coworkers who were fired.

For others replying here: looking through this user's comment history, pretty much all of their comments are equally snarky and troll-ish.

For the parent: this is very much not appreciated here on HN. Take it elsewhere.

First: writing has other tangible benefits! Journaling can get difficult thoughts / stressors out of your head and on paper, helping you process and move past them. Taking notes improves comprehension, and is also (often) of higher value in a professional context than most people realise.

Things I've heard writers / bloggers / etc. in my life say about writing:

- There is no magic bullet; you just have to practice, practice, practice and be willing to throw away large sections or even entire drafts. Most people, including famous authors, write large volumes of crap. - If you're explicitly looking for an audience, you have to test with that audience! Get feedback early and often, and use that feedback to improve what (and how) you write. (If you have any product / design / UX training, you'll notice how similar this advice is to best practices in those fields!)

(On the second point: using Notion, Google Docs, or any other tool that gives you an easily shared link and allows inline commenting is a great way to get useful feedback!)

More accurate comparison: you return a purchase to Walmart for a refund - which, unlike shoplifting, is entirely legal - and they then seize all your previous Walmart purchases and ban you from the premises.

After all, disputing a charge on your credit card isn't some shady underhanded process; it's a right you have under law [1]. The real issue here is that, under digital distribution models, you have no real ownership of things you've purchased; in some sense, you're just renting or licensing them.

Merchant wants to ban your account for issuing a chargeback? Fine, but they should be required to preserve your access to purchased digital goods, or to otherwise compensate you for those goods. Consumer protection laws need to catch up to reality, and fast.

[1] https://consumer.ftc.gov/articles/using-credit-cards-disputi...

To be fair: the reference to `node-gyp` gets at a general problem with most high-level languages. I've seen very similar issues in Python - once you start to deal with native bindings, your nice high-level language abstractions become leaky, and you can no longer guarantee that building on new hardware won't fail in mysterious ways. (This is, incidentally, one of the benefits of VMs / containers / anything designed to remove or mitigate the "new hardware" part of that risk.)

If you look deep enough, or do anything low-level enough, or need to work with high-performance native libraries enough, you will find these leaky abstractions in every high-level language. Maybe it's at the "I want to do awesome Cormack-style invsqrt() pointer punning hacks" level, maybe it's at the "eep I'm dealing with raw binary data over a network and now the order of bits matters" level, maybe it's at the "argh I'm using a package that has native architecture-specific implementations" level.

As someone who coaches a local amateur sports club: at our level, the main reason to learn proper biomechanics is to reduce risk of injury. (At a higher level, it's also useful for getting those small advantages in effective reaction speed and positioning.)

Changes in direction are a really, really, really common cause of knee, ankle, and foot injuries. There's a _lot_ of force on fragile joints when you turn, dodge, fake out, etc. at speed - and especially for occasional / amateur athletes, who often don't have a high base level of strength and mobility.

It looks silly, but I'd rather our players look silly than tear ACLs or rupture Achilles tendons. (Plus in Canada, those tears and ruptures also cost taxpayer money - a whole lot more of it than making a quick video!)

> But getting back to the thought experiment it may ultimately even be the case that widespread rehabilitation is impossible.

And yet Norway manages a recidivism rate of 20% [1], by starting from the premise that rehabilitation is the point of incarceration; I'd certainly call it "widespread" to rehabilitate 80% of prisoners!

Also, I disagree strongly that the logical extreme of "some people are incapable of exercising full agency" is "free will doesn't exist at all, because biochemical determinism". This is a textbook example of the slippery slope fallacy. The law already recognizes and accommodates the possibility of the former, both in cases of permanent disability and of temporary incapability. One of its main tools for doing so is consultation with experts in psychology, which also means that we can refine legal application here as our understanding of psychology improves.

Moreover, "all behaviours are driven entirely and completely by chemical and electrical processes..." does not imply that free will doesn't exist! After all, it's pretty well demonstrated (through transcranial stimulation studies, cognitive behavioural therapy, more recent psychedelic studies on MDMA, etc.) that we can profoundly alter those chemical and electrical processes ourselves. Perhaps the better conclusion is that "free will" is merely our ability to alter our own biochemical state (where "merely" is doing a lot of heavy lifting here!)

[1] https://en.wikipedia.org/wiki/Incarceration_in_Norway

Conversations around semantic HTML make me wonder: asking devs / product teams to use semantic tags, ARIA attributes, etc. doesn't seem to work; perhaps we should focus on making screen readers and other assistive tools smarter?

Put another way, where's the assistive technology equivalent of OXO Good Grips? I'd imagine a tool that is part ad-blocker, part auto-summarizer, part navigation helper, part personal curation assistant; that does the Right Thing (tm) 90-95% of the time, even on highly dynamic web applications (since that's already _way_ better than the proportion of sites / applications built with a11y in mind); that people in general find to be a superior user experience, regardless of whether they have disabilities or not.

Why assume? You can copy-paste the code and see how it works.

Most pure CSS checkboxes make heavy use of pseudo-classes and pseudo-elements - but it is very possible to make these sliders without JS!

Meanwhile, Ireland manages to amend its constitution regularly [1] without exploding.

I _very much disagree_ with the assertion that the US constitution's rigidity is its greatest strength. Similar to taking on too much technical debt, this rigidity makes it impossible to update in response to changing circumstances! I'm not convinced that's ever a good thing; what good reason is there to believe that a constitution conceived over 200 years ago (when the US had roughly 1% the people, ~1/3 the land, legal slavery, an early-industrial / agrarian economy, etc., etc., etc.) is useful today?

Even if we agree that "free speech" and "free association" are reasonable universal rights (and I think we do), what these concepts mean in practice must necessarily evolve as technology gives us new ways of speaking and associating - and we will _always_ have to deal with the difficult question of what to do when someone, through exercising these rights, deprives others (intentionally or unintentionally) of the ability to exercise theirs. This balance necessarily changes as our methods of exercising free speech and association change.

Overall, I'd argue that this rigidity - in the constitution, in the calcified two-party system, in US politics / political systems in general - maybe started out as a unique strength, but is _very much_ a weakness in more complex and rapidly changing times.

[1] https://en.wikipedia.org/wiki/Amendments_to_the_Constitution...

Auto-expiry of laws is an interesting idea, and one that gets floated here on HN with some regularity (possibly because it appeals to the refactoring mindset?)

I wonder about "Chesterton's Fence" effects, though - maybe we'd have to make a _lot_ more use of the "institutional memory" of the non-political parts of government. Behind every law, there's usually at least some advisory recommendations / reports from various agencies, and over 10-30 year timescales there's a non-zero chance that some of the original authors of those are still around.

Otherwise, we'd run the "junior developer" risk of perpetually refactoring laws without understanding the reasoning behind them, and breaking functionality users depend on in the process. Sure, it's obvious that some blue law about not pasturing your cow on ye towne grasse on ye Holye Sundaye is outdated, but I suspect those obvious deprecation cases are few and far between. Thoughtful, context-aware refactoring applies to systems in general, not just computer systems.

I've done work in the public sector before. Here's what I told recruiters who asked for my salary history after that:

"In my previous job, I deliberately took a below-market rate to work in the public sector, as a form of service to my community. I don't consider that salary relevant for this discussion."

End of story. I'm fortunate to be in a place where broader salary statistics are available, so from there I simply redirected the conversation to "here's what I'm seeing as the range of market rates here, and why I think I deserve to be on the high end of that", and that was fine.

Remember: in this industry, your BATNA (best alternative to a negotiated agreement) is...just walk away, and answer the next recruiter who's begging for your time. If they can't consider putting you forward because of an arbitrary number from a non-comparable position, well, that's their problem and their loss.

I'm glad you've had a positive experience: everyone deserves a respectful work environment, both because it's the Right Thing to do and because it improves productivity.

That said, you're countering a researched article, and the experiences of the vast majority of people in this thread, with...your anecdatum.

Does it seem that absurd to suggest that, wherever you put an abusive person in a position of power with much at stake, abuse happens regardless of setting?

"I wouldn't call it _malice_. I make more money robbing travellers on the King's road than not doing so, and it's very unlikely I'll get caught!"

Assuming a value system in which certain acts are wrong even if not observed / punished, some acts can be rational _and_ malicious.

(This isn't intended to say anything either way about BART's actions here, which are obviously not the same as literal robbery; I'm mainly disputing the idea that rational acts can't be malicious.)

Step N+1: advocate for better cycling infrastructure in your area / town / city. Places that are bike-friendly don't rely on driver or cyclist behaviour to prevent collisions; they build separated lanes, provide bike boxes in front of stopped cars, reduce speed limits, install automated speed enforcement, connect cycling paths through parks, and so on.

Aside from other good techniques mentioned here (have a mediator who is empowered to force a "disagree and commit" resolution, use collective or impersonal language), one useful technique is to focus not on where you disagree, but on where you agree.

For instance: in debugging, even if you disagree on what to try, you probably still agree on what's happening, and that you want to fix it. This changes your task from proving who's right to solving the problem together. It also focuses attention on what you know / can observe to be true.

IANAL, but this depends on the jurisdiction. In some places (e.g. Ontario, Canada), e-signatures are fine; often this is because the law explicitly says they have the same effect as a "wet" signature. In this case, "looking real" doesn't enter into it.

In others (e.g. Denmark), you don't even need to sign - merely stating your intent to accept a contract, and having a clear record of that intention, is enough. In this case, again, "looking real" is a non-issue; you can even send an email in some cases.

In yet others, you will definitely be asked for a "wet" signature, and a digital signature is not considered legally acceptable. Here looking real could matter; if your signature is obviously non-physical, it may be refused.

This also varies by situation. In some places, banks want to see a wet signature, _and_ will compare it with an existing wet signature they have on file. In this case, it very much matters how real it looks, where "real" means "matches this other real signature". (Does this make sense? Arguably no, but that's the way it currently is.)

Well - that might be overstating the matter; after all, academia also has workshops focused on very small niches...

...but also: it's not uncommon to find industry conferences about a specific framework, because it's not just about the framework - it's about the uses to which that framework can be put, and about interacting with the community around that framework. Both of those facets permit a lot of variety, especially for foundational tools (e.g. web application frameworks, UI libraries, database platforms, etc.)

Perhaps...you're just not aware of what managers do, or you've never been exposed to good management? 10 years ago, I probably would have agreed with you. After running my own consulting practice for a few years, being the technical lead on a couple of big projects, and generally gaining more experience / wisdom - I definitely don't agree.

It turns out that coordinating people, and getting them to work towards a common goal, is hard. There's all those pesky individual motivations, major life events and crises, and psychological strengths and weaknesses. Add to that a modern work environment in which many of us work on complex systems with many pieces and dependencies, any of which can break down and block forward progress. Plus, like it or not, businesses have hard legal requirements - financial reporting, human resources practices, etc. - to satisfy, along with their usual goal of building products other people (with equally complex motivations and incentives) want enough that they'll pay for them.

A good manager shields individual contributors from as much of this as possible. In other words: the better a manager is at doing their job, the more it looks to ICs like that manager is doing nothing at all - because the ICs experience so little of the behind-the-scenes logistics that they can imagine, to a first approximation, that the business magically runs exclusively on engineering effort. It's sort of a weird spin on the Dunning-Kruger effect, where your worth is inversely proportional to the external perception of that worth (as opposed to internal perception) - which is deepened by the fact that a good manager also takes blame and gives praise.

That's not to say that meetings are good, or even necessary in most cases! They're just one tool for building shared vision, and like any tool they can be (and often are) misused - long, pointless meetings with too many attendees and no agenda. I've been at those meetings. I'll admit to having held a couple of those meetings - though by now I like to think I've learned better; now, I'll always make sure there's a clear agenda with clear desired outcomes, that only truly necessary attendees are invited, and that it's not the sort of thing for which an email or async discussion would be fine. (Plus I invest some of my time in learning how to properly facilitate.)

This is not a compelling argument against GitHub (and, as others note, it doesn't really have anything to do with the article, nor does it really add anything to the discussion.)

Why does Linus hate "the way GitHub does things"? Are you referring to this [1] (which, I'll note, is ambivalent on the value of GitHub as a whole, and is only negative specifically on the matter of GitHub merges?) Or is there some other argument here that we're all supposed to be familiar with?

What are these "better solutions"? Where are they? Where can I find and use them? Are they, in fact, better thought-out and more usable than GitHub? How can I test your assertions here?

[1] https://lore.kernel.org/lkml/CAHk-=wjbtip559HcMG9VQLGPmkurh5...

Another use case where this is potentially useful: relocation. I've been rejected for financial things before after international moves, since I have no credit history _in that place_. Income? Doesn't matter. Previous history elsewhere? Doesn't matter.

This is _also_ an issue for self-employed people, contract workers, or...well, basically anyone who doesn't fit the "I stayed in one place and work full-time" mould.

...except, really, when people use this argument, they're often not using that one data point in isolation. This is just one data point, true, but it's one _more_ data point on top of an increasingly long list of "freak" weather events.

500-year floods, 100-year storms, 100-year heat waves, etc. are becoming almost annual / decennial events. We absolutely should be willing to change our prior probability that global warming is A Real Thing from "very high" to "very, very high" for one more data point; that's how Bayesian inference works.

Well: IMHO, "company bullshit" really has nothing to do with the word "company"; you could as easily substitute "interpersonal" / "human" / "team dynamics". People are the hardest part of any problem...

...but also the most rewarding. For me, no, the money would not be enough to put up with the bullshit, not by itself. Much more compelling is the idea that multiple people working together as an effective team can build things of greater scope, quality, and importance than one person can working alone.

Of course, if "people here can't work together as an effective team" - e.g. because the culture is overly cutthroat, or the environment is interruption-prone, or project teams are demotivated by a lack of trust / agency / autonomy, or impossible deadlines are the norm - well, if those things are part of the bullshit, no amount of money will make that enjoyable and rewarding.

In such an environment, what's a rational strategy? Probably to save up a bunch of money, to the point where the next job search can be motivated by things other than immediate financial need, and quit once that's achieved. (Hence "rest and vest" behaviour, which is often a huge red flag about the organization and not the individual person.)

I'll choose instead to be amazed that Doom-capable computers are now inexpensive and ubiquitous enough that it makes total financial sense to use one in a light bulb!

More seriously, I see this argument all the time: that we are just squandering our advances in hardware by making comparably more inefficient software! Considering that efficiency used to be thought of on the level of minimizing drum rotations and such: the whole point is that we're now working at a much higher level of abstraction, and so we're able to build things that would not have been possible to build before. I for one am extremely grateful that I don't have to think about the speed of a drum rotating, or build web applications as spiders' nests of CGI scripts.

Are there modern websites and applications that are needlessly bloated, slow, and inefficient? Certainly - but even those would have been impossible to build a few decades ago, and I think we shouldn't lose sight of that.

If you think pornography is somehow uniquely modern...well, you're ignoring a millennia-long history of erotic depictions there, on top of presenting absolutely no evidence to support your rather Puritanical claims.

To be clear: data model migrations should still be tested and scripted to the extent possible; there should still be backups in place; there should still be a way to roll back application code and data schema. Just because a team / organization decides not to do zero-downtime updates - which I'm arguing is a completely reasonable choice in a lot of cases - doesn't mean they should abandon other software engineering practices.

Looking through the comments on this post, I see a lot of conflation between "not doing zero-downtime deployments" and "seat-of-your-pants engineering", as though fully orchestrated / containerized blue-green zero-downtime deployments were the One True Way for all teams / organizations / projects, and completely inseparable from other parts of good engineering practice.

As stated in the post: these steps make complete sense if you're aiming for a nice, smooth zero-downtime transition from the old data model to the new.

However, if you can get away with some downtime, you can instead notify your users of a planned outage, shutdown, update everything, and startup again. This eliminates several steps of the process, which has the added benefit of reducing the number of places where something can go wrong.

To put this in context: say you guarantee 99.9% uptime - that's still 43.2 min / month of downtime available to you! You can update quite a lot of machines / database rows in even 10-20 min, making this viable in many cases. (Obviously there is a scale threshold past which this is no longer viable, but if you're at that threshold you can probably also spare the engineering effort to go the zero-downtime route!)

It's a fair remark, but like any large organization, government isn't this single homogenous entity: it's a collection of groups with imperfect communication and sometimes conflicting / separate goals. (That doesn't make scenarios like this better, but it at least makes them understandable.)

IMHO if you want to understand what an effective response looks like - don't look at North America or Europe. Think Vietnam, Australia, New Zealand, and many parts of Africa, all of which had vastly better outcomes.

Of course, I'm not an epidemiologist or public health expert, so while I have some guesses I'm not sure what exactly they did that was more effective - but there's no question that it was more effective. If I was going to look for case studies to understand what to do next time, I'd start there. If I was going to look for case studies to understand what not to do next time, well...

Re: renaming tables - yay! It's essentially double-buffering for databases.

I've used a slight variant of this in the past: I'll have a table (e.g. my_schema_new.my_table) that gets updated by an ETL pipeline. I'll then also have a matview (e.g. my_schema.my_table) that's just SELECT * FROM my_schema_new.my_table. As long as I can give this matview a UNIQUE index, I can then REFRESH MATERIALIZED VIEW my_schema.my_table CONCURRENTLY for zero-downtime updates.

(Of course, if you're using this in a non-interactive data warehouse context, you might not care so much about zero-downtime updates; this is more for application-facing views. The REFRESH ... CONCURRENTLY pattern can be faster for incremental updates, but often struggles with larger changes to the underlying table, as it's essentially applying a diff between the two versions. Also, it only works in cases where your users can tolerate data that's as stale as the scheduled time between REFRESHes.)