You’ve built your business on a large rock, it has served you well over the years, buuuut... technical debt has accumulated everywhere around your applications.
As designers getting up to speed on a new client project, we often feel the tension of designing quickly to earn trust, and designing to provide lasting value to users and the business. We want to be partners, not just another resource to be called upon when desired. But how can we smoothly transition into this partnership?
Product vision can be a powerful thing. It tells a story of what’s possible and pulls people toward that change. A lack of vision can be insidious. At its best, it leads to missed potential. At its worst, it can lead to unmotivated, burned-out teams and a disjointed product that fails to deliver customer value.
A client of ours has a long-lived React application using an architecture that was common at the time of its creation: Redux with thunks and sagas, with Redux Form powering the majority of forms throughout the UI, which is rich with input fields. To those familiar with this combination of technologies, you might immediately understand why they reached out to us to help fix their app’s performance issues.
People say "technical debt" like it's a bad thing. But those who are serious about software development know that this game is all about managing technical debt. Technical debt is a natural part of the landscape in any software development team’s world. It's neither good, nor bad. Yet when trade-offs are mismanaged, technical debt is likely to cause your productivity to grind to a halt. For people who hit that point and wonder why - there should be no mystery about what causes technical debt, the answer is right in front of you.
While the world of office work has changed for us and many others since we first released Lunch in 2016, the app itself has been happily chugging along, attracting regular users and helping teams with one of the most pressing questions of the day: where’s lunch?
If you use the browser development tools, you've likely seen the request timing information on the Network tab. It shows how long it takes for web pages and their components to load. But did you know that servers can also send their own timing information? They can do this with a header named Server-Timing. Modern browsers can show the server timing data next to the client timing data on the Network tab. This can help developers find and fix server-side performance issues such as N+1 queries. You can read more about the Server-Timing header's specification in the W3 working draft, or on Mozilla’s documentation site
Progressive Enhancement as a guide to choosing which tool to use in Hotwire
When you build a developer center or developer portal, you’ve got tough customers. They’re developers, after all. They either know precisely what they want, in which case they will demand that you deliver exactly what you advertise. Or they don’t know what they want at all, in which case you have to educate them in the most painless way possible, and make onboarding easy and fun.