I’ve been sitting down and spending some more time with the Hotwire framework after building an initial proof-of-concept and moving towards a simple 0.1 version of something. I still really like the framework, mostly because it simplifies a lot of development, without feeling like I’m sacrificing anything. Not only am I not doing as much work in the front-end, but the advantage of server-side rendering means there’s little to no state to manage in the front-end, which seems to be a huge part of front-end development. Moving from the “standard” way of writing a static webpage and populating it based on JSON data to rendering the page on the server-side is a change in how back-end development gets approached, but really it’s not as much as you may think. I stand by my comments in my original post – Hotwire is my first choice for a front-end framework.
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.
From the “stuff I screwed up” files – the missing email link test
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.
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.
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.”
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.