or practical like Facebook’s

I’m also part of a fast growing company and we’re always hiring, so I thought I’d see if I could leave a fun message in the console, and play around with ASCII art while I was at it.

Kustomer’s logo is Kusty; a smily speech bubble with apostrophes for eyes:

So how did I get Kusty showing up in the console on this site? I started with a bit of a cheat: I asciified the logo using asciify.me/. That got me a nice starting place, I had an Ascii version of Kusty to work with:

 ' ``.'` . -_+")cTtfyyyszztszszszztzfztfsfzsfzsstttyt17vr>, .   ` '-`- `
  ..`.'`.~)71tyyzzfzfzsyststztyftsytsystyztzzyzsyyytyfsytf1l?!  -.` `'`.
-.- - `+}Tzztsfyffztzzyyztsffyytfyyzztyfzyfzyfystzftszfytfysyt{+--'.- `.
 `--.>Lyffttyztsfyztyt11fYtyyzYTz1yT1yfzfTt1TsYfftsttzzysffssyyt7+  ''`-
 -`!iysttfstffzTi?"+,,!~^~!^__~!_:,:^^^,!~_~~:_,,!:^+/i1zyytfyztzzi~''-.
. !}tsftzffyTv+~..  -`-.' '. .`-   .'.-- ` ` . -'- .-..~+v1fsfttszf}< . 
 ,xftyyysszv, -. ```' '. .-.``'.-   ''.'--'- '  ` ...''  .!vytyzsstsx^- 
'/zsstzzzf*` `` '  ` `- '`- ` `.`  -.-   - `.'-- -` - '` '``=1szfyzssi' 
+Yzftsztf? `  `-` ` -- ` "vje4J>' ...` `  '~iteau(.'` `-- ``'/tzszszfY+'
isttsstzl:     `.-  .`'[qQQRgQBt  - `-.' rkDQWRQg6  -''- `   ^]ffyzstyi'
xyfssytyv''- .''-   .:#QBW&j}v+'  '`. `'s@gR@$Lv"-``   - - .'`?ystysztL`
xtyytzsyv .`-.'-  `' JRgBV:...``.' -.  [HWHd+  .'-- `-     '' /ysyzftsl'
cyyfysfyi  '-`'``' -`NBWW^'    .'`` - '2gBQ{`    .-`-'. . `-'.(zsyyzzzL_ 
{ytyztfti    '-`'..''DBRWSS%9wk"-  .-  nWWHOwE%%5x    `' -  `'|ftzttytx- 
{ttszfysi.`-' `.'' -.DWHgggBRgH2-`.''  2BWHgWRHgB&' .`. '  . '/sfztfsyc` 
7zzsfsyzi - '`  '' ` &BHgQWRgBHj-'- ' 'JQWHBBHHHQ@   ` .-```- /ttfttyy7' 
lsfsttfti-'.`  -` -'`DBHgHHRWRHu.. `'`.nWHRgRRBgg&.`'` '`   '-?fsysfss7.
xstfsytti `- `.'''`.'pBBRQQRBgBn. '' ' CQBWBQBBBQO--'`   - -- )sstfzyz] 
}fzztyfsv.  ' -   '..+[yfsfyzyv!-    ` !ittfftztc+' '  '  -. ')zzzzstsL`
7ttszfssi'- '-  '`  -``-- - -`` -.-.-`` `` '..- . .''- .  '.- /sfyyftsL`
{fsyysyzv-' ' .-  '`  '    - - -  ```-...' .' -  - .-'`-.'-  `/fstyzszl'
7{yzzyttfi '- '.'.' ' ' . - - . -'  -'-- ''`  .  -'   `'- .  '`(ffstfss}`
{ztfzttsi -   -' ..'` ``'`.--  .  -. '. .'''   '  -' -''.-. ' )zssfyzs]-
{tzszzzyi'.'-`.--  ' `"&QQQHQWWgHWWgBQWWBggBgWW&/ `` '.' '`- -/zfszzzs}-
xyffzzzsi -.`-`'''- ' ']MHgHRHHgRQHBBWQWHHgBQQO1-`.`'.--. ''` |zzztfysl' 
ittsfsttc^`   -  .'   '`~zMHHQWgBQRQgHQWggHQMt:'' '`- .'   `-,{fttttzzi`
+Yzftsstt|'. .  ' .   .  .-vJONHHBWQggBB&MFi. ` ' -.  `.'--  \yyzszyf1>`
 /tfyyyzyf"  - `.`'..``  -`- -+\c1f2yTc/<. '``.-`.`'-.'`-'` rfztyssfsi'' 
 :Ltzzytsstv,- ` '.`'  '` ' ```- '`    .`.- `'. . - ` ``--,itftfsfyt{,'`  
--^LtfsfsftsYi+:'`-. `  .  .-` - `.--''`` -   `. ``'`  ~>iTztyyyfzs[< `.
.. ^iftstzzfsssYv)r,^__!_^!!~'.-'. ..- -'' `,_:_~_~:>)i1zsfzsstfzfi!. `-
.`  .>]ytfyyzsyszftsz1TYY1Y11v>-     -.'-'. {TYTTYstzttfzsfftsstl<'   '`
-.-.-. >lfsszzsyytszysyzzzzysfy1?< '       `7zzffsyystzsttztzfx>` ' - .'
`.' `''`.^(c1zfttfztfyssyyffttzyyf}r~.- '''-7tfyzszzztysfy1L(!-.-`-.`.-`
-'    `' -. !+"([TyyzyzzsztststfsszyYi*_` -`{zyzfzfffT[v">!'`..`-` .`.-` 

At this point I could have tossed that into a console.log and called it a day, but I wanted to take this to the next level. And that means color!

This isn’t something you run into every day while writing for the web, but it turns out that you can apply css to text in the console using a %c macro. The format goes like this:

console.log('%cbold text %cred text', 'font-weight:bold', 'color: red')

That code outputs bold text red text.

Of course its a pain to split that giant Kusty ascii block into multiple console logs with different colors. So I minimized the pain and wrote a script that would let me take a set of ranges and render characters in one of 3 colors, and using either solid characters A-Za-z1-9+{}<>; or space characters `.,_-’. I did eat the cost of writing out the map characters manually based on the generated ascii. If I was going to do this again, I’d probably write out a script to generate the map from the original ascii image, and just fill in the color mappings manually.

//we use these characters for the solid lines
const solidChars =
  'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ123456789+{}<>;';
// and these ones for empty space
const spaceChars = " `.,_-'";

// these maps chars and colors 
const chars = [spaceChars, solidChars];
const colors = ['#E0E0E0', '#ED6159', 'black'];

// this is the mapping to generate kusty
const map = [ [13, 0, 0], [45, 1, 1], [13, 0, 0], null, [9, 0, 0], [53, 1, 1] /* etc */ ]

// generate the ascii string from the map
const ascii = map.reduce((agg, val) => {
  // nulls mean spaces
  if (val === null) return agg + '\n';
  agg = agg += '%c';
  let characters = chars[val[1]].split('');
  const randChar = () =>
    characters[Math.floor(Math.random() * characters.length)];
  for (let i = 0; i < val[0]; i++) {
    agg += randChar();
  }
  return agg;
}, '');

const colorStrings = map
  .filter(x => x !== null)
  .map(
    val => `color:${colors[val[2]]}; font-family: monospace, font-weight: bold`
  );

console.log(ascii, ...colorStrings);

The code is fairly straightforward, going through each segment and generating a string of random characters based on the map. The interesting parts are probably:

• We use null to denote new lines. Could have been anything, but null is pretty obvious when you write out the mapping markup.
• I usually use lodash for this, but I wrote some custom code to pull a random item from an array: const randChar = () => characters[Math.floor(Math.random() * characters.length)];
• I added a rare for loop in JavaScript code: even though map/filter/forEach etc work better for most things, a for loop is still the best way to do things when you’re given a number of times you want something to occur.

It works pretty well!

Next Steps

Now that I’ve done this it would be pretty easy to reuse this code to create a terminal Kusty with chalk. Maybe next New Years.

For everyone else, if this seemed fun to you, you might be interested in the job openings at Kustomer. Feel free to apply or reach out to me directly if you’re interested in working with us.

Turns out that starting a new job while learning to be a parent sucks up a lot of time! I’m not making any promises for 2020, but I expect that my writing rate will fall somewhere in between the first 7 months and last 5 months of 2019. In the meantime, here’s a brief look back at the year on the blog.

This was my first year where I spent the full year managing people, and that was reflected in the blog’s topics as well as where I spent my time.

Most Read Posts Published in 2018

• Reusable Code In React: Inheritance, Composition, Decorators and Mixins The most popular post for the year was also one of my favorites: a dive into the various mechanisms React provides for reusing code.

• Improving Code Readability With Async/Await I really like async/await but its not always clear how to move older patterns to use it. This was just a quick example of taking some ugly callback code and converting it to use async await.

• What’s involved in Front End Architecture? Another one of my favorite posts to write, this is a look at what types of things developers should be thinking about when they consider front end architecture.

Languages and Libraries I used a lot of in 2019

JavaScript (ES6), React (including hooks), PostgreSQL, lodash, Jest, Immer, CSS Modules, Redux,

Tech I want to try in 2019

We’re starting to roll out TypeScript at Kustomer and I’m excited to use it in production for the first time. My code time is more limited these days, so that will probably be my main area for learning as I focus more on helping other people get stuff done.

Blogs I started following in 2019

• Irrational Exuberance! by Will Larson - a great engineering / technical leadership blog

Blogs I read every post from in 2019

Overreacted by Dan Abramov, Lara Hogan’s Engineering Leadership blog and newsletter, Rands In Repose

Software I used (nearly) every day in 2019

MacOS/iOS, Google Search, Chrome/Safari/Firefox, GMail/MailPlane 3, Twitter/Tweetbot, Feedbin/Reeder, iMessage, Slack, Jira, 1Password, VS Code, iTerm, Fish Shell, Github/Bitbucket, Fantastical, Spotify, Bear, CloudApp, Dash, Postman

Best Technical Books I read in 2019

• The Pragmatic Programmer 20th Anniversary Edition - A huge update from the 1st edition, this remains my #1 book recommendation for any professional software developer
• Accelerate - A great look at the impact improving devops/release practices can have on software teams/companies

Best Technical Leadership Books I Read in 2019

• Resilient Management - A great collection of management wisdom from Lara Hogan. Nothing revolutionary here for those who already follow her blog/newsletter, but its great to have it all together in one place.
• The Manager’s Path - A super helpful book for anyone thinking about their career path in tech, especially if they’re considering management. Lots of helpful tips for those already managing people as well.
• An Elegant Puzzle - Another “blog book”, this one is a bit of a grab bag of topics, but the content is so high quality it was completely worth it.
• Turn The Ship Around - Not tech-specific, but one of the best books on leadership I’ve read, in the form of a history of a nuclear submarine crew getting ready to deploy.

Best Non-Technical Books I read in 2019

• I Hear You - A small practical book on validation that will make you a better friend / spouse / coworker.
• Why We Sleep - A fascinating book on the (pop) science behind sleep
• Team Of Rivals - A very readable history of the Lincoln presidency focused on his relationships with the other candidates for President in 1860. Incredibly well done.
• Evicted: Poverty and Profit in the American City - A sobering look at how laws, norms and expectations around rentals and evictions in America contribute to spirals of poverty. Another very well written book, make sure to read the end to understand the research that went into it and allowed for the very personal feel.
• The Common Rule - This is a Christian look at how ritual and habit can help us overcome modern distractions and focus on the things that are important. I’ve read a lot of books in this genre in recent years (Deep Work / Indistractable / The Tech Wise Family) and this was my favorite.
• The Foundation Trilogy - Classic scifi, and a great read. Fascinating to read a mid 1900s view of the future and realize that while space travel and force fields sounded great, it was inconceivable that casual tobacco use in the home might go away.

What Is Value?

It can be easy to think of software engineering work as a series of task where you’re given instructions and you make the computer do what the designer / PM / CEO asked. Or as a series of fun problem solving challenges that you’re somehow getting paid to complete. Both of those views will eventually lead you to make suboptimal decisions when it comes to helping your business and growing in your role though. Instead consider the following definition:

Software Developers create value through shipping working code that solves important user problems in a predictable manner.

This captures a number of important things.

Shipping

Real Artists Ship - Steve Jobs

Software Engineer’s super power compared to other roles is that we get to build. We create new things, add new behaviors, and ultimately (for a product company) control the shape of the product our company is built around. This only has value when software actually ships though. When we’re not shipping, it’s actually worse than just being slow to deliver value, because of a few non-obvious factors.

First, unshipped code rots. When we leave code in a branch 90% done, it doesn’t just stay the same. It’s quite common for our situation to get worse. Our teammates check in code that may cause merge conflicts, or worse just doesn’t take into account the unshipped code and sets us up for subtle bugs. And when we do get back to the work we’ve often lost valuable mental context that makes any remaining work or testing harder and more error-prone.

Second, we learn from shipping! It’s quite common in software development for a developer or team to complete 90% of their feature according to the spec, only to find that they have another 90% of the work to go. Doing the work to push things through to production inherently de-risks things, because we learn what the challenges are, and we know how long the work took. Up until then, we will always have unknowns. And when software goes out to users, we get to hear their feedback as well. Shipped software lets us learn from our users (and from the performance of our system) and make adjustments that we wouldn’t have known about if we sat on the code.

So how do we get to shipping? First, it’s important to push things through to completion rather than allowing ourselves to jump from project to project, making progress without finishing, and incurring a lot of cost from context switching. Soemtimes this may mean imposing kanban style work in progress limits on ourselves. Second, its often helpful to break things into smaller chunks. Small code reviews are easier to complete, test, review and verify. So multiple small changes will often go through faster than the same changes bundled together into a big chunk. This can go too far, but as long as your changes work in isolation and provide value, I’d encourage erring on this side when in doubt.

Working Code

[We Prefer] working software over comprehensive documentation - The Agile Manifesto

Software engineers are responsible for their code working. At the simplest level that means delivering code that doesn’t crash when run in the intended way. As we grow and mature as developers however, we should aspire to learn to write code that will scale to any reasonable load the system might see (and maybe even to unreasonable loads), code that handles odd input or context gracefully, and code that is easy to modify and maintain. We should also take responsibility for proving that it works; writing tests, making the code easy to monitor in production, and providing good logging for debugging all fall under a software engineer’s domain. We also should make sure that our definition of working matches what the business needs, not just a pedantic reading of whatever spec we’re working off of. More on that in a moment.

Solving Important User Problems

Just really funny- What the Customer Wanted expanded pic.twitter.com/kdr7HKTSDy

— Frank Spillers (@farreaching) August 13, 2016

Software Engineers can be quite inventive in the ways they write code without solving important user problems. Some common routes:

1. Working on their own pet projects over the prioritized business problems - Tech improvement work and engineer-driven projects are part of a healthy organization, but if they consistently replace work that was scoped based on user requests / feedback, they can cause problems
2. Matching the spec without solving the original problem - This is partially a design/product problem, but its often possible to meet all the stated requirements for a project without solving the original user pain point. Great engineers understand exactly what problem they’re trying to solve with a feature and will always step back to evaluate whether they’re succeeding throughout the development process.
3. Matching the spec and causing new problems - Oftentimes our efforts to fix cause or expose new problems. When we dodge responsibility by ignoring or hiding those problems instead of openly evaluating tradeoffs or working to improve the solution, we’re not providing all the value we’re capable of.

These are ultimately issues of ownership. When we’re invested in our work, we will want to work on useful problems and make sure they produce real value. If you’re consistently not feeling that way, it may be time to find something else to work on.

In a predictable manner

The challenge and the mission are to find real solutions to real problems on actual schedules with available resources - Fred Brooks

Ok, now we come to the section that is the boring part for many software engineers. But as somebody who has recently converted to the management side of the fence, the ability to ship predictably is incredibly important.

It’s important for software engineers to ship predictably in 2 senses:

1. There is ongoing understanding of when something is likely to ship among the people who need to know
2. There is ongoing understanding of how something will work when it will ship among the people who need to know.

Estimating software engineering projects is not an exact science. Nobody reasonable expects estimation perfection from software engineers, especially those new to the field. Instead we aim to be as accurate as possible, and especially to be transparent as those estimates change over time.

When we encounter obstacles, it’s important to be realistic about what they mean to schedules and update the important people in a timely manner.

For those working on a product team that may be a manager and a PM, for those building something solo, that may be the customers or internal users of the software directly. It’s never fun to say something is going to be late, but its always better to say that we’ll miss a date that is 2 weeks away than to tell somebody for the first time that you’ve missed the date that was 2 days ago.

Communicating about the scope of work is just as important as schedule. If we find out a piece of a feature is unfeasable or we dropped it due to time pressure, its important to communicate that. Depending on your team/product, that may mean sharing with people directly, updating documentation, or just making the new behavior clear in an interface.

It’s a process

Nobody starts out their first software engineering job with a fully evolved sense of how to estimate, scope and document their work. Most have no clue how to think about building a system to be scalable or when to escalate problems to other members of the team. These are skills learned through hard experience. Make sure to always be reflecting on what you’re experiencing though. Experience combined with reflection is a powerful mixture, and eventually will lead to growth. Good luck!

If you’ve followed my newsletter for a while, you’ll have seen me link to Lara’s work on a regular basis. Lara’s strength as a teacher is building meaningful exercises for thinking through abstract topics, and that plays out here. Almost every piece of advice and insight comes with a suggestion on how to start implementing it, or an exercise to help you think deeper about yourself or your situation. I’ve found her leadership colors and her MadLibs worksheet for leadership philosophy particularly helpful for me.

In addition to the helpful exercises, the highlights of the book for me were Lara’s look at the BICEPS model for understanding people’s needs at work, the way she structured her book around a groups evolution over time, and the chapter on communication plans. I’ve made notes to reference each of those areas the next time I hit a relevant situation.

Overall I’d recommend this book to pretty much any early-career engineering manager. If you’re not already familiar with Lara’s work, there should be some fantastic new ideas for you in here. If you have followed it, I recommend buying out of appreciation, and to get the concepts bundled in a nice cleanly organized packages. These are ideas worth paying for.

Resilient Management is available from A Book Apart

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

const reducer = createReducer(initialState, {
  ADD_USER: (state, action) => {
    state.users = [...state.users, action.user];
    // numUsers is derived state: it will always be tied to users
    state.numUsers = state.users.length;
  }
})

Storing state that is directly derived from a prop in a component

const Widget = props => {
    // the hasError state is derived from the error prop
    let [hasError] = useState(!!props.error);
    //... continued ...
}

Storing state that is directly derived from another piece of state

class NameForm extends React.Component {
    constructor(props) {
        super(props);
        this.state = {
            firstName: '',
            lastName: '',
            fullName: '',
        }
    }
    // because fullName is directly associated with firstName and lastName, we have to update it
    // any time they are updated
    updateFirstName(newFirstName) {
        this.setState(state => ({
            ...state,
            firstName: newFirstName,
            fullName: newFirstName + ' ' + state.lastName,
        }))
    }
    updateLastName(newLastName) {
        this.setState(state => ({
            ...state,
            lastName: newLastName,
            fullName: state.firstName + ' ' + newLastName,
        }))
    }
    // ... continued ....
}

These examples are all based on real-world code I’ve seen. And they all were in code that worked, the program executed as expected. But they’re still problematic. This type of derived state is error-prone; when new code is written to update the state, each new programmer touching the code has to understand the relationship, or the whole thing can get out of sync. When state is coming from props, like the error example above, you have to make sure that the state gets updated properly when the props change. And when the state gets out of sync, it is possible to end up in strange states where a programmer’s expectations are violated. A program shows a blank state saying no users have been added, even though one has already been created. A form is expecting to have an error, but the error text is empty or set to a default value. Or a site has 2 different names for an individual that show up differently in separate parts of the interface.

This type of problem isn’t a new thing in Computer Science. When programmers do it by accident they usually call it a DRY violation. When they do it intentionally they call it caching. And when they do it intentionally but screw things up, they make jokes about off by one errors. Fortunately, that means that the tradeoffs are pretty well understood here. So how do we handle situations where it looks like derived state may be necessary?

Just Derive State At Render Time

For many many things, including the 3 examples above, if you need information at render time that can be derived from other pieces of state, it’s totally fine to just calculate it at render time. For the first name example above, you can just include a let fullName = this.state.firstName + ' ' + this.state.lastName; line at the top of your render function and move on¹. Storing derived information is unnecessary and harmful when calculating it at runtime adds minimal performance overhead or repetition.

Memoization

But Ben, my component is slow now!

…are you sure it’s actually slow? Have you tested it? Have you proven that the derived state calculation is actually a meaningful part of this?

Deriving state can be slow when you have to do complicated calculations or reformatting of data. This is still not usually a problem, but if you’re in a performance sensitive area of code and have proven it to be a problem, you can start considering caching solutions. You still don’t want to store your cached values in state or your redux stores though. Instead, you want to use a computed value that is recalculated when its inputs change. The exact code will depend on your state management strategy, but some examples out there include

• Reselect for Redux
• Computeds in MobX
• useMemo in React Components

All of these methods use memoization, a type of caching where arguments are passed to a function, and if the function has been called with those arguments before, it returns the previous result rather than recomputing. If for instance we had a component and wanted to get the names of all users with the current type based on props, and we knew that users was sometimes quite large, making the calculations slow, and we expected the component to re-render often for some reason or another we might write code like this:

const UsersList = ({users, type,}) => {

    let userNames = useMemo(() => users.map(user => user.type === type), [users, type]);
    // ... continued ...
}

Now userNames will automatically be recalculated only when users or type changes². The MobX and Redux solutions work similarly. Memoization isn’t a performance silver bullet: at some point, you might have to look at how you can make your calculations less expensive or take them off of the rendering path completely. But for most simple data transformation tasks, deriving state at render time and using memoization to keep it performant where needed should help you tame any derived state problems you encounter.

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.

Evaluating on outputs is tricky for tech work in the short term. It’s often hard to tell how hard a specific task should have been. But over the long run, you’ll need to find ways to see if developers are meeting their goals, and focus on that over the exact times they did work. And this is good, because that is actually what matters.

Output is a lagging indicator though. In the short term, what you can evaluate if “butts in seats” isn’t an option. I recommend process: is work being documented, are tests being written and are code reviews being done in a timely manner? The nice thing about this is that you can check these things in low touch ways; by reviewing your issue tracking and version control systems rather than having status meetings or sending distracting slack messages. This idea comes up in Camille Fournier’s book The Manager’s Path, where she argues persuasively for always doing your information gathering in ways that don’t disrupt your team first.

1-1s are extra important

Let’s say Sarah has some lingering concerns about her current project that she’s not yet ready to raise to the full group. When I work in the same office with Sarah, she can drop by my desk anytime to talk through a small issue. When we’re working remotely, that may not feel as comfortable for a variety of reasons. Good 1-1s provide space for the little things to come out.

When you get in-person time, focus on the relationship

Currently I get together with my team (and my manager) about once a quarter. Initially my instinct was to save the “big work stuff” for that time. And I still try to get a few big conversations in each time, mostly around career development. But the most value from these visits has come in the gaps, when I go out to lunch with my team and chat, or we get together with a larger group after work. Time spent together builds trust, and that trust lingers and pays off when you’re back on the other side of the internet the next week.

Async communication is great. Don’t neglect “face to face” time.

“Embrace async communication” is common remote work advice. When you get stuff done through email/slack/Github/Invision/etc you have fewer meetings and more flow time for your team. Which is great! My team takes advantage of “async” tools every day. But I also try to be intentional about working in “face to face” time through Zoom. For my team that’s a daily standup and weekly 1-1s, but it could be different for another team’s process. The key is to not only rely on writing. Writing is an amazing way to communicate, but it will always lack the context of the human face. For now I’m aiming for a mix of mostly async with regular “internet face to face”, and occasional “in person”.

Make sure to personalize your communication as well. If Jerry tends to miss all nuance when you communicate in text, try to spend more time talking over zoom to make sure you’re communicating. On the other hand if Jennifer has a tendency to lose track of what you’re asking her to do, you may want to give instructions through a text medium, where you can use it for accountability later.

Hire for remote success

Not everyone is going to thrive in a remote role. Most companies hiring remote recognize this and try to filter for it in some form. A lot of companies’ response here is to “only hire senior”. Which is probably a workable heuristic in some ways. Developers that have a proven track record of success probably have built up some habits that will help them succeed in remote work even if they aren’t naturally inclined to it. But hiring only senior folks is expensive, and makes things like diversity and career growth paths harder.

I haven’t done this enough to draw any hard conclusions on remote hiring yet. But the qualities I want to evaluate for are independence, technological comfort, writing skills, and a history of taking the initiative to seize opportunities (in whatever domain). Obviously that’s in addition to normal hiring criteria.

Tools and Process matter

The worst way to work remote is to not commit to it. Commitment means aligning your process toward remote work. Some lessons here.

First, Hybrid meetings are harmful to your team. There are 3 ways to do meetings: in person, remote, or hybrid. An in person meeting involves putting a number of humans in a small room for an hour and letting them talk through an issue. A remote meeting connects various people from the comforts of whatever work venue they’ve chosen, and discussion ensues over the internet. In a hybrid meeting, some people are in the room, and some are connecting remotely. Hybrid meetings are hell for the remote folks. Usually they can’t hear at least one person well. They can’t match faces to voices, lose context of what is happening in the room, and are sometimes just plain ignored by the folks in the room.

I really didn’t understand how bad this was until I did it myself a few times. If you’re a leader who uses or tolerates hybrid meetings, I highly recommend trying to call into them remotely a few times. As the boss you’ll get a slightly different experience, but ask yourself: are you a first class meeting participant when you’re calling in remote? If not, is it acceptable to you to treat your remote workers as second class participants?

Second, Use good tools. Bad collaboration software is a drag if you’re working with people in person. It’s a killer for remote teams. Use software that lets you communicate in timely and useful ways, keep your project critical information organized, and lets your team focus on getting stuff done. There are hundreds of good tools out there these days, so there’s no excuse for using bad ones. My recommendations, which are not particularly controversial and also not the only good options: use Zoom for video chat, Slack for messaging, Bitbucket, GitHub, or Gitlab for Version Control, Trello or Jira² for task tracking depending on the size of your team, and Google Drive for keeping documents and documentation together³.

Camille Fournier’s book The Manager’s Path steps into this breach by laying out a clear look at an engineering management-focused career path. The book runs through a series of roles: Mentor to Tech Lead to Manager to Manager of Managers all the way up to Executive. For each role she describes what the job is, walks through what type of challenges you might face in the role after a promotion, and offers practical advice on overcoming those challenges.

I found it to be an extremely engaging read, and the best description of what it actually looks like to advance in technical leadership roles I’ve ever read. Because she focuses on skills and responsibilities more than titles, it’s possible to apply her advice across large and small companies, even those with wonky title structures. It helped me think about what skills I need to be building in my career, and gave me a glimpse of what next steps look like.

The focus on common challenges and how to face them was also helpful, though whole books could (and have) been written on those challenges and how to face them at each level. The Manager’s Path serves as a good starting point here, identifying the challenges and giving good solid general advice for facing them. For those new to a role it could help them identify where they’re weak or uncomfortable, and serve as a starting point to a deeper dive into those areas.

As I read the book, I immediately thought of 4 or 5 people at various points in their career I knew who could benefit greatly from reading this book. If you’re working in the software world and think that you long term are interested in advancing in your career beyond your current role, there will probably be interesting tidbits in here for you. Even those who are sure they don’t want to be in management could benefit from understanding the perspectives of what engineering managers actually do. The book is also structured so that the first few chapters are highly relevant for both technical and manager track developers; tech lead is an important role on both tracks. If you fall into one of those buckets, I highly recommend The Manager’s Path.

Choosing values is an odd process, because you’re choosing between “goods”. When I first went through this sheet, I circled over 40 words as values that “resonated” with me. They’re things that I value and strive for, or wish that I was more like. Deciding between adventurousness and cowardice is not a “values decision”. A real values decision means that you’re trying to decide whether good traits like adventurousness, belonging, or clear-mindedness are more important to you.

Management often forces you to choose between goods: Will we ship quicker? Aim for higher quality? How do those choices impact work/life balance for our teams?. It’s hard to know if we’re making good choices, because the results routinely lack clarity. Indicators lag, causation is fuzzy, and we don’t get to compare to a control group. Values can be guideposts through ambiguity. I’ve seen the power of this at a company level in my current gig, where having a set of values that are kept in the spotlight often allows us to weaponize them as decision making tools ¹.

Going through the list, I eventually cut things down to 20, 12, 10 and then 8. That still feels like a lot to me, but for each of the 8 I can easily cite work situations I’ve faced in the past month where my response came directly out that value. In the end I ended up with Integrity, Thankfulness, Community, Prudence (in the classical sense), Generosity, Continual Improvement, Accountability, Justice. I find that these are easy to connect to my everyday work when I write them out as more detailed sentences though.

1. Act with integrity.
2. Live with thankfulness for what I’ve been blessed with.
3. I want to work and live life in community.
4. Make decisions based on a rational analysis of reality, not feelings and first impressions (Prudence).
5. Don’t save it all for myself. Leave margin and be generous.
6. Continual Improvement + Goodism are a powerful combo².
7. Be accountable for my responsibilities and hold others to the same.
8. Actively work for justice

I’ve published them here with a bit more detail.

Those are “guideposts” that I can easily quote to myself or post up somewhere, but they still have enough substance to say something meaningful when I’m considering how to handle a low-performing employee, organizational changes, or personal career decisions. I’ve already seen these values bring a clarity to my thinking about tough things in a short period of time. If you’re interested, I highly recommend checking out Google’s training.

The phrase herding cats comes from the common saying that something involving coordination of many different groups or people is as difficult as herding cats. One of the commonly encountered uses of the term in technical fields is the phrase “Managing programmers is like herding cats” or “Managing engineers is like herding cats”. In education it would be “Managing students is like herding cats”.

The phrase correctly captures the difficulty of getting a group of programmers (or even worse teams of programmers) on the same page. But there’s an inherent arrogance to it. The implication is that the herder is the adult in the room and everyone else’s pointless individualism is getting in the way.

There are days that I think I could fix everything if I could just get the *&$% cats to move in the right direction. In those situations I’ve started telling myself that what I’m actually doing is herding lions. How do you herd a group of lions? I have no idea. But I know that if you don’t start with a healthy respect for the lion’s capabilities and agenda, it won’t end well for you.

When you treat people like lions, it’s an opportunity to stop and figure out why they’re not just getting on board with your obvious plan. It’s an opportunity to learn, to find new ways to motivate people, and maybe even to empower somebody who had been viewing themselves as more of a kitten. Ultimately the best teams flourish where people can be strong contributors, take risks and do work they find meaningful. They’re teams of lions.

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.” https://t.co/JzdYmSvJWH

— Patrick McKenzie (@patio11) April 9, 2019

And then you repeat it to someone and they say “lol that is obvious” and you wonder if you know the advice well enough yet to correct them on how not obvious it is going to be for their next 10 years.

— Patrick McKenzie (@patio11) April 9, 2019

I realized that I’ve encountered plenty of pieces of wisdom in my software career that have this property; I see them as clear and obvious when put in the abstract, but only learn to actually apply them by repeatedly failing to do so. This is what people talk about when they say something is “hard earned experience” I guess.

Here are some examples from my career:

1. In the long run, rate of improvement (or regression) matters more than current level - This has applications in hiring, code quality, and finding/staying in a job. But it’s often easier to observe how good something is now than to see how its changing, and I often fail to properly estimate what a trend means for a situation 1-3 years down the road. It’s also easy to mis-apply this principle when you for get about the “long run” part. A new employee with tons of potential won’t help you when you need an experienced hand now and fixing technical debt can easily cost you your ability to hit a quarterly objective. Knowing how to balance these long and short term goals is something I still struggle with all the time.
2. Rewriting from scratch is (almost) never worth it - Joel Spoelsky wrote about this way back in 2000 and I remember reading that article nearly a decade ago and nodding along. I seem to have infinite capacity to convince myself that my current situation fits in those parentheses though. In my career this has mostly been a problem where I’m able to more accurately forecast the pain that would ensue from fixing what exists (because that code exists and is easier to work with), while I appear to systematically underestimate the pain of building the new thing (because the internet told me it would be great, and the code doesn’t exist for me to nitpick yet).
3. Always consider multiple options - Pretty much any decision (technical or otherwise) benefits from having multiple contenders. This seems obvious. But I have often let myself fall into situations where I’m choosing between just 2 options, or really just choosing whether or not to do 1 thing. This has applications in technology choices, job choices, responding to another person’s provocations, and more. I intuitively know that more options are good, and I constantly miss opportunities to add options.

So how do we improve on these situations where we fail to apply obvious wisdom? I’ve been learning a few things lately.

1. Always review what you’ve done on a regular basis - Do weekly reviews about how your week went. Do quarterly reviews with yourself about how your job is going. When you make big decisions, make sure to find a time to check back in later and evaluate how it went. We make better decisions when we take the time to measure our results
2. Note Missed Opportunities - When you do those reviews, make sure to pay attention to when you missed an opportunity to apply something you knew. Sometimes we make mistakes because we just didn’t know something. It’s more common though that we didn’t properly apply our own principles and knowledge.
3. Identify Cues - Identify the thing that you know you’re going to have to handle different next time. Maybe you say “if I’m looking for a job, I should consider at least 4 or 5 different companies and not focus in on just one”, or if I’m asked to fix a legacy codebase, I will spend at least 3 months trying to improve it before considering a re-write,and I’ll look for real world comparisons to base a rewrite estimate on”. Whatever it is for you, when you can identify situations where a specific action should take place, it can help you be better the next time instead of repeating the same old mistakes.