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 👇

Today I eliminated that excuse.

Since I've been cross-posting each atomic essay over to my blog*, I have a lovely RSS feed to use as a trigger for automations. Here's how I turned an RSS feed into nicely formatted LinkedIn posts and eliminated my excuses.

The magic is in the Pipedream.

Think IFTTT, but with code to do the dirty work. I've barely touched it in the past, but thanks to good docs I was up and running in <20 minutes, reading included.

Essentially you just need to create a workflow with 3 steps:

1. Trigger – New Item In Feed

Add a trigger with the RSS New Item in Feed component and an RSS source pointed at your blog's feed URL.

2. Code – The Magic

For the entries received from my blog, there will be a Title and an encoded content block with HTML. We want to turn that content block into an automatically formatted text (line breaks, UPCASING for headers, etc), prefix it with the title, then send that to LinkedIn.

Pipedream sets itself apart with the ability to write Nodejs, with modules, as a step. Add a step of Node –> Run Node Code.

Grabbing the html-to-text package and a little bit of cleanup (my blog always includes an email signup form after the last <hr/> that I want removed for LinkedIn) this was trivial. Full code of the step:

import { convert }  from 'html-to-text';

export default defineComponent({
  async run({ steps, $ }) {
    const title = steps.trigger.event.title;
    const body = steps.trigger.event["content:encoded"]["#"]
    const html = body.slice(0, body.lastIndexOf("<hr/>"));

    const content = convert(html, {wordwrap: false});
    $.export("content", title + "\n\n" + content);
  },
})

3. Action – Post to LinkedIn

Posting to LinkedIn is a prebuilt action in Pipedream.

Simply add the Post to LinkedIn step, configured for type Text (not Article), Public Visibility, and Text set to {{steps.code.content}}. Voila, automatic posting, with nice formatting.

As easy as this was, I think I need to explore more use cases with Pipedream. If you use it, or something else, I'd love to hear what excuses you eliminate through automation.

• I know, ship30for30, no blogs, blah blah. But I need a place for long form writing, owning my content library links, and The Blog is my Lightsaber. Future post coming on that last part...

This was the Day 17 #ship30for30 #atomicEssay.

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

Luckily, learning it doesn’t have to be like drinking from a firehose.

I was just a kid when I first picked up Vi. And after 30 years of Vi & Vim, with 10 straight as a primary editor, I have a few suggestions for new vim-ers.

Eat the elephant, one bite at a time

Time and again, when I’m helping someone who has tried and failed with Vim, the loss in early productivity is what scared them away. They tried to get comfortable with all the motions, plugins, everything all at once.

What they should have done is pick one feature and use it ’till it’s normal. Then repeat.

Example: Don’t do every motion all at once. Start by getting comfortable moving by Words with W and B. That’s it.

Don’t worry about anything else for a few days. Work it like a (mostly) regular editor, except when using the word motion.

Do the tutorials

Start with vimtutor. For Neovim, use nvim +Tutor. That’ll get you the basics, and ready for the next step.

the average user needs something more than vimtutor and less than the help manual.

After vimtutor, move to Learn Vim: The Smart Way, where that quote comes from.

Add plugins slowly

Nothing wrong with starting with one of the beginner configuration bases, like kickstart.nvim or Neovim from Scratch. Also use other people’s config as inspiration. Just don’t pull them in blindly, all at once.

Pick one, get comfortable with it in your workflow, and then add another.

If you’re going to code, I’d suggest coc.nvim or nvim-lspconfig as soon as you’re ready. They both enable VSCode-like IDE power through the magic of LSP servers.

If you go slow, you’ll be productive faster. Don’t rush it.

This Day 16 #ship30for30 #atomicEssay was shipped with this tweet:

Day 16 of #ship30for30

Learning the ultimate editor (Vim) can seem daunting. Take a few tips from a long time user to ease the process. pic.twitter.com/iGY6K7vJSV

— bkono ? (@bkono101010) October 31, 2022

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

Don't worry, I'm not looking for a Vim vs Emacs comments war (it would be a slaughter anyway 😆). I know full well how productive other editors can be. There was even a time I played rockstar coder armed with Visual Studio and Resharper.

To each their own. But for me, the right choice is Vim and its variants.

If you've never given it consideration, here's a few of the reasons I think it's amazing:

Less memorizing, more mnemonics

By most measures, I'm a keyboard junkie. But even I forgot if that shortcut was ⌘-⌥-S or ⌃-⌘-S. Vim let's me skip the modifiers and focus on mnemonics.

Go to References is simply gr with my cursor on a symbol. Easy peasy.

Your hands and wrists will thank you

Years ago I had brutally painful, early carpal tunnel.

Turns out, modifier keys, even remapped to better locations, are not my friend. The stretching of the fingers caused too much stress. Since switching to Vim, this is gone.

I hardly ever need a modifier beyond the Control key, and with that mapped to Capslock, there's no stretch needed. It took many hours of wrist, forearm, and grip training (thanks deadlifts) to recover.

A Vim a day keeps the Carpal away.

Modal editing is amazing

Most of our time is spent reading and navigating code.

Modal editing is natural and very powerful. But it isn't something that can be explained, only experienced. Give it a couple weeks and you'll love it ... or hate it. But you'll understand either way.

As simple or complex as you want

Zero plugins, or over-powered-IDE, Vim has you covered.

Integrate an LSP server and you have all the power of VSCode. Add as many features and snippets as your heart desires.

Or don't. It'll still be an exceptionally lightweight, powerful editor.

Opens the door for the best remote pairing tool available

This is a topic for another day, but once you're living in Vim-land, you gain access to the best remote pairing solution I've ever used.

And pairing remotely is one of the most important level-ups a remote working software developer can do.

Long story short, Vim is awesome. Give it a chance, just take it slow. There's a lot of power in there.

This Day 15 #ship30for30 #atomicEssay was shipped with this tweet:

Day 15 of #ship30for30 ... Hot take, Vim is the best editor for software developers.

Yeah I said it. Here's why I'm right? pic.twitter.com/dbZTPzZlPr

— bkono ? (@bkono101010) October 30, 2022

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

As a convert to Golang nearly 7 years ago, I've written many small projects with it. Most dead and forgotten, some running for years with virtually no effort. With each new project, I'm convinced Go is the perfect starting point.

Here's why Golang is a great choice for small side projects:

No distractions, Just code

It Just Works™, and can be as simple as a single main.go file if you choose. No picking a dependency manager or build tool (looking at you JS). The language even encourages you to get to work solving your problem, not spend hours finding “the right package” to solve it for you.

Born for the cloud, besties with serverless

Run it cheap, run it serverless. Go is extremely resource efficient, has blazing fast startup times, and produces self-contained artifacts. It is a perfect match for serverless infrastructure where you pay based on resources consumed.

Add in a few great Github Templates* and you have an asset deploying with a CI/CD pipeline to a low-to-no cost serverless infrastructure in minutes.

PoC fast, pivot quickly

With the two prior bullet points in place, Go lets you PoC blazing fast, for virtually zero cost. Doesn't matter if you're shipping a CLI, API, or full website. And since we know where you started isn't where you're going, Go lets you pivot quickly. No ceremony, just code.

Side projects are all about efficiency with your time. Pick tools that get out of the way and let you move fast and cheap.

Next time you're thinking of kicking off a new side project, try building it with Golang.Tweet lead-in

*Bonus: My best templates aren't public (yet), but you can use this (https://github.com/bkono/go-lambdatmpl) as a great starting point for AWS Lambda.

This Day 13 #ship30for30 #atomicEssay was shipped with this twitter thread:

Day 13 of #ship30for30 ... Let's keep Go-ing.

When working on a software side project, you want to ship fast & cheap. Here's why Golang should be your Go-to choice ? pic.twitter.com/NztxrlydBS

— bkono ? (@bkono101010) October 27, 2022

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