Timberwolf

You get an interesting collision between two expectations on licensing in a modding community for an open source game.

Modding communities have historically leaned on self-penned bespoke licences tending toward the, "only Tool fans can use this! Do not rip my sprites without permission, that means you XxSephiroth494 YOU HAVE BEEN WARNED!!" school of legal text. But as an open-source project, there is a convention to upload things to the content distribution network with a GPL or Creative Commons licence.

This causes some rather dramatic fallouts when "I don't have to give you any source code, it's mine and I wrote it" or "he can't just take my mod and build his own version of it" meet the inevitable response of, "you released it under the GPL, that's how it works". It gets rather messier when said work includes upstream things which were originally released under the Tool Fan Restricted Licence or similar where the original creator forbade further sharing of source code.

It's been a long time but I'm sure I remember something along similar themes being one of the essays in the back of the SimCity 2000 manual. Which now makes me all nostalgic for the days when game manuals were something existing at the confluence between readme, strategy guide and just plain good reading matter.

Sorry, jargon: Individual Contributor, meaning someone who works on things directly and doesn't do any management.

Companies really struggle with this, and in both directions. Startups and scale-ups tend to overcompensate to the point management hires get interviewed as super-ICs, where they'll be expected to answer technical stages at (or even above) the company's top IC standard, but only get a couple of basic scenario questions about management that anybody could answer. Sometimes you get lucky and they're good at both, but it's a big source of the "management by yelling at people" and "I can't have a 1:1 with you, I'm fixing a production issue" schools prevalent in such environments.

It's rare to find a company balanced in the middle where they're looking for someone who clearly "gets it" and can talk about technical solutions, but also has the ability to solve the people problems. (Often good managers were also skilled ICs before they made the jump, but lack of everyday practical use leaves them with a layer of rust. In an hour interview with someone you've never met before it's hard to tell the difference between "rust" and "has heard of the concepts but doesn't really understand them" though)

I think the article misses what I think is a vitally important part of the job: being a crap shield.

A lot of the work of an EM is wading into the slurry pit with a shovel so your team are free to get the job done: bashing your head against InfoSec teams stuck in the '80s so the CI/CD toolchain can deploy to production, negotiating freedom with a CTO who wants to specify everything to the level of individual data structures, convincing HR that no, we really do need to pay for a good senior and not hire someone with 2 years experience in a configuration galley because they're cheap.

On top of that there's the process battles; in older firms, all those interminable "but can't they just use Waterfall?" meetings that go on for hours and are spawned every time there's a minor project manager reshuffle. In newer ones, the ongoing fight of, "you can't address debt or build foundations for the future, we need features, if it can't be done in less than a week it's not MVP enough"

There's a fine balance in that I think a good EM lets their team know this is going on and get involved where they want without dumping all the crap downward. Not least because they should be coaching their team leads in that responsibility, so they can take the career step when they want.

Going back to the article, as others mentioned it does read a little bit more like a "why I'm frustrated with my manager" than a "how to be a good EM", but it's easy to misconstrue the meaning of text.

One thing which really resonated:

"But will you do the boring but necessary browser testing to figure out if what you’re describing is always true, or just most of the time? And will you repeat that testing once new versions have come out? Will you go through related pages..."

This. A thousand times this. The problem for me isn't the quantity of information any more, it's the quality. 10-15 years ago if you hit an even slightly esoteric problem you'd bottom out a search pretty quickly and be on your own. Now, you'll find dozens of blog articles, community answers, Reddit threads... and unless you're very lucky they will all be wrong, from subtle "works on my machine"-isms up to "just commit a god-rights CI token to your repository, it'll be fine" - the telltale sign often being nobody can tell you why this is the solution, merely that they bashed other random solutions to related problems together until a particular combination happened to work.

Authoritative sources like MDN are vital in this context, having something you can refer to that tells you how things actually work so you can verify whether the suggestion you or a co-worker found on a blog is a sensible solution or the kind of horrible mess you'd expect to find alongside world-writable S3 buckets and services that regularly time out due to being OOM killed.

What I like about the '70s stuff is almost everything uses standard parts you can get from any reasonable factor, and the few unique components are usually still simple enough that some hobbyist or small machine shop will be turning them out and selling them. Providing it hasn't been abused it's possible to refurbish something using only simple tools and a bit of testing, and some of the equipment is seriously good even by modern standards. (One of the main reasons I ended up with a '70s turntable is I couldn't find anything new under £1000 with the same sound quality, or that didn't require directly fiddling with belts and pulleys to change the speed.)

By comparison, whenever any of my modern kit breaks down I find the offending part will be unique to that unit, the spare parts supply is nonexistent, and there will be no published specs allowing one to cobble something together.

I spent four years at an organisation rife with this. I found two major routes for getting to work on hard problems.

The first was joining initiatives that were in such utter disarray people were willing to take any risk to get out of the "someone's gonna get fired for this" hole. They were typically rich in hard problems (the chaos was usually caused by failure to address one or more of them) and people liked the idea that someone else was taking on responsibility and becoming the person who was most likely "gonna get fired for this". I was happy taking that risk, considering the payoff in getting to work on interesting problems worth it.

In the absence of disarray, I had to go down the much slower route of finding small things that received so little attention I could just do them; nobody cared about them enough to worry about success or failure, and the time input was small enough nobody got upset about it. Over time the cumulative impact would gain me enough trust to take on something bigger, and assuming that went well things would snowball from there. In this way I "trained" one of my bosses from flipping out at the most minor suggestion to pretty much leaving me alone to get on with what I felt like, on the basis I would usually find things to do that reflected well on him.

Unfortunately I never worked out how to get anywhere with the kind of person who benefited from the hard problems not being solved -essentially those profiting from either the prevalence of bullshit or non-essential things being done as per points 3 and 4 in the article's section on what happens when you do tackle the hard stuff.

I'd also caution in my experience it wasn't useful in advancing my career at the same company - I did see a big benefit in credibility but it was among peers and the people I depended on to "get a VIP pass around bureaucracy". This has been general across organisations in my experience: the career stage benefits only come when I move on and have a load of experience in problem spaces I simply wouldn't have encountered had I kept my head down and merely done my job.

This is a consistent bugbear of mine, and I think a big factor in the resurgence of vinyl. I find it frustrating I can take a recording from a format with limited dynamic range and stereo separation, which is incredibly vulnerable to environmental contamination and vibration, where the playback device adds its own bundle of mechanical noise and unusual non-linear responses... and yet if I have a good pressing it will sound better than a "digital remaster" CD which has none of these inherent issues, because the digital copy has been compressed and limited to the point where it's fatiguing to listen to.

That said, I've bought a few modern albums which have been really nicely mastered; they've got that rich, deep '70s LP sound but available on a FLAC download without all the surface noise and rumble.

Also that section on the '60s loudness war underplays quite how LOUD some of those old mono 45s are... I typically set things up so my peaks are at -12dB when recording, and I have the odd mid-1960s single which will be pegged right up against the red if I don't adjust the levels. No wonder there were some pressings that were notorious for throwing the stylus out of the groove when people started chasing ultra-low tracking weights in the early '70s.

I thought similar. To me what Buzzfeed are calling the "old Internet" here is something I very much remember bemoaning as the "new Internet" in which dedicated protocols such as NNTP and IRC got displaced by brattish commercial upstarts whose web-based versions had 10% of the quality-of-life features and about 5% of the community etiquette. However they displaced everything that came before them because you could embed images, have an animated avatar and (most importantly) not have to delve into the world of finding a client of choice and connecting it to your ISP's news servers.

What I find myself missing more than anything else is that news server was something you paid for, either as part of an ISP package, as a dedicated service or your university tuition fees. The commercial model was purely the provision of that resource - not selling your data, nor being a vector for targeted political ads. There was no incentive to make the basic mechanics of discussion worse or promote flame wars in the name of "engagement" or "monetisation", and while I'm sure the smaller community size played a part things seemed to bump along with a far greater degree of civility and allowance for misunderstanding.

My experience working for the 800lb gorilla incumbent was that we didn't take competition seriously at all. Even stuff competitors did that would be trivial for us to replicate got put in the "not a priority" bucket. The few cases where we were forced to match a feature you were looking at a lead time measured in years, tending to infinity if it threatened the influence of a powerful department. And this is the reactive stuff. Forget actual innovation, other than a few toy projects that never escaped the lab!

However, this was justified: even the most promising-looking competitors tripped over their own bad assumptions long before becoming a threat. We saw plenty of novel ideas but they'd always be sunk by a failure to understand the basics of how our market worked - things like trying to put a complicated app with a thousand options at a point in the journey everyone is trying to simplify and time-optimise, etc.

If someone who knew the market well had gone at it seriously and solved hard problems rather than apply the usual hand-waving "tech! blockchain! magic!", by the time we'd noticed it would have been too late to respond. You'd hope more recent incumbents like Netflix or Twitch might be a bit more responsive, but corporate inertia can build up surprisingly quickly.

The problem with such regulations is they tend to be written by the same kinds of people - those who still assume that having meaningful SQL characters in a password is insecure, or that every device on the Internet will have a static IP.

They're a great example of the unintended consequences of regulation. I'm sure the original intent was not to have a huge banner where the options for managing what the site tracks were a one click "sure, whatever" or a multi-stage process of "no -> manage preferences -> categories -> reject all -> find the actual 'save' button, not the 'enable and save' one -> confirmation page where 'cancel' is lined up in the same place as 'save' was previously".

I loved this feature in Windows 7, because all it did there was an exact substring match over the items in the Start menu. As a result, it was instant.

The Windows 10 one where it's trying to do a Bing search, look through the Microsoft Store for apps to buy and who knows what else is... I can see what they're trying to do, but if you have 24 years of ingrained habit of only using Start to launch programs it's annoying having the feature made so CPU and disk intensive to add options you don't use. At least Microsoft have put a lot of work into improving it. Using some of the early iterations on a slow spinning-rust laptop would frequently result in the process searching your installed programs timing out, leaving only the web search option.

Every once in a while I'll catch myself trying to read web content in the tiny window between the sidebar ads, the floating video, the cookie control panel and the "other content you might like" block... and I'll stop, pull back, and ask myself, "how did computing get this BAD?"

Especially in the web context, I think it's as you say: the real product has little to do with the task you came to the site for, so everything is trying to distract you away from that task. The end experience is as if the people who used to run warez pages with 9 giant buttons to download dodgy IE toolbars and one 20px link to get the actual file grew up and got jobs running mainstream news sites.