I’d go further and say the advice in this blog is rarely the right move. It’s written for a context where everyone else is wrong except you, dear reader, who can see the true path forward.

It also appeals to people who think in false dichotomies, where your only two options are to do strong-headed moves like this or become a passive sheep who fails because your boss is bad.

In real businesses it’s rarely that simple. Using “dangerous advice” or becoming the “scary professional” as another influencer words similar advice sounds best when you’re imagining how the interaction will go and how much you’ll be winning when it’s done, but in a real business where things get done through relationships and trust it’s very easy to find yourself moving backward and being pushed out when using advice like this.

I couldn't agree more. Software engineering environments vary so wildly that you better respect your own context

I don't think I agree; some of what's recommended here is what stops dysfunctional orgs from getting their shit together.

Plus every developer believes they're a special and insightful little petal so all the caveats will get ignored.

No, some of that is horrible advice even at a healthy functional organization. You don't want to break rules silently, defiantly, or row in the opposite direction.

Leadership should be establishing cultural and communication norms. So if you have ideas, questions, concerns, for example - you don't need to break rules or work against the engineering org vision, culture, or process.

Mistakes and learning and being busy and lack of communication process aside... You should be expected to have a negative consequence for following some of this advice. It'd be well deserved.

Now, hopefully, you have some excellent managers who can help guide and support you...but if we have articles like this that kinda drive the behavior we don't want to see and people put more trust in random internet junk than they do their managers. That's a problem.

The two worse pieces of advice in the article are breaking the rules and making your own decisions on what to work on.

Everyone including the CEO [1] has a mandate on what they are suppose to be working on. If you choose to work on something else without a mandate and the buy in of your organization, it has downstream and upstream effects you aren’t innovating, you’re being disruptive and not in a good way.

If you have an idea that you think is good, first you sell it internally and get buy in - either via a proof of concept or at least a decent write up or conversation - then you implement it.

From 2016-2018, my responsibility coming from the director was “we just got acquired by a PE firm and you are responsible for integrating these disparate systems of these companies that are being acquired. Let me know your plan and how many people you need”.

Even with a mandate that broad, I knew what rules couldn’t be broken or when I needed to ask for guidance from legal, finance, the CTO, etc.

I didn’t get to “make my own decision about what to work on”. I had broad categories of objectives and I could choose how to prioritize and took some latitude about what to “delegate to the floor”. But anyone who needs to read his advice doesn’t have the experience or professional maturity to know that. I didn’t early in my career and I have the PIPs to prove it.

The next company I also had a broad mandate. But that doesn’t mean I was going to “break the rules” and start putting workloads on Azure in an AWS shop or implement something using Postgres when we were a MySQL shop.

Fast forward to the present. I am a staff engineer working at a cloud consulting company. My responsibility is to either deliver implementation projects or your standard 40-50 page management consulting type reports.

I still have rules I know not to break even though I’m given really wide latitude about how I deliver - they still have to be done on time, on budget and meet the guidelines of the contract.

And the ends justifying the means doesn’t work at large companies. I worked at GE when it was the 6th most valuable company (where I overcame a PIP that was caused because I wasn’t politically savvy) in the US and later Amazon (AWS). With a lot of startups and small and medium companies scattered before and between.

[1] If the company has outside investors they are accountable to their boards and investors.

It's a fanciful idea, but just like the real life analogue it models, it completely turns a blind eye to the fact that, ultimately, the pirates are looters and pillagers and will burn the shop down, both yours and possibly theirs.

And no I don't agree a pirate captain is needed; the notion of a "static" equilibrium is contrived and a non-sequitur in the analogy. The ship could simply sail smoothly instead (still an equilibrium) without arbitrary changes in speed or going too close to the reefs for no bloody reason.

And if the "chaos" is "strategic", then it's not bloody chaos to begin with, is it?

Sure there is a way, hire good people, fire bad people , give them wide guardrails and hold them accountable for results.

Hire people based on their proven ability to deal with ambiguity and gets things done. Like Joel Spolsky said, the only hiring criteria is if they are smart and get things done.

> If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.

You can say that about everything that has some form of guardrails. It goes faster without them. That doesn't necessarily mean it's the right decision to remove them. People tend to change their minds after they have an accident, which to me is an indication that they can't seem to properly assess the risk and the outcome beforehand.

This is a really bad take. Professional arborists don’t “rip every guard off their saws”, there aren’t even that many guards to begin with, and the ones that exist (chain brake, hand guard, throttle lock) don’t slow anyone down. They’re there so you don’t bleed out in a tree.

The “LARPing” angle makes even less sense. What’s the software equivalent, saying that keeping engineers out of direct prod access is just an ego hit? That’s not LARPing, that’s risk management. Same way arborists keep the guards on because downtime from losing a hand costs more than any pretend efficiency.

Bad tools don’t make you a pro, and pretending guardrails are just for “fools with money” is an incredibly bad take. It’s like those YouTube get rich folks that never mention how much of the success is luck.

> Every now and then, there’s a nasty accident...

That may just be they aren't very good at risk assessment. Nasty accidents with a chainsaw are in a different league of damage for the person involved compared to, eg, accidentally deleting a database or upsetting a manager. A software engineer is all but guaranteed to walk away from deleting a DB with their limbs intact. Even if their manager gets really angry a dev is almost certainly going to survive the encounter.

>If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.

What are you actually talking about here? Tree surgeons may remove some of them some of the time, but all of them would either kill them, get them fired, or both.

Here is an old quote to put into perspective:

https://quoteinvestigator.com/2022/06/06/old-bold/

It isn't experts who remove it. It is professionals whothink they know. I've been trained on chainsaws by USFS experts - they used the safety gear and demonstraighted that used correctly things work just as fast. In fact they were often faster than the professionals who thought they were faster - because the planning and communication steps (6 steps) often saved more time than was gained by jumping in)

safety gear doesn't cost much time to put on. Checking the safety gear also finds not safety things wrong with it.

In my experience it's the other way around. It's typically the bottom of the barrel contractors who sabotage their own (and others) safety for a quick buck.

The same way a senior engineer is more likely to use version control, backups and automated testing rather than YOLOing vibe coded applications to prod.

The old saying "they've forgotten more about X than you'll ever know" is very true. A professional quite often has forgotten what it was like to be a beginnner, making them both very knowledgeable about a topic but also very likely to give dangerous advice to a beginner.

Although I've never worked as an arborist, I supervise the installation of high voltage equipment for a living. I work with all kinds of contractors. Our equipment weighs tens of tonnes.

If I would see somebody removing the guardrails from their tools, I would send them off site immediately. There will be no nasty accidents.

Although, loggers have specialized vehicles (harvesters and whatnot) that look more like construction vehicles with giant saws and grabbers on the front.

I think there’s something interesting in the pick of arborist (somebody specialized in coming in and dealing with troublesome trees) vs some kind of logger (specialized in the at-scale harvesting of trees). I bet there’s more room for modified consumer gear in the previous case, because the whole job is to figure out weird situations (like taking down or cleaning up a too-big tree in somebody’s back yard with poor access and lots of things you don’t want to hit) that might preclude the use of the ideal equipment.

But, it isn’t obvious to me which is more like software engineering. Ideally, the software company is a cultivated environment optimized for productivity, more like a logging forest. Part of the engineer’s job is to help cultivate the nice orderly rows of correct-sized trees so that they can just rip through them at scale, right? Maybe the arborist is more like some high-end consultant that you hire when things go wrong.

I wouldn't call myself an expert arborist, but I cut the firewood that provides all my heat in the winter. The safety features (mainly the goofy guard they put on the end of the bar) are good if you're a homeowner cutting some shrubs a couple times a year, but you have to take that off to drop a tree or cut pieces wider than your bar, so they aren't practical for serious work.

Fortunately, a chainsaw isn't a very dangerous tool, since it stops as soon as you release the trigger. The danger in dropping trees is from the tree itself: having one fall the wrong way or crack loose at the base before you expect it. I don't drop anything large when I'm working by myself, for that reason. I've been mildly injured by some surprisingly small trees, when something happened to bounce where I wasn't expecting.

> There’s a big ego hit, in LARPing a highly-experienced engineer, when you’re not one, yourself.

There's a big ego hit in punching up, down, and sideways, and it's far too popular among engineers these days.

I wish that engineers overall were more humble with each other, but it's not going to change quickly. And regrettably it is the human condition. Humility is also unprofitable.

Having grown up in a rural environment and nearly having my own catastrophic accident while using a circular saw with all of its safety features intact and myself being in an alert and mindful state, I can only describe the scenario you've outlined as, "typical idiot-class behavior".

You see this kind of stuff amongst the petty-criminal working class who chain smoke and binge drink and steal tools off the work site and complain about never being able to get ahead. I've had numerous uncles and neighbors who have life-long debilitating injuries because they showed up to work drunk and fell of a ladder or dropped a running chainsaw on their foot. Every single one of them thought they were a bad ass who "knew what they were doing".

My own accident occurred because I was over-using the tool. I did not have the best tool for the job. The tool was generally appropriate, but I also didn't have the best work space set up for it. The work space wasn't uncomfortable, but I didn't give myself room for error. I thought I had all of the safety features in place and was "being extra careful" while I used it at an awkward angle. Then, halfway through the cut, I noticed the off-cut drooping and knew it was going to damage the piece I was cutting if it dropped too far. I reached to support the droop with my off-hand, which given my angle meant I had to cross under my arm pushing the tool. In a moment I still don't completely understand, the path I sent my hand on did not go directly towards my armpit as I knew I would need to do to keep clear of the tool and instead went under the saw directly. I ended up touching the running saw blade sticking out of the bottom of the piece I was cutting.

A half-dozen different things could have been done differently to avoid the mistake, any one of which is not all that dangerous in isolation, but combined created an incredibly narrow error envelope.

What I didn't consider is that "being extra careful" can change in an instant. One little bump in balance, one little fleeting distraction, one little change of thought as you are mid-task and don't immediately stop to re-evaluate and you blow right on out of your after envelope.

Luckily, I only cut the tips of two fingers. I was able to get them stitched up and they have healed almost completely (there is some thick scar tissue right where my fingers hit keys in my keyboard that serves as a daily reminder).

You don't see this behavior amongst the professionals in the trades who successfully build their businesses from the ground up. Professionals over design their safety envelope. And they still occasionally get hurt. Just not as catastrophicly so.

> If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.

I've never seen an expert arborist remove any safety feature from a chainsaw and they'd be off site in a heartbeat if they did.

You're imagining a scenario to support your opinion, no basis in fact.

In Argentina, a well known case (well known within the industry) of fatal radioactive poisoning from an experimental nuclear reactor happened because an extremely experienced and well regarded operator was used to disabling safety measures of the reactor to speed things up. After all, he understood it perfectly and knew what was and wasn't actually safe to do.

Until he made a mistake, got a dose of radiation (he may have splashed himself with water, actually), and he instantly knew he was dead. And he was, within days, if my memory serves.

Experts make the dumbest mistakes because they are sure safety doesn't apply to them, because they know better.

And what do their insurance companies think about this?

And if they cut their hands off as an independent worker, the only person who gets hurt will be themselves.

But I bet if they start a business and have employees they will have rules against removing safeties and fire anyone who gets caught because now they have to worry about insurance premiums, lawsuits, and their business going under.

race car drivers are the exact opposite of what you are describing and they compete in a sport where every gram matters.

That is about right. The backlog is what makes money in general.

You want the top 5% not working on the backlog because that means if something urgent comes up you don't feel bad about asking them to switch tasks. If a junior needs help they are not interupting anything imbortant to ask. and it means you are making the 5-10% your leads and thus growing them into future top 5%.

that the top 5% often discover things that make money you didn't expect is a bonus.

Even the top engineers don’t have total freedom to choose what they work on. The work has to contribute to the business. I’ve seen valued engineers go off on tangents that don’t produce anything useful, which after time gets noticed and they are no longer considered one of the top engineers at the company. Worst case, the company needs to do layoffs and they look at what everyone has been contributing. They realize the engineer off working on their own thing could be removed without impacting operations at all, and that they have become detached from core business operations. So they are laid off and, honestly, nothing changes.

Everyone has to work on things that are in the company’s backlog of needs. The more status you have, the earlier you can be involved in shaping that backlog. But the backlog always comes down to what the business needs.

I feel like there’s a cultural difference between people in this thread. I’ve lived and worked in 3 different countries and I can say that in one , you absolutely don’t need to tell anyone that it’s ok to break rules sometimes. They’ll do that without your advice, you can be sure of that! In others, only a small percentage of people will, specially when they are inexperienced and fear the consequences more than would be warranted in reality. Perhaps that’s the biggest culture difference I’ve noticed.

The key is goodness/badness of advice is a function of the receiver. The internet doesn't give you control over who reads your stuff, so internet advice is safer and less useful than it could be.

The advice "use 'any' if it's too much work to type" is dangerous/bad advice for some developers because they don't have a well tuned definition of 'too much work', and they might not have all the tricks in the toolbox for every situation.

But legacy code or poorly typed libs can be an infinity time suck, and the most pragmatic approach might be to cut your losses, slap an 'any' on it and move on.

A great mentor gives the best (different axis than good/bad or safe/danger) advice for an individual in a specific situation.

As an engineering manager ... please don't "knowingly" break the rules. It makes my job so much harder. Just break them and apologize. And try to break a different one every time; this is the one thing to be inconsistent on.

Also, I never said this; I disavow all knowledge of writing this message. I am probably drunk and queued this message to be sent during working hours as a prank to myself.

A lot of it is quite debatable if not outright wrong.

Imagine you find yourself going into a meeting with no strong opinion on whether the new queue should be implemented with Kafka, Redis, or your existing SQL DB, and only average time pressure. The possible solutions here, in order of worst to best, are:

- equivocating until your manager picks the worst one

- picking one and not telling anyone you're unsure

- picking one and mentioning it might not be optimal but you think it'll work and we need to pick something

- cancelling the meeting midway through once you realise you don't know because you didn't do your homework

- moving the meeting to tomorrow three hours before it starts so you can do your homework

- turning up to the meeting having already picked one, with a reasonable understanding of the trade-offs and a quick write-up for everyone to review (bonus points if you sent it around beforehand, and if you're able to change your mind in response to valid criticism)

If you don't know the answer, that's a problem, and you should go work it out. If you are in a meeting to decide something that's not important, that's a problem, and you should cancel it and give everyone their time back (and also, how do you know it's not important?).

Yes. Letting the young ones drive because they seem confident is a recipe for disaster over the long haul.

Since I've taken a recent foray into management I'm also inclined to disagree slightly with the article. In big tech I see a lot of managers as people who's main goal is climbing the corporate ladder and therefore don't want to make waves. If you're more concerned about your reputation than doing your job it'll affect your openness. This isn't limited to tech, it's just the corporate ladder. Engineers are treated more like children than idiots, but I think that distinction is minor.