CS in Review
A weekly roundup of my favorite papers/articles

The Software Ark: Issue 6

Tue 06 September 2022 / the-software-ark

Quote of the week

I have no intention of making small bets

- Masayoshi Son


WhatIfs and WhatNots - Markov Chain Monte Carlo

I've always been a fan of forecasting - I believe in the "if you fail to plan, you're planning to fail" paradigm. Forecasting is quite ubiquitous, you use it when: planning a project, planning your investments, deciding to buy a house, etc. The way I do this is by encoding what I hold to be true as Google Sheets formulas, and then leveraging Causal which integrates well with Sheets. This is basically MCMC: Markov Chain Monte Carlo.

The space of forecasting is getting quite saturated now which is a good thing. We have Prophet from Meta, now AWS Forecast and so many more. As far as I'm concerned, it's only a matter of time before forecasting becomes the gold-standard of risk-management.

The absurdity of being too busy

Raise your hand if you've ever been too busy to build high-quality software. Since you can't see me through the screen, my hands waving in the air. In my opinion it gets worse as you get more and more experienced. You get brought into more meetings, are asked for your opinion on things that don't matter but are fun to talk through, spend time interviewing to help out sister teams that don't have experience hiring themselves, etc. In positions of leadership, this can cascade to your team if you're not too careful: you're busy, so you ask someone on your team to go to that meeting instead. You ask them to attend a design review and to let you know if anything seems fishy. It slowly builds up.

That's when I advocate for focus, then simplify. You take a step back, decide what's important and then work on that. You have to communicate the reprioritization to help course-correct (or be course-corrected). But it beats having to work 40+hrs/week regularly. It's one thing for someone to choose to work longer hours to get promoted faster. It's another for that to be considered the baseline to meet expectations.

Working crazy hours or in a stressful environment is known to affect the sustainability of said pace and causes harm. Though motivation does protect against this somewhat. High productivity is just masking an exhausted workforce.

From a management perspective I agree with Nicole that we need to rethink how we measure and reward productivity. I'm curious to see how Meta does it. A lot of people put in more than 40 hours and might generate more impact. But is it normalized so you can exceed expectations putting in 40 hours? or is that not a factor when it comes to PSC? I guess I'll find out.

See also: do we need an office, and optimizing the remote experience.

What distinguishes a great Software Engineer

I would've put this as a link, but it's important enough that I honestly think it's worth a separate read.

My summary:

  1. Don't be an ass - consensus is that you can't learn this.
  2. Embody Kaizen - keep trying to get better.
  3. Think in bets to make robust decisions. Embrace complexity and manage it well by maximizing the current value of your work.
  4. Write good, clean code. Code that makes people say "This person knew what they were doing".

If you want a better summary, check this out, or better yet, read the paper!

The silent majority - dev edition

The silent majority holds a lot of unacknowledged power in both politics and in the day to day. As consumers, they're who you build for - they'll give you the most revenue. But they won't engage with your feedback channels, or give you a review, but they will use your product - and you've got to learn by how they use it.

As your peers (fellow devs), they keep the world running, don't engage with latest fads, that cool new article/language/library, or sometimes even business goals. I knew a lot of devs who didn't really care if the company flourished or if it crashed - they wanted to come in, write code, and clock out. You don't hear about them much, and I don't think that's right.

While I disagree with this author that being more vocal is always a good thing - I think being aware that you're only seeing the tip of the iceberg when it comes to any opinion / argument is very very important. It's why data-backed decision making works, but data-driven decision making really doesn't.

Write to think

100%. Putting pen to paper, or fingers to a (custom) keyboard really forces you to think through what you want to convey. Which in turn forces you to think through what's important, why you think it's important, the details to support your argument, etc. I find that writing an e-mail forces me to clarify my thinking a lot more than just sitting and staring at a screen. Though that's important as well. What I fail at is condensing my thoughts at the end, despite multiple revisions. It's hard to know what to keep and what to leave out.

Instead of yammering on and on, let me instead direct you to: putting ideas into words


Your moment of Zen

If only learning worked like this