A pleasant walk through computing

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

Remote Micro-Exclusions: Two Poor Daily Standup Practices

Remote (Micro) Exclusion

"Remote exclusion" happens when remote developers are treated as less equal than on-site developers. This usually isn't intentional, but is instead a result of group dynamics.

Some behaviors, such as not including remote workers in decisions because it's "too much of a bother" to contact them, are obvious when pointed out. But there are other actions that seem innocuous, yet contribute to the problem. These are"remote micro-exclusions"

Consider the daily standup meeting where the bulk of the team is on site, and a few are remote. Here are two practices that can unconsciously devalue the remote team.

No Video

There are three basic ways to communicate with the remote team in a live meeting.

  1. Audio Only
  2. One-Way Video
  3. Two-Way Video

The first two ways are a problem.

  • Audio Only: Unless someone on the remote team is vociferous, they'll be ghosts, rarely seen nor heard.
  • One-Way Video: To my mind, this is worse than audio-only. The implication is, "they can see us, be we don't need to see them." The on-site team only see their avatars, at best.

What's critically missing without two-way video is the visual cues. How is the remote team reacting? What are they seeing at the main site? What is everyone communicating physically?

Two-Way Video is a must because, "if words and body language disagree, one tends to believe the body language"1 And in those cases, body language can be 55% of communication.

Remote Team Last

If the remote team always goes last, it's likely they'll always have less time. Unless a daily standup is being run really strictly, there's going to be conversation about whatever each developer is working on. If there's no two-way video it's worse. The "main" team will tend to dominate the conversation because they can see each other. Consider that for a team of eight, a fifteen minute standup gives each person two minutes. That's honestly plenty of time to report what happened yesterday, what's being worked on today, what's blocking, getting quick answers, and setting up follow ups on issues that take too long for the meeting.

Yes, this is a standup management problem. "I'll email you to schedule a talk" should be said frequently. But the remote team is still devalued by going consistently last.

Solutions

  1. Everyone must be visible on video. Work as if everyone is remote.
  2. Start standups with the remote team for a week or two, to remind everyone they're equally important. Then, randomize the order people go in.

Remote work can benefit many companies and employees. It takes effort, but is a worthwhile practice to learn.

References


  1. Albert Mehrabian’s 7-38-55 Rule of Personal Communication It should be noted that these oft-quoted ratios have their limitations and critics.

Memstate: The Practical Argument for Big, In-Memory Data

Today I listened to a fascinating episode of Jamie Taylor's The .NET Core Podcast, featuring an interview with developer Robert Friberg. Do listen to it.

Friberg and his team have been working on Memstate, an in-memory database. When I first started listening, I thought "this sounds like one of those interesting, technical edge-cases, but I'm not sure I see the point." By the end, I not only understood, I wanted to start using it! But since I don't know how soon that will happen, here's the compelling meat.

Relational databases solve a problem that doesn't exist anymore. That problem is limited memory relative to dataset size.

Your OLTP data can probably all fit in RAM.

Here, simplistically, is how Memstate looks compared to a relational database.

In a relational database, the data is: Read into Memory > Changed in Memory > Saved to Transaction Log > Saved to Storage > (Potentially) Reread into Memory

In a memory image, the data is: Already in Memory > Changed in Memory > Change is saved to Transaction log

The idea of keeping all needed data in RAM has been around for awhile. Friberg recommends reading Martin Fowler's description of the pattern, and so do I. This tidbit helped me grasp how common the concept is:

The key element to a memory image is using event sourcing.... A familiar example of a system that uses event sourcing is a version control system. Every change is captured as a commit, and you can rebuild the current state of the code base by replaying the commits into an empty directory.

I think this is fantastically straightforward. Why persist state on every write? Why not just persist the change, and keep the state in memory? In the past, the answer was "We can't fit all the data into memory, so you have to read it each time." But as Friberg points out, you can configure an Azure virtual machine instance with 1 terabyte of RAM!

Friberg is clear that this method, like any, shouldn't be applied to all use cases. He nicely points out that even if you kept, for (his) example, all of IKEA's inventory levels for all its warehouses in memory, you wouldn't keep all the product descriptions and images. Consider what we already do today with blob assets:

  • We don't (typically) store images in version control. We reference it externally.
  • We keep images in cache because it's static.

(And, of course, it also doesn't mean you couldn't keep that data in memory.)

Imagine if your order entry system data was running fully in memory. Now, ask--not rhetorically--could it? The answer will very likely be yes.

What happens if you need to perform maintenance? Surely it would take forever to replay all those millions of commands (transactions).

Friberg gives an example where a very large dataset could be loaded back into memory in about ten minutes.

Finally, while most of the podcast discussed big data, I wonder about small data. One of the persistence stores for Memstate is--you guessed it--a file. I think this would be a great solution for any app that needs a small database. The state would load fast, the app would run fast, and there wouldn't be any of the overhead of using a database engine.1

Want to go a step further? If the store is a file, and if the amount of data isn't huge, and if absolutle top performance isn't necessary, then I'll bet the transaction information could be stored as plain text. And this means your data and history are future-proof.

And that's how I like my data.

References


  1. Not that, for instance, SQLite is big. I think it's just a .dll.

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.

   Older