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.
Like a lot of developers, I’ve worked on applications that solve business problems for almost all of my career (there was that brief time I worked for a government contractor). I’ve started to realize that there’s a lot of overlap between charities and businesses in terms of the general types of problems that they need solved. For starters, a lot of charitable organizations employ people to run the operation, so any employment/business management software would apply there. Then there’s the fact that there are certain types of problems that are universal to organizations trying to do something for other people. Businesses want to solve these problems to be better at making money, and charities want to solve them to be better at helping people, but they’re still the same classes of problems, and both of them could use cost-effective solutions to help them.
So how’s the whole remote learning thing working out for everybody? That’s a rhetorical question, people have no problem talking about how much they hate the whole setup. I get that parents want their kids to go back to school (or at least give them some peace and quiet while they’re trying to work from home), but not only have we been at this for a while, a lot of us are likely to still be at this, likely for the rest of the school year. It’s really frustrating, but now that we’ve moved from the “This is good enough to finish the semester and then next fall we’ll be back to normal” of spring 2020, to “Well, we actually did this for a whole year” (calendar year at least), it’s time to start having a little bit of a retrospective on virtual education, what does work, what doesn’t, how how it needs to change to be useful in the future.