Most software companies have to make decisions on whether to build a custom software or buy it from a vendor. In the last year I read many good articles on the web that helped shape my thoughts on how to approach these discussions. This article lists of questions that I have started to use to understand and make these decisions.
“The tests are timing out again!”, someone yells. “Alright I’ll bump them”, you instinctively respond. Then you pause and feel uneasy. Is there another way?
In this blog post, I share my growing disconnect with code-coverage and unit-testing. I then detail the method I’ve been using for the greater part of 7 years and how it still allows me to preach at length that being correct is the single most important thing for a developer.
This is an excellent article about understanding technical debt:
It is a fact that, over time, all development teams get slowed down by the existing codebase. But why? Is it because maintenance is inevitable? Or because we could do something better in the first place? Or both?
Luca argues that technical debt is introduced as a by-product of disagreement, which itself is a by-product of two phenomena: wrong design, and rapid evolution. Thoughtful stuff. Well worth your time.
In my 15+ years of web development, there are very few things I can say are unequivocally a good idea. It almost always does depend.
Storing timestamps instead of booleans, however, is one of those things I can go out on a limb and say it doesn’t really depend all that much. You might as well timestamp it. There are plenty of times in my career when I’ve stored a boolean and later wished I’d had a timestamp. There are zero times when I’ve stored a timestamp and regretted that decision.
Idempotence is the property of a software that when run 1 or more times, it only has the effect of being run once. I’ll describe a process I’m making at work, and describe the problems that idempotence will help avoid.
This is a nice, simple example (charging dormant customers a monthly fee) of how a slight change to the way you tackle a feature can make it idempotent, which is most definitely something you want your software routines to be.
Stefan Buck:
In this post I share my learnings of doing code reviews for 10 years. I have received positive feedback from my peers in the blog post and since code review is becoming more and more the standard of development I think sharing my learnings here will may help someone.
Number 10 introduced a new term for me. The “gangsta merge”?! 🤣
In this post, Tomas Wróbel lays out 10 potential drawbacks to the typical PR flows:
Jose Valim (the creator of Elixir) recently asked developers from all programming languages to contribute a solution to a short coding challenge based on a real world use case that I had come up while building an Elixir application. Here’s what happened.
Carlos Alexandro Becker joins Mat, Natalie, & Johnny to discuss the ins and outs of releasing your Go code. Carlos created and maintains GoReleaser, a popular tool that helps you deliver your Go binaries as fast and easily as possible.
It is always very tempting — and some claim “quicker” — to use primitives instead of creating new types. When we do this, we’re probably missing an opportunity to model a concept of the domain we’re working with — or, at least, to raise the abstraction level a little bit.
In this insight-filled episode, Bill Kennedy joins Johnny and Kris to discuss best practices around the design of software in Go. Bill talks through scenarios, lessons learned, and pitfalls to avoid in both architecture and coding of Go projects.
We’ve linked to exa in the past, but this post may convince you to give it a try by detailing its many virtues.
I believe exa is one of the easiest, most adaptable tools. It helps me track a lot of Git and Maven files. Its color-coding makes it easier for me to search through multiple subdirectories, and it helps me to understand the current xattrs.
In this post, I’d like to share alternative approaches for dealing with conditional rendering in React. I will try to list out the pros and cons of 3 different approaches (doesn’t mean couldn’t be more!) and hopefully this can be useful for you someday.
Matt E. Patterson writing for A List Apart:
The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. This costs dev time, slows release cycles, and saps the bandwidth for innovation.
What’s old is new again (with a twist):
a new WebSockets-driven approach is catching web developers’ attention. One that reaffirms the promises of classic server-rendered frameworks: fast prototyping, server-side state management, solid rendering performance, rapid feature development, and straightforward SEO. One that enables multi-user collaboration and reactive, responsive designs without building two separate apps. The end result is a single-repo application that feels to users just as responsive as a client-side all-JavaScript affair, but with straightforward templating and far fewer loading spinners, and no state misalignments, since state only lives in one place.
I won’t spoil the ending where Matt places his bet on the best toolkit to accomplish this, but let’s just say you’ve probably heard of it. Whoops!
Brad Dickason:
… teams consistently overlook speed. Instead, they add more features (which ironically make things slower). Products bloat over time and performance goes downhill.
New features might help your users accomplish something extra in your product. Latency stops your users from doing the job they already hire your product for.
Slow ui acts like tiny papercuts. Every time we have to wait, we get impatient, frustrated, and lose our flow.
When are microservices a good idea? Avery Pennarun shared a complete walk-through of modules, monoliths, and microservices.
Can systems design answer the microservices question? Yes, but you might not like the answers. First, we’ll need some history…
Michael Irogoyen:
Continued use of icon fonts is a detriment to your visitors and a time-sink for you. By replacing your existing icon font implementation with SVG icons, you’re helping people utilizing assistive technologies, improving the quality, clarity, and reliability of your icons, and reducing your time to maintain legacy assets.
He makes a compelling case.
Miroslav Nikolov:
I want to tell you the real story behind an ambitious two-month project my team completed, with a huge impact on our organization. A very stressful, challenging, and full of surprises journey, marked by developers being the leaders. I intend to reveal why things went bad and how with a proper smart set of decisions the front-end team managed to navigate its boat.
Stick around to the end for his best practices summary.
Sometimes you can’t make an informed decision because you don’t even know what should factor in to that decision. Shekhar Gulati is here to help provide those factors and he even produced this handy decision matrix for you.
If you maintain an open-source project in the range of 10k-200k lines of code, I strongly encourage you to add an ARCHITECTURE document next to README and CONTRIBUTING. Before going into the details of why and how, I want to emphasize that this is not another “docs are good, write more docs” advice. I am pretty sloppy about documentation, and, eg, I often use just “simplify” as a commit message. Nonetheless, I feel strongly about the issue, even to the point of pestering you:-)
The author points to rust-analyzer as a good example.
Austin Henley:
I wanted to test my mastery of Node.js and my reliance on Google and Stack Overflow, so I set out on an adventure to make a todo list web app without touching any external resource for help. I just couldn’t do it…
But this got me thinking. How many people out there, especially professional web developers, can do this?
I used to google for things all the time while programming, but not anymore. 😉
At this point probably everybody has heard about Docker and most developers are familiar with it, use it, and therefore know the basics such as how to build a Docker image. It is as easy as running
docker built -t name:tag ., yet there is much more to it, especially when it comes to optimizing both the build process and the final image that is created.
The article goes on to cover caching, slimming, and securing your images so they’ll run faster and be less prone to abuse.
Samuel Taylor (yes, that Samuel Taylor) shared a few things that works for him when joining a team and learning the codebase.
I have switched teams more often than I have had to implement an AVL tree, and you can guess which one of those two was taught in school. I wish someone had taught me how to join a new team! While learning a new codebase can be daunting, I’ve found a few things that work for me. You should do at least three things when joining a new team. The order of these three can be whatever you like, but all three should be done as soon as reasonably possible.
Tudor Girba unpacks the statement “developers spend most of their time figuring the system out.”
…reading is just the means through which information is gathered from data. It also happens to be the most manual possible way to do that, so this lends itself to an important opportunity for optimization.
Before you can do something significant about anything, you have to name it. Otherwise it’s like with Voldemort. Many winters ago, I called the effort of “figuring the system out to know what to do next” assessment. And I claimed we should optimize development around it. For a whole decade my colleagues and I explored this idea. And it led us to what we now call moldable development.
In this episode we talk about various types of writing and how we as Go developers can learn from them. Whether it is planning and preparing to write, communicating with team members, or making our code clearer for future developers to read through style guides.
