Adam Keys is Thinking https://therealadam.com/ en Thu, 29 Feb 2024 12:37:00 -0500 “Yes, and” despite your pessimistic engineering intuitions https://therealadam.com/2024/02/29/yes-and-despite.html Thu, 29 Feb 2024 12:37:00 -0500 http://therealadam-ng.micro.blog/2024/02/29/yes-and-despite.html <!-- wp:paragraph --> <p>As engineers, we often face the consequences of shallow ideas embraced exuberantly. Despite those experiences, we should try to solve future problems instead of re-litigating problems-past.</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"> <p>Engineers put too much value on their ability to spot flaws in ideas. It’s only worth something in certain situations.</p><p>— Thorsten Ball, <a href="https://registerspill.thorstenball.com/p/63-unpopular-opinions">63 Unpopular Opinions</a></p> </blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Don’t be edge-case Eddie, wont-scale Walter, legacy code Lonnie, or reasons Reggie. At least <em>try</em> to think around those issues and <em>solve the problem.</em></p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>This is very much a note to my previous self(s).</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"> <p>Pay attention to intuitive negative emotion…If you’ve been asked for quick estimates a bunch, you might have noticed that sometimes the request triggers negative emotions: fear, anxiety, confusion, etc. You get that sinking feeling in the pit of your stomach. “Oh crap”, you think, “this is not going to be easy.” For me (and most experienced software engineers), there are certain kinds of projects that trigger this feeling. We’re still pattern matching, but now we’re noticing a certain kind of project that resists estimation, or a kind of project that is likely to go poorly.</p><p>– Jacob Kaplan-Moss, <a href="https://jacobian.org/2021/jun/2/swag-estimates/#how-to-swag">The art of the SWAG</a></p> </blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Jacob recommends noting how intuition and emotion are natural and not entirely negative influences on the process of evaluating ideas. The trick, he says, is to pause and switch to <em>deeply thinking</em> through the idea (or estimate) you’re presented with.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>This, again, is very much a note to my previous self(s).</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Now, if you’ll excuse me, I need to get back to brainstorming and estimating this time machine, so I can deliver this advice to my former self.</p> <!-- /wp:paragraph --> Building software is great https://therealadam.com/2024/02/27/building-software-is.html Tue, 27 Feb 2024 13:28:00 -0500 http://therealadam-ng.micro.blog/2024/02/27/building-software-is.html <!-- wp:paragraph --> <p>…even if some days working in corporations or under unwanted pressure makes it considerably less fun. </p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>I also just don’t especially want to stop thinking about code. I don’t want to stop writing sentences in my own voice. I get a lot of joy from craft. It’s not a universal attitude toward work – from what I can tell, Gen Z is much more anti-work and ready to automate away their jobs – but I’ve always been thankful that programming is a craft that pays a good living wage. I’d be a luthier, photographer, or, who knows, if those jobs were as viable and available. But programming lets you write and think all day. Writing, both code and prose, for me, is both an end product and an end in itself. I don’t want to automate away the things that give me joy.</p> <!-- /wp:paragraph --><cite>– Tom MacWright, <a href="https://macwright.com/2023/04/15/ai.html">The One About AI</a></cite></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>What a great distillation of what makes working on software great! It’s an opportunity to think all day, earning a good wage doing so. Sometimes, to make something of value. Even more rarely, to make something of lasting value. Most of all, to be challenged every day. On the good days, it’s the future we were promised!</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:paragraph --> <p>Other days, it’s a bit much. Corporations and all their baggage will get ya down. Deadlines, communication, coordination are how one makes big things, but they have their drawbacks. They (can) drain all the energy and excitement of <em>making</em> something.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>There <em>are</em> jobs that sound exciting from the outside or on paper. Driving race cars and being around motorsport, sounds exciting! But it’s probably a lot of toil, intense competition, and very little invention. Imagineering at Disney is likely immensely rewarding when an idea makes it all the way to the real world or a theme park, every several years. Between those years, it’s likely equal amounts of frustration and the friction of working at a giant company.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>So, for me, building software it is. Even on the days when deadlines and coordination have got me down. Thinking them through to put a bit of the magic of software into the world, it balances out.</p> <!-- /wp:paragraph --> Careers are non-linear https://therealadam.com/2024/02/13/careers-are-nonlinear.html Tue, 13 Feb 2024 12:00:00 -0500 http://therealadam-ng.micro.blog/2024/02/13/careers-are-nonlinear.html <!-- wp:paragraph --> <p>David Hoang, <a href="https://davidhoang.com/blog/should-managers-be-technical/">Should managers be technical?</a>:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>Career development looks more like unlocking attributes for a different subclass in a role-playing game, than picking a distinct class that can never change. It’s not a path. It’s a collection of skills and attributes focused on certain outcomes. Applying foundational skills is heavily contingent on your role and responsibility.</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>👍🏻 Careers, management or not, aren’t straight lines. The skills you need for your career aren’t a tree with one root. You can skip between various skill trees, if you like! You can go deep, but wide is an option too. The more you know, the more you can delegate!</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>You should check out <a href="https://www.proofofconcept.pub">David’s newsletter</a> too.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>A wise person from a Destiny 2 Slack:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>I guess when you’re done with the main quest, you go back and do side quests </p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Careers (and lives) are non-linear. Occasionally their trajectories don’t make sense. They may even outright disappoint, in the moment. The silver lining is, they give us unique skills and experience that <em>someone</em> in the world wants if only we can find them. 📈</p> <!-- /wp:paragraph --> Squeezing ideas https://therealadam.com/2024/01/27/squeezing-ideas.html Sat, 27 Jan 2024 14:30:00 -0500 http://therealadam-ng.micro.blog/2024/01/27/squeezing-ideas.html <!-- wp:paragraph --> <p>Turning a big idea into a more manageable one has second-order consequences:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>Remember, the more complex the issue, the more prone communication is to being lost.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>– Andrew S. Grove, <em>High Output Management</em></p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Communicating complexity is compression. Compressing ideas is loss-y. Can’t get around that. There’s ​<strong>no way to convey a complex idea and maintain fidelity</strong>​. To work with an idea amongst abstractions is to ​<strong>accept that rabbit holes will develop</strong>​. And, that sometimes <strong>problems will hide in the depths</strong> and mazes of those rabbit holes.</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>When you compress air, it heats up. The molecules are <em>literally</em> squeezed together, they collide more, and the air gets hotter. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>In combustion engines, compressing air coming into the engine to a higher pressure means you can add more fuel to it and get more power without increasing engine size. But, doing so requires extra machinery, turbochargers or superchargers, and requires an intercooler to cool the air down before it reaches the combustion chamber so it doesn’t explode prematurely. Second-order consequences!</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I haven’t (yet) thought of a snappy analog to compressing ideas — yet. A way to integrate this with a mental model continues to elude me.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>Abstraction, in the every-day software development sense, is compression. All the <a href="https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/">cautions</a> and <a href="https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction">mythology</a> programmers tell themselves about <a href="http://worrydream.com/LadderOfAbstraction/">abstraction</a> distill down to “compression is great if you can accept the trade-offs”.</p> <!-- /wp:paragraph --> Notes on focus and attention https://therealadam.com/2024/01/24/notes-on-focus.html Wed, 24 Jan 2024 08:34:10 -0500 http://therealadam-ng.micro.blog/2024/01/24/notes-on-focus.html <!-- wp:paragraph --> <p>Focus and attention are inputs to producing excellent things. All the talent in the world won't get me far if I’m not focused or attention isn't working in my favor. Beyond my skills at whatever I’m making (software, teams, products, essays, etc.), I need attention and focus.</p> <!-- /wp:paragraph --> <!-- wp:more {"customText":"Keep reading"} --> <!--more Keep reading--> <!-- /wp:more --> <!-- wp:paragraph --> <p>In other words: I want to make what’s important to me: teams, writing, and software. I need focus to decide what to write/build with excellence. I require attention to sustain that focus.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>Henrik Karlsson on <a href="https://www.henrikkarlsson.xyz/p/multi-armed-bandit">multi-armed bandits and focus</a>. First, explore to find what I <em>might</em> want to focus on:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>The trick is to collide your mental model with the outside world as often as possible. This is what exploring does. You think you know the distribution of payoffs of the slot machines, but you try something new. You discover that you were wrong. You update your model.</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>This is a life design thing. Get out in reality, seek novelty, try plenty of things, “touch grass” with the world outside my mental model, the more the better. Experience a bunch of things, surround myself with intriguing, intense, or impactful people. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Surely things could have gone differently for me if I’d done more exploring when I was twenty-something. But, much less of the world was available to me then. More important that I figure out the world needs exploring now and then and that I can explore even with the responsibilities of my forty-something years.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>After the exploration, “exploit” what I’ve found. Choose a few things and go deep on them. Things which resonate with me and make me think “this is a thing that I can do or invest my time and effort in”. I start doing it and that is focus.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>But, <em>really</em> choose those “pillars” of focus. If I pick seven things, I haven’t really chosen. Pick a few of these things, leave several on the cutting floor. Don't construct some wild productivity system where I can spread my energy out over the seven days of the week, over seven areas of alleged focus and get nothing done (except possibly create a wobbly ideology and maybe a video course selling it 🌶️).</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>May I recommend the rule of three? It’s great.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Focus-and-exploit lets the brain work the problem even when offline, away from keyboards and tools. Pro-tip: mundane chores are an excellent tool here. e.g. take a shower, mow the lawn, go for a walk. </p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>Why would focus compound? Part of it is time. If you care about less, you spend more time doing what you care about most. Also, you are always nonconsciously processing the thing you focus on. So cutting priorities means you work even when it looks like you’re not working. These days, I’ll spend the afternoon playing with the kids, doing the dishes, repairing the houses—being busy in a mind-clearing way. Then, when I sit down to write the next morning, I can type 700 words without thinking. The ideas have been churning in my head, just below the surface of conscious thought, and come fully formed.</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>If you're really focused, your brain is always working on those three pillars. It's thinking about whatever it is you're doing, turning over problems, processing that information, compiling it, organizing it while you sleep, and while you do mundane things. </p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p><a href="https://austinkleon.com">Austin Kleon</a> suggested a similar approach. When he runs out of writing/creative energy, he cleans his pool. Basically, he takes his thinking mind out of the loop. Lets his physical body do something routine and mundane to invite the creative mind to return. (Sorry, I can’t remember which Austin Kleon thing I saw this as a comment on. 🤦🏻‍♂️)</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>If you like this explore and exploit stuff, you’re going to really dig <a href="https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539">Kent Beck’s ideas about explore, expand, exploit</a>.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>On the other hand, allowing ideas into my sphere of thought from social feeds designed to put me in a bad mood or get me to buy stuff breaks the focus. I need attention.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Craig Mod, <a href="https://craigmod.com/essays/how_i_got_my_attention_back/">How I Got My Attention Back</a>:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>If I tell people I went offline for a month, it’s like telling them I set up camp on Mars. It hints of apostasy, paganism. Tribes seem to find pleasure in knowing all members suffer equally. But, really, is the situation so dire that we can’t wrangle a little more control? We’ve opted into this baffling baseline of infinite information suck, always-availability. Nobody held a gun to our head. We put our own mouths on the spigot every single day.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>But it’s so delicious. That spigot goo — buoyed by pull-to-refreshes and pings and wily dots. Giving up attention, so seductive.</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>I can’t focus if my attention has me thinking of “5 amazing one-takes by Scorsese” or “INSANE Porsche 911 builds”. 🧠🫠 Too much social media feed is an inescapable gravity well of wandering thoughts. Modern, programmed attention makes it difficult to <a href="https://therealadam.com/2022/12/27/think-your-thoughts/">think our thoughts</a> or sustain them.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>However, disconnection is a luxury, and a bit ascetic. The real tactic requires figuring out how to thread the needle, striking a balance between connectedness and <a href="https://studio.ribbonfarm.com/p/against-waldenponding">Waldenponding</a>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>So I need guidelines, even when discipline wanes:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>The internet goes off before bed. The internet doesn’t return until after lunch. That’s it. Reasonable rules. I’m too weak to handle the unreasonable.</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>What works for me:</p> <!-- /wp:paragraph --> <!-- wp:list --> <ul><!-- wp:list-item --> <li>Remove the glaring offenders in my “attention” life. Mute, unfollow, etc.</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Set coarse rules that protect my time to focus. e.g., I take the first hour of my day for a writing routine, while my energy is high and the world is mostly asleep instead of eager to distract me.</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Remove decision-making. I listen to the same album on repeat during my writing session (currently, <em>A Love Supreme</em>). I work through the same five-item to-do list every time to get my energy going.<br></li> <!-- /wp:list-item --></ul> <!-- /wp:list --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>Attention and energy are finite. Don’t worry when one or both dwindle. At the end of the day, after numerous meetings, the weekend after a long week. That’s when it’s basically okay to allow a little temptation into your day. Don’t succumb to hustle culture! I encourage you to take a break from crushing it now and then.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><strong>Excellence</strong>. This bit started with trying to figure out how focus and attention generate excellent work. In particular, I need more than acumen and experience to make exceptional things, teams, organizations. I need to choose the right thing to focus on. But, tying up excellence with identity can cause misery or generate path dependence. I require honesty with myself when I’m doing great work and when I’m going through the motions to keep the work going. Focus and attention are preconditions for making excellence.</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>I Swear, I Really Wanted to Make a 'Rap' Album but This Is Literally the Way the Wind Blew Me This Time – Andre 3000</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>It’s all <a href="https://therealadam.com/2024/01/12/work-in-progress/">works in progress</a>. Many posts are rough drafts I put out there to keep myself going. I have no idea which ones will stick and which ones will bounce. Plenty of drafts and following the way the wind blows me.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>I know that if I let my attention wander, I will put less out there. Ergo attention. And I know that if I try to make several kinds of things, I will put less out there. Ergo focus.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>Teams and organizations have focus and attention, too. Builders — developers, designers, etc. — focus on their slice of a problem. Teams focus on the problem as a whole. Organizations focus on solving problems that generate an impact on the metrics or goals they’re chasing.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Priorities are the attention of a team or organization. The negative space in those priorities reflects problems and impacts the group will say “no, thanks” to. That suggests a tidy way to think of personal and group attention; we should say “no, thanks” to attention-sinks which aren’t aligned with our personal goals and priorities. “No, thanks” to algorithmic feeds when our goal is to write, for example.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>(Time to land this thing.)</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Focus is a capacity to get stuff done. To choose a problem and put many hours and days into it. A sense of purpose, if that’s your thing.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Attention is deciding what the mind is thinking about. Attention can complement focus, or derail it. It’s how minutes turn to hours, in good ways (or bad).</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Shallow focus and attention see us bouncing from one idea to another. Often, without our intention to intervene (i.e., dopamine hits). The good focus and attention turns minutes into hours of engagement and days of interesting work into the weeks and months of a notable career or legacy of work.</p> <!-- /wp:paragraph --> Work in progress https://therealadam.com/2024/01/12/work-in-progress.html Fri, 12 Jan 2024 19:25:04 -0500 http://therealadam-ng.micro.blog/2024/01/12/work-in-progress.html <!-- wp:paragraph --> <p>I’ve had this sitting prominently in my Muse workspace for a while. Seems like a good time to deploy it now.</p> <!-- /wp:paragraph --> <!-- wp:image {"id":9067,"align":"center","linkDestination":"none"} --> <div class="wp-block-image"><figure class="aligncenter"><img src="https://cdn.uploads.micro.blog/151691/2024/b12f272aba.jpg" alt="What if it’s all work in progress? Just sharing/publishing the process as we go along?" class="wp-image-9067" /><figcaption>What if it’s all work in progress? Just sharing/publishing the process as we go along?</figcaption></figure></div> <!-- /wp:image --> <!-- wp:paragraph --> <p>Barry Hess, <a href="https://pika.bjhess.com/posts/you-re-a-blogger-not-an-essayist">You’re a Blogger, Not an Essayist</a>:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"> <p>I’m not going to look down on you for micro-posting on your blog, either. Heck, I might do it myself. I don’t prefer it, though. A blog isn’t Twitter. Just like I don’t think of a blog as something containing 2,000-word, heavily researched posts.</p><p>You don’t have to be an essayist. (Though you can be one if you want!) Don’t let those essayists discourage you from blogging.</p><p>Just write. Just blog.</p> </blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Cosign.</p> <!-- /wp:paragraph --> Journal for work/life/everything https://therealadam.com/2024/01/07/journal-for-worklifeeverything.html Sun, 07 Jan 2024 12:37:53 -0500 http://therealadam-ng.micro.blog/2024/01/07/journal-for-worklifeeverything.html <!-- wp:paragraph --> <p>Ray Grasso, <a href="https://www.grizzlebit.com/posts/2023/05-21-long-live-the-work-journal/">Long Live the Work Journal</a>:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"> <p>Keep a journal for work, champions.</p><p>It’s pretty easy to get started—just create a text file.</p><p>Throw in a new heading each day and write down whatever you did—a single line for each task is usually enough. I put the newer dates at the top so it’s less scrolling to get to the most recent content. Over time you end up with your own little private reverse-chronological blog-in-a-file.</p><p>Each day, dump in commands you’ve run; links to documents you’ve created, reviewed, or read; tasks you want to get done; or goals you want to achieve.</p><p>You’re building a little outboard brain where your work history is just a short grep away.</p> </blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Endorsed. Journals are the best PKM impact-to-effort ratio out there. I like <a href="https://dayoneapp.com">DayOne</a>, been using it for more than ten years and thousands of entries. But, anything works! Your notes app, a text file, a document in your preferred word processor. Anything you can search later and access anywhere is good!</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>The most important thing is to turn what’s in your head into “words on paper”. That’s when the magic happens!</p> <!-- /wp:paragraph --> Notes on strategy and execution https://therealadam.com/2023/12/06/notes-on-strategy.html Wed, 06 Dec 2023 09:57:12 -0500 http://therealadam-ng.micro.blog/2023/12/06/notes-on-strategy.html <!-- wp:paragraph --> <p>Will Larson, <a href="https://firstround.com/review/how-to-size-and-assess-teams-from-an-eng-lead-at-stripe-uber-and-digg/">How to Size and Assess Teams From an Eng Lead at Stripe, Uber and Digg</a>. This pull-quote lead me through some juicy lines of thinking: </p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>Inflection points are just sustained implementation of a very reasonable thing. Often, the role of the great leader is not to come up with a brilliant strategy, but to convince people to stay the course with a very basic strategy.</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Leaders <em>lead</em> folks in exercising a plan or series of plans (i.e. strategy). Basic strategies are almost certain to outperform complex strategies. Complex strategies tend to leak energy and effort at the seams between the basic/legible parts and all the edge cases and exceptions that generate complexity.</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:paragraph --> <p>“Sustained implementation” implies both quality of execution and compounding returns on effort. Sustaining any strategy is more likely to compound effort than frequently changing strategies. But, bear in mind that high probabilities don’t guarantee that an event will happen.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>At the team level, strategy is “why is this project/idea/work important enough to ignore all the other things we could be doing?”. The strategy generates the alignment which makes execution decisions easier. The alignment gives you a principle or goal to return to when things don’t go to plan. The strategy and alignment are guidelines helping teams pull together in the same direction, instead of zeroing out their effort by all pulling in different directions.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>No strategy is worse than no strategy. A lack of strategy is the worst thing, probably worse than having no plan. Any given present/actual strategy is likely to outperform no strategy. So definitely have a strategy, even if it is simple or your first try at having a strategy.</p> <!-- /wp:paragraph --> Organize for Discovery https://therealadam.com/2023/12/04/organize-for-discovery.html Mon, 04 Dec 2023 08:40:50 -0500 http://therealadam-ng.micro.blog/2023/12/04/organize-for-discovery.html <!-- wp:paragraph --> <p>S-tier programming skill: organize code and behavior such that others can discover and understand it out later <em>without</em> your presence/consultation.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>S-tier writing skill: organize a story or idea within a story such that the reader understands or builds upon it, makes it theirs.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>A-tier relationship skill: organize or set stuff down such that your partner can find it later, <em>without needing to ask you where it is</em>. (Riffing off <a href="http://wisdom.limo/">Merlin Mann</a> here, I think.)</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Ergo: organizing, and <em>empathizing</em>, are skills worth developing.</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:paragraph --> <p>It’s a bit of an affordance. Put the idea, code object, etc. where you’d <em>expect</em> to find it or <em>naturally</em> reach for it. Even better, put it where you think <em>someone else</em> would look for it first.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Tiago Forte, <a href="https://fortelabs.com/blog/how-to-take-smart-notes/">How to Take Smart Notes: 10 Principles to Revolutionize Your Note-Taking and Writing</a>:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p> In other words, instead of filing things away according to where they came from, you file them according to where they’re going. This is the essential difference between organizing like a librarian and organizing like a writer. </p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>All those productivity hacks <em>might</em> pay off, some day!</p> <!-- /wp:paragraph --> Sidestep process by sharing tangible progress https://therealadam.com/2023/12/02/sidestep-process-by.html Sat, 02 Dec 2023 14:55:26 -0500 http://therealadam-ng.micro.blog/2023/12/02/sidestep-process-by.html <p><a href="https://ruby.social/@nat/111348115101014452">Nat Bennett</a>:</p> <blockquote> Cannot overstate the value of regularly delivering working software. <p>My single most effective software dev habit is to start with a walking skeleton &ndash; a &ldquo;real&rdquo; if very stubbed out program that can be deployed on its real infrastructure, receive real calls, visited for real etc. &ndash; because of what this does for non-programming stakeholders.</p> <p>When they see a real working thing and then they see that thing get meaningful improvements they tend to chill <em>way</em> out and get much easier to work with.</p> <p>You can save a week of effort on process with a couple hours of sharing tangible progress.</p> </blockquote> <p>Related: you can save a week of planning with a couple hours of programming. You can save a week of programming with a couple hours of planning.</p> Notes on focus https://therealadam.com/2023/12/01/notes-on-focus.html Fri, 01 Dec 2023 09:46:18 -0500 http://therealadam-ng.micro.blog/2023/12/01/notes-on-focus.html <!-- wp:paragraph --> <p>I’ve tried a bunch of things, over the years, to find time and discipline to focus on working the tasks and projects that are meaningful to me. Mostly it boils down to actually doing the work and choosing the right kind of work. 🤷🏻‍♂️</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:heading --> <h2 class="wp-block-heading">There are two voices</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>“Focus on doing the most important thing so that you can get it done. Then, you can do the next most important thing, and so on”, says one. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>“Follow your interests. Turn your energy into some kind of progress. Even if it’s not aligned to the absolute most important thing, all the time”, says the other. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>They’re not-wrong!</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">The Important Thing</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>If there’s anything more useful than <a href="https://therealadam.com/2021/06/01/one-priority-is-like-wind-in-the-sails/">one clear priority</a>, it’s One Important Thing. Maybe they’re two sides of the same coin. Either way, if you know that Thing #1 is more significant than Things #2-10, you have an advantage.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Priority makes focus. Purpose makes focus. Aligning purpose with priority. That’s a winner.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">The big tent of principles</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>That said, it’s possible to pursue smaller things and stay in alignment with priority and purpose. The big-rock/one-important-thing isn’t an identity. They don’t have to represent your life goal. I recommend <em>against</em> trying to stay aligned with a big life goal, lest one miss all the lovely moments and achievements along the way. In other words, stop to say <a href="https://www.youtube.com/watch?v=sn6ru7FaQns">”well if this isn’t nice, I don’t know what is”</a>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>The big tent of principles means you can connect the dots from working on something for a short period of time, say a day or month, to what you’re trying to do with the months and years of your life or career.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Side note: your big principle needs a bit of an open-ended definition. If the principle you’re basing the years of your career is “make a push-button UI that is 5% better”, it’s difficult to fit side-quests into that tent. “Improve the low-hanging fruit in human-computer interface and swing for the fences a few times on drastically improving the state of the art” is a better big tent principle.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">Focus begat finish</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Focus is a means, not an end. The end is finishing. Not almost-done, basically done, or waiting on one little thing before it’s done. Finished means it’s out there, people are reading it or using it or thinking about it or benefitting from it in some way.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Focus makes the room in your life (and inside your head) to make the thing or polish it or package it or tell the people about it. But focus alone won’t finish it.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Finishing is dozens of little details that need doing, aren’t doing themselves, and may indeed look dissimilar to monk-like focus. It’s probably an entirely different topic. For the purposes of these notes, remember that it’s easier to finish if you have developed the discipline to focus.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">No</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p><a href="https://short.therealadam.com/2023/11/01/saying-no-is.html">Saying “no” is the first step</a>. Apps and trinkets and minimalism and meditation are not the key to generating focus.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>To paraphrase Prince: “Nothing Compares 2 No”. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Saying “no”:</p> <!-- /wp:paragraph --> <!-- wp:list --> <ul><!-- wp:list-item --> <li>Reduces your inbound volume of work</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Decreases coordination and collaboration multipliers that generate drag</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Aligns more of the tasks on your list with the thing I said “yes” to<br></li> <!-- /wp:list-item --></ul> <!-- /wp:list --> <!-- wp:paragraph --> <p>OTOH, many people feel bad vibes when they hear or say “no”. Say the literal word with care.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>Don’t get so wrapped up in focusing and how other people do it and your ideal schedule and preparing to do the work that you never get around to doing the work.</p> <!-- /wp:paragraph --> Zawinski's law, updated https://therealadam.com/2023/11/25/zawinskis-law-updated.html Sat, 25 Nov 2023 11:32:04 -0500 http://therealadam-ng.micro.blog/2023/11/25/zawinskis-law-updated.html <p>Every program attempts to expand until it can</p> <ul> <li>read email (the original)</li> <li>invite a friend</li> <li>check off tasks in a list</li> <li>record consent to receiving cookies or storing data in the United States (GDPR)</li> <li>store an audit trail (SOC2)</li> </ul> My summer at 100 hertz https://therealadam.com/2023/11/09/my-summer-at.html Thu, 09 Nov 2023 08:32:23 -0500 http://therealadam-ng.micro.blog/2023/11/09/my-summer-at.html <!-- wp:paragraph --> <p>Is there <a href="https://ruby.social/@therealadam/110967664496416049">a lost art to writing code without a text editor</a>, or even a (passable) computer? It sounds romantic, I’ve done it before, I tried it again, and…it was not that great. 🤷🏻‍♂️</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:heading --> <h2 class="wp-block-heading">0. An archaic summer, even by the standards of the late 1990s</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>The summer of 2002 was my last semester interning at Texas Instruments. I was tasked with writing tests verifying the next iteration of the flagship DSP for the company, the ‘C6414<sup><a id="ffn1" href="#fn1" class="footnote">1</a></sup>. This particular chip did not yet exist; I was doing pre-silicon verification. </p> <!-- /wp:paragraph --> <!-- wp:image {"id":8586,"sizeSlug":"medium","linkDestination":"none","align":"center"} --> <figure class="wp-block-image aligncenter size-medium"><img src="https://cdn.uploads.micro.blog/151691/2024/3983cb4e79.jpg" alt="“A baroque painting of a monk programming an old computer surrounded by stacks of paper, broken punch cards, and many discarded cups of coffee” via DALL-E" class="wp-image-8586" /><figcaption class="wp-element-caption">“A baroque painting of a monk programming an old computer surrounded by stacks of paper, broken punch cards, and many discarded cups of coffee” via DALL-E</figcaption></figure> <!-- /wp:image --> <!-- wp:paragraph --> <p>At the time, that meant I used the compiler toolchain for its ‘C64xx predecessors to build C programs and verify them on a development board (again, with one of the chip’s predecessors) for correctness. Then, I shipped the same compiled code off to a cluster of Sun machines<sup><a id="ffn2" href="#fn2" class="footnote">2</a></sup>and ran the program on a gate-level <em>simulation</em> of the new chip based on the hardware definition language (VHDL, I think) of the as-yet physically existent chip<sup><a id="ffn3" href="#fn3" class="footnote">3</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>The output of this execution was a rather large output file (hundreds of megabytes, IIRC) that captured the voltage levels through many<sup><a id="ffn4" href="#fn4" class="footnote">4</a></sup> of the wires on the chip<sup><a id="ffn5" href="#fn5" class="footnote">5</a></sup>. Armed with digital analyzer software (read: it could show me if a wire were high or low voltage i.e., if its value was 0 or 1 in binary), and someone telling me how to group together the wires that represented the main registers on the chip, I could step through the state of my program by examining the register values one cycle at a time.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Beyond the toolchain and workflow, which is now considered archaic and generally received by younger colleagues as an “in the snow, uphill, both ways” kind of story, I faced another complication. As you can imagine if you work out what “running a gate-level simulation of a late-90’s era computer chip on late-90’s era Sun computers” implies, from first principles, you’ll realize that at a useful level of fidelity this kind of computation is phenomenally expensive.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>In fact, I had plenty of time to contemplate this and one day in fact did so. Programs that took about a minute to compile, load into a development board, and execute ran over the course of an <em>hour</em> on the simulator. Handily, the simulator output included wall-clock runtime <em>and</em> number of cycles to execute. And so I divided one by the other and came to a rough estimate that the simulator ran programs at less than 100hz; the final silicon’s clock speed was expected to hit 6-700MHz if I recall correctly.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I was not very productive that summer<sup><a id="ffn6" href="#fn6" class="footnote">6</a></sup>! But it does return me to the point of this essay: the time when it was better to think through a program than write it and see what the computer thought of it was not <em>that</em> great.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">1. Coding “offline” sounds romantic, was not that great</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>I like to imagine software development in mythological halls like Bell Labs and Xerox PARC worked like this: </p> <!-- /wp:paragraph --> <!-- wp:list --> <ul><!-- wp:list-item --> <li>You wrote memos on a typewriter, scribbled models and data structures in notebooks, or worked out an idea on a chalkboard. </li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Once you worked out that your idea was good, with colleagues over coffee or in your head, you started writing it out in what we’d call, today, a low-level language like C or assembly or <em>gasp</em> machine code.</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>If you go far back enough, you turn a <em>literally handwritten</em> program into a typed-in program on a very low-capacity disk or a stack of punch cards.</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>By means that had disappeared way earlier than I started programming, you convey that disk or stack of cards to an operator, who mediated access to an <em>actual computer</em> and eventually gave you back the results of running your program.<br></li> <!-- /wp:list-item --></ul> <!-- /wp:list --> <!-- wp:paragraph --> <p>The further you go back in computing history, the more this is how the ideas must have happened. Even in the boring places and non-hallowed halls.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I missed the transition point by about a decade,<sup><a id="ffn7" href="#fn7" class="footnote">7</a></sup> as I was starting to write software in the late nineties. Computers were fast enough to edit, compile, and run programs such that you could think about programming <em>nearly</em> interactively. The computational surplus reached the point that you could interact with a REPL, shell, or compiler fast enough to keep context in one’s head without distraction from “compiler’s running, time for coffee”<sup><a id="ffn8" href="#fn8" class="footnote">8</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">2a. <a href="https://en.wikipedia.org/wiki/Snowclone">Snow-cloning</a> the idea to modern times</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>In an era of video meetings and team chats and real-time docs, this older way of working sounds somewhat relaxing. 🤷🏻‍♂️ Probably I’m a little romantic about an era I didn’t live through, and it was a bit miserable. Shuffled or damaged punch cards, failed batch jobs, etc.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I like starting projects away from a computer, in a notebook or whiteboard. Draw all the ideas out, sketch some pseudocode. Expand on ideas, draw connections, scratch things out, make annotations, draw pictures. So much of that is nigh impossible in a text editor. Linear text areas and rectangular canvases, no matter how infinite, don’t allow for it.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>But, there’s something about using only your wits <em>and hands</em> to wrestle with a problem. A different kind of scrutiny you get from <em>writing</em> down a solution, examining it. Scratching a mistake out, scribbling a corner case to the side. Noticing something I’ve glazed over, physically adjusting your body to center it in your field-of-vision, and thinking more deeply about. I end up wondering if I should do more <em>offline</em> coding.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">2b. Ways of programming “offline” that weren’t that great in 2023</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Sketching out programs/diagrams on an iPad was not as good as I’d hoped. Applications that hint at the hardware’s paper- and whiteboard-like promise exist. But it’s still a potential future, not a current reality. The screen is too small, drawing lag exists (in software, at least), and the tactility isn’t quite right.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Writing out programs, long-hand, on paper or on a tablet is not great. I tried writing out Ruby to a high-level of fidelity<sup><a id="ffn9" href="#fn9" class="footnote">9</a></sup>. Despite Ruby’s potential for concision, it was still like drinking a milkshake through a tiny straw. It felt my brain could think faster than I could jot code down and it made me a little dizzy to boot.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Writing pseudocode was a little more promising. Again, stylus and tablet isn’t the best, but it’s fine in a pinch. By hand on paper/notebooks/index cards is okay if you don’t mind scratching things out and generally making a mess<sup><a id="ffn10" href="#fn10" class="footnote">10</a></sup>. Writing out pseudocode in digital notes, e.g. in fenced code blocks within a Markdown document, is an okay to get a short code out and stay in a “thinking” mindset rather than “programming”.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">3. Avoid the computer until it’s time to compute some things</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>To an absurd reduction, we use programming to turn billions of arithmetic operations into a semblance of thinking in the form of designs, documents, source files, presentations, diagrams, etc. But, rarely is the computer the best way of arriving at that thinking. More often, it’s better to step <em>away</em> from the computer and scribble or draw or brainstorm.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>(Aside: the pop culture of workspaces and workflows and YouTube personalities and personal knowledge management and “I will turn you into a productivity machine!” courses widely misses on the mark on <em>actually generating good ideas</em> and how poorly it fits into a highly engaged social media post, image, or video.)</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">Find a reason to step away from the computer</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Next time you’re getting started on a project, try grabbing a blank whiteboard/stack of index cards/sheet of paper. Write out the problem and start scribbling out ideas, factors to consider, ways you may have solved it before.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Even better: next time you find yourself stuck, do the same.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Better still: next time you find a gnarly problem <em>inside a problem you previously thought you were on your way to solving</em>, grab that blank canvas, step away from the computer, and dump your mental state onto it. Then, start investigating how to reduce the gnarly problem to a manageable one.</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol><!-- wp:list-item --> <li>The <a href="https://en.wikipedia.org/wiki/Texas_Instruments_TMS320#C6000_series">TMS320C64x</a> chips were unique in that they resembled a GPU more than a CPU. They had multiple instruction pipelines which the compiler or application developer had to try to get the most out of. It didn’t work out in terms of popularity, but it was great fun to think about. <a href="#ffn1">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>…in a vaguely-named and ambiguously-located datacenter somewhere. Cloud computing! <a href="#ffn2">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Are we having fun yet? In retrospect, yes. <a href="#ffn3">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>I don’t think it was all of the wires in the chip, as even at the time that would have been hundreds of millions of datapoints per cycle. <a href="#ffn4">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Again, simulated and not yet extant 🤯 <a href="#ffn5">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Excruciatingly so, by my current standards. <a href="#ffn6">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Modulo writing programs to run in gate-level simulations. <a href="#ffn7">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>At least, for smaller programs in some languages. <a href="#ffn8">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>i.e. few omitted syntactic idioms <a href="#ffn9">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Arguably, the point of working in physical forms is to make a mess, IMO. <a href="#ffn10">↩</a></li> <!-- /wp:list-item --></ol> <!-- /wp:list --> Tooling has improved for ambitious software developers https://therealadam.com/2023/11/04/tooling-has-improved.html Sat, 04 Nov 2023 12:37:57 -0500 http://therealadam-ng.micro.blog/2023/11/04/tooling-has-improved.html <!-- wp:paragraph --> <p>Tools for working on software in the large<sup><a class="footnote" href="#fn1" id="ffn1">1</a></sup> <em>have</em> improved a lot over since <a href="//therealadam.com/2013/06/28/tools-for-software-in-the-large/">I last considered them ten years ago</a>.</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:image {"lightbox":{"enabled":true},"id":8563,"sizeSlug":"medium","linkDestination":"none","align":"right"} --> <figure class="wp-block-image alignright size-medium"><img src="https://cdn.uploads.micro.blog/151691/2024/bbdb1cbc48.jpg" alt="A sloth cutting an impossible Gordian Knot" class="wp-image-8563" /></figure> <!-- /wp:image --> <!-- wp:paragraph --> <p><a href="https://www.jetbrains.com">IDEs</a> are better, faster, and have excellent navigation/search features. Full-text search is now somewhat syntax aware and able to index and quickly query large codebases. Tools like <a href="https://sourcegraph.com/search">Sourcegraph</a> exist on the high end and <a href="https://github.com/BurntSushi/ripgrep">ripgrep</a> on the low end.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="https://copilot.github.com">AI assistants</a>/<a href="https://sourcegraph.com/cody/chat">copilots</a> can wear the hat of “better autocomplete” today and may wear the “help me understand this code” or “help me write a good PR/commit message” hat later. I’m skeptical about the wisdom of handing off the latter to a program, but we’ll see how it goes.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Applications have made <a href="https://www.elastic.co/kibana"><code>tail -f</code></a> a better and more legible experience. Somehow, exception trackers and performance monitoring tools don’t seem to have evolved much over the past ten years. This is perhaps a result of market/product consolidation more than an indicator that the category is tapped out.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>It’s hard for me to say how much language is creating leverage for working on software in the large. Ruby and JavaScript were prominent in my daily work ten years ago and are still prominent today. Both have evolved gradual type systems that <em>might</em> make it easier to hold a large program in an individual’s head productively. Both gradual type systems are going through the “trough of disillusionment” phase of the technology hype cycle. I’m cautiously optimistic that <em>some</em> kind of static analysis, whether it’s linters or type checkers, will make writing Ruby and JavaScript less haphazard.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Notably, deploying software doesn’t seem to have improved much at all for the individual developer. Heroku, in its prime, is still the golden standard. Perversely, Heroku sometimes fails to meet this mark. The options free of lock-in for such a service are limited-to-nascent<sup><a id="ffn2" href="#fn2" class="footnote">2</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>In short, tooling <em>has</em> made it easier for fewer people to maintain and enhance larger software. With luck, the options for doing so without paying a monthly tithe to dozens of vendors will improve over the next decade!</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol><!-- wp:list-item --> <li>We would say “at scale”, now, shamelessly. <a href="#ffn1">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Notably, I have not used Kubernetes but the anecdotal data does not lead me to think I’m missing out on much. <a href="#ffn2">↩</a></li> <!-- /wp:list-item --></ol> <!-- /wp:list --> <!-- wp:image --> <figure class="wp-block-image"><img alt="" /></figure> <!-- /wp:image --> <!-- wp:image --> <figure class="wp-block-image"><img alt="" /></figure> <!-- /wp:image --> Top of Mind No. 6 https://therealadam.com/2023/10/26/top-of-mind.html Thu, 26 Oct 2023 18:50:50 -0500 http://therealadam-ng.micro.blog/2023/10/26/top-of-mind.html <!-- wp:paragraph --> <p>I’ve been thinking a lot about setting expectations and goals. I have an idea about setting expectations on how we practice software development in teams and four pillars thereof. They are, broadly: alignment/consensus, accountability/responsibility, transparency/visibility, execution. These seem like four useful touch-points for coaching individuals. More concretely: help teammates drive scope (down, mostly) by setting time expectations and iterating from there.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>The other angle on my mind is using subjective measurements to evaluate changes to human systems. That is, don’t ask a person or team to change how they work and immediately hit a numeric benchmark. Instead, ask them how the change is going and rate it from 1-5, worst to best. If the desired outcome is “know what the team is up to on most days”, ask them to write a status report, but<em> don’t specify a number to hit</em>. Instead, use 1:1s to reflect on how the change is impacting their work, look for advantages or shortcomings to the change in process, and decide how to correct course from there.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Updates: <a href="https://therealadam.com/2023/04/26/top-of-mind-no-5/">LLMs</a> are still promising, but not as much for leadership work. <a href="https://therealadam.com/2023/01/08/top-of-mind-no-3/">Working incrementally</a>, still underrated.</p> <!-- /wp:paragraph --> Inside you, there are two or more brains https://therealadam.com/2023/10/03/inside-you-there.html Tue, 03 Oct 2023 07:36:07 -0500 http://therealadam-ng.micro.blog/2023/10/03/inside-you-there.html <!-- wp:paragraph --> <p>David Hoang, <a href="https://www.proofofconcept.pub/p/galaxy-brain-gravity-brain-and-ecosystem">Galaxy Brain, Gravity Brain, and Ecosystem Brain</a>:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"> <p>The Galaxy Brain thinkers are in 3023 while we're in 2023. They relentlessly pursue the questions, “What if?” Imagination and wonder fuel the possibilities of what the world could be.</p><p>…</p><p>I believe every strong team requires skeptics and realists. Introducing, the Gravity Brain. Don't get it twisted in thinking this is negative—it's a huge positive. If you say "jump," to a Gravity Brain person, they won't say, "how high?" Instead, they say, "Why are we jumping? Have we considered climbing a ladder? Based on the average vertical jump of humans on Earth, this isn't worth our time." Ambition and vision don’t matter if you don’t make progress towards them.</p><p>…</p><p>Ecosystem Brains think a lot of forces of nature and behaviors. They are usually architects and world builders. When they join a new company, they do an archeological dig to understand the history of society, language, and other rituals.</p> </blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>I’m a natural gravity brain and occasional ecosystem brain. I aspire to galaxy brain, but often get there by of proposing a joke/bad idea to clear my mind and get to the good ideas.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Which one are you?</p> <!-- /wp:paragraph --> I’m not your cool uncle https://therealadam.com/2023/09/29/im-not-your.html Fri, 29 Sep 2023 10:00:00 -0500 http://therealadam-ng.micro.blog/2023/09/29/im-not-your.html <!-- wp:paragraph --> <p>I find that playing the “I’m the leader, this is the decision, go forth and do it” card is not fun and almost always wrought with unintended consequences. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>A notable exception is teams that fall back to working in their own specialized lanes<sup><a id="ffn1" href="#fn1" class="footnote">1</a></sup> and throwing things over the wall. Really, the issue is throwing things over the wall, working in your lane isn’t inherently harmful<sup><a id="ffn2" href="#fn2" class="footnote">2</a></sup>. Playing the leader card and insisting folks work across specialization in their lane or closely with a teammate whose skills complement their own has fixed more things than it complicated. More specifically, the complications were the kind of difficulties a high-functioning team would face anyway, i.e., “high-quality problems”.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Now I wonder what other scenarios justify playing the power dynamic or “I’m not your cool uncle” card to escape an unproductive local maximum.</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol> <li id="fn1">e.g. back-end, front-end, mobile, etc. <a href="#ffn1">&#8617;</a></li> <li id="fn2">Assuming you’re adept at communicating progress and avoiding rabbit holes <a href="#ffn2">&#8617;</a></li> </ol><!-- /wp:list --> I got better at estimating projects with intentional practice https://therealadam.com/2023/08/23/i-got-better.html Wed, 23 Aug 2023 10:19:00 -0500 http://therealadam-ng.micro.blog/2023/08/23/i-got-better.html <!-- wp:paragraph --> <p>I like the idea of practicing<sup><a class="footnote" href="#fn1" id="ffn1">1</a></sup>, in the musical or athletic sense, at professional skills to rapidly improve my performance and reduce my error rate. When I was a music major<sup><a class="footnote" href="#fn2" id="ffn2">2</a></sup>, I spent hours practicing ahead of rehearsals, lessons, and performance. Until recently, I was unable to conceive of how I might do the same for leadership.</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:paragraph --> <p>Estimating the time and effort of a software project is error-prone, even when one considers how error-prone the activity is<sup><a id="ffn3" href="#fn3" class="footnote">3</a></sup>. Reasoning about a clearly defined functional scope is a classic "unreasonably difficult even when accounting for how difficult it is" problem. Everyone wants to know how many days a project will take, but few try to understand the myriad, interconnected ways the number of days can grow surprisingly large. (More on that later.)</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>What I figured out was, practicing at estimates is as “repeatable and atomic” (see below) as scales are for music. The material one needs as <em>input</em> to <em>practice</em> at estimating is available on the marketing websites of the numerous startups, technology, and software product companies out in the world. Any number of feature or pricing pages are sufficiently interesting to ask myself, "how would I start building the functionality or feature advertised here?” Then, do a 15-60 minute exercise of breaking it down, thinking about scenarios, discovering risks and dependencies, laying out a plan, and even thinking out the high-level technical design.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>This is even easier if I start from products I already know well from daily use. Most developers know GitHub's features pretty well. Starting from their <a href="https://github.com/features/code-review">Pull Requests</a> marketing page is a familiar starting point. This lets one work on the mechanics of thinking holistically about the functional scope. Then, I can get down to details about how to build a (hypothetical) wholly new capability or feature into a (hypothetical) product.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>This insight allowed me to move past a "I guess estimating is a struggle bus that could limit my growth" mindset. Now I feel like "I can get as good as I want at this by doing the reps", much like practicing at music or free throws<sup><a id="ffn4" href="#fn4" class="footnote">4</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">The recipe for practicing at estimating</h2> <!-- /wp:heading --> <!-- wp:list {"ordered":true} --> <ol><!-- wp:list-item --> <li>Think up some kind of project I might do in the future <em>or</em></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Find a software product page on the web and use that as an imaginary requirements document<sup><a class="footnote" href="#fn5" id="ffn5">5</a></sup></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Spend 20 minutes going through the motions of how I like to estimate projects (break down scopes, think through happy/edge cases)</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Spend 10 minutes breaking down the work, identifying the risks, etc. – use an outline, sticky notes, a whiteboard, whatever works</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Reflect on what I came up with, how I’d tackle it differently next time</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Rinse and repeat. Take a different approach to the same project. Estimate a different project. Try the exercise with a few of my favorite colleagues/collaborators and see how it comes out differently.<br></li> <!-- /wp:list-item --></ol> <!-- /wp:list --> <!-- wp:paragraph --> <p>The most important thing to keep in mind: formality is not required when practicing. It’s about low-stakes and fast iteration.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">Practice makes estimating less imperfect</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Practice can make software estimates more useful. Not more prescient, necessarily. But definitely, I can produce better outcomes by practicing <em>around</em> the process of planning and estimating software.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Practice works because it is <em>atomic</em> and <em>repeatable</em>. I’m using database terminology a little oddly here.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Atomic, in the sense of database transactions, means I can "return to square one" at my discretion without imposing on anyone else. To carry the metaphor, practice sessions are more atomic than rehearsals or performances. I can throw away the results of my estimation practice session without ruining anyone’s project/roadmap/schedule.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Repeatable means I can estimate similar projects over and over again until I’m satisfied I’ve reached the level of skill mastery necessary. To carry the metaphor, I practice a passage or shoot free throws until I’m confident I can perform it correctly the vast majority of the time.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>The great thing about practicing at estimating <em>fake</em> projects is it <em>will</em> make me better at estimating <em>real</em> projects. Like they say: practice makes perfect.<sup><a id="ffn6" href="#fn6" class="footnote">6</a></sup></p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Equally great, I’m not accountable for fake projects. I don’t have to worry about breaking things down incoherently or overlooking a key bit of functionality. Hopefully, I find it upon review and reach a state of coherent, complete estimates. But the risk of one individual practice estimate ruining someone’s working week is non-existent.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>The web is rife with practice material. Grab a short product description, pitch, etc. Marketing and feature pages on a favorite app’s website work great. Previous projects or imagined software work too. Maybe jot down prior assumptions, e.g., I’ve already built authentication or a mobile app or payments. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>With a “practice” functional scope and some constraints in mind, it’s time to start practicing. Ask where the seams are, how to split things up, what are the risks, could this part be omitted, do we have prior art for this, etc. Make a list or board or mind-map or whatever. Organize it by concept or how I would tackle the project. Look for gaps in how I would explain the plan or pitch it to my team. These all work well for me, but you may estimate differently. That’s fine, and the point! Try different approaches and see what is effective, efficient, and generative.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I can practice at taking the <em>idea</em> for a software project, feature, enhancement, etc. and turning it into a <em>plan</em> for how to build it. When I practice at this, I improve at finding risks, breaking down problems, writing down ideas, coming up with novel approaches, considering how to apply technology to solve problems, deciding which parts of the problem to focus on, etc. All of this yields better plans for building the project, which leads to better execution. Somewhere in the middle of those plans come estimation, which I’m getting more reps at, so hopefully I’m getting better at it.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Planning and estimating software forces me to turn over stones I may otherwise overlook. It gives me an opportunity to tackle kinds of software I may not otherwise build, or even learn how to build software I may not otherwise build at a high level. For example, I have no idea how to build a game, but practicing estimating a game project sends me down a discovery process that will certainly teach me something<sup><a id="ffn7" href="#fn7" class="footnote">7</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Rinse and repeat. Do this over and over until you are as good as you want to be at estimating software. Maybe do this with your team. It’s a little harder, but teaching everyone to do it will raise all ships.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>A crucial element of practice is immediate feedback; “how’d I do?”. Practicing at estimation gives me one kind of immediate feedback in the form of revealing more of the puzzle as I go. On the other hand, I (still) don’t get the crucial feedback that makes software estimation so difficult in the first place — measurement of accuracy and precision. Software estimation is hard because a lot of the factors that go into how long building software takes are invisible and unpredictable.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">Reflections on practicing at estimating software projects</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>So, I found it possible to quickly gain experience at the “guessing at numbers” part of estimation. This bit is amenable to iteration – I can work through a stack of software project ideas, call upon my experience, and guess at what the tasks are and how long they might take. I did several of these over the course of a couple of weeks. I found it effective enough, I no longer felt like I was “working from behind” when called upon to estimate how the effort and time for a project at work.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Lately, I’m using <a href="https://jacobian.org/2021/may/25/my-estimation-technique/">Jacob Kaplan-Moss’ approach to estimation</a>. List out the tasks, score them by effort and risk/variance. Add up the numbers and get a sum. Decide that number is fine, or investigate the critical tasks (large effort or high variance) to get a better idea how to break them into less risky tasks.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="https://therealadam.com/2023/05/07/improving-when-you-cant-rinse-and-repeat/">Practice makes challenging activities something you can rinse and repeat.</a></p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Key caution: this kind of iterative improvement is not the same kind of activity as Platonic practice activities like shooting free throws or methodically learning a piece of music. To use a coarse analogy, practicing at estimating software is like practicing free throws, but I can’t see or hear the ball after I release it. There’s no feedback loop, I can’t know if the shot went in, bounced off the backboard, or missed entirely<sup><a id="ffn8" href="#fn8" class="footnote">8</a></sup>. In other words, everything that happens after the initial estimate is the wicked problem that defies both practice and systemic, industry-wide improvement.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>On the other hand, this form of the activity <em>does</em> look like basketball or musical practice because it’s in a safe bubble. My practice at estimating doesn’t put real projects with real people working them at risk. If I try something unusual, no one has to put up with it later. This affords trying multiple approaches to the same problem and experimentation. I find this is the key insight – for <em>some</em> non-coding leadership/management activities, it’s possible to practice at some <em>part</em> of the activity and gain confidence in running that part. Possibly, not the whole thing, but at least a slice of the process is improvable without relying on live people and live work for non-methodical iteration and experimentation.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">In short…</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Estimating software projects is a relatively easy, learnable planning/brainstorming creative task coupled with wicked expectations of the ability to predict the future in terms of outcomes, unknowns, risks, and things that just don’t go my way. I can practice at the first part.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>No software estimate is perfect. The world is full of surprises<sup><a id="ffn9" href="#fn9" class="footnote">9</a></sup>. Focus on the easy part, decomposition and discovery. Tackle all the execution stuff downstream separately.</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol><!-- wp:list-item --> <li>This thinking was inspired by an Andy Matuschak Patreon post on <a href="https://www.patreon.com/posts/implicit-sight-64561750">practicing at sight reading on piano</a> <a href="#ffn1">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Double bass performance, orchestral, first year. I switched because it was far easier for me to spend six hours in front of a computer than in a practice room. Caveat raptor. <a href="#ffn2">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Even multiplying estimates by two is considered a pretty-okay practice, but is often insufficient for a good, let alone reasonable, answer. <a href="#ffn3">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Which I have done very little practice at and, accordingly, am not very good at. <a href="#ffn4">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Whether a marketing page is a better product spec than what you receive for normal projects in your org is a matter of variance. <a href="#ffn5">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Caveat: this isn’t intense concert pianist/pro athlete level practice. If you do end up producing &gt;99% <em>perfect</em> estimates, please all of us know your secret! <a href="#ffn6">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>It may prove that what I learn is how little I know about actually building game software! <a href="#ffn7">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>It’s perhaps not <em>that</em> bad. Perhaps it’s more like the difference between shooting free throws and scoring field goals in a basketball game. I have no hope at the latter if I can’t perform the former at a high level. <a href="#ffn8">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Sorry ‘bout that! <a href="#ffn9">↩</a></li> <!-- /wp:list-item --></ol> <!-- /wp:list --> When finished isn’t done https://therealadam.com/2023/07/08/when-finished-isnt.html Sat, 08 Jul 2023 14:01:54 -0500 http://therealadam-ng.micro.blog/2023/07/08/when-finished-isnt.html <p>The work is done, the post is published, the code has shipped, the boxes are all checked.</p> <p>And yet, it remains in my head. The bit of code I’d like to revisit, an edge I couldn’t round off, a paragraph that doesn’t fit like I want it to, a workflow we didn’t improve upon, a conversation about trade-offs that went sideways…</p> <p>The work is more than the work, more than an end. It’s emotions and memories. A new way of thinking, experience and wisdom newly integrated with what I’ve done before. The start of something new, with this finished work as the prologue that sets the stage for the next story.</p> <hr /> <blockquote> Previous tasks continue to consume attention even after switching. This is especially true for anything that causes strong emotions. I find it hard to concentrate if I&#8217;m opening (Slack) every 15 minutes and every time seeing that thread where someone is arguing with me and they&#8217;re totally wrong and how can they even believe what they&#8217;re saying and what was I doing again? — Jamie Brandon, <a href="https://www.scattered-thoughts.net/writing/moving-faster/">Moving Faster</a> </blockquote> <ol> <li>Acknowledging and managing emotions is a productivity/go-fast hack</li> <li>Really, don’t dwell on people being wrong. You can’t control it. Just keep going.</li> <li>Absent people and emotions, completing a task doesn’t mean it’s out of our heads. Account for that in planning the day or projects.</li> </ol> <hr /> <p>Often, things are only getting started when I check that box.</p> <p>We call it perfectionism when we hold the work back to make one last tweak, another small improvement. Perfectionism is pouring myself into one checkbox for weeks or months at the expense of all the other things I want to do. It’s not so much seeking perfect, but an inability to let go and get started in earnest.</p> <p>To the contrary, every day I’m more convinced that perfect emerges from checking that first box. Putting the work out there, starting the next checkbox (of several dozen), accumulating and shaping something more perfect.</p> <hr /> <p>Everything finished is the start of something else.</p> Notes on narrative for engineering leaders https://therealadam.com/2023/06/09/notes-on-narrative.html Fri, 09 Jun 2023 09:34:37 -0500 http://therealadam-ng.micro.blog/2023/06/09/notes-on-narrative.html <!-- wp:paragraph --> <p>Alex Reeve, <a href="https://www.reeve.blog/articles/product-management-principles">22 Principles for Great Product Managers</a>:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"> <p>You have to own the narrative. When there’s a narrative vacuum, people will “creatively” fill in the blanks themselves—and you might not like it. Losing control of the narrative can be incredibly disruptive to your team’s ability to deliver. </p><p>– (Alex Reeve, 22 Principles for Great Product Managers)</p> </blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Same goes for plans &amp; projects. If you don’t have a plan, someone else will. You may not like their plan.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Telling the story of a goal/project/initiative isn’t manipulation<sup><a id="ffn1" href="#fn1" class="footnote">1</a></sup>, it’s setting the vision.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>All narratives compress out important details and trade-offs as an expense of clarity and noteworthiness (i.e. an un-memorable narrative is not a particularly good narrative).</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Narrative is is a fantastic skill to have as an engineering leader. The more you can convey your ideas, goals, projects, and initiatives as a narrative, the more you can get people on the same page. It’s also a <em>fun</em> skill to acquire. It’s all around us in culture. It’s one of the few things where you can improve in your profession by paying attention to how movies, television, or fiction are structured. (Highly recommended: <a href="https://www.youtube.com/user/everyframeapainting">Every Frame a Painting</a>)</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol> <li id="fn1">Bad-faith narrative construction exists, please don’t act in bad faith. <a href="#ffn1">&#8617;</a></li> </ol><!-- /wp:list --> Three meditations on wins https://therealadam.com/2023/05/10/three-meditations-on.html Wed, 10 May 2023 08:18:07 -0500 http://therealadam-ng.micro.blog/2023/05/10/three-meditations-on.html <!-- wp:paragraph --> <p>Leaders (and managers) are successful to the extent that their teams and peers notch wins. Former Intel CEO Andy Grove calls this the “output” of a manager, and wrote the book on it<sup><a id="ffn1" href="#fn1" class="footnote">1</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Easier said than done! What <em>is</em> it for a lead to create wins (aka output)?</p> <!-- /wp:paragraph --> <!-- wp:heading {"level":2} --> <h2>1. Choose games that are winnable</h2> <!-- /wp:heading --> <!-- wp:quote --> <blockquote class="wp-block-quote"> <p>Only play games you can win.</p><ul> <li>Warren Buffett or the Beastie Boys (probably)</li> </ul> </blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>Our time is highly constrained. Saying “no” is an underrated and under-discussed leadership skill. Saying no on behalf of my team, peers, or organization, I’ve <em>created focus</em> on a (potentially) winning effort.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Some great reasons not to play a game<sup><a id="ffn2" href="#fn2" class="footnote">2</a></sup>:</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":false} --> <ul> <li>The opportunity, as presented, is not yet small enough in scope to notch a win in the time available to work the opportunity. Find a smaller win in the presented opportunity that will give you a hint as to the real potential of the bigger project.</li> <li>The calendar time necessary to run the project or ongoing effort to completion (notch the win) is dominated by process, coordination, and bureaucracy. That is, try again when there is a way to realize the impact with less overhead/organizational drag.</li> <li>There’s a gap between the desired/supposed outcome and the project(s) that could realize that outcome. The immediate win is to research/brainstorm/write your way to connecting outcome with action(s).<br></li> </ul> <!-- /wp:list --> <!-- wp:paragraph --> <p>Pro-tip: provide feedback on not-yet-winnable games in the form of “I don’t <em>yet</em> know <em>how</em> to win that game, let’s start by fixing that”. No one likes pessimism, cynicism, or shutting down all the project ideas. That said, it’s fair to provide constructive feedback that will improve the idea or bring it closer to action/win-ability.</p> <!-- /wp:paragraph --> <!-- wp:heading {"level":2} --> <h2>2. What counts as a win?</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Once something is out in the world, it’s a win. Publishing an article, releasing a feature to your customers – those are definitely wins.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Getting something out of your team or head, that’s a sort of win. Rolling out a new process or tool is some kind of win. Worth sharing! But it doesn’t directly improve what customers are paying for, so focusing entirely on this kind of win doesn’t count.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><strong>Wins have to change your company’s world in some tangible way.</strong> The change need not be objective or quantitative; a subjective/qualitative survey is enough!</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>If what you’re recognizing as little wins doesn’t yield bigger wins, then it’s time to reflect on what you’re encouraging.</p> <!-- /wp:paragraph --> <!-- wp:heading {"level":2} --> <h2>3. Avoid short-term thinking, build momentum with little wins, build big wins</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>A culture of thoughtfulness about outcomes, potential, impact, and trade-offs makes 1 and 2 happen.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Loud voices may try to convince you that un-winnable games have lots of promise. Urgent voices might tell you counting something as a win and moving on is the right move.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Moving the goal-line closer, so you can recognize a win, is expedient and productive, occasionally. Other times, moving the goal-line is self-defeating.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>It is often difficult to stick with long-term projects. There is so much other stuff to work on, all of it intriguing. Other folks in the organization will want to know how much of “all of it” we could produce in the current and next quarters.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>The challenge is to stay the course, believe in the purpose, and stack all those little wins, every week, until the big win takes shape. Tell your colleagues about the big win’s emergence…</p> <!-- /wp:paragraph --> <!-- wp:heading {"level":2} --> <h2>In short</h2> <!-- /wp:heading --> <!-- wp:list {"ordered":true} --> <ol> <li>Choosing what to work on (or not) is of crucial importance. </li> <li>Recognizing the right kinds of progress makes it easier to stack little wins on the way to big wins.</li> <li>Exercising the discipline to stack meaningful progress (wins) is the engine for generating big outcomes.</li> </ol> <!-- /wp:list --> <!-- wp:list {"ordered":true} --> <ol> <li id="fn1"><a href="https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884">High Output Management</a>. See also, <a href="https://about.gitlab.com/handbook/leadership/high-output-management/">GitLab’s notes on the same</a>. <a href="#ffn1">&#8617;</a></li> <li id="fn2">Would a whole post on indicators of losing/un-winnable games come off as <em>too</em> cynical? <a href="#ffn2">&#8617;</a></li> </ol><!-- /wp:list --> Improving when you can’t rinse and repeat https://therealadam.com/2023/05/07/improving-when-you.html Sun, 07 May 2023 13:38:46 -0500 http://therealadam-ng.micro.blog/2023/05/07/improving-when-you.html <!-- wp:paragraph --> <p>You can’t practice at some things. Putting the cat back in the bag or the toothpaste back in the tube. The undoable, the things that you can’t unsay. The measure twice cut once stuff. </p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>In those cases, a little preparation and reflection go a long way. I think about what's important to say or verify before I say/do the undoable. Afterward, I reflect on how things went, if I learned anything surprising, and how I can improve the process next time. Ideally, I write all this down, so I don't lose any wisdom for the next time I'm faced with a similar challenge.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I'd normally say rinse and repeat here. But the point here is there is no rinse! There is only setting myself up for success when I find myself facing a one-way door.</p> <!-- /wp:paragraph --> Top of Mind No. 5 https://therealadam.com/2023/04/26/top-of-mind.html Wed, 26 Apr 2023 08:32:29 -0500 http://therealadam-ng.micro.blog/2023/04/26/top-of-mind.html <!-- wp:paragraph --> <p>Like everyone (it seems), I’m exploring how large language model copilots/assistants might change how I work. A few of the things that have stuck with me:</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":false} --> <ul> <li><a href="https://simonwillison.net/2023/Mar/27/ai-enhanced-development/">Use LLMs to reduce the cost of doing things, there by increasing ambition.</a> That is, reducing cost increases demand.</li> <li><a href="https://martinfowler.com/articles/2023-chatgpt-xu-hao.html">Using LLM prompting to think through/design a new bit of program functionality</a>. If one can manage to write a generic prompt, without proprietary information, you have given many programmers a much wiser pair than they might normally have.</li> <li><a href="https://buttondown.email/hillelwayne/archive/gpt4-should-be-part-of-your-toolkit/">Use LLM flexible tool for thinking through problems or solving them outright</a>. GPT4 is like rolling a REPL, a junior developer, and a conversational partner into one very flexible toolkit.<br></li> </ul> <!-- /wp:list --> <!-- wp:paragraph --> <p>My take right now: GitHub Copilot is the real deal and helpful, today. On the low-end, it’s the most useful autocomplete I’ve used. On the high-end, it’s like having a pair who has memorized countless APIs (with a somewhat fallible memory) but can also type in boilerplate bits of code quickly, so I can edit, verify, and correct them.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I don’t expect the next few products I try to hit that mark. But, I suspect I will have a few LLM-based tools in my weekly rotation by the end of the year.</p> <!-- /wp:paragraph --> Err the Blog, revisited https://therealadam.com/2023/04/14/err-the-blog.html Fri, 14 Apr 2023 07:45:54 -0500 http://therealadam-ng.micro.blog/2023/04/14/err-the-blog.html <!-- wp:paragraph --> <p>Before there was GitHub, there was <a href="http://errtheblog.com/">Err the Blog</a>. Chris Wanstrath and PJ Hyett wrote one of the essential Rails blogs of early Rails era. Therein, many of the idioms and ideas we use to build Rails apps today were documented or born.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I’d figured this site was offline, as are most things from the mid-2000s. ‘Lo and behold, it’s still online in its pink-and-black glory. Lots of nostalgia on my part here.</p> <!-- /wp:paragraph --> <!-- wp:more --> <!-- /wp:more --> <!-- wp:paragraph --> <p>There was a Big Moment here, in my career and Ruby/Rails, where an abnormal density of smart people were together in a moment (if not a community) and the basis of my career took shape. It was good times, even if we didn’t yet have smartphones or doom-scrolling.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Allow me to reflect on what I found as I went through the archives.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">How we built things back then</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Rails circa 2.x was a quite unfamiliar game to the modern developer. REST conventions for CRUD controllers had <em>just</em> taken hold, and were not yet the canonical way to structure Rails code. There was a lot of experimentation and many of the solutions we take for granted today (namely, dependencies) were extremely unsolved back then.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/8-dry-your-controllers">DRY Your Controllers — err.the_blog</a> – ideas about CRUD controllers before CRUD controllers were <em>the</em> thing in Rails (2.0 I think?). That said, if you were to write this now… I'd have issues with that. 😆</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/33-my-rails-toolbox">My Rails Toolbox — err.the_blog</a> – this probably represented the state of the art for building Rails in its time… 17 years ago. 👴</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/50-vendor-everything">Vendor Everything — err.the_blog</a> – I followed this approach on my first Rails app. It was a pretty good way to keep things going for one, enthusiastic developer at the time. But RubyGems, Bundler, etc. are <em>far better</em> than vendor’ing these days. And, one of the crucial leverage points for working in the Rails space.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">How we built things back now</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Some things stay the same. For example, the need to fill in the gaps between Rails’ conventions for organizing your app, enhancing Ruby via ActiveSupport, and the lack of a suitable approach to view templates that satisfies writing code, testing code, and building front-ends.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/3-organize-your-models">Organize Your Models — err.the_blog</a> – early memories of <em>attempting</em> to organize files in a <em>Rails 1.2</em> app despite numerous headwinds presented by Rails itself. (IMO, organizing a Rails app by folder+namespace has really only started to work after Rails 6.0).</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/42-rails-rubyisms-advent">Rails Rubyisms Advent — err.the_blog</a> – a love letter to ActiveSupport's extensions to the Ruby language. Many of these are in the Ruby language now, thankfully! ActiveSupport (still) rubs some folks the wrong way, but it remains one of my favorite things about Rails.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/66-view-testing-20">View Testing 2.0 — err.the_blog</a> – amazingly, there's <em>still</em> no good story here. It's all shell games; write e2e tests instead of unit tests, use object-like intermediaries instead of ERB templates, etc.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">How we stopped building things that way</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Rails has always had flawed ideas that need re-shaping or removing over time. Mostly in making ActiveRecord as good of an ecosystem participant as it is a query-generation API.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/39-withscope-with-scope">with_scope with scope — err.the_blog</a> – ActiveRecord scopes are way better now! I think <code>with_scope</code> remains, at least in spirit, in the Rails router API.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/7-activerecord-variance">ActiveRecord Variance — err.the_blog</a> – wherein our heroes discover inconsistencies in AR's <code>find*</code> APIs and patch their way to more predictable operation thereof.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">How I was even more excited about Ruby</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Err the Blog was not first on the Rails hype wave of the mid-2000’s. But, it was consistently one of the best. Every time a new post was published, I knew it was worthwhile to make time to read the latest post. I learned a lot about my favorite things about Ruby from Err: writing little languages and <code>Enumerable</code>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/37-pennin-a-dsl">Pennin' a DSL — err.the_blog</a> – I could not read enough posts on building DSLs in my early Ruby days. It was <em>the feature</em> I was excited about in Ruby. Thankfully, it's a lot easier to do 'macro magic' in Ruby these days. And, hooking into the idiomatic ways to write Rails-style declarative bits is <em>much better</em> now.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p><a href="http://errtheblog.com/posts/44-select-a-reject">Select a Reject — err.the_blog</a>, <a href="http://errtheblog.com/posts/45-allow-me-to-inject">Allow Me to Inject — err.the_blog</a> – love letters to Enumerable, my <em>favorite</em> thing about Ruby. And <a href="http://errtheblog.com/posts/63-full-of-ambition">Full of Ambition — err.the_blog</a> – fan fiction about Enumerable and ActiveRecord finally uniting in a loving relationship.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">We have to go back</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>If you liked this, you may also enjoy revisiting:</p> <!-- /wp:paragraph --> <!-- wp:list --> <ul><!-- wp:list-item --> <li><a href="http://blog.hasmanythrough.com">has_many :through</a> – Josh Susser’s blog was one of the first to explain how Rails works and how to leverage it</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li><a href="https://hobix.com">Red Handed</a> – _why the lucky stiff’s blog</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li><a href="https://blog.envylabs.com/tagged/rails">Envy Labs</a> – a Rails blog from the Rails Envy folks, Gregg Pollack and Jason Seifer</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li><a href="https://web.archive.org/web/20080209140932/http://blog.caboo.se/">Caboose</a> – part community, part collective, an early nexus of Rails talent<br></li> <!-- /wp:list-item --></ul> <!-- /wp:list --> <!-- wp:paragraph --> <p>And so, I come to the end of my nostalgia. Now, I must go forward.</p> <!-- /wp:paragraph --> Focus in a time of distraction https://therealadam.com/2023/03/24/focus-in-a.html Fri, 24 Mar 2023 08:02:30 -0500 http://therealadam-ng.micro.blog/2023/03/24/focus-in-a.html <!-- wp:paragraph --> <p>That is, some notes on helping junior developers focus on execution when they are surrounded by the twin distractions of novelty and outright broken things. With apologies to <em>Love in the Time of Cholera<sup><a id="ffn1" href="#fn1" class="footnote">1</a></sup>.</em></p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Faced with a junior developer who finds themselves stuck, what questions could you ask them to help them get back on the happy path without <a href="https://therealadam.com/2022/11/21/one-thing-at-a-time-incrementally/">all the distractions that junior developers</a> face:</p> <!-- /wp:paragraph --> <!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>The trick for juniors, is they’re always learning more than one thing at a time, often on accident. They want to build a feature, but it requires a new library, and it requires learning the library. They went to start up my development server, but then something weird happens with Unix. It’s the essential challenge of being a junior – they’re just getting started, so they’re always learning a couple of things at a time2.</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:heading --> <h2 class="wp-block-heading">Is this a side quest?</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Compared to senior developers, juniors often find themselves down <em>the wrong</em> rabbit hole. Senior developers have a better sense of when they are chasing the right lead. Over the course of months and years, they develop a sense of when we’re looking at a red herring. More so, they learn to recognize issues caused by development environment rot, bad data, unrelated bugs, and other sorts of non-essential annoyances.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>In those situations, it’s helpful to ask junior developers if they’re pursuing the essential problem or if they’re on a side-quest. If it’s a side-quest, write it down and get back to the essential issue. If it’s the essential problem, then…</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">What do you need to know to focus or make progress?</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>At all experience levels, software developers face the frustration of “it <em>just</em> doesn’t work”. Occasionally, this is down to outright broken software. Often it’s not knowing about or misunderstanding a crucial detail of how the sub-systems work together.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>It’s <em>extremely</em> tempting to skip ahead, tell a junior developer what they need to know, and move along. That’s how it works on the internet<sup><a id="ffn2" href="#fn2" class="footnote">2</a></sup>. It’s time efficient. The ability to swoop in with an answer feels wizardly, and that’s pretty fun.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Unfortunately, that’s the “give a man a fish, you feed them for a day” approach. Junior devs are a source of endless questions, sometimes excellent and sometimes not. Answering one question, no matter how decisively, is unlikely to change the shape of the ‘questions per hour’ graph.</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">Better questions, better information</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Better to teach junior developers to generate <a href="https://jvns.ca/blog/good-questions/"><em>better</em> questions</a>. Nudge them to lead with what they <em>know</em> about the non-working situation. Encourage them to steer clear of trying magical solutions<sup><a id="ffn3" href="#fn3" class="footnote">3</a></sup> and whack-a-mole troubleshooting<sup><a id="ffn4" href="#fn4" class="footnote">4</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>This teaches a junior developer two things: </p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol><!-- wp:list-item --> <li>They probably know more than they think. </li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>They’re more likely to find their answer by <em>answering questions</em> than by <em>fixating on what doesn’t work</em><br></li> <!-- /wp:list-item --></ol> <!-- /wp:list --> <!-- wp:heading --> <h2 class="wp-block-heading">Which questions can you answer right now?</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>Now that our junior developer is armed with <em>better</em> questions, it’s time to answer them. Given all the questions that might help them make progress, they should start from the ones we know how to answer right now. Sometimes luck strikes and the problem is solved. Other times, the issue <em>and</em> the tricky questions remain.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>This is the scenario where senior developers<sup><a id="ffn5" href="#fn5" class="footnote">5</a></sup> can help a junior developer the most and teach them to fish, so to speak. Senior developers are often more adept at using REPLs, debuggers, automated tests, documentation, static code reading, inspecting data, or observing runtime behavior to turn good questions into answers. In one session, a mentor can show an apprentice how to use an unfamiliar tool, think about problem-solving, <em>and</em> solve the original question. The mentor will probably learn something too!</p> <!-- /wp:paragraph --> <!-- wp:heading --> <h2 class="wp-block-heading">Luck happens</h2> <!-- /wp:heading --> <!-- wp:paragraph --> <p>There is a bit of chance in solving problems. Recall what you already know. Pattern match on the (correct) factors that likely won’t bring you closer to a solution. Ask <em>answerable</em> questions that narrow the issue space. If you make a mis-step at any of these, you could end up confusing yourself even more!</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Stick with it. Maybe step away if you’re already drained, or it’s getting late in the day. But stick with it. Persistence beats luck and chance, most of the time<sup><a id="ffn6" href="#fn6" class="footnote">6</a></sup>.</p> <!-- /wp:paragraph --> <!-- wp:separator {"opacity":"css"} --> <hr class="wp-block-separator has-css-opacity" /> <!-- /wp:separator --> <!-- wp:paragraph --> <p>Thanks to Wade Winningham and Henrik Nyh for sharing ideas on <a href="https://ruby.social/@therealadam/109813587776869003">this topic via ruby.social</a>.</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol><!-- wp:list-item --> <li>Which I have <em>not</em> read but <em>is</em> a pretty snappy title. <a href="#ffn1">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>e.g. Stack Overflow and its ilk <a href="#ffn2">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>e.g. restart the computer, reinstall something <a href="#ffn3">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Trying random changes, repeating one test in hopes of seeing a different result, blindly applying suggestions from similar problems posted on the internet. <a href="#ffn4">↩</a></li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Senior developers <em>appear</em> to have the superpower of seeing circumstances and going <em>directly</em> to the root cause. That usually happens by quickly enumerating <em>what they know about the problem</em> and pattern matching on the circumstances to reduce the problem space to a few possibilities worth eliminating or verifying.<br>This happens via answering enough questions that the problem or behavior of the system becomes obvious. It’s a bit of crafting a theory until you trip over the actual situation. <a href="#ffn5">↩</a> </li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>Casinos and rigged games are notable exceptions. <a href="#ffn6">↩</a></li> <!-- /wp:list-item --></ol> <!-- /wp:list -->