Programming – Page 3 – Software and Other Shenanigans

What it means to actually run an API

General Commentary, Programming No Responses »

Oct 312021

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 »

From the “stuff I screwed up” files – the scourge of the automated retries

General Commentary, Java, Programming, Stuff I Screwed Up, Work No Responses »

Jun 302021

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

Java, Programming, Work No Responses »

May 312021

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

Programming No Responses »

Apr 302021

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.

Tuning Java lambda cold start performance

Java, Programming, Work No Responses »

Mar 312021

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.

Rock stars and ninjas are overrated, be a plumber

General Commentary, Programming, Work No Responses »

Nov 302020

Anyone remember back when companies would try to be “cool” by advertising that they were looking for a “ninja” or “rock-start” software engineer? Thankfully, those days really are just memories (hopefully the days of the “10X egnineer” will go extinct soon, too). These terms were stupid as job titles because they had no bearing on what you actually did for a living. A “rock star” means that you spent some amount of time being playing in the Silver Bullet Band. And if people know that you’re a ninja, then you were really bad at it. I suppose these job titles stemmed from words people used to describe some the better developers where they worked, but there’s a difference between internal compliments and an actual role at a company. That said, the most useful role within any company is probably the programming equivalent of a plumber.

Don’t try to out-think your users

General Commentary, Programming No Responses »

Jul 042020

Few things are as annoying as when you have a device that tries to be helpful and is completely, and utterly, wrong. Not only are you not gaining any convenience, because you still have to go back and fix it, but psychologically it feels worse because instead of making things better and doing things automatically for you, you’re having to go back and do it yourself anyways. If these were settings users can easily change, then it’s a minor inconvenience because we can update a configuration and be done with it. Sadly, that’s not the case, especially with devices that are supposed to be “smart” and thus figure it our without us having to do anything, or software that doesn’t expose these settings to users.

You need 3 administrative consoles

General Commentary, Programming, Work No Responses »

May 312020

1 of the most iconic components to running software in production are consoles full of graphs and metrics about how that software’s performing. Generally, they’re called “dashboards,” but in my experience you want something that provides the ability to act on the data being shown on the console as opposed to a dashboard which is generally read-only. That action could take the form of filtering or drilling down on the data being shown, or triggering some administrative task. Like with everything else in life, 1 size, or in this case 1 administrative console, doesn’t fit all. If you group the different types of users who have a need for an administrative console, you’ll find they fall into 3 general personas.

Monoliths and service-oriented architectures

General Commentary, Programming No Responses »

Apr 302020

For some reason, I’ve been seeing a lot of people piping in and saying and/or predicting that monolithic software architecture is going to be making a comeback starting this year. It probably doesn’t help that once I started reading the first article about companies moving from services to monoliths, Google kept highlighting more, but I think the impetus of this was Kelsey Hightower’s unpopular opinion segment arguing that most companies that switch to service-oriented architectures end up creating “distributed monoliths” that are the worst of both worlds. By the way, you’ve likely noted that I’m just using the term “service-oriented architecture” (OK, “SOAs”, because I’m lazy) for both service-oriented architectures and microservices – that’s just to make my life easier – as far as I’m concerned a microservice is just an SOA service with a very small scope.

The Truth About “10X Engineers”

General Commentary, Programming 1 Response »

Sep 302019

A couple of months ago, developers on Twitter started spamming jokes or frustrations about the mythical “10X engineer” in response to this tweet by a startup investor from India. Thankfully, outside of this guy’s original tweet thread, nobody else was buying the “10X engineer” nonsense. Unfortunately, the fact that this guy tweeted it in the first place means there’s too many people out there laboring under a delusion that desperately need to be set straight.

Older Entries Newer Entries