Work – Software and Other Shenanigans

Data ingestion sucks

Aug 312023

If you spend any time on any system that involves importing data, and you’ll likely have heard the phrase “garbage in, garbage out (GIGO).” It’s usually muttered (obscenities optional) right around the point a developer has given up on trying to “fix” the data coming into a system and willing to abandon users to whatever crappy, unusable, incorrect data they have floating around on their system. As long as whatever junk users were importing doesn’t actually break your code, let them suffer.

From the “stuff I screwed up” files – caching was a bad choice

Programming, Stuff I Screwed Up, Work No Responses »

Jun 302023

OK, so the phrase “caching was a bad choice” isn’t exactly something you expect to hear about software development. Generally, caching is a good thing – it improves performance by reducing calls to your database or external services, saving time and resources by not re-querying or re-computing. What’s not to love? Well, as with everything else in life, the devil’s in the details, and if you don’t get those right then anything can become a failure.

New approaches to skilling up future workers

General Commentary, Shenanigans, Work No Responses »

Apr 302022

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.

From the “stuff I screwed up” files – the missing email link test

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

Feb 282022

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.

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.

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.

The commandments of working with tickets

General Commentary, Work No Responses »

Feb 282021

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.

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.

Keeping your sanity while working from home with the rest of the family

Education, General Commentary, Work No Responses »

Aug 242020

I’ve seen a lot of bad stuff about how to best work from home (because apparently that’s not going to stop any time soon) floating around, either from people I know offline or being posted on social media. Given that most people were going into work every day, I’m guessing a lotheirt of employers were scrambling to define what they expected about working from home. Judging by some of the dictates I’ve seen come out, these employers they only really know how to operate off the “butts in seats” school of management. So, when faced with this brave new world of employees not being on-site anymore, they appear to have turned to how-to guides that were already out there online, which means they were pre-pandemic, when people working from home were generally there by themselves. Now that we’re all doing it, that’s a dumb assumption, but I haven’t seen anything that acknowledges the realities of trying to put in a productive workday with the whole family at home, so let’s revisit the whole “how to work from home” thing, shall we?

Older Entries