Tag: Think Big

Whoever Will Lose Their Life

Whoever Will Lose Their Life

Last month, my post on layoffs got 113 views in one day. I suppose that’s what passes as “going viral” around these parts. While I certainly wouldn’t mind more readers, I’m okay with my current reach.

How does that square with the principle of thinking big? The common way of considering scale is quantity; it’s certainly the easiest to measure. But one can have an outsized impact in quality without needing large numbers. Think of it like big in depth vs big in breadth. When it comes to technology I embrace breadth, but when it comes to impact, I value depth quite a bit more. And sometimes to get that result requires thinking small.

On my desk is the following photograph by Eric Peters. It captures my objective well.

Speaking of things on my desk, perhaps I’ll document my setup in a future post. That could be fun.

Eyes On The Prize

Eyes On The Prize

“Only those who will risk going too far can possibly find out how far one can go.”

T. S. Eliot

Yesterday I finished To Flourish or Destruct, and with that I’ve completed year one of my meta-resolution: reading 43 books, the same number as my age.

I’ve also successfully written on this blog at least once every month, another of my resolutions. This is my 31st post, so I’ll finish the year no worse than averaging 2.5 posts a month, a pace I’m happy with.

However, I haven’t ended up learning a new programming language this year, my other resolution. And that’s okay. Not because ChatGPT stands to replace coders soon (spoiler: it won’t), but because while goals should be SMART, they needn’t all be actually achieved. The goal of resolutions is not absolute completion, but inspiring yourself to accomplish something. To move the needle positively for your life. To take a step towards become a fully flourishing human person, as Christian Smith would say in the book I just read (echoing Aristotle 2300 years before him).

While each goal in and of itself should be achievable (the A in SMART), in aggregate they should be aspirational. When discussing goal setting with my team, I want them to define enough goals for themselves that it’s likely there’s one or two they won’t complete. Otherwise they’re not thinking big enough.

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!