All of this advice here is ok as long as you work in a functional organisation. However it should be used strategically, sparingly and only when you have gained the trust of your superiors.
If you work in a dysfunctional organisation I would advise against ever using any of this advice. Any of this advice can be and in some circumstances is, used to discredit you, even if the outcome was successful. In a dysfunctional organisation you should concentrate on protecting yourself.
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've read some other posts on there. I agree the advice is dubious. There is a bunch of caveats to everything and he doesn't make it clear what caveats are.
I know what those caveats are. However if you are more inexperienced you don't know what those are.
As Kosh said, once the avalanche has started, the pebbles don’t have a vote. Unless you are high up in the organization, you can’t change a dysfunctional organization.
It’s best to just leave.
Hell as the most recent CEOs of Intel have found, even if you are high up in the org, you often can’t change a dysfunctional organization.
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.
> 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.
Breaking the rules Silently/Defiantly is being a diva and that is no good.
I've had to inform superiors that I disobeyed their instructions to get something done, I had a good reason for doing so (it wasn't at a whim). You should do this sparingly and only when you established that you are competent enough to make that call.
Sometimes you do need to push back hard against people. I've had to call co-workers and have an unpleasant conversation because repeatedly didn't even check something compiled. I was fed up with it and my superiors had done nothing, it was stopping me from getting my work done.
> 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.
I've found that even in "(more) functional organisations" cultural or communication norms are typically broken or preformative.
e.g. I worked in one org where there were things obviously broken on a website and no bugs were raised because "there wasn't a requirement for it". Now I could have raised it. I felt like they should of immediately raised it, because it was so obvious (it wasn't the first time either). I deliberately left it an entire fortnight on the site to see if any of the QA raised it. Nobody did. I then used this an example to highlight the fact that people weren't thinking. It was a various the old "teacher leaves a deliberate mistake in to see if the students are paying attention". I shouldn't have to resort to high school teacher tactics.
Sometimes you have to be very disagreeable for people to take notice.
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.
> The two worse pieces of advice in the article are breaking the rules and making your own decisions on what to work on.
If you read some of his other pieces that are linked. There is other dubious advice and analysis on that blog.
> 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.
Yes I agree. There are rules that cannot be broken in the organisation. It is highly dependant on industry and the size of the business.
I think there are times when you need to break the rules to get stuff done e.g. Self approving a PRs to get something working when someone else isn't around / available on a non-prod environment. I categorise that as a "bit naughty". I am assuming that is what they mean, but the haven't made that clear if that is the case.
> 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.
I have got hosed by acting like a maverick. You learn quickly you can't behave like that.
> 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.
I work in a small org. I will at least talk to my superior if I am going to implement something that hasn't been agreed or take a significant detour.
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?
The further away one gets from the technical side the more one is operating with imperfect information. Even if you're technical yourself you can't oversee everything so you look for rules that you can impose to try to guide things without having to micromanage.
If every function could be reduced to rules, however, life would be a lot simpler than it is. Rule makers need to understand why people have to do X or Y before banning or forcing some behaviour and I think this is where rules go wrong - the people that make them aren't the ones necessarily having to live by them.
I've been a manager and I know of no way to deal with this other than to make time for development myself and see where the problems are. I think one shouldn't really be making rules for things one isn't doing oneself - if you are then you're going too low level.
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.
Most businesses don’t need rockstar ninja developers. They just need professionals who give a damn. That doesn’t mean have “passion” and work 60 hours a week or filter based on people who can reverse a binary tree on the whiteboard.
Ordinary enterprise CRUD “senior” developers don’t cost that much especially if you hire remotely.
No offense to enterprise devs intended. That’s what most developers are who work in the US as was I for the first 25 years of my career.
My problem, when I was hiring for my company about year ago, was with not having the money to get people like that. This was in the UK of course and this year the employers seem to have a big advantage thanks to world events.
If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.
Every now and then, there’s a nasty accident, but most of them respect their tools, and just make a lot of money (which you’ll understand, if you’ve ever hired one).
Same goes for pretty much any vocation.
That said, manufacturers have learned that there’s a lot of money to be made, selling professional tools, to insecure fools with money.
There’s a big ego hit, in LARPing a highly-experienced engineer, when you’re not one, yourself.
> 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.
I think that falls into the "did not correctly assess the risk beforehand" bucket (and as you say and as the post I was replying to said, this is quite common). If they had correctly assessed "this is going to be really awful if it happens such that want to rule out even an unlikely possibility of it" they ought to not want to do it the first time.
In this definition I think virtually no one assesses the risk correctly. It is a human nature to overreact (post-factum) to an unlikely event to the extent that most languages have a dedicated saying ("having burned yourself on hot milk, one now blows on water" is the non-English version I heard as a kid).
No offense intended, but I also yours is not a good definition of "correctly assessing the risk". If it were followed, an extremely unlikely possibility of a horrible outcome would stop people from doing most optional things. For example, a risk of a horrible disease while on travel will lead to no travel.
Personalities differ and there are daredevils and scaredy cats that differ in pre-event risk assessments, but post (unlikely and traumatic) event assessment change is pretty universal. My 2c.
Correctly assessing the risk doesn't mean "I don't do anything that has an unlikely possibility of a horrible outcome", it can mean "I decide that I'm OK with that possibility and do it anyway, because I think the benefits outweigh the possible drawbacks". If you then do get unlucky and catch a nasty disease, that should not change your post-recovery decisions about going on holiday a second time: your risk/reward tradeoff should still be "I'm OK with the possibility of a bad outcome".
Re "It is a human nature to overreact (post-factum) to an unlikely event" -- yes, absolutely agreed. This is what I mean by saying that humans as a species are terrible at assessing low-probability risks. That most people change their view just means that most people both underestimate the likelihood of low probability events that haven't happened to anybody they know, and overestimate the likelihood of low probability events that have happened to somebody they know.
Agreed on both the definition of the optimal assessment and on the fact that the humans are bad at it. I actually think this (humans being bad at it) is good for the civilization as it helps people try things they would be too scared to do if they properly assessed all the potential outcomes with their probabilities.
A couple of years ago we bought a 50-year-old-house and gutted it. We had professionals do the stuff that required expertise or a lot of time / skills (electricians, plumbers, plasterers, etc), and did most other things ourselves.
At some point I'd come in to do something within my remit while the electricians were here. I'd put in earplugs to do some masonry drilling, because I've only got one set of ears and I'd like to be able to hear things when I'm 80. One of the electrician's assistants, probably in his late 20's commented on it, something like, "Got your ear condoms on, huh?" I'm at a stage in my life where I don't really care about that sort of thing, so just blew it off.
A few months later, that same guy came in to do the final wiring on something. He'd lost the end of his thumb -- had an accident with some tool or other and cut it off.
It's hard for me not to think that his attitude toward earplugs and his accident were related. Nobody deserves to be maimed for life, but we live in a universe which can be pretty unforgiving.
In my experience, the people who make unsolicited comments about others’ risk mitigations have incorrectly learned that safety precautions indicate weakness or inexperience, when experience teaches the opposite.
Seasoned professionals know that tools and environments don’t care about your skill level. A tool will injure anyone who doesn’t respect its inherent dangers.
The mockery typically comes from those who’ve either been lucky so far or selectively absorbed workplace cultures that prioritize appearing tough over staying whole.
On the other hand, there's the people who make a big song and dance ritual over putting their eye and ear pro on just to impact off one bolt that'll be maybe a couple clacks of the hammer. It's not realistic to do that for every single transient noise or tap on something, the safety is just performative at that point.
I have no problem letting those people and behaviors be ridiculed.
If I'm not directly impacted by someones' use of PPE, then that's their business even if I think it is an overreaction or performative. I've injured myself while doing "simple" operations before when a bolt or screw unexpectedly failed, so it may not be as performative as it appears.
On the other hand, if I'm working with someone in a professional capacity and they are delaying our work because they are acting in an anxious manner about safety, then I'll take time to talk through why I see their actions as counter-productive and then we can discuss how to be safe and efficient.
Yup. One of my arborist friends was a bit reckless (very, very good, but I thought he took unnecessary risks). Whenever he would see me, he’d hold up his left hand, to show he still had all his fingers, because I’d always tell him he’d lose one.
Not sure which of us was in the wrong. He made very good money.
I remember some electricians, working on our lighting system, at work.
They worked on live (320 Volts) fixtures. Never bothered to kill the circuit breaker.
I’ve found that pro tools tend to look pretty scruffy, while amateur tools tend to look shiny.
I know that was supposed to be an insult, but it's actually true. I don't mind at all.
Not my wheelhouse. I'm just repeating what the electrician told me, verbally, about twenty years ago. I wasn't actually that interested, at the time, so it's expected that my memory of it is terrible.
There's all sorts of stuff I ain't qualified to write about, and I'm not embarrassed in the least, to say so. That's one of the reasons I hang out here.
I suspect that it was 277 volts. I'm pretty sure that's a thing. I'm sorta sure that he said 300-something, but, as was noted above, he may have been just using the most impressive number he could find, or he was talking about the tolerances of the switches. I'll bet that it came up, because we were discussing the budget he was charging my department, and I probably had a question about the stuff he was ordering. Otherwise, I don't see why it would have interested me. I've learned to leave contractors alone, while they work. The reason that I knew they were working on live wires, was because the lights turned on, as I was walking past, and there was a slight spark in the box he was tweaking.
I've repeatedly heard the anecdote (to the point that I suspect it's now data) that inexperienced users of chainsaws are terrified of them, experienced users are comfortable with them, and very experienced users are even more terrified of them.
I've heard this of driving: that very novice drivers are terrified and extra careful, as you gain confidence you lose your fear and make dangerous mistakes, and when you're truly experienced the rate of accidents decreases again.
Don't know if it's true.
I can say I know cases of extremely good people committing very dangerous mistakes due to disabling safety checks, thinking they don't apply to them...
I throw these sort of quips the internet love into the same mental bucket (the trash can, tbh) as tabloid health advice.
Even if the general rule is right it likely comes with caveats that make it inferior to applying situation specific information or qualifiers that make it little better than chance or a coin toss.
Opinions like yours are wildly popular on the white collar internet because they "feel good" to people who are far removed from actual danger and productivity. But if you go to a part of the internet where many are self employed such naïve and un-nuanced opinions will be laughed at and ridiculed because they completely ignore the benefit side of the equation.
We all only get so much time on this earth and on some level quality and quantity are fungible, if inefficiently and imprecisely with some element of chance.
How much is a life worth? What's a finger worth? What's a crippling accident worth? And so on and so on. Once you define these terms numbers can be crunched and it can be determined whether you are right or wrong in any given case, and I assure you, there will be cases where your attitude computes so poorly it is farcical.
Is the retired carpenter with 10 fingers really better off than the one with 7? Sure the guy with 7 wished he'd not made that foolish mistake but the lifetime productivity gains of habitually moving fast likely show in his quality of life.
More complex benefit calculations simply make the problem more complex, but they do not change the fundamental nature of the tradeoff.
Depending on what an injury is worth, the compensation structure, etc, etc, it may very well be the right decision to disable all the safeties on everything and work fast for 10yr before losing a finger and moving on to something else because the faster man can command the higher labor rate, etc, etc.
Likewise, often times it's more valuable to write crap software in a week that solves a transient need for a year rather than spending 7mo spec'ing out and developing the arc of the goddamn covenant. Yeah it might shit all over your production database but if you're smart about the details it won't be much more likely to do that than "good" software and you can be on to the next value producing task.
Unfortunately, this is pretty much exactly the view of many pros. Time is money, and they will shave off things that may cost time (sometimes, that's Quality).
I mentioned that they removed the safety guards, but I never said it was good. Myself, I would not do that. I enjoy having some of the safety features that modern languages offer. I can work very quickly, indeed. I probably work faster (and safer) than I ever did, because of this.
A big danger of seasoned pros, is that they get casual with extremely dangerous things, and remove the safety stops, in order to accelerate their workflow.
One day, they are too casual, and you end up with a smoking pair of shoes on the floor.
But at the end of the day it's all just a N-way tradeoff between body parts/health outcomes, time and money, and god knows whatever other factors you seek to define.
Nobody blinks an eye when you say you're making a financial gamble and if it pays off you'll be able to retire young enough to enjoy it.
But everyone loses their minds if you're putting up your health instead of dollars, as if those aren't fungible.
Take for example (and this is a literal example from my friend group, not hypothetical) a man in the metal fabrication business. On day one he can either buy the "cheap and unsafe" old flywheel press brake or he can take out a loan for the modern hydraulic equivalent that is much safer, but also 3-5x slower depending on what you're using it for. That's a lot of money in his pocket over time. He never lost a finger in 30yr and ultimately sold out. Now, his lungs aren't great. But if he'd been slaving away at a hydraulic press all those years he'd never have had to either take a much smaller cash out or wait so long that he couldn't enjoy the retirement.
Now, obviously there's not a direct tradeoff between disabling guards or "unsafe choices" and productivity, and there's not a direct tradeoff between "safe choices" and health outcomes. And you can always make good or bade tradeoffs. What's a good tradeoff for the self employed 40yo isn't necessarily smart for the wage laborer at 20, or the business owner who is responsible for the wage laborers.
And at the end of the day it's all safety choices to some extend, but those safety choices are also time and money choices. Do you chock your forklift every time or do you trust the parking brake? It's really easy to sit there and say chock it every time but the nickels and dimes add up, but on the flip side of that coin the health and safety risk exposure adds up too[1].
These tradeoffs are all inter-related and the people saying to "do all the safety all the time" are just as stupid as the people saying you can run a cutting torch naked.
[1] if anyone wants to make a low effort quip about the step stool and utility knife being the most dangerous tools in the shop now's your chance.
This is not what the word "fungible" means. Not at all. Dollars are fungible. You can replace any $1 bill with any other and it doesn't matter. Calling trading X for Y where calculations of comparable value have to occur is exactly the opposite of fungible.
You’re over complicating things because you have no idea what you’re talking about.
At every worksite, the equation is: how much will the company lose in lost productivity and workman’s comp if someone is injured. And the equation goes in favor of safety every time.
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.
I guess the equivalent would be compiling rm without the '--no-preserve-root' option?
Realistically I know a professional arborist. Not only does he have all the safety equipment on his saws, all his crews have full PPE available and use it. The only piece of safety equipment I've ever seen that was dubious is the "sawstop" for table saws, primarily because it false triggers so often.
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.
You have bad catastrophe management if deleting a database causes issues. I've seen databases accidentally deleted in production ... we just restored from a backup losing only a few ms of writes.
This stuff happens; sure it causes downtime, but it shouldn't have any real ramifications.
This doesn't account for safety critical systems or databases containing highly personal information or those in highly regulated industries. The software engineer might walk away with their limbs but others will fall to suicide or life changing financial circumstances.
I can't help but think of the software engineers who followed exactly what their Volkswagen bosses were instructing and are now in prison.
>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.
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.
Agree. I am really surprised this posters opinion or the linked article is anywhere on the radar of professionals. There is a time and a place for everything. Maybe in an emergency it makes sense to get write access to a prod DB but even as a “professional” I want a second pair of eyes with me or have a backup ready to go.
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.
If you’re regularly cutting pieces of wood wider than your bar, for god’s sake invest in a bigger saw. It will serve you better in many ways, safety included.
> 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.
> 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.
This is a great summary.
Your best-laid plans (with power tools, motor vehicles, gravity, etc) can be completely invalidated with a single twitch (possibly not even your own). If you're operating at the margins of safety, there is no room for that.
And it takes experience to know where you are on the safety spectrum! But even that is sometimes inadequate.
For example, I love my radial arm saw. It's my favorite tool for cross-cutting wood. It's an old Craftsman, from the 1970s or so. I bought it from a furniture manufacturer who used it as an infrequently-used backup tool for ad hoc manual fixups, since new (they had big industrial machines for ordinary manufacturing operations). It was very close to new spec when I bought it, but I've tuned it back to perfect. All of the safety guards (the minimal ones that existed in the 1970s) except the dust hood were removed before I bought it.
Anyway, I love it. But they don't really sell RAS's at the consumer level any more, because people hurt themselves with them too frequently. Table saws are also quite dangerous, apparently. Circular saws are supposed to be the safest option, even more so than miter saws.
So I have a lot of experience with all of these tools, and with my RAS specifically. I think I know where I am on the safety spectrum, which I believe to be acceptably safe. But the statistics say otherwise, and one of us must be wrong. I don't think it's me, and my ten fingers attest to that belief.
Right? Or maybe wrong! I think about this every single time I use the RAS, which is probably a good thing. I guess we'll see.
I think a lot of the problem with power saws of all kinds is that each one looks nearly identical to the others, but they each are best for specific uses with only a small amount of overlap. Short cross cuts on a table saw are not as safe as using a radial arm saw or circular saw. Long rip cuts with a circular saw are not as safe (or convenient or repeatably precise) as a table saw. But a naive interpretation sees "blade goes around" and thinks "with a little effort, this one tool can do all of this." And, as a hobbiest or on-site worker, you may not have the room for all of those tools. So, you try to make do, and 99 times out of 100 it's fine, maybe not satisfying, but fine. You cut a little over, clean up the edge with other tools, generally just compensate for the shortcomings.
But 1% issues come up a lot when you're working a lot. I'm in the middle of the most complex project I've ever undertaken, a queen-sized bed frame. I'm about $1000 in on wood and $500 in on new tools. All told, ignoring my time (which is fair because this is also an entertainment activity for me), I'll end up saving at least $8500 over similar designs one could buy from a craft woodshop. And it won't fall apart in 5 years like a $1500 bed frame would.
My design doesn't have a lot of complex cuts, but it does have a lot of cuts total. And where I cut myself was in trying to "save money" and build a jig for something that was really only $100 for a new tool. To try to save about 1% of my "profit", I added immeasurable danger. Even with insurance, my urgent care visit was about $250 and recovery took long enough that it threw me out of the flow of getting the project done. I'm almost done now, nearly a year after starting, but only just restarted 3 weeks ago.
Every project is a series of decisions. I started off deciding I didn't want to buy a bed frame because the frames that fit my budget are junk. Once that decision was made, I should have trusted it and stopped trying to readjudicate cost, especially at such a small level.
I do a lot more with hand tools now. I'm not a production wood worker. If the project takes twice as long, it's not bread off my table. But errors in using hand tools are far less likely to end in literal catastrophy. And it really doesn't actually take twice as long. Maybe 25% longer. And it's an order of magnitude cheaper for the tools. And they fit in my basement shop better. Which is probably why you actually see quite a few "hand-tool only" production wood workers in the real world.
I would imagine the spark arrestor is the first and least dangerous 'feature' to be removed by regular chainsaw users.
It's a small oblong of fine stainless steel mesh that sits at the exhaust, prevents any large hot particles escaping, but also gradually impedes the operation of the motor.
It can clog up fairly quickly, especially if you run a slightly higher oil:petrol ratio, which you may have very sensible reasons for doing.
And because it's bothersome to remove (especially when the engine is hot) and clean (you need a toothbrush, some petrol, a small container, etc) or replace (you need to carry a spare, and different models have different sizes) - a lot of people just remove it.
None of my chainsaws still have theirs, f.e. It's a calculated risk, but I'm very careful with where and when I use a chainsaw, and also cautious about monitoring fire risks.
Interesting, I've never thought of the spark arrestor as a safety feature. I guess theoretically it prevents starting a fire in dry conditions, which is a good thing.
My chainsaws came with two safety features: the kick guard (or handguard) and a tip protector. For those who don't know, the kick guard sits above your forward hand and stops the chain immediately if you push it forward. If the tip of your chain catches a log juuust right, and you aren't holding the saw firmly with both hands, it can "kick" the chain up towards your face. If that happens, the kick guard will hit your hand and stop the chain. You take a deep breath, pull the kick guard back to release the chain, and keep working. I don't know why anyone would remove it, or if it's even possible for my saws to run without it.
The tip protector is intended to prevent kickback at all, by keeping the tip of the bar from contacting anything in the first place. That's fine if you're cutting stuff a few inches across, but it makes cutting large stuff impossible and even small stuff inconvenient. Kickback doesn't happen often, very rarely if you're careful, and the kick guard handles it, so I've never seen anyone cut with a tip protector. But if you're new to using a chainsaw, it's probably not a bad idea to keep it on.
Your electric chain saw weighs a ton for its power output and run time. You'd feel differently if you had to schlep it into the top of a tree all the time.
I have an electric chain saw. It overlaps in use with small, but not arborist small, gas saws and excels at some things they don't. While they can all do each other's jobs if you're ok with it being slower/not ideal it's very much a complimentary tool.
Where it really excels over gas saws is highly intermittent use, reduced maintenance and increased situational awareness (i.e. you can do stupid things more safely).
You must not be using professional saws then. An electric version of a professional Husqvarna or Stihl (only as an example) with the battery weigh the same as a gas version with gas and oil in the tank.
I would argue it’s even more obvious that you have not used one or at least in a professional capacity as you are still looking at 90-100dB running an electric chainsaw.
> with the battery weigh the same as a gas version with gas and oil in the tank.
I still marvel that the liquid I call 'petrol', is called a gas in some parts of the world.
In one of the bigger models, say the Stihl 66x series, there's 825ml of petrol, and 825ml of oil (let's call that 1.5kg) that isn't there by the end of your half hour. Whether that's meaningful I guess comes down to fitness / strength.
As sibling commenter noted, electric chainsaws are hugely compelling for intermittent / infrequent use. Here in AU the pricing isn't compelling yet, though.
While my day job is not an arborist I deal in logs and tree felling for one of my side gigs.
The weight is comparable but the electric saw has less speed/power than the same weight gas saw the battery capacity for a given amount of work output costs you a lot of weight. A gatorade bottle of gas shoved in my pocket weighs a lot less than a 40v battery.
Don't get me wrong, electric saws are great, but I wouldn't want to bring one into a tree. The couple times I've had to climb a tree I've used an electric saw but it is because I value the other factors despite the performance hit.
The difference between gas and electric is being able to hear your buddy yell at you when you're running the saw. While this is not necessarily useful for felling a singular perfect tree in the middle of a field as you crank up the complexity and/or stupidity of the situation in which you are working it becomes more valuable. If an electric saw cracks 100db it's only just barely, gas is categorically louder and everyone who's used both one knows it.
I own a wide variety of mid size saws in both homeowner and "pro" at this point, pretty much all bought used. While power and features vary I mostly discriminate based on chain/bar condition and running condition, they all do the job well enough. I have one tiny saw and huge saw that I only own in "chinese clone of a real brand" quality so I can't compare to high end saws in those classes. Chainsaws are fairly maintenance intensive high strung power equipment and electric is just easier, even if it's heavier. Homeowners who only need to maintain their property and may only run a chainsaw 1-2x per yea would be well advised to get a 40+ volt electric saw of whatever brand makes the most sense in the context of their other tool needs.
The pros I know have lift trucks and so don't schlep it up trees. I've seen videos of tree climbing, that looks too dangerious for me anyway. (And most pros agree)
i'm not a pro. for me there is no gas adveantage. I don't have the stamina to run a saw all day anyway.
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 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.
I disagree with the original poster about arborists, but I don’t think racing is a better example. Racing is a sport with rules (limitations) specifically designed to promote some type of fair competition. It is a game designed around wanting to drive cars really fast, it looks nothing like “getting a task done as fast/easily as possible.”
If the goal was just to get from point A to point B as fast as possible without and constraints, I guess they would launch the guy out of a cannon or something.
If the goal was to do something useful, like move a lot of people/stuff from one point to another, we’d end up looking at solutions that look nothing like a race car; public transit, stuff like that.
One, is that line about LARPing. I think that's what's really gotten folks upset, and rightly so. I sincerely apologize. It came across as snide. It was a poor choice of words.
The other, is that I gave the impression that I approved of the practice of removing safety gear. It was an observation; not an approval. I've watched "cowboy" arborists at work, and find it terrifying (and, TBH, impressive, as well). I think they are accidents waiting to happen.
But it still goes on, in many industries, including software development. Another poster talked about the calculations that people make, taking risks, in order to move faster. Their post seemed unpopular, but they were absolutely correct.
A big problem with experienced folks demonstrating reckless behavior, is that it gets aped by folks that may not be able to manage things safely, and that's where the real danger lies.
One thing specifically about arborists—it is a sort of weird job, right? Homeowners can handle most normal trees. The arborist’s job is specifically to handle troublesome trees in weird environments. The problems look similar to ones that homeowners have, but they are more difficult (because nobody calls in the tree guys for an easy tree, right?). So I wouldn’t be surprised if they are uniquely prone to some extent, to wanting consumer gear with (some specific) guardrails removed, or used in creative ways.
By the numbers, I suspect the vast majority of trees that get chopped down get chopped down by loggers in specialized environments, with hyper-specialized equipment (that looks nothing like modified consumer gear). I suspect most engineers think of themselves as more like the loggers: cultivating that environment is a big part of it, and their tools are just different from consumer ones. If riskier, only because bigger moving parts involve greater energies.
Race cars have special rules - safety equipment in general does not count against some track limits so winners are looking for ways to hide something that makes them go faster in safety equipment. Every gram matters but there are things that matter more than grams.
This is good advice for workers trying to thrive in dysfunctional organizations, but these are the kinds of people who cause the company to become dysfunctional in the first place, by only doing work that causes them to get ahead, instead of what is right for the company. And I'm not referring just to line workers here, but management too. Incentives are there to point people in the right general direction, not to give license to abandon your ethics and sense of craftsmanship. An alternative to pursuing incentives to the point of abandoning your principles might be to go to a better company, or even starting your own.
Reading this as a pilot, this thing reads like a primer for How Not To Think.
The author might think they're being a meta-pirate by saying "oh these are all possible actions proscribed by most organizations" implying that the proscription itself is a sign of ossified incompetence, instead of identifying the underlying one-true-savior fallacy that underpins it all.
The general danger here is human error. The point of leveraging a collaborative environment is to design process to detect and remediate human error before it radiates outward into more cost. The farther it goes, generally, the higher the cost, non-linearly. It shouldn't be "never do this", but instead "if you're going to do this use every tool at your disposal to make sure it's done correctly." Siloing the entire decision tree to yourself is exactly how not to do it.
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.
Yes, but... as the author already pointed out, this only works if you know what you are doing, i.e. having all the required mental resources, i.e. knowledge, experience, intelligence, courage, intuition, and some more.
There are some engineers who know what they are doing and why.
And there are many others who don't.
Nevertheless, heartily tremendous thanks and greetings to the author, very very much appreciated.
I'm a senior of 35 yrs active software dev, half employed, half self-employed, in many different environments.
I can tell from my own experience and daily work life, yes, "this is the way" (quoting from The Mandalorian).
There’s a magic component to rule breaking that a lot of online advice doesn’t usually talk about: You have to actually be right. Your ideas have to be good. Companies don’t want everyone breaking the rules because a lot of devs don’t have the engineering skill to back it up.
So if you start operating as a rogue agent then make sure you are good. Tom Cruise (stuntman and actor) had a quote I love- “Don’t be careful. Be competant.”
I don't feel the need to give dangerous advice. As an educator that has to do with the stuff people build more or less unsupervised I can assure you that dangerous is the defacto default starting point for anybody who has no idea what they are doing.
There is only a very specific class of person, who is often overcautious and perfectionist to a degree that they won't even get started. They might need some advice that eases their worries. But the dangers are real. Overcomplexity is also a danger.
Most of the "dangerous advice" I have encountered as an engineer (be it electrical or software) I have seen in the form of legacy projects without anybody there to explain them to me. There you can see where corners where cut, where they were completely out of their depth, etc.
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.
Sure, FYI I am teaching Germany. Not exactly known to be a country of rule breakers, in fact more like the opposite. But rules that you don't know are easy to break.
E.g. beginners with electrical wiring may or may not know what is up to code and what isn't and thus violate said code without knowing it.
To know when certain rules can be bent or broken usually requires a deep understanding for why the rules exist and what they are meant to prevent. Beginners do not have that knowledge and thus I'd hessitate to give any general advice to skip rules to them, unless it is extremely specific and tied to one specific situation.
Usually the more useful advice to beginners is when to ignore conventions and how everybody is doing it and when to just use the boring stuff.
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.
> Deliberately break written company rules sometimes
I love this. It’s so true. Rules are written for indemnity, but nobody will blame you for not remembering every one of the 216 rules the company has as of this moment (217 tomorrow).
And they’ll love you for fixing the problem now, instead of waiting for the two week review cycle to finish. That is assuming you don’t break shit, but even then it’s a matter of ‘sorry’ in all but the most egregious cases.
> Rules exist to constrain engineers with bad judgment, not to bind the ones with good judgment
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.
Of course you don’t knowingly break the rules. How can you possibly suggest it’s deliberate. I just can’t keep the full list of company rules in my mind at all times, and things slip through the cracks. Things slip through the cracks a lot more if it’ll make my chain of command happy though.
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?).
Software engineering career advise is a minefield. Contexts vary so wildly that
the best advise probably is more like a case study into personal experiences and
how one navigated various delicate/intricate issues.
I for one have two part time jobs and one full time job. My primary challenge has
to do with triaging issues ahead of time so that I can draw up a comprehensive
plan for working on them ahead of time over the weekend so that I'd be in execution mode throughout the week - which is infinitely more productive - low context switching and more flow.
I also have a mini bottleneck with one company where I'm not given production access - not even readonly and only hear about issues later on from the lead developer. There are often things that I'd rather diagnose in a production env but no - policy dictates part time workers are not given that kinda access.
At the same company, I go to some of the websites we maintain and find somethings are broken and wonder - are these really used by real people or just bots.
We have about 2 mobile apps that do similar things and I'd love to push for a monorepo setup but I have to look around at the engineering culture and realize that a monorepo setup would do more harm than good because it requires a better calibre of engineers.
We have a nestjs codebase full of antipatterns that even I a newbie to nestjs can easily pinpoint and identify - but can't truly get them to consider a huge refactor. I see all manner of nasty rest api implementations that make data flow unintuitive but my leadership skills might be lacking.
I work at a "consulting" firm with a colleague that has issues delegating and primarily prefers import statements be arranged in a particular order. I hated working there because I felt arranging import statements were an insult to my time and abilities as a programmer - but the work pays the bills and I've to bide my time.
I've ranted enough. The bottom line is context varies much too wildly for any advise to be particularly useful beyond being a case study. I'd be more interested in the authors specific experiences than advise
Management isn’t one entity with one perspective so to some extent I can see why they might have competing interests and sometimes the ones who are “right” in terms of actually getting things done might lose. But,
> Another reason why is that managers will almost never give you dangerous advice, even if it’s what you need to hear. If a manager tells you to ignore company policy, and you do it wrong - for instance, if you post in Slack that you’re doing it and your manager said it was OK - then that’s bad for them. In fact, it’s much worse for them than it is for you. Tech company leadership often views engineers as useful idiots. Managers are expected to be professionals.
> However, lots of managers wish they could give you advice like this. They certainly appreciate it when you follow it. I’ve never been a manager, but it must be incredibly frustrating to manage strong engineers who would be much more effective if they approached work a little more tactically (and a little less according to the written job description).
This advice and circumstance basically sucks, right? Ultimately management (as a whole) is responsible for coming up with policies that don’t get in the way of productivity. Making policy and taking responsibility for when it doesn’t work out: that is part of their job.
The advice here is to just let your manager have the upside of having a team that is more productive by following an alternative set of rules, without the downside of accepting additional risk. That’s just letting them not do part of their job. Everybody would love a consequence-free dodge of the shitty part of their job.
Advice like this introduces a dangerous blind spot: It assumes the engineer is always right and their peers and manager just don’t understand:
> It can be deeply alienating to know things don’t work the way they officially should, but to have nobody to talk about it with.
There are instances where this is true, obviously. One of my more frustrating job experiences was getting hired late into a startup where the founder had already hired their friends, who were not familiar with the domain, into all of the decision making roles. Being stuck in a workplace where the necessary knowledge is absent from upper ranks is very frustrating. As I learned, the real solution is to leave.
The problem that occurs with advice like this blog is that some engineering personality types will see it as affirmation that they are right and the business is wrong even if that may not be true. I can’t begin to count the number of engineers I’ve worked with who went off and chose to work on their own priorities or did some of the other techniques mentioned in this blog when they were not right. It causes a lot of problems for everyone and doesn’t help that person’s career at all.
Before you go out and use some of this strong-headed “dangerous advice” in blogs like this, do your best at the diplomatic approach. It sounds cool to become a “grifter” and work on your own things like this blog suggests, but you’ll get much farther if you simply become someone who is good to work with and trusted. Trust leads to more autonomy and freedom. Becoming a “grifter” and going your own way does not. And if you’re not right about your own decisions, you risk blowing a hole in your trust that can be hard to recover from.
> Tech company leadership often views engineers as useful idiots. Managers are expected to be professionals.
I'm not sure if this quote really adds value to the article. At best it's probably not true, especially if you avoid working at a "tech company". At worst, it's insisting on the false narrative of "class warfare" that only seems to be true when you're junior and still don't understand why nobody cares about you or wants to hold your hand.
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.
All of this advice here is ok as long as you work in a functional organisation. However it should be used strategically, sparingly and only when you have gained the trust of your superiors.
If you work in a dysfunctional organisation I would advise against ever using any of this advice. Any of this advice can be and in some circumstances is, used to discredit you, even if the outcome was successful. In a dysfunctional organisation you should concentrate on protecting yourself.
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've read some other posts on there. I agree the advice is dubious. There is a bunch of caveats to everything and he doesn't make it clear what caveats are.
I know what those caveats are. However if you are more inexperienced you don't know what those are.
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.
It is a Chesterton's fence type argument. You need to understand the rules, before you know which ones you can break and when you should break them.
> Plus every developer believes they're a special and insightful little petal so all the caveats will get ignored.
I don't believe that is true. I think there is a vocal minority of developers that would apply to.
As Kosh said, once the avalanche has started, the pebbles don’t have a vote. Unless you are high up in the organization, you can’t change a dysfunctional organization.
It’s best to just leave.
Hell as the most recent CEOs of Intel have found, even if you are high up in the org, you often can’t change a dysfunctional organization.
Nice quote, totally stealing this.
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.
> 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.
Breaking the rules Silently/Defiantly is being a diva and that is no good.
I've had to inform superiors that I disobeyed their instructions to get something done, I had a good reason for doing so (it wasn't at a whim). You should do this sparingly and only when you established that you are competent enough to make that call.
Sometimes you do need to push back hard against people. I've had to call co-workers and have an unpleasant conversation because repeatedly didn't even check something compiled. I was fed up with it and my superiors had done nothing, it was stopping me from getting my work done.
> 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.
I've found that even in "(more) functional organisations" cultural or communication norms are typically broken or preformative.
e.g. I worked in one org where there were things obviously broken on a website and no bugs were raised because "there wasn't a requirement for it". Now I could have raised it. I felt like they should of immediately raised it, because it was so obvious (it wasn't the first time either). I deliberately left it an entire fortnight on the site to see if any of the QA raised it. Nobody did. I then used this an example to highlight the fact that people weren't thinking. It was a various the old "teacher leaves a deliberate mistake in to see if the students are paying attention". I shouldn't have to resort to high school teacher tactics.
Sometimes you have to be very disagreeable for people to take notice.
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.
> The two worse pieces of advice in the article are breaking the rules and making your own decisions on what to work on.
If you read some of his other pieces that are linked. There is other dubious advice and analysis on that blog.
> 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.
Yes I agree. There are rules that cannot be broken in the organisation. It is highly dependant on industry and the size of the business.
I think there are times when you need to break the rules to get stuff done e.g. Self approving a PRs to get something working when someone else isn't around / available on a non-prod environment. I categorise that as a "bit naughty". I am assuming that is what they mean, but the haven't made that clear if that is the case.
> 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.
I have got hosed by acting like a maverick. You learn quickly you can't behave like that.
> 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.
I work in a small org. I will at least talk to my superior if I am going to implement something that hasn't been agreed or take a significant detour.
In my experience orgs need a mix of both rule followers and rule breakers to function.
I really like Dimitri Glazkov's "Sailors and Pirates" framing of this:
https://glazkov.com/2023/04/02/sailors-and-pirates/
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?
The further away one gets from the technical side the more one is operating with imperfect information. Even if you're technical yourself you can't oversee everything so you look for rules that you can impose to try to guide things without having to micromanage.
If every function could be reduced to rules, however, life would be a lot simpler than it is. Rule makers need to understand why people have to do X or Y before banning or forcing some behaviour and I think this is where rules go wrong - the people that make them aren't the ones necessarily having to live by them.
I've been a manager and I know of no way to deal with this other than to make time for development myself and see where the problems are. I think one shouldn't really be making rules for things one isn't doing oneself - if you are then you're going too low level.
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.
With unlimited budgets and American employment law perhaps .. or if you're in a startup and have the luxury of beginning from scratch.
Most businesses don’t need rockstar ninja developers. They just need professionals who give a damn. That doesn’t mean have “passion” and work 60 hours a week or filter based on people who can reverse a binary tree on the whiteboard.
Ordinary enterprise CRUD “senior” developers don’t cost that much especially if you hire remotely.
No offense to enterprise devs intended. That’s what most developers are who work in the US as was I for the first 25 years of my career.
My problem, when I was hiring for my company about year ago, was with not having the money to get people like that. This was in the UK of course and this year the employers seem to have a big advantage thanks to world events.
The right tool, for the right job.
If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.
Every now and then, there’s a nasty accident, but most of them respect their tools, and just make a lot of money (which you’ll understand, if you’ve ever hired one).
Same goes for pretty much any vocation.
That said, manufacturers have learned that there’s a lot of money to be made, selling professional tools, to insecure fools with money.
There’s a big ego hit, in LARPing a highly-experienced engineer, when you’re not one, yourself.
> 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.
It might alternatively be an indication that they can't properly assess the risk and the outcome afterwards....
(More likely both: we are as a species absolutely terrible about assessing low-probability risks.)
I've benefitted from modern "safe" languages.
I cut my teeth on things like Machine Code, ASM, and ANSI C.
I don't miss them, at all.
Nowadays, I write primarily in Swift, and I absolutely love not testing for leaks, anymore.
How does this support your original position? Now you're saying you want the guardrails, I don't get the point you're trying to make.
I think he's happily retired.
I enjoy the non safe parts and proving with code in production for decades it works... it is sort of like code golf.
however I use everytrick I tan to get memory safety when possible.
Yes, that is a valid point you make!
It can also mean they properly assessed the risk and got incredibly unlucky
In that case they would not change their mind, though.
Not necessarily. Having a painful accident often leads people to a position of "even if I know a mishap is very unlikely I am not doing this again".
I think that falls into the "did not correctly assess the risk beforehand" bucket (and as you say and as the post I was replying to said, this is quite common). If they had correctly assessed "this is going to be really awful if it happens such that want to rule out even an unlikely possibility of it" they ought to not want to do it the first time.
In this definition I think virtually no one assesses the risk correctly. It is a human nature to overreact (post-factum) to an unlikely event to the extent that most languages have a dedicated saying ("having burned yourself on hot milk, one now blows on water" is the non-English version I heard as a kid).
No offense intended, but I also yours is not a good definition of "correctly assessing the risk". If it were followed, an extremely unlikely possibility of a horrible outcome would stop people from doing most optional things. For example, a risk of a horrible disease while on travel will lead to no travel.
Personalities differ and there are daredevils and scaredy cats that differ in pre-event risk assessments, but post (unlikely and traumatic) event assessment change is pretty universal. My 2c.
Correctly assessing the risk doesn't mean "I don't do anything that has an unlikely possibility of a horrible outcome", it can mean "I decide that I'm OK with that possibility and do it anyway, because I think the benefits outweigh the possible drawbacks". If you then do get unlucky and catch a nasty disease, that should not change your post-recovery decisions about going on holiday a second time: your risk/reward tradeoff should still be "I'm OK with the possibility of a bad outcome".
Re "It is a human nature to overreact (post-factum) to an unlikely event" -- yes, absolutely agreed. This is what I mean by saying that humans as a species are terrible at assessing low-probability risks. That most people change their view just means that most people both underestimate the likelihood of low probability events that haven't happened to anybody they know, and overestimate the likelihood of low probability events that have happened to somebody they know.
Agreed on both the definition of the optimal assessment and on the fact that the humans are bad at it. I actually think this (humans being bad at it) is good for the civilization as it helps people try things they would be too scared to do if they properly assessed all the potential outcomes with their probabilities.
A couple of years ago we bought a 50-year-old-house and gutted it. We had professionals do the stuff that required expertise or a lot of time / skills (electricians, plumbers, plasterers, etc), and did most other things ourselves.
At some point I'd come in to do something within my remit while the electricians were here. I'd put in earplugs to do some masonry drilling, because I've only got one set of ears and I'd like to be able to hear things when I'm 80. One of the electrician's assistants, probably in his late 20's commented on it, something like, "Got your ear condoms on, huh?" I'm at a stage in my life where I don't really care about that sort of thing, so just blew it off.
A few months later, that same guy came in to do the final wiring on something. He'd lost the end of his thumb -- had an accident with some tool or other and cut it off.
It's hard for me not to think that his attitude toward earplugs and his accident were related. Nobody deserves to be maimed for life, but we live in a universe which can be pretty unforgiving.
Quite possibly.
In my experience, the people who make unsolicited comments about others’ risk mitigations have incorrectly learned that safety precautions indicate weakness or inexperience, when experience teaches the opposite.
Seasoned professionals know that tools and environments don’t care about your skill level. A tool will injure anyone who doesn’t respect its inherent dangers.
The mockery typically comes from those who’ve either been lucky so far or selectively absorbed workplace cultures that prioritize appearing tough over staying whole.
On the other hand, there's the people who make a big song and dance ritual over putting their eye and ear pro on just to impact off one bolt that'll be maybe a couple clacks of the hammer. It's not realistic to do that for every single transient noise or tap on something, the safety is just performative at that point.
I have no problem letting those people and behaviors be ridiculed.
If I'm not directly impacted by someones' use of PPE, then that's their business even if I think it is an overreaction or performative. I've injured myself while doing "simple" operations before when a bolt or screw unexpectedly failed, so it may not be as performative as it appears.
On the other hand, if I'm working with someone in a professional capacity and they are delaying our work because they are acting in an anxious manner about safety, then I'll take time to talk through why I see their actions as counter-productive and then we can discuss how to be safe and efficient.
“It was only a couple clacks of the hammer” will be a cold comfort if one of those clacks is the one that sends a fragment of metal into your eye.
Yup. One of my arborist friends was a bit reckless (very, very good, but I thought he took unnecessary risks). Whenever he would see me, he’d hold up his left hand, to show he still had all his fingers, because I’d always tell him he’d lose one.
Not sure which of us was in the wrong. He made very good money.
I remember some electricians, working on our lighting system, at work.
They worked on live (320 Volts) fixtures. Never bothered to kill the circuit breaker.
I’ve found that pro tools tend to look pretty scruffy, while amateur tools tend to look shiny.
320V circuit eh?
That’s what I was told.
Apparently, our building had a certain kind of wiring.
I was also told it was pretty common.
Might not be exactly 320, but it was over 300 (not 240).
I'm told it's common in many industrial/office buildings.
Probably 230v three phase, 230v RMS would be around 330v peak
Probably 230 and OP is not qualified to be speaking about it.
> OP is not qualified to be speaking about it
I know that was supposed to be an insult, but it's actually true. I don't mind at all.
Not my wheelhouse. I'm just repeating what the electrician told me, verbally, about twenty years ago. I wasn't actually that interested, at the time, so it's expected that my memory of it is terrible.
There's all sorts of stuff I ain't qualified to write about, and I'm not embarrassed in the least, to say so. That's one of the reasons I hang out here.
I suspect that it was 277 volts. I'm pretty sure that's a thing. I'm sorta sure that he said 300-something, but, as was noted above, he may have been just using the most impressive number he could find, or he was talking about the tolerances of the switches. I'll bet that it came up, because we were discussing the budget he was charging my department, and I probably had a question about the stuff he was ordering. Otherwise, I don't see why it would have interested me. I've learned to leave contractors alone, while they work. The reason that I knew they were working on live wires, was because the lights turned on, as I was walking past, and there was a slight spark in the box he was tweaking.
To paraphrase your comment, you're easily impressed by reckless behaviour and mistake it for expertise.
Listen, you didn't like the LARP comment, and you're right. I apologize.
Let's just bury the hatchet, eh?
I've repeatedly heard the anecdote (to the point that I suspect it's now data) that inexperienced users of chainsaws are terrified of them, experienced users are comfortable with them, and very experienced users are even more terrified of them.
I've heard this of driving: that very novice drivers are terrified and extra careful, as you gain confidence you lose your fear and make dangerous mistakes, and when you're truly experienced the rate of accidents decreases again.
Don't know if it's true.
I can say I know cases of extremely good people committing very dangerous mistakes due to disabling safety checks, thinking they don't apply to them...
I throw these sort of quips the internet love into the same mental bucket (the trash can, tbh) as tabloid health advice.
Even if the general rule is right it likely comes with caveats that make it inferior to applying situation specific information or qualifiers that make it little better than chance or a coin toss.
Opinions like yours are wildly popular on the white collar internet because they "feel good" to people who are far removed from actual danger and productivity. But if you go to a part of the internet where many are self employed such naïve and un-nuanced opinions will be laughed at and ridiculed because they completely ignore the benefit side of the equation.
We all only get so much time on this earth and on some level quality and quantity are fungible, if inefficiently and imprecisely with some element of chance.
How much is a life worth? What's a finger worth? What's a crippling accident worth? And so on and so on. Once you define these terms numbers can be crunched and it can be determined whether you are right or wrong in any given case, and I assure you, there will be cases where your attitude computes so poorly it is farcical.
Is the retired carpenter with 10 fingers really better off than the one with 7? Sure the guy with 7 wished he'd not made that foolish mistake but the lifetime productivity gains of habitually moving fast likely show in his quality of life.
More complex benefit calculations simply make the problem more complex, but they do not change the fundamental nature of the tradeoff.
Depending on what an injury is worth, the compensation structure, etc, etc, it may very well be the right decision to disable all the safeties on everything and work fast for 10yr before losing a finger and moving on to something else because the faster man can command the higher labor rate, etc, etc.
Likewise, often times it's more valuable to write crap software in a week that solves a transient need for a year rather than spending 7mo spec'ing out and developing the arc of the goddamn covenant. Yeah it might shit all over your production database but if you're smart about the details it won't be much more likely to do that than "good" software and you can be on to the next value producing task.
Unfortunately, this is pretty much exactly the view of many pros. Time is money, and they will shave off things that may cost time (sometimes, that's Quality).
I mentioned that they removed the safety guards, but I never said it was good. Myself, I would not do that. I enjoy having some of the safety features that modern languages offer. I can work very quickly, indeed. I probably work faster (and safer) than I ever did, because of this.
A big danger of seasoned pros, is that they get casual with extremely dangerous things, and remove the safety stops, in order to accelerate their workflow.
One day, they are too casual, and you end up with a smoking pair of shoes on the floor.
But at the end of the day it's all just a N-way tradeoff between body parts/health outcomes, time and money, and god knows whatever other factors you seek to define.
Nobody blinks an eye when you say you're making a financial gamble and if it pays off you'll be able to retire young enough to enjoy it.
But everyone loses their minds if you're putting up your health instead of dollars, as if those aren't fungible.
Take for example (and this is a literal example from my friend group, not hypothetical) a man in the metal fabrication business. On day one he can either buy the "cheap and unsafe" old flywheel press brake or he can take out a loan for the modern hydraulic equivalent that is much safer, but also 3-5x slower depending on what you're using it for. That's a lot of money in his pocket over time. He never lost a finger in 30yr and ultimately sold out. Now, his lungs aren't great. But if he'd been slaving away at a hydraulic press all those years he'd never have had to either take a much smaller cash out or wait so long that he couldn't enjoy the retirement.
Now, obviously there's not a direct tradeoff between disabling guards or "unsafe choices" and productivity, and there's not a direct tradeoff between "safe choices" and health outcomes. And you can always make good or bade tradeoffs. What's a good tradeoff for the self employed 40yo isn't necessarily smart for the wage laborer at 20, or the business owner who is responsible for the wage laborers.
And at the end of the day it's all safety choices to some extend, but those safety choices are also time and money choices. Do you chock your forklift every time or do you trust the parking brake? It's really easy to sit there and say chock it every time but the nickels and dimes add up, but on the flip side of that coin the health and safety risk exposure adds up too[1].
These tradeoffs are all inter-related and the people saying to "do all the safety all the time" are just as stupid as the people saying you can run a cutting torch naked.
[1] if anyone wants to make a low effort quip about the step stool and utility knife being the most dangerous tools in the shop now's your chance.
This is not what the word "fungible" means. Not at all. Dollars are fungible. You can replace any $1 bill with any other and it doesn't matter. Calling trading X for Y where calculations of comparable value have to occur is exactly the opposite of fungible.
You’re over complicating things because you have no idea what you’re talking about.
At every worksite, the equation is: how much will the company lose in lost productivity and workman’s comp if someone is injured. And the equation goes in favor of safety every time.
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.
I guess the equivalent would be compiling rm without the '--no-preserve-root' option?
Realistically I know a professional arborist. Not only does he have all the safety equipment on his saws, all his crews have full PPE available and use it. The only piece of safety equipment I've ever seen that was dubious is the "sawstop" for table saws, primarily because it false triggers so often.
Well, I made a couple of mistakes, when writing the post[0]. It was misinterpreted, but that was entirely my fault.
[0] https://news.ycombinator.com/item?id=45027284
> 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.
Deleting a DB could have life-changing ramifications, depending on what's in the DB.
I used to write a lot of hardware-interfacing software.
The cool thing about writing things like device drivers, is that you can have some really kinetic bugs.
You have bad catastrophe management if deleting a database causes issues. I've seen databases accidentally deleted in production ... we just restored from a backup losing only a few ms of writes.
This stuff happens; sure it causes downtime, but it shouldn't have any real ramifications.
True. That's what good process and risk management gives you.
I have blown up $40,000 receivers, though.
Hard to restore from a backup.
This doesn't account for safety critical systems or databases containing highly personal information or those in highly regulated industries. The software engineer might walk away with their limbs but others will fall to suicide or life changing financial circumstances.
I can't help but think of the software engineers who followed exactly what their Volkswagen bosses were instructing and are now in prison.
> I can't help but think of the software engineers who followed exactly what their Volkswagen bosses were instructing and are now in prison.
Huh? Are you conflating "I mistakenly pressed the wrong button" with "I was just following orders"?
>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.
Agree. I am really surprised this posters opinion or the linked article is anywhere on the radar of professionals. There is a time and a place for everything. Maybe in an emergency it makes sense to get write access to a prod DB but even as a “professional” I want a second pair of eyes with me or have a backup ready to go.
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.
This is absolutely correct.
I must confess that I have done exactly that.
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.
If you’re regularly cutting pieces of wood wider than your bar, for god’s sake invest in a bigger saw. It will serve you better in many ways, safety included.
> 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.
That's a good point.
I didn't mean it to be taken as so, but I guess that I should have anticipated it.
I'm pretty sure that line is the real reason for the animosity.
My sincere apologies. I'll leave it there, as a lesson to others.
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.
> 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.
This is a great summary.
Your best-laid plans (with power tools, motor vehicles, gravity, etc) can be completely invalidated with a single twitch (possibly not even your own). If you're operating at the margins of safety, there is no room for that.
And it takes experience to know where you are on the safety spectrum! But even that is sometimes inadequate.
For example, I love my radial arm saw. It's my favorite tool for cross-cutting wood. It's an old Craftsman, from the 1970s or so. I bought it from a furniture manufacturer who used it as an infrequently-used backup tool for ad hoc manual fixups, since new (they had big industrial machines for ordinary manufacturing operations). It was very close to new spec when I bought it, but I've tuned it back to perfect. All of the safety guards (the minimal ones that existed in the 1970s) except the dust hood were removed before I bought it.
Anyway, I love it. But they don't really sell RAS's at the consumer level any more, because people hurt themselves with them too frequently. Table saws are also quite dangerous, apparently. Circular saws are supposed to be the safest option, even more so than miter saws.
So I have a lot of experience with all of these tools, and with my RAS specifically. I think I know where I am on the safety spectrum, which I believe to be acceptably safe. But the statistics say otherwise, and one of us must be wrong. I don't think it's me, and my ten fingers attest to that belief.
Right? Or maybe wrong! I think about this every single time I use the RAS, which is probably a good thing. I guess we'll see.
I think a lot of the problem with power saws of all kinds is that each one looks nearly identical to the others, but they each are best for specific uses with only a small amount of overlap. Short cross cuts on a table saw are not as safe as using a radial arm saw or circular saw. Long rip cuts with a circular saw are not as safe (or convenient or repeatably precise) as a table saw. But a naive interpretation sees "blade goes around" and thinks "with a little effort, this one tool can do all of this." And, as a hobbiest or on-site worker, you may not have the room for all of those tools. So, you try to make do, and 99 times out of 100 it's fine, maybe not satisfying, but fine. You cut a little over, clean up the edge with other tools, generally just compensate for the shortcomings.
But 1% issues come up a lot when you're working a lot. I'm in the middle of the most complex project I've ever undertaken, a queen-sized bed frame. I'm about $1000 in on wood and $500 in on new tools. All told, ignoring my time (which is fair because this is also an entertainment activity for me), I'll end up saving at least $8500 over similar designs one could buy from a craft woodshop. And it won't fall apart in 5 years like a $1500 bed frame would.
My design doesn't have a lot of complex cuts, but it does have a lot of cuts total. And where I cut myself was in trying to "save money" and build a jig for something that was really only $100 for a new tool. To try to save about 1% of my "profit", I added immeasurable danger. Even with insurance, my urgent care visit was about $250 and recovery took long enough that it threw me out of the flow of getting the project done. I'm almost done now, nearly a year after starting, but only just restarted 3 weeks ago.
Every project is a series of decisions. I started off deciding I didn't want to buy a bed frame because the frames that fit my budget are junk. Once that decision was made, I should have trusted it and stopped trying to readjudicate cost, especially at such a small level.
I do a lot more with hand tools now. I'm not a production wood worker. If the project takes twice as long, it's not bread off my table. But errors in using hand tools are far less likely to end in literal catastrophy. And it really doesn't actually take twice as long. Maybe 25% longer. And it's an order of magnitude cheaper for the tools. And they fit in my basement shop better. Which is probably why you actually see quite a few "hand-tool only" production wood workers in the real world.
That's a good anecdote! I can relate although my mistakes and almost-mistakes aren't related to power tools.
Well put!
> 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.
Actually, I have several friends that are arborists. It's a fairly common vocation, hereabouts.
It's not nice to be not nice...
What safety features are they removing from their chainsaws to speed the job up?
I would imagine the spark arrestor is the first and least dangerous 'feature' to be removed by regular chainsaw users.
It's a small oblong of fine stainless steel mesh that sits at the exhaust, prevents any large hot particles escaping, but also gradually impedes the operation of the motor.
It can clog up fairly quickly, especially if you run a slightly higher oil:petrol ratio, which you may have very sensible reasons for doing.
And because it's bothersome to remove (especially when the engine is hot) and clean (you need a toothbrush, some petrol, a small container, etc) or replace (you need to carry a spare, and different models have different sizes) - a lot of people just remove it.
None of my chainsaws still have theirs, f.e. It's a calculated risk, but I'm very careful with where and when I use a chainsaw, and also cautious about monitoring fire risks.
Interesting, I've never thought of the spark arrestor as a safety feature. I guess theoretically it prevents starting a fire in dry conditions, which is a good thing.
My chainsaws came with two safety features: the kick guard (or handguard) and a tip protector. For those who don't know, the kick guard sits above your forward hand and stops the chain immediately if you push it forward. If the tip of your chain catches a log juuust right, and you aren't holding the saw firmly with both hands, it can "kick" the chain up towards your face. If that happens, the kick guard will hit your hand and stop the chain. You take a deep breath, pull the kick guard back to release the chain, and keep working. I don't know why anyone would remove it, or if it's even possible for my saws to run without it.
The tip protector is intended to prevent kickback at all, by keeping the tip of the bar from contacting anything in the first place. That's fine if you're cutting stuff a few inches across, but it makes cutting large stuff impossible and even small stuff inconvenient. Kickback doesn't happen often, very rarely if you're careful, and the kick guard handles it, so I've never seen anyone cut with a tip protector. But if you're new to using a chainsaw, it's probably not a bad idea to keep it on.
I won't give up my electric chainsaw... no spark arrestor.
Your electric chain saw weighs a ton for its power output and run time. You'd feel differently if you had to schlep it into the top of a tree all the time.
I have an electric chain saw. It overlaps in use with small, but not arborist small, gas saws and excels at some things they don't. While they can all do each other's jobs if you're ok with it being slower/not ideal it's very much a complimentary tool.
Where it really excels over gas saws is highly intermittent use, reduced maintenance and increased situational awareness (i.e. you can do stupid things more safely).
You must not be using professional saws then. An electric version of a professional Husqvarna or Stihl (only as an example) with the battery weigh the same as a gas version with gas and oil in the tank.
I would argue it’s even more obvious that you have not used one or at least in a professional capacity as you are still looking at 90-100dB running an electric chainsaw.
> with the battery weigh the same as a gas version with gas and oil in the tank.
I still marvel that the liquid I call 'petrol', is called a gas in some parts of the world.
In one of the bigger models, say the Stihl 66x series, there's 825ml of petrol, and 825ml of oil (let's call that 1.5kg) that isn't there by the end of your half hour. Whether that's meaningful I guess comes down to fitness / strength.
As sibling commenter noted, electric chainsaws are hugely compelling for intermittent / infrequent use. Here in AU the pricing isn't compelling yet, though.
While my day job is not an arborist I deal in logs and tree felling for one of my side gigs.
The weight is comparable but the electric saw has less speed/power than the same weight gas saw the battery capacity for a given amount of work output costs you a lot of weight. A gatorade bottle of gas shoved in my pocket weighs a lot less than a 40v battery.
Don't get me wrong, electric saws are great, but I wouldn't want to bring one into a tree. The couple times I've had to climb a tree I've used an electric saw but it is because I value the other factors despite the performance hit.
The difference between gas and electric is being able to hear your buddy yell at you when you're running the saw. While this is not necessarily useful for felling a singular perfect tree in the middle of a field as you crank up the complexity and/or stupidity of the situation in which you are working it becomes more valuable. If an electric saw cracks 100db it's only just barely, gas is categorically louder and everyone who's used both one knows it.
I own a wide variety of mid size saws in both homeowner and "pro" at this point, pretty much all bought used. While power and features vary I mostly discriminate based on chain/bar condition and running condition, they all do the job well enough. I have one tiny saw and huge saw that I only own in "chinese clone of a real brand" quality so I can't compare to high end saws in those classes. Chainsaws are fairly maintenance intensive high strung power equipment and electric is just easier, even if it's heavier. Homeowners who only need to maintain their property and may only run a chainsaw 1-2x per yea would be well advised to get a 40+ volt electric saw of whatever brand makes the most sense in the context of their other tool needs.
The pros I know have lift trucks and so don't schlep it up trees. I've seen videos of tree climbing, that looks too dangerious for me anyway. (And most pros agree)
i'm not a pro. for me there is no gas adveantage. I don't have the stamina to run a saw all day anyway.
Perhaps you guys are in completely different regions?? I wouldn’t assume arborists behave the same everywhere!
> Actually, I have several friends that are arborists.
Right, and they're removing chain brakes and throttle lockouts, are they?
> It's not nice to be not nice...
It is nice to make up stories to support your worldview?
I've never seen a professional modify equipment to remove safety features, let alone an expert.
The same person flat-out contradicted themselves about guardrails: https://news.ycombinator.com/item?id=45024689
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.
I disagree with the original poster about arborists, but I don’t think racing is a better example. Racing is a sport with rules (limitations) specifically designed to promote some type of fair competition. It is a game designed around wanting to drive cars really fast, it looks nothing like “getting a task done as fast/easily as possible.”
If the goal was just to get from point A to point B as fast as possible without and constraints, I guess they would launch the guy out of a cannon or something.
If the goal was to do something useful, like move a lot of people/stuff from one point to another, we’d end up looking at solutions that look nothing like a race car; public transit, stuff like that.
Well, I made a couple of mistakes in the post.
One, is that line about LARPing. I think that's what's really gotten folks upset, and rightly so. I sincerely apologize. It came across as snide. It was a poor choice of words.
The other, is that I gave the impression that I approved of the practice of removing safety gear. It was an observation; not an approval. I've watched "cowboy" arborists at work, and find it terrifying (and, TBH, impressive, as well). I think they are accidents waiting to happen.
But it still goes on, in many industries, including software development. Another poster talked about the calculations that people make, taking risks, in order to move faster. Their post seemed unpopular, but they were absolutely correct.
A big problem with experienced folks demonstrating reckless behavior, is that it gets aped by folks that may not be able to manage things safely, and that's where the real danger lies.
I definitely agree with your last paragraph here.
One thing specifically about arborists—it is a sort of weird job, right? Homeowners can handle most normal trees. The arborist’s job is specifically to handle troublesome trees in weird environments. The problems look similar to ones that homeowners have, but they are more difficult (because nobody calls in the tree guys for an easy tree, right?). So I wouldn’t be surprised if they are uniquely prone to some extent, to wanting consumer gear with (some specific) guardrails removed, or used in creative ways.
By the numbers, I suspect the vast majority of trees that get chopped down get chopped down by loggers in specialized environments, with hyper-specialized equipment (that looks nothing like modified consumer gear). I suspect most engineers think of themselves as more like the loggers: cultivating that environment is a big part of it, and their tools are just different from consumer ones. If riskier, only because bigger moving parts involve greater energies.
There are a lot of safety rules on how to do any type of work, though.
The goal of work is the task. The rules exist to reduce the number of people who get hurt while doing it.
The goal of a sport is to engage in entertaining competition. There are additional rules in sports, to maintain an entertaining competitive landscape.
Race cars have special rules - safety equipment in general does not count against some track limits so winners are looking for ways to hide something that makes them go faster in safety equipment. Every gram matters but there are things that matter more than grams.
This is good advice for workers trying to thrive in dysfunctional organizations, but these are the kinds of people who cause the company to become dysfunctional in the first place, by only doing work that causes them to get ahead, instead of what is right for the company. And I'm not referring just to line workers here, but management too. Incentives are there to point people in the right general direction, not to give license to abandon your ethics and sense of craftsmanship. An alternative to pursuing incentives to the point of abandoning your principles might be to go to a better company, or even starting your own.
Reading this as a pilot, this thing reads like a primer for How Not To Think.
The author might think they're being a meta-pirate by saying "oh these are all possible actions proscribed by most organizations" implying that the proscription itself is a sign of ossified incompetence, instead of identifying the underlying one-true-savior fallacy that underpins it all.
The general danger here is human error. The point of leveraging a collaborative environment is to design process to detect and remediate human error before it radiates outward into more cost. The farther it goes, generally, the higher the cost, non-linearly. It shouldn't be "never do this", but instead "if you're going to do this use every tool at your disposal to make sure it's done correctly." Siloing the entire decision tree to yourself is exactly how not to do it.
In my experience, only the top 5% or so of engineers actually get to decide what to work on. Everyone else just has to churn through the backlog.
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.
Yes, but... as the author already pointed out, this only works if you know what you are doing, i.e. having all the required mental resources, i.e. knowledge, experience, intelligence, courage, intuition, and some more. There are some engineers who know what they are doing and why. And there are many others who don't. Nevertheless, heartily tremendous thanks and greetings to the author, very very much appreciated. I'm a senior of 35 yrs active software dev, half employed, half self-employed, in many different environments. I can tell from my own experience and daily work life, yes, "this is the way" (quoting from The Mandalorian).
There’s a magic component to rule breaking that a lot of online advice doesn’t usually talk about: You have to actually be right. Your ideas have to be good. Companies don’t want everyone breaking the rules because a lot of devs don’t have the engineering skill to back it up.
So if you start operating as a rogue agent then make sure you are good. Tom Cruise (stuntman and actor) had a quote I love- “Don’t be careful. Be competant.”
I don't feel the need to give dangerous advice. As an educator that has to do with the stuff people build more or less unsupervised I can assure you that dangerous is the defacto default starting point for anybody who has no idea what they are doing.
There is only a very specific class of person, who is often overcautious and perfectionist to a degree that they won't even get started. They might need some advice that eases their worries. But the dangers are real. Overcomplexity is also a danger.
Most of the "dangerous advice" I have encountered as an engineer (be it electrical or software) I have seen in the form of legacy projects without anybody there to explain them to me. There you can see where corners where cut, where they were completely out of their depth, etc.
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.
Sure, FYI I am teaching Germany. Not exactly known to be a country of rule breakers, in fact more like the opposite. But rules that you don't know are easy to break.
E.g. beginners with electrical wiring may or may not know what is up to code and what isn't and thus violate said code without knowing it.
To know when certain rules can be bent or broken usually requires a deep understanding for why the rules exist and what they are meant to prevent. Beginners do not have that knowledge and thus I'd hessitate to give any general advice to skip rules to them, unless it is extremely specific and tied to one specific situation.
Usually the more useful advice to beginners is when to ignore conventions and how everybody is doing it and when to just use the boring stuff.
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.
>https://www.seangoedecke.com/programmer-archetypes/
I found this one super interesting. Personality types that make sense but I haven't seen them described this way before.
> Deliberately break written company rules sometimes
I love this. It’s so true. Rules are written for indemnity, but nobody will blame you for not remembering every one of the 216 rules the company has as of this moment (217 tomorrow).
And they’ll love you for fixing the problem now, instead of waiting for the two week review cycle to finish. That is assuming you don’t break shit, but even then it’s a matter of ‘sorry’ in all but the most egregious cases.
> Rules exist to constrain engineers with bad judgment, not to bind the ones with good judgment
Also, “how to fall to the dark side” xD
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.
Of course you don’t knowingly break the rules. How can you possibly suggest it’s deliberate. I just can’t keep the full list of company rules in my mind at all times, and things slip through the cracks. Things slip through the cracks a lot more if it’ll make my chain of command happy though.
This can be taken the wrong way by self-centered people and cause damage- specifically, the advice to “take strong positions even if uncertain.”
I work with someone that does this regularly, and it’s made for a hellscape.
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.
Software engineering career advise is a minefield. Contexts vary so wildly that the best advise probably is more like a case study into personal experiences and how one navigated various delicate/intricate issues.
I for one have two part time jobs and one full time job. My primary challenge has to do with triaging issues ahead of time so that I can draw up a comprehensive plan for working on them ahead of time over the weekend so that I'd be in execution mode throughout the week - which is infinitely more productive - low context switching and more flow.
I also have a mini bottleneck with one company where I'm not given production access - not even readonly and only hear about issues later on from the lead developer. There are often things that I'd rather diagnose in a production env but no - policy dictates part time workers are not given that kinda access.
At the same company, I go to some of the websites we maintain and find somethings are broken and wonder - are these really used by real people or just bots.
We have about 2 mobile apps that do similar things and I'd love to push for a monorepo setup but I have to look around at the engineering culture and realize that a monorepo setup would do more harm than good because it requires a better calibre of engineers.
We have a nestjs codebase full of antipatterns that even I a newbie to nestjs can easily pinpoint and identify - but can't truly get them to consider a huge refactor. I see all manner of nasty rest api implementations that make data flow unintuitive but my leadership skills might be lacking.
I work at a "consulting" firm with a colleague that has issues delegating and primarily prefers import statements be arranged in a particular order. I hated working there because I felt arranging import statements were an insult to my time and abilities as a programmer - but the work pays the bills and I've to bide my time.
I've ranted enough. The bottom line is context varies much too wildly for any advise to be particularly useful beyond being a case study. I'd be more interested in the authors specific experiences than advise
If you need this in the form of advice, it's something you shouldn't be doing.
Management isn’t one entity with one perspective so to some extent I can see why they might have competing interests and sometimes the ones who are “right” in terms of actually getting things done might lose. But,
> Another reason why is that managers will almost never give you dangerous advice, even if it’s what you need to hear. If a manager tells you to ignore company policy, and you do it wrong - for instance, if you post in Slack that you’re doing it and your manager said it was OK - then that’s bad for them. In fact, it’s much worse for them than it is for you. Tech company leadership often views engineers as useful idiots. Managers are expected to be professionals.
> However, lots of managers wish they could give you advice like this. They certainly appreciate it when you follow it. I’ve never been a manager, but it must be incredibly frustrating to manage strong engineers who would be much more effective if they approached work a little more tactically (and a little less according to the written job description).
This advice and circumstance basically sucks, right? Ultimately management (as a whole) is responsible for coming up with policies that don’t get in the way of productivity. Making policy and taking responsibility for when it doesn’t work out: that is part of their job.
The advice here is to just let your manager have the upside of having a team that is more productive by following an alternative set of rules, without the downside of accepting additional risk. That’s just letting them not do part of their job. Everybody would love a consequence-free dodge of the shitty part of their job.
Advice like this introduces a dangerous blind spot: It assumes the engineer is always right and their peers and manager just don’t understand:
> It can be deeply alienating to know things don’t work the way they officially should, but to have nobody to talk about it with.
There are instances where this is true, obviously. One of my more frustrating job experiences was getting hired late into a startup where the founder had already hired their friends, who were not familiar with the domain, into all of the decision making roles. Being stuck in a workplace where the necessary knowledge is absent from upper ranks is very frustrating. As I learned, the real solution is to leave.
The problem that occurs with advice like this blog is that some engineering personality types will see it as affirmation that they are right and the business is wrong even if that may not be true. I can’t begin to count the number of engineers I’ve worked with who went off and chose to work on their own priorities or did some of the other techniques mentioned in this blog when they were not right. It causes a lot of problems for everyone and doesn’t help that person’s career at all.
Before you go out and use some of this strong-headed “dangerous advice” in blogs like this, do your best at the diplomatic approach. It sounds cool to become a “grifter” and work on your own things like this blog suggests, but you’ll get much farther if you simply become someone who is good to work with and trusted. Trust leads to more autonomy and freedom. Becoming a “grifter” and going your own way does not. And if you’re not right about your own decisions, you risk blowing a hole in your trust that can be hard to recover from.
> Tech company leadership often views engineers as useful idiots. Managers are expected to be professionals.
I'm not sure if this quote really adds value to the article. At best it's probably not true, especially if you avoid working at a "tech company". At worst, it's insisting on the false narrative of "class warfare" that only seems to be true when you're junior and still don't understand why nobody cares about you or wants to hold your hand.
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.