Blasphemy? Maybe.

Read on for 2 changes in your meetings to engage and include your remote workers.👇

Meetings are already a waste of time, why wouldn't you want to minimize the time we are all stuck on one?

I've been doing the remote work thing for over a decade. Bear with me on this one.

1. Expect and accept small talk

It's important to remember that remote workers don't have the luxury of water-cooler talk. There's no direct equivalent to chatting with someone in the hall.

Zoom meetings are one of their few human-focused, face-to-face interactions.

Even remote workers need an opportunity for small talk.

To build camaraderie, you need unstructured conversation. By allowing, and expecting, this to occur in your meetings you empower team bonding.

2. When the conversation diverges, give it a chance

And let's not forget the benefits of serendipity.

Sometimes an unexpected topic comes up. With devs, it's usually a bug, feature, or design decision. The original conversation prompted someone to pivot.

Allow that pivot. Let the conversation flow.

This isn't an endorsement for derailing every meeting, dodging the original topics, or dragging things out to the detriment of everyone on the call.

It is a call for intentionality in allowing the team to interact, in a human-centric way.

With their voices, expressions, and emotion. All those things missing from Slack (regardless of how many emojis you use).

TLDR;

1. Expect and accept small talk
2. When the conversation diverges, give it a chance

Making these two changes to your meeting will give your remote workers a chance to bond with the rest of the team.

Don't deny them that.

#devp #remotework #crosspost #ship30for30

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

Even the title of this essay is hard to wrap your head around.

But as someone who has built systems on DynamoDB where sub 8ms response times were maintained well past 5T (yes, trillion) records, I can tell you both the title and the concept are worth learning. To do it, you'll need to approach modeling from a different point of view.

Thankfully, there's some excellent resources available. Start with these three.

1. Official DynamoDB Docs

The name is “Best practices for modeling relational data in DynamoDB”, from the AWS docs themselves. Covers a common, recognizable order entry and HR schema, showing the traditional relational model, and then an example of how to reapproach it with an access patterns mindset.

2. Alex Debrie's one-to-many

Through showing strategies for modeling and querying the most common relationship in a relational data model, Alex hits multiple bite-sized samples. Most devs who have used SQL will have the wheels start turning on how to connect this to more complex schemas they've worked with in the past.

3. trek10 Blog Post

Much respect for tackling the Northwind DB as their example. If you've been through a few SQL tutorials, you'll recognize that name. And if you've been reading my earlier DDB posts, the video at the start of the post should look familiar.

These three resources will show you the possibilities of thinking about your relational data models differently.

Still stuck wrapping your head around a concept? Let me know in the comments.

This was the Day 23 #ship30for30 #atomicEssay.

#dynamodb #aws #crosspost

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

When I'm giving demos to or pairing with other devs, they inevitably ask how I put together my workflows and tooling. It, usually, appears smooth and effective. Everything from mnemonic shortcuts in my terminal to instantly opening the AWS console to the right account. I can thank two habits for building and keeping my workflows going.

1. Keep a Friction List

As I'm working throughout the day, whenever there's a little hiccup or annoyance in my workflow, it goes on the Friction List. My natural inclination (and desire for procrastination) says to stop and fix it immediately. But in the spirit of GTD I send it off to a trusted system, knowing I'll circle back to it eventually.

Here's a small snippet of things currently on it:

• no auto format on save for lua
• ave should default to target1 acct
• fuzzy directory jump history doesn't sync between laptops
• nested cdk dir changes nvim file listing context
• vaulted doesn't support image sharing

Each of these has at one point or another annoyed or impeded my flow. Tiny to significant bits of friction that once removed, give back precious seconds to minutes of my day. Capturing them as they occur is a start, but it isn't enough to stave off the desire to fix them all. For that, I need to...

2. Review and improve for 15 minutes each week

Doing is critical to actually improving.

Each week, 15 minutes of dedicated AM time is spent reviewing the list and making progress on something. It could be a quick new shortcut, or planning out the next feature on a side project.

Any action is fair game, so long as it makes progress on the list.

Now it's your turn. Do you track the friction in your workflow? If not, how do you know what to improve?

This was the Day 24 #ship30for30 #atomicEssay.

#devp #crosspost

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

There are a lot of videos and blogs about DynamoDB.

And I've watched/read more than I care to admit. While most hit the basics, they tend to miss out on the advanced, real-world application. And very few give that [Keanu voice] “Woah” moment.

But the #1 must watch video on DynamoDB I've found is Advanced Design Patterns for DynamoDB by Rick Houlihan. (Plenty of Woahs waiting in this one)

Here's a teaser of what it covers:

1. Real, concrete examples of relational data modeled in DDB.
2. Partition Key and Secondary Key deep dives & best practices
3. Examples of mixing different data types in a GSI (Index Overloading design pattern)
4. Access pattern analysis from one of the best in the biz.
5. An example with a dozen access patterns supported by two GSIs on a single table. 🤯 One of the single best aha moments of any DDB resource around.

And so much more ...

Honestly, this video changed my perspective and continues to influence each of my DDB designs. Sometimes you just have to see the examples put to practice to really understand the power. Why not learn it from a master of his craft?

If you are at all interested in DynamoDB, do yourself a favor and clear your calendar to give this a watch.

This was the Day 22 #ship30for30 #atomicEssay.

#crossPost #dynamodb #aws

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

Choice of persistence stores has an outsized impact on project design.

Having architected many projects for the cloud, I've wrestled with “which persistence” too many times to count. But it is a decision that needs to be made early and thoughtfully.

Applying these 3 questions quickly narrows down the choices.

1. Is the domain model highly normalized and relational?

While most developers will automatically say yes, they're wrong.

In my experience, this is very rare. These designs are usually because of a team's existing relational experience and mental models. Not actually because the domain needs it.

But, if your domain really is highly normalized data, don't think twice. Go relational.

2. Is it cloud native?

If your project isn't already taking advantage of cloud native features, forcing in Dynamo might bring more pain than value. Think traditional web frameworks with built-in ORMs, apps on steady EC2 servers, and similar designs.

On the flip side, if you're already living with fine-grained IAM permissions, async processors off SQS, or highly variable connections (like Lambdas spinning up and down), Dynamo will fit right in.

3. How well do you know the access patterns?

DynamoDB shines when you use access-patterns-first design.

Always start with access patterns. If you don't know them, figure them out. If you can't, because they are truly unknowns, choose a relational DB.

Starting with access patterns will lead to a very different design than data model first.

And often times forcing a decision about the access patterns leads to changes in the application design. That's a good thing.

Notice, I didn't talk about cost, scaling, or high-availability requirements. More often than not, the prior three questions bring an answer before bridging these topics. But if you're still on the fence, those are the next design decisions to make.

Drop a comment if you've struggled with the decision or have different criteria for picking persistence.

This was the Day 21 #ship30for30 #atomicEssay.

#crossPost #dynamodb #aws #serverless

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇

I'm an avid believer in developers always having a side project.

As a dev with ~200 repos on GitHub, many of them private, you could say I've worked on a few. Some big, some small, some were a few days effort and others have been going for years. I keep going for two reasons.

1. You need a safe space to experiment

Under heavy pressure to finish before a deadline is not the time to try out a new framework. Or deploy to a new platform. Or bring in a language you've never used.

But as a dev, you need to explore to improve.

Years ago I used to say the blog is my lightsaber. Something I'd craft myself, test out crazy ideas, and generally a thing for focused play. As the blog has become a commodity, side projects became the perfect opportunity to dabble.

2. There's more opportunities to up-level your skills

Often times as engineers we become known for specific domains or skills. A Golang, Java, Backend, React, Functional, or [fill in the blank] developer. While that's not always a bad thing, we're best served by branching out.

Gaining broader, full-stack experience makes us better at our day to day.

Maybe your place of business is an AWS shop, but you never touch anything cloud related. Why not try deploying your side project to Lambda? Or use a non-relational store like DynamoDB, when your work projects only ever use Postgres.

Each tech stack and new mental model learned in our side projects expands our ability to understand complex systems.

Take advantage of that! Be intentional with your growth. Find something that meets your Rule of 3, and give it a run while scratching your own itch.

Remember, Always Be Coding, even if it is just a toy project.

This was the Day 20 #ship30for30 #atomicEssay.

#crossPost #devp

Thanks for reading. If you enjoyed the article subscribe via RSS feed or enter your email in the box below 👇