HN user

mtippett

111 karma
Posts17
Comments49
View on HN

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.

Lots of good advice there. I did pause on the "Be risk adverse". My take is

- Be Risk Aware - know them, quantify them, manage by mitigating or having contingencies

- Don't be Risk Averse - Averse means being avoidant of risks or disinclined, it's safer, but it means risks aren't taken.

- Don't be Risk Paranoid - Protecting against unseen risks wastes time and efforts.

The following could be completely wrong...

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.

ChatGPT (gpt-4.0) is crazy omniscient.

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.

For me, it's all about coherent externalization.

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).

Then take a look at https://www.gianlucagimini.it/portfolio-item/velocipedia/

Until you try to communicate a concept or idea in words or diagrams, the chances are you are hallucinating your understanding.

Alexythimia 4 years ago

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".

This morning after being hit by Meta's layoff, I created a discord server for those affected, and those who might want to support them.

It's quickly blown up to 500ish people, and so I'm looking at generalizing it to Tech-pocalypse 2022.

Feel free to join, get involved and help the industry move through this period.

(Note the server is < 12 hrs old at this stage, so it's gonna take some love, if you want to help reach out to @mtp.

I can go back 26 years. Sorry.

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.

Ultimately it's a mind game.

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.

Didn't get the job...

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.

Arggh.

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.

I like how he says little-a agile - what most teams use. big-a Agile I reserve for specific Agile methodologies. Most companies aren't willing to invest in the rigor and effort for big-A Agile, and so you end up with this weird-ass hybrid.

That's actually a good hack. I tend to take a similar approach, but using approximate days in a fibonacci sequence.

Start at the high end, will it take... years: NO quarters: NO months: erm... NO. weeks: maybe days: Unlikely hours: Ha. No.

So you end up with a range (days?-weeks-months). That's too broad, what could go wrong to avoid making it months long project (well we could investigate X, Y, and watch for Z). What needs to go perfect for it to be days? (well we could... wait, days is unlikely).

Those discussions about the high and the low to get "reasonable" confidence are super important.

I actually see just as in a lot of cases as being as a painful indication of a gross trivialization of something.

I regularly call out engineers when they say "just", in a lot of cases when I say - can you explain "just" they go and pull out their collection of familiarity and understanding. To which I usually ask - "How much of your understanding will the reader have?".

When I ask them to remove the just, suddenly a single word becomes a couple of sentences that expand the "just". Magically something trivialized becomes described.

I've often wondered if dreams are fully constructed stories during REM or REM is more or less random vignettes of cognition that are assembled into a constructed story upon awakening.

Rewriting memories seems to be reasonably well understood, and if the recall mechanism for waking memories reconstructs a plausible story from memories, is it reasonable that the same is happening with dreams?

We always remember dreams, have there been experiments where the paralytic effect of sleep has been blocked? I remember seeing a cat video (ironic) of a cat having that part blocked by drugs or surgery and it jumping like it is catching a bird.

Oooh! The memories. First year university in Australia and discovering the internet, IPs and FTP. Everything felt so accessible then. Even 20 3.5" disks for an install of SLS Linux felt easy and effortless... Now, shoot me if I need to transfer not in a network.

No they don't.

The toxic communities that exist have a mixture of no-clue 11 year olds with minimal parental supervision (or parental supervision that's failing) through to young adults who found a community that can reflect their feelings back.

Eg: the proana/edtwt communities are clearly children just working things out to young adults getting followings and interaction with a community. It sickens me to see a post from a 23 yr old spouting how to hide ED from your parents by doing the following... Or using subliminals to change the shape of your nose.