Tag: Think Big

Testing, Testing, 1, 2, 3

Testing, Testing, 1, 2, 3

Hard to believe it’s been 3 years since I started taking AWS Certification exams, eventually passing all 12 that were active at the time, thanks in part to virtual proctoring and a knack I’ve had since college for being good at multiple-choice tests.

In order to stay current one must retake the exams within a three year window, so I’ve been working my way back through them. Over the summer I passed Solutions Architect Professional and DevOps Engineer Professional, and yesterday I completed the Security Specialty. Thanks to lower-level exams auto-renewing when professional exams are passed, that brings me to 7 exams that will remain current through 2025.

Seven is a nice number; don’t think I’ll bother renewing the others unless a need arises.

Progress Report

Progress Report

At the beginning of this year I made two resolutions:

  1. Post on this blog at least once per month
  2. Learn a new programming language

For the first one, so far so good. For the second, not so much. I read a book on Clojure, but haven’t yet had a reason to use it beyond tutorial exercises, so can’t really say I’ve learned it. Maybe it’s just that these days I’m thinking more about systems than software, and thus language choices seem less important?

Speaking of book reading, though, I’m well on my way to achieving my meta resolution (to read the same number of books as my age, every year, for the rest of my life). According to Goodreads I’ve completed 39 books so far against a goal of 43 (seven books ahead of schedule). Should be no problem to get to the finish line and beyond.

Here are the five star highlights:

Honorable mention goes to Range, which I can’t recommend enough for anyone who feels like they’ve missed out on their calling by meandering through a number of life experiences. Generalists make the best leaders and problem solvers, so embrace the variety of perspectives you can bring to the table. Real life is not like golf or chess or programming only in assembly.

We’re All Just Folk Now

We’re All Just Folk Now

Back in 2014, I read The End of Men; having just been hired by a startup run by a woman, it felt like a good time to explore ideas about why men have traditionally dominated positions of power, and how and when that might change. I don’t remember many details about the book itself (and apparently it’s somewhat controversial in conservative and progressive circles alike), but I do remember coming away challenged to do my part in centering women as I moved forward in my career.

Fast-forward to this past week, during which I happened to have many interactions with female colleagues:

  • Two women presented a dashboard on team performance metrics to our team
  • I got career advice from the female founder of a major cloud consulting company
  • Three times I met with various female peers to discuss leadership transition opportunities
  • I provided coaching to a woman just beginning her career in technology
  • I partnered with a woman to conduct four back-to-back interview sessions

While there’s still more work to do to undo historic inertia, realizing that I’m surrounded by so many capable women from whom I can learn is an opportunity I hope only gets less rare.

Sharing Is Caring

Sharing Is Caring

Last week I recorded a Q&A video session with a colleague for an upcoming team all-hands meeting. Ostensibly we were there to speak on the benefits of a recently-deployed internal tool that’s become quite popular. But the value comes not from the tool itself, but from those whom it empowers to easily share their work.

https://stackoverflow.blog/2020/05/14/the-most-successful-developers-share-more-than-they-take/

Maybe it’s just the self-reflection inherent to middle age (I turned 43 a month ago), or the heartfelt email my team received this weekend from a recent customer, but in some small way I hope that when I’ve gone I’ll have contributed my portion to the ongoing corpus of human knowledge, and further, that I was able to utilize said knowledge for the greater good. The only way for that to happen is to maximally share what I build whenever possible, whether through open source code repositories, high-quality documentation, or even this blog (modest though it may be). It takes extra work, but the work is worth it.

Resolute Comprehension

Resolute Comprehension

I really like New Year’s resolutions. As a lover of habit, the beginning of a year is perfect time to calibrate a new routine. This year I have two resolutions:

  1. Post on this blog at least once per month
  2. Learn a new programming language

The latter was inspired by this article, which is stupidly long but thoroughly enjoyable. As a non-fan of OOP I found myself nodding along quite frequently. He advocates pretty hard for functional languages; while I’m familiar with the paradigm having used it in Python, I haven’t done much with purer forms. In 2022 I intend to change that, probably by learning Clojure.

Erlang and Go are also on my to-learn shortlist, the former for its first-class support for concurrency, the latter because it’s the new hotness for performant APIs.

In other news, I’m working on publishing my first CDK construct, which I’ll share here when it’s ready. I do wish I didn’t have to write it in TypeScript, but sadly I’m at the mercy of the JSII compiler. Why TS doesn’t have first class support for comprehensions boggles my mind. This is the closest I could get:

Array.from(nodeProps.entries()).map(e => new HyperledgerFabricNode(scope, `Node${e[0]}`, e[1]));

Compare that with a Python equivalent:

[HyperledgerFabricNode(scope, f'Node{i}', p) for i, p in nodeProps.enumerate()]

For shame, TypeScript. For shame.

It’s A Small World

It’s A Small World

Several weeks ago I recorded a half-hour talk for our big annual kickoff meeting. It turned out to be quite the production, with ring lights and lav mics and a team of people helping me set up and run the recording. Not to mention the time that went into prepping the content and having it peer reviewed and copy edited.

There was a moment amidst the mayhem when I wondered if it was worth it, especially considering all my other responsibilities. I briefly thought about calling it off altogether. But it’s an honor to be selected in the first place, so perseverance was appropriate.

Turns out it has been a singularly rewarding experience hearing positive feedback on the session. Not just from my own team, but from people all around the world. Twelve countries at last count (in order by timezone):

  • Myanmar
  • India
  • United Arab Emirates
  • Israel
  • Sweden
  • Italy
  • Switzerland
  • Germany
  • France
  • England
  • Brazil
  • United States

I happily responded to every email and Slack message, even had a couple quick video chats about it. Pretty darn cool.

The Lies We Tell Ourselves

The Lies We Tell Ourselves

I’ve written before about the importance of writing documentation. Like anything else it’s a skill that takes both training and practice. The latter only takes time, but there’s not a lot of material out there on the former. Therefore it made me happy to discover Write The Docs, a global community of people who care about documentation.

The recommendations in their Beginner’s Guide To Writing Documentation I found quite helpful. And loved this quote, which is only tangentially related to docs:

Fear is what happens when you’re doing something important. If you are doing work that isn’t scary, it isn’t improving you or the world.

The article argues that writing documentation for yourself and others is one way to alleviate fear, and I agree. So go forth and write!

Put A Bow On It

Put A Bow On It

I spent a bunch of time over the holiday cleaning up some Python tools I’ve written, and packaging them up for easy distribution via an internal PyPI repository.

The endless list of things to learn never ceases to amaze me, in this case I got to play with tox for matrix testing/packaging, and twine for publishing. Also got a lot better at writing setup.py files and integrating quality tools like flake8 and safety.

Here’s a couple helpful write-ups that I found when researching best practices for Python packaging:

Packaging a Python library
Python packaging pitfalls

In the course of the above, I also found it necessary to inquire about modifying an open-source tool for measuring code coverage. Turns out it was easy enough to make the modification and submit a PR to the maintainer. If you’ve never contributed to an open-source project, I highly recommend it!

No True King

No True King

Recently I’ve revisited thoughts I’ve had about what it means to be a senior engineer. One summary I came across that I liked was making the move from “delivering” to “leading”.

And another I gleaned from an email Eric Raymond sent to Linus Torvalds regarding the latter’s over-reliance on his own genius. While not sent in the context of senior-level engineering, I think it’s still informative of an attitude adjustment that must be made when taking on the mantle of leadership:

The bill always comes due — the scale of the problems always increases to a point where your native talent alone doesn’t cut it any more. The smarter you are, the longer it takes to hit that crunch point — and the harder the adjustment when you finally do.

There will come a time when your raw talent is not enough. What happens then will depend on how much discipline about coding and release practices and fastidiousness about clean design you developed before you needed it, back when your talent was sufficient to let you get away without.

I would add “ability to delegate and elevate the work of those around you” to that last paragraph. It’s hyperbole to say that every line of code written by an engineering leader represents a failure, but I coach up-and-coming senior folks to think that way nonetheless.

Out Of Sight, Out Of Mind

Out Of Sight, Out Of Mind

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.