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.
Election season is upon us yet again, which means it’s just about time for anyone who’s not registered as being affiliated with 1 of the 2 major parties to start hearing about how voting for anyone other than {speaker’s preferred major party candidate} is effectively voting for {candidate from the other major party that the speaker can’t stand}. It’s my biggest pet peeve of the whole process, mostly because the argument is stupid. Vote who you want to vote for, and if they’re not running under a “Big 2” ticket, then vote for them anyways, they’re who you want to vote for.
It’s real easy to get lost in the day-to-day of software development, especially if what you’re doing doesn’t fall under a heading that most people would call “game-changing.” As a result, we don’t really feel like talking about it. The downside to that is it means you’re not keeping your public-facing work updated with what’s going on, what technologies you’re using, or really anything else that would indicate that you’re still working at all. It’s tempting to go silent, but I’m beginning to think it’s good to just talk about the uneventful and non-noteworthy stuff, just to remind ourselves that the normal day-to-day is…well, normal.
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?
Generally speaking, when a software development organization says that they’re going or practicing agile development, they mean they’re following the Scrum methodology. Most jokes about doing software development have nothing to do idiosyncrasies of programming itself (Gary Bernhardt’s classic “Wat” presentation notwithstanding), but rather about dealing with Scrum. I get the frustration, As fun as it is to make fun of Scrum (and I’ve made my fair share of jokes about it), I really do think it’s a good development process (when done well), and that we would do well to keep it in mind. So having said that, here’s my attempt to defend Scrum.
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.
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.
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.
Continue reading »Whenever we write applications or services, we generally include some form of health check that we can easily (and regularly) poll to make sure everything is still up and running. That health check likely confirms that your code has access to everything it needs to function correctly. Well, generally that’s “everything it needs that its developers can control.” Rarely does our health check include external dependencies, even though almost all released software has dependencies that are outside the control of its authors. So, how do you tell when the external systems you rely on to work, don’t?
Continue reading »Steven Hicks retweeted a great thread by Marco Rogers on “full-stack developers” a little before Christmas last year. I was starting to ponder a post on how it was getting nearly impossible to be a “full stack developer”, but the thread covered a lot more than I was originally planning to, so I want to use it as a starting point. My original idea was going discuss focusing on front-end vs. back-end development, specifically how front-end development has moved away from “be able to write HTML/CSS/Javascript (optionally using jQuery)”, while Rogers’ Twitter thread (very accurately) pointed out there’s much more to the whole “full stack” thing.
Continue reading »