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.
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.
> 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
> 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.
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.
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.
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
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.
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.”
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.
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.
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.
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).
>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).
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".
19 comments
[ 1.8 ms ] story [ 34.8 ms ] threadThere 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.
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.
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
I really like Dimitri Glazkov's "Sailors and Pirates" framing of this:
https://glazkov.com/2023/04/02/sailors-and-pirates/
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.
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.
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 work with someone that does this regularly, and it’s made for a hellscape.
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
I found this one super interesting. Personality types that make sense but I haven't seen them described this way before.
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.”
> 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.
> 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.
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.
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".