DEV Community: Mike

Family Leave

Mike — Tue, 07 Jul 2026 23:37:52 +0000

Two New Additions

On 4/24/2026 my wife and I welcomed our twins, Clyde and Clara, and the day before that I started my paternity leave. Outside generously provides twelve weeks of paid leave, and during it there’s nothing I’d rather be doing than spending time with my family. Building bonds and routines, and watching my two children’s personalities begin to show, has been incredible.

The reality of a leave this long means that the return date looms close by and the tectonic shifts since taking off are a concern that clouds each week.

Extended time off means that while I was able to prepare a Q2 plan and the beginnings of a Q3 plan, I wouldn’t be there to see through Q2 or adapt Q3 to the reality of what we achieved in Q2. The scope of my role will likely be forever changed as colleagues forge new processes and relationships. I’ve been there since 2021 and risen up through multiple promotions. I look forward to talking to my coworkers as ever, but I know I’ll feel less ’needed’ and that will sting at first.

Missing out

Part of stepping away is the quiet fear of falling behind. The industry moves fast. The obvious thing I’ve missed out on is three months of development around LLM usage at work. Day to day, I think the momentum is still going in the same direction. LLM and agentic development has proven itself for developers. However, I’ve been anticipating more interest in lower-cost tooling and per-token models that keep their interfaces low-friction, especially since organizations were just hit with the reality of token-based enterprise costs and the newly discovered possibility of government restrictions on frontier models. Despite this, I don’t see most of those engineers ever going back to ‘hand-coding’.

In my experience, these three months are also where the year really begins. Ideas get in motion and start to blossom further. This aligns with our users’ patterns too. In the cadence of the year at Outside, the summer is one of the peak seasons. People are going outside, reading to be inspired, researching trail conditions, and tracking their routes to look back and reminisce. Projects are being ideated for the next few quarters, and while a strategy was laid out before my leave, the expectation is that reality led to pivots - ones I’ll only learn about once I return.

It’s a cliché that trust while delegating is one of the most challenging parts of delegation, but it consistently remains true. You surround yourself with an excellent team you trust, you agree upon a plan, and yet execution is still a skill folks ascribe to successful companies for a reason. It doesn’t come for free.

What to return to

When you’re hired to a role, the hiring manager has an idea of the problems you’re there to solve and the team you’re there to manage. I took a twelve-week leave doing that job along with the role creep that comes with promotions along the way. As tends to be the case, I was doing the work required of me by the job description, plus the work I thought I was uniquely capable of executing on.

For instance, I historically took it upon myself to get the most out of developer tooling, since it’s complementary to DevOps, and to focus on operational efficiencies like bringing many teams (and many more brands) onto shared services such as payments and identity - which is critical to maintaining a platform (vs a series of businesses under one roof). Those initiatives were delegated while I was away - either to engineers on my team or to IT - and the business hasn’t come crashing down as a result.

Aside: isn’t that always the case? You feel crucial until you’re gone, and then you realize people move on. You’ve probably done a better job of ‘working yourself out of a job’ than you give yourself credit for - which means you should probably scale up to bigger and better problems.

How to design it

So to wrap this up, what are my next steps?

Determine what I must do. What’s my job description?
Determine what I want to do. What fills my cup each day to allow me to keep doing the hard things?
Determine what I will stop doing. This was delegated but doesn’t go away. Someone is waiting to hand this back off to me.

Leave handed me a rare reset. I’m excited to come back thoughtfully.

Bringing the blog home

Mike — Fri, 05 Jun 2026 00:00:00 +0000

For years my writing lived on Medium. It’s a fine place to read, but the work — and the SEO that comes with it — belonged to someone else’s domain. So I’ve brought the blog home.

From now on, posts are written in Markdown and published here first, at mikerenoe.com/blog. Everything is generated by Hugo and deployed alongside the rest of the site on Vercel, so the blog shares the same look and feel you’re seeing right now.

There’s an RSS feed too. When I cross-post to Medium or dev.to, those copies point their canonical URL back here — so this page stays the original, and the search-engine credit stays with the site.

More soon.

What’s in my Inbox?

Mike — Wed, 05 Jun 2019 00:00:00 +0000

Note: I originally wrote this post in 2019. Some of the newsletters below have since gone quiet or shut down, so treat this as a snapshot of what I was reading at the time rather than a current list.

Photo by Brodie Vissers from Burst

Email newsletters have been a relatively recent addition to my morning routines but they’re something I value as highly as my favorite podcasts in some cases. Newsletters and especially newsletters via email are by no means new but I think services like The Skimm have certainly popularized the brief curated medium. We’re surrounded by an abundance of information each and every day, selected a source who’s dedicated to bringing you a slice of news from a segment of your interest has greatly improved the quality of my media diet.

I’m making this list in the hope that someone will find in valuable, a lot of these newsletters I found via word of mouth or following the curator. Substack offers some lists of newsletters but there’s not a suggestion platform yet for newsletters like podcasts or books. These curators put their time and energy into these emails and rely on word of mouth. I’m gaining nothing by sharing these (except for referral credits from Finimize at the bottom) aside from the hope that the creator continues maintaining them well into the future. This is my thanks to them.

Reply All Newsletter

https://gimletmedia.com/shows/reply-all

How often? Weekly

What’s in it? Recommendations from around the Gimlet Media office.

Why I love it: The Gimlet staff has great taste on the whole and if you’re a fan of the podcast you’ll like this. From it I’ve started listening to Clairo, watched a LOT of weird YouTube videos, and even received new recipes!

Last Issue: Read here!

Subscribe: Here!

A Woman to Know

(image via Wikimedia*)*

How often? Every weekday

What’s in it? A quick summary of a notable woman in history, her accomplishments, and lots of links for further reading.

Why I love it: Lots of women through history didn’t achieve the publicity level of the men surrounding them for many reasons. This newsletter serves to supplement our knowledge of historical figures and improve the visibility of women and their achievements over time.

Last Issue: Read here!

Subscribe: Here!

What’s the Difference Between…

How often? Weekly

What’s in it? Brette Warshaw clearly and succinctly explaining the difference between terms that might seem similar or are similar but are actually different. Described by Brette herself as: “A newsletter for the curious & confused.”

Why I love it: I love etymology and word history. Often the newsletters break down the history of a term and how subcategories develop from that original topic. I’m mostly thinking about this issue, CRUDO, SASHIMI, TARTARE, AND CARPACCIO? but they’re all great and along that same line.

Last Issue: Read Here!

Subscribe: Here!

Perf.email

How Often? Weekly

What’s in it? Curated list of links and blurbs by Calibre related to web performance and accessibility.

Why I love it: Web Accesibility means creating websites and web apps that can be easily and clearly accessed by everyone. Issue 23 in particular featured this blog discussing how JPEGs are displayed, encoded and broken down as well as a talk by Tatiana Mac on how Privilege Defines Performance.

Last Issue: Read Here!

Subscribe: Here!

Now I Know

http://nowiknow.com/

How Often? Every Weekday

What’s in it? Stories, trivia, and lesser known facts from around the world. Every Friday also features a ‘Weekender’ with long-reads and puzzles to hold readers curiosity til the coming Monday.

Why I love it: Dan’s stories are exactly the kind of trivia I love to read that tends to stick with me throughout the day. Last issue in particular featured a story about a soccer goalie who was so dedicated that when the game was called on account of fog and poor visibility, he remained on the pitch until the police came to find him after the team had showered and packed up. He just thought his team was holding the other to their own goal!

Last Issue: Read Here!

Subscribe: Here!

A11y Weekly

How Often? Weekly

What’s in it? Curated list of links to blogs, articles and tutorials related to web accessibility, web design and building a more inclusive web.

Why I love it: I subscribe to two newsletters on Web Accessibility because it is a relatively new topic for me to delve deeply into. It’s always been a concern but I wasn’t aware how much more I could be doing until I started seeking out resources like this. This curated list is getting me up to speed with accessibility with tons of tutorials and well written blog posts.

Last Issue: Read Here!

Subscribe: Here!

The Monday Medley

How Often? Weekly

What’s in it? A collection of thoughts and links from Nat Eliason from the previous week.

Why I love it: Nat is a great resource for information on growth, marketing, and growing a small business. Nat’s marketing know how was my original reason for subscribing. Digital marketing was something I was learning on the job but wanted to start getting a leg up.

Since that original impetus, it’s moved into just seeing what someone else finds on the web in a given week. There’s often a topic or two I would disagree on if we met in person and with his accompanying viewpoint on a link I’ve been able to hear an opinion I might not have heard in my day-to-day communications. I always walk away thinking about something that wasn’t on my mind previously.

Last Issue: Read Here!

Subscribe: Here!

Rendezvous with Cassidoo

How Often? Weekly

What’s in it? A weekly roundup of links relating to the web, a few words, a joke and a quick programming challenge.

Why I love it: Front end web design is constantly moving, changing and growing more opinionated, this newsletter focuses the fire-hose of information into a steady stream. Additionally, front end web design is another blind spot for me, I’ve always been more comfortable with back end engineering at the expense of digging into the front end. Newsletters like this one pull back the curtain for me to jump into CSS, JS and the design process.

I also really enjoy the ‘interview question of the week’, when I have the time available I always try to solve it as a fun puzzle.

Last Issue: Read Here!

Subscribe: Here!

There’s a few others listed below that I don’t read as often but might be interesting to readers here:

Mozilla’s Developer Newsletter — Quick set of links and blurbs about where the web is going.
99% Invisible Newsletter — From the team that brings you your favorite podcast. Accompanying articles for new episodes as well as stories too small for podcasts.
The Good News Email — The best positive news to your inbox, once a week because sometimes we focus too much on the worst.
Brain Pickings — One of the original ones that I’m aware of. Carefully and artfully curated selection of the best works of fiction, art, or anything that can lead to a more beautiful life.
Finimize — Daily and weekly roundup of business, financial, and money news.

Learning Go by writing a TCP Server

Mike — Tue, 30 Apr 2019 00:00:00 +0000

Takeout Central had a problem. We were running a TCP Server and a UDP Server. Both were written in Perl. Neither was taking advantage of concurrency. At the same time, our team of Delivery Heroes became frustrated while beta testing an IoT device in the field. Information sent to the ten beta test devices took an hour or more to update, which we found to be an unacceptable amount of time.

Enter Go. I’d used Go in the past. It was my language of choice for Advent Of Code 2017. As I kept up with the five days of challenges, I found that writing in Go was a breeze. After that, I kept an eye out for a problem that called for a robust systems language. Here was the opening.

Go uses concurrency rather than parallelism. While the differences between concurrency and parallelism are slight to most, co-designer of the Go programming language Rob Pike explains it like this: “Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.”*

First, I wanted to know how concurrency functioned in Go. It was so straightforward that even beginner tutorials discussed it relatively early. Next, I needed to know how to implement concurrency in a server environment. After a few more minutes of googling, I found the scaffold for the TCP server. I learned how Go handles socket communications on this blog, which also explains how these can all be leveraged using goroutines. The go keyword before handleRequest does all of the work for concurrency, because each function called with a preceding go starts a new concurrent process. Getting the server off the ground was easy, because all it entailed was prefacing a function call with “go”.

//Taken from https://coderwall.com/p/wohavg/creating-a-simple-tcp-server-in-go
package main

import (
 "fmt"
 "net"
 "os"
)

const (
 CONN_HOST = "localhost"
 CONN_PORT = "3333"
 CONN_TYPE = "tcp"
)

func main() {
 // Listen for incoming connections.
 l, err := net.Listen(CONN_TYPE, CONN_HOST+":"+CONN_PORT)
 if err != nil {
 fmt.Println("Error listening:", err.Error())
 os.Exit(1)
 }
 // Close the listener when the application closes.
 defer l.Close()
 fmt.Println("Listening on " + CONN_HOST + ":" + CONN_PORT)
 for {
 // Listen for an incoming connection.
 conn, err := l.Accept()
 if err != nil {
 fmt.Println("Error accepting: ", err.Error())
 os.Exit(1)
 }
 // Handle connections in a new goroutine.
 go handleRequest(conn)
 }
}

// Handles incoming requests.
func handleRequest(conn net.Conn) {
 // Make a buffer to hold incoming data.
 buf := make([]byte, 1024)
 // Read the incoming connection into the buffer.
 reqLen, err := conn.Read(buf)
 if err != nil {
 fmt.Println("Error reading:", err.Error())
 }
 // Send a response back to person contacting us.
 conn.Write([]byte("Message received."))
 // Close the connection when you're done with it.
 conn.Close()
}

I’d become comfortable with concurrency and goroutines, so I turned my attention back to the problem at Takeout Central. To replace the old system that was slowing us down without losing any functionality, we needed the new TCP server to:

Concurrently handle each Device-to-Server TCP connection using goroutines
Respond to valid requests with a JSON packet
Log requests, failures, updated states
Update a MySQL database accordingly

JSON

Because our devices sent requests and expected responses in JSON, it was my next topic of interest. The json package Marshal function does the work producing the JSON string and it’s documentation lays out the possible inputs.

I chose to use an exported struct. It offered clearly-defined messages, meaning the struct was also self-documenting. I prefer to use explicit key names whenever possible, which is why I also utilized the ‘json’ tag in cases where a device’s expected key did not conform to Go’s style.

type errorMessage struct {
        Error string `json:"error"`
    }

This struct is populated using the explicit assignment seen below where the variable message is a string containing a user defined error message. The resulting struct is Marshaled into a byte slice to be returned by our connection handler.

ourErrorMessage := errorMessage{Error: message}
errorMessageAsJSON, err := json.Marshal(newMsg)

On the flip side, requests need to be validated by the Unmarshal function. Given the errorMessage struct above we can put together the pieces to get an error message from the client using the code below. If invalid JSON is passed, the Unmarshal function will pass an error for our server to log. This validates that messages are at least using valid JSON.

The standard Unmarshal function omits fields that don’t exist in your struct definition by default. Here at Takeout Central on this project specifically we’re working with standard messages with very little variance between them. If that’s not the case for your application, you might want to look into handling unexpected messages using a different interface than a struct.

//given a JSON String
var errorRequest errorMessage 
request := "{\"error\": \"Unknown Error Occurred\"}"
err := json.Unmarshal([]byte(request), &errorRequest)
if err != nil{
 //handle error
}
errorMessage = errorRequest.Error

Logging

For logging, Go provides the log package. We start here by initializing a pointer to Logger in main using Log.new. Using this pointer and dependency injection we pass this along to the handleConnection function and furthermore into our subsequent log helper functions.

f, err := os.OpenFile("/your/log/file", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
if err != nil {
 log.Fatalf("error opening file: %v", err)
}
defer f.Close()
logger := log.New(f, "", 0)

For the formatting I prefer something along the lines of 2019–04–25 21:26:17 [error], and so our log functions look like this:

func logError(l *log.Logger, msg string) {
    l.SetPrefix(time.Now().Format("2006-01-02 15:04:05") + " [error] ")
    l.Print(msg)
}

It’s important to note here that when using dependency injection on concurrent functions the objects you’re passing need to be thread-safe. This is necessary to avoid race conditions as well as ensuring one of the many concurrent processes don’t fail because it’s attempting to modify our log file while it’s in use. Luckily for us, the documentation for Logger spells that out explicitly.

If one thing has come through thus far, I hope it’s how straightforward and ‘batteries-included’ Go is for these tasks in particular. Up until now and in fact, excluding the MySQL drivers I’m about to delve into, everything in our server is powered by the Go packages from the core team.

MySQL

Go doesn’t implement each database in their own core libraries, it’s been left as a challenge to the users or the reader. They do provide the sql package as an interface and a comprehensive list of drivers for your ease. I went with go-sql-driver as it best fit my projects needs.

go-sql-driver and Go sql follow standard patterns if you’ve worked with MySQL before. Starting with a pointer to the DB(database) object we use it like Logger before as this is also designed to be threadsafe as you might expect.

For our use-case, we’re monitoring and updating devices one at a time. This means there’s very few cases where we have to fetch more than one row from the database, meaning our requests and data grabs tend to look like the code below. Like log our database pointer is initialized in main and passed to each handleConnection goroutine.

The variables you see that aren’t initialized in view: dbh, our database pointer; log, pointer to our log object; errors which is a package Go provides to handle passing errors between functions.

var foo, baz int
err := dbh.QueryRow("SELECT foo, baz FROM devices WHERE id=? LIMIT 1", ID).
 Scan(&foo, &baz)
if err != nil {
 logError(log, "No devices with ID: "+ID)
 return nil, errors.New("No devices with ID:" + ICCID)
}

Wrapping it all together

This was one of the most enjoyable projects I’ve worked on recently and I owe it largely to Go’s internal packages and tools. In particular, goroutines as a thread abstraction. Having worked with threads manually in the past I fully appreciate just how much heavy lifting they do. The simple ‘go’ keyword provided a smooth abstraction that is less prone to error and automatically efficiently schedules threads. If you’re implementing this yourself, please keep in mind other aspects of a production server like malicious attackers and prepare accordingly. With that in mind though, this is a great TCP server app for a few IoT devices connecting to a central server; I hope it serves you well.

The Problem With Bike Registration

Mike — Sat, 02 Mar 2019 00:00:00 +0000

This blog is an expanded version of a letter that I sent to my NC State Rep Verla Insko

This week the NC State Representative from Wilkes County, Jeffery Elmore, proposed H157, a bike registration bill. If passed, cyclists riding on any NC state road will be required to pay $10/year for a registration card and plate for their bicycle and failure to do so can result in a fine up to $25. As a bike lover and cyclist, I’m vehemently opposed to this bill. In its current state, it discourages recreational cycling statewide and places a heavy burden on the lowest income populations.

Cycling means a lot to me. I learned the roads of my community on a bike, earned my first paycheck delivering papers by bike, and made friends who also rode bikes. It was my only means of transport through college; I didn’t buy a car until graduation week. Biking was how I got groceries, visited friends, and eventually how I rode across the country advocating for affordable housing with Bike & Build. For some, like myself, it’s a path to self-actualization and autonomy but for others, it’s how they stay active and healthy.

You might be reading this and thinking $10/year is a small cost, who cares? I completely understand. For us, this is a new hoop to jump through, an added barrier between the occasional bike commute or workout. This could become a subconscious justification for not riding today. It’s telling yourself you’ll bike to work tomorrow or it’s the reason you can’t ride bikes with your kids today. However, if you do choose to ride your bike despite the known consequence, you’re now at risk of paying 2.5 times the original price on top of the future registration. Does $35 sound right for a stroll down the road? Consider now the people for whom $10, $25, and $35 is everything. It’s all that’s leftover after a paycheck or all that they can save after a couple of weeks. For every person who’s making the choice to ride their bike rather than a car or for the fun of it, there are those who have no other option.

Outside of major metropolitan areas even simple tasks like grocery shopping are substantially more difficult and time consuming on public transit or walking. For those folks who don’t own a car and are healthy enough to ride one, a bike is the only realistic option for commuting and errands. The ubiquity of bikes makes them accessible to most people regardless of their socioeconomic status. Whether from thrift stores, non-profits, or even a friend with a beat up bike, a bike is a sturdy machine designed for heavy use. These are the cyclists, however, who will be most harmed by the otherwise low-cost registration as well as the punitive fine. This fine is comparable to overdraft fees as it targets similar socioeconomic statuses and has a similar charge. As such, Americans, in total, paid $34 Billion in 2017 (https://www.marketwatch.com/story/overdraft-fees-havent-been-this-bad-since-the-great-recession-2018-03-27) with only an average of $20 for each fee. Even that is less than the exorbitant fine for not having a registration plate on your bike. Imagine how this could add up over a year for a person.

Offenders will rarely just pay the $25. The $25 fine is currently listed as an infraction in the bill, this means it comes with additional court fees to pay on top of the previous amount. (https://www.nccourts.gov/help-topics/fees-and-payments/court-costs#criminal-and-infraction-costs-including-traffic-tickets-5430) These additional costs add up over time and don’t include the career cost of attending court during the workweek. Riding your bike to work or to get groceries will carry with it the impending threat of swiping a debit card with a precariously low balance. These folks don’t need another bill or threat of debt over their head while they ride to work.

Bike registration isn’t a new idea. Since I started riding on the road, I’ve encountered drivers who feel like I don’t belong because I’m not buying into the care of it. This claim has been debunked and addressed many times over. (https://www.bicycling.com/training/a20042771/the-best-responses-to-anti-cyclist-claims/) My arguments here aren’t comprehensive of all the reasons why bike registration is the wrong move but it’s impact on people is the most important to me. Don’t keep me from riding my bike a couple of times a week and don’t place another barrier between those without a car and getting to work on time.