Get Used To It
I was skimming over a few old posts, and came across this recap of the past year, which closed in a way that sounds quaint at best:
I’m eagerly anticipating the new normal of 2020. More to come!
Yeah, not quite what I meant.
A Virtual Bank Is Still A Bank
Recently I was attempting to set up automatic payments with a utility company via their website. I dutifully entered my bank’s routing number and my account number, but when I tried to submit, I was told the routing number was invalid. I double-checked it with the bank’s website, but I still got the error.
Being something of a nerd, whenever I run into trouble like this on a website, I open up Chrome’s dev tools to see what’s going on. Turns out the UI was sending the routing number to an API endpoint that ensured it belonged to a real bank before submitting the form. For whatever reason it appeared this API didn’t have my bank in its database.
Which made me wonder if I could twiddle the site’s Javascript to skip this API call and submit the form anyways. Lucky for me they didn’t perform any minification, and it was straightforward to bypass this verification step. When I did so, the form submitted just fine and told me automatic payment setup was complete. I suppose I’ll find out on my next billing cycle if it worked, but I bet it will.
Three takeaways from this little adventure:
- As I said a few days ago, I’m glad to be the kind of person that has both the knowledge and curiosity to solve a problem like this, instead of falling back to an interminable customer support call.
- If you’re going to put a blocking validation process in front of your customers, you better be darn sure to get it right, especially if having it fail means a loss of potential revenue.
- Client-side validation is only a convenience, and Javascript is easily manipulated (even if minified, but honestly people, minify!) Server-side validation of all input is absolutely essential.
Perdido En La Traducción
Today my kids had to choose between virtual and socially-distanced on-campus learning for this fall semester (thanks COVID-19). The selection process involved picking their high school from a drop-down on the district website. Oddly we couldn’t initially find their school (Del Norte) in the list.
Why not? Well, it turns out that Google Chrome’s auto-translate feature was attempting to be helpful, and transformed it into “From North”. Which made me realize three things:
- I’m really thankful to be techie and able to debug such issues, because I imagine this will cause confusion for those less clued-in to potential browser oddities.
- It’s really hard for computers to do be “smartly” helpful in a transparent way; if an algorithm isn’t darn near perfect it’s likely to do more harm than good.
- The implementor should have added
translate=noto their<html>tag to avoid this problem altogether.
Descend Into The Particulars
When I’m asked about interview advice, one suggestion stands far above the rest: be specific.
I want to hear real stories about events that actually happened, not hypothetical situations you might come across in the future. Having a real story to tell that only partly addresses the question is better than a direct answer with no experience to back it up.
Tell me the actions you individually took in the situation, not what the team generally did. A job interview is not the time for false modesty. Be humble and honest about it, of course, but you’re the subject of the interview, not your colleagues.
Explain not just what you did, but how the situation turned out. What were the actual results? If you have metrics or other data you used to measure the outcome, even better, and if you can quote actual numbers, that’s the holy grail.
Finally, what did you learn from the experience, and how would you apply that to future situations? A discussion on learnings is never out of place, no matter the interview question.
Bonus tip: don’t be afraid of negative examples. No one is perfect, and most future successes are predicated on prior failures. As long as you can articulate how the situation changed you for the better, it’s a plus in your column.
Three Things I Like
I like AWS. So much so, I decided to work for them.
I also like Python, as I’ve said many times.
If you want to learn them both in a beautiful amalgam, consider the Learn Python On AWS Workshop.
We’re All In This Together
I went far too many years into my career before truly trying to understand networking, despite it being an increasingly common source of problems. If I could give younger self some advice, I’d recommend taking some time to learn networking.
In that spirit I present to you How DNS Works, a “fun and colorful” comic that describes in detail the operation of the Domain Name Service. Enjoy!
Badges Badges Everywhere
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!
The Dark Side Of Reuse
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.
Design Like Goldilocks
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.
Hitting The Links
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.