Charles Villard

The newest trend in design will be words.

Mon, 27 Apr 2026 17:14:42 GMT

A lot of what we're seeing today in the developer space is oriented around the acceleration of value. AI being the trendy topic, it's only natural that corporations want to appear invested, employees want to seem knowledgeable, and investors want to see it supported. I won't bore anyone reading this with a list of examples; throw a stone and you'll hit five. Still, just to summarize, AI seems to be the latest threat used by some people coming for the lunches of engineers, designers, project managers, and, to some extremes, generally other people, in the most haunting way.

Asking an LLM when ChatGPT became mainstream seems trite, but I did, and the answer I got back was 2022. That seems like a short and long time ago at the same time. Short, in that it's only been a few years, but long when it comes to the industry's race to innovate exponentially faster. People can build all kinds of things, in varying capacities of "good" or "bad", cheaper now than ever. Whether that's "good" or "bad" is not why I'm writing this, though.

On the other side of React Miami 2026, I'm thinking back to James Mikrut's Robots Can't Taste and Serge Leon's The Anti-Shiny Object Syndrome, both fantastic talks that share intention as a through line. The former highlights how AI can't have opinions or points of view, and how those are still the responsibility of the user. The latter was a study on one company's findings while growing out their codebase and building lasting tools. One takeaway from both: human input and discretion are key. Maybe that's not saying much, but it's important enough to repeat and remember. The "human in the loop" is more than just a checkbox.

Even so, as we try to design better ways to accept AI into our workflows, it feels to me like there's always a fuzzy border to keep an eye on. Adoption of these tools often foments proliferation of these tools, and that pushes the border closer to human users, leaving us with less to have a say in. Which is why I think we're overlooking what's likely our best design tool.

You're reading them, actually.

In 2013, Mig Reyes wrote a fantastic post that's stuck with me reminding us that design is still about words. I think that's probably more true now more than ever. Websites are simply a medium for us to contextualize our content, and applications are a throughway for us to move that content and context around. AI tools are certainly capable of generating content, but without the human experience, it will only parrot what it thinks we want. We can guide it, but that doesn't replace thought, consideration, care, and detail.

Is it possible it may learn how to accomplish that in time? Yeah, but the funny thing about the human experience is that it's probably the one thing that changes exponentially faster than technical innovation. As long as we don't allow human creativity to be quashed, I can see a world where AI may expedite the technical, but we as humans will drive the experience we want our users to feel, not simply use or see.

Really roundabout way to suggest that you start creating or blogging again, but if you read this far, I must have done something right, huh?

Let's play ball

Thu, 05 Feb 2026 14:54:18 GMT

It's been a few weeks since I start, and these cold snaps need to stop. Warming my fingers up every ten minutes has slowed my coding down so much. It's a stark difference compared to week one on the job.

New job, freshly landed

I would describe Santo Domingo as, at times, ...aggressive. Buildings often felt like they loomed over the bumper-to-bumper traffic and motorcycles would thread through lanes in a semi-calculated dance. Elevated expressways, crowded with vehicles leaving the city, cut through swaths of tightly-packed apartments and businesses, some close enough to step over to from the overpass.

Amongst the throng was the van ferrying me to the second day of my new job: Senior Software Engineer for the Miami Marlins. Along with the rest of the Baseball Systems team, we headed to the Marlins Academy in the Dominican Republic, east of Boca Chica.

Talk about setting a high bar for onboarding.

My claim of week one being a lot was accurate. The idiom "drinking from the firehose" doesn't do it justice. Between learning about our cohort's responsibilities and initiatives, the technology they've deployed, what projects are coming down the pipe, and the Academy's work as part of the Dominican Summer League and the Marlins' recruitment pipeline (did I mention we were in the Dominican Republic, yet?), a firehose feels like a weak comparison. It was more like being dropped in the ocean. Thankfully, my colleagues were and have continued to be plenty supportive, answering my questions and entertaining my curiosities about the game and how the Marlins are trying innovating in the sport. It's going to be a fun year, to be sure.

On top of a fantastic and productive offsite, whether through serendipity, happenstance, kismet, or something else, I got to reunite with some of my family. The bookend to my trip was being able to visit my father, whom I hadn't seen in more than five years.

Removing friction to win

As someone whose last athletic foray was a poorly played season of JV basketball during his freshman year of high school, I never consciously drew parallels between sports and software. Yet, when you consider everything that gets tracked about players' efforts in any sport, the need for intuitive tools to understand it all makes sense.

Over the last few decades, professional teams across sports have realized this, and have become highly invested in building better tools to improve their chances at a championship. The drama Moneyball touts how the Oakland A's leaned on the concept of sabermetrics to out-recruit teams with deeper pockets and reach the playoffs in 2002, winning 20 consecutive games along the way. Tools for this kind of work have modernized since then, but like many an internal tool and enterprise software, "good enough" meant software was left alone as long as it got a result, even if it took minutes. My job is basically to help break that notion with intentionally designed, performant front-end code.

When I first applied to this job, I have to admit it was for the nostalgia. I was born and raised in Miami, growing up alongside the Marlins back when they repped Florida. Learning more about the work got me excited about building intuitive interfaces to surface a wide range of data, and working around areas like machine learning, data visualization, and statistical analysis.

Needless to say, I'm thrilled to have made the cut. I can't talk about much, but I'm excited to share more about what I learn. For now, does anyone have some throwing drills to recommend? My fielding needs some work.

Landing

Wed, 07 Jan 2026 16:28:23 GMT

The end of 2025 was... well, it sucked. Getting laid off is never fun.

Immediately after I got the news, I started reaching out to people in my network to find something fast. If you're someone who reached out to me, thank you for the kind words, support, opportunities, and referrals. If you're someone who never knew me before last November and met with me anyways, thank you for your consideration, guidance, direction, and time. I'm really grateful to be in touch with so many brilliant, empathetic people.

The holidays were really a bit of a mess for me, getting ready to celebrate Thanksgiving and Christmas in between the severance paperwork, intro calls, panel interviews, technical assessments, coding exercises, and feedback reviews. Lots of possibilities were considered: pivoting to developer relations, switching to DevOps or AI engineering, freelancing, starting my own thing. None of these options were realistic in the short term, but between the economy, the industry, and my pyramid of intrinsic needs, I was willing to consider them.

As luck would have it, an organization I applied to shortly before I was released reached out to me. It wasn't one I expected to hear back from, but it was one of those opportunities you get curious about because it generates a feeling. Kind of like being a teenager and landing a gig at that one shop you and your friends always stopped by.

Well, after many conversations with their team, I can say I've accepted an offer from them. I won't be saying who they are just yet, but I start next Monday. I couldn't be more grateful for the chance.

Week one is going to be a lot.

Ready for new opportunities

Mon, 17 Nov 2025 22:15:16 GMT

I'm currently on the market looking for a new full-time software engineering role! What follows is a bit about myself and what I'm looking for in my next position.

I am a...

Builder of digital things

I level up websites and applications with modern tooling and best practices, curating cohesive and compelling brand stories, building intuitive user interfaces for unique solutions, and developing tooling and platforms to help other engineers excel.

Flexible learner

I pride myself on the ability to learn and become productive with new languages and esoteric tools quickly. I'm not afraid to step outside my comfort zone, and I'm always willing to experiment, explore, and come back with insights.

Collaborator

Collaboration on diverse, cross-functional teams is important to me, learning from the perspectives of others, whether they're designers, marketers, engineers, product managers, or otherwise.

Presence on stage and screen

I enjoy employing my background in communications to present demos, speak on podcasts, deliver talks, and even read lines for voice acting. I've presented at multiple hackathons, hosted meetups and conferences, and have spoken to college students about web development and the tech industry.

Advocate for the community

Advocacy is something I care about very much. I do my best to be an active participant in the discourse of the web development community in social media threads, Discord servers, and Slack channels.

What I'm looking for

Frontend and Full-stack Development

I have a decade of experience in frontend and full-stack development, building intuitive, accessible user interfaces and integrating APIs written in PHP, Ruby on Rails, and TypeScript. I've even worked on ASP.NET Web Forms projects in C#.

Some of my favorite projects involve informing and enabling others with the best experience possible, whether that's building tools for development teams or open-source, applications for users, or marketing websites to inform visitors. I enjoy roles with novel problems to solve that allow experimentation and are open to suggestions.

Roles I'm interested in:

Frontend or Full-stack Engineer
Design or UI Engineer
Design Technologist
UI Platform Engineer
Web Engineer

And I'm definitely open to discussing their "senior," "staff," and "developer" derivatives as well.

Developer Advocacy

Another area that's been particularly interesting to me has been developer advocacy. I enjoy working with developers, communities, and non-technical staff to find answers to novel questions, and bring constructive feedback to project owners and engineering teams. If you are hiring for roles involved in developer relations, advocacy, evangelism, documentation, or similar, please feel free to reach out! I'd love to have a conversation.

What makes a role stand out

Beyond the salary, there are a few things an organization can offer that would catch my attention.

I prefer and have thrived in remote roles. Currently based outside of Tampa, Florida, so I am also open to flexibly hybrid roles within the Central Florida area. I'm also open to discussing relocation, though I expect it would be difficult at this time.
Medical, dental, and vision benefits that significantly cover the health costs of both myself and my family
401k match
Inclusive employee resource groups that represent the diversity of your organization
Professional development budget
Flexibility to pursue personal growth opportunities like speaking engagements

Things I'm not looking for

I'm willing to consider positions at many companies or for a variety of causes, but there are a few lines and veils I do my best to adhere to.

I'm not interested in roles that focus heavily on direct sales, account management, people management, or marketing. I enjoy being as close to the code as possible.

While the tenants of decentralization are appealing and I wouldn't mind exploring projects like the AT protocol more, I'm not interested in working in web3, blockchain, or cryptocurrency. Nor am I interested in military defense contracting.

How you can get in touch with me

If my resume and what you've read here aligns with a position you're looking to fill, please feel free to reach out to me at c.d.villard@gmail.com. You can also learn more about me at:

Running TypeScript in Node in Date.now()

Sun, 06 Jul 2025 00:39:06 GMT

TL;DR: Use tsx as a modern replacement for tools like ts-node and nodemon.

Platforms like Deno and Bun support TypeScript out of the box. However, peek into any API-related course using TypeScript like I did recently, and you'll likely be working with Node. The particular API design course I used was a bit dated by a few years, from before when Node supported native ESM imports. The instructions asked students to install ts-node, a TypeScript engine and REPL, to run TypeScript files locally.

Unfortunately, that was a roadblock for me, throwing type errors left and right when I tried to start my development server. No matter how many errors I fixed or changes I made to my config, if my app didn't throw:

TypeError: Unknown file extension ".ts",

it was throwing:

Error: Cannot find module './index.js'.

Part of the problem, I'm guessing, was that I was using newer versions of Node and TypeScript than the course was designed for, with pnpm instead of npm to boot. The course was released back when ts-node was the common approach. The ts-node project hasn't received updates since then, so there was likely some discrepancy between what would work then versus now. This might be old news for TypeScript developers working on APIs everyday, but as a front-end developer trying to refresh my full-stack skills, silly me for not remembering the pace of JavaScript's innovation.

Finding a solution for running TypeScript projects locally was a frustrating rabbit hole. Typical TypeScript development calls for code to be compiled with the tsc CLI before restarting the server for every change you might want to test. A Google search for a solution to smooth that experience out kept turning up dated content with titles like "How to set up a Node server with TypeScript in (insert any year after 2020 here)," all basically recommending ts-node. The circular nature of my predicament frustrated me enough to almost put down the work altogether.

Thankfully, I came across tsx. According to its documentation, tsx is designed to "enhance" Node.js, with support for CommonJS and ESM modes, and a built-in Watch mode to restart development servers on every saved change. Beyond being an easy drop-in replacement for ts-node, it can also be used in place of Node commands.

The big benefit I've enjoyed from tsx is not needing to toss out my coursework to start over with another version of Node. I could have tried to use newer versions of Node now that TypeScript is supported natively, sure, but then, I'd need to figure out what else might be compatible or incompatible, and at that point, I might as well be forget about API design and start writing my own course!

The point is, tsx is a quick and easy way to run TypeScript files with little fuss around configuration, and it's with that in mind that I'm writing this post. I hope other developers who need a quick solution can find this and avoid the dated solutions still topping the search results today. If you're one of them, please ping me on Bluesky! I'd love to know how it worked for you.

A warning about Upwork

Tue, 01 Jul 2025 23:38:43 GMT

I won't bury the lede with this one: no matter who contacts you or what the pitch is, never share an Upwork account.

If someone reaches out to you asking to borrow your Upwork account, or asking you to act as a "senior so-and-so" to market services via an Upwork account, immediately report them as best you can. They're trying to scam you.

Some context

As more engineers struggle to find opportunities, especially those entering the industry, it may become more tempting to find alternative streams of income. This is nothing new. I've seen a few booms and busts when it comes to the web development economy. It's during those busts that I've witnessed a disturbingly consistent trend throughout my nigh-on ten years in web development, and it's still happening today.

Upwork is one of the longest-running marketplace platforms for businesses and freelancers. It lets companies find and pay hired help for projects, and lets freelancers find and get paid for work on said projects. I don't know how popular it is now, but it was fairly common when I was getting started to see early web developers try and cut their teeth on freelance projects via Upwork.

Ever since I started putting myself out there as a web developer, I've been contacted by dozens upon dozens of accounts seeking assistance. They'll initiate contact, maybe with small talk or a plea for help. Eventually, they'll ask you a favor. The request is always the same. Whether it's that they're located in a country that can't access it, or they've been banned by mistake and their livelihood depends on it, they will ask you to play liaison to clients through an Upwork account you control, offering a percentage of or fee from the project's profits.

Don't 👏 do 👏 it 👏.

While it may be tempting to do so, never entertain the idea that the person pitching you a partnership where you put your name and reputation on the line and on an Upwork account is in it with your best interest at heart. If you're caught, you would be the one losing your account and likely banned for the privilege. This kind of operation violates Upwork's ToS, and might end up supporting illegal activities like money laundering, fraud, or impersonation.

Where's all this coming from?

I've got my start in web development teaching myself how to code, and that's was back when things were rough for me financially. While non-traditional paths into web development aren't uncommon, it's been my experience that people taking those paths come from an "up from the bootstraps" background. In times where many people in the workforce, both new and tenured, are financially vulnerable, hearing there's a way to make money by skirting the rules a little can be tempting. So I say this in the hopes that it informs someone before they make a bad choice out of desperation: don't share an Upwork account.

Leet Heat Travelogue

Mon, 23 Jun 2025 06:54:00 GMT

Earlier this year, I got to be on an episode of Leet Heat! Jason, Mark, Annie, and the entire crew were phenomenal to work with! I'm a few days behind publishing this after some very necessary days off, but I wrote most of this months before the episode aired, so I could tell you about my experience while it was fresh. Consider this a little peek behind the scenes.

The show

For those who haven't seen it yet, Leet Heat is a game-show concept from the mind of Jason Lengstorf. If you like Jeopardy, web development, and Hot Ones, you will certainly dig this! It's basically "the worst technical interview ever," as two contestants spin a wheel of categories and answer questions based on what it lands on. Should a player get the question wrong, they're docked points, their spice level is increased, and they have to eat a spicy Deno Nuggie! The higher a player's spice level, the hotter the bite, up to level 10.

Every game also starts with one "Leet Heat" tile. When a player spins and lands on that tile, their spice level is automatically increased, and they have to eat a spicy bite. Plus, once a category is played through, that category also becomes a "Leet Heat" tile! That means players eventually end up with a five-in-six chance to automatically down some spicy noms! Whoever gets the most points at the end of two rounds of spinning and spice wins the game and... well, bragging rights, essentially!

On the set

Walking into the studio, it was so cool seeing the setup in person. The whole thing is shot on several high-def cameras with Mark Techson hosting, Annie Sexton serving up punishing Deno Nuggies, Jason producing a la the "man in the chair," and the contestants at their podiums, all mic'ed up. Watching Jason's crew handling lighting, sound, hair, makeup, props, set design, still photography, and video production was amazing. (Also, special thanks to Jason Hill for the photos you've seen so far!)

Standing in the midst of all that made being there all the more real and my nerves started getting to me. My biggest fear at that moment was seizing up in front of the camera. Thankfully, everyone had my back. My opponent, Brittany Ellich (who also got to shoot an episode of Web Dev Challenge, you should check it out!), was super encouraging leading up to our shoot. Mark was ever the consummate game show host, checking in on us when he could, keeping us loose, and making sure it was fun the entire time.

After our episode was in the can, I hung out for the rest of the day and got to see more of the behind-the-scenes process. The goal was to shoot five episodes in a day, which Jason and the crew managed to knock out on time despite setbacks and hold-ups. Given the number of moving parts and variables, it's hard to describe how impressive a feat this was. Once a groove was found, everything and everyone felt in sync.

Now, this will be the corniest line I'll ever write, but the real magic was indeed the amazing group of people I got to connect with along the way. Whether it was someone I only got to chat with online before that day, or someone I'd never met before, it was a blast hanging out with the other contestants! There's something about connecting with other developers and engineers that re-energizes me about this work. It gets me wanting to learn and build! If you're reading this and we met on the Leet Heat set, you were an absolute pleasure to hang out with, and I hope we can do it again sometime!

A thanks and a plea

I can't thank Jason enough for letting me be a part of this! If this is how you're learning about Leet Heat, I can't wait for you to watch these episodes. Some are hilarious, and some are real nail-biters!

If there is something I could ask of you, though, it's that you please share these with your colleagues or even people outside the tech community! We're in a time right now where the tech industry can use some levity. It'd make me so happy to see Jason and others do more cool stuff like this! The more eyeballs these get and the more companies see people like this kind of content, the more companies might be willing to sponsor it, and the more opportunities we create for our community to make and build fun stuff together!

VueConf.US 2025 Recap

Mon, 26 May 2025 18:58:47 GMT

I attended Vueconf.US 2025 this past week as it returned to Tampa, Florida! This was a bit of a homecoming for me, as Vueconf.US was where I gave my first-ever talk to a live crowd when it was last in Tampa in 2019. I finally got some time to write, having taken the week off to also celebrate graduations and get some downtime, so here's a recap and some thoughts on my experience!

My history with Vue

For those unfamiliar with my backstory, I cut my teeth using front-end frameworks with Vue.js back when I worked for Tenet Partners as a full-stack web developer in 2016. When a client requested custom features to help their employees select the right letterhead for their communications, I was challenged to add single-page application-like features to a predominantly multi-page application built on .NET Web Forms. After reviewing multiple options, I landed on Vue.js for its developer experience and progressive approach to installation. I worked with Vue in various roles until my current role at Hewlett-Packard Enterprise, where I work predominantly with React and HTML5 custom elements. All that to say, I have quite a bit of history with the framework.

Two days of great talks

Vueconf.US features a day of workshops, which I didn't get to attend, followed by two days of talks, the first of which was all stress because I was one of the speakers!

My talk, "Full-Circle: A Time Traveler's Perspective on Vue," is a recap of the last ten or so years of Vue's ecosystem. Like the title suggests, it's from the perspective of someone who used to work within the ecosystem and is returning to it after years away. When I started researching for this talk, what was a comparison of what I used to work with and what Vue developers are using also became a discussion about the impact of Vue 3's rewrite, the struggles of major migrations, and the impact engineering decisions can have on developers and engineers.

Giving the talk and hoping all my slides worked was one thing, but it was another thing to be giving it following the creator of the Vue framework, Evan You! No pressure, right?

In addition to giving my talk and emceeing for the afternoon, I got to enjoy fantastic talks by fantastic speakers! I won't go through every one, as they'll all be available online at some point, but some talks of note:

Evan forwent his typical State of Vue-style address to get into the technical details of Vue's new Vapor Mode
Daniel Roe and Alexander Lichter of the Nuxt core team spoke about the state of Nuxt development and underutilized features, respectively
Alex Riviere gifted us the use-magic-props package after teaching us increasingly chaotic ways to define props on Vue components
Kathryn Grayson Nanz embodied the "Pirate City Vue" theme, encouraging us to ruin our users' experiences for fun and profit
Abbey Perini hit us in the feels with her talk about how ADHD can be some developers' superpower and how they must advocate for themselves
Nerando Johnson called us all out about our side projects, whether they're our sidekicks or mentors
Henry Lie showed us how automating our testing suites (you do have tests, right?) isn't as daunting as we think

On top of the talks, the "hallway track" always makes for insightful conversations, speaking with developers from around town and the world about their challenges and discoveries. All in, I couldn't have asked for a more energizing experience. If ever you get the opportunity, I encourage you to attend an in-person conference. Especially in the recent climate of the tech industry, it's one of the best places to find inspiration, connection, and drive.

Special thanks to Pratik and Vincent of connectevents.io for having me!

Leveraging GitHub Copilot for Git commits

Thu, 03 Apr 2025 20:16:33 GMT

I would never call myself an early adopter when it comes to software trends, and one of those trends I'm admittedly behind on is AI integrations in my toolset. I do have access to GitHub Copilot via work, and I recognize it's been free for everyone for a while now, but I'm all about gradual adoption when it comes to new things. Some people try stuff by tossing out their entire kit and diving into the new tools headlong. I dip my toes in to make sure it's not too shallow.

That gradual adoption has helped me spot a lot about AI integration I'm not thrilled about, but also many smaller things that I can appreciate. Case in point: I recently learned GitHub Copilot can suggest commit messages. It's smaller features like this that help me improve my workflow and draw me to AI more than being told to use it outright.

Normally, I'd advocate that it's a good practice to commit often, and I stand by writing informative commit messages about the intent, not the content, of the commit. However, I'd be lying if I said I never wrote a bunch of code, only to look back and start picking through files to determine which files match with what and how to group them best in case of a reversion. I posit that's one of the better curb-cut uses of the feature: identify what I did and summarize it for me so I can either improve on the message or commit it in the meantime.

Either way, it sure beats my commit history being a mix of:

"Changes"
"Fix a typo"
"Remove a comment," and
"Please work now"

Oh, and before I'm labeled an AI doubter, or worse, not a team player, I'm not saying I'd never use tools like Cursor or that I'd never vibe code. Normalizing on a set of tools is normal for an organization, and it's a practice companies exercised before AI was a thing. I'm simply taking my time to bring it into my personal workflows.

Tell a story you're a part of.

Thu, 16 Jan 2025 23:30:34 GMT

A friend was preparing for a job interview at a pretty high-profile startup when he reached out for advice in an online community we both frequent. The recruiters had laid out some expectations for the interview that seemed pretty bog-standard, but one particular item prompted my friend to seek some guidance. Paraphrasing a bit, the prompt stated interviewees were expected to talk about a few things including:

What's a complex project you've worked on, relevant to this position? Who did you collaborate with? How did you contribute to the project? What were some challenges you overcame? How did your work affect the project in the end?

That first part can hit the panic button pretty hard.

What's a complex project you've worked on...?

It's a fairly common question to get asked in interviews, especially for tech-related jobs, and yet, it always seems daunting to answer.

Imagine someone walking up and asking this right when you're about to order some food. I'd wager your first thought may be, "Wait, what? I trying to get a sandwich."

Give it a second, let it sink in, and your next thought may be, "Oh, goodness. What's a complex project I worked on? What work did I complete that was genuinely complex, let alone relevant to the next job I want?"

For most people, this is likely when they scroll through their job history in their minds and find the most complex project they led and delivered, start to finish, top to bottom, soup to nuts. I'm hardly innocent of this myself. I can count on my fingers how many times I answered similar questions with a vote of confidence, and that would be a good guess at best.

For my friend, the nuance of answering this question wasn't about what complex project he solved, but that he hadn't solved any complex problems yet, in his mind. He hadn't worked in software development that long. How was he to honestly answer this with only so much work experience under his belt?

Main character syndrome

In this day and age of AI-driven web scrappers, I presume you who are reading this are like me and are human. We humans naturally tend to center ourselves when asked questions about what we've done. Speaking for myself, talking about and upselling my work is probably one of the most uncomfortable positions to be in, and I bet I'm not alone in that sentiment. Let's take a second to re-interpret the prompt, though.

Instead of thinking about it as:

What's a complex task you yourself organized, led, championed, and delivered?

Let's try interpreting it as:

What work have you contributed to a complex project?

Suddenly, answering this just got a lot easier, didn't it? Talking about your role in something complex can be a lot easier than talking about a complex role you had to fill.

Part of the sum

Anyone working on software, let alone anything in general, is rarely asked to deliver deeply technical and complex solutions all by themselves. Any given project is usually broken down into tasks. Those tasks are delegated to people, often based on their specialties or bandwidth. The sum results of these individual tasks being completed, in addition to solutions to challenges the team collaborates on, are what generate outcomes. At that point, it's usually fairly clear how someone's completed work can influence those outcomes. That throughline, starting from the tasks a contributor was delegated and ending at those outcomes, is what recruiters asking that question want to hear about.

Sure, sometimes there are highly passionate, high-output contributors whose work supports the outcomes of the project to an outsized degree, but they're outliers. Even their work doesn't usually meet the project's goals in and of itself. Heck, Superman could thwart the best-laid plans of many villains, but even he was part of the Justice League.

What if you're the only one on the team solving those problems? What if you've built something for yourself to solve your own complex problems? The same rubric applies, and you're still not in a silo. You're likely still collaborating with stakeholders, one of which can definitely be you in the mirror, to identify deliverables and timelines. You may own more of the project, but you're still handling tasks and challenges in threads instead of drawing the rest of the owl in one step.

Complexity by any other name

When my friend asked about how to respond, he also served up another interesting question: What counts as "complex?" Other friends in the community chipped in on this one.

One pointed out, "Complexity doesn't necessarily have to be strictly technical." The complications of any given project could refer to resource constraints, prioritization, or regulatory and standards compliance of one kind or another. It's common to even have conflicting milestones on the same project that make it difficult to navigate towards a single outcome.

Someone else added, and I'm paraphrasing a little, that the important bit of talking about one's role in a complex project is "your ability to recognize that there was a system, that it was complex, that you recognized it as complex instead of diving head-first only to regret it a week later, and how your actions treated it as the complex project that it was." This is a sharp edge I've cut myself on numerous times. Learning how to identify a system or project as complex takes time and experience, but that learning can be done through experimentation and study.

Taking a look at the prompt as a whole one more time:

What's a complex project you've worked on, relevant to this position? Who did you collaborate with? How did you contribute to the project? What were some challenges you overcame? How did your work affect the project in the end?

it's easy to see now how redefining the mental image of a "complex project," changing it from a one-person show to a collaborative effort, can help answers for the rest of the prompt fall into place. Being asked what you've worked on is a chance for us to talk about our smaller part in a larger whole. It's not a question about how you found and climbed the mountain. It's more about how you, and maybe your team, worked to make climbing that mountain easier, even if your part in that seemed small at the time.

What environments social media can create

Thu, 24 Oct 2024 14:16:17 GMT

I'm primarily a front-end developer. That means I often deal with user experience-adjacent concerns and the environments developed for users. I have also been a Twitter user, officially since 2008 but actively since mid-2010s. It was around the same time I began exploring web development. I created my account on the advice of my mentors at the time because that's where the web development community was most active. The platform was a boon to my career, helping me keep up with industry trends, build my network, and find new opportunities. It was far from perfect, but it was an environment I grew to enjoy.

As that platform stands today, I hardly recognize it as the same environment anymore. When the new owners posted that ridiculous kitchen sink video, it was clear the platform would change. Those changes started drastically enough, but to what degree they would go in the long run wasn't clear. Today, we see what decisions like changing the platform's name, laying off critical departments, deeply monetizing major existing features, and the recent changes to safety tools have wrought.

In becoming a part of people's daily lives, the Internet is a part of their environment and is thus impactful to how they view themselves, others, and the world around them. Many people still don't see the Internet as anything more than a reference tool, but just as many are constantly connected, whose ages skew increasingly younger. These younger users see Internet access as an expectation of their everyday world, not a new feature like older generations. That's why the online social environments we develop must treat trust and safety as first-class concerns, moreso than performance, profitability, and features.

Twitter, despite all of its warts and issues, grew some understanding of those concerns over time. The current regime running what was once Twitter doesn't understand that, nor do they seem to care. Their latest revisions to the platform say as much.

The reach the platform provides can't be denied, and I have continued using it, but what reach I've enjoyed there has been the product of the time I had invested in building my network and presence there. I'm not one of the larger creators on the platform, receiving ad revenue for engagement. Nor am I one of the platform's subscribers, receiving access to features. My investment in the platform paid out when I was able to speak and interact with people in my industry in a way I enjoyed. Many of those creators have since moved on. So to that end, I'll likely start looking to bluer skies and other places to make my mark, if this trend continues.

Learn your tools

Sat, 31 Aug 2024 04:51:30 GMT

A typical pattern most developers get caught in when learning the tools of their trade is learning the 20% of the available functionality that can get them through 80% of their work, which is perfectly understandable. I'm no different. Once we can get started on work, why dive too much deeper? The downside of that mindset is that we miss out on beneficial functionality that won't come up without some digging.

There's so much efficiency to unlock by digging a little deeper into the editors and libraries we use daily. Plus, it can be such a flex! During the technical interview for my first job, way before CoPilot was a thing, I made an entire class skeleton pop up in a Visual Studio C# project with a keyboard shortcut. The hiring manager did a double-take and paused the interview to make sure I wasn't copy-pasting code. You'd be surprised by who doesn't know this and, with that knowledge, how many people you could teach.

A solid strategy to learn these features is to hunt them down while working on projects, especially when we wonder how to improve an awkward workflow. I did this while fixing an issue with my blog and thought I'd share two examples. Hopefully, you'll see some parallels with bits of awkwardness in your workflow and be encouraged to find ways to improve them.

The issue at hand

The homepage of my site features a blog list sorted by a simple Javascript sort method before it renders the posts on the page. That code sorts the posts by newest first based on each post's updatedDate and pubDate properties. I use Tina.io for my CMS. When configuring the content model for a project, each "collection" of a particular class requires a field type for each property on that class. In this case, the updatedDate and pubDate properties of my post were of field type datetime, which returns a Date string in ISO string format.

I would have liked to set a new Date for these values as a default for a new post but I couldn't find a reliable way to do so, likely due to a version mismatch between what I installed and what the docs described. So, to be sure I didn't publish a new post without these dates set, I made them required fields as a reminder to manually update them. It was far from ideal, but it suited my needs.

I published "Curation" pretty late on August 27th, followed by "Giving yourself grace" the night after. The code was pushed to GitHub and picked up by Netlify, which ran the build commands for Tina and Astro. All lights came back green, all good.

At least, it would have been, except that the post at the top of the blog list was still "Curation." I found "Giving yourself grace" below the fold. Why?

Well, when I had written those content models, the definition of the updatedDate and pubDate fields were pretty barebones, just setting the field name, a readable name, and the type of datetime.

import { defineConfig } from "tinacms";

export default defineConfig({
  // ...
  schema: {
    collections: [
      {
        name: "post",
        label: "Posts",
        // ...
        fields: [
          {
            type: "datetime",
            name: "pubDate",
            label: "Publish Date",
            required: true,
          },
          {
            type: "datetime",
            name: "updatedDate",
            label: "Updated Date",
            required: true,
          },
          // ...
        ],
      },
    ],
  },
});

This lightweight definition defaults to an ISO date string with just the year, month, date, and a localized time value of midnight GMT. That meant both "Curation" and "Giving yourself grace" had pubDate values of 2024-08-27T04:00:00.000Z and weren't sorted at all in the blog list, which was rendered out of order.

The solution

The solution to this seemed pretty straightforward: ensure the datetime values for the pubDate and updatedDate properties include the time whenever changes to a post are saved. This way, the values would always be unique enough for sorting unless manually edited. Finding the right approach was the tricky part, though. As I said before, setting a default of the immediate time and date when the user clicked on "New Post" would have saved me time, but that seemed like more installing and troubleshooting than I cared for at the time.

Looking through my code, I couldn't spot a convenient fix. There had to be some way to address this in Tina's documentation. After a bit of digging around, I came across exactly what I needed in the form of the Before Submit Function.

The Before Submit Function is a function property nested in the content model that lets you control aspects of the output when you hit "Save" in Tina's editor. It effectively acts as a lifecycle hook for your publishing workflow that lets you access the form, the Tina CMS instance, and the values you input to said form. The latter lets me access both properties and update their values with new Date().toISOString(). I also added a timeFormat property to both properties, which will let me edit them in the CMS should I need to in the future.

import { defineConfig, Form, TinaCMS } from "tinacms";

export default defineConfig({
  // ...
  schema: {
    collections: [
      {
        name: "post",
        label: "Posts",
        path: "src/content/posts",
        ui: {
          filename: {
            readonly: false,
          },
          beforeSubmit: async ({
            form,
            cms,
            values,
          }: {
            form: Form
            cms: TinaCMS
            values: Record<string, any>
            }) => {
            if (form.crudType === 'create') {
              return {
                ...values,
                pubDate: new Date().toISOString(),
              }
            }

            if (form.crudType === 'update') {
              return {
                ...values,
                updatedDate: new Date().toISOString(),
              }
            }
          },
        },
        fields: [
          // ...
          {
            type: "datetime",
            name: "pubDate",
            label: "Publish Date",
            description: "This will be generated at first publish",
            ui: {
              timeFormat: "HH:mm", // adding `timeFormat` will make sure I can edit the time in the CMS
            }
          },
          {
            type: "datetime",
            name: "updatedDate",
            label: "Updated Date",
            description: "This will be generated if it's already published on save.",
            ui: {
              timeFormat: "HH:mm" // adding `timeFormat` will make sure I can edit the time in the CMS
            }
          },
          // ...
        ],
      },
    ],
  },
});

That checked the boxes for both the automatic generation and ensuring I got the exact time of publication, meaning unique strings to sort by! As a bonus, I could update both based on the crudType property of the form value that gets passed into the beforeSubmit function. Something to note is that I had to remove the required property from both fields to allow the form to save successfully without validating their respective inputs.

First this, then that

While fixing the sorting issue, I crossed paths with a familiar annoyance in Visual Studio Code. Some might say Intellisense is an unsung hero of modern development, but I've always had a nitpick with it. While Intellisense can provide type-ahead suggestions, it falls a little short with things like TypeScript libraries. If I know what I'm typing, it can offer suggestions and will usually list what I'm looking for, but if I want to explore an object's properties, I have to play "guess the letter."

It always bugged me because all the answers are in the type inference. I could do a lookup with "Go to Type Definition," but now I'm pulling myself away from my code and going down another rabbit hole. So hey, since we're digging around documentation already, let's check out VS Code's docs to see if they- oh, they did! It turns out that hitting the keyboard shortcut Ctrl+Space will trigger Intellisense and show all the properties and methods available within the class your cursor is in. That can be a huge efficiency boost when your primary job is to find the methods and properties to make the magic squiggles on the screen keep squiggling.

So, what did we learn?

Huzzah! Our sorting problem is solved, but the real treasure was the new tricks we learned along the way, right?

Yeah, kind of, but not quite. What I hope you take away from this aren't niche solutions but that you, as a developer, should learn your tools. Sometimes, it takes a bit of searching to find what you're looking for. Look at how far into the documentation I'd need to traverse to find information on the Before Submit Function if they didn't have a search bar! That would have taken time! And effort!

The thing is that time and effort are well worth spending now to be more productive later. The Copilots and chatbots of the world can help, but in that half-automated pair programming session, you're still the one driving. You need to know your ship.

Giving yourself grace

Wed, 28 Aug 2024 00:00:00 GMT

I have a confession to make: despite having kept up with my commitment publishing to my blog every day for what's now three days in a row, I am only human. While I was drafting my post about human curation, I was truly and utterly exhausted from the culmination of a busy work day and a severe case of revenge bedtime procrastination. I was trying to drum up my thoughts while also calling into a late-night push-to-production meeting with about 100 of my closest co-workers, just in case something needed a last-minute bug fix.

Between the fact-checking and fits of micro-sleeping, I had already lost my progress, twice, to sleepily drifting fingers accidentally closing or refreshing the browser window I was editing the post in. That sure well teaches me to not write drafts in an online editor. For the curious and opinionated, Obsidian is my go-to tool as I'm writing this.

After losing my introduction a second time, I had to laugh at myself and find some folks to laugh with me. Sharing my experience on my Discord server of choice netted me what was an appropriate response.

Fair enough, but I was really excited to expand on the intersection between curated subject matter websites, the need for human connection, and a lack of community and conversation for web developers ever since Twitter changed. This was going to be a truly insightful post! I had to get it down and published for the masses to read so I could change the minds of powerful people at a fundamental level!

Then I looked at the clock. It was 1:00 am. I had to get up the next morning to get the kids' school lunches ready and hop on a networking call. As they say, time is undefeated.

So, I'll be giving myself some grace, especially when I want to write but rest is required. That post about community and conversation is still forthcoming, but it will have to wait for a more rested version of myself to write it. At the very least, a tomorrow version. Right now, I'm going to bed.

Curation

Tue, 27 Aug 2024 04:00:00 GMT

Some of my favorite Internet finds are websites dedicated to telling their readers about a single subject. Curated and maintained by a single person or a community of folks in their spare time, they are rarely fancy. There aren't any complicated algorithmic suggestions, and there is no pressure to pay with your money or data. They might have a blog, update feed, or tools of some kind. All told, these websites are intentionally designed to stand as independent, growing, evergreen repositories of information about a single subject.

I loved websites like these, back when I was learning how to code, like Shay Howe's Learn to Code HTML & CSS, and Jon Chan's Bento. Industry-specific websites that I've kept coming across over the years include Dee Bradley Baker's "I Want To Be A Voice Actor!" and Jason Thor Hall's develop.games. I even developed one called Miami Data when I was learning about civic tech.

Of course, there are more websites out there on all kinds of subjects. These were just the first I thought of when I saw Chad Stewart's recently launched Job Search Resources site on TechIsHiring. Visitors to the site can check out resources across a few categories and submit their own. Chad's goal is to grow it over time and, hopefully, the community will help it grow into a central repository geared towards helping those on the job hunt.

I think the coolest thing about Chad's Job Search Resources site is that it's not trying to be anything more than a resource to those who will benefit from it, contribute to it, and have conversations around it. It is an addition to another website, but it could stand on its own as a resource just as well. With algorithms driving what parts of the Internet I discover, and AI now generating what content it thinks will get the best spot in that algorithm, these kinds of websites are more dear to me than ever before.

It's a sentiment I hold for more than just websites, and one I'm not alone in holding. Jeremy has talked about this before. Cassidy has discussed it as well. The Internet can, will, and probably should evolve, but it was supposed to be a resource for humans to connect through. The directions companies have taken the Internet through their practices and legislation have leveled up its capabilities but seemingly at the cost of curiosity and genuine organic interest. The Internet we know today doesn't offer the same sense of wonderment when surfing through new and unfamiliar parts as it once had.

It still can, though. We may just need to build it ourselves.

By the 46th episode

Mon, 26 Aug 2024 04:00:00 GMT

I didn't get to see it in theaters, but the family and I finally got to stream the newest Ghostbusters movies last weekend. I've been a fan of the franchise since catching reruns of The Real Ghostbusters when I was a kid. I still enjoy the early movies, The Extreme Ghostbusters reboot series, and I even liked the 2016 take on the movie, whatever the critics said.

There was a bit in Ghostbusters: Afterlife that really stuck with me. A supporting character going by the name of Podcast mentions he hosts a conspiracy-theory sci-fi podcast (get it?) that doesn't get a bunch of listeners, but "really finds its voice in Episode 46." It's paid off later much to Podcast's delight, which is how I'd like to imagine I'd react if someone knew me from my work.

Funny enough, people have told me they've seen my work, namely my blog posts. It's happened a couple of times, much to my surprise. However, instead of delight, the feeling I got was pure apprehension. What did they think of it? Was it too short? Did it actually convey anything useful? Did I sound like someone else? Did my Anthony Bourdain fanboy rear its ugly head again? No, what did they really think of it? What about in this particular paradigm, angle, and context, how about now? Okay, for real though, why didn't they saying it was actually bad?

It's this nerve and anxiety that's held me back from drafting a lot of my ideas, let alone posting or publishing them. Fun fact, I've even chickened out of a small book deal because of this kind of self-talk. I could be swimming in likely tens of dollars from my split as the author of the definitive manual about Vue 3 and the composition API! Tens of dollars!

In all seriousness, this kind of doubt is also what keeps me from pursuing other endeavors. I've plied my trade as a web developer and software engineer for more than eight years now, but mainly full-time for companies. That contrasts wildly from the people in this industry I really admire, those that follow the Indie Hacker ethos, that build for themselves and make a living through their passions, that stream all day while building a business and brand that lets them live on their terms. Sure, I've got guaranteed health insurance and RSUs, but if my employer goes under or lays me off, being able to build like these people could save my family's bacon and bank accounts.

So, eight years in, I'm deciding now is as good a time as any to start figuring it out. I'm still working a 9-to-5, but I'm at least going to start working towards a business, a brand, something I can call my own. Hence why I applied to get into DiscoLink Club. Their Discord server is full of hackers, entrepreneurs, creators, and builders either trying to improve the outcome of their businesses, or trying to get started building their own.

I've only been a part of it for a few days, and I can tell Saron Yitbarek has built something really special here. I've had the pleasure of learning about content creation from Scott Hanselman, got some great advice and coaching from Ryan Cox, and I'm getting a lot of encouragement from people who have been in the same place I am now. In fact, another member of the DiscoLink Club, Jono Yeong, suggested I try a 30-day posting challenge to get over this nervousness about how "worthy" my writing is. That's why you're seeing this post today.

What I'll be writing about over the next 30 days, 30 posts, or however long is going to be a bit up in the air. It will likely involve some JavaScript, some thoughts on the tech industry, maybe even a bit about cooking, who knows? I'm just hoping that by the end, I can be a little bit more like Podcast, build some neat things that I can turn into something neater, and find my voice some time in between.

There's no %20 in file-system naming!

Sat, 24 Aug 2024 04:00:00 GMT

Over the last few years of my career, I've focused on front-end web development. I work a lot within file systems, but the code I typically write doesn't manipulate files. So when I hit a weird bug while refreshing my Node basics, I was reminded of a question from when I was learning to code: why do programmers seem to avoid adding spaces to their directory names?

During the "FS module" chapter of Scott Moss' Introduction to Node v3 on Frontend Masters, Moss introduces his students to using the fsPromises.readFile method to asynchronously read the project's package.json file. The code is pretty straightforward:

/** bring in the promise version of fs */
import fs from 'node:fs/promises';

/** define readPackageJson */
const readPJson = async () => {
  /** 
   * get the path to the package.json, but create a URL 
   * because Node no longer has __dirName 
   * */
  const pJsonPath = new URL('package.json', import.meta.url).pathname;
  /** log the output of package.json */
  console.log(JSON.parse(await fs.readFile(pJsonPath, 'utf-8')));
}
/** run the code */
readPJson();

Scott runs the code on his machine. The output is a JSON object in his terminal. I ran it on my machine, and my output was this error:

# truncated the pathnames for privacy and readability
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: ENOENT: no such file or directory, open '/Users/.../Frontend%20Masters/intro-nodejs-v3/package.json'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/Users/.../Frontend%20Masters/intro-nodejs-v3/package.json'
}

Node.js v20.11.0

This is odd, thought I. I've run all the other fs commands introduced so far, so why is this one failing? I did just upgrade my laptop's operating system. Sometimes, OS upgrades mean permissions changes. It wouldn't be the first time. Could it have something to do with that? Let me run a test script in the same file to see if it's some read permission issue.

/** same promise-version of fs */
import fs from 'node:fs/promises';

/** 
 * this time, log all the files in the same directory
 * from which this command is run
 */
console.log(await fs.readdir('./', (err, files) => {
  console.log(files || err);
}));

The resulting output was an array of the filenames I expected to be in the directory I ran the code from. So it was unlikely a permissions problem. Now, I admit, I shortcut solving this bug using CoPilot, but keen-eyed readers might have caught the bug in my code already, especially if they noticed the detail in the title. Let's look at the path in the error one more time.

{
  ...
  path: '/Users/.../Frontend%20Masters/intro-nodejs-v3/package.json'
}

That %20 in the pathname represents a UTF-8 encoded space character. If we look at another command-line tool that can read pathnames, pwdwhich returns the path of the directory the user is currently in, the output looks a little different.

# truncated the pathname for privacy and readability
$ pwd
  /Users/.../Frontend Masters/intro-nodejs-v3

That space makes all the difference. Renaming the Frontend Masters folder to something like frontend-masters fixed the issue.

The workaround for issues like this is decoding the pathname string. I could see this being common practice, used as a precaution to avoid the headache of dealing with pathnames, but I don't write enough backend code dealing with file systems to know for sure.

import fs from 'node:fs/promises';

const readPJson = async () => {
  const pJsonPath = new URL('package.json', import.meta.url).pathname;
  /** Yay, no need to worry about spaces with this line! */
  const decodedPath = decodeURIComponent(pJsonPath);
  console.log(JSON.parse(await fs.readFile(decodedPath, 'utf-8')));
}

readPJson();

So, yeah, big revelation: encoding and decoding special characters can make reading files finicky. It's no surprise developers deal with this kind of thing at work every day. Imagine working around these problems at the scale of large applications like word processors or digital asset management software. No wonder developers do whatever they can to avoid inconveniences like character decoding.

Copy other people's copywork

Mon, 22 Apr 2024 03:32:35 GMT

After I updated my post about replacing ESLint with Biome, I asked in a Discord server how to set up my RSS feed to share that a post was updated. Cassidy pointed me in the right direction and shared with me her entire approach. She sent me links to everything including query schemas, conditional logic, her XML setup, everything to help me get an “updated” property on my RSS feed. I let her know I was grateful. "This is really cool, thank you! I'm stealing this during lunch."

To write that phrase, to say I'm going to steal someone else's idea, openly, might have scared me early in my career. I think it scares most people today, especially beginners.

A lot of conversation has come up about retaking the web and building things for fun as of late. Salma Alma-Naylor has talked about it. Jason Lengstorf basically lives it every day. This discourse became personally ironic to me when I started looking up old Frontend Design Conference content, of which I'll be attending the 2024 edition this week, and saw that Adam Kuhn spoke at the last one about the same thing.

They're right. Web developers should build all kinds of useless fun things and make the Internet our own. Not just SaaS clones of eCommerce stores, but fun, impractical websites and applications. These projects are how web developers learn the basics and more advanced parts of our digital practice.

However, I think there's something we also need to add to that discussion, or at least say it out loud once again, because the algorithms that currently govern the Internet might not. We do ourselves, and especially those entering the space, a service by giving us and them permission to build whatever they want. That comes with a disservice, however, if we don't address it. We as a community can give all the permission in the world to build, but we also need to give permission to steal.

Overwhelm

One of the first things I wanted to build when I started learning web development was a website for myself. My first thought was, I better look up some inspiration and see what others have done. What do they post on their portfolios?

One Google search later and my early-career web developer brain was dumbfounded. The top results were basically listicles featuring amazing, unique, well-crafted portfolios. Crawling through Twitter bios uncovered even more, chockfull of insightful blog posts about their experiences and their work. So much inspiration! Whatever could I do with it all?!

I saved them all to a folder in the bookmarks and called it a day.

It was too much. All of these websites expressed things about these developers and engineers that I just didn't believe I had: personality, insight, experience, confidence, skill. There was no way I could build something comparable.

Eventually, I worked out a website based on a Jekyll theme and made it my own. It featured a picture of myself, had some blog posts, and a page for my resume. that was about it. I tried to believe it was okay, and people were encouraging, but I knew what was out there and I had no idea how to get that good.

Copycat

It was by happenstance that I came across Dan Mall's blog post about stealing your way to designs. In this piece, Dan's first step in the process is copywork, taking something already set in stone and making it again. This post was encouraging because, at the time, I had an inkling of a talk idea that I never gave and this made me feel like I was on the right track. The point of the talk was to give yourself permission to do the following:

Lie to yourself that you can build great things and work towards proving myself right
Cheat with tools and abstractions until you feel ready to learn what they provide and how they worked
Steal inspiration from those around you and see how you might build somthing.

The talk sounded good in my head. It was freeing to think I could give myself that permission, to crawl through and imitate other people's code and not worry about whether what I'm using it for was original or unique or innovative. Alas, in the same way that I never gave that talk, I never followed my own advice. I never worked that muscle and developed projects on the side. I never wrote about the niche technical details, or at least now I'm trying to and it's really, really hard.

We already have it

The funny thing about web development is that we already have the permission to "steal," in a way. Our entire industry is built on the shoulders of open-source software development, the contributions of many developers before us who cribbed from each other and learned collectively. That history comes with its twists and turns, but the sum of it is that our community is built on borrowed code and ideas.

We're seeing history repeat itself as new frontend frameworks help websites go from servers, to statically generated, to single-page applications, to server-side rendered again. All the while, they're borrowing ideas, patterns, and constructs from one another. Heck, Fred Schott admitted to asking Ryan Carniato for ideas. This is the norm! So why shouldn't it be the norm to try and build your own version of a silly piano or taco builder?

As we try and retake the Internet and build cool things again, I simply want to help others get ahead of this analysis paralysis now. If you know someone who is staring at that blank canvas, who wants to build a new Geocities, or a Bridgerton Binge Tracker in preparation for season three, and they don't have a direction to start with, send them this with a message: it's okay to steal inspiration.

I mean, don't be a jerk and copy someone else's work wholesale. It'd be pretty easy to spot if you did.

But steal ideas. Steal patterns. Steal snippets. Learn what the code does and why it works. This kind of copywork will only help you grow.

Oh, and Cassidy's response when I said I was stealing it? “You are very welcome!!”

Trying out a new developer Biome (get it?!)

Sun, 07 Apr 2024 21:20:14 GMT

These days at work, I'm responsible for maintaining a new global common header. It's built with web components using Microsoft FAST elements and TypeScript, with ESLint for linting and formatting. The setup is pretty bog-standard, and really common these days. Visual Studio Code offers Intellisense for TypeScript and JavaScript out of the box, but adding ESLint for TypeScript requires adding a few other packages to your project. Which may not be the end of the world, but it does mean more dependencies to download and manage, which inherently chips away at the developer experience.

An alternative to ESLint I've started trying out is Biome.js. The history behind this package is fascinating. Long story short, Biome is a fork of Rome Tools, a project promising an all-in-one JavaScript ecosystem that was unfortunately plagued with issues and eventually abandoned. Biome is still aims to provide that complete ecosystem with linting and formatting for many flavors of JavaScript built-in including TypeScript. This means no ESLint-specific dependencies and plugins just to have TypeScript in the environment.

For my particular project, implementing Biome meant replacing all of this…:


@typescript-eslint/eslint-plugin:    2.680MB
@typescript-eslint/parser       :    0.018MB
eslint-plugin-headers           :    0.052MB
eslint-config-airbnb-base       :    0.094MB
eslint                          :    3.030MB
____________________________________________

Total size of files             :    5.874MB

…with just this…:


@biomejs/biome                  :    0.130MB

…and effectively getting the same thing.

All of the packages I get to remove are just developer dependencies and won't directly affect the end user's experience, but the difference and benefits are still pretty significant. Considering the primary consumer of this packages are product teams looking to maintain consistent branding, this change means less code for them to download and install. It also means less surface areas for potential issues and threats, which translates to Dependabot having less to scan and fret over.

I highly encourage developers working with ESLint to take a look. Your milage may vary, of course, and I'm still testing it before merging it into the project, but it's that much less to worry about installing every time.

Testing for 'U's and not 'u's

Tue, 19 Mar 2024 03:44:08 GMT

It's fifteen minutes ‘til the hour, what most people call “midnight”. Tonight, I'm calling that "end of day."

That was when I said I'd have the new feature merged into the main branch of the repo. I was so confident that I'd have this working, ready to get into staging, by “end of day.” I had no doubt in my mind.

Lo, and there was a sullen cry, as if a million Github Actions and test runners rang out and said, "No."

I don't know what I was thinking. I should have remembered. I'd done this dance before. We, us engineers, we rallied against this hydra before. We asked for the time and resources to slay this multi-headed beast sucking up our flow state, this parallelized threat to our work-life balance. We finally got what we needed! And yet, at what cost?

This Minotaur we wrestle with on an hourly basis? Our monolithic - no, not monorepo, our monolithic front-end's testing suite. What was once a well-meant suite of tests and checks meant to gatekeep the release of bugs and broken features from production. Now, a massive amalgamation of integration and end-to-end tests, the culmination of years of copied and pasted testing patterns, rushed descriptions, and accepted Copilot suggestions. The spitting image of the Testing Pyramid upturned.

On every pull request, the paralellized processing power of 30 machines must grind away at these tests to sate what could likely be done - nay, should be done! - by unit tests. Should even one fail, be it a test related or not to the pull request, it's a slow and arduous wait until the others finish before the the failed machine can be started again. And if it is related, may luck go with you that the task of correcting it and pushing a change not send you into a seemingly Sisyphean spiral as it has for me on this dark night.

What pray tell is causing my tests to fail? Could it be another timeout as the test runner searches for an element that may or not be there? Could it be a change to a conditional that only now has finished trickling down with out proper vetting? Or is it another string expected to start with a capital “U” again in a phrase like 'Delete Users' . . . where all others are expected to be sentence-cased?

But alas! The bells of the test runner chime again for me! Another failure. I must tend to it, lest I be here another hour. Quickly. Flee. Flee from whence you came. Away from those tempting warmth of “80% test coverage!” I shall shield your escape while I return to my work . . .

Post-to-post: 2023 from the rearview mirror

Tue, 30 Jan 2024 23:43:56 GMT

It's been over a year since my last post, ironically enough. That post discussed the importance of writing regularly and declared that I would be doing so.

That didn't happen. I've drafted an idea or two, but I didn't get a single new post out. Whoops.

This wasn't because I had nothing to say. Much like many others, the habit of writing blog posts and building side projects is not one that ever came naturally to me. Day-to-day life is usually my reason d'jour, and mine is replete with work, children, family, chores, events, concerns, a limited amount of energy, and all kinds of other excuses.

So, in an effort to kickstart a change in that habit, I wanted to highlight a few things that I accomplished over the course of the last year as a senior member of a hybrid UI platform/infrastructure team. While I can't show off much code, I think this will give a peak into what front-end development can look like beyond the components and styling for which it's popularly known.

New dashboard, whose service?

The first project I tackled last year was leading the development of a redesigned dashboard for HPE GreenLake. This project is kind of special to me. With all its ups and downs, it was my first real test as a developer with the word “Senior” somewhere in their title.

The outline for this project seemed pretty straightforward: rebuild the dashboard to focus on the services each of our main applications offer instead of the applications themselves. Between myself and another engineer, we managed a proof-of-concept in record time. However, like many projects, what seemed like a "simple reconfiguration" of the UI turned into a far deeper rabbit hole. In one conversation, teammates involved in building the dashboard's previous version estimated our work would replace approximately 80% of the pre-existing monolithic front-end.

There were plenty of obstacles and red tape to get through, and challenges I won't get into details about here. Despite all of them, we completed our work in time for it to preview at HPE's annual Discover event, and that very work is now available to all of HPE's users. This work really taught me what it means to be a senior engineer by putting my feet to the fire. I came away from it with a better understanding of what senior- and staff-level individual contributors may need to navigate, what's worth documenting, what hills are worth fighting for, and much more.

"DivOps?" "WebOps?" Front-end build tooling

Not long after I completed and handed off the dashboard build, I got the opportunity to work in a vageuly defined subsection of front-end development. Though I do like how Ben Ilegbodu defined it: DivOps. A number of applications were being prepared for a new offering, and it necessiated an update to our micro-frontend architecture to ensure we could host applications not only in the cloud, but also on-premises. This meant divesting ourselves of libraries like single-spa-react and adjust to hosting applications as individual SPAs.

Unfortunately, its work that won't make it into production. Such is the nature and whim of business. On the other hand, it got me getting comfortable with JavaScript build tools and their capabilities. It also got me working with a lot of teams and writing a lot of documentation, ultimately a lot of good practice. It also set the groundwork for a lot of really cool frontend architecture work our team will be taking on in the coming months.

Headers are hard. Who knew?

After working on front-end build tools for a while, and after the decision to shelf my previous work, my responsibilties moved back towards UI, maintaining a new and improved global header. It's my primary focus these days, and a really interesting challenge. When we designed the v1 of this new header, we decided on building out a web component-based header to allow applications built on any framework to consume it with a simple set of contracts to meet. This next year is going to involve a number of new integrations and features that I'm excited and anxious to build out.

What about now?

Now that we're a month into the new year, I'm hoping to increase my output outside of work hours as well. I've already streamed a bit and I'm hoping to write a bit more as well. We'll see what comes of this next year. All in, I'm seeing this as a blank slate opportunity to define my career moving forward. Hope you stick around to check it out.

Keeping a record

Thu, 19 Jan 2023 17:00:28 GMT

When I started learning web dev, I had built a portfolio and blog. The work featured mainly websites for loved ones or agency work and a few odd posts. It made it way easier to get eyes on my resume.

However, after VueConf.US in 2019, I lost the practice of maintaining it. I had decided to rebuild my portfolio using Gridsome. Somewhere between npm install gridsome and life, I hit a road block. My portfolio sat in an "under construction" state for ages.

My career progressed forward without it, nonetheless. It wasn't that I didn't need one, just that I had established some experience and that was enough to get me hired. Now I'm a senior engineer, and it could be said I got here despite not having a well-maintained portfolio or website.

Except I don't have anything concrete to look back on except for a one-page resume.

The practice of writing isn't for everyone, but I would advocate that maintaining some record of your career is a healthy practice to pick up. That could take the form of maintaining a series of side projects, blogging, or even just journaling in private. It helps build a detailed history and breadcrumb trail of your career you can look back at to help remind you of what you learned and when, of the reasons behind choices made, of what you want to avoid moving forward. It's part of the reason why I'm working on this site, to revive that practice for myself, taking the advice of prolific blogger Chris Coyier.

It's harder for me now, being a senior engineer and a family man, to find the time to write detailed, technical long-form pieces or long-living libraries. But I still think the practice is worth it, and I know that it will only become easier with repetition. I will never not advocate that developers at all points in their career consider keeping a record of their career, be it as a blog, diary, notes, or heck, even bullet journaling. Just build yourself a history, and preferably on a platform where your data is yours to keep.

Jamstack Conf 2022 - One Dev's Recap

Tue, 29 Nov 2022 17:00:33 GMT

It's already been almost a month since Netlify's 2022 Jamstack Conf. In that time, I've been trying to get my thoughts of this year's event for all things "Jamstack" on paper.

The short version of those thoughts: the Jamstack has not changed much at all. Its concepts and practices are pretty well documented at this point, if not by the company that coined the term in 2015, then by the robust community and ecosystem backing it.

What has changed are the problems and challenges the Jamstack community is trying to solve today. In years past, the big question was, "How do developers get a website stood up faster and less painfully without maintaining a server?" That question has been answered by now. All kinds of solutions are offered by the likes of Vercel, AWS, Cloudflare, Github, and Netlify itself. And that's great, but as with anything that needs to scale, it seems answering that one question has uncovered more.

"How do we keep this ecosystem healthy?"
"How do we help non-technical people contribute?"
"How do we get our content to users faster?"

In my mini-recap of Jamstack Conf, I mentioned a few themes strung across the whole conference: collaboration, abstraction, and access. This post will aim to elaborate a bit on what I saw of those themes.

Recordings of the talk are starting to make their way onto the @JamstackConf YouTube channel, so I'll add links to the ones I mention here as they're made available. Until then, I'll try and do the general vibe of the conference and Phil Hawksworth's hosting justice.

Abstraction (or "How Third-Party Tools Help Take the Pain Away")

As Bud Abbott once said, "Now wouldn't this be a fine [baseball] team without a pitcher?" Well, wouldn't the Jamstack be a fine architecture without abstractions? Every year, Jamstack Conf highlights what abstractions can do for developers. This year was no different, with presentations covering libraries, frameworks, and as-a-Service... services.

Some talks felt like seeing the sentiments of Chris Coyier's 2018 and 2019 Jamstack Conf talks become manifest. Amy Dutton of the COMPRESSEDfm podcast talked about how she and her co-host, James Q. Quick, built all kinds of nifty features and tooling into their podcast's website leveraging Jamstack tools. Phil chatted with Aaron Emery and Kady Wood about how TripActions bet on the Jamstack to move their monolithic marketing project towards more nimble tooling.

Other presentations highlighted the many challenges teams can face on various technical levels and offered innovative solutions. The abstractions available to developers today are bonkers compared to where we were a few years ago. Content managements systems were of course well represented, but the Jamstack has clearly grown much further than that. Services on display covered problem areas including database management and orchestration, websockets, eCommerce, collaborative design, and monorepo build systems. A few that caught my eye in particular:

Clutch, providing visual tools that allow designers to work on a canvas while allowing devs to use code for prototyping.
Ably, aiming to simplify the development and management of websockets and realtime communication
TanStack Router, which offers framework-agnostic, type-safe routing and serialized state management
Qwik, a new front-end framework that focuses on resumability instead of hydration to send as little JavaScript as possible with amazingly fast time-to-interactive.

Collaboroation (or "Why Can't We Be Friends?")

Many of the services I mentioned offered features that let non-technical people contribute in technical ways. More crucially, though, a few of the presentations stressed the importance of how we enable others to contribute. Sanity's Knut Melvær drove home why caring about the content creator is important, and how Markdown isn't helping. OSS organizations and maintainers discussed how they're welcoming the cross-pollination of ideas more in recent years. Personally, Iooking at the open-source space today, I think it shows!

One panel of independent framework developers discussed the importance of working together and inspiring each other's work on community-driven tools instead of dogmatically black-boxing ideas. Another panel, this time of database experts, highlighted the concerns of scaling database management today . Yet another discussed the problems of building runtimes and logic closer and closer to the edge.

The overarching sense I came away with was that many people in tech are all trying to solve similar problems. So why make it difficult for others to help solve them? Why fight over what the "silver bullet" answer to every edge case might be? These kinds of open conversations are encouraging and healthy for the community. They show that, despite competition, there's collaboration and stewardship involved in finding the solutions.

Access (or "How I Learned to Stop Worrying and Embrace the Edge")

It felt like almost every talk acknowledged the potential of leveraging "the Edge." So much so that I effectively learned more about what that phrase meant at Jamstack Conf than anywhere else. And that's coming from someone who currently works at a cloud service provider!

Cloudflare's Obinna Ekwuno and Netlify's Erica Pisani gave great talks that helped define what the Edge is to developers and users. Erica taught us about the benefits of leveraging edge functions, while Obinna dicussed the challenges of deploying databases closer to the user. Obinna's points and concerns were also echoed in the databases panel I mentioned earlier, particularly in figuring out how to abstract the database away from developers while maintaining up-to-date state close to the user.

The real highlight for me around this topic was the edge runtimes panel. Despite copious amounts of notes, I feel like I need to watch it a couple more times to get everything! It serves as a pretty good study of what the Edge represents and where it's going. Much of the conversation reminded me of the "next billion users" concern that became popular a while back. As access to the Internet becomes increasingly common worldwide, how do you give users the same responsive experience whether they have high or low connection speeds? As more developers start building applications at scale, what are the acceptable tradeoffs to keep data healthy and in sync?

So, so much more and so little time.

I'm missing a lot here. It's really hard to bottle my experience at this conference and confidently say I'm doing Phil justice here. Everything I've touched on doesn't even cover the "hallway track." When I missed talks, I was having fascinating conversations with vendors at their booths, with folks about their thoughts on challenges I'm trying to solve, or even just in passing. Nevertheless, it was nothing short of a fantastic experience.

I'd like to shout out to everyone who made my time at Jamstack Conf 2022 such a delight! Thank yous again to Jo Franchetti, Alex Trost, Matt Biilmann, Sara Viera, Ben Hong, Brian Douglas, Chris Bach, and Jem Young, as well as to Caleb Jasik, Misko Hevery, Dana Lawson, Zach Leatherman, Phil Hawksworth, Jason Lengstorf, Monica Sarbu, and anyone else I may have forgotten! I know everyone here is just a regular person, but it'd be a lie to say I wasn't a bit starstruck.

One more thing: if you managed to make it to the end of this recap and you yourself have not attended a conference, I implore that you make attending one a goal. Even if it's a small one without a ton of coverage or big names, I encourage you find out where one is, whether their code of conduct is up to snuff, and if it is and you're up to it, try and attend. Network with people, speak about what you're concerned about, and add your voice to the conversation. The ecosystem needs it, and you'll be all the better for the experience later.

On the way home from JamstackConf 2022

Fri, 11 Nov 2022 17:00:51 GMT

My head is still reeling

Reeling, I say! - from two days of talks, discussions, and laughs while attending Netlify's JamStackConf 2022. I got to meet and say hi to a bunch of brilliant people like Jo Franchetti, Alex Trost, Matt Biillman, Sara Viera, Ben Hong, Brian Douglas, Chris Bach, Jem Young, and so, so many others! A few major themes could be seen across the whole of the conference:

Collaboration

So many new and neat tools are trying to solve creative problems not just for developers, but for the team members that work with developers. Content management tools that provide both strong DX and UX, visual design tools letting developers prototype logic where the layout design lives, database tools that let non-technical users manage stored procedures, and companies trying to use the Jamstack for the greater good.

Abstraction

Those aforementioned tools exhibited the power of low-code/no-code tooling in today's ecosystem. In my discussions and in several talks and panels, speakers highlighted how using reliable services for concerns like authentication, payments, form submission, user registration, and more paid more dividends than just "building it ourselves."

Access

As more and more users connect to the Internet, the advent of serverless technologies is allowing for more of the application stack these users see to not just exist on someone else's metal, but closer to the user by putting it "on the edge." Effectively this means hosting as many copies of an application as possible as close as possible to the user, leveraging distributed servers to make responses to their browser and app requests faster. We've successfully managed this with storage, as well as app logic by way of edge functions. The next step of this movement is now moving data to the edge, and finding ways to reliably provide accurate copies of databases and changes made to them to users around the globe as quickly as possible.

I plan on writing a blog post in the coming days to further discuss what all happened and some personal thoughts, but the future really is bright for the Jamstack. I'm here for it!