Continuing from Q1, Q2 36. “How Not to Be Wrong: The Power of Mathematical Thinking” – Jordan Ellenberg I thought this was a good example of how STEM communication can work well. The author introduces concrete, everyday problems then provides the math and logic to work through them. That is surprisingly rare in STEM comms. 37. “The Hundred Thousand Kingdoms” – N. K. Jemisin I’m on a N.K. Jemisin tear this year.
This is a continuation of what I started with “Books from Q1 2018“. 19. “Semiosis” - Sue Burke I really enjoyed this book. It’s basically “if a botanist wrote sci-fi” and felt very fresh as I haven’t read anything in that vein before. It does suffer somewhat from what I call Clarke-Doctorow syndrome – a condition in which the quality of the ideas presented vastly exceeds the quality of writing.
Microservices can be awesome. Splitting up your monolith to scale services independently, accelerate change, and increase resiliency can reap huge returns. The agility that well-implemented microservices provide is one of those things you look back on and think “How did we manage this before?” Microservices can also be terrible. If implemented poorly, they can cause more problems than they fix and create unmanageable chaos. I’ve seen both scenarios, but failed microservice projects outnumber the successful ones I’ve come across.
Because spinning up VMs in the cloud is so easy, it’s equally easy for your monthly bill to scale up as well. What may have started as a few hundred dollar-a-month charge for a few VMs can quickly ratchet up into tens of thousands of dollars. In larger businesses, I’ve seen this get so bad that management freaks out and moves everything back on-premises, even when the growth was legitimate and not the result of waste or mismanagement.
I’ve been reading more than writing so far this year. I tend to go in bursts like that – lots of writing, lots of reading, lots of Netflix, repeat. I’m not sure why, it just happens. So far this year, I’ve read 18 books, a mix of fiction and non-fiction. I’m putting together notes on what I’ve read so I can come back to them and so they might be useful to others.
Leaving a job is hard, and oddly enough, it gets harder each time you do it. When you’re new to the workforce, you don’t know enough to appreciate what you might be leaving behind or worry about what you might be going to. As you get older, that changes. You know how hard it is to build relationships and find your place. You know how stressed out you’ll be for the first six months in the new job, fighting against imposter syndrome and the uncertainty of new territorial politics and personalities.
I’ve never been at O’Hare for what anyone would consider a layover. It’s always been more a “desperate sprint from one far-flung terminal to another”. Wandering through terminal C, looking for somewhere to grab a drink and food, therefore, feels novel. The high arched ceiling of the main corridor alludes to gothic cathedrals. The niches and warrens that house shops, bars, and cafes strengthen that tie. Unfortunately, the limited space also makes it hard to find somewhere to sit.
A few months ago, a recruiter sent me a LinkedIn message with a link to a recruitment video. I’ve been seeing more of these lately, but this one was particularly impressive at how quickly it turned me off from the company. It described their idea of a tech utopia, a place where developers could use whatever technology they desired. “Read a blog post about something new in the morning. Deploy it to prod in the afternoon.
Some background: I previously wrote a python lambda function that copies AWS RDS snapshots to a different region. This has been working for months but recently started throwing this obfuscated error: Thinking this might be due to some timestamp shenanigans, I looked at the Cloudwatch Events trigger for the lambda and saw that there were two triggers instead of the original one that I setup. Both were scheduled for the same time.
I’ve been trying to flesh out my Python knowledge and learn more about machine learning(ML) in the process. Most of my day-to-day Python use is focused on text manipulation, API calls, and JSON parsing, so leveling up on ML is more math (specifically stat-related) than I’m used to. Today I played around with the NumPy Python package a bit and figured out some simple things. For example, if I wanted to multiply the numbers in two lists with vanilla Python, like this: