This comes with a move toward orchestration, and a fundamental change in how we engage with our craft. Many of us became coders first, software engineers second. There’s a lot more to software engineering than coding, but coding is our first love.

Coding is comfortable, coding is fun, coding is safe. For many of us, the actual writing of syntax was never the bottleneck anyway. But now, you can command swarms of agents to do your bidding (until the compute budget runs out, at least, and we collectively decide that maybe junior engineers aren’t a terrible investment after all).

The day-to-day reality of the job is shifting. Instead of writing greenfield code or getting into the flow state to debug a complex problem, you’re now multitasking. You’re switching between multiple long-running tasks, directing AI agents, and explaining to these eager little toddlers that their assumptions are wrong, their contexts are overflowing, or they need to pivot and do X, Y, and Z.

And that requires endless context switching. Humans cannot truly multitask; our brains just rapidly jump context across multiple threads. Inevitably, some of that context gets lost. It’s cognitively exhausting, but it feels hyper-productive because instead of doing one thing, you’re doing three—even if the organizational overhead means it actually takes four times as long to get them all over the finish line.

This is, historically, what staff software engineers do. They don’t particularly write much code. They juggle organizational bits and pieces, align architecture, and have engineers orbiting around them executing on the vision. It’s a fine job, and highly impactful, but it’s a fundamentally different job. It requires a different set of skills, and it yields a different type of enjoyment. It’s like people management, but without the fun part: the people.

As an industry, we’re trading these intimate puzzles for large scale system architecture. Individual developer can now build at the sacle of a whole product team. But scaling up our levels of abstraction always leaves something visceral behind.

It was Ben who first pointed out to me that many of us will grieve writing code by hand, and he’s absolutely right. We will miss the quiet satisfaction of solving an isolated problem ourselves, rather than herding fleets of stochastic machines. We’ll adjust, of course. The field will evolve, the friction will decrease, and the sheer scale of what we can create will ultimately make the trade-off worth it.

But the shape of our daily work has permanently changed, and it’s okay to grieve the loss of our first love. Consider this post your permission to do so.

I’ll explain myself, don’t worry.

I like Vim. Enough to write a book about the editor, and enough to use Vim to write this article. I’m sure you’ve encountered colleagues who swear by their Vim or Emacs setups, or you might be one yourself.

Here’s the thing most people get wrong about Vim: it isn’t about speed. It doesn’t necessarily make you faster (although it can), but what it does is keep you in the flow. It makes text editing easier — it’s nice not having to hunt down the mouse or hold an arrow key for exactly three and a half seconds. You can just delete a sentence. Or replace text inside the parentheses, or maybe swap parentheses for quotes. You’re editing without interruption, and it gives your brain space to focus on the task at hand.

AI tools look this way on the surface. They promise the same thing Vim delivers: less friction, more flow, your brain freed up to think about the hard stuff. And sometimes they actually deliver on that promise! I’ve had sessions where an AI assistant helped me skip past the tedious scaffolding and jump straight into the interesting architectural problem. There’s lots of good here.

Well, I think the difference between AI and Vim explains a lot of the discomfort engineers are feeling right now.

The depth problem

When I use Vim, the output is mine. Every keystroke, every motion, every edit — it’s a direct translation of my intent. Vim is a transparent tool: it does exactly what I tell it to do, nothing more. The skill floor and ceiling are high, but the relationship is honest. I learn a new motion, I understand what it does, and I can predict its behavior forever. There’s no hallucination. ci) will always change text inside parentheses. It won’t sometimes change the whole paragraph because it misunderstood the context.

AI tools have a different relationship with their operator. The output looks like yours, reads like yours, and certainly looks more polished than what you would produce on a first pass. But it isn’t a direct translation of your intent. Sometimes it’s a fine approximation. Sometimes it’s subtly wrong in ways you won’t catch until a hidden bug hits production.

This is what I’d call the depth problem. When I use Vim, nobody can tell from reading my code whether I wrote it in Vim, VS Code, or Notepad. The tool is invisible in the artifact. And that’s fine, great even - because the quality of the output still depends entirely on me. My understanding of the problem, my experience with the codebase, my judgment about edge cases, my ability to produce elegant code - all of that shows up in the final product, regardless of which editor I used to type it up.

AI inverts this. The tool is extremely visible in the artifact - it shapes the output’s style, structure, and polish - but the operator’s skill level becomes invisible. Everything comes out looking equally competent. You can’t tell from a pull request whether the author spent thirty minutes carefully steering the AI through edge cases or just hit accept on the first suggestion.

That’s a huge problem, really. Because before, a bad pull request was easy to spot. Oftentimes a junior engineer would give you “hints” by not following the style guides or established conventions, which eventually tips you off and leads you to discover a major bug or missed corner case.

Well, AI output always looks polished. We lost a key indicator which makes engineering spidey sense tingle. Now every line of code, every pull request is a suspect. And that’s exhausting.

Looking done versus being right

I just read Ivan Turkovic’s excellent AI Made Writing Code Easier. It Made Being an Engineer Harder (thanks for the share-out, Ben), and I couldn’t agree more with his core observation. The gap between “looking done” and “being right” is growing, and it’s growing fast.

You know what’s annoying? When your PM can prototype something in an afternoon and expects you to get that prototype “the rest of the way done” by Friday. Or the same day, if they’re feeling particularly optimistic about what “the rest of the way” means (my PMs are wonderful and thankfully don’t do this).

But either way I don’t blame them, honestly. The prototype looks great. It’s got real-ish data, it handles the happy path, and it even has a loading spinner. It looks like a product. And if I could build this in two hours with an AI tool - well, how hard could it be for a full-time engineer to finish it up?

The answer, of course, is that the last 10% of the work is 90% of the effort. Edge cases, error handling, validation, accessibility, security, performance under load, integration with existing systems, observability - none of that is visible in a prototype, and AI tools are exceptionally good at producing work that doesn’t have any of it. The prototype isn’t 90% done. It 90% looks good.

Of course there’s an education component here - understanding the difference between surface level polish and structural soundness. But there’s a deeper problem here too, and it’s hard to solve with education alone.

The empathy gap

My friend and colleague Sarah put this better than I could: we’re going to need lessons in empathy.

Here’s what she means. When a PM can spin up a working prototype in an afternoon using AI, they start to believe - even subconsciously - that they understand what engineering involves. When an engineer uses AI to generate user-facing documentation, they start to think the tech writer’s job is trivial. When a designer uses AI to write frontend code, they wonder why the team needs a dedicated frontend engineer.

And none of these people are wrong about what they experienced. The PM really did build a working prototype. The engineer really did produce passable documentation. But the conclusion that they “did the other person’s job” and the job is therefore easy - is completely wrong.

Speaking of Sarah. Sarah is a staff user experience researcher. It’s Doctor Sarah, actually. And I had the opportunity to contribute on a research paper, and I used AI to structure my contributions, and I was oh-so-proud of the work because it looked exactly like what I’ve seen in countless research papers I’ve read over the years. And Sarah scanned through my contributions, and was real proud of me. Until she sat down to read what I wrote, and had to rewrite just about everything I “contributed” from scratch.

AI gives everyone a surface-level ability to contribute across almost any domain or role. And surface-level ability is the most dangerous kind, because it comes with surface-level understanding and full-depth confidence. Modern knowledge jobs are often understood by their output. Tech writers by the documents produced, designers by the mocks, and software engineers by code. But none of those artifacts are core skills of each role. Tech writers are really good at breaking down complex concepts in ways majority of people can understand and internalize. Designers build intuition and understanding of how people behave and engage with all kinds of stuff. Software engineers solve problems. AI tools can’t do those things.

The path forward isn’t to gatekeep or to dismiss AI-generated contributions. It’s to build organizational empathy - a genuine understanding that every discipline has depth that isn’t visible from the outside, and that a tool which lets you produce artifacts in another person’s domain doesn’t mean you understand that domain.

This is, admittedly, not a new problem. Engineers have underestimated designers since the dawn of software. PMs have underestimated engineers for just as long. But AI is pouring fuel on this particular fire by making everyone feel like a competent generalist.

So what do we actually do?

I don’t want to be the person writing yet another “AI is ruining everything” essay. Frankly, there are enough of those. AI tools are genuinely useful - I use them daily, they make certain kinds of work better, and they’re here to stay. The scaffolding, the boilerplate, the “I know exactly what this should look like but I don’t want to type it out” moments - AI is great for those. Just like Vim is great for the “I need to restructure this method” moments.

A few things I think help, borrowing from Turkovic’s recommendations and adding some of my own:

Draw clear boundaries around AI output. A prototype is a prototype, not a product. AI-generated code is a first draft, not a pull request. Making this explicit - in team norms, in review processes, in how we talk about work - helps close the gap between appearance and reality.

Invest in education, not just adoption. Rolling out AI tools without teaching people how to evaluate their output is like handing someone Vim without explaining modes. They’ll produce something, sure, but they won’t understand what they produced. And unlike Vim, where the failure mode is jjjjjjkkkkkk:help! in your file, the failure mode with AI is shipping code that looks correct and isn’t.

Build empathy across disciplines. This is Sarah’s point, and I think it’s the most important one. If AI makes it easy for anyone to produce surface-level work in any domain, then we need to get much better at respecting the depth beneath the surface. That means engineers sitting with PMs to understand their constraints, PMs shadowing engineers through the painful parts of productionization, and everyone acknowledging that “I made a thing with AI” is the beginning of a conversation, not the end of one.

Protect your flow. This is the Vim lesson. The best tools are the ones that serve your intent without distorting it. If an AI tool is helping you think more clearly about the problem, great. If it’s generating so much output that your job has shifted from “solving problems” to “reviewing AI’s work” - that’s not flow. That’s a different job, and it might not be the one you signed up for.

I keep coming back to this: Vim is a good tool because it does what I mean. The gap between my intent and the output is zero. AI tools are useful, sometimes very useful, but that gap is never zero. Knowing when the gap matters and when it doesn’t - that’s a core skill for where we are today.

P.S. Did this piece need a Vim throughline? No it didn’t. But I enjoyed shoehorning it in regardless. I hear that’s going around lately.

All opinions expressed here are my own. I don’t speak for Google.

While I won’t comment on the situation at Google, there are many anecdotes online about folks online who raise concerns about increased work pressure. When a response to “I’m overloaded” becomes “use AI” - we’re heading for unsustainable workloads.

The problem is compounded by the fact that AI tools excel at prototyping - the type of work which makes other work happen. Now, your product manager can prototype an idea in a couple of hours, fill it with real (but often incorrect) data, sell the idea to stakeholders, and set goals to productionize it a week later.

“Look - the prototype works, and it even uses real data. If I could do this in a couple of hours, how hard could this be for an experienced engineer?” - while I haven’t heard these exact words, the sentiment is widespread (again, online).

In a world where AI provides a surface-level ability to contribute across almost any role, the path to avoiding global burnout is to focus on building empathy. Just because an LLM can churn out a document doesn’t mean it’s actually good writing, and we’re certainly not at the point where a handful of agents can replace a seasoned PM. However, because the output looks polished - especially to those without deep domain knowledge - it’s easy to fall into the trap of thinking you’ve done someone else’s job for them.

That gap between “looking done” and “being right” is exactly where the extra professional pressure begins to mount. This is really caused by the way we still measure knowledge worker productivity - by the sheer number of artifacts they produce, rather than the outcomes of the work.

The right way to leverage AI in workspace is as a license to work better and focus on the right things, not as a mandate to produce more things faster.

At this point I have 20-or-so services running and sometimes it gets hard to keep track of what’s where. For that - I found Homepage. A simple, fast, lightweight page which connects to all of my services for some basic monitoring, and reminds me what my service layout looks like.

Here’s what I built:

I love that the configuration lives in YAML files, and because the page is static - it loads real fast. There are many widgets which provide info about various services out of the box. It’s neat.

There’s definitely a question of how much I’ll keep this up-to-date: it’s not an automatically populated dashboard, and editing is a two-step process (SSH into the machine, edit the YAML configs) - which adds some friction. We’ll have to wait and see, but for now I’m excited about my little dashboard.

I’ve been writing a lot more over the past year - in fact, I’ve written at least once a week, and this is article number 60 within the past year. I did this for many reasons: to get better at writing, to get out of a creative rut, play around with different writing voices, but also because I wanted to move my blog from a dry tech blog to something I myself am a little more excited about.

I started this blog in 2012, documenting my experiences with various programming tools and coding languages. I felt like I contributed by sharing tutorials, and having some public technical artifacts helped during job searches.

Over the years I branched out - short reviews for books I’ve read, recounts of my travel (and turning my Prius into a car camper to do so), notes on personal finance… All of this shares a theme: descriptive writing.

I feel most confident describing and recounting events and putting together tutorials. It’s easy to verify if I’m wrong - an event either happened or didn’t, the tool either worked - or didn’t. And I was there the whole time. That kind of writing doesn’t take much soul and grit, and while it’s pretty good at drawing traffic to the site (eh, which is something I don’t particularly care about anymore), I wouldn’t call it particularly fulfilling. Creatively, at least.

I’m scared to share opinions, because opinions vary and don’t have ground truth. It’s easier to be completely wrong, or to look like a fool. I don’t want to be criticised for my writing. Privacy is a matter too - despite writing publicly, I consider myself to be a private person.

So, after 13 years of descriptive writing, I made an effort to experiment in 2025. I wrote down some notes on parenthood, my thoughts on AI and Warhammer, nostalgia, identity, ego… I wrote about writing, too.

It’s been a scary transition, and it still is. I have to fight myself to avoid putting together yet another tutorial or an observation on modal interfaces. I’ve been somewhat successful though, as I even wrote a piece on my anxiety about sharing opinions.

But descriptive writing continues sneaking in, trying to reclaim the field.

You see, I write under my own name. I like the authenticity this affords me, and it’s nice not having to make a secret blog (which I will eventually accidentally leak, knowing my forgetfulness). I mean this blog has been running for 14 years now, that’s gotta count for something.

But writing under my own name also presents a major problem. It’s my real name. If you search for “Ruslan Osipov”, my site’s at the top. I don’t hide who I am, and you can quickly confirm my identity by going to my about page. This means that friends, colleagues, neighbors, bosses, government officials - anyone - can easily find my writing. If there are people out there who don’t like me - for whatever reason - they can read my stuff too.

The more I write, the more I learn that good writing is 1) passionate and 2) vulnerable (it’s also well structured, but I have no intention of restructuring this essay - so you’ll just have to sit with my fragmented train of thought).

It’s easy to write about things I’m passionate about. I get passionate about everything I get involved in - from parenting and housework to my work. I write this article in Vim, and I’m passionate enough about that to write a book on the subject.

Vulnerability is hard. Good writing is raw, it makes the author feel things, and leaves little bits and pieces of the author scattered on the page. You just can’t fake authenticity. But here’s the thing - real life is messy. Babies throw tantrums, work gets stressful, the world changes in the ways you might not like. That isn’t something you want the whole world to know.

Especially if that world involves a prospective employer, for example. So you have to put up a facade, and filter topics that could pose risk. I’m no fool: I’m not going to criticize the company that pays me money. I like getting paid money, it buys food, diapers, and video games.

I still think it’s a bit weird and restrictive that a future recruiter is curating my writing today. The furthest I’m willing to push the envelope here is my essay on corporate jobs and self-worth.

Curation happens to more than the work-related topics of course. And that might even be a good thing. I don’t just reminisce about my upbringing. It’s a brief jumping off point into my obsession with productivity. Curation is just good taste. You’re not getting my darkest, messiest, snottiest remarks. You’re getting a loosely organized, tangentially related set of ideas. Finding that gradient has been exciting.

So, here’s what I won’t write about. I won’t share too many details about our home life. I won’t complain about a bad day at work. I won’t badmouth people.

But I will write about what those things feel like - the tiredness, the frustration, the ego.

Everyone warned me that starting daycare will be rough. Everyone said oh hey, you’ll be sick all the time, your kid will be sick all the time, you’ll be miserable.

How bad could it be, right? Well, it’s bad. I don’t have a thesis for this post, I just need to vent. And yeah, sick kiddo is why I’m almost a week behind my (self-imposed) writing schedule.

Because over the past month this child was supposed to be in daycare (which isn’t cheap, mind you), she’s been home at least 50% of the time. And oh how I wish I could just blame daycare and say they don’t want to deal with yet-another-whiny-and-snotty-kid, I also empathize with both the overworked daycare employees who want to send her home.

Being a daycare worker isn’t easy, and I’m sure constant crying doesn’t help. When we were touring daycares, we’ve noticed something interesting: every place posts pictures, names, and mini-resumes for their teachers - and what stands out to me is that many have 1-2 years of experience. Not just at the daycare we picked, but among the majority of places we’ve toured.

Turns out daycare workers have a significantly above average turnover - like a press release from Federal Reserve Bank of Cleveland indicating that the “turnover among childcare workers was 65% higher than turnover of median occupation”. The wages are low, the hyper-vigilance needed to keep infants and toddlers alive takes a toll on a nervous system, and the job is mostly sedentary - with lots of sitting on the floor and baby chairs watching the little demons crawl around.

Where was I? Oh, yeah, I don’t know what daycare workers are going through, but I empathize.

But I also empathize with myself (d’oh), working half-days and taking unexpected time off as my clingy, cranky, annoyed toddler wants demands some kind of attention. The kiddo’s sick and wants to be held 24/7. But you know what else? She gets bored, so she wants to play. But it’s hard to play when you’re being held. So crying tends to be a good solution.

And all of that is on top of the fact that this disease-ridden potato has gotten me sick, 4 times and counting in the past 3 months. Her and mom get pretty sick, but - probably because mom’s body is working for two - they do mostly fine. Sick, but manageable.

I on the other hand just feel like I’m barely able to survive some days. Everything hurts, and nothing helps. I used to like being sick, in the same ways I love rainy days. You get an excuse to veg out - yeah, it’s unpleasant, but you get to binge your favorite shows or play some sick-friendly games. You order in or your partner cooks for you. You drink tea and such. It’s cozy.

And most importantly for someone who struggles to sit still, I don’t feel any guilt for doing nothing. It’s nice.

But being sick with a kid - hell no. Gone is the guilt-free experience. Kid’s sick, wife’s sick, I’m sick. We’re all rotating through our chores, we all have our roles to play. One of us soothes the baby, one of us cooks and cleans, one of us cries and leaves a trail of snot on the floor.

So yeah, here I am, on my 4th sickness, taking a breather to write up this note while mom took the kiddo to get some fresh air.

Send help. No, really - shoot me an email to tell me I’m not alone and you’ve survived this. Or maybe tell me why you also enjoy how being sick gives you a permission to be lazy. Someone please normalize my experience!

We spent time in Ho Chi Minh (or Saigon if you’re old) before heading to Tokyo, and the contrast was so striking that I can’t stop thinking about it. Both incredible places, both completely different in ways I find genuinely fascinating - and completely hilarious.

Japanese people love to queue. I say this with admiration - it’s a cultural commitment I find both impressive and, in its most intense forms, comedy gold. Food? Queue. Taking a train? Queue. Elevator? Believe it or not, queue. I’m half convinced there’s a queue somewhere just for the privilege of standing in another queue.

And oh, the “close door” button on elevators. I witnessed something beautiful in Tokyo: the unmistakable rapid-fire mashing of that button the moment someone steps inside, even when - especially when - they can clearly see me approaching. It’s not malicious. I don’t think it’s even personal. It’s just… commitment to efficiency, extending all the way down to shaving those precious three seconds off the elevator door’s natural rhythm. Dude. I can see you. I’m right here.

Just look at the wear pattern on these elevator butons:

That’s what most elevators looked like.

The subway has a similar choreography. People pushing past you with practiced, almost apologetic urgency. Same with the konbini - if you’re in someone’s path to the onigiri section, you will be navigated around like a minor obstacle in an otherwise frictionless system. It’s nothing personal, you’re just in the way of the system.

Here’s what really struck me about Tokyo: you can go an entire day without having a meaningful interaction with another person. And I don’t mean that in a sad, lonely way - I mean it as a genuine observation about how thoughtfully everything is designed.

Restaurants have ticket machines where you order and pay before sitting down. Your food arrives. You eat. You leave. No one needs to talk to you. No one wants to talk to you - and that’s not rudeness, it’s infrastructure. The system handles everything. The mother’s rooms were cleaner than our own house (and I mean that literally - I looked around one of those nursing rooms and felt personally called out by my own bathroom at home). Everything has a place, a purpose, a queue.

It’s impressive. It’s hyper-functional. And after coming from Vietnam, the contrast was jarring.

In Vietnam, you cannot avoid interacting with people. It’s physically impossible. Every transaction feels impromptu, like you’re the first customer they’ve ever had and everyone’s figuring it out together in real-time.

Paying a bill at a restaurant? That might involve three people, a calculator that may or may not work, and a vague sense that the total is more of a collaborative suggestion than an established fact. “How much?” “Uh… let me ask my cousin.” This is not a criticism - it’s delightful. There’s a warmth to that chaos.

Service in Japan is polished to perfection, almost rehearsed - which makes sense, given the cultural emphasis on hospitality. In Vietnam, it felt more like someone’s aunt decided to help out at the family restaurant. Less professional, maybe, but somehow warmer? The friendliness wasn’t performance, it was just… how things were.

Traveling with an infant is exhausting in ways I couldn’t have predicted, but it’s also like carrying around a small social barometer. You get to see how different cultures engage with kids, and the contrast between Tokyo and Ho Chi Minh was striking.

In Ho Chi Minh, my daughter was a celebrity. Everyone wanted to hold her, talk to her, feed her something we probably shouldn’t let her eat. The warmth was overwhelming - chaotic, often not always hygienic, but deeply human. Strangers cooing at her, shopkeepers waving, someone’s grandmother stopping us to admire the baby. Human connection wasn’t optional - it was woven into the fabric of every interaction.

Tokyo was different. Not cold, exactly. Just… distant. People are exceptionally polite, but there’s a respectful bubble around families. No one’s stopping you on the street to admire your baby. Which is fine! Privacy is a gift, especially when you’re tired. But it’s noticeable when you’ve just come from a place where your kiddo was treated like a visiting dignitary.

In Japan, you can live in a world of seamless, frictionless interactions. Machines handle payments, apps handle navigation, and the physical infrastructure is designed to minimize the need for human contact. It’s efficient, clean, and just really cool.

In Vietnam, the infrastructure almost forces you to connect. Nothing is fully automated. Everything requires negotiation, conversation, a smile and a nod - it’s messy. It’s inefficient by lack of design. And it’s incredibly human.

I’m not saying one is better than the other - that’s too simple, and frankly, kind of reductive. But I do find myself wondering what we optimize away when we make things frictionless. What do we gain, and what do we lose? Japan’s systems are a marvel, but they also create a world where you can be surrounded by millions of people and have a difficult time connecting with them. Vietnam’s chaos forces connection, for better or worse.

Or maybe I’m taking huge leaps in judgement based on a few weeks in countries where I didn’t speak the language and barely knew anyone.

It was a good trip. We had a great time, even if traveling with an infant is a whole thing. We’ve been unable to do many fine dining establishments because of the kiddo, and honestly? We felt much more comfortable and relaxed eating at a regional equivalent of Denny’s. It’s nice not to feel too bad when your baby starts happily throwing food around.

Maybe next time we bring parents along. Outsourcing some of the infant-wrangling sounds appealing.

Here’s an article from The College Fix from June 20, 2025: Computer engineering grads face double the unemployment rate of art history majors. In the article, the author claims:

The stats show art history majors have a 3 percent unemployment rate while computer engineering grads have a 7.5 percent unemployment rate. Computer science grads are in a similar boat, with a 6.1 percent rate.

Ok, let’s find if this lines up with what NY Fed says:

Oh, what’s that number next to “unemployment”? Uh-oh. Underemployment accounts for people working in a job which does not require a bachelor degree. This means that a computer engineering graduate is working a tech job, while an art history major takes up work in a fast food restaurant. And all of a sudden, the picture shifts. 17% of computer engineering majors were underemployed, while a whopping 46.9% of art history graduates weren’t utilizing their degree.

This article is one of many, which cherry-picked data from the NY Fed and made outrageous claims. Further, the data is from 2023, which the article above mentions near the end, in passing. That’s a pretty relevant bit, for an article written in 2025, isn’t it?

For me this brought up a question of digital hygiene and how the headlines I see affect us.

I have seen this headline many times throughout the year - I never read through content, but over time the headline stayed in my memory.

The illusory truth effect is the cognitive bias where repeated exposure to a statement makes it seem more truthful, even if it’s known to be false.

I really did believe that CS graduates had lower employment than art history majors. Don’t get me wrong, the job market for newgrads is oh-so-brutal, and the future prospects are murky. Which probably made it easier to believe such an outrageous claim.

Yes, disproving the headline took all of 10 seconds, but how many headlines do you see a day? What other misinformation cements itself in your head?

And ultimately, is it better to limit access to such information, or - however impractical - try to verify everything you see?

I’ll follow-up in six month to year to see if that’s just a gimmick purchase. Or maybe I end up drafting up my next book using this thing - we’ll just have to see.

Well, it was a gimmick. It’s a great keyboard, and I’m sure niche use cases will come up here and there, but… yeah, a gimmick. There I was, on our family trip to Japan and Vietnam, excited about all the writing I might do from a hotel room, or maybe in a coffee shop, or even on the long flight.

But here’s the thing, we travel with an infant. Yeah, that’s an important part I kind of glanced over. There really isn’t that much free time to write when you either entertain, feed, or sleep the little potato, and when you’re not doing that - you just want to lay down, or maybe talk to your partner because you two haven’t had uninterrupted conversation in months.

But even beyond that, I massively overestimated my own desire to write when I’m on vacation. I love writing, and it did find a few occasions to plop open the device and jot down some notes, but ultimately writing is work. Rewarding work I enjoy, but it’s still work. I don’t like to work on vacation. I like to chill.

With hindsight, as I’m reading the excited mini-review for my little ProtoARC XK04, I can clearly see how naive I was, and how I fell for the idea that all I need is a sleek little keyboard, and I’ll write more! I will be oh-so productive!

My partner and I often talk about the barrier to doing things (tm) and how it interacts with the stuff you buy.

I don’t really need a fancy pair of running shoes to start running. And I don’t need a fancy notebook or a nice keyboard to write. Yes, it’ll probably get me excited to get into the hobby, but this type of excitement passes quickly.

A few years back - half a decade or so - I lived a little too far from work to bike. A little too close to justify driving. My wife and I decided we’ll get me an ebike, ebikes aren’t cheap, or at least they weren’t back then. We got one, and it was exactly what I needed: a little more power to make my hilly 30 minute commute by bike a no-brainer. I biked 5 days a week, and I did so for years until we moved.

Maybe that’s why it’s so hard to tell when something is the right tool for the job, or ultimately just a gimmick and a waste of money. Companies have gotten very good at selling you a belief in a version of yourself - you don’t buy an item, you think about who you will become (with a help of said item). I think of myself as somewhat frugal and prudent with money, but this just comes to show how easy it is to fall into that trap.

So yeah, I didn’t write more because I bought a little keyboard. But I am writing more (twice a week for nearly a year now) because I made a commitment, because I enjoy the creative process, and because it makes me feel good.

My daughter was born, and she’s pretty cool. Adjusting to life with an infant wasn’t easy, but we took on the challenge gladly - we lost our firstborn, and we’re grateful for every inconvenience or a sleepless night. But yeah, life won’t ever be the same.

I took a lot of time off work to be with my kiddo, which was great for my mental health. This is the longest I haven’t worked in my adult life, and believe it or not - not working is nice, and I’m hoping I’ve been trying to keep this optimistically detached attitude as I got back to work throughout the year - with mixed success, but it’s nice to know what the north star feels like.

The space to not work opened up room for other things. I got pulled into writing - a lot more than before. This year I published far north of 100,000 words across this and my gaming blog - publishing weekly across both outlets. That’s a thick novel worth of words, and while not everything I wrote was great, I enjoyed having to come up with new topics, having to get my thoughts out on paper, and getting to experiment with various voices as a writer. 4 of my articles got boosted on Medium this year (which I thought was pretty cool), and I had some incredible conversations with folks in email and comment chains. I especially enjoyed jotting down decades worth of unfinished thoughts about games - gaming is a hobby I deeply enjoy.

We’ve done a few international trips - namely to Japan and Vietnam, and enjoyed both. Traveling with an infant was fun and weird, and I’m excited for even more travel next year. I also got to enjoy building different relationships with my parents and my in-laws, since we now primarily engage with them from the lens of having a kid. It’s fun, it’s frustrating, it’s novel.

All of this - alongside many conversations with family and friends - really brought on a philosophical shift. More appreciation for the impermanence of things. Life won’t be simpler than it is today, things will only get more complicated. And that’s fine. I get to appreciate the way life was before, and I get to enjoy the way life is now. More complicated, more messy, much more full of life.