DEV Community: Paul Cook

Product management doesn't have to be hard: 5 tools you can steal from Basecamp today

Paul Cook — Sun, 09 Aug 2020 19:15:15 +0000

If the first thing that comes to your mind when you think of product management is Gantt charts and analyses that seem like they need an MBA then you think product management is hard.

As developers, we know how to build. Give us a side project we can work alone on and consider it done.

But when you get a bigger team with a more mature product it gets complicated.

You might have to start thinking about things like epics, velocity, capacity management, etc., and then we have to consider the tools to manage that complexity.

We think we need to use diagrams that have the word "matrix" in them that some consultants from McKinsey invented.

Have you ever wondered if it had to be that hard?

Do you need to have an MBA from Harvard or Stanford to run a product management process?

I don't think so.

Shape Up by Ryan Singer gives us a bit of a glimpse of what a simpler product management process could look like.

It's all about the process Basecamp has used for the last 15 years to develop products.

What this post is about showing you 5 product management tools and techniques you can steal and use right away.

These are tools that Basecamp came up with to work within their product development system, but I've found them to be helpful in the pseudo-scrum-kanban-agile systems that a lot of us work in.

Here are the tools:

Design Tools

Breadboarding
Fat Marker Sketches

Product Management Tools

The Pitch
Scope Map
Hill Chart

Design Tools

There's a Goldilocks zone for design specifications.

I used to think I always needed a pixel perfect design fresh from Photoshop.

Here's the problem: you can have a design that's too high fidelity.

With software development, it's not a question of whether you can build a design. You can build anything, but do you want to spend the time it's going to take to build that design you're so hyped about?

Sometimes you do, but if the early design is set in stone without considering the implementation you could run into trouble.

There's another extreme, too. Instead of a design, you get a ticket or user story that describes the solution with a paragraph of text.

There's more freedom with that, but sometimes too much freedom can crush you.

All of a sudden you're not sure the boundaries of the solution, and you have to figure out what the design will be at the same time as you're figuring out the functionality.

In both situations, there could be edge cases that cause the project to explode.

Two tools that help here:

Breadboarding
Fat Marker Sketches

Tool #1: Breadboarding

Source: Shape Up

Think of breadboarding like a textual map of the UI. It's like a statechart for product management.

It's called breadboarding.

Why? Because it's inspired by the breadboards of circuit design which allow you to prototype and test circuits without having to worry about the final design.

It's a tool that allows us to think through our UI solution.

It consists of these elements:

Places
Affordances
Connection lines

Places are where users can navigate to like pages, dialogs, menus, etc.

Affordances is a fancy word for something a user can do (think a button or form field), or shows a user what can be done (think UX copy or an icon).

Connection lines show what happens when a user interacts with an affordance.

Source: Shape Up

The big win from this is how it allows us to think through the user's path without having to get too concrete too early.

We don't get hung up on early design ideas because all we have is text, but it's concrete enough to allow us to see what won't work.

Tool #2: Fat Marker Sketches

Source: Shape Up

There are times when text alone isn't enough, and you need to sketch out an idea

A drag and drop interface of some sort comes to mind. They can be complicated enough that breadboarding alone wouldn't be sufficient.

At the same time, you might not need to jump into detailed mockups.

That is where fat marker sketches come in.

It's almost laughable to call this a technique, but I can testify to its value.

A fat marker sketch is a low-fidelity wireframe done with a tool (like a king size Sharpie) that limits the amount of detail we can show.

It's not going to be confused with a mock-up, and because of that, it's not going to tie anyone's hands further down the line. It gives room for interpretation so that the designer and the developer can make the best possible choices as they work on the design and implementation.

The lack of detail is a feature, not a bug.

Source: Shape Up

Product Management Tools

This next class of tools is what I consider to be core product management tools.

They help you get a handle on where the project is:

What even are we working on?
What are the independent parts?
How close are we to completion?

Important questions for any project.

Three tools help us with that:

Pitches
Scope maps
Hill Charts

Tool #3: Pitches

I don't know about you, but I've worked on a bunch of disconnected and disembodied user stories and tickets over the years that I've had zero clues on how they relate to the overall vision of the project.

How does "as a user, I can edit my profile picture" connect to what we were doing again?

The worst part about not knowing how things connect is it often leads to bad outcomes during integration phases of later user stories/tickets.

You might not have thought about how one piece interacts with a later part of the project because you never knew you would need to think about it. When it comes time to build that later piece you have to rework a lot of what you already had done.

Not good.

But what can be done?

Enter the pitch.

All the pitch is, is a write up of a proposal for a new feature or an improvement.

It's obvious, right? But I've worked on plenty of projects or features that didn't have anything like it associated with them.

At least not anything that I saw.

Think of it like pitching any idea:

A company
A movie
A book

The pitch has to persuade and explain. In the case of products, we want to persuade why what we're proposing matters and how it will work.

It has five ingredients:

Problem
Appetite
Solution
Rabbit holes
No-gos

Problem

What problem will your solution solve?

Is there an issue customers are facing? Common complaint?

This is what will motivate people to want to work on the feature. They buy into the problem you present as being worth solving.

Appetite

How much time are you willing to spend on solving your problem?

I love this concept of appetite. If you only want to spend two weeks solving a problem that will constrain what you do as compared to two months.

The appetite will serve to frame your solution. Some problems are worth spending months on, but if you look at what your appetite is for a project you might find it's less than you might think.

I've estimated a lot of projects over the years, and what is seldom known is how much time the business is willing to spend. In other words, seldom is it asked what the appetite is.

So many ideas never get worked on because the estimate ends up being huge when if the appetite was known from the beginning the proposed solution could have been scaled down.

One way Basecamp constrains their appetites for even massive projects is keeping the work to 6 week cycles. They seek to find the 6 week version of the solution to fit the problem.

Solution

Once you know the problem you're trying to solve, and how much time you're willing to spend to solve it you can work on finding the solution.

This is the proposal on how to solve the problem within the allotted appetite.

What are the elements that need to be there?
What are the nice-to-haves?

Should be clear and include visual aids to understand what needs to be done.

Rabbit holes

As you're thinking through the solution keep an eye out for possible distractions. These can be nice-to-haves that you can see having the potential of being a major time sink.

Make those explicit and optional. If we have a specific appetite for the project we should be willing to give up parts of our solution that are not central to solving the problem.

No-gos

These are things we explicitly aren't going to do. Doesn't mean we won't do them ever, but we don't want our time eaten up by them right now.

Shape Up gives the example of a team forgoing making a particular form field WYSIWYG. That would be a nice improvement, but it's not central to the solution and can be done later if needed.

Write and present

Once you have all your ingredients gathered you write it up and present.

At Basecamp they use Basecamp to present, but you could use email or even a GitHub issue to layout your proposal.

Having it written is important. It gives people the option to read, digest slowly, and give measured feedback.

Source: Shape Up

Tool #4: Scope Maps

Source: Shape Up

The work in a lot of projects isn't divided up well.

Sometimes they're divided up by who will be doing the work. That can be fine, but if, for instance, the front end work is too disconnected from the backend work it can create communication problems.

It can also mean that the individual members of the team don't have a good sense of the overall scope of what they're working on because they're focused on a small subset of a slice of the problem.

Or we divide up the project and then try to move all the separate parts forward at the same time without ever completing something until at the end.

This hurts the context we can build when we focus on completing the independent pieces one at a time.

This is where the scope map is helpful.

You can think of the scope map like the product manager's version of a butcher map.

A butcher's map of an animal shows where different cuts of meat come from.

In the case of the scope map, we want to show what the individual pieces of the project are.

In other words, what are the smaller individual scopes in this project that can be completed independently of one another?

As you do discovery and start working on a project you start to see the individual pieces that need to be done. You might organize this into some sort of todo list, user stories, or something else.

At first, you'll just have one big list, but the goal of the scope map is not to leave it that way.

Instead, you want to start grouping those items that make up the orthogonal pieces so they can be done separately.

And then you start working on them one slice at a time.

It's important to know that you might not have the scopes fully mapped out at the start of the project. There will be things you discover later on that reveal further scopes to you.

That's okay. It's all part of the process.

The goal with the scope map is to have a map of what needs to be done so you don't get lost along the way.

Tool #5: Hill Charts

Source: Ryan Singer

It can be hard to know how close a project is to "done," especially, if you're not doing the work yourself.

The developers might have a fingertip feel of how close they are to being complete, but even they can be wildly off if they have tunnel vision on whatever it is they're working on.

You might not be able to tell if a particular ticket or user story is 10% or 90% done.

Even if you have a todo list associated with the task there could be items that take as much time to complete as the rest of the list combined. If you just went by the percentage of items complete you could be WAY off.

Basecamp's solution to this uncertainty is the hill chart.

Hill charts start with the assumption that there are two main phases of work for a project:

Uphill
Downhill

Uphill

The uphill part of a project is when you're struggling to get it to the top. You can't see the other side so you're not quite sure how close you are to completion.

There's a lot of unknowns left to discover.

In the uphill phase, you could be knocked back down the slope. Maybe you discover the data you'll need for a particular task isn't where you thought it was, and so you have to go out and get that data when you weren't planning to.

Downhill

Once you crest the top of the hill things become easier. You can see what's left to be done laid out before you, and you know the path to get it done.

Momentum can take over as you knock off one task after another.

The power of the hill chart

The power of the hill chart is it allows you to visualize the progress of a project. You can see where the uncertainty is. What needs extra effort to be pushed up the hill.

Maybe you'll devote more resources to it, or simply be able to see what's going on.

From day to day people can update where things are at. One item was near the top of the hill yesterday, but new issues or problems have arisen and it's rolled halfway back down the hill today.

That's valuable data for any team.

Source: Shape Up

Hill charts are guesses

It's important to know: this is a guesstimate , and it's always subject to the fallibility of people.

We're not making a quantitative judgment. In some sense, it's kind of like a thermometer. How does the team feel the project is going?

How do you create a hill chart?

The main tool I know of is in Basecamp. Now, I don't use Basecamp, but there's no reason you couldn't use a whiteboard.

Conclusion

There's way more in Shape Up than these tools.

It's a look behind the curtain of what product management can look like outside of Agile/Kanban/Scrum.

Your team might not be ready to adopt all the practices in it (mine isn't!), but there's no reason you can't steal these 5 simple tools and make life a little easier for your product management process.

Painless Code Reviews

Paul Cook — Wed, 27 May 2020 18:43:13 +0000

Code reviews can have a bad reputation. We’ve all heard, been witness to, or lived through horror stories where every last line is torn to shreds.

So much feedback that you have to scroll and then keep on scrolling to get to the bottom.

And the comments! So directed and personal that you would think they were meant to be personal.

The knives were brought out and we were cut up in public like a street fight.

They can make us angry, ashamed, or embarrassed. At the end of it you wonder, "what could I have done differently?"

That’s what this post is about.

What can you do differently?

How can you make reviewing our code painless so that even the biggest nitpick on your team has nothing but praise?

Let me offer you a few tips that have helped me.

The Golden Rule: Minimize the Number of Roundtrips

"Roundtrips (from teammate to reviewer back to teammate) are expensive, costing up to two working days of a sprint each time."

From: Feedback Ladders: The Code Review System We Follow at Netlify.

As much as possible reduce the number of roundtrips in the code review process.

What do I mean by roundtrips?

I mean those back and forth exchanges where the reviewer asks you why you didn’t go with a particular solution, and you have to explain why you tried what they suggested but it didn’t work.

And then the reviewer asks what problem you were solving with a particular design decision, and after your answer asks some follow up questions.

Repeat ad nauseam until by the end everyone is annoyed.

Why do I call it the golden rule?

"Do unto others as you would have them do unto you." Because I hate the back and forth when I’m reviewing someone else’s ticket. It’s what I wish others would do for code that I review, so, I’m going to do it for others.

There’s a few ways I’ve found to reduce the roundtrips.

Document ambiguous design decisions

There are times when you reach a fork in the road. You're solving a problem, and you could go with A or B (maybe even C, D, or E).

You weigh which design is the best, and you make your choice after having carefully considered each option.

Recently I got some feedback in a code review that was basically, "why didn't you go with option D?" What they didn't know was that I had that and it didn't work, so, I went with B.

What I could have done (and what I do in my better moments) is describe why I chose the solution I did, which other solutions I considered, and the ones I tried but didn't work.

You don’t always have to go into *that *much detail, but if you think there’s reason to then do it.

Most of the time I'll leave these comments in the ticket after I finish so the person reviewing has more context to help their review.

Occasionally, you'll find these comments are so valuable they should be put into the documentation to explain things like architecture and design patterns, or left as comments in the code itself.

Preemptively review your code

When you make that last commit, and push the code your job isn’t done yet.

Try to look at your code from the perspective of another person.

This might mean giving it a day for the code to sit so you can come back with fresh eyes.

Imagine it wasn't you that wrote it.

Where might there be confusion?
What issues might there be for someone else who comes to the code?
What changes do you need to make to eliminate those issues and confusion?

I’ll often go through my code following a self-review checklist I’ve put together over the years.

There's an old sales technique called anticipating objections. The idea to preempt any objections people might have by bringing them up yourself, and then addressing it ahead of time.

Same idea here. We want to anticipate the objections that could be raised against our code, and fix them ahead of time.

How do you know what those objections could be?

Once you've had enough code reviews at a company you will know the problems people have with your code. Add those issues to your code review checklist, and fix them before your code is reviewed by anyone else.

If you're getting nitpicked a ton, adopt a code linter/formatter

If people are always needling you for the formatting of your code that's a smell that your team needs some automatic code linting or a formatter like Prettier.

The code review process shouldn't concern itself with those kinds of details. It should be focused on finding bugs and design flaws.

If people are having to point out things like,

That you should or shouldn't use semicolons,
Wrap your if-statements in brackets,
Use const instead of let,
Prefer arrow functions,
etc.

that is wasting precious brainpower.

Propose that you adopt something like Prettier with the basic recommendations and be done with it.

Understand the patterns of the codebase

When I first joined my current company I was hammered pretty regularly in code reviews.

Often not for major flaws in my code, but for merely not adhering to the patterns and conventions of the codebase. Some of that was solved by the above point of using Prettier and a linter, but some of it came from understanding how the team writes code.

If your team has separate files for all components/classes don't start putting a bunch of components in a single file.

Working on a team requires a bit of give and take.

I prefer writing my code in a more functional style. Most of my team does not. There are certain ways I would write code in a personal project that I don't do at work.

This doesn't mean you don't argue for opinions, and try to get people to see your way of thinking. Or even try to introduce new patterns.

It does mean that when your team makes a decision to do things a certain way you can disagree, but then commit to doing it anyways.

Remember:

I want to wrap things up, but there’s just a few things that I’ve found helpful to keep in mind. I think they’ll be helpful for you, too.

Good code reviews require shared context
It’s not personal
It’s a learning experience

One, good code reviews require shared context

The best code reviews come from skilled engineers who have a good understanding of the problems you're trying to solve and the codebase you're working in.

If you're the only person who has any clue what you're working on, you need to create that context.

Part of that can be solved by sharing your ideas early and often.

Often what I will do is write my high-level idea for how to solve a problem, and then ask people who are familiar with the systems I'm working on for feedback.

It's a less formal RFC (Request for Comments).

If I'm working on a UI, I'll describe how I'm thinking of approaching the problem. I might provide a low-fidelity wireframe or examples from other apps that match my proposed solution. I'll tag the best UI people on my team to see what they think

If I need to mock out an API I'll write out a proposed URL structure including any parameters I might need and a potential model. I'll then tag the API people.

The goal is to see if the direction you want to go even makes sense to other people.

People will either provide helpful feedback and suggestions, or they’ll affirm you’re not crazy and it’s a good idea.

It’s just generally a good way to think through problems, too, as it forces you to think rigorously about your approach.

Also, at the end of the day when the code goes into review people aren’t going to look at your code, and be mystified with how you came up with the design you did. You worked in public from the beginning.

Two, it's not personal

This is key.

Most of the time people aren't trying to be jerks in the way they're reviewing your code.

They're just trying to make the codebase as good as they can because they want to build an excellent product.

It doesn't help that code reviews often happen over text, and most people are awful at conveying emotion in writing. So, take what's said with a grain of salt, and try not to assume malice where less insidious explanations will suffice.

We suffer more in imagination than in reality.
– Seneca

Easier said than done, Seneca!

The problem is it's hard not to take it personally. We become so tied with our code and ideas that criticism of them feels like a criticism of us as people. It feels like a questioning of our abilities.

A lot of devs don't make this any easier. They come across as rude and petulant jerks.

We have a deserved reputation for not being very compassionate and empathetic as an industry.

But we can choose to interpret others in the best way possible. We can choose to not take it personally and to view it as everyone trying to create the best possible thing we can.

And in the end when you view it that way you start to see code reviews as a collaborative process.

Like an author and an editor both working together to make a beautiful piece of writing, the code author and the code reviewer work together to make something good into something great.

Three, it's a learning experience

No matter how experienced they are, the person reviewing your code has something to teach you.

If they're a senior engineer they can teach you about some method you didn't know existed that can solve your problems in the half the lines of code that it took you, or some other interesting approach.

If they're a junior engineer they can ask you the kinds of questions that reveal you don't understand things quite as well as you thought because otherwise, you would be able to explain why you went with a particular solution.

Whatever happens in our code reviews we should strive to learn and grow from them.

Earlier in my career, I started trying to learn from every piece of feedback, and to eliminate things people knocked me multiple times for in reviews.

We can all do that.

The End State

I can only speak from my own experience, but, as I've followed each of these practices over the last few years, code reviews have lost their sense of dread. I used to hate moving my tickets from being in development to ready for peer review.

No longer.

Reviews have become an opportunity for me to learn and improve.

As I've made my code less painful for others to review something remarkable has happened:

The review itself has lost its pain for me.

🔍 Dev Finds Friday 5

Paul Cook — Fri, 22 May 2020 19:26:15 +0000

This was originally published in my free weekly newsletter, Dev Finds Friday. It's like having that cool friend who sends you all the best links on the internet (but better).

Onto the the links!

Remote Work Takes Over

Two months into the current crisis, and the walls holding back the big tech companies in Silicon Valley from allowing remote work have started to tumble down.

The first company I read that made the move was Twitter after CEO Jack Dorsey emailed the company telling them they'd be allowed to work from home for forever.

HN discussion of Twitter's move: link.

This week at least two more dominoes have fallen. Coinbase announced that after COVID-19 they'll be a remote-first (!) company, and, then the granddaddy of all the remote announcement,

Facebook said that within 5 years half of all their employees would be remote.

HN discussion on the FB announcement: link.

Which domino will be next to fall?

Weird Wide Webring

The web needs a little more weird. These sites are helping.

I'm a great lover of the personal site. I think we're experiencing a bit of renaissance after having many people abandon their own places on the web for social media.

The Weird Wide Webring is one such group of people helping to fuel the personal site resurgence. It's a collective of sites helping to make the web a bit more weird.

Static Hoisting

The JAMstack has become the thing in the front end world. For good reason, too, there's a lot of great patterns on how to build web applications that have emerged.

In this article Guillermo Rauch uses the analogy of hoisting to describe what makes static sites so special.

A key tenet of static site generators is to pull in content not when it's being requested by a user, but in a build step. A WordPress fetches post content directly from the database when someone hits a post URL.

Something like Gatsby bundles up the post in static HTML when it's published. What this means is that our sites no longer have to exist on one single shared server somewhere in Virginia.

Instead, modern hosts like Netlify and Vercel "hoist" the site to CDN edge locations as close as they can get to visitors.

It's an ahead-of-time approach vs. just-in-time.

“The title ‘Front-End Developer’ is obsolete.”

A CSS-Tricks article expanding on a Twitter thread about how many front-end developers ignore everything outside of JavaScript to the detriment of the user-experience.

The front-end requires not just knowing JS deeply, but know CSS and HTML deeply. It means knowing how to write accessible markup.

It means not solving problems in complex JS that could just as easily be solved with some CSS transitions.

The modern frontend developer is most often than not a 'Jack of all trades' mastering JS (or even just a framework) and barely tolerating HTML/CSS as a necessary evil. That’s understandable. I strongly think it’s a different specialization, and it’s too much for a single person.

Some good discussion (surprisingly) can also be found on Reddit: link.

How to Center in CSS

Less of a how-to guide than a friendly little web app that generates code for you to center things.

Need to center a div of an unknown width and height, and you have to support IE6 (yes, really). This has got you covered.

That's all I've got.

If you're a curious dev, and that sounds like something you'd like to get directly to your inbox, sign up: Dev Finds Friday.

Much appreciated.

Stay healthy and thanks for reading!

Human Code Reviews | Dev Finds Friday

Paul Cook — Fri, 15 May 2020 14:24:02 +0000

This was originally published in my free weekly newsletter, Dev Finds Friday. It's like having that cool friend who sends you all the best links on the internet (but better).

Onto the the links!

I've been thinking a lot lately about how to conduct human code reviews. I use the word human there on purpose because I've found that some devs take a perverse pleasure in ripping apart code without giving a second thought to how the information is communicated.

Our industry has a reputation for not being human, in other words, and our code reviews are often inhumane.

Some of us like that.

Many of us don't.

None of us should.

So, let's inject a little humanity into our code review process.

Here's a few thoughts on how:

Make it clear what feedback is blocking and non-blocking. Don't hold work up because you have some minor nitpicks. Netlify put out a great piece on their Feedback Ladder that applies here.
Assumptions:
- DON'T assume the person whose code you're reviewing thinks the same way as you, or that the way you're thinking about the problem is the one true solution.
- DON'T assume they know what you know. Provide links to blog posts, Stack Overflow answers, GitHub issues, and whatever else.
- DO assume they've already considered your suggestion before. Ask them how they arrived at their solution, and if they thought about your suggestion.
Encourage what's good. Code reviews shouldn't be all negative.
Consider how you're coming across. What's your tone? Is it dismissive?
If matters of style and formatting come up a lot, adopt team wide linting rules/a code formatter.

I'm planning on writing more on this in the future. It's an important topic we could all improve (myself included) because, after all, we're only human.

Onto the links!

The Links

Write Libraries, Not Frameworks: "Frameworks aren't always bad, but they are a much bigger risk - for both the creators and the users - than libraries are. If your framework can be a library without losing much, it probably should be. If you don't work at a major tech company, you probably don't have the time or energy to give a framework all of the attention it requires. Libraries aren't everything, but they should be preferred."

Hacker News discussion.

Moss Garden: A stream of ambient music perfect to listen to while programming.

**Why does writing matter in remote work?: **Many, many reasons.

It saves time.
It makes meetings a last resort.
It removes extrovert bias.
It invites other perspectives.

List Style Recipes: Do you know how to style a list with Roman numerals? How about the Greek alphabet? Never knew you wanted to know how to do that? Well, this article from CSS-Tricks is for you!

Blush, Illustrations for everyone: A neat little (FREE) collection of those doodles of people that every startup uses on their landing pages. You’ll see what I mean.

My Mid-Career Job-Hunt: I've only had 2 job hunts for dev roles, so, I seeing what the process is like for others. What helped the author land a gig:

Speaking at conferences.
Having a blog (though not as much as the author would have thought).
Having a special branded resume for each company (you'll have to read the article to see what I mean).
Side projects.

Hacker News discussion.

Being Slow to Criticise: "I try to be slow to jump to that conclusion, that the software is garbage. So often there are reasons for things to be the way they are."

Hacker News discussion.

Rebuilding our tech stack for a new Facebook.com: A more clickbaity title would be "You'll never believe how Facebook reduced their CSS by 80%."

Some curmudgeons are fond to remind others that they're not Google or Facebook, but on the front end we deal with a lot of the same problems and bottlenecks. Helpful to see how one top tier engineering team is pushing their app forward.

What accomplishments sound like on software engineering resumes: Nicely complements last week's link from Sarah Drasner, Advice for Writing a Technical Resume.

A couple more links I came across in this vein:

Lots of examples on how to be specific with your professional accomplishments.

The joy of sets - BBC Archive: Spice up your Zoom calls with backgrounds from famous BBC show sets.

That's all I've got.

If you're a curious dev, and that sounds like something you'd like to get directly to your inbox, sign up: Dev Finds Friday.

Much appreciated.

Stay healthy and thanks for reading!

The idea that changed the way I program - Dev Finds Friday

Paul Cook — Fri, 08 May 2020 14:33:02 +0000

This was originally published in my free weekly newsletter, Dev Finds Friday. It's like having that cool friend who sends you all the best links on the internet (but better).

Onto the the links!

I was browsing Twitter earlier this week when I came across a thread on ideas that changed your life.

It's well worth a read in and of itself, but it got me thinking about what ideas changed the way I program.

I tweeted out my first thoughts on what those ideas might be, and as I think about it now perhaps the biggest change was learning how to use JavaScript's array methods.

I read through a tutorial on functional programming in JavaScript, and overnight it transformed my code. I don't remember the last time I wrote a for-loop in my day job.

I've read a lot of articles, watched tons of courses, and listened to too many podcasts, but only a small percentage of that content has truly shaped the way I program. It's fun to look back and reflect on the ones that did.
What ideas have influenced you?

The Links

Rules of thumb for a 1x developer: Everyone is obsessed with the idea of a 10x developer., but what do you do when you're a 1x dev?

"Rule 3: Focus “learning time” on things that compound"
"Rule 18: Estimates serve more for creating pressure than for project planning"
"Rule 20: When somebody says Agile, push for Kanban, not Scrum"

Hacker News discussion.

Advice for Writing a Technical Resume: Great article from Sarah Drasner on exactly what it says.

"Each time you list a work example, answer this: what did you accomplish? This is a good way to provide valuable information without unnecessary fluff."

Regular Expressions for Regular Folk: A visual tour de force through regular expressions.

SQL Police Department: Learn SQL while solving crimes. The Hacker News discussion has a few other links to similar SQL tutorials, as well, like SQL Murder Mystery.

Software Folklore – A collection of weird bug stories: We've all experienced our share of tough bugs. This is a collection of doozies like a bug that only showed up depending on the phase of the moon.

The Hacker News discussion has more bug stories.

Analyzing Analytics (Featuring: The FBI): In which our young adventurer discovers a site secretly run by the FBI.

The Eng Hiring Bar: What the hell is it?: A question for the ages. Long answer made short: it depends, but it's pretty high.

Corresponding Hacker News discussion.

That's all I've got.

If you're a curious dev, and that sounds like something you'd like to get directly to your inbox, sign up: Dev Finds Friday.

Much appreciated.

Stay healthy and thanks for reading!

Zoom Doom - Dev Finds Friday

Paul Cook — Fri, 01 May 2020 17:59:26 +0000

This was originally published in my free weekly newsletter, Dev Finds Friday. It's like having that cool friend who sends you all the best links on the internet (but better).

Onto the the links!

We all live in Zoom, now, and people are starting to feel the Zoom doom brain drain.

Daily active usage has gone from around 10 million people to 300 million.

And maybe that's the problem. Even those of us used to virtual meetings from being remote find ourselves in Zoom after hours. Church is done in Zoom, birthday parties in Zoom, our kids' school is in Zoom, get togethers with friends done in Zoom, and on and on.

So, if you feel like "I don't want to be in any more Zoom calls" just know you're not alone.

And maybe take the night off.

Links:

Dev of the Week: Josh Comeau

I love checking out other dev's personal sites, and Josh's is one of the best. I'm always inspired whenever I check it out, and also a little bit jealous because I'm nowhere near as creative.

Link to his site: https://joshwcomeau.com .

Here's a Twitter thread where he talks about some of the little details that went into it: https://twitter.com/JoshWComeau/status/1232022395365535750

A few articles to read:

Cool Tool of the Week: Excalidraw

Link: https://excalidraw.com/

There's a spectrum of diagrams I create for my coding.

They range from drawings on a whiteboard that will be erased as soon as I'm done to more serious diagrams done with Draw.io that will live on in documentation to be updated over time.

Excalidraw falls somewhere between those two extremes. It's a web app that allows you to create whiteboard like diagrams that feel hand drawn.

Check out the story of how it went viral.

8 Things I Learned from Rich Hickey That Helped Me Write Better Software (Simple Made Easy)

Paul Cook — Wed, 12 Feb 2020 14:16:12 +0000

I think you'll agree with me when I say:

One of the most difficult problems in software development is dealing with all the complexity that comes along with our job.

Rich Hickey, author of the language Clojure, understands that problem, too, and his talk Simple Made Easy has helped me learn how to think better
about complexity in my own work.

Here's a few things I learned from his talk that I have helped me, and I hope will help you.

Why easy isn't (necessarily) simple
The difference between the construct and the artifact
How complexity hurts our understanding
What's true of every bug
What it means to complect
How to make hard things easy
How to make complex things simple
The true benefits of simplicity

1. Why easy isn't (necessarily) simple

Hint:

They aren't synonyms for one another even if we use them that way.

But developers love to pretend they are. The most egregious examples is all of the libraries that describe themselves as being "dead simple."

What do they even mean by "dead simple?"

Urban Dictionary describes it well: "So easily done that even a complete idiot could figure it out."

So, "dead simple" means so easy a cave man could do it. But is that really what simplicity is?

Simple vs. Complex / Easy vs. Hard

To understand the difference between simple and easy you need to understand what they contrast with.

Simple contrasts with complex while easy contrasts with hard.

Looking at the root of simple we find sim and plex which means one fold or braid. Complex means braided or folded together.

Something is more or less simple depending on how interconnected or interweaved. Think of a rope here.

Easy origins look something like this: ease < aise < adjacens. You can see the word adjacent there

Easy has the idea of lying near or being at hand. We can think of something that's easy as being near our capabilities.

Simple = Objective whereas Easy = Subjective

Simplicity is measured by how interconnected a program is. Whether or not it's interleaved is something that anyone can see. In other words, it's objective.

Easiness can only be measured from person to person.

In other words, it's subjective and personal.

Easy for whom? Or hard for whom?

For instance, speaking Spanish is hard for me. I don't know it and have never had any formal or informal learning of it.

It's easy for my wife because she grew up with it as her first language.

Playing piano is hard for me because I stopped practicing 20+ years ago. I couldn't play a single song today if I tried.

It's easy for my sister because she never stopped practicing and has been playing now for around 30 years.

I could make Spanish easier for myself by spending time learning it, same with piano, but the only way to make something complex simple is by spending the time untangling the web of knots.em

Simple != Easy

2. The difference between the construct and the artifact

We tend to think easy = good. Easier things are better than hard things, right?

Don't you want to use easy tools? Well, yeah, I do.

But should that be your primary focus?

Hickey says no, and the reason he says no is because our primary concern shouldn't be our own convenience of the tools and languages we use, but the results of those tools.

Hickey calls them our constructs. The things we use to build our software which is our artifacts.

We're focused on the wrong metrics. It doesn't how convenient it is to use if that convenience just sends us further down the road of complexity.

We should instead be focused on how easy it is to change down the line.

Now, this does not mean that all easy tools produce complexity, but it does mean that ease of use alone shouldn't be the deciding factor.

3. How complexity hurts our understanding

The world record for most balls juggled is something like 11. That's not too distant from the guy above with 3. He looks like he could probably handle a few more, but what would happen once he got beyond

4 or 5 or 6?

My guess is he would quickly come to his limit and start dropping the balls.

Juggling things with our hands isn't so different from juggling ideas with our minds.

Like a juggler has a hard upper limit on how many balls they can keep in the air we have an upper limit to how much stuff we can hold in our brains at the same time.

And there's not so great a distance between the most intelligent among us and the least.

We can only hold so much in our mind at once.

The more complicated and interconnected our codebase becomes the more difficult it becomes to understand all of it. When things are interweaved together we can no longer think about the different parts in isolation, but have to look at them together.

So if every time I think I pull out a new part of the software I need to comprehend, and it's attached to another thing, I had to pull that other thing into my mind because I can't think about the one without the other. That's the nature of them being intertwined. So every intertwining is adding this burden, and the burden is kind of combinatorial as to the number of things that we can consider. ^^So, fundamentally, this complexity, and by complexity I mean this braiding together of things, is going to limit our ability to understand our systems^^.

4. What's true of every bug

What's true of every bug?

It passed the type checker (assuming you have one).
It passed the tests (you should have at least a few of those!).

Types and tests are not enough to ensure a simple codebase. We need our code to be simple enough that we can reason about it on our own.

The more complex our code becomes, the more difficult that is, and if we're relying on the guardrails of our types and our tests alone they won't prevent us from writing a big ball of mud.

Those are orthogonal concerns to simplicity.

In other words, you can have complex code and static types **and **tests. Focus on the simplicity and don't think you're getting that for free types and tests.

5. What it means to complect

Who doesn't love new vocabularly? Hickey introduces us to a new old word "complect."

What does that mean?

It means to interleave, entwine, braid. It's the verbal form of complex.

You don't want to be complecting your code.

Look at this diagram. Look at the first one. Look at the last one. Right? It's the same stuff in both those diagrams, the exact. It's the same strips. What happened? They got complected.

We need to be asking the question of every decision we make, every library we pull in, and any code we write: "is this complecting my program?"

6. How to make hard things easy

Say you don't know a particular programming language. It's hard for you, in other words. How do you make it easy?

When you put it that way it becomes pretty obvious: learn, experiment, try.

Go to the tutorials and learn from others further along than you. Work on a small toy project.

Work through exercises and problems in the language on a site like Exercism. Making hard things easy is all about making them familiar.

Yes, there's more involved than just that, but there's not less.

7. How to make complex things simple

This is trickier than making hard things easy.

It's a matter of disentangling.

You're going to get this. You're going to need to first sort of figure out where it's going. You're going to have to follow stuff around and eventually label everything. This is the start. This is roughly what the process is like. But again, it's a whole separate talk to try to talk about simplification.

That's easier said than done, especially if you're working in a very large complex codebase.

But it's fundamentally a matter of taking the twisted and intertwined parts and untwisting them.

8. The true benefits of simplicity

Ease of understanding.
Ease of change.
Ease of debugging.

The knitted castle and the Lego castle both look beautiful from the outside, but say you had to change the layout. Which would you want to have?

Conclusion

If any of that piqued your curiosity, I encourage you to run (not walk) to watch the Rich Hickey's talk Simple Made Easy.

It's changed how I think about the code I've written and going to write. Maybe it can do the same for you.

Links

The talk itself: https://www.infoq.com/presentations/Simple-Made-Easy/

The transcript for those of you who prefer to read: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md

What role has luck played in your career?

Paul Cook — Sun, 20 Oct 2019 19:42:28 +0000

I think we don't recognize the role of luck enough in our lives/careers.

Let me give you an example from my own life:

I was talking with my boss recently and he brought up why he looked at my application out of the hundreds he got (remote positions advertised on StackOverflow get a LOT of applications).

Basically the whole reason I have the job I have is because the first guy who hired him for a dev job is named Paul Cook so when he saw my application he was curious if I was his former boss.

And that was the reason he gave me a call.

Of course, I had to interview well and be a compelling candidate, but with hundreds of other people applying he could have just as easily never taken a look at my resume.

So, what about you?

What role has luck played in your career?

DEV Community: Paul Cook

Product management doesn't have to be hard: 5 tools you can steal from Basecamp today

Design Tools

Tool #1: Breadboarding

Tool #2: Fat Marker Sketches

Product Management Tools

Tool #3: Pitches

Problem

Appetite

Solution

Rabbit holes

No-gos

Write and present

Tool #4: Scope Maps

Tool #5: Hill Charts

Uphill

Downhill

The power of the hill chart

Hill charts are guesses

How do you create a hill chart?

Conclusion

Painless Code Reviews

The Golden Rule: Minimize the Number of Roundtrips

Document ambiguous design decisions

Preemptively review your code

If you're getting nitpicked a ton, adopt a code linter/formatter

Understand the patterns of the codebase

Remember:

One, good code reviews require shared context

Two, it's not personal

Three, it's a learning experience

The End State

🔍 Dev Finds Friday 5

Remote Work Takes Over

Weird Wide Webring

Static Hoisting

“The title ‘Front-End Developer’ is obsolete.”

How to Center in CSS

Human Code Reviews | Dev Finds Friday

The Links

The idea that changed the way I program - Dev Finds Friday

The Links

Zoom Doom - Dev Finds Friday

Dev of the Week: Josh Comeau

Cool Tool of the Week: Excalidraw

Other Links of Note

8 Things I Learned from Rich Hickey That Helped Me Write Better Software (Simple Made Easy)

1. Why easy isn't (necessarily) simple

Simple vs. Complex / Easy vs. Hard

Simple = Objective whereas Easy = Subjective

2. The difference between the construct and the artifact

3. How complexity hurts our understanding

4. What's true of every bug

5. What it means to complect

6. How to make hard things easy

7. How to make complex things simple

8. The true benefits of simplicity

Conclusion

Links

What role has luck played in your career?