Anselm Hannemann is a freelance front-end developer and architect and cares about sustainable front-end experiences and ethical choices in life. He curates the WDRL, a weekly handcrafted web development newsletter that thousands of developers love and subscribe to.
We shouldn’t let ourselves get distracted by people who work on different projects than we do. If a developer advocate works on a web-based QR code application, for example, their way of tackling things most certainly won’t fit your project. If someone builds a real-time dashboard, their concept won’t relate to the company portfolio website you’re building. Bear in mind that you need to find the best concept, the best technologies, the best solution for your specific project.
Thinking about the right decisions rather than following cool, new trends blindly, is the first step to building responsible web solutions. That’s what we call progressive enhancement. The only subjective matter in this undertaking is you, judging what level of progressive enhancement a solution should have.
Are you afraid of refactoring code? I love refactoring code. It’s nice to see a code base growing, but this also means that new quirks and suboptimal changes are introduced along the way. At some point, you might realize that there could be a huge opportunity in rewriting the code — to eliminate conflicts or to rename things.
For me, refactoring is both: It’s a challenge to master, but, in the end, also a relief to see how the code evolved. We can’t anticipate everything when we first build modules, and we shouldn’t try to do so either. So let’s not be afraid to set our hands to an already existing code base and improve our code over time instead.
We have great new technology available to enhance our websites. But while theoretical articles explain well what the technologies do, we often struggle to find real use cases or details on how things worked out in actual projects.
This week I stumbled across a couple of great posts that share exactly these precious real-life insights: stories about HTTP/2 implementation, experiences from using the Cascade of CSS in large-scale projects, and insights into employing Service Worker and BackgroundSync to build solid forms.
As developers, are we paid to write code? This challenging question raises concerns about product quality, code quality, and our purpose as developers in a world of coded applications. You’ll find an interesting post that dives deeper into the matter in the “Work & Life” section of our reading list this week.
But we have other amazing resources to look at this week, too: new tools, new tutorials, and we’ll also take some time to reconsider CSS print styles. Let’s get started!
These days, I’ve been pondering what purpose we as developers have in our world. I’m not able to provide you with an answer here, but instead want to encourage you to think about it, too. Do you have an opinion on this? Are we just pleasing other people’s demands? Or are we in charge of advising the people who demand solutions from us if we think they’re wrong? A challenging question, and the answer will be different for everyone here. If you want to let me know your thoughts, I’d be happy to hear them.
We all have visions and dreams. Whether it’s about our personal lives, our work, or about complex concepts that target issues which are hard to grasp. The important thing is to listen to your ideas, to write them down, and, if they wake strong feelings, to pursue them.
It can be easy to achieve this, yet sometimes it’s not. A nice technique is to start small and take small steps instead of going 100% all-in or do nothing at all. We like to play with new things, we like to try out new technology, and our minds want to explore new paths — let’s do it!
Is a person who is sitting by herself in a room alone? From an outside perspective, it might seem so, but the human brain is way more interesting in these regards. We carry a map of relationships inside ourselves, and it depends on this map if the person actually does feel alone or not.
As people working in front of a screen all day, we often struggle to find the right balance. I’m not talking about work-life balance alone here, but of how our life that is completely virtual during the day often causes us to not take real life into account.
We tend to forget that our bodies need something else than coding all day. And we need to take care of our fellow human beings in real life as well. Just think about this number: The average US person will spend over 9 hours in front of a screen today. Time to become more aware of how we can keep the balance between the virtual and the real world.
But then again, we have to remind ourselves that we shouldn’t immediately jump to a new tool just because it’s available, to not rewrite the whole code of a project just because conventions have changed. No project will stop working because you’re using OOCSS instead of ITCSS or Backbone.js instead of React.js. If the project is an ongoing process and will be developed and maintained for another few years, you should evaluate to change tools from time to time, of course. But take your time. Better evaluate first, then reconsider, before you immediately jump on a train from which you don’t know where it’s heading.