So I was working through an issue where I’m having to put together a multi-table query that gets run as part of a scheduled job, and as I’m taking a break after finding the XML file and getting this query (and resulting data mapping) added to said XML file, I come across this tweet, and it described exactly what I was feeling. Why was I shoving queries into an XML file shunted away in my resources
directory instead of just building it in the code? Surely there are better ways to construct SQL queries, right? Well, maybe, but in the end, what I was doing was probably better than I thought it was at the time.
Hotwiring a web application
I spent some time playing with Hotwire (for HTML Over The Wire) framework, mostly because it promised building a web application with minimal Javascript. As someone who’s largely a back-end developer and general Javascript non-enthusiast, that fact right there made Hotwire very appealing. Hotwire has absolutely delivered on its minimal Javascrip promise – in fact, I think it’s going to be my first choice for front-end development.
If you thought meetings were productivity killers, wait till you try development by committee
I’m no fan of “professional meeting attendance” as a career path, but at least that limits the damage it inflicts on an organization. Meetings can be skipped or at least you can bring a laptop and work through them. Sometimes, they’re actually useful. But I’ve never seen anything bring development to a grinding halt like having an external team demand the authority to oversee, and overrule, product decisions made by the teams that are supposed to own those products. When that happens, there’s a step in the development process that literally consists of “come to a full stop and beg permission to do your job.”
What it means to actually run an API
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. Continue reading »
None of this has been “in spite of working remotely”
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.
Of Newspacks and Substacks
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?
Targeted advertising isn’t the problem, but cross-site tracking is
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.
From the “stuff I screwed up” files – the scourge of the automated retries
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.
I got 99 problems, and environments are all of them
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.
Hydrick’s Laws For Software Development
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.