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.
I agree with most of what is suggested in the article.
However a big part is missing is the reality that there are a set of hypotheses (is that right) in play at any point in time. A lot of debugging is the cycle of
1. Think about the system, gather any available data - you can't boil the ocean
2. Consider a set of hypotheses possible cause (even if it is a partial cause)
3. Seek any method to either refute or confirm the possible cause which gives more data.
Wash, rinse, repeat. Each cycle will likely get closer to the problem.
Each cycle also is likely to find other tech debt that needs to be solved.
Rarely is there a single hypothesis that is right first time. Although an experienced person will prune out a lot of poor ideas automatically, and likely subconsciously.
Observability goes a long way to getting the data needed to confirm or refute.
For the most part, we are all forgettable, and it doesn't matter what we do won't be memorable for most people.
When you think about it, you are a single person looking at out the world. You are neither a collective, or part of an explicit audience. It's your eyes, and your thoughts looking out. There may be 100 people around you, and each one of them will be having their singular experience.
A very small number of them will be having sharing their 1 person experience with your 1 person experience. But it is still them.
Look around next time you are the gym - notice how many people are actually looking around. (Of course if you are looking around quickly, you might get a few more eye contacts than you would otherwise).
Make sure you are not looking out and judging others, I know a number of people who can't even consider doing anything that might get a gaze. But they are also the first person to comment about others. It's a tiny, tiny percentage of people who do that though.
Building resilience is probably the biggest direct action you can take. Choose one thing that is just uncomfortable and do it. Do that every week. As you push your boundaries of what makes you uncomfortable, you will find that the comfort buffer that you had around you was much, much thicker than you expected.
Now there will be times you may step into something and you may actually awkward. But even then, you will learn where that boundary is, and with friends it will become a story. With strangers it will just be a easily forgotten anecdote.
I had just moved to Toronto in about 2002, and was waiting for an interview. I saw one of those microwave horns on a building in the distance. Puzzling over what it was.
Interview started, talking about something glanced over the background and muttered verbally "Microwave" as it hit me that it was a microwave waveguide of some sort.
Fully agree. There are huge nuggets of wisdom in old-school engineering. For example PERT is something that most people don't know about. But it's simple to apply in the real world. Get three estimates - optimistic, pessimistic and realistic. double the realistic, add the optimistic and pessimistic and divide by four. It's basically a centerweighted estimate - but it forces you to think about the the corner-cases and what could go wrong.
Lots of other old school stuff that we "just turning grey" people need to translate for the new kids.
I hate multipliers. It's not poor estimates that need to be doubled. It's the lack of experience in identifying the complexity or likely risks in a project.
So rather than multiply, ask for risks. You'll find that most engineers know the risks (or at least they may know it is without risk). As you explore risks, you'll find the estimates will lengthen automatically.
So rather than do the multiplier, explore the risks. They are what makes projects late, not intrinsic engineer productivity. You'll end up with better engineers who know themselves and their problem spaces better. You'll also get a clearer view of what could screw up your project.
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.