It’s really popular to say we’re writing web services, built on top of RESTful APIs, but the reality is what most of us are really doing is writing web applications that make REST calls back to that app’s server for data, not actually calling a generalized web service with multiple sets of users. That’s fine – I use web applications almost all day just like everyone else. Occasionally we need to actually get some data from another team’s data store, and it’s cool, they have an endpoint you can hit and get it. See? Web services with RESTful APIs. The problem is there’s a difference between, “There’s an endpoint that can give us that data” and running a service who’s purpose is to be used by anyone other than the team that wrote it.
1 of the biggest gripes I’ve had lately is people describing working remotely as some sort of impediment to companies being successful. It may not have been something your organization wasn’t doing before and had to adjust to, but for office jobs, working remotely is something that’s been entirely possible for years. In fact, companies like StackOverflow and Basecamp have not only been remote for years, but have written about being successful remote companies extensively, for years (Basecamp even literally wrote a book on making remote work, work). Remote work had slowly been growing in popularity before the pandemic as people started pushing for the flexibility and to drop the requirement to either deal with long commutes or living in expensive cities.
A couple of years ago, Automattic (makers of WordPress, which powers this blog), Google, and some news-related organizations announced Newspack, a publishing platform that was supposed to be “WordPress for news organizations” (per their site). The original announcement, like all new product announcements, sounded very promising – a publishing platform that had best practices built right in, a curated list of plugins designed to support news organizations, all built on top of the platform that most of the web already runs on. So how did Newspack seem to peter out, especially when other publishing platforms, like Substack, take off?
DHH (of Basecamp and Ruby on Rails fame) wrote a blog post in May titled Targeted ads are staggeringly unpopular so we should ban them. The basic premise of the post was that people hate being tracked online and so many people have opted out of tracking that it’s clear the practice is so unpopular that it’s time to be banned. I think DHH is right about tracking being so clearly unpopular something needs to be done. I don’t think banning targeted advertising is the right thing to do though. The fact that I used to work for an email marketing company (whose product has since been shut down) that promoted targeted email marketing messages probably may have influenced that position, but I think the problem is less the act of targeting an ad, and more how we go about targeting.
We all screw up, it’s part of life. What’s important that we learn from it all. I’ve found it’s generally better to document the learning, both to help internalize it, and to share it with who I can. I recently worked an issue stemming from automated API call retries that didn’t go nearly as well as it probably should have, and I wanted to take a little time to post-mortem on how everything went, and how it could have gone better. A lot of this is fairly specific to what I was doing with that particular problem, but there’s hopefully some general lessons that can be drawn from the whole ordeal.
We’re all used to dealing with different environments in our code. On the surface, this just means that we need to make sure our code runs fine in all of our environments. But what about the other services that your code is consuming? If your reaction is that it’s the responsibility of the team writing and running that code to make sure that it’s up and running, you’re living in a fantasy. At some point, you have to write (and maintain) your side of the connection to those services, and if something goes wrong, you have to be able to show the issue isn’t on your end. Oh, this is assuming an exact 1-1 match between your environment and their environment (for example, your dev to their dev, your QA to their QA). Even if the external environment doesn’t use the same naming conventions as you, having each of your environments connect to 1 (and only 1) environment of an external service simplifies things exponentially. If people are asking that you update your code to point to other environments of your dependencies, your life gets complicated fast.
Not too long ago, my friend Warren tweeted a link to Atkin’s Laws of Spacecraft Design. That in turn got me thinking about Peter’s Laws: The Creed For The Sociopathic Obssessive Compulsive (which I had in poster form for the better part of a decade), and that inspired me to think of truisms I’ve learned about software development over the years. I may not have enough to fill a full 20+ (or even 40+) item list, but maybe I’ll update and add to it over the years. So without further ado, I present to you, Hydrick’s Laws For Software Development.
Cryptocurrencies changed the game in terms of currencies, bringing money forward into the Internet age. Since its introduction in 2008, Bitcoin has redefined how people buy and sell online. Since Bitcoin’s initial introduction, we’ve seen more cryptocurrencies enter the market, from Ethereum to Dogecoin. And now, I’m pleased to announce a thrilling new cryptocurrency designed for artists and young professionals just starting out…Exposure.
During some recent performance testing at work, we noticed an endpoint showing slower than usual response times. Digging into the calls, we found that on slow responses, virtually all the time was spent on waiting for a specific lambda function to return data. Digging into that function we found several calls that appeared to be timing out, and many others that were taking 9-10 seconds. This lead to a day or 2 spent reading up on the workings of AWS lambdas and how they work with Java. What was probably most striking is that while the solution to our problem was eventually findable with some Googling – and the “fix” involved practices that are mentioned in the official AWS documentation – they’re almost mentioned in passing, and don’t call out the performance impacts they have on your billed runtime.
Software development is like a lot of jobs, in that there’s some sort of system that lists the things you need to work on. Doctors and lawyers have appointments, technicians have calls, and software developers have tickets. It’s a fairly basic idea, open whatever ticket tracking software you use, find the stuff that’s assigned to you, do the work, move the ticket to the next step in the process when you’re done, rinse and repeat. That said, it’s still easy to create unnecessary problems for yourself just by getting lazy when working with tickets. So with that in mind, here’s a few “commandments” that will make the administrative part of your life easier.