I worked at a place where we had other teams contacting our team’s manager asking him to please stop scheduling so many meetings for our team because we weren’t able to meet our commitments to other teams.
In one part of Microsoft, I heard that they wrote a meeting cost calculator that took the levels of everyone and the median salary for that level and gave an approximate cost of the meeting. I tried doing this as a back of an envelope calculation and worked out that one recurring meeting I was in cost over half a million dollars a year. I wish Outlook had this kind of of thing integrated.
I’ve seen this referred to as the “burn rate” of the meeting and I find it useful to think about sometimes, especially for meetings that have a lot of people or low engagement.
I had a manager who would schedule all hands meetings every time I told them we didn’t have the capacity to do something urgent. I never managed to get it through his skull, that an day long all hands would only slow us down even more… I would even be sitting there in the meeting room with my laptop, fanatically trying to get a server back on line or something like that while various other non-technical types would ask me how long it would take…
I would even be sitting there in the meeting room with my laptop, fanatically trying to get a server back on line or something like that while various other non-technical types would ask me how long it would take…
It took me quite a while to realize that I should really not try to protect management from their own mistakes. In that kind of situation, you are expected to attend the meeting. Attend the meeting. If the server is down, well, not much you can do, you are in a mandatory meeting.
At some point, if everything fails, someone higher up the chain will realize there’s a problem. And if no one does (I’ve seen it happen), who cares as long as you are being paid? Nobody is going to reward you for your efforts; quite the contrary, you will probably be blamed for what your boss will perceived as attempts to go against him (again, been there, done that).
Tactical tornado engineering is a great example of this:
Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.
…I totally recognize this in one of my coworkers. XD I think we have successfully channeled them into a place where their unrestrained enthusiasm gets applied towards the forces of good with a minimum of fallout: front line troubleshooting, proof-of-concept testing and customer demos. The fast pace and tactical absorption are very useful when things need to be solved Right Now, and then afterwards more cautious engineers can wade through the wreckage to cherry-pick lessons learned and scoop up the more interesting bash scripts to be turned into real tools and upstreamed.
To their credit, they also recognize this is their MO and tend to stay away from development that would have deeper or wider impacts on core systems, and prefer to enjoy the endless novel problem-solving of operations-y stuff.
This is definitely one of the roles where folks like that can shine. But it isn’t a panacea.
A person in a similar role once told me that they wrote their own implementation of a cryptographic algorithm because “[the platform used in the product] didn’t allow importing the existing npm package for it” and that it wasn’t a problem because “they tested the implementation with all the standard test vectors and it passed all tests.”
It took me two hours to explain the difference between “this implementation has no security vulnerabilities” and “we don’t know of any security vulnerabilities in this implementation.”
Thankfully, I caught it early enough that it didn’t cause any serious issues. It would have been really bad if we had shipped it to a customer and it turned out being problematic in some unforeseen way.
oh ho ho wow, good catch! I had a similar experience once explaining that we weren’t going to ship a telemetry-monitoring tool to our customers that consisted of a bash script calling curl on undocumented HTTP endpoints. But I think your story wins. At least they did test their impl with all the standard test vectors?
Now, Oracle can just go shrug, stuff happens and fix it, but I was at a small-ish startup at the time and wasn’t willing to bet our future on being able to do the same. Not to mention that it would have much more likely been (in part) my mess to clean up, and certainly not the tactical tornado’s.
I’ve seen people promoted for writing a lot of code. In particular, the kind of developer who seems to have a mindset of ‘never do in 5 lines of code what you could do in 200’. They look amazingly productive because they’ve added a load of new features to the product and the manager doesn’t notice that the rest of the team is less productive because they’re spending all of their time fixing bugs in this person’s code.
these guys have long been a frickin pain in my backside. Mr. Minimum Viable Product, Except Not Even Actually Viable. one example left four years ago and we’re still finding messes he left.
If one of these people is in a code base right at the start sometimes you can never fix it. I remember starting a job and working on a particular API model. I asked who the SME was and someone told me “Well, I think it’s you now.” It was probably the most important data model in the system and one of the most complex ones. It was an absolute rat’s nest or JavaScript. That was 5 years ago and I don’t think it ever got better. I don’t think they’ll ever fix it.
I worked at a place where we had other teams contacting our team’s manager asking him to please stop scheduling so many meetings for our team because we weren’t able to meet our commitments to other teams.
When it’s that visible, you know it’s bad.
In one part of Microsoft, I heard that they wrote a meeting cost calculator that took the levels of everyone and the median salary for that level and gave an approximate cost of the meeting. I tried doing this as a back of an envelope calculation and worked out that one recurring meeting I was in cost over half a million dollars a year. I wish Outlook had this kind of of thing integrated.
I’ve seen this referred to as the “burn rate” of the meeting and I find it useful to think about sometimes, especially for meetings that have a lot of people or low engagement.
I had a manager who would schedule all hands meetings every time I told them we didn’t have the capacity to do something urgent. I never managed to get it through his skull, that an day long all hands would only slow us down even more… I would even be sitting there in the meeting room with my laptop, fanatically trying to get a server back on line or something like that while various other non-technical types would ask me how long it would take…
It took me quite a while to realize that I should really not try to protect management from their own mistakes. In that kind of situation, you are expected to attend the meeting. Attend the meeting. If the server is down, well, not much you can do, you are in a mandatory meeting.
At some point, if everything fails, someone higher up the chain will realize there’s a problem. And if no one does (I’ve seen it happen), who cares as long as you are being paid? Nobody is going to reward you for your efforts; quite the contrary, you will probably be blamed for what your boss will perceived as attempts to go against him (again, been there, done that).
What I’d be more interested in seeing would be “things that people think are 10x but are actually -10x”.
Tactical tornado engineering is a great example of this:
From “A Philosophy of Software Design” by John Ousterhout. https://www.goodreads.com/author/quotes/14019088.John_Ousterhout
…I totally recognize this in one of my coworkers. XD I think we have successfully channeled them into a place where their unrestrained enthusiasm gets applied towards the forces of good with a minimum of fallout: front line troubleshooting, proof-of-concept testing and customer demos. The fast pace and tactical absorption are very useful when things need to be solved Right Now, and then afterwards more cautious engineers can wade through the wreckage to cherry-pick lessons learned and scoop up the more interesting bash scripts to be turned into real tools and upstreamed.
To their credit, they also recognize this is their MO and tend to stay away from development that would have deeper or wider impacts on core systems, and prefer to enjoy the endless novel problem-solving of operations-y stuff.
This is definitely one of the roles where folks like that can shine. But it isn’t a panacea.
A person in a similar role once told me that they wrote their own implementation of a cryptographic algorithm because “[the platform used in the product] didn’t allow importing the existing npm package for it” and that it wasn’t a problem because “they tested the implementation with all the standard test vectors and it passed all tests.”
It took me two hours to explain the difference between “this implementation has no security vulnerabilities” and “we don’t know of any security vulnerabilities in this implementation.”
Thankfully, I caught it early enough that it didn’t cause any serious issues. It would have been really bad if we had shipped it to a customer and it turned out being problematic in some unforeseen way.
oh ho ho wow, good catch! I had a similar experience once explaining that we weren’t going to ship a telemetry-monitoring tool to our customers that consisted of a bash script calling
curlon undocumented HTTP endpoints. But I think your story wins. At least they did test their impl with all the standard test vectors?They did. But standard test vectors are proof of functionality, not safety.
For example, test vectors didn’t protect the Java 15-18 ECDSA implementation from accepting
(0, 0)as a valid signature for any message: https://twitter.com/tqbf/status/1516570590211153922Now, Oracle can just go shrug, stuff happens and fix it, but I was at a small-ish startup at the time and wasn’t willing to bet our future on being able to do the same. Not to mention that it would have much more likely been (in part) my mess to clean up, and certainly not the tactical tornado’s.
I’ve seen people promoted for writing a lot of code. In particular, the kind of developer who seems to have a mindset of ‘never do in 5 lines of code what you could do in 200’. They look amazingly productive because they’ve added a load of new features to the product and the manager doesn’t notice that the rest of the team is less productive because they’re spending all of their time fixing bugs in this person’s code.
these guys have long been a frickin pain in my backside. Mr. Minimum Viable Product, Except Not Even Actually Viable. one example left four years ago and we’re still finding messes he left.
If one of these people is in a code base right at the start sometimes you can never fix it. I remember starting a job and working on a particular API model. I asked who the SME was and someone told me “Well, I think it’s you now.” It was probably the most important data model in the system and one of the most complex ones. It was an absolute rat’s nest or JavaScript. That was 5 years ago and I don’t think it ever got better. I don’t think they’ll ever fix it.
Too real. Whenever I hear the word “pragmatic” in a programming discussion I get tech debt PTSD.
I like to think this is about time at place. There are times when going into tornado mode is super useful: prototyping, grenade-diving, etc.
But you have to own the maintenance of your own shit.