Solved by Code

ship30for30

I write high quality production Go every week, and I love it.

While I've worked across many languages, Go is definitely my go-to over the last half decade or so. When someone joins one of my teams, it is one of the two tech stacks they're looking to work with.

Even if they aren't new to Go, these are the three resources I start them with:

Learn the style guide with: Effective Go

A good style guide introduces the idioms of the language while minimizing questions around naming, code organization, and in-code patterns. Effective Go is one of the best I've ever seen. Everything from package naming to core tenants of concurrency are covered. A must read to learn to write like a native.

Learn the philosophy with: Go Proverbs

Understanding the philosophy and core principles of a language will make you a better practitioner. Why not learn straight from the mouth of one of the creators? These tidbits permeate many decisions made in good Go codebases, take the time to internalize them.

Have a deeper resource to answer questions, starting with testing: Table Driven Tests

Being able to explore additional topics on your own is vital to quickly coming up to speed. Go's Wiki is a wealth of information, and starting with an important testing topic will pay off during your first PR. As general questions come up, check here first to see if it is answered before reaching out to the rest of your team.

These 3 resources will set you on the right path from the very first step.

Links

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

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

Ever had a slack conversation go like this?

J: 12:20pm – Hello! B: 12:21pm – hi. B: 12:25pm – did you need something? J: 1:15pm – oh, right, what time is that meeting?

Ugh. You interrupted your workflow to respond to someone, and got back crickets until almost an hour later.

Your train of thought was disrupted. You probably hung around for another minute or two expecting a follow up. Finally, you flipped over to other work, frustrated, and spent far too much time trying to refocus.

As a long time remote worker, I've been there many times. Once I understood what was really the problem, the answer seemed so simple.

The root cause here is treating DMs as synchronous communication. Instead, remote workers and their teams need an async mindset. And that mindset starts with one simple change:

Don't say hello

That doesn't mean don't be friendly or casual. But it does mean when you message someone, make it a complete thought.

When the recipient does take the time to read it, they should have all the information they need to help you.

Here's how our original example could have gone:

J: 12:15pm – Hello! Do you remember what time that meeting is? B: 12:20pm – yup, 2pm PST. J: 1:15pm – perfect, thanks

The difference? All the needed context was present from the start. B was able to respond, and move on. No loose ends drawing at your attention. Everyone walked away more productive.

There's even a website for this idea, that makes it a real movement right? Join the No Hello movement, and help everyone be more productive.

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

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

Everyone who works remote eventually struggles with questions interrupting their flow.

I've been a remote and hybrid worker for over a decade now.

During my early days I knew I needed to work hard to be available since no one could glance at my office to see me heads down. When questions would come in, I'd drop whatever deep work I was trying to do and respond.

I realized I was thinking about “availability” all wrong. Many learnings came from this (to be discussed in more essays), but one in particular made a huge difference.

Instead of instant responses, most questions need a Visibility Timeout.

What is a Visibility Timeout? In software dev, during processing a message we set a period of time where it shouldn't be picked up by any other workers.

When it comes to DMs interrupting your work, most of those need to simmer for a bit. In reality, you shouldn't be the first person to work on it. The sender should.

Working on a platform that serves thousands of other developers comes with a lot of support requests. And those requests have reinforced why I use this technique.

In my experience, at least 70% of questions I receive are solved before I respond, or dramatically improved in specificity by the time I do. This is because the asker invested time in trying to solve it themselves.

While this may not apply to every question (or every asker), if you find yourself frequently interrupted, give the Visibility Timeout a chance.

Oh, and a bonus for you parents out there.

This works great with kids too. A few hours ago my daughter interrupted my wife preparing lunches for tomorrow with a panicked, “It's not working!”. We gave each other a glance, and kept doing what we were doing. Not 2 minutes later, she shouted “Nevermind, I fixed it”.

Another win for visibility timeouts.

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

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

There are many traits common to great engineers.

While chatting with a senior developer looking for advice to advance to staff, I realized some of those traits are obvious and others are so natural they're hidden in plain sight.

I've had the opportunity to build, lead, and contribute to high performing teams across organizations of all shapes and sizes. As I've progressed over the last ... too many years ... one particular Wizard of Oz-like insight stands out above the rest.

Behind every great engineer is a sounding board made up of their peers

Despite the old stereotypes, true 10x developers don't work in isolation. They collaborate. They engage the hive mind. They feed off the energy and thought processes of those around them.

And the most effective way to do that? With a sounding board of their peers.

Top tier developers cultivate a sharp group of other engineers, with varied perspectives. Through collaboration over complex problems you:

  • Expand your toolbox of options
  • Evaluate many solutions at a dramatically higher pace than doing it alone
  • Interact in a way that increases your technical influence while elevating your peers

Now that you want one, how do you build it? Seeding a sounding board is shockingly simple. You just ask for help, in the right way.

As engineers, we all love a good complex problem to solve. It's literally what we're here for. Find one, give an honest first pass, and then ask someone who's opinion you respect to provide an extra set of eyes.

That's it. But that honest first pass is important. This isn't LetMeGoogleThatForYou time.

You want to be known for bringing the interesting problems, valuing other engineers opinions, and not wasting their time.

If you don't already have a sounding board in your corner, fix that. Today. It's too powerful of a tool to skip.

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

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

Every developer on a team that cares about quality will eventually participate in the Code Review (or Pull-Request / PR) process.

As a developer regularly sought after to provide PR input, I know being an effective reviewer can appear as an art form. In reality, thoughtful application of a simple set of rules is all it takes to succeed.

Before jumping into the how, let's discuss the why.

Why should you care about being an effective Code Review-er?

The PR process is about more than catching bugs before production. It gives an opportunity to spread knowledge across the team, raise the standard, and guide the codebase's future direction.

For the participants, it is a prime chance to learn from each other, and impart your technical influence. Both sides are vital to your growth as a dev.

Now that you care, how can you do it well?

  • Ask questions to clarify and to suggest. Avoid demands. Prefer asking, “Have you thought about naming this, ___“. Don't hesitate to say “I didn't understand this section. Can you clarify?”

  • Use neutral, non-personal language. I'm a fan of “Prefer <approach> if possible” & “Avoid <approach> to prevent <future problem>“. Never use words like “dumb” or “stupid”.

  • Reference a style guide. If you don't have one, use a well known public guide that matches your language and framework. Let it provide credibility and avoid turning the feedback into opposing opinions. Even better, a good guide will contain the why alongside the what. Reference the why to validate your suggestion.

Above all else, remember there is a human on the other side of that code. We've all been guilty of getting attached to our code, be respectful and enjoy the collaboration.

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

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

For many developers, good design is hard. We can recognize it, but creating it is a whole different story.

When working on something at the edge of our comfort zone, productivity slows to a crawl. Falling into the nit-picking trap mentioned in yesterday's essay becomes all too easy.

Luckily, there are core principles and techniques for refactoring into something objectively “good”. These are three of my favorite books to elevate your design game.

  1. Refactoring UI by Adam Wathan (tactical) From the creators of the first css framework to convince me not to hate css, @tailwindcss. Dedicated to actionable steps to improve your design without going down any rabbit holes. “Design with tactics, not talent”.

  2. Design for Hackers by David Kadavy (tactical) Introductory level. Excellent approach in teaching through the lens of reverse engineering designs.

  3. Don't Make Me Think by Steve Krug (conceptual) All about UX, with principles that apply to everything from front-end interactions to backend API design. Contains brilliant real-world examples of design fails that will get you thinking.

Invest time in boosting your design skills. While I'm usually tagged as the (cloud, devops, golang, backend, etc) guy, being able to produce a polished-enough POC has sold many clients and managers on my proposals. Tangible financial and career benefits come from going that extra mile.

The above three books will get you well on your way to producing better designs, faster.

As a bonus to dive even deeper, check out Laura Elizabeth's course Design Fundamentals.

If you have a favorite design-for-devs resource, let me know. Would love to add to this list.

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

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

If you want to kick up your efficiency, you need to become aware of the friction developers create for themselves.

After working to level-up hundreds of engineers over dozens of companies, I've found common patterns and habits across the 10x devs and those that strive to be one. So in keeping with the theme of developer productivity is as much about not wasting time on the wrong things as it is efficiently doing the right things, let's take a look at one of the main activities we do to procrastinate without even realizing it.

Bikeshedding over minute details

This shows up at all levels of the stack. Nit picking at the name of a function before writing the logic, playing with the thickness of a button border when you should be making the button do something, or stressing over the speed of your loops before you know whether they work are prime examples of the phrase “missing the forest for the trees”.

For me, it often shows up indirectly. As developers, we love making the drudge work go away through automation.

I regularly catch myself trying to automate a task before I've finished solving it the first time. No, I don't need to write a shell script to save 1 minute of future mouse clicking before I've shipped the feature.

If you find yourself with code that doesn't yet do the job it is supposed to, but you're more concerned about whether the variable names are short/long/explicit enough, hit pause. Make it work, then make it pretty.

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

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

There are over 2.1 MILLION javascript packages on npm. On average, 32,000 new ones are published every month.

The more you track Hacker News and [insert your favorite language / framework] Weekly newsletters, the more overwhelming the sheer amount of new tech seems. This un-ending influx of new tools, libraries, and frameworks leads to a constant need to chase shiny objects, and a time sink that is a huge hit to developer productivity.

There's just too much noise and not enough signal. One of the most important tips I've picked up to help filter the firehose is...

The Rule of 3 (trusted sources)

The “rule” states simply that I won't invest time digging into any new library, framework, or tool until it has naturally surfaced from 3 separate, trusted sources.

Applying this rule eliminates FOMO. With a good set of trusted sources, whether that is from personal twitter lists, blogs, developers you know IRL, or elsewhere, you can feel comfortable passing on the early buzz and let your sources do the first round of filtering. As you curate those sources over time, only the most useful, highest potential items will rise up from the rest of the cruft.

I've used this technique for many years, and each time I teach it to another developer they stop getting caught by the half-baked new toys, instead becoming the dev who always knows when something is worth looking into.

Remember, developer productivity is as much about not wasting time on the wrong things as it is efficiently doing the right things.

Think about what sources you trust to help apply the Rule of 3 and respond with a few in the twitter thread.

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

#ship30for30 #devp

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

Mentioned this in the earlier tweets, but I recently signed up for Dickie Bush & Nicolas Cole’s cohort-based course, Ship 30 for 30. And finally today is the day, it’s time to start shipping!

In deciding to join, there were So Many Reasons. Since we’re supposed to show restraint (~250-words) here are just a few of them:

Make a habit out of shipping

Getting into the habit of writing consistently is hard. Even when I manage to get the writing done, there’s always a resistance to pushing publish. The #1 goal for this cohort is to replace those problems with a brand new habit.

Build a library of content

I spend a lot of time rehashing and writing up bits and pieces of my (opinionated) development philosophy. Creating a library of content to point at will help me in many ways.

And ideally I can do that while also….

Finding a community of like-minded peers

Selfishly, more people and perspectives to engage with is a great way to level-up my own thinking. Unselfishly, it creates an opportunity to help many more people than I do during my day job.

Over the next 30 days, I plan on writing about a slew of (mostly) development topics, with the intent of finding what is both enjoyable to write, and helpful to others.

Join me on this adventure—and let me know if you have any questions along the way!

I’m excited to start sharing with everyone!

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

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