George Rodier's Blog

Website Refresh 2026

George Rodier — Sun, 08 Feb 2026 00:00:00 GMT

If you have a personal website, I’ll usually be the first person to tell you not to waste your time consistently redesigning. You’re much better off producing content for the website or working on projects that actually interest you. Pushing pixels without a purpose is almost always a distraction.

Now there are exceptions to that rule. Lynn Fisher and her yearly redesigns are at the top of that list. Or maybe you want to try the latest and greatest CSS property and need a site to experiment on. Or maybe for you having something to continue to iterate on brings you joy. So maybe there are a lot of good reasons…

But for the most part, what you have is probably good enough. And it’s advice I remind myself often.

So it should come as no surprise that I disregarded my own advice and redesigned my website.

The previous version of my site lasted for almost exactly 2 years. At the time I created it, I used a heavily modified template. It looked pretty professional, but lacked character. I think it was a great approach to be get something up quickly and then focus on content (which I was kinda meh about).

But now the year is 2026 and things have changed. It’s easy to create something with AI that lacks personality. Too many of the web water holes silo your interactions and your data is not really your data (hoping ATProto changes that). But we can fight back against the enshittification of the web and personal sites are our weapons.

So yeah I got the itch.

Now just because I got wrapped up in the excitement, didn’t mean I was looking to redo my site right away either. It wasn’t until I had an idea for a design that I couldn’t get out of my head that made we want to go all in on it. And I got that idea when exploring the very early iterations of blento.app.

Blento is a super cool idea that allows you to create “your own corner of the web” built on ATProto with customizable bento box style layout. It’s like a customizable new age MySpace. But it’s the bento-style layout that caught my attention.

One of the problems I’ve had with creating a personal site, is I never knew what I wanted it to be. As a developer, I thought it should be a portfolio site that showed off some of my skills. But then I thought, I also enjoy cooking, what if I shared some recipes too. Does that make sense on my portfolio site? Should it be on a separate site that I link to? What’s the best way to surface the various content that I might want to talk about?

But all those things are me. And thus they should be on a personal site. The bento style unlocked the idea of having a “hub” of me where i can link off to the various things that help make me “me”.

One of the opportunities this homepage hub offers is the ability to continually iterate on the site with new ideas without being pigeon-holed into one particular corner. Outside of blocks I currently have, some of the others I considered included a GitHub contribution chart, resume, current weather, a block with a fun/interesting/inspiring quote, food recipes, bookmarks or interesting articles that I want to highlight and share, contact, and latest social post. And if I ever have a lack of items to work on, I can always dip into this backlog of block ideas to implement.

With a bento-style layout decided on, the next thing I needed was a design. To keep with the personal trend, I wanted it to feel less professional and corporate, and more human. Lots of colors was a must. And maybe it’s because I have two super young kids and was on paternity leave as I started working on the site, but I decided to tap into the nostalgia of my youth.

The colors of the bento boxes were meant to invoke dodgeballs on a playground. And to really emphasize that point, I created a background for each block that has a dodgeball-like texture. The background color on the entire page was meant to invoke a well played with baseball that had lost it white lust and picked up dirt from the infield. Finally, I created a subtle hover effect that makes it look like the cards are haphazardly being picked up.

Now since I’m not a designer, and thus don’t know how to use Figma, Sketch, Photoshop, or whatever your design tool of choice is, I stuck with what I knew best html and css. Honestly, this was super helpful approach that allowed me to subtly adjust colors and contrast and different ideas quickly until I was able to settle on something I liked (or disregard). And don’t let anyone tell you it’s not a valid approach to designing - it most certainly is!

In fact, that design ethos carried out to the rest of the project as well. My favicon was designed with css using the same background and colors as my bento square, screenshotted, background removed with Mac’s Preview app, and then size adjusted. Likewise, my social cards (following an approach similar to Emma Goto and Cassidy Williams) are also entirely CSS with a script to automate screenshot and creation.

So now that I have a new website in place, the next steps are to write more, build more, and share more. And not because I have to, but because building community and participating with like-minded individuals brings me a ton of joy. To that end, I’ve included both an rss feed and a newsletter where you can keep up to date and follow along on my journey.

And I encourage you to participate too! One of the coolest things I’ve seen recently is the proliferation of new sites being shared on personalsit.es (including mine) and elsewhere on the internet. Much of this is a desire to reclaim a little personal space in the large net of the web. And you can be part of this movement too. Be original. Be intentional. Bring joy.

Overcoming Goodhart's Law

George Rodier — Thu, 17 Apr 2025 00:00:00 GMT

Imagine this scenario: you’ve recently been getting a high number of complaints about defects in your application. Customer satisfaction scores are tanking. Someone notices that test code coverage is around 40%. A mandate is put in place to raise code coverage to over 80%. Surely that must fix the problem!

A month of hard work later, and your code coverage is up. But the defects? Still there. Customer satisfaction? In a death spiral. What gives?!?

Congratulations, you’ve just discovered Goodhart’s Law. Luckily, there’s still hope for you, but let’s take a look at what just happened first.

Goodhart’s Law states, “When a measure becomes a target, it ceases to be a good measure”. As soon as we turned the code coverage percentage into the target, we lost sight of the real goal: reducing defects and improving customer satisfaction. Instead, we incentivized developers to maximize coverage (perhaps at all costs).

Code coverage is a flawed metric. It tells us “what you definitely haven’t tested, not what you have”. There’s the potential for developers to write code that covers every line without covering every branch. Even more common, in my experience, is testing flawed, already written code without considering the actual test cases. The goal of tests is to give us confidence in the code we’re writing. This doesn’t mean code coverage is bad. Generally, better code coverage is a positive sign. But on its own, without additional context, it doesn’t definitively tell us anything about the quality of our code.

But this isn’t an article about code coverage. It’s about Goodhart’s Law. And Goodhart’s Law extends to any metric that could become a target. For example, it’s possible to create a web page that gets a 100 on a Lighthouse performance score without being performant. Likewise, you could create another page that gets a 100 accessibility score while being completely inaccessible. We can’t just set targets without having the conversation about the goals we’re trying to achieve.

Now, some of you might be thinking that maybe we just chose the wrong metric. Clearly a performant, accessible site with great code coverage is to help improve customer satisfaction. Right? Maybe…

You then spend months doing everything to improve customer satisfaction. And you succeed. In fact, you exceeded your target and are super excited to let your boss know! Except, instead of receiving the expected praise when you have the conversation, you’re given a pink slip. You gave away too much for free (much to the customer’s satisfaction), revenue plummeted, and the company is on the verge of going out of business. Oops!

Metrics don’t live in isolation. Putting in the effort in service of one metric could degrade another. So you get clever and pick two targets as the priority to track together. But then an unexpected third metric suffers. So you track that with your other priority items, too. Soon enough, everything’s a target, everything’s a priority, and thus nothing is a priority and nothing gets done.

Gwrarrr this is frustrating! I bet you’re about ready to give up on targets and trying to improve your metrics. I wouldn’t blame you either. However, there is a better way. I know of a target metric that you can start using today!

Want to know more? Great! Go ahead and look up your current code coverage. And while you’re at it, maybe your performance and accessibility scores. Or maybe your customer net promoter score. Or revenue. Whatever metric you might want to potentially set a target to improve, look it up and see what the value of that metric is today.

Have it? Awesome. So your new target is now anything better than that. That’s right, we’re not setting an arbitrary target. Instead, we are establishing a benchmark with a directional target of always improving (however iterative that may be) and never going in the opposite direction.

The always improving part seems obvious, but I really want to stress the never going in the opposite direction portion. Doing so is how you introduce tech debt into your systems, diminish the quality of your software, and move further away from the goals that are important to you and your team. In fact, if possible, put an alert or check your key benchmark metrics as part of a continuous integration pipeline. If they are moving in the wrong direction, that needs to be addressed right away.

Now, addressing metrics that are worse than your benchmark doesn’t necessarily mean removing the code or process that may have caused the degradation. That may be the right solution. Having something slightly worse in one area could greatly improve something in a different area. But determining which is the right area to focus on is a human activity. It takes understanding your current metrics, having conversations, creating metric “budgets”, and understanding the impact of what you’re doing.

And that’s the most important part of this exercise — having human conversations and providing context to what we’re doing. Did we add the right test to help catch that tricky bug we were encountering? Is it ok to add that new image if it slightly increases our largest contentful paint but greatly increases our conversions? Identify what metrics are important to your team, be agile in changing what metrics you want to follow, iterate towards always improving, and have human conversations based on your data to set the right context.

Practical Advice on Advice

George Rodier — Wed, 02 Apr 2025 00:00:00 GMT

If you click a button online, you can’t help but stumble into someone trying to give advice. Commenters on Reddit and Hacker News are anxiously waiting for the moment to drop a new best practice you need to follow. Even more helpful friends on social media won’t mind sharing a tip every now and then. But with any advice, you need to be careful.

Advice, especially of the unwarranted kind, usually (but not always) falls into one of two camps: either someone is trying to sell you something, or they’re giving advice that really means “here’s what worked for me.” That doesn’t mean advice from someone selling something or sharing personal experience won’t work for you—but you need to be cautious. Otherwise, you might run with something and waste a ton of time following bad advice. So how can you deal with advice that’s given to you?

Generally, there are three guidelines I like to follow:

Understand the problem you’re trying to solve
Understand the context of the advice being given
Be agile with applying any advice

First, it’s important to understand the problem you’re attempting to solve. If you don’t have a problem or aren’t actively seeking advice, any advice you’re given is unwarranted and should be dismissed. In these situations, someone is giving you advice without any understanding of your context, and they have no way of knowing whether their input is helpful or not. In fact, most people providing advice in this context are doing so in a self-serving manner. They could be trying to sell you a product or selling you their own good feels. But if you don’t have a problem, you DO NOT have time for this.

If you do have a problem that needs solving, make sure you understand the context of your own situation before seeking advice. Otherwise, you’ll never know whether the advice actually applies to what you’re trying to solve. This is another great way to waste a lot of time.

In addition to considering your own context, the second point is to understand the context of the person giving the advice. A lot of times, they’ll share something that sounds really smart and they’ll often have proof to back it up. But the unspoken message is, “this is what worked for me in this very particular context.” That doesn’t mean the advice can’t be helpful to you, but it’s worth digging into what that context actually is. Advice without context is a solution to an unknown problem. And there’s no way to know if that solution applies to your situation or not.

Finally, after considering advice, if it’s something you want to apply, be agile in implementing it. Don’t accidentally lock yourself into bad advice. Instead, give it a trial run. See if it works for you. If it does—great! Keep applying it. But if not, be okay with pivoting and trying something new.

If you follow those guidelines, you’ll be better equipped to deal with advice. But you can also use these same principles to decide whether you should give advice. Is the person you’re advising open to it? Do you understand their context? Can you frame your advice with the context in which you might apply it? If you fail to do any of these things, you won’t sound trustworthy. Instead, you’ll come off like an internet reply guy (and everyone hates that person).

So to wrap it up, let’s get meta. Should you follow any of the advice I’ve shared here? First, I’m offering this for anyone who has struggled with knowing whether advice is good or has had issues applying advice and wants to get better at it. For context: I’ve personally fallen prey to bad advice in the past (I assume most have). In my younger developer days, naive little me would get caught up in the tech hype machine and assume everything shared was “best advice.” But as I progressed in my career, I became much more likely to assess the problem first and try to understand why advice might be given. So with that context, apply this advice if it makes sense for you (and please stop if you find it doesn’t work)!

It's Not Enough To Build Great Software that Solves Problems

George Rodier — Thu, 03 Oct 2024 00:00:00 GMT

It’s always been my personal belief that good software developers are always curious and excellent communicators. Great software developers build on those soft skills by identifying problems and delivering reliable, scalable, performant software that solves those problems. But that’s not enough to truly distinguish yourself. Your solution doesn’t provide value unless people are actively using it to solve real problems.

“If a tree falls in a forest and no one is around to hear it, does it make a sound?”

I recently reread Jason Cohen’s article The Code is your Enemy. The context of the article is directed mostly at developers turned founders. But I think there’s valuable information that applies to all software engineers because engineers should be acting more like business owners. That leads to the two missing pieces of why it’s not enough to build great software that solves problems: the problem needs to be tied to business objectives, and the solutions can’t hide in the shadows.

Tinkering away, constantly innovating and iterating, and making small, tiny changes that compound over time is the dream of software builders everywhere. Engineers can probably identify a task that would provide some type of value: a refactoring for better maintainability, a new test, a new function to help provide more information, and maybe a feature gap in the product they are working on. And boy, oh boy, is sitting down at a computer and cracking away at the code on these issues satisfying. But to what end?

A new test or function could help catch a valuable bug, or you might have enough coverage to be confident already. A refactor could help deliver a new feature faster, or it could be mindlessly moving code around. A new feature could be a great boon to feature adoption, or it could be something that customers don’t care about. So, how can you tell if what you’ve decided to work on makes sense or not? You have to start talking to your customers and stakeholders.

Customers and stakeholders (depending on your role, a project stakeholder might be your customer) might come to you with product ideas or features to work on. However, implementing them blindly is a great way to not understand the value of your work. By talking to the customers/stakeholders, you’ll better learn what the goals of the users are, what the business objectives are, and what the real problems to solve are. Maybe their original ask makes perfect sense. Or maybe you’ll find that what they want can be solved in a better way. Either way, you need to start talking.

Ok, so you’ve spent multiple recurring sessions talking to customers and stakeholders. You understand their wants and needs. You’ve identified the problems they want to be solved. You have an ideal solution for them. You go off and implement this solution. You know that it will be super valuable. It’s perfect…

But then, crickets. No one uses it. No one even notices.

It’s not enough to just build something valuable if no one knows about it or how to use it. You need to actively promote what you’ve built. Developers need to be their own marketers—making sure the value of their work is seen, understood, and used. That might mean writing technical documentation that helps people leverage your solution, creating blog posts that explain why your feature solves a key problem, holding office hours to get direct feedback and answer questions, or even speaking at conferences to further accelerate the reach of your work.

By talking to stakeholders and customers, both existing and new, throughout the lifecycle of the project, you deepen your relationship with them. You build trust. And more importantly, you move beyond shipping new code and towards shipping new value. And at the end of the day, that’s a software engineer’s job—build great software that solves problems and delivers realized value for others.

Pragmatic Agility

George Rodier — Mon, 16 Sep 2024 00:00:00 GMT

Something that’s been on my mind is how there are different rules for developing software depending on the context. There are certain practices you might put in place as a small team or individual that wouldn’t adapt well to a larger team. Similarly, there are things you’d probably do differently if you were a startup compared to if you were working on an established product.

On the surface, that’s pretty easy to accept without much push back. But here’s the real kicker, the rules and practices for two different teams working on the same product can be wildly different as well. And not only is that ok, it’s probably the correct approach.

If the goal is to deliver high quality software (and that should always be the goal - even though there’s a lot of wiggle room in that phrase as to what high quality software actually means), each team needs to find their own best practices on how to deliver that software. Just as individuals are unique and thrive in different circumstances and different techniques, teams are also unique. What works for one team won’t necessarily work for another.

Forcing teams to work the same way might anecdotally work by luck or happenstance due to similar cultures, but more often than not might lead to discontent within certain teams. There is a folly in thinking that a healthy culture can be dictated. It needs to be encouraged and earned.

So how can we foster the correct environment? We need to be pragmatic and agile - let’s combine this into a fun term and call it pragmatic agility.

A set of standard operation procedures or practices is a good starting point. It might not be formalized, but most teams could talk about how they produce things and communicate with others. However, those standard operation procedures as a starting point won’t work across every team. Within a team what worked on day one might not work in the future usually due to team attrition and expansion, but also due to the ever changing and growing opinions of individuals.

It’s a managers job to help cultivate those rules and practices within a team. Identify where weaknesses are and try out new rules/practices/procedures/etc to address the weaknesses. But here’s the seemingly obvious but not always followed part: if the new thing isn’t working you can just stop doing it and try something different. You don’t have to wait particularly long to adapt and change either. Prolonging a bad practice to attempt to wait it out will only breed discontent within the development ranks.

As teams continue to work on themselves and develop stronger patterns for delivering better software, they should be doing so independently (as the collection of individuals are different) and thus can result in teams developing different cultures of work. This should be table stakes.

However, there is the acknowledgement that not everyone may be onboard within a larger organization and there are still touch points that you may have no control over being reported up an organizational chain. In this case the team should be viewed as a black box. The implementation details (aka those rules and practices the team develops) don’t need to be known outside that black box as long as they are conforming to the interface (the information needed from each team). Often times a good manager will play the role of the interface and shield the team from the outside. But that too is just another practice that can be tinkered with and iterated on.

In an ideal world, someone overseeing a team of teams acts no differently than a manager would towards individuals. They can first help teams identify if they are meeting goals or not and work with them to help better meet goals. They should be working with managers of teams to explore ways to help teams iterate on their procedures to find the best ones. They need to help architect the API (goals) of the functions (teams) and how the functions (teams) work together, but they shouldn’t be concerned with writing the actual functions themselves (that belongs to the teams). As soon as leaders dictate how things need to be developed, they cease to be leaders and instead become dictators (and no one wants to work in a dictatorship).

I began by calling referring to this as pragmatic agility. The goal is to always work to bettering ourselves, drop practices that prevent us from achieving whatever our optimal success is, continually evaluate what we are currently doing and if it needs change, and try new things and iterate until we are at a spot that leads us to a better outcome. We are pragmatic and we are agile.¹²

A lot of what I’ve described is from working in teams for over a decade and seeing what works and what doesn’t. But I’d be lying if I said I didn’t have outside influences leading to these opinions. First up, is Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Dr. Nicole Forsgren, Jez Humble, and Gene Kim. This is an awesome and well researched book that brings the concept of a Pragmatic Programmer to a team and organization level. ↩
Second, and perhaps with an even greater influence, is a talk I heard from Dave Thomas (one of the authors of The Pragmatic Programmer) at Emerging Tech East this past year. Dave Thomas who helped author the Agile Manifesto famously decried what Agile had become. His talk, Reclaiming Agility, had less to do with the Agile industry and more about what it really means to be agile. Much of which is adapted to some of the approaches I described here. ↩

The Years of Experience Myth

George Rodier — Mon, 08 Apr 2024 00:00:00 GMT

Have you ever come across a job description that you thought you were perfect for? The job description describes work you are interested in and would excel at. You even know some of the teams members and know you’d be a great fit. You go through the requirements and realize that you check off every single thing they are looking for. Except one…

“Years of experience”

Maybe you’ve been performing a job for 5 years, but they are looking for someone with 10 “years of experience”. You have that sinking feeling that you would need to work twice as long as you already have to even be considered. Instant disappointment.

And a job application might not be the only time you encounter this unfortunate situation. Maybe you’ve been told you need more experience for a promotion and thought that meant you needed to wait for some time in the future. Or maybe you compared yourself to another developer and wondered how long until you would be on their level.

Here’s the thing though, “years of experience” is a myth. I’ve intentionally put “years of experience” in quotation marks, because it is only suitable as a measure of time a job was performed. It is not a measure of experience gained over that time. I like the very official sounding definition of experience in the Merriam-Webster Dictionary:

Experience is a direct observation of or participation in events as a basis of knowledge

The definition speaks to encountering problems and interacting with them to increase our knowledge. Having a lot of experience means dealing with a vast set of problems, sometimes repeatedly, and iterating on what we know to come up with better solutions and continually increase our knowledge.

Importantly, in that definition, there was no indication that time was a requirement. “Years of experience” is commonly used, because working for more years increases the likelihood that a person will “observe or participate in more events” and thus gain experience. But there is no guarantee. Imagine, someone working on the same task repeatedly over a long period of time. They will get very good at that task, but that’s all they’ll be good at. They haven’t explored anything else and their experience will be limited as a result.

This isn’t different than lifting weights at a gym. Imagine Gym Goer No.1 picks up a barbell and loads it with the same weight and does the same number of sets and reps each time you go to they gym. They’ll see gains in the beginning and get very good at lifting that weight for that many sets and reps, but they’ll eventually notice they aren’t getting any stronger. Gym Goer No.1 will plateau.

Now imagine Gym Goer No.2 does a progressive overloading program. They slowly increase the number of sets, reps, and weight they do with each workout. They begin to notice that each time they’re getting stronger and stronger. But eventually Gym Goer No.2 realizes to take the next step they’ll need to adjust their diet and the exercises they’re doing. After a year of each gym goer following their routines, it’ll be no surprise to anyone that Gym Goer No.2 will have much more gains. But just as importantly, by trying so many things to get those gains, in the same time period Gym Goer No.2 will have a lot more experience as well.

The fact that experience isn’t tied to time should be liberating. It means we are in control of our experience rather than it being a byproduct of waiting something out. And because we are in control we can seek out new problems, solutions, and ideas as opposed to waiting for them to come to us.

We can accelerate our experience.

The only caveat, is that increasing our experience takes work and an active effort on our part. It does mean carving out time to participate in and observe new events. And that doesn’t happen over night. However, time is only a correlation and not the causation of our experience. You are. So go out and seek ways to increase your knowledge and gain experience!

It Only Gets Better From Here

George Rodier — Sat, 27 Jan 2024 00:00:00 GMT

I’ve been thinking a lot about success in different contexts, what success means, and how to achieve it. One of the most common characteristics I’ve observed amongst “successful” people is showing up and putting in the effort.

Want to become rich? Invest your money in index funds and let them compound over time. Want to get strong in the gym? Show up consistently week in and week out for multiple years and use progressive enhancement. Want to be a better employee? Continually learn and work hard at your craft. The growth you’ll see looking in the rearview will astonish you.

Quick wins are rare. Continual improvement over time always wins out.

I share this, because I feel it is the only appropriate mindset to have when writing a first post. There is a recognition that this isn’t the final product. I have so many ideas that I want to explore and share (technology, writing, building, ambition, motivation, pragmatism, frameworks, cooking, software, and more). By continually showing up and writing, day in and day out over many years, I’ll be able to find my voice, pull at the threads of my writing interests, and hone my craft.

What can you control today? What can you start with right now?

Completing a marathon and running 26.2 miles is a successful accomplishment. But to get the finish line, you need to get to the starting line. And before the starting line is the hard work of training. To train effectively you need an established running base. To establish a running base you need to go on that very first run. And before that very first run you need to put on and lace up your shoes.

A first post is putting on the shoes. It’s a journey. This is the first step. And it only gets better from here.