Changelog

In this blog post we will introduce you to some of out internal best practices we have developed or discovered to simplify and speed up working on open-source and other projects. There’s nothing revolutionary in here for those experienced in open source maintenance, but it’s a good rundown nonetheless. It’s also interesting to see how many teams are now using (and recommending) dependency update services such as dependabot and Greenkeeper.

Yegor Bugayenko: Now here is a simple, plain list of recommendations for you: what you should do if you want to be a more successful programmer. Not a better algorithm designer, even though that’s important. Not a funnier team player, even though that’s also important. But a more successful software engineer, both financially and socially. Of the 14 recommendations, I’m happy to report that I regularly engage in 10 of them! The only one that I’m diametrically opposed to is Earn Certificates. No thanks! What do you think of Yegor’s recommendations?

Martin Fowler’s TellDontAsk principle is very useful in object-oriented programming. However, it is not enough to follow only this idea: we also need to be very careful in order to not break the interface of the object, otherwise we won’t be able to keep telling it what to do later and we will end up asking for data again.

Do you love programming for its own sake, or do you just program for the outcomes it enables? Depending on which describes you best you will face different problems in your career as a software developer. Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love. Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build. Which is your camp and why?

This is a spectacularly thoughtful and insightful piece by Eugen Kiss on testing: Different kinds of tests have different costs and benefits. You have finite resources to distribute into testing. You want to get the most out of your tests, so use the most economic testing approach. He goes on to describe why he believes that integration tests provide better ROI than unit tests and end-to-end tests. Then he turns his aim on unit tests in particular: There is the claim that making your code unit-testable will improve its quality. Many arguments and some empirical evidence in favor of that claim exist so I will put light on the other side… Unit tests ossify the internal structure of the code. Click through to read his whole argument, but I will say in my experience unit tests only ossify the structure when I do them poorly. In other words, the better I get at unit testing, the more useful they become. In light of that, Eugen’s big takeaway at the end might be 💯 on point: If you desire clear, albeit unnuanced, instructions, here is what you should do: Use a typed language. Focus on integration and end-to-end tests. Use unit tests only where they make sense (e.g. pure algorithmic code with complex corner cases). Be economic. Be lean.

We recently talked with Daniel Stenberg about HTTP/2 and QUIC, so this news comes with little surprise looking back on that conversation with hindsight. The protocol that’s been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham. On November 7, 2018 Dmitri of Litespeed announced that they and Facebook had successfully done the first interop ever between two HTTP/3 implementations. Mike Bihop’s follow-up presentation in the HTTPbis session on the topic can be seen here. The consensus in the end of that meeting said the new name is HTTP/3!

My biggest take away from this epic announcement from ZEIT? The support of the majestic monorepo! …Now 2.0 enables what we will call The Majestic Monorepo, inspired by a similarly named essay by DHH, creator of Ruby on Rails (The Majestic Monolith). We don’t agree that you should be orchestrating a big server abstraction (a monolith), but we believe you should be able to collocate your APIs and your business logic in a single place, with a cohesive deployment story. It looks, feels and deploys like a monolith, with none of its downsides. …but there is SO MUCH MORE to this announcement. Also, we talked a bit about David’s idea of The Majestic Monolith on The Changelog #286.

There’s some seriously interesting thoughts shared here for building out a multi-CDN strategy. Having had issues with how to best use and leverage a CDN to get the best performance benefits, I can see how having a multi-CDN implementation would allow us to choose the right CDN for a given region of the world, as well as a whole host of other options based on things like cost, performance, and of course redundancy for when things go wrong. Murphy’s law, right? This summer, the 2018 World Cup set an all-time streaming record – tripling its own 2014 record – with over 22 Tbps measured by Akamai at peak, but the event wasn’t smooth sailing for everyone. In a highly competitive market, and in an age where streaming failures make headlines, redundancy and quality of experience have never been more crucial for content publishers. Drop a comment below if there are other resources out there on this subject that we should check out.

How do you balance delivering on time and the frustration of seeing messy, out-of-date code? In this article you’ll learn a set of heuristics to help you decide when—and why—to cleanup to your code.

Derrick Camerino: As developers there are some many things to work on. We must learn how to prioritize our tasks and focus on the most important things. Our time is a valuable asset. In this post, I discuss some ways to increase leverage and get more impact from your efforts.

The fight against complexity is analogous to the fight against contentment. Find contentment and you will find yourself at the end of a project. Hint: we will never be fully content. We live in a dynamic world of infinite, and never-ending change. There will always be a critique to offer. Perfection is an illusion. We’ve all worked on projects that never seem to end. Every time you think you’re done, you realize you’re not. There’s “one more thing” you or your client wants to add. Somehow, you get exhausted and your work suffers. Sometimes you simply burn out and move on to something else. Why does this happen? Why do we consistently underestimate how much extra work it is to do “one more thing?”

A look at the difference between Indirection and Abstraction, with the focus of understanding how to evolve a system to make it more maintainable and easy to develop.

This was from an AMA, but Sindre turned it into a blog post since his response was so popular. Also, his answer applies particularly to Node.js. Sindre writes on his blog: Make small focused modules for reusability and to make it possible to build larger more advanced things that are easier to reason about. And, also… It doesn’t matter if the module is one line or hundreds. It’s all about containing complexity. Think of node modules as Lego blocks. You don’t necessarily care about the details of how it’s made. All you need to know is how to use the Lego blocks to build your Lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works.

Choosing the right open source database is an important decision. Start by asking the right questions. All too often, people put the cart before the horse, making decisions before really understanding their needs. Solid tips by Barrett Chambers. Here’s another one courtesy of yours truly: Start your database selection journey by asking yourself, “Why not use PostgreSQL?” 😉

This is a must-read for any software engineer wondering how they can move up the ladder without falling pray to the Peter Principle. Career progress for programmers doesn’t require giving up coding to become a manager. You can get more autonomy—and stronger negotiation leverage—by going from implementer, to problem solver, to problem finder.

Kate Matsudaira provides 5 excellent strategies for pushing through: Even if you love your job, you don’t always feel like doing it every day. There are so many factors that influence your ability to show up to work with enthusiasm and then work hard all day long. From gamification to calendaring, Kate has a lot of good advice in this piece. I even learned a new word, “precrastination”, which I’ve been doing a lot of without even knowing it! 💪

Yup, it’s true…“estimating project costs is hard.” I thoroughly enjoyed the tongue in cheek logic shared by Dave Rupert in this post. …let’s say your app has a logged-in or logged-out state, well, that’s at least 2 if-statements. Starting price: $20,000. Never before has it been this easy to price and scope out complex stateful apps! The cost of complexity in software is real and this is a very practical post to share with would be customers of your software team. This applies to freelancers, consultants, and even teams inside larger orgs. We all have to account for our time, and that means accounting for the money being spent along the way.

Silas Reinagel: Recently, I led a 7-day highly-ambitious software project in which both the quantity and quality of work delivered blew away all my expectations. This is what empowered such incredible productivity. Click through for explanations of all 5 key factors.

Brad Armstrong lays it all out there about how to transition from an engineer to a manager: There are decades of books and thousands of blogs dedicated to trying to answer these questions, so I‘m not here to pretend that I’ve got the secret to success. But I do know a few ways that I’m pretty sure can guarantee you’ll fail. He takes you through 8 easy steps to failure. I’ll disappoint you now and spoil that step 1 is to keep coding 😱

Yegor applies a kitchen metaphor to code: The kitchen is clean when there is no dirt in the oven. But if its electric panel speaks French, I can’t use the kitchen. Even if it’s perfectly clean. It’s not clear how to use it—that’s why it’s useless. Sounds good to me, but how do you know if your code is actually clean and clear? He provides a heuristic: If a stranger can modify your code and fix a bug in less than an hour, it is maintainable. The entire post is well worth a read.

Lorenzo Pasqualis on why agile practices and vision must coexist. And why.

When you pull in a library dependency, it is rare that you need all of the functionality it offers. This isn’t usually a problem for backends, because that code never leaves the server. However, In frontend-land your users pay the price for all that unused functionality every time they hit your website with a cold cache. Moment.js is an excellent date/time library. It is packed with functionality, and you probably don’t need everything it has to offer. Instead, check out date-fns, which offers small, highly targeted functions you can probably get by with. There’s even an ESLint plugin that will help you identify places in your codebase where you don’t really need Moment.js!

What is flow? …a state of mental flow. Programmers live for it and work at their peak potential when they are in it. Also known as “the zone,” Flow is the mental state of operation in which a programmer is immersed in a feeling of energized focus, complete involvement, and enjoyment in the process of coding. Here’s a challenge — read this and apply just one idea to your work this week and report back in Slack how your work was impacted, positive or negative.

This contrarian post comes by way of the aptly named programmingisterrible.com. It’s a bit ranty, but I rather enjoy the author’s tone: If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever! He’ll take you step-by-step through why he thinks these generally accepted principles are often mistakes.

In response to a recent Twitter poll from Kent C. Dodds, Eric Clemmons shared concerns about how organizational boundaries are impacting where development happens. Kent tweeted… Hey folks who have a decoupled client-server application (no server rendering, server is just an API server). Where is your client code and server code located? (#) Together in one repo? In separate repos? Eric writes in his response on Medium: Software is like Jello: poke it in one place, and another place jiggles. In my experience, a repository should house all of the code necessary to make developing & shipping features relatively frictionless. This isn’t an exact 1:1, but this was a big part of the reason why Segment transitioned back to a monorepo.