A really good book on this is "Turn the ship around".
Your role is to improve your staff to be better in their jobs. Ignoring the Manager/Engineer caste system, there is a lot general leadership in both roles.
You want your staff to be able to integrate and find information that allows them to make decisions, you don't lose accountability or responsibilty.
There is a big difference between
- "I've looked at the details, and I think we should do X, what do you think?"
and
- "What should we do about this?"
In the former, you can add extra context, and help your report understand details that may have been hidden or unknown to them. In the latter you are allowing your report to shift all the burden to you.
Bamboo is a grass, it doesn't layer bark. It's one and done. The internode distance is pretty much fixed once it hardens. The bamboo cells inflate and harden. So the graphs make a reasonable amount of sense.
The wall thickness is a function of time to harden, and time to add extra stuff to the wall. Segments close to the ground have simply longer time, and likely hardening begets hardening.
The internode distance is interesting in that there is a natural point at which the bamboo stops elongating and begins to start shortening (again in a negative exponential). My understanding is that bamboo does start to keep "leaves" that sprout from the nodes, to gather light and energy. I wonder if that is the point that the leaves start, and hence it is a mixture of both time (less time = shorter) and investment in energy (effort to grow sun-catching leaves).
Some interesting followups would be in the natural habitat, where does the typical canopy start?
That happened to me. AMD stock certificate from 2006 received at about $10. They accepted it, were willing to transfer it into my account. Unfortunately, I had moved country and the annual meeting messages were returned to Computershare as RTS. They declared me (and my stock certificates lost) and hence eschewed them to the state of Delaware. Where they were dutifully sold and state lost property had the results of the sale. The eschewment happened in 2015 when the stock was about $5.
When I realized I had them, and tried to deposit them in etrade, it all went well, except the certificates were returned "no longer valid eschewed to the state of delaware".
The bummer is that the stock was running at about $80 then, and is running at around $150 now.
sigh.
So they will be valid, but there will paths that will "expire them".
To me, it isn't about the code itself, it's about communication, it's about a relationship with others through code, systems and architecture.
Using the relationship analogy, when you can hear something small from your partner and know what they are thinking, understand what they may do next it feels effortless.
When you look at some code, can you trust what the function name implies is done, without concern?
When something is complex in a relationship we pause to take time to communicate and come to a common understanding, we write notes to each other.
When we have something complex in code do we write down information to help the other engineers work through it?
In a lot of ways the way we relate to our peers through code is possibly a reflection of how we relate to others in life.
It doesn't diminish, the knowledge is like a fractal. You can zoom out, in, etc.
I created a prompt that asks me a set of questions on a topic. It then scores my understanding, gives me deeper insight into the topics, broadens my understanding with some extra information, and then provides a mind-map of related topics, and a mind-map of adjacent topics.
To bootstrap an area of understanding, I ask it for a mind-map of a topic. Like a fractal, you can choose a line item and go deeper.
Prompt 1: Give me a small mind map on the amygdala
Based on that, prompt 2: give me a mind map on the role of the basolateral nuclei of the amygdala in the creation of phobias
My background theory is around schematization. Our knowledge is a complex web of inter-related concepts. Some factual, some abstract.
For audiobooks/read books, I look for 2 or 3 key "aha moments" that stick with me. For Thinking Fast it was "two ways of thinking", "loss aversion". From there other related concepts are just below the surface.
For Thinking in Systems it's "stocks + outflows + inflow", and "all systems reach an equilibrium".
As you read more, you get lots of different ideas cross pollinate, and from there you gain your own insights.
As others have said, pondering or applying the ideas in real life is really important.
Your brain takes shortcuts, you can think you understand what is going on, it's only when you need to communicate it you realize how many shortcuts in hallucinations of understanding there are in your head.
So for those with imgur accounts... I have a challenge for you.
Most people will know how to ride a bike, will know a bike when they see it.
But can you communicate what a bike looks like (in a diagram)? 90% of you won't be able to.
Grab a piece of paper, and draw a bike. Post it to imgur, and post a link to it below (please don't be a troll).
I feel I've got something similar. Memory encoding/recall via emotions I struggle with. I can understand emotions, but it seems to be more cognitive. So I struggle to share the same "emotional space".
It was a mixture of VGA CRTs and VT220's. I just missed token ring,
New graduate, started in Australia at $35k. That's about $65k in current dollars. No stock, maybe a bonus.
Manuals were binders or printed books. Builds were managed by the "Configuration Manager", and coordinated nightly. The languages were C, Ada, Assembly.
The network was BNC cables.
Design reviews were a thing, code walk throughs were a thing. People were trying to work out how to apply UML.
Printers will still a mix of dot matrix and lasers.
Design patterns I think, had just become a thing.
Work life balance was okay. Everything was waterfall, so you ended up in death marches semi-regularly.
Linux was just ascending, but big-iron Unixen ruled the dev environment. Microsoft was just trying to work out itself (Microsoft Mail, Lotus 123, Domino)
So he can't work on the product for the full week as per the article.
What about looking internally about tools, techniques and approaches that can help him accelerate the team. It is outside of the product.
From what I have seen of hyper productive employees, there are two types:
The self aware junkie - they know why, how and what to do. You can ask them, and they will tell you. People won't necessarily agree or understand why it works, but they know. This ability to externalize and communicate allows for step function improvements in the org. IF the team is willing to try new things.
The naive "I dunno" - this is much harder, they do what they do, but they don't know how they do it. in this case you just need to fill up the hopper with more work.
Of course there are risks here, the velocity my end up making the system "their system" capturing their ideas, conceptualization, etc. If they have a great bar in communication (documents, diagrams, etc) then that can work quite well. But the risk is that people may not understand what it is they are working on in the end (see Tao of Rodney in Stargate Atlantis).
But ultimately this is between the engineer and their manager. They need to work it out. The engineer needs to work out what they really want, and the manager needs to work out how to provide.
Your role is to improve your staff to be better in their jobs. Ignoring the Manager/Engineer caste system, there is a lot general leadership in both roles.
You want your staff to be able to integrate and find information that allows them to make decisions, you don't lose accountability or responsibilty.
There is a big difference between
- "I've looked at the details, and I think we should do X, what do you think?"
and
- "What should we do about this?"
In the former, you can add extra context, and help your report understand details that may have been hidden or unknown to them. In the latter you are allowing your report to shift all the burden to you.