Dangerous advice for software engineers
seangoedecke.com
seangoedecke.com
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.
Plus every developer believes they're a special and insightful little petal so all the caveats will get ignored.
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.
> 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.
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.
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 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 know what those caveats are. However if you are more inexperienced you don't know what those are.
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.
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.
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.
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.
I've heard the demographics in Germany have changed dramatically. That could no longer be the case.
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.
I really like Dimitri Glazkov's "Sailors and Pirates" framing of this:
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?
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.
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.
(More likely both: we are as a species absolutely terrible about assessing low-probability risks.)
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.
however I use everytrick I tan to get memory safety when possible.
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.
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.
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...
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.
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.
I have no problem letting those people and behaviors be ridiculed.
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.
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.
Let's just bury the hatchet, eh?
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.
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.
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.
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.
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.
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.
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.
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.
This stuff happens; sure it causes downtime, but it shouldn't have any real ramifications.
I have blown up $40,000 receivers, though.
Hard to restore from a backup.
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"?
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.
It's not nice to be not nice...
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.
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).
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.
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.
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.
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.
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.
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.
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.
The goal of a sport is to engage in entertaining competition. There are additional rules in sports, to maintain an entertaining competitive landscape.
I must confess that I have done exactly that.
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.
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.
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.
safety gear doesn't cost much time to put on. Checking the safety gear also finds not safety things wrong with it.
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:
If I would see somebody removing the guardrails from their tools, I would send them off site immediately. There will be no nasty accidents.
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.
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.
The same way a senior engineer is more likely to use version control, backups and automated testing rather than YOLOing vibe coded applications to prod.
The “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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
Yuk, yeah, no - We don't appreciate it when you just do your own thing. We appreciate it when you're able to cut through red tape and get it done. That thing, that we discussed, during our 1:1's, when I told you what we wanted to do and you said "I have a sharp tool that will cut through that BS". Sometimes we want to cut through the tape, sometimes we're laying it. It's all to make sure you continue to get a paycheck. You're welcome.
Take down production though and we're going to have one of those things managers call a "difficult conversation".
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.
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 found this one super interesting. Personality types that make sense but I haven't seen them described this way before.
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
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.
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.
I work with someone that does this regularly, and it’s made for a hellscape.
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?).
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
> 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.
> 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.