A pleasant walk through computing

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

Grammar for Developers - Apostrophes: 3 Simple Rules, 3 Common Mistakes

It's a truism that (many) developers are not good writers. And it's not just style or composition, it's grammar. This has always puzzled me, since if a programmer makes a grammar mistake (using a backtick instead of an apostrophe, for instance), the program won't run. Maybe the problem is that they don't pay attention to the red squigglies in Word.

Arguably the worst error I see is wrongly using an apostrophe when "its" is possessive. Here's a sentence to illustrate. Every apostrophe is correct.

Harvey's car's in the shop to have its radiator fixed before it's blown to bits.

Expand the contractions and the differences between possessives and contractions are clear. Harvey's car is in the shop to have its radiator fixed before it is blown to bits.

Here are three rules that, if followed, would take care of about 70% of the most grievous errors I see in blog posts, emails, business proposals, and technical documentation.

I even made a fancy PDF.

Grammar for Developers - Apostrophes

3 Simple Rules

  1. Never make a pronoun possessive using an apostrophe
  2. Always make a noun possessive using an apostrophe
  3. Never use an apostrophe with a verb

3 Common Mistakes

Right: Unit testing has its benefits.
Wrong: Unit testing has it's benefits.

Right: Carol's code is clean. Her code's style is precise.
Wrong: Carols code is clean. Her codes style is precise.

Right: He runs that backup every day.
Wrong: He run's that backup every day.

Terms

A noun is a specific person, place, thing or idea: Carol, France, house, radish, memory, Chipotle.

A pronoun is a generic, non-specific person or thing. These are the common pronouns: it, he, she, her, them, they.

A verb is an action taken by the subject. He codes. She tests. They demonstrate.

Weekly Sugar: 'Accelerate', the Best Book About DevOps

I run a Meetup called Coffee. Quiet. Code. I want to encourage developers to work together in the same casual space without having to discuss anything or even interact much. It could be seen as a far less rigid version of Mycroft Holmes' "Dionysus Club", a way to enjoy shared community.

My inspiration came from people, often strangers, reading together in libraries, and also the sweet memories of my whole family reading their separate books they received as holiday gifts. In that spirit, here's a book recommendation.

Accelerate: The Science of Lean Software and DevOps is exactly what it claims to be: high-quality, peer-reviewed research answering the practical question "What's really working in software development across all industries and team sizes?" There are plenty of opinions out there on DevOps. This book deals in facts.

I wrote an extensive book summary for a client, which you'll find on my web site.

'Accelerate' Book Notes And Quotes | Software Meadows

Flatt's Posts/Casts Review #003 - Incentives, Emotions, Diversity, and Applying Bodyguard Training to Coding

2019-05-23 to 2019-06-16

I'm still in the discovery period for how to present my summaries of the articles and podcasts I read over a period of time. While I'm hoping the information is useful to others, it's primarily for me to A) continue learning, and B) look for essential patters in the material.

This week I'm going to present what I think are the top-level ideas across all the material, and the top ideas for each episode. This should make the information easier to digest.

But, since I highlighted it in the title, here's the link and notes on the Bodyguard podcast and how I'd apply them to development.

Art of Manliness #513 Be Your Own Bodyguard

  • These are self-defence principles, and apply to potentially dangerous situations. But note how they also apply to coding!
    • Avoidance is the most important thing you can practice. (testing)
    • Deescalation is the next most important. (find/fix bugs fast)
    • Where are your exits? (version control)
    • IF there's a fight, what are your three or four "go to techniques you practice all the time"? (logging, alerts, debugging)
    • Regularly simulate and practice stress situations in class. (disaster testing)
    • Learn from people who've experienced it. (involve users)
    • What's the legal impact?

Essential Learnings

  • Align incentives
  • Emotions drive our decisions
  • Study multiple subjects (generalize) and apply to your specialty
  • Diversity is highly beneficial

Podcasts

Leading Agile - What is a Well-Formed Backlog? w/ Jeff Howey

  • Creating clear characteristics of a well-formed backlog is valuable
  • Keep the criteria simple and short as possible
  • Define the terms and make sure everyone understands them. (Publish)
  • Howey's characterstics: Clearly Prioritized, Linked to What's Important, Shared Understanding, Identify Dependencies, Clear Acceptance Criteria, Clear Definitions of "Done" "Ready", Good Enough to Start a Conversation

Art of Manliness #511: Mastering the Psychology of Investing

  • We think bad things happening are dramatically less likely than good things.
  • "The more complex and dynamic a system is, the more simple your solution needs to be."
  • "There's a weak correlation between knowing the right thing to do and actually doing it."
  • Our decisions are strongly influenced by our bodies and emotions. Don't code upset!
  • Humans are terrible at probability. They tend to reason in group terms, and conform to the group.

Art of Manliness #512: Why Generalists Triumph in a Specialized World

  • Tiger Woods specialized. Roger Federer generalized until his twenties when he settled on tennis.
  • The "ten thousand hours to become an expert" research examined specific fields that, it turns out, yield well to early specializing.
  • Most of the time kids are better off delaying specialization.
  • Generalists are better at new situations because they can synthesize and apply previous experience.

Developer Tea - Mental Models w/Gabriel Weinberg Part 1
Developer Tea - Mental Models w/Gabriel Weinberg Part 2

  • Book of 300 mental models, i.e. "fancy word for concepts"
  • Models Weinberg thinks managers/developers often miss:
    • Opportunity Costs: "The cost of what you're working on is what you're not working on."
    • Forcing Function: "Scheduled process to force everyone to think critically."
  • Find root cause using the Five Whys Model, asking "why?" until getting to the root
  • "I want to do this thing not because it's imporant, but because it's more important that all these other things."

Developer Tea - 3 Assumptions That Can Hurt Your Job Search

  1. When you get turned down that means you are incapable of doing that job.
  2. Someone is going to read your whole resume.
  3. Applications to jobs are how people get jobs.

"Imagine you're trying to find a job without job boards being available. What else can you do to find a job?"

Developer Tea - Aligning Incentives w/ Lambda School CTO - Ben Nelson (part 1)
Developer Tea - Aligning Incentives w/ Lambda School CTO - Ben Nelson (part 2)

  • Lambda School doesn't charge tuition for its education, and only makes money when its graduates get a job.
  • Very high bar for getting in. They're looking for grit.
  • Incentive Alignment. Both sides are working toward the same goal, and only succeed if the goal is achieved.

Hanselminutes: How to build an inclusive conference with Saron Yitbarek

  • Codeland Conference
  • Yitbarek's goal in the conference is to celebrate coding, not the tools, and to be the most inclusive conference.
  • She mentions a study of people who do/don't finish computer science degrees. Those who do have a higher threshold for confusion.

Science Vs. - How Bad Science Killed A President

  • Garfield died two and a half months after being shot
  • Among those who tried to help were Alexander Graham Bell with a new invention: a metal detector!
  • Despite Joseph Lister lecturing about bacteria and how to kill them for five years, doctors still don't believe it.
  • So, basically, the doctors are digging around in Garfield's body with grubby hands, causing infection.
  • Nine years later, partly due to Garfield's death, doctors believe in germs and are sterilizing everything.

Growth Mindset #59 - The World of Martech - Scott Brinker

  • One interesting comment was that Brinker thought marketers had an easier time experimenting--such as using A-B testing--that developers. (He was talking about the idea of Agile Marketing.)

Developer Tea - Test Driven Meetings - Measuring Outputs and Side Effects

  • Look at a meeting as if it's made up of methods. A one-on-one meeting might have a "feedback function," which is a unit test idea. So look at the inputs and outputs.
  • But we also want to look at meetings as integration tests. What are the side effects, both positive and negative?
  • Here's what Jonathan suggests in trying to apply the idea
    1. Before the meeting, write down the outputs and the side effects that you desire from the meeting.
    2. Announce the outcome(s) and side effect(s) at the top of meeting so everyone is oriented toward them.

Art of Manliness #515 - Aristotle's Wisdom on Living the Good Life

Developer Tea - How Can Two Rational People Disagree?

  • Given the same data, the frame parameters are different.
  • Example: Choosing between a bug or feature. Developer says feature because his frame is long-term. Manager says bug because his frame is short-term. Both are rationally good choices given the data.
  • Often, in conflict, desires and incentives are the same.

Growth Mindset - Doing the Difficult Thing - Dr Niall McCann

  • Inspiring and humbling. The guy's amazing.
  • Find out what motivates those who can help you attain your goal, AND
  • Align their incentives to yours.
  • Do what you're doing first because you enjoy it. But also show how success has layers of benefits. Example: McCann's organization protecting a swathe of land not only prevented mass killing of elephants, but also raised local employment, the success increased donorship, and tourism increased because the animals were there to be seen.

You're not really a conservationist unless you've conserved something.

Art of Manliness #516 - How to Lead an Unstoppable Team

  • Mills is fantastically clear
  • You have to lead yourself first before you can lead others.
  • Building a team means building relationships, which involves feelings.
  • The CARE Loop
    1. Connect The real goal in connecting is to build trust.
      Three tools: communication, commitment, credibility.
    2. Achieve Set direction.
      Five A's: Aspiring (which he's using like "inspiring"), Assume they can do the job, Assess what they're doing, Appreciate their efforts internally and externally, and ????
    3. Respect Goal of respect is contribution, and requires mutual respect. To get everyone contributing their ideas, skills, etc.
      Want people to be willing to say "I made a mistake," then answer three questions: what happened, what I was trying to achieve, what I'm going to do about it.
    4. Empower Getting people to think like owners.
      Three Es: Educating, Enabling, Engaging

Sciene Vs. - SHARKS!!!

  • Top speed of Great Whites, in just a couple of tail flicks, from 1mph to 25mph.
  • Sharks cannot smell blood in an Olympic-size swimming pool. They smell as well as other fish.
  • From 2010-2012, more people died from TVs tipping over onto them (51) than from shark attacks (3). 124 shark bites.
  • There's no such thing as a rogue shark (like Jaws).
  • One quarter of shark species are threatened with extinction...including the Great White.

.NET Core Podcast #27 - Blazored with Chris Sainty

"What's so great about Blazor?"

  • Ability to write truly full stack applications using just C#
  • Opens up using NuGet instead of waiting for a new javascript framework's ecosystem to build up.
  • On security of running a C# dll in the browser, Chris points out WebAssembly runs in the same sandbox as javascript. So, no more or less secure than javascript.
  • But, it's still in early development. Not ready for general production use.

Whenever we take on a dependency into our applications, if you're taking on someone else's code, you're always taking on a level of risk, and it's up to you to assess that level and go from there.