A pleasant walk through computing

Comment for me? Send an email. I might even update the post!

Flatt's Posts/Casts Review #002 - Real Problems, Strengths, Korean War, Smaller Problems, Good/Bad Shame

2019-05-26 14:14

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

The 50-10 Time Box - Revising Pomodoro for Software Development

2019-05-22 23:08

This is a slightly edited repost of an article I wrote last year. I think it's valuable enough to promote the technique again, along with the supporting science.

Many of us have trouble with three aspects of programming:

  • The cost of interruptions
  • Methods for staying on task
  • The benefits of taking breaks

Each of these has studies behind it (see References), as well as anecdotal information. The simple question I wanted to answer is:

What's an effective work-break cycle for programming?

The three most common cycles I know of are:

  • Pomodoro - 25 minutes work, 5 minutes break
  • 52/17 - 52 minutes work, 17 minutes break
  • 90/? - 90 minutes work, then a break

Pomodoro

The Pomodoro Technique is popular, and, besides the work-break cycle, has these suggestions:

  • Plan the tasks
  • Check off completed tasks
  • Record interruptions so you can return to them outside the work interval

The problem is, Pomodoro, to my knowledge, hasn't been studied scientifically. When I used it for non-programming tasks, I could see the benefit. The more I tried using it for programming, the less effective I found it.

The Task Recovery Lag

Numerous studies show there's a recovery lag when resuming an interrupted task. For software developers, it takes about fifteen minutes to recover the previous context--to "get back to where I was." The worst time to be interrupted is when there's the highest mental workload. (Like when I'm in the middle of debugging a method having spent twenty minutes understanding how it relates to five other modules.)

I think it's a mistake, though, to think only in terms of interruptions. A programmer always ramps up when starting (or restarting) a coding session. In other words, we should plan on the first fifteen minutes being devoted to recovering context.

Breaks

I've worked for hours straight, and thought I was being productive. Maybe sometimes I was. But the research shows that regular breaks improve productivity, because the brain needs that time to recover from fatigue.

The Friction

So, where does that leave us regarding Pomodoro?

  • It takes a programmer at least fifteen minutes to "ramp up"
  • A Pomodoro work period is twenty-five minutes
  • That leaves ten minutes or less of effective work time

Well, no wonder Pomodoro wasn't working out!

I have tried the 52/17 cycle. I found the seventeen minute break too long. I read an article where office workers tried it themselves, and it was pretty challenging. I suspect that the original study wasn't looking at programmers....

There are benefits to Pomodoro. The task planning and completion help a lot with emotionally attaching to success, and with chunking down larger items.

Proposal - The 50-10 Time Box

I've been trying this for over a year now, and it's working well for me. So, maybe it will work for you, too. Basically, use Pomodoro Technique but with a 50 minute work cycle followed by a ten minute break. This allows for the fifteen minute ramp up, then thirty-five minutes of solid, focused work. I've found that I'm usually ready for a break at the fifty minute mark.

Even if I wasn't "ready" for a break, when I took it I found I needed it.

I use an online tool named Marinara Timer to manage my time boxes. It has a Custom timer where I configured my cycles.

What do I like about this approach?

  1. It aligns on the hour, making it easy to understand.
  2. I get enough context recovery time.
  3. Four cycles gets me to lunch, the remaing four finish my day.
  4. A ten minute break is enough to take a walk, catch up on email, even have a short conversation. It's an effective coding break.
  5. That break has often helped me solve a thorny problem.
  6. Improves my task estimates.

A complete work session looks like this. I use a Markdown document to track my work sessions, distractions and notes, but paper and pen (or pencil!) would work as well or better.

1. Plan my tasks.

# Distractions

# Round 1
- [ ] Validation rules
- [ ] Unit tests

# Round 2
- [ ] Review code, make sure setting values correctly
- [ ] Improve queries based on understanding of rules

# Round 3
- [ ] Design workhorse feature

# Round 4
- [ ] Begin coding workhorse feature

2. Start my timer.

3. Work deliberately, with intense focus. Record distractions.

It's important to not noodle around during the work time. Manage distractions! This is a hallmark of deliberate practice, and an aspect of meditation and mindfulness.

# Distractions
- [ ] Email from Luis, not urgent but should get back to him soon.
- [ ] Birthday gift research for Joanie.

# Round 1
- [ ] Validation rules
- [ ] Unit tests

4. Check off tasks

# Distractions
- [ ] Email from Luis, not urgent but should get back to him soon.
- [ ] Birthday gift research for Joanie.

# Round 1
- [x] Validation rules
- [ ] Unit tests

4. When the work cycle ends (I'm currently enamoured of the Whoosh sound), take a break.

It can be hard to stop, but do it. And, I recommend walking away from the desk, and/or closing your work windows, so you don't get sucked back into the task.

5. Repeat.

Conclusion

I was spurred to write this post because of this article. The author, Tyler Hakes, gives several examples from his workday of how he reduces interruptions in his day, and it's worth reading.

Below are a bunch of references I read both before and while creating this entry. They include links to the primary research papers that other articles refer to. I've called out some quotes that I found useful.

References

Articles

Papers

When resuming an incomplete programming task, the developer must remember their previous working state and recover knowledge about the software. Details of working state might include recalling plans, intentions, and goals. Details of knowledge might include plan progress, component mechanisms, and domain representations.

Our data suggests that people compensate for interruptions by working faster, but this comes at a price: experiencing more stress, higher frustration, time pressure and effort.

DeMarco reports that the recovery time after a phone call is at least 15 minutes.2 Even though we could not measure recovery time exactly, we believe his estimate to be valid. If more than 10 interrupts occur during a day, the time between the interrupts becomes too short to accomplish product development work.

Work fragmentation as result of interruptions usually demands extra effort to recover and resume pending activities: a study of 24 information workers found that a worker needs on average 25 minutes to get back on an interrupted task [5]. Similarly, Iqbal and Horvitz [6] found that people experience disorientation and loss of context when multitasking. Czerwinsky et al. found that after experiencing work fragmentation people found it more difficult to perform interrupted tasks and took longer to complete them [7].

Flatt's Posts/Casts Review #001 - Job Search, Burnout, Blazor, .NET Core Configuration, Personal Agency, Natural Movement, KonMari in Business

2019-05-20 14:49

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!

Articles

Spark Joy In Your Business With The KonMari Method

https://heragenda.com/spark-joy-in-your-business-with-the-konmari-method
Rieva Lesonsky

2019-05-13 15:43

Notes
KonMari Six Methods

  1. Be committed
  2. Imagine your ideal life before you start
  3. Tidy by category, not location
  4. Discard before you re-organize
  5. Do the easiest things first
  6. Keep what sparks joy

The author discusses applying the KonMari method to your business. She brings up circle good ideas, especially being more mindful and forward thinking.

One thing she doesn't expand on is how to involve staff in applying the method. This seems important to me, so that staff have a strong stake in the outcome.

Note that condo recommends completing an entire category rather than an area. this reminds me of software development where you complete a vertical slice of the feature set.

Quotes

Instead of organizing what you already have, Kondo’s method focuses on getting rid of what you don’t like and don’t need so you’re left surrounded only by things you love and use.

Steps to KonMari for Your Business On her website, Kondo shares the six basic principles of the KonMari method. Here’s how to apply them to your business.

  1. Be committed.

    In order for KonMari to work, you need to dedicate yourself to doing it wholeheartedly. Ideally, you’d complete the whole process over a weekend or series of days. For businesses, that may not be realistic—but you still need to commit to finishing what you start and working through each category completely before you stop. Otherwise, you’ll lose momentum. For example, set aside the weekend to focus on files and documents so you can get it all done in one fell swoop. If you’re getting your whole company involved, think of it as an offsite meeting and set aside time.

  2. Imagine your ideal life before you start.

    Before you start decluttering, take some time to think about what you want your business and life to look like when you’re done. What do you want to achieve by decluttering? Do you want your business to be more efficient, more successful, more enjoyable, more appealing for employees? Kondo’s method places great importance on being mindful, introspective and forward-looking. Thinking about why you’re embarking on this project before you start will help you focus when you begin decluttering.

  3. Tidy by category, not location.

    When you think of decluttering your office, you might start with straightening your desk or cleaning out a file drawer. Instead, Marie Kondo wants you to declutter each category all at once. In the home, this means taking out all your clothing (from the closet, the dressers, the hall closet, the under-bed storage) and going through it all at once. For your business, it might mean going through all your equipment first, then all your paper documents, etc.

  4. Discard before you re-organize.

    After you’ve cleared out your file cabinets or your computer, you might get inspired to set up a new organizational system right away. Don’t! Wait until your entire decluttering process is finished to organize what’s left.

  5. Do the easiest things first.

    Start decluttering with a category that’s easy for you to let go of. For home decluttering, Kondo recommends doing clothes first and sentimental items last, since these are the hardest to let go of. Figure out what’s easiest for you to start with (such as paper documents) before moving onto more difficult areas such as business processes.

  6. Keep what sparks joy.

    The KonMari decluttering method involves holding each item in your hands and asking yourself, “Does this spark joy?” Don’t overthink it: go with your first instinct. Of course, not everything in your office will spark joy (I’m looking at you, ream of printer paper). For such items, ask yourself whether it’s necessary to help you accomplish a task.

You can use this method for a surface-level decluttering, such as cleaning out your emails, your file folders and your receipts. But you can also get much more from it if you use it on a deeper level. Ask yourself these questions:

What sparks joy in your business?

If there’s a certain product, service or focus in your business that brings you the most joy, maybe you should put more energy there.

What if there’s a whole element of your business that doesn’t spark joy?

If you find out something on this level doesn’t spark joy, it’s time to have some serious conversations and do some soul-searching.

Before you discard an item, Marie Kondo says, you need to thank it for its service to you. (Yes—even if you’re getting rid of an old stapler.) The process helps you “let go,” she says. But when you’re decluttering your business, I think you should also thank the things that you’re keeping. Take some time to feel your appreciation for all the elements that help your business thrive, from your employees to your suppliers to your customers.

ASP.NET Core 3.0 Configuration Factsheet

https://www.red-gate.com/simple-talk/dotnet/net-development/asp-net-core-3-0-configuration-factsheet/
Dino Esposito

2019-05-13 15:47

Notes
.NET configuration is a special interest of mine, especially since I created a .NET Full configuration package: NuGet Gallery | DeftConfig 1.1.1

I've looked at .NET Core's configuration before, and, while impressively complete, it wasn't clear what the common scenarios were.

This is a good overview of how configurations work both conceptually and with some implementation. But it doesn't show a "typical configuration" like I'd want to see.

While configuration data is name-value pairs, the resuling configuration can be nested.

The order of the ConfigurationBuilder pipeline determines which configurations win when there are duplicates. Last configuration wins.

Files can be environment-specific, e.g. appsettings.development.json.

The IOptions approach has no explicit benefit over using a POCO (see article for Esposito's reasoning).

Use IOptionsSnapshot<T> to re-get settings on each request. Use IOptionsMonitor<T> to re-get settings if they change.

Quotes

If you check out the Microsoft documentation, you might be frightened by the number of possible ways you can manage configuration data,...

The configuration of an ASP.NET Core application is based on a list of name-value pairs collected at runtime from a variety of data sources—primarily, but not necessarily, one or more JSON files.

All loaded values are composed (aggregated) into a single container.

The root container is an object that implements the IConfigurationRoot interface.

public class Startup
{
    public IConfigurationRoot Configuration { get; }
    public Startup(IHostingEnvironment env)
    {
        var dom = new ConfigurationBuilder()
            .SetBasePath(env.ContentRootPath)
            .AddJsonFile("appsettings.json")
            .Build();
 
        // Save the configuration DOM
        Configuration = dom;
 
        // Next tasks:
        //   - Load the config data into a POCO class
        //   - Share the POCO class with the rest of the app
    }
}

(Three ways to return setting from this JSON)

{
   "print" : {
       "pageFormat" : "A4",
       "color": "true"
   },
   "grid" : {
       "sorting" : "false",
       "search" : "false"
   }
}

var pageFormat = Configuration["print:pageformat"];

var fmt = Configuration.GetValue<int>("print:pageformat");

var fmt = Configuration.GetSection("print")
                       .GetValue<int>("pageformat");

In ASP.NET Core, instead, you can use the Bind method on the configuration root object.

var appSettings = new GlobalAppSettings();
Configuration.Bind(appSettings);

The final step to conclude the first round of application settings in ASP.NET Core 3.0 is sharing the configuration POCO class with the rest of the application. In ASP.NET Core, the recommended approach is using the native Dependency Injection layer. All you need to do is adding the freshly created (and validated) instance of the GlobalAppSettings class as a singleton.

var appSettings = new GlobalAppSettings();
Configuration.Bind(appSettings);
services.AddSingleton(appSettings);

IOptions approach:

// the code below belongs to the ConfigureServices method of the startup class.

services.AddOptions();
services.Configure<GlobalAppSettings>(Configuration);

public DemoController(
             IOptions<GlobalAppSettings> options)            
{
   Settings = options.Value;
   ...
}

IOptionsMonitor<T>

var dom = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", 
                         optional: true, 
                         reloadOnChange: true);

The ideal approach is to learn the absolute minimum you need to know (which means how to load the configuration as an immutable singleton in a C# POCO class) and then look around in case more is required or would be good to have.

Podcasts

Art of Manliness #507 - How to Increase Your Personal Agency

https://www.artofmanliness.com/articles/increase-your-personal-agency/

2019-05-14 16:15

Notes
Kids are growing up with more structure, and if the encounter situations where the rules aren't obvious they flounder because they haven't learned to be self-reliant.

Men are falling behind women in terms of adaptation and agency.

Quotes

From the podcast: "Paul explains what he means by agency, and why learning how to get better at thinking, acting, and making choices for yourself can be the real key to feeling less stuck in life."

When our minds and bodies are in balance, our decision-making improves, and when our decision-making improves we then create a life that's more in line with matters to us.

Separate your thinking and deliberation from your taking action, especially on important decisions.

When you're saying yes to something, you're saying no to something else.

The 7 Principles

Behavioral

  1. Control Stimuli
    • Put phone away. Don't let devices determine your attention.
    • When you want to reach for device, get up an move instead to recharge.
    • Monotask, don't multitask.
  2. Associate Selectively
    • Mirror neurons help us pick and mimic those around us.
    • People closest to us have enormous effect on our level of agency.
    • Isolation is like kryptonite.
  3. Move (using your body, nutrition)
    • Movement increases brain activity.
    • We're built to move, and we're too sedentary.
    • Pay attention to body and be in top shape. Some men take better care of their cars than their bodies.
    • Sleep deprivation reduces IQ.
    • When sitting, we communicate "I'm stuck," leading to learned helplessness.
    • Get outside.

Cognitive

  1. Position Yourself as a Learner
    • When we're well-informed, we make better decisions.
    • Identity your learning style [clf: Hopefully not the discredited visual/aural/etc].
    • More than 50% of jobs existing for kids born today won't exist when they become adults.
  2. Manage Your Emotions and Beliefs
    • Emotions are the strongest things happening in our heads.
    • Have your emotions, rather than your emotions having you.
    • Beliefs are better off when we question and update them over time.
    • Values tend to be bedrock things.
    • If we navigate the world with outdated beliefs we don't make better decisions for ourselves.
    • Understand how beliefs and emotions affect our thinking.
  3. Check Your Intuition (what does my gut tell me?) *
  4. Deliberate, Then Act
    • Decision-Making
    • We don't get training in making decisions, despite making decisions effectively determing who we are.
    • Daniel Kahneman, Amos Tversky research on decision-making.
    • System 1 thinking: fast thinking
    • System 2 thinking: deliberate, rational, analytical
    • Acting:
    • Four large impediments: procrastination, impulsivity, obsession, perfectionism

References

Art of Manliness #508 - Break Out of Your Cage and Stop Being a Human Zoo Animal

https://www.artofmanliness.com/articles/podcast-508-break-out-of-your-cage-and-stop-being-a-human-zoo-animal/

2019-05-15 20:49

Interview with Erwan Le Corre, founder of MovNat physical fitness system and author of The Practice of Natural Movement: Reclaim Power, Health, and Freedom

Notes
This is a quick summary of a long interview (1h 18m, ouch!). The reason I can do this quickly is I have a pretty good understanding of Le Corre's approach and source for his method.

His Natural Movement means to practice the kinds of movements that are part of homo sapien's two to three hundred thousand-year-old heritage, specifically: walking, running, balancing, jumping, crawling, climbing, swimming, lifting, carrying, throwing, catching, and self-defense.

These are almost exactly the same skills that made up George Hébert's "la méthode naturelle": walking, running, equilibrium (balancing), jumping, quadrupedal movement (crawling), climbing, swimming, lifting, throwing, and defending.

There are only two skills added: carrying and catching, both of which make sense to me.

Hébert was influenced by what came before him, and his method is a key inspiration for parkour.

MovNat seems to be a professional system, complete with certifications. While it's a business, it doesn't strike me as a sloppy scam. Listening to Le Corre, it's clear he's invested in helping people improve their health, and he has a solid athletic background.

He makes a good point that athletics--especially movement responding to an unpredictable environment--improves cognition and problem-solving. Fencer Aldo Nadi said the same thing, that fencing made a person smarter.

Quotes
Not many quotes this time. But I like Le Corre's plain-speaking on some subjects that isn't rude or arrogant. For example, on reducing the amount of recess in schools--or making equipment "too safe"--because of liability, he says, "It's criminal. It's just going to kill the kids even more. It's going to kill their physiology to begin with...there are windows of physiological development and if you miss them it's hard to catch up.... What's needed [at a certain age] is not only proper nutrition, it's also proper movement.... I'm saying this with sadness."

(On doing natural movements while you're in your normal day)
"You see, it does not take time off of your occupations because you can do it [natural movement] as you do what you need to do. It doesn't cost any money, it doesn't cost time. It costs very little energy, actually...but it's beneficial not only to your physiology but it's beneficial to your work."

References

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

2019-05-15 22:48

Notes

This episode was appropriate for me since I'm between jobs--"under employed," as my mom says.

Summary of the 3 Principles

  1. Jobs are about relationships

    • Most jobs are found through previous, current, or new relationships.
    • The hiring process is very human. The evaluators have the same biases you do. They can be affected by not having eaten breakfast that morning, for example.
    • It's not a computer on the other end that's ultimately going to decide.

  2. Your job search is an evolving and continous process, not a discrete process with a single outcome

    • Determine your values.
    • Don't hold yourself to one particular title.
    • Most of the time, the opportunity to be fulfilled in your job will come again.

  3. Environment-first thinking

    • Depending on your environment, you happiness in a job can vary greatly.
    • Ask yourself questions about the environment just as much as about skills, title, compensation and people.

      It's very possible to work with people that you admire and respect, but because the environment has been cultivated in a particular way you end up being miserable.

    • Are my values tolerated/respected in this environment, or will I have to suspend my values?
    • Are you safe? Will you grow?

Quotes

The job market is, unfortunately, fairly inefficient. We haven't figured out how to align job candidates with their prospective perfect job.

We may not know what we want, and the person posting the information...may not be describing the job well.

If you stray away from these principles, [finding a job] is going to get harder.

These are really principles of working, as well.

People don't get jobs on their first shot, and you're probably not going to be an exception to that.

Developer Tea 20190517 - 3 Red Flags That You're Heading for Burnout

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

2019-05-17 16:47

Notes

Myths of Burnout

  • It makes you a bad worker.
  • You have to hate your company (or job, or manager, or coworker) to feel burned out.
  • You have to be overworking to become burned out.

Being burned out is a combination of factors.

  • Having a negative perspective on your work or workplace.
  • Don't feel fulfilled.
  • Exhaustion. But doesn't have to mean you're overworking.

3 Red Flags

  1. Your motivation is almost entirely external.
    For example, you're only motivated by the money, or threat of losing your job. You're more likely to game the system.

  2. You find it incredible difficult to focus.
    Have more and more trouble focusing. Procrastinating.

  3. Your work is becoming progressively worse.
    Not ups and downs, but always going down. This triggers a negative loop.

Solution? This episode doesn't go into depth, but notes that work needs to coexist with home in a balanced way. They need to enrich each other.

Quotes

We can feel that by becoming burnt out we've somehow done something wrong. That we've made the choice to feel burned out, or that everyone else has a longer fuse that us and we are somehow isolated in our feeling burned out.

If you set your hours at forty hours and you're exhausted at thirty-five, no matter how hard you try to not be exhausted, perhaps in spite of you trying to not be exhausted, you're likely to become even more exhausted.

Nobody strives for burnout.

Our internal motivation is a much stronger motivator than external motivator.

The .NET Core Podcast #25 - Blazor - You Want to Run .NET Where?!

https://dotnetcore.show/episode-25-blazor-you-want-to-run-net-where/

2019-05-19 18:40

This is a short, fast--almost blazing(heh)--version of a talk1 Jamie gave to a user's group about the history of web applications leading up to Blazor: .NET running in the browser.

Which, as James Taylor says frequently, is nuts. But it's working. I'll leave you to listen to the nuts and bolts, but here's the top level:

  • Blazor is a .NET web frameowrk which runs in the browser.2

  • Blazor relies on WebAssembly

  • WebAssembly:

    WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

    "In summary, high level languages can be compiled down to WebAssembly and run in the browser at native speeds"2

  • Blazor was created by Steve Sanderson.

  • Blazor uses the Mono runtime.

  1. Blazor - An Introduction - Slides from Jamie's Presentation↩

  2. What is Blazor and why is it so exciting?↩↩

Newer   Older