I’ve been continuing my posts on Engineering Management the last few weeks. To keep email volume reasonable, I’m going to continue rolling these up into ~biweekly digests for this newsletter. I hope you enjoy the posts, and if there are engineering management topics that you’re interested in, feel free to shoot me a question

• Handling Accountability — Some ideas on adjusting to being accountable for the output of a team if you’re used to being more in control of your work

Hi there!

I’m spending the next 2 months on parental leave helping take care of our 2 year old, newborn and 8 month old puppy, so life is a bit crazy these days. The time away from work though has been a good time for reflection as well, and over the next few weeks I’m planning on sharing a bunch of things I’ve learned about Engineering Management over my first few years in that role.

Included below is my 2020 roundup post from the blog. Thank you all for continue following this newsletter through a year that has been quiet in terms of post and tumultuous in terms of the outside world. Have a great new year!

2020

2020 was the 7th full year of my blog, and it was by far the quietest in terms of output. For reasons that are both obvious (global pandemic!) and personal (toddler, puppy, still learning a new job) writing has been on the backburner for a year. I hope to change that in 2021, but with another child on the way in February I’m not foolish enough to make any promises here.

Hi all 👋

As I’m rebooting my blog / newsletter, I am continuing to play around with the format. This week I simplified my site design (it had gotten a bit messy over the last few years of gradual evolution), and also clarified my theme: I’m going to be writing about engineering leadership and productive product teams. I also expect to be writing more short posts like the one below where I share interesting ideas I’m reading about and how I’ve seen them play out.

This week’s post is relevant to all of us who are on month 6 of pandemic life. To paraphrase the footnote below

A season is only a season if it has a defined endpoint or offramp… This is your life.

A lot of us are fighting through stressful situations as 2020 has become an intersection of health, safety, justice, political, and personal challenges for so many. It’s worth taking a step back to figure out what needs adjustment.

👋 Hi there! It’s been a minute since I sent one of these, and while I’m not at a point in life where I’m going to be able to send weekly newsletters, expect to see some irregular articles coming through.

📖 This Week’s Article

I’m currently reading Doublas Hubbard’s How To Measure Anything and it is driving home a point I’ve observed anecdotally throughout my career; when people don’t know something exactly, they often throw away a ton of things that they do know. You can see this in project estimation, where engineers often resist providing any estimate since “it’s hard to tell before we actually build it”. You can see it in product planning, where teams I’ve worked with struggle to provide clear usage or business impact goals since “it is hard to tell how impactful this will be till we build it”.

In addition to the post below, I have a roundup of 2019 up on the site, feel free to check it out!

Fun with Ascii: Putting some console art on my site

👋Hi there! It has been a minute since I’ve been able to send one of these. I started a new job and it’s been a whirlwind. I also have a one year old in my house. Life has been great but quite busy. I made a decision to drop the newsletter and blog for a few months while I adjusted to the new normal. Things are still busy, but I’ve learned a lot the last few months and I’m hoping to clear some time to share. Tonight I’ll start with my first new article since July. But before I do, a quick note about that new job.

I now work at as an Engineering Manager in our Durham NC office. We’re a fast-growing startup with and a lot of interesting technical challenges. If you’re interested in joining us in Durham or New York City, please feel free to reach out. We have openings for Front End Devs, Back End Devs, and an Engineering Manager (NYC only).

📖 This Weeks Article

Resilient Management by Lara Hogan is a short and useful read for engineering managers who want to think more systematically about how they support their team. Lara covers concepts like how to connect with a new team, how to encourage growth in your teammates, and how to communicate difficult news. This is a blog+ book: most of the material here has appeared previously in Lara’s blog or newsletter, but for the book it has been cleaned up and organized together in a coherent fashion that makes it greater than the sum of its parts.

📖 This Weeks Article

A lot of advice in the React community is focused around avoiding explicitly storing “derived state” of some type or another. Some examples of this type of “derived state” that the community warns against:

Storing data that is directly derived from another piece of data in redux

📖 This Weeks Article

Working with people over the internet is different from meeting in an office five days a week. This isn’t a moral statement. I’ve done and enjoyed both. Working with a distributed team requires a different set of skills, especially when you’re a leader. Today I want to share the most helpful lessons I’ve learned over the last year managing a distributed team.

Evaluate process and outcomes, not inputs

Focusing on output` is great advice for any team, but it’s easier and more important when managing remote teams. When you’re not in the office with people, you won’t see when they start in the morning or finish at night. You won’t be able to tell if they’re taking long coffee breaks or checking Amazon between tasks. You’ll have to evaluate them on their output and on the methods they use to get work done.

📖 This Weeks Article

Working with people over the internet is different from meeting in an office five days a week. This isn’t a moral statement. I’ve done and enjoyed both. Working with a distributed team requires a different set of skills, especially when you’re a leader. Today I want to share the most helpful lessons I’ve learned over the last year managing a distributed team.

Evaluate process and outcomes, not inputs

Focusing on output` is great advice for any team, but it’s easier and more important when managing remote teams. When you’re not in the office with people, you won’t see when they start in the morning or finish at night. You won’t be able to tell if they’re taking long coffee breaks or checking Amazon between tasks. You’ll have to evaluate them on their output and on the methods they use to get work done.

Hi All,

Before you get to the article, I’d love a bit of feedback from you. I’m starting to write more posts on leadership/management topics (the following post is an example). Since my site started as a pure technical blog this is a bit of a departure. I still intend to post both types of articles and I’m considering splitting the blog into 2 separate topic-focused blogs to keep things interesting for the audiences that have found me at different points.

I’d love to hear from you whether you’re interested in dev content, leadership content, or both. Feel free to reply to this email or vote in the twitter poll.

Update: I’m working on making some changes to the blog right now, and some inconsistency in posting will probably continue for the next few weeks. Should have more info soon :)

📖 This Weeks Article

I used to find myself using the term “herding cats” a lot when confronting inertia, disorganization or ambiguity in work situations. actually endorses this:

📖 This Weeks Article

I saw a tweet thread a few weeks ago that made me think:

There’s a bit of a meme in some parts that there is value in saying, out loud, “I realize that I am surprised.” For similar reasons, I often subvocalize “I believe I now understand the type of situation the ‘trivial’ advice was preparing me for.”

— Patrick McKenzie (@patio11)

📖 This Weeks Article

Deliberate practice [is when] (1) your attention is focused tightly on a specific skill you’re trying to improve […] (2) you receive feedback so you can correct your approach to keep your attention exactly where it is most productive.

📖 This Weeks Article

One of the most popular posts in the history of my blog was a list with the click-baity name Ten Things A Serious JavaScript Developer Should Learn. It explicitly focused on the set of technical skills that you need to become a “senior” JavaScript developer. While I’m happy with that post, I’ve always wanted to revisit the idea, because it is my strong belief that once you’ve hit a minimum level of technical capability, only about 20% of career success is determined by your technical skills. The other 80% is composed of skills that can be loosely bundled under “soft skills”.

📖 This Weeks Article

The last few weeks I’ve had several conversations with a coworker about consistency in code: why do we do things one way here, and a different way there? Some of this is macro level; Where do we split chunks of related functionality into different files? Some of it is micro level; what should the rules be for when we use an inline function instead of pulling it out into its own named method? Some of it is trivial; Do we use _ or - to separate words in file names? In our current codebase we’re not always consistent on many of these issues. As we’ve discussed the various issues, I realized that some of them bothered me more than others, and (more interestingly to me) my ideas have changed here over time.

📖 This Weeks Article

For the last 6 months I’ve been serving as a hybrid developer/engineering manager. It’s been an interesting experience, and because this is a fairly common way to transition into engineering management¹, I thought it might be worthwhile to share some lessons I’ve learned so far.

📖 This Weeks Article

I’m trying something different today. This is a review of 2 books I’ve read recently; I’m combining them because their similarities and differences are just as interesting to me as the practical steps they encourage.

Deep Work is a 3 year old book from Cal Newport focused on encouraging readers to spend more time on their most important work. It starts out with sections defining and motivating “Deep Work”: focusing without distraction on cognitively demanding tasks. Then it goes on to give a series of recommended strategies for creating more and better deep work time in your life.

📖 This Weeks Article

As I’ve gone through projects over time, I’ve found a few functions that I end up creating for every significant project that I’ve worked on. Some of the details differ from project to project, but the basic function remains the same. I thought it would be helpful to do a rundown:

React/JSX

Some of my utils are focused on making JSX nicer to deal with. 2 situations that I’ve run into a lot in JSX are conditionally showing an item in JSX, and determining which of several classes to add to an element based on logic. Scenarios like these:

📖 This Weeks Article

Once somebody hits a minimum threshold of technical skill to hold a job in the industry, about 80% of their ability to succeed in Software Development is determined by their communication and people skills, not their technical abilities

-

📖 This Weeks Article

A member of my team at work asked me last week how I continue to learn things about JavaScript. This is my answer. Note that it is focused on leveling up for folks with existing programming experience, not giving the best pathway into the field.

I’m going to break this up into 3 parts.

📖 This Weeks Article

I recently read A Philosophy Of Software Design by John Ousterhout. In an early chapter he paints a picture of a “tactical tornado” programmer, a programmer who is always focused on solving the current problem by the most expedient method possible, with no thought to the long term implications. I suspect anyone with even a few years in the programming has seen programmers like this, and has also from time to time written “tactical” code like this themselves. Ousterhout’s recommendation is instead to write code strategically rather than tactically, taking more up front time to plan the structure for the benefit of longer term productivity.

Ousterhout focuses his examination of tactical vs strategic coding on the issue of complexity. Complexity as he defines it is anything that makes the system difficult to work with. It is the root issue behind much of the concern I identified in my . But we can expand this to encompass all of the front end concerns. We can easily impact reliability, performance, ease of change, accessibility, security and capability when we make short hand tradeoffs.

📖 This Weeks Article

Once you get past the initial complexity it creates by bucking conventions, React is the most developer friendly UI library I have ever used. A big reason for that is the way it uses and encourages a variety of patterns to share codes and concepts across a code base. Let’s look at how 4 traditional code re-use patterns are used by React and in the React ecosystem, using a simple counter example to explore why each pattern is used.

Inheritance

Inheritance is a code-reuse technique associated with object oriented programming. If you’re like me and learned to program in school using Java, it probably is one of the very first Computer Science concepts you learned. For self-taught JavaScript devs it may be much less familiar. Inheritance is a pattern for extending an existing class or object with additional methods or data, possibly overriding the implementations of other methods in the process. A classic example of inheritance looks like this in JS:

📖 This Weeks Article

Performance is a tricky topic to give generalized advice about. Moreso than any of the other front end concerns I discussed in my post at the beginning of the year, it is remarkably tied into the details of what an app is doing and how it is built. That said, here are some general principles for designing performant applications that I’ve picked up over the years:

1. Measure First

📖 This Weeks Article

When it first became a part of JavaScript, I wasn’t sure how much I was going to use async-await. I could see that it made things prettier in some cases, but I was pretty happy with my promise chains and thought that async-await might just be some extra language baggage. Since then I’ve fully converted; it’s one of my favorite features added to the language in recent years. The reason? It helps you write code in a linear manner.

A principle of readable code:

📖 This Weeks Article

In my recent post on Front End Architecture I identified Reliability as a key concern of front end architecture. I define reliability as follows:

📖 This Weeks Article

I’ve read 2 things lately that really reminded me of the value of code reviews. One was A Philosophy Of Software Design by John Ousterhout, which I reviewed here. Philosophy of Software Design is a practical guide to software design, and Ousterhout emphasizes code reviews as the best point for “practicing architecture” in real world projects. The 2nd was Sophie Alpert’s recent blog post , where she lists the various advantages she’s seen from having code reviews. I can’t improve on her list, but I can endorse it. I’ve seen all of the things she listed as benefits from code reviews in the past. However I’ve seen these benefits come out in some environments more than others. So I wanted to share 6 practical tips to getting the most valuable possible out of your team’s code reviews.

📖 This Weeks Article

The word “architecture” gets thrown around a lot in software discussions. But we don’t seem to always use it the same way. Some example usages:

Our app uses Redux for our architecture.

Hi all, this is Ben McCormick. This is my first week trying out a new newsletter format for email subscribers. More details below in the post, but I’d love feedback!

📖 This Weeks Post

2018 was the 5th full year of this blog, and I chose to experiment a bit. For the first 9 months of the year, I posted a Weekly Links post every week, and also published 24 normal articles, before taking a break the last 3 months to deal with some changes in work and home life. My employer went through an acquisition this year and I started working with a new team. Then Claire and I welcomed our first daughter, Elena, to the world earlier this month. It’s been a busy but rewarding year.