I’m a sucker for gamification, so when I saw today’s announcement that AWS Certification badges could now be collected and published on a little profile page, I was all over it.
Nine certs in nine months so far, and I’m taking a tenth exam tonight. Wish me luck!
Every branch that bears fruit, he prunes it so that it may bear more fruit.
– John 15:2
Deleting code feels so good, especially when it’s code I’ve written. It’s an emotion predicted by the Creator’s Curse, and it also make sense under the lens of this article, which challenges developers to write code that’s “easy to delete”.
Too often, especially in academic settings, or with inexperienced engineers who don’t have the experience of the dirty hacks required to keep an actual real-life system running, there’s a view that good software engineering practices are like the Ten Commandments, never to be violated. But for every rule, there’s any number of exceptions, and I loved the way the author laid out these tensions.
I feel like I say “_______ is hard” a lot, so forgive the repetition, but today’s article illustrates that service design is hard. The “micro” in microservices leads many (including myself at times) to believe each service should be as small as possible. It’s an unfortunate name, because that’s not the truth (naming things is hard too, but I digress).
What’s the right size for a Microservice dispels the above myth and several others, on its way to presenting a few helpful criteria to size a service. For anyone who designs systems, or builds systems, it’s worth your time.
And while you’re add it, read Martin Fowler’s paper on the topic.
And further, from these, my son, be warned; the making of many books hath no end – Ecclesiastes 12:12
One could spend the entirety of their waking hours reading articles on software engineering. While I try to keep up the headlines, I aim to limit myself to 10-15 minutes a day. Anything more proves a burden.
Over the past couple weeks there’s been a few discussions I’ve found particularly helpful. The first, On Being A Senior Engineer, echoed thoughts I’ve had for some time. I do believe the title of “Senior” is handed out too quickly in many parts of the software development world. This probably makes me sound like an angry old man, but no one should be called senior until they have at least ten years under their belt, if not fifteen. To quote Andy Jassy, “there’s no compression algorithm for experience.”
I also appreciated the article’s emphasis on sponsorship. Being a senior engineer in my view has little to do with your technical breadth or depth. The step up to senior means that you’re now looking to expand your influence beyond what your own two hands create, whether that be being a team lead, one-on-one mentorship, or participation in the larger development community. Senior engineers recognize that building great software is a human activity, and develop their soft skills.
Finally, a crucial aspect of being a senior engineer is humility. I view this as a complement to what Larry Wall famously said, and not in contradiction. It takes maturity to know what you don’t know.
“When two things are not the same, then they are different.” – Jud
A popular discussion topic these days is how society will change due to the COVID-19 pandemic. One obvious likely outcome is even more will be accomplishable online, for example, the AWS certification exam I took from the comfort of my armchair this past Saturday morning. I thought I’d share my experience, and a few specific recommendations (in bold).
The process started with the normal scheduling workflow via the AWS Training website. Once that was complete and I paid the fee, I got an email with a link to instructions on how to run a system test. The recommendation was to do this right away, which I did. This involved installing a local application, verifying my laptop’s webcam and microphone worked, and testing my Internet bandwidth. Given that the application will completely take over your machine, and you must close all other running processes, I’d recommend using a personally-owned computer for this, and not a work computer (especially if you don’t have local admin).
Also as part of the above process, I had to take a picture of my face, my driver’s license (both sides), and four photos of the location where I’d take my exam, one from each of the front, back, left and right. A link sent to my phone via SMS guided me through these steps (so have your phone handy); it went quicker than I expected, and the photos were automagically submitted. Nice!
The day of the exam, about 15 minutes before my scheduled time, I closed everything on my personal laptop, and launched the client app. And here’s where I had my first hiccup: the app required that I upgrade to the latest version. This meant re-downloading and re-installing, which was annoying; I wished the app could have streamlined that process. Once the update was done, I had to go back through the entire system test process (including taking all the photos mentioned earlier). This was annoying, and made me wonder if the earlier test was even worth taking. At minimum, you want to be sure to get started at least 15 minutes before your scheduled start time in case you run into issues.
Once I got upgraded and back through the system test, my webcam became active and indicated I was being recorded. From this point you cannot leave the room (or move out of view of the camera), or open any other applications. I had to wait in this state for about 5 minutes before I was put in contact with a proctor, first via chat, and then via phone call. Be prepared to sit in silence for a bit while you wait. For a final verification I had to do a sweep of the room with my webcam to show it was empty of both other technology and other people. Be sure at this point that everything and everyone is out of the room. I even unplugged my extra monitor, just in case.
As I tried to launch the actual exam, I hit another problem. The app detected instances of chrome running in the background, even though I thought I’d closed everything. I had to go into activity monitor and kill them all before the test would launch. So, it’s worth looking through activity monitor right before you start to avoid this hangup (though the proctor was friendly and patient with me, which I appreciated).
(Oh, and speaking of things to do right before you start, use the restroom and get a drink of water right before you settle in; absolutely no breaks or food or drink are allowed).
Finally I could load the exam and begin. It’s a bit nerve-wracking to be video-recorded, but after a few minutes I tuned it out. You do need to be conscious not to look around the room, else the proctor might ping you to hold still (this didn’t happen to me, but I read about it). The test interface itself was pretty much like the in-person experience, with the ability to skip ahead, flag questions for review, etc.
Once I completed the exam, there was a survey, just like the in-person experience, and I was given the results (I passed, woot). Then the app closed and I was done. Piece of cake.
Even given the gotchas, I’d say the experience is easier and more convenient than scheduling a time with an in-person testing center, driving there, etc, if for no other reason than the available time slots for online proctoring ranged across all days of the week, and nearly all hours of the day (want to take your exam at 3am? knock yourself out). I’ll definitely use this online proctoring again, probably exclusively, as long as I have option to do so.
Have you been thinking about getting AWS certified? If so, I’d encourage you to go right now and get a date on the calendar. You’ve nothing to lose, and it’s now easier than ever.
Are you using the AWS Cloud Development Kit yet? If your job ever involves creating or maintaining infrastructure (on AWS, natch), you absolutely should be. Take the power of CloudFormation (minus the annoying parts) and mix it with the familiarity of your favorite programming language (Python, am I right? Yes I am. But TypeScript, Java, and .NET are also choices), and you get a killer option in the burgeoning Infrastructure as Code toolbox.
Instead of spending a bunch of time telling you why the CDK is so great, here’s some resources to help you to discover so for yourself:
Happy building!
Have you ever looked at a heavily object-oriented codebase (Java, I’m looking at you) and immediately felt dumber? Did the design patterns touted as the ultimate in software craftsmanship sound amazing when you studied them in school, but now every time you see them in real projects they result in layer upon layer of confusion?
There is no one approach to rule them all when it comes to software development, and while I wouldn’t be quite as hard on object-oriented programming as the articles linked above (yes, there are multiple ones), it’s not the only, best, or even appropriate pattern to use in all circumstances.
AWS provides a number of fantastic managed services that make building applications quick and easy. At least for the most part. But there are plenty of interesting gotchas, and instances where the underlying details matter.
This past week I was working on an app that used the Simple Queue Service (SQS) to exchange messages between components, and I had implemented long polling to reduce the cost of repeated API calls. I’d also set a long visibility timeout because the processor took a significant amount of time to handle each message.
During the course of testing I was finding that messages were getting stuck in an “in-flight” state; given the long visibility timeout, this was causing delays in processing because the handler had to wait for the timeout to expire for these stuck messages. But I couldn’t initially figure out why the messages were getting stuck in the first place. I only had one handler thread; why were messages getting pulled in flight, but not getting processed and eventually removed?
It turns out the reason was that in the course of testing I was regularly killing off the handler with Ctrl+C and restarting it. And that terminate signal was cutting short the long poll API call into SQS. Why did that matter? Because a long poll call fires off a process on the AWS servers that is waiting for messages to show up on the queue so it can return them. That process continues to run even if the client that initiated it dies. Thus if a message shows up on the queue after the client goes away, but before the long poll time expires, it’s taken off the queue as “in flight”, but sits there until the visibility timeout hits because there’s nothing to subsequently process and delete it.
I was unable to figure out the above until I learned more about what actually happens within AWS during an SQS long poll. Finding this thread about the Node.js client helped too (I was writing my client in Python but the behavior is common across all SDK implementations). If I’d only been able to reason at the level of the queue abstraction, I’m not sure I could have solved the problem. Once again, descending into the particulars was the path to a solution.
Today I came across this statement from Alfred North Whitehead, and instantly loved it as an extension of my previous post on abstractions.
“Civilization advances by extending the number of important operations which we can perform without thinking about them.”
That to me is the essence of abstractions. Not that one needn’t ever be required to dig down into the implementation details, but that the layer on top of those details enables them to be ignored to an increasing degree.
Incidentally, this is the second Alfred North Whitehead reference I’ve come across recently, the first being a mention of his book Science and the Modern World in one of my favorite podcasts. Something tells me I need to dive deeper.