The Software Ark: Issue 6
Quote of the week
I have no intention of making small bets
- Masayoshi Son
Articles
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:
- Don't be an ass - consensus is that you can't learn this.
- Embody Kaizen - keep trying to get better.
- Think in bets to make robust decisions. Embrace complexity and manage it well by maximizing the current value of your work.
- Remember that sometimes trips "to the moon" might make sense
- Write good, clean code. Code that makes people say "This person knew what they were doing".
- Sometimes choose technical debt, but never technical fraud.
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.
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
Links
- The state of Java & the JVM
- Meta's releasing BlenderBot: GPT3 + organic interactions + the ability to search the interwebs
- AWS Wickr - E2EE messaging in the public sector
- Do you think you'd ever want to go to a virtual classroom?
- Bar-Raisers, Committees, and Structured Hiring
- Honeypots for students: fake websites tracking cheating students
- ML enhanced code completion to boost productivity
- Circuit breakers for better CI/CD at Slack
- It's kinda crazy that AWS released an open-source K8 auto-scaling library to work on top of AWS
- Go use Python's walrus op, I'll wait
- You can pay someone to tell you what to tell DALLE2
- Git's DB internals
- Auto responding to recruiters with GPT3 - I want this!
- Python's still #1 - when was it not?
- Owl to distribute hot content - torrenting at scale in Meta
- DataMesh as a platform, a Netflix production
