Most people "just" do their work and mostly assume things as they are. Often, they don't ask questions nor question things. Perhaps they asked the same questions in the past and haven't found an answers. There is also finite number of things we can fix.
I love when things are fast, that's why I avoid working with JVM ecosystem. People ask me why and the thing which holds me back the most is speed of compilation, testing, running and startup costs a specially with Spring Framework.
There is also this great talk "Performance Matters" by Emery Berger which I highly recommend. Speed is important and often can highlight issues which could show up after release when changing things is harder. If we look at current software development, microservices, containers, IaC and we add up all the time we are waiting for the whole delivery processes there is a lot of time to be saved. Seen things like installing all the tools for CI every time it runs without caching :(
Tho there are people who care and if they see things like this they fix them :)
I suspect that you are also allergic to inefficient systems as well. I think it's more than not having a mental model. I think some people keep the individual details top-of-mind and others (like yourself) keep systems top-of-mind.
Details folks internalize the systems - they know them but do not access them while they work unless they externalize it somehow, by drawing it out or asking an expert, referencing a book.
Systems folks internalize the details - they know them, but, unless painstakingly memorized, may not be able to recall them when asked directly. They prefer to reference details in a book, etc.
Each type has a sense of when things are not right when it is within their area of strength or they happen to have done it recently.
How does this relate to being irked by waiting? Maybe nothing, lol. Not directly, at least. It may have to do with knowing that things are potentially working incorrectly (there could be a better way). It's like a silent alarm bell and you're wondering why no one else hears it.
I've worked with systems that I thought were developed by mistake - they were obviously going to run into critical problems immediately, but they still went ahead and built it with no regard to the impending crash ahead. I was dumbfounded, as all the alarm bells were going off for me immediately, but no one batted an eye. It crashed, but that was okay - now they can optimize for version 2. Same team, different crashes (my suggestions were classified as over-optimizing) - no lessons learned. Systems thinking was the job of the (nonexistent) software architect.
Unbalanced teams likely waste billions of dollars doing things that don't need to be done. For years, I thought it was intentional - just to keep investors happy, etc. Now, I'm 90% certain they have no alarm bells and work entirely within a vacuum - just doing their work as they interpret it. Imagine writing a book where the only oversight was grammar check. Everyone made sure they had the best paragraphs, managers double checked for capitalization and spelling, but no one made sure it the order of each sentence made logical sense.
I don't know. I'm writing too much here, but yes. Others have those silent alarms too.
Thank you! That's very insightful. "They prefer to reference details in a book, etc" -- yes!
"Everyone made sure they had the best paragraphs, managers double checked for capitalization and spelling, but no one made sure it the order of each sentence made logical sense." -- this sounds like something that would drive me mad.
Most people "just" do their work and mostly assume things as they are. Often, they don't ask questions nor question things. Perhaps they asked the same questions in the past and haven't found an answers. There is also finite number of things we can fix.
I love when things are fast, that's why I avoid working with JVM ecosystem. People ask me why and the thing which holds me back the most is speed of compilation, testing, running and startup costs a specially with Spring Framework.
There is also this great talk "Performance Matters" by Emery Berger which I highly recommend. Speed is important and often can highlight issues which could show up after release when changing things is harder. If we look at current software development, microservices, containers, IaC and we add up all the time we are waiting for the whole delivery processes there is a lot of time to be saved. Seen things like installing all the tools for CI every time it runs without caching :(
Tho there are people who care and if they see things like this they fix them :)
Maybe we just care deeply about our craft, and we project our standards and expectations onto others.
I suspect that you are also allergic to inefficient systems as well. I think it's more than not having a mental model. I think some people keep the individual details top-of-mind and others (like yourself) keep systems top-of-mind.
Details folks internalize the systems - they know them but do not access them while they work unless they externalize it somehow, by drawing it out or asking an expert, referencing a book.
Systems folks internalize the details - they know them, but, unless painstakingly memorized, may not be able to recall them when asked directly. They prefer to reference details in a book, etc.
Each type has a sense of when things are not right when it is within their area of strength or they happen to have done it recently.
How does this relate to being irked by waiting? Maybe nothing, lol. Not directly, at least. It may have to do with knowing that things are potentially working incorrectly (there could be a better way). It's like a silent alarm bell and you're wondering why no one else hears it.
I've worked with systems that I thought were developed by mistake - they were obviously going to run into critical problems immediately, but they still went ahead and built it with no regard to the impending crash ahead. I was dumbfounded, as all the alarm bells were going off for me immediately, but no one batted an eye. It crashed, but that was okay - now they can optimize for version 2. Same team, different crashes (my suggestions were classified as over-optimizing) - no lessons learned. Systems thinking was the job of the (nonexistent) software architect.
Unbalanced teams likely waste billions of dollars doing things that don't need to be done. For years, I thought it was intentional - just to keep investors happy, etc. Now, I'm 90% certain they have no alarm bells and work entirely within a vacuum - just doing their work as they interpret it. Imagine writing a book where the only oversight was grammar check. Everyone made sure they had the best paragraphs, managers double checked for capitalization and spelling, but no one made sure it the order of each sentence made logical sense.
I don't know. I'm writing too much here, but yes. Others have those silent alarms too.
Thank you! That's very insightful. "They prefer to reference details in a book, etc" -- yes!
"Everyone made sure they had the best paragraphs, managers double checked for capitalization and spelling, but no one made sure it the order of each sentence made logical sense." -- this sounds like something that would drive me mad.
It's related to this post: https://registerspill.thorstenball.com/p/two-types-of-software-engineers?lli=1