I wrote recently about how what most of us build as back-ends aren’t really APIs, but just a back-end that provides data to your Javascript. I’ve emphasized the fact that a basic RESTful back-end is not, in fact, an API, and that there are differences between how you build and run the 2. However, there are also very important similarities to REST back-ends and APIs that you need to remember.
So a (semi-) local coding boot camp is going to be trying something that I really hope works out – partnering with a local company to sponsor and ultimately hire the graduates. I love this idea because of the way it shifts the financial risks in training people for future careers, the direct contrast it puts colleges in, and the fact that a set up like this is inherently designed to make the “graduating class” more successful, and not just because a higher percentage of them got their first job quickly.
Something broke with our approach to disagreements. We went from simply arguing with people who were wrong on the Internet to to demands that people be deplatformed because they’re wrong, according to people who seem to be right equally rarely. Thanks to the aggregation of content onto a few major platforms, a few people have the arbitrary ability to make other people vanish from public discourse. At this point, it’s impossible to tell who’s right, who’s wrong, and who’s been disappeared for having views deemed “unacceptable” by people who have no business making that determination. It’s starting to seem like the reason you can’t trust just anything you see online has moved from “anybody can post anything on the Internet” to “because publishing anything too contrarian will get you kicked off.” That’s not good.
I was working on hotfix that turned hotter than I wanted during the deployment, all because we missed an important test case that left us scrambling to resolve an issue during the deployment that we should have caught earlier. We got lucky and fixed it during the deployment, but we shouldn’t have been in that position because the scenario that failed was a known requirement, which means we should have tested it. So what happened? Well, point blank, we forgot a test case.
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.”
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 »
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.