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.

I'm fascinated by how many of the things they identified as helpful to new users were later reverted. Looking at my Windows 10 desktop all of the work they did to find a solution where all users identified a program as "running" has been undone - it's back to icons with only a subtle indicator to distinguish between those that represent shortcuts and those that represent a running program.

The Start Menu is now assumed knowledge that the furthest left icon on the taskbar is "special" and does something different to all the other shortcuts. I guess the modern equivalent of "Start" is "Type here to search" in the Cortana bar but that's not a great experience for new users. We all know the propensity for it to decide to search Bing at the slightest provocation but if you try some natural "never used a computer before" things like searching for "power off" or "shut down" you get some quite unhelpful results. (The former wants me to set up a power plan, the latter directs me to Add or Remove Programs)

It feels like computer use is assumed knowledge in 2019 - that everyone who buys a computer already knows what the Windows logo represents, how minimising and overlapping works, what the difference between an app icon and a notification tray icon is, and so on. Microsoft no longer feel the need to design so much for people buying their first ever family computer, having never even used one before. Probably true in the first world, but I wonder if this holds out globally?

not the VPs, not the CEO

This is the biggest problem where I've seen companies try to do this. The C-level and senior management team make a big fuss about how the company is having too many pointless meetings, they need to be effective, short and have agendas... and usually you can count in hours the time before the one of the exact same senior managers has sent a 2 hour, 20-person invite titled "project catch up" with a blank body.

(You can probably generalise this to many company initiatives, not just the ones about meeting habits.)

There are some categories of product I'm no longer willing to buy from Amazon: power cables, replacement chargers and batteries being the biggest offenders. They're such a minefield of fakery and shortcuts that are outright dangerous (e.g. UK plugs lacking fuses and with pins the wrong shape/size) that I'd rather have the extra work and expense of going to a local shop where I can inspect what I'm buying.

I tend to swap between two modes.

If I'm working with well-known tools and a problem I understand reasonably well, I'll approach it in ultra-strict test-first style, where my "red" is, "code won't compile because I haven't even defined the thing I'm trying to test yet". It might sound a step too far but I find starting by thinking about how consumers will call and interact with this thing results in code that's easier to integrate.

However, if I'm using tools I don't know well, or a problem I'm not sure about, I much prefer the "iterate and stabilise" approach. For me this involves diving in, writing something scrappy to figure out how things work, deciding what I don't like about what I did, then starting again 2 or 3 times until I feel like I understand the tools and the problem. The first version will often be a mess of printf debugging and hard-coded everything, but after a couple of iterations I'm usually getting to a clean and testable core approach. At that point I'll get a sensible set of tests together for what I've created and flip back to the first mode.

Totally agree. In my experience "that's just X it does that sometimes" have been symptoms of some of the scariest bugs in the system we've been working on. A couple of examples:

- a caching issue that was a "just X" on a single server, but took product search (and by extension most of the business) offline if two servers happened to encounter the same problem at the same time.

- a "just X" on user logins, which turned out to be a non-thread-safe piece of code that resulted in complete outage of all authn/authz-related actions once demand hit a critical point.

On top of that, having a culture where there are errors it's okay to not fix is tremendously damaging to team values. I've not seen a team with this attitude where the number of "just X" errors wasn't steadily increasing, with many of the newer ones being quite obvious and customer-affecting problems.

If you take "the idea is to give people a chance to share how they really feel in a vulnerable, one-to-one setting" and replace "one-to-one" with "small group" then this feels very close to the way many people used LiveJournal at its peak. Maybe slightly different in that the one-to-one stuff wasn't automated: people would have public posts in which they'd share more generic stuff, then curate private friend groups from people who responded in ways that suggested they would have empathy. These private networks would be where the more vulnerable things got shared and discussed.

Of course as a community it was much derided - teens and young adults finding their way in the world looked naive and emotionally immature from the outside - but it's interesting seeing someone trying to bring that pre-Facebook sense of sharing with a small and sympathetic group back.

Something I've noticed about the culture of "work through midnight if that's what it takes" is how much work gets thrown away. I worked at a few places with this culture (startup and established), and it seemed entirely normal for something to be the most urgent thing ever at 9pm and then, "actually, we've decided to approach it differently" the next morning.

I think this is because the impact of an error of commission is low. The worst that happens is people work a bit later, and since they're always working later... well, it's fine to build things that don't need building and have meetings about things that aren't happening. Nobody worries about wasting time because it's just pushing work into a buffer that is treated as infinite. But with limited incentive to select high-value work, it's easy to fall into a trap of working 12+ hour days entirely on low-value stuff.

"Go home on time" cultures are forced to prioritise to be effective. If you know you're going to shut down the laptop with tasks unfinished, you have to make a choice on which tasks you're willing to accept not getting done today. In this situation there is a significant impact of an error of commission, because it means something more important not getting done. IME this results in higher-value work overall, because the organisational instinct tends toward scrutinising everything to see if it's worth doing, not just the things which will take you past 5pm.

I've not been fortunate enough to work somewhere with a 4 day week, only places with generous working hours, but my feeling is it would be a further improvement on this. (Especially since with more free time, people are not going to assign such a high importance to doing their finances, keeping track of Reddit, daydreaming about DIY or any of the other thousands of things people in long-hours cultures do on company time).

Someone (I think possibly John Cutler) made a good point about this, which is that by now the early and middle adopters of classical manifesto-style "Agile" have absorbed it so thoroughly that it's no longer something deserving of a special term, it's merely the way things are done.

This leaves the late adopters, and the sociopaths whose main interest is extracting money from the late adopters. As a result, it's becoming a safe bet that anyone using the word "Agile" unironically is either going to inflict upon you whim-based development with added Post-It notes, or sell you an enormous slab of process binderware with bonus added two day certification courses. (From which your managers will return having spent the entire course answering e-mails on their laptop, and proceed to inflict upon you whim-based development with added JIRA.)

I think LinkedIn suffers from people treating it as an extension of a CV or prospectus, which probably isn't an unfair assumption on their part. Which means not introspecting failures, only commenting or reacting on banal platitudes, and not saying anything that might be remotely controversial for an employer.

This is sad, but as someone who will happily admit failures, frustrations and annoyances on LinkedIn I have been in interviews where people have dinged me heavily for it. So far these have all been quite toxic work environments - maybe you could count it as a useful filter, but I understand given this why people feel pressure to do little more than copy/paste the same Oleg posts ad infinitum.

In this context, the rationale was little more than this being the last version in which "John" had done significant day-to-day programming, and therefore felt informed enough to interfere with on a daily basis. My personal take was that a lot of the negative behaviour was being unable to "let go" and accept no longer feeling like the best programmer in the organisation.

I worked with a "John", with the added bonus that I was expected to be the hatchet man telling developers that they couldn't use any language features introduced post Java 5 or that they had to restructure all of their solutions in line with the latest edict. Thankfully we had some very good teams who saw exactly what was happening, and were able to schedule a round table so we could talk about how this was both demoralising and causing things to go extremely slowly. (At one point "complying with edicts" was taking up 80-90% of engineering effort).

The net result of the big round table with every senior dev in attendance was "John" spent an hour trying to deflect us from the topic at hand, 30 minutes pretending to listen to us, then within two days it was back to, "I want you to tell the teams to go back and rename all the DTO objects they've created".

In the end I just left. There's no point fighting that kind of environment. Someone hires "John" and is happy with what they do.

I went through this with power tools. What I found was products would end up with three broad classes of negative reviews, segmented mainly by price:

* Expensive tools would have gripes about price or lack of inclusion of accessories. If I bought something in this category it would be problem-free, but so far in excess of what I need as a hobbyist/DIYer that it was comical, e.g. a circular saw that could happily saw my car in half when all I'm doing is building bookshelves.

* Cheap tools would have a consistent pattern of reviews mentioning one or more specific failures that occurred during normal use - e.g. belt sanders that swallow belts or drills where the chuck quickly comes loose. If I bought something in this range, I'd experience exactly the same failure myself.

* Finally, mid-price tools would have the same number of poor reviews as the cheap ones, but the scenarios described would be abusive or unrealistic expectations: people complaining that they couldn't use an orbital sander on concrete tiles or fit enormous router bits to something consumer-grade.

The realisation I wish I'd come to earlier is that stuff in the last category is fine, particularly when it comes to a tool I only use occasionally. Stuff here does exactly what I need, gives good results, and doesn't result in me paying for power I'm never going to use. I guess that's part of the problem with online reviews - needing to get to the level where you're analysing them in depth to differentiate between "it broke because it's badly made" and "it broke because I was doing something completely crazy with it".

In my experience, architects who are valuable to their teams tend to be the ones who rarely do any "architecture" themselves; instead they work their arse off trying to smash apart every last blocker to the engineers in a team being able to own architectural responsibilities themselves. (This may include asking smart questions to help a team who don't really do systems thinking start engaging with it). This inevitably ends up off in the EA realm grappling with Conway-type questions: not so much "how should we structure our software to make it good?" as "how should we structure our organisation so it naturally produces good software?"

Sadly these people are also rare as it requires a combination of sufficient technical skill and the ability to effectively navigate the people side of the equation.

The "white paper" style of architect is very frustrating in comparison, not least because they are too removed from the context and impact of their decisions. This results in a situation where a team views their architect as merely a source of additional work, much of which is frustrating and pointless if not outright damaging to the system being built.

I had a 17" CRT monitor on a 286, with a Trident 8900 SVGA card driving it. Hard to credit in these days, where even using a non SSD equipped computer is painful, I used to happily wait several seconds for Program Manager to repaint itself.

Remastered has it too. Steam version even has achievements for doing things that require you to get a small way through the original.

Agree on not needing to play Maniac Mansion first, too. I came to the original having no idea that MM even existed. The characters and story are great even if you don't know the references.