Ultranormal

Category: development

  • Wrapping up National Blog Post Month

    Between writing a blog post almost every day and going back to the beginning of this blog and re-reading stuff I wrote over twenty years ago, it’s been a bloggy month over here!

    I only missed two days. I can live with that. I’ve blogged more this month than I have in years, and that was the whole goal.

    My big learning from this experience is that social media really killed my blogging. If you look at the first few years of posts, I sometimes posted multiple short posts in a day and maybe one longer thing a week.

    Now, I never write short posts. They’re all longer than a paragraph, and that’s what blogging means to me now, which I think is misguided and too inspired by more “professional” blogs. This is my personal space, and I should use it to post whatever inane nonsense is on my mind. It’s not a diary, but it is kind of a public journal of what I’m thinking about – a perennial first draft of things that might become something more professional in the future.

    I need to give myself permission to post the first draft (sorry in advance), and be OK with it living forever(ish). Because that’s what blogging should be – the great empathy engine of the web. It’s our thoughts, our selves, out there for anyone to stumble across and get a glimpse of our lived experience. Whether you’re me, a cishet white male with serious dad energy, a writer in Minnesota, or a famous sci-fi author in Ohio, your life is worth talking about. Your thoughts are worth sharing.

    I probably won’t post once a day, but I’m hoping I make blogging a habit again. Fingers crossed!

  • The expert is calling from inside the house

    I’ve played product manager more often this year than I have in years. It’s been a fun role to get back into.

    It’s also been a long time since I played product manager at a larger company. The last two times were tiny startups, and well, it’s a very different experience.

    With tiny startup product management, I didn’t have a lot of internal expertise to rely on, so most of the research was external – I had to find people to talk to, find research, do a lot of research, and figure out how to validate assumptions.

    A lot of that is similar in a larger company, but, the expertise is inside the walls at a larger company. I’ve had great results in all of my recent projects by just asking for folks who have expertise in big public Slack channels and they just appeared!

    I think we frequently discount our own, and our peers’, expertise when doing discovery and research, especially our peers in customer support roles. I think that’s a huge mistake. Who talks to your customer more than the folks in customer support? Nobody. Who knows your product better than the people who have to support it? Pretty much nobody.

    I was able to jump start onboarding to new subject areas a whole lot faster by asking our support teams about their processes and doing user interviews, just like I would with a potential customer, and that lead to some really interesting discoveries and avenues to explore.

    So, don’t take your internal experts for granted! Ask them things! Praise them! Share your results back with them!

  • Avoiding cynicism

    I mentioned this last week, but while I’ve been fixing formatting issues on my old blog posts, I’ve made the mistake of reading some of them. Getting a glimpse of me 20 years ago has been interesting – he was so angry, usually about work, and talked about it a lot.

    That guy was on the verge of burnout every other week, and I think he was actually burned out quite a lot.

    I’m not angry about work anymore. I was last really burned out over five years ago.

    I think if I’d kept going the way I was headed back then, I’d be a cynical burned out husk. I haven’t read beyond the beginning of 2003 yet, but I can’t wait to see when the switch flipped (having a “coming attractions” for my own past is pretty weird).

    If you asked me right now how I avoid being a cynical husk, I think it comes down to my rules for working:

    • Never miss a chance to celebrate. We’re confronted with failure so often at work, that we should celebrate every little win.
    • Focus on the who and the how. We don’t control what we work on most of the time, and pinning our self-worth to the success or failure of the things we work on is a recipe for sadness. So, I no longer really care what I work on. I care about enjoying the people I work with, and focus on how I work. I can control how I work more than I can any other part of it.
    • Compete only with yourself. I try not to compare myself to other people. I’ve got my challenges and other commitments, and I know nothing of theirs. So, I only compete against Past Me™️ – which also helps make sure I’m constantly improving, even if it’s just a little bit.

    That’s not a lot of rules… but they work for me. I might change them…

  • The past is embarassing

    This blog is twenty-something years old, and has moved blogging platforms at least three times, and between various WordPress installs at least another three times. Some of the older posts got messed up along the way, so I’m going back through them and trying to fix them.

    Re-reading stuff I wrote from 2001 is… something. I talked way too much about work (this was before “dooced” was a verb). I don’t remember what exactly I was angry about back then, but I was often very annoyed and not good at not writing about it. I also posted a lot. I’d totally forgotten how short and frequent my post were back then, pre-Twitter.

    I’m glad those posts exist, even the stupid ones. They’re fun to look back on and laugh at what I was excited about (like waiting for a new mac with a 60gb hard drive, and triple booting it – I also did a lot more compiling software than I do today). It turns out, 2001 was the year of linux on the desktop?

    I think the saddest thing is how many of the links are now dead. Most of the blogs I linked to back then don’t resolve, or are for sale.

    Rediscovering blogging has been the best part of , and I probably won’t ever top the 5 posts in one day I used to do in 2001, I’m going to try to post more regularly if only so I can look back in 20 more years at how stupid I was in 2023.

  • Mid-caffeination Mastodon Thoughts

    Derek Powazek posted this on Mastodon yesterday:

    An actual use for machine learning that I’d want: a bot that records all the posts that cause me to block someone, saves them into a db, and then automatically hides posts that match above a certain threshold.

    Derek on Mastodon

    I love a good brain exercise, so I’ve been thinking about it, and I don’t actually think this is that hard, and is very possible using tools you already need to run Mastodon in production.

    I might play with actually implementing this during my week off around cooking and family time, but if someone else wanted to do it, this idea is 100% free.

    To enable search in Mastodon, you have to install and use ElasticSearch. It has machine learning goodies in it already like nearest neighbor and vector search.

    Basically, we should be able to build a very personal spam/block bot for Mastodon given some training data (posts that pushed you to block someone) and some fiddling about (which is the hard/fun part).

    Right now, there are no dates on blocks in Mastodon (I haven’t checked the schema yet to see if they’re there but not returned), and you can’t see which post “triggered” the block. I think that could be added fairly easily – or at least something like “Add this to Blockbot” to use it to train the bot.

    Mastodon doesn’t really have a plugin architecture yet, so I’m not sure if this should be a standalone app that sits alongside your running Mastodon instance or a feature – I’ll probably try it as a feature to get familiar with Mastodon.

    Basically, we take “blockworthy” posts, index them, and then use that to compare posts to the blocklist to get a semantic distance. Once we have the distance we can start manually testing for accuracy and tweak settings until we get something close to a “block score”. Users could then say, “yep, don’t show me anything with a block score greater than 1.5” and ta-da, a little robot janitor is just cleaning up your feed for you. That’s probably computationally intensive to do on every post, but I think you could apply it to people you don’t follow who reply to you to weed out the worst Reply Guys and riff raff.

    You could also have community-wide block bots that are trained on a communal collection of blockworthy posts. It could help get around rigid blocklists by allowing targetted removal of replies from timelines instead of blocking whole instances.

    It could also be used for finding good stuff too… Imagine something that found you people who post things like you do and brought them to you. It could be used as an “attract” bot as well.

    I think ideally, it could be used like left and right handed whuffie. When you come in contact with a profile, how alike and how different are your posts from theirs’? Do we agree on anything? Are our disagreements strong enough, and on topics that are sensitive enough, that I probably don’t want to engage with them? Then it’s more informative than just a robot going out and sweeping up my replies.

    Yeah, this is hand wavey, but a lot of this stuff is just built in to ElasticSearch already, so it’s not like we have to invent anything (yay, because that’s hard). We just have to assemble it and feed it enough data.

    It should be fun, and I think it could be helpful, especially for folks who get inundated with awful replies.

    And if you beat me to implementing it, that’s great! Then it’ll be out there in the world and we can all play with it!

  • Strategic apathy

    I have a bad habit at work of saying “I don’t care” without qualifying it. It comes off as sarcastic or dismissive, when that’s not how I mean it – which means I need to find a new way to express it.

    Most of the time, it pops out of my mouth when my manager asks me if I want to work on something and then she gives me a look, and I have to explain myself.

    Here’s the explanation: I no longer care what I work on. I’ve built one of pretty much anything I’d ever want to build, and the what just no longer matters. What matters to me is how I work, and who I work with. I alluded to this in the post about ficlets, but the individual projects blur together. The thing I remember is the thrill of building something with people. I remember the people, and how I felt while we were building whatever it was.

    I still believe in constant incremental improvement, and only competing with myself. I also now finally understand that just building something that’s technically superior doesn’t guarantee success. Success or failure in the eyes of the market almost never has much to do with the code that implements it. It requires the work of everyone on the team, every discipline, and a ton of luck.

    And all of that means I’d much rather focus on making sure that I’m helping everyone else on the team do their best work, and asking them to help me make sure I’m doing mine. That’s literally all that matters to me at this point. Yes, I love big meaty technical problems, but that’s a very small part of the overall solution. The most important part is the borders where disciplines meet and making sure that those borders are seamless, complementary and supportive of the rest of the disciplines involved. That’s way more complicated, and way more rewarding when it works.

  • App Defaults

    Why not do an old school blogging meme for day 13? Well, that’s what I’m doing today, so… let’s go! I’ve seen it a couple of places, but I last saw it over here, which is where I was convinced that it would be today’s post.

    I’m pretty much all Apple for end-user things. I’m also an Ubuntu users, but I pretty much only interact with it via the command line.

    • Mail Client: Mimestream on macOS, Apple Mail on iOS
    • Mail Server: It’s GMail all the way down.
    • Notes: Apple Notes
    • To-Do: Apple Reminders for long-term and recurring things. I use Day One for short-term to-dos and my daily work journal
    • Photo Shooting: the iOS Camera or Hipstagram if I’m feeling fancy/silly.
    • Photo Management: Apple Photos
    • Calendar: Fantastical
    • Cloud File Storage: Google Drive and iCloud
    • RSS: NetNewsWire everywhere, and I’m so glad it’s back.
    • Contacts: Google + iCloud (they’re a mess)
    • Browser: Firefox for personal stuff, Chrome for work, Safari for mobile. I’m polybrowserous and am fine with it.
    • Bookmarks: Firefox and Chrome (in profiles because you gotta keep things separate)
    • Read It Later: Pocket, but it’s mostly later because I forget to check it.
    • Word Processing, Spreadsheets & Presentations: Google Suite
    • News: The aforementioned NetNewsWire for following blogs like Talking Points Memo (which has been awesome for 20+ years), Apple News+, NY Times, Washington Post, The Ringer and The Athletic.
    • Music: Spotify and my Plex server for live shows and mashups
    • Podcasts: Overcast
    • Password Management: 1Password
    • Code Editor: VS Code, but I really miss Atom.

  • Just trying to be understood

    If you are writing the clearest, truest words you can find and doing the best you can to understand and communicate, this will shine on paper like its own little lighthouse. Lighthouses don’t go running all over an island looking for boats to save; they just stand there shining.

    Anne Lamott

    The creation of all media is accompanied by a wish: to experience and to be experienced by another human mind. Above all this means to feel and to be felt.

    Ze Frank

    Today, you get quotes. So far, National Blog Post Writing Month has me writing longer-than-I-expected posts about things that I either wrote about a long time ago, or things that have been trapped in my head for years and I finally had a reason to write them down.

    All of it is an attempt at being understood… and it’s my favorite thing about personal blogging. It’s one person, quietly sharing their heart, in the best way they know how, out into the chaos and cacophony of social media.

    I’ve been doing it, somewhat inconsistently, for almost twenty-four years. This is the 2,800th post on this blog (here’s the first), and over 2,500 are mine, written by me (my wife also used to blog here once upon a time).

    A lot of those posts are now kind of embarrassing. I don’t think I’ve ever gone back and deleted any (guaranteeing that I’ll probably never be able to run for office – a brilliant bit of subconscious self-sabotage). But, they provide a portrait of what I was trying to make sense of at the time, what was important, and again, all in an attempt to understand and be understood.

    The mind that is not baffled, is unemployed.

    Wendell Berry

  • People are always the problem

    I’m now a very senior engineer. I don’t even know what the right title is (once I got “CTO” titles kind of stopped mattering), but at Gusto I’m an L6 and there are seven levels at the company.

    One of the great things about working at a larger company is how many people I get to work with, and how many opportunities I have to mentor more junior engineers.

    We spend so much time early in our careers just learning the mechanics of our immediate job: how to write code, make it maintainable, how to test it, how to make it performant, etc, etc, etc. That takes years, and is a lot. And then someone promotes us, tells us we’re now a “senior” engineer and we’re now presented a whole new scale of problems, and all of those problems involve people.

    I think the industry does a pretty terrible job of preparing software developers to deal with people problems. We tell them to focus on code, which is important, because that’s the first layer of what’s expected of us.

    If we think about the problems we deal with as we get more senior as layers, I think it’s easier to understand them. To me, in this very much first draft of me putting this into words, the layers are:

    • Code: We have to be good at this to be asked to do anything else (even though almost all code problems are also caused by people).
    • Individuals: We have a manager (at least one), people on our team, product managers, designers, etc. We need to deal with them individually and make sure we get what we need, and meet their needs.
    • Processes: Everything we do at work is some kind of process – the meetings we have, how we deliver code, how we get rewarded for our work, all processes.
    • Systems: Collections of processes in action – I think of them mostly in code, but “the patriarchy” is a system.
    • Organizations: Organizations are just groups of people who create systems in order to accomplish their goals. Depending on the size of your company, you may in a nesting doll of organizations and may interact with several more.

    As you get more senior, you’re expected to be able to solve problems on and across all of those layers. The hard part is figuring out what layers are “crossed by the problem you’re trying to solve, and then peeling them off and solving them – because the tools you can use are wildly different at each layer and require different skills.

    The good part is that solving problems across layers is extremely valuable to organizations, so if you can do it, you’ll be just fine. The bad part is that as soon as you start crossing layers, people are always the problem.

  • Looking back: ficlets launching

    I was going to just post a quote for today’s NaBloPoMo, but I was looking for old posts and stumbled on this one about ficlets launching.

    Re-reading it, sixteen and a half years later, a few things jump out:

    • How many people I worked with, and thanked in the post, are no longer with us: Cindy Li, John Anderson and Suzie Austin are all gone, and gone way too soon.
    • How often I think about the people I worked with on ficlets, and how much ficlets opened my eyes to what working at a small startup could be like.
    • I thought that ficlets launched in 2006, but nope, it launched in 2007, and I left AOL in May of 2008.
    • How happy I am that all the links to the stories actually work (because AOL never owned the domain name, and didn’t make me give it to them, I took it back around the time I set up the ficly archive, and ta-da, all the stories live again on the web at their original URLs). I couldn’t do the same for the blog posts, unfortunately.
    • How much ownership we felt over the product and the community. Jason, Joe and I spent a lot of time “rescuing” the stories (thank goodness for Creative Commons licensing), and then building ficly.

    Most of the hundreds of projects I’ve worked on over the years (LOL, decades) blur together into vague lumps, but not ficlets. It was just the absolute best, most fun, weirdest thing I’ve ever gotten to do, and I miss it all the time (because working at a startup wasn’t really like that – it was way scarier).

    The last thing is just how strong my feelings are for the people I’ve worked with. I may do a terrible job of keeping in touch, but I really do love all of them. The products we work on, they don’t matter nearly as much as the people we work with. And none of it lasts, not the products, not the jobs, none of it – but the people, the people are what’s important, so act accordingly.