gemstones

Sure they do! New grads absolutely have people skills. They make silly workplace norms mistakes too, but they generally aren’t clueless about how to get along with people like you see in a lot of programmers from earlier generations.

A take on why there’s so much over 40 discrimination, and why I expect it to decline somewhat in the next decade:

Imagine the crotchety (young) programmer you know. The guy who’s kind of a mild know-it-all, who gets disinvited from business meetings for being too abrupt, they guy you have to front with a good PM to talk to anyone external. Maybe a little autistic, perhaps undiagnosed; regardless, they seem to have trouble connecting and “getting” people.

Early CS - before it was well known that it would be a fast track to the upper middle class - was full of these people. Computers draws that personality type in. Limited interaction with others, working code wins, you can get lost in a math problem.

But we needed more programmers! And now, it’s well known that being a programmer is lucrative. So the younger generation is less full of people who really love computers and want to escape human interaction; they learned computers cause they’re smart, and want to make money. But they’re probably good with people too! Most people are.

Where does that leave the older generation? Over a certain age, you’re more likely to be the type that’s a bit hard to work with, swimming in a sea of graduates who have people skills now. And as you might expect, companies will pick the people with hard and soft skills given the choice. They don’t want to entertain the prickly guy who wants a math problem and a pizza slid under the door, if they have alternatives.

As the pool of devs widens, expect the age discrimination gap to narrow. Not go away, but narrow. People never really liked the no-social-skills aspect of CS nerdiness. They just tolerated it, for a time.

I guess I don't typically think of things like Go's context when considering DI, but it serves conceptually the same purpose. My beef is more with the DI frameworks, I suppose.

I'm very curious to hear from someone who likes DI in a non-OOP language - why? What techniques do you use to make the level of indirection feel like a help, rather than a hindrance, in your codebase?

Reading this article reminded me that DI has a lot of advocates, but I've never heard a compelling reason to use it in most codebases.

Maybe in high school debate class, it is. But for established societal norms that most people can see the benefits of, someone who comes in with a fringe belief is expected to provide a more interesting answer. If someone said “correlation is not causation” to the assertion that people who go to the gym regularly are more fit, people would dismiss them out of hand and treat them like an annoyance too.

Nope! Clojurescript also has bloat, but I’m referring to the unique problems that arise with combining the two.

Funnily enough, the author is the creator of DataScript, a language which has been the source (directly or indirectly) of some of the biggest bloat/performance problems I've encountered in client side programming.

Because it’s on you to show what about the correlation makes causation unlikely, and most people don’t take that step. We all know correlation isn’t causation, that’s trite and obvious. Why wouldn’t the correlation between married parents and better child outcomes be causative?

I have found success with having a session with the PM where the goal is not to have complete, perfect cards, but at least one ticket for every thing you can think you will need to do on the project.

So you’ll have a bunch of one liner cards, but at smaller fidelity, like

- Make a bulk create API endpoint - Migrate data from old to new table

Then, if there are 5 or more cards there, make your estimate

((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days

It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”)

Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.

In my (admittedly anecdotal) experience, security people are the worst at this. I’m not sure if the problem is that they have so many certs that you can just memorize canned answers and get a job rather than go through an SWE coding test at most places, or something else.

Being overweight is a lot less of a disadvantage in a fight than you might think.

The American midwest is relatively safe to settle in. St. Louis, Kansas City, Minneapolis, Indianapolis, Milwaukee, Detroit, and Chicago in particular.

    Any derivative works of AGPL-licensed software must also use the AGPL.

How a court interprets "derivative" here makes a big difference, that Drew doesn't seem to effectively counter. I'm not sure why his take on what it means will make a difference to what a judge may think it means.

Until AGPL is tested over and over in court, and all interpretations converge on Drew's interpretation here, it's not safe to have anywhere in your commercial stack.

You would think that companies would take the easy step of not using internal company nicknames in these press releases (Stackers.)

Just “employees” would make it sound less tone deaf.

So why did the frontend engineers move on from Ruby on Rails?

When I was an ROR developer, RailsCasts would tell you to do basically the same thing as HTMX, return partial HTML and use a tiny bit of JS to update the appropriate part of the DOM.

It’s a good fit for simple experiences, but breaks down when you need the result to update more than one place (say, a counter by the cart icon, or a set of options in a select in the sidebar.) Then, you hypermedia approach has forced you to try and explore your HTML snippet to pull relevant information, rather than get it in a nice structured format.

Another wrinkle - lots of web apps have a need to say, I’m going to give you one bundle of JS for this whole hostname, regardless of URL, but then have to handle getting loaded from arbitrary URLs (that may have semantic meaning for your server) anyways. Everyone gets the complexity of a URL document hierarchy, even if your web app isn’t document-based.

Yeah - it’s a wildly different paradigm. It’s not quite the same as Erlang/OTP, but it requires a mindset shift much like learning OTP and thinking of callbacks on an event loop working together. Users can interrupt code when they want, and aren’t obligated to take a blessed path of actions.

I will say that some of the complications he mentions are from web apps needing to compile down to a single executable, on a platform that only really supports one interpreted language. Perhaps WASM will help here, over time.

It’s not a problem for me! It sets a precedent, sure, but I’m okay with the tradeoff there.

Although in this case, this was a good use of government time even if it goes to the courts! I would like to see the government instill a culture of fear in these companies’ legal departments, that leaves them wondering them the law will change to hit them.

As a voter, I’m OK with them not following the process on this one!

Yes it is, because this one negatively affects enough people that the law should make a special case to disallow it. Contracts are enforceable when laws say they are enforceable, but governments are free to change laws.

If the government says it is a fiction, it is a fiction.

At one point, it wasn’t an Irish company. Now technically the American company sold or transferred its IP to the Irish company. But it did so as a fiction, to avoid taxes, and neither I nor a government I help elect are obligated to honor that fiction.

Living a 5 minute walk from the office is how most humans have lived throughout history, and what most of Europe’s most pleasant cities to live in were designed to support.

I know tech changes things, but if I had to guess, the era we just lived through was the weird one, and living a 5 minute walk away from work and amenities is the norm we’ll revert back to the moment that tech adequately supports it.

There is something salient about the fact that Canonical’s culture is not one to mimic, though.

What if there is something about following this advice that unwittingly selects for candidates who will make a super long and off-putting interview loop?

I’m curious, since most people seem to take company-wide statements like this as having no implicit limitations -

Why? Why would this supercede fiduciary duty? Maybe this is a real ask for managers which isn’t considered anymore after a certain point. Why is every rule expected to apply equally across every level of the company?

If you think about the fact that higher level languages are largely a 1950s innovation, it helps.

Disciplines that are 70 years old are not likely to be stable.

TBH, by some measures Japan also applies here. They do better on a lot of measures, but their parenting story is one of pushing all responsibilities onto the woman and keeping men at the office late forever. That's a different type of servitude and denial of care to families with young children than America, but it matches the OP's comment.

Good thing they can benefit from those changes, now that we’re decades in! Can you imagine if they had to manage ARP still?

These are some very compelling bingo items - I’m not sure if sharing this card is having the intended effect (unless you wanted me to continue to think that IPv6 isn’t ready for real use?)

There are things which come with being the richest country and a really populous one - you're targeted by all kinds of scammers who view you as the best target. Similar to how startups try to serve the U.S. market since it's 300 million relatively wealthy people. You could start your startup in Germany, but is the market there for what you're doing? Scammers use the same logic.