|View this newsletter on the web.
🔗 Links from around the web
- Here’s a great post from Bastian Allgeier all about simplicity in web development. He writes about how things are getting more complicated and it might not be helpful for us all in the long run:
You want to build a JS file? Please update Webpack first. Oh, that new version of Webpack is no longer compatible with your Node version. Oh, your new Node version is no longer compatible with that other dependency. Oh, now you have 233 detected security issues in all your node_modules but you can’t fix them because that would break something completely unrelated.
This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.
- Scott Jehl explains that 5G is on the horizon and how it could cause problems for users. The idea is that when we get power, we use it… and then some. Since 5G will arrive in affluent areas first, we’ll widen the gap between high and low end connections even wider than it are today.
- caniuse.com is perhaps the greatest website ever made but the brand new caniemail.com must come just shy at second place (just look at that nice mobile experience). It helps figure out which features email clients support.
- How do you change the colors of product images using CSS blend modes and SVG? Kyle Wetton answers that question by showing us how to build a feature that changes the color of someone’s t-shirt without needing a brand new photograph to do it! Pretty nifty trick, this one.
- A while back, Monica Lent wrote about what she learned as a junior developer and has some super interesting thoughts on technical debt, what being a senior developer means, and the skills that a programmer should acquire that go beyond coding. And at the other end of the spectrum… What does tech leadership really mean?
📝 From the blog
Sarah Drasner offers this primer on contributing to open source projects for those who may be new to it. I particularly like this bit:
As a maintainer, it’s frustrating when someone put in a lot of work and submits a giant honking PR that does 10 different things. It’s really tough to review, and inevitably, they’re doing six things you want, and four things you don’t. Not only that, it’s usually spread out over multiple files which is difficult to untangle. I’ve definitely closed PRs with some high-quality code I would like just because it would take forever for to review and manage it.
In my opinion, you have about 1,000% more chance of getting your PR merged and your time spent honored if you split things over multiple, smaller PRs.
This advice reminds me of what I learned a while back on the topic of starting a front-end refactor, too. Keeping focused is the hardest part about contributing to any project but it will be sure to pay off over time.