🔥 The DevEx Rebel's Handbook: Forgiveness Over Permission

Wecome back, developrrrs! 👋 New look, who dis? Today I’m debuting my newsletter’s fresh logo rebrand. After 37 cup-of-coffee design iterations and one existential crisis about font choices, we’ve finally arrived at visual perfection. Hit reply with your thoughts—constructive criticism welcome, absolute praise preferred.

Coming soon: I’m launching a dedicated archive website where you can binge-read all previous issues like they’re episodes of that show everyone’s talking about but you haven’t started yet. No more doom-scrolling through your inbox looking for that deployment strategy I covered in February!

🤿 Deep Dive

I once observed a team meeting where developers spent 30 minutes venting about their terrible developer experience. The slow CI pipeline, the clunky approval process, and the outdated documentation. Then they all agreed someone should “really do something about this” before promptly returning to their regularly scheduled feature development.

Let’s get controversial: Waiting for your organization to prioritize DevEx is like waiting for that person who never texts back to ask you on a date.

According to the State of Developer Experience 2024 report, developers spend up to 28% of their time on building and testing artifacts – that’s not coding, that’s just waiting for your tools to work.

🛠️ The DIY DevEx Revolution

Here’s my radical suggestion: Own your DevEx. Stop waiting for permission to fix what’s broken.

I once worked with a team plagued by flaky tests. Instead of submitting yet another ticket, one developer took a Friday afternoon to create a script that identified and automatically re-ran only the flaky tests. By Monday, the entire team was using it. Two weeks later, the infrastructure team officially adopted it.

The secret? It’s easier to get forgiveness than permission, especially when you’re showing results. 🙏🏼

“But wait, I don’t have time with all my assigned tasks!” Fair point. Here are battle-tested approaches:

The stealth approach: Build improvements while doing your regular work. That script to automate a tedious task isn’t a side project – it’s just a smarter way to complete your assigned work.

The “documentation” angle: Nobody questions the time spent on documentation. Creating tooling that makes processes more repeatable is just “executable documentation.”

Just do it: A working prototype that saves everyone time tends to retroactively justify its creation.

🌱 The Grassroots Effect

DevEx improvements spread organically. That one-off script becomes a team utility. That team utility becomes a department standard.

This bottom-up approach is often more effective because developers know exactly where the pain points are. Top-down DevEx initiatives often miss the mark because they’re disconnected from daily reality.

🤝 Know When to Collaborate

While “ask forgiveness, not permission” is often effective, some scenarios require caution:

Security boundaries: Tread carefully with tools that touch authentication or production environments.

Team alignment: Ensure your solutions don’t conflict with team standards.

Hidden dependencies: Some systems have complex relationships. I’ve seen innocent-looking scripts break CI pipelines in mysterious ways.

The goal isn’t to seek permission for every improvement but to recognize when your fix might impact critical systems.

🔗 The DevEx Connection

Your personal developer experience isn’t isolated from your team’s. When you reduce your own cognitive load, you’re more likely to help others do the same.

Better tools lead to better code. Better code leads to fewer firefights. Fewer firefights lead to more time for… even better tools.

💡 The Bottom Line

Stop treating DevEx as someone else’s problem. Start small, focus on your specific pain points, and share your solutions.

Concrete first steps:

1. Identify your biggest time-waster this week

2. Dedicate 2 hours to building something that addresses it

3. Share it with at least one colleague

4. Repeat

The best DevEx improvements aren’t handed down from on high – they’re built by the people with actual skin in the game.

Stay self-reliant! 🛠️

Powered by coffee ☕️ and the stubborn refusal to accept unnecessary suffering

📊 Stat

Developers spend an average of 100 days onboarding due to the number of tools involved

Tool sprawl and lack of standardization lead to prolonged onboarding periods for new developers. Consolidating tools into unified platforms or providing robust knowledge bases can significantly reduce onboarding time and improve developer experience.

💡 Key Insight: Faster onboarding translates directly into faster contributions from new hires.

📌 Essential Reads

🛑 Breaking Up with On-Call. Alexey Karandashev critiques the on-call culture in large tech companies, arguing it incentivizes unreliable software and burnout. He contrasts this with smaller teams and startups, where tighter constraints lead to higher-quality code and fewer emergencies. The piece advocates for shifting from reactive on-call duties to building more resilient systems, potentially with AI handling routine incidents.

🧠 Accelerating Large-Scale Test Migration with LLMs. Airbnb leveraged large language models to migrate 3.5K test files from Enzyme to React Testing Library—cutting a 1.5-year manual effort down to just 6 weeks. They built a scalable, step-based pipeline with retries and dynamic, context-rich prompts to handle both simple and complex test files. The process achieved a 97% automation success rate, showcasing LLMs’ transformative potential for large-scale codebase maintenance.

🚀 Everything I Know About Shipping Code Faster. Ryan Peterman shares actionable tactics to dramatically speed up code delivery, based on his experience shipping over 1,000 commits to production. He covers code search fluency, small diff strategies, faster reviews, and flow state optimization—all aimed at reducing friction and iteration time. The post blends practical engineering tips with insights on soft skills and workflow design for high-impact development.

🛠️ Tools

• Statoscope is a powerful webpack bundle analyzer that helps visualize and optimize build performance.

• LlamaIndex is a data framework for connecting custom data sources to LLMs, streamlining AI-powered application development.

• Hurl is a command-line tool for running HTTP requests defined in simple text files, great for API testing and automation.