Each week I'll try to post summaries, notes and quotes about articles I've read and podcasts I've listened to during the week. This helps me pay closer attention to the material, and may help you decide if you want to go to the source--which I hope you do!

Podcasts

Art of Manliness #509 - Good Shame; Bad Shame

https://www.artofmanliness.com/articles/shame/

2019-05-20 22:25

Developer Field Value

  • "Good" shame promotes shared socially acceptable behavior, and has the possibility of redemption
  • "Bad" shame is cruel and negates who the person is.
  • Discover, recognize, and accept your own (and others') limitations
  • Men and women have, according to science, actual differences. Learn which are real vs societal.
  • About the evolution of masculine and feminine traits: "you can't shame that out of existence."

Notes

Interview with Joseph Burgo, PhD, author of Shame. The author's thesis is that there is a spectrum of shame, and that certain types of shame can be valuable.

Categories of Shame:

  • Unrequited love
  • Exclusion (from the group)
  • Unwanted exposure (public embarrassment)
  • Disappointed expectation

A potential value of shame is to "promote social values that are shared".

Brains have critical periods for formation, and if a child doesn't get the love, etc. that's needed, "you can't make up for it entirely in later life." They can grow and compensate, but it's within the limits of their early experience.

Burgo makes the case for a couple of socially uncomfortable ideas:

  1. Most people can't be whatever they want to be. They'll be restricted by limits.
  2. Men and women are truly genetically different, and trying to force men (in this case) to be the same as women leads to men rebelling and demonstrating even uglier, extreme "manly" behaviors.

Burgo says there's been a trend since the 60s to create a gender-neutral society, that "men and women should express the same basic positive traits...there is no difference." Burgo doesn't believe that, and says the science doesn't support that view. About the evolution of masculine and feminine traits, "you can't shame that out of existence." This is an important point, and I think it's the same science-based understanding of why homosexuality and transgender also must not be shamed.

(However, I hate using a computer metaphor when it comes to biology. People aren't computers.)

One way people deal with early core shame is to become narcissists.

It's still hard for men to admit they need--and accept help. It's socially not considered manly. It's even worse in other countries (he cites India).

"Positive" shaming must not be cruel.

Quotes

I think it's better to be honest about the way our pasts ...can place limits on our future. It's better to take those limitations into account rather than pretending their are no limitations then failing and feeling even more shame.

The sad science shows that children who grow up with parents who don't love them have brains--their brains are different.... Alan Shore shows brain scans of children who grow up in normal environments and those who grow up in really deficient ones, and [the children in deficient evironments] brains are smaller, they have fewer neural connections, they're just visibly different.

The so-called "slacker" personality is organized around avoiding shame. It doesn't look that way, it looks like they don't have any ambition, but that's not really the issue.

[Shaming] can be a good thing if it promotes more socially acceptable behavior. In order to do that, it has to hold out the possiblity of redemption. It has to be "you should feel ashamed of this, and your shaming experience is going to have this duration, and we expect you to make amends and then change your behavior." That's the only way shame is ever effective.

References

Developer Tea 20190522 - Make Your Problems Smaller

https://spec.fm/podcasts/developer-tea/298464

2019-05-22 19:14

Developer Field Value

  • When facing any item of work, ask if it can be broken into simpler components.
  • Then, elimate the parts that don't matter until finding what's essential.

When you have eliminated the impossible, whatever remains, however improbable, must be the truth. --Sherlock Holmes

Notes
Reducing tasks into smaller tasks is well known in software, and in general productivity. Not as well known, I think, is applying this approach to solving problems.

So, I'm seeing there's an obvious--yet overlooked--generalized pattern.

When facing any item of work, ask if it can be broken into simpler components.

Then, elimate the parts that don't matter until finding what's essential.

In software, this principle applies to User Stories, architecture, methods, problems, debuggin, and tasks. In habit-forming (and breaking), examining the desired habit and finding the chain of triggers leading to that habit allows you to target the earliest trigger.

I like his coding examples.

  1. During a debugging session where problem seems to keep moving around, eliminate all the code that isn't part of a function or function call. This lets you see just what's calling what.
  2. For a syntax error: eliminate code by halves until error goes away.

I've done number two. Number one is a very interesting idea.

The principle is also stated in Sherlock Holmes' famous maxims.

When you have eliminated the impossible, whatever remains, however improbable, must be the truth.

And this quote.

Having gathered these facts, Watson, I smoked several pipes over them, trying to separate those which were crucial from others which were merely incidental.

Quotes

Often the problems that we're trying to solve are not actually singular problems. This is true both in our code and our relationships.

The complexity of a given problem is first of all hard to define, but secondly it's often undertated. How many factors affecte that problem in the first place, and can you even go back and simulate the problem that occurred? Or maybe you have a difficult decision to make. How can you possibly understand all the factors related to that decision?

When you look at every problem as it stands, in the context of the world, in the context of the universe, then of course it's prohibitively difficult to answer these questions.

We can easily become crippled by our problems.

Art of Manliness #510 - The Greatest Battle of the Korean War

https://www.artofmanliness.com/articles/chosin-reservoir-battle-korean-war/

2019-05-24 22:24

Development Field Value

  • Listen to your "people in the field." These can be direct reports, customers and users.
  • Surround yourself with people who will respectfully disagree, when needed.
  • Stay honestly humble. Find ways to keep your ego in check.

What often surpises me about AoM episodes is that I expect to be either bored or think "ugh, this is not my kind of subject." Neither has ever true.

Take this episode. I'm not big on war history, and it seems like a stereotypical thing to talk about on a "manliness" show. I keep forgetting that AoM questions stereotypes in favor of finding a better truth about what it means to be manly.

Notes
Hampton Sides wrote a book on and discusses the events surrounding the Battle of the Chosin Reservoir and the Marines who dubbed themselves the "Frozen Chosin."

This quote is terrific, so I'm putting it near the top. It's one of the biggest lessons from the conflict, in the author's view.

Keep a channel of communication from the bottom up, not just from the top down.

After WWII, Korea was divided in half, the north going to the Soviet Union under Stalin, and the south to the US under Truman. Both were supposed to be temporary. There was supposed to be reunification and an election, but that didn't happen, and the result of each country's influence is clear.

MacArthur's mistake, coming out of his hubris, ego, and willful ignorance, was to not stop at the 38th Parallel and instead push further in--under the pretense of making sure it wouldn't happen again--triggering China to get involved because the US would become so close to their border.

The description of MacArthur...at this point in his career...is strikingly similar to Donald Trump.1. About MacArthur:

  • People didn't know how to handle his personality.
  • McCarthyism had risen, and Truman/Democrats were being accused of being soft on Communism. (today it's being soft on immigration.)
  • Refused to believe the intelligence reports that China had entered the conflict. Some of his lieutenants doctored the reports (the "yes men" problem, ensuring MacArthur heard what he wanted to hear.)
  • Didn't listen to General Smith, his commander on the ground. (Trump famously says he knows more than his generals.)

There's a fascinating segment giving credit to a Marine civil engineer asked to do seemingly impossible feats, like building an airfield on frozen ground, and building a bridge in just a few hours.

Quotes

About Douglas MacArthur:

It was all about him. He loved he vertical pronoun. "I shall return." The way he used the media, the way he had an entourage everywhere he went, the way he surrounded himself with "yes" men who just told him what he wanted to hear...he had a long, interesting and amazing career, but this was near the very end and I think it had all gone to his head. He just thought he could kick ass and take Korea, and it would be super easy, and didn't think the Chinese would intervene and even if they did it'd be so easy to...you know...and of course he wanted to use nuclear weapons against China when they did intervene, just blow up Beijing no problem. He had by this point become, I think, I very scary dude in the sense of having so much power in this one guy.

MacArthur was not on the ground in Korea. He would fly over occasionally for a photo op.... It's said that he never slept a single night on Korean soil. He's the classic example of an absentee commander. He just was out of touch with reality, and that's where a lot of the problems lie.

It's one the greatest military intelligence failures in our history, and ultimately it's MacArthur's fault.

It happened because diplomacy failed,...because we didn't do the hard, messy work of diplomacy. We didn't have a relationship with the most populace nation on Earth. We refused to recognize Mao as the legitimate leader of China, we had no back channels of communication. He sent ample signals to us that he was going to intervene and we just kind of ignored those signals.

I think of the legacy of this battle as being, exhibit A, what happens when diplomacy fails. And, the other legacy that I really look at here is just how important it is to listen to your field commanders.

This whole thing could have been avoided if we had listened to what General Smith had to say.

References

Developer Tea 20190524 - Crafting Your Work By Your Strengths

https://spec.fm/podcasts/developer-tea/298944

2019-05-26 11:08

Development Field Value

  • Map your skill/knowledge strengths/weaknesses to the job's required core/ancillary skills/knowledge.
  • Improve your weaknesses that are in the job's core.
  • Improve your strengths that are in the job's core.
  • Don't deprecate yourself for weaknesses and mistakes.

I always look forward to Jonathan's podcast, and rarely find myself critical, but I found this episode unclear and unfocused. I'd like to help clarify what I think Jonathan wanted to promote.

As developers, workers, and people, we're faced with deciding whether to improve our weaknesses or our strengths, and which ones. We need to do both. Focusing on only one or the other is unlikely to lead to success. There's science supporting that only repeating what you're good at doesn't lead to improvement. However, only working on what you're not good at leads to atrophy of your strengths.

I'm a martial artist. If my left side kicks aren't as good as my right side kicks, then I need to work harder at my left ones. There's an implicit goal of parity. However, we sometimes forget (as students and teachers) that the purpose of that goal is improvement, not achievement. It's OK if my left side kicks are never as good as my right ones. It's also OK if I work hard to make my right kicks amazing.

But--to continue the analogy--should I focus on being able to side kick to someone's head who is over six feet tall and hold that kick in place? Some kata competition champions can do this. It's their strength. It's not mine. The short answer is "no," because this is important in the context of competition, but not in my interest which is daily health and self-defense.

With that context, let's go back to the podcast and pull the benefit from it. What's a way to help clarify which job skills we should improve?

Create two lists. One is your skill/knowledge strengths and weaknesses. The other is the job's required core and ancillary skills/knowledge.

Skill/Knowledge Lists

( * Starred items are ones I'm naturally good at.)

ME JOB
Strong Core
Tenacity* C#
System Organization* Customer requirements gathering
Understanding Customers' Needs* REST-ful APIs
C# Scalable architecture
WebAPI
Documentation
Weak Ancillary
Self-confidence Employee management
Proven scalability experience Documentation
Python

To meet the job's needs, we should always work on the core skills. Give these lists, here's what I'd recommend the fictitious developer focus on improving:

  • C#, keep improving
  • Customer needs, leverage your strength into becoming an expert
  • WebApi, keep improving
  • Scalable architecture, work hard at improving this weakness

And don't spend much time on:

  • System organization, Tenacity, or Documentation, you're already good enough
  • Personnel management

I really think this is the essence of what Jonathan was trying to say, but--unusually--the message got lost on a first listen.

Notes

Here's a link from the show notes for a free eBook: GitPrime.com/20Patterns

The point of this episode is to encourage focusing on strengths rather than weaknesses. (No, that's not quite right.)

  • "If you focus on everything you're weak at, it will take a very large jump to go from being weak to strong."
  • Investing time in what your good at takes you from good to great.
  • Investing time in what you're not good at takes you from poor to good, but probably not further.
  • One skill may support another skill.
  • Working on a weakness may "unlock" a strength.
  • Understand the core vs ancillary skills needed for the job.
  • Perform ancillary tasks acceptably, perform core tasks excellently.
  • Map your strengths to the required core skills. Is there a big mismatch? You either improve those skills, or consider a career change.
  • Focusing on ancillary skills isn't as important as focusing on core skills.
  • It's OK to delegate or collaborate on ancillary skills

Job crafting: Look at the skill map, what you're already good at, and "wrap" your job around those skills.

Note: Cutrell pronounces "ancillary" the British way.

He's not saying only focus on strengths. I'll call this great quote out:

If you take away the message that you should stop focusing on your weaknesses and only focus on your strengths, it's very possible that you will lose your job.

Another message in this episode is it's OK to fail, to learn, as well as not neglect your strengths.

Quotes

If you listen to a lot of podcasts...you may think there's a lot of room for improvement...that there's just this endless hill in front of you. And you may think you have to break yourself down to become the engineer that you want to become. And in many ways, this is true. We all have a lot to learn, and we all have shortcomings.... In today's episode...I want to help you focus on something a little bit different. Rather than looking at self-improvement as a long and arduous task where you are faced with your weaknesses every single day, I want to help you shift to a different point of focus.... If we focus only our shortcomings and weaknesses, we'll likely miss out on major opportunities.... An unintended effet of this show may be that you have taken the time and the energy to beat yourself up when you're not focusing, or to feel bad when you think you haven't broken things down, when you think you've made an assumption.

All of these ideas presented on Developer Tea,.. business management/process books, books about software development--all of these things are not intended to fix all your broken parts. Instead, they are intended to be building blocks, foundational, to help push you up rather than break you down. This kind of different way of thinking about your skillset requires a fundamental shift in focus away from your weaknesses and toward your strengths.

If you become incredibly good at your ancillary skills then you don't have time to invest in your core skills.

Hanselminutes #685 - Solving real problems with software and the Human Utility with Tiffani Ashley Bell

https://hanselminutes.com/685/solving-real-problems-with-software-and-the-human-utility-with-tiffani-ashley-bell

2019-05-26 13:20

Developer Field Value

This was an inspiring episode!

  • There are opportunities to improve local government using fairly simple technologies that the employees won't be aware of, or afraid to take a risk on.
  • Developers are paid pretty well, and thus privileged. We are in a position to improve the lives of the less fortunate.
  • Most people don't set out to have problems. Sometimes "life happens." They break an ankle, and suddenly can't pay their rent.
  • A software-specific understanding of "life happens" is that we don't intend to write bugs, and we can have bad days. We shouldn't be terribly penalized even if our mistake crashes a system. We should be helped up, not beaten down.
  • In any system, ensure it's not being taken disadvantage of through validation. (In the Detroit case, they extensively validated the claims)

Notes

Has found lots of her opportunities on Twitter (prior to the current political environment's negative unfluence on the platform).

Read an article about how 100,000 people in Detroit were going to have to live without running water because their water was being shut down due to non-payment. "I thought it was bad...I thought it was really crappy."

Great example of using simple technology, putting up a quick and dirty website in a few hours, then letting people know it's available and seeing if they'll come. For the initial Detroit water project, she and her partner used Google Docs and Forms and some Bootstrap. Over the weekend, the started being contacted by people who wanted to help. They then made improvements to allow donorship.

One thing that was critical was finding and publishing people's actual stories of why they were behind in payment (see quotes)

Quotes

[Scott] When you start poking around in local government, with all due respect to all of our hard-working people in government, the solutions they have and the technologoy they have and the gaps can be filled in by pretty straightforward bits of workflow, not rocket science, we don't need machine learning to make it easier for someone to find out when to come to pay their parking ticket.

You get these situations where cities have multi-million dollar contracts to really large corporations that make [for instance] databases, when they could really be using something a lot simpler in a lot of different places, because some salesperson came in, convinced a person who didn't know how to buy these things, or didn't know the he could go somewhere and perhaps download something and still get support.... They're used to these big enterprise companies coming in and offering that, and at great expense. But they don't realize it doesn't take all these heavy solutions to do simple things for citizens, and that lack of knowhow isn't there in a lot of situations.

I think also...people don't want to get in trouble for the things that they buy. What's the old saying? "You never get fired for buying IBM."

[Scott] These are folks [Detroit who couldn't pay water bill] who are maybe on disability...one person was written up in National Geographic...who received a $672 monthly check, but her rent was $600, so she had $72 left at the end of the month, and slowly, slowly, slowly...got a $500 overdue water bill, so they came to her house and turned off her water.

And this happened to tens of thousands of people in Detroit--who had 90 million dollars in bad debt--and shut offs were being called in for anyone who owed $150 or more, and it seems that for some people that's a crushingly huge amount of money, and for other people, like you said, it's a bad meal for four in the Bay.

One of the stories I think about was a woman...she had three kids...who skimped on her heart medication, cut her pills in half...to pay the water bill each month.

References

  1. With the exception that Trump appears to have had far fewer successes than he claims.↩