Tag: Are Right A Lot

Meta Post

Meta Post

Really enjoyed Two Heads Are Better Than One, a discussion of the various ways technology has allowed humans to have “second brains.” I realized in some ways this blog is one such implementation; it’s a place I can capture thoughts and stories so that I can recall them later without keeping them in working memory.

As a bonus, via the article I discovered Obsidian, which I’m now dying to try out. I’m a sucker for Markdown and the power of plain text processing tools.

Expect The Unexpected

Expect The Unexpected

Like many other languages, Python has the notion of default values for function parameters, for example:

def compute_final_price(cost, sales_tax_rate=0.08):
    return cost * (1.0 + sales_tax_rate)

This code behaves as you would expect:

compute_final_price(10.0, 0.07)  # returns 10.7
compute_final_price(10.0)  # returns 10.8

However, interesting things happen in more complex cases, because the default value is evaluated once, at the time the function is defined, and not when it’s executed.

my_rate = 0.05

def compute_final_price(cost, sales_tax_rate=my_rate):
    return cost * (1.0 + sales_tax_rate)

compute_final_price(10.0)  # returns 10.5
my_rate = 0.06
compute_final_price(10.0)  # still returns 10.5

You can prove to yourself the value is evaluated at definition time by running help(compute_final_price), and you’ll notice the default value has already been computed:

Help on function compute_final_price in module __main__:

compute_final_price(cost, sales_tax_rate=0.05)

The above can be pernicious if the default value is an object that’s modified inside the function:

def add_to_list(item, my_list=[]):
    my_list.append(item)
    return my_list

add_to_list(4, [1, 2, 3])  # returns [1, 2, 3, 4]
add_to_list(1)  # returns [1]
add_to_list(1)  # returns [1, 1]

A common workaround for the above is to do the following:

def add_to_list(item, my_list=None):
    if my_list is None:
        my_list = []
    my_list.append(item)
    return my_list

add_to_list(1)  # returns [1]
add_to_list(1)  # returns [1]

I’ve encountered folks that insist one should never use default values except for None and the above pattern, but I’ve found most of the time I’m not mutating such defaults, and the behavior described here is fine. But still, the more you know.

Into The Sunset

Into The Sunset

I’ve mentioned before my penchant for minimalism, which is why for the past 8 years my code editor of choice has been Atom (in fact, I may have been a beta tester for it, my memory’s a bit fuzzy on that point). Which is why it bummed me out a bit to read it’s being shut down at the end of this year. Technology marches on, I suppose. I can’t blame GitHub Microsoft for wanting to consolidate development effort in their fully-featured IDEs, especially integrated cloud-based solutions like Codespaces.

Still, I’m going to miss Atom’s simplicity and customizability (I’d even contributed to a few plugins). It was robust enough to be a complete development environment (for my coding style, at least), yet snappy enough for quick one-off text file editor. For the former case I’ll probably get back into VSCode, and Sublime Text ought to do the trick latter. Though maybe I can use it for both?

Crossing The Rubicon

Crossing The Rubicon

There are a plethora of resources for those just getting started with software development, and best I can tell, most of them will do the job adequately well. But there isn’t nearly as much on what is needed next: guidance on how to get from “early intermediate coder” to “seasoned software engineer”. In brief, here are some suggestions:

  1. Study existing high-quality code; if you don’t know what good looks like, it’s nearly impossible to produce it.
  2. Write a lot of code. There’s no substitute for practice and putting in your time.
  3. Find someone who can give you feedback on the code you write, and humbly iterate per the guidance.

In my experience, an efficient way to do all three is to find a couple open source projects that need support, dig into their code, and submit contributions. You start from a base of quality code, get to write more, and you’ll get feedback through pull requests. And the icing on the cake is that it’s all done in public.

Spend a few years of doing the above and you’ll be well on your way to next-level programming expertise. It’ll also teach you how to code with a distributed and decentralized community of stakeholders, and that’s no small thing.

Public Service Announcement

Public Service Announcement

This is a slash: /

This is a backslash: \

Website URLs have slashes. If you say “backslash” or “forward slash” when describing a URL, I will judge you.

That is all.

Automatic For The People

Automatic For The People

When I quit my first job after nearly 12 years, it was a shock to lose access to all the software I’d spent years developing. While I believe strongly in Egoless Programming, and resisting the notion of “my code”, so much reference material I’d built up was suddenly lost to me. I decided in that moment I needed to build up a portfolio that could not be taken away.

A few weeks ago I published Chrome Local Storage, a Python package that can read from and write to the Chrome’s browser’s internal storage, either one running locally or on an Android mobile device. The first draft didn’t have any CI/CD automation in place, but this weekend I fixed that.

It now automatically sets the version according to the git tag, runs some limited automated tests, runs a linter, scans both the code and dependencies for security vulnerabilities, and publishes builds to PyPI. All via Github Actions.

Did this project really need a complete pipeline? Not really, I doubt I’ll see much reason to modify it in the future. But I wanted to learn Github Actions, and I’d wanted to learn Poetry. Now I’ve done both, and have a publicly available reference to which I’ll always have access for when I need to build Python packages in the future. And if others need the same, they can use it as well.

Throwing In The Towel

Throwing In The Towel

I’ve said before that I enjoy thinking about organizations, continuously optimizing them to give the highest probability of the desired outcomes. Organizational ergonomics, if you will. I’m also a mathematician by training and a nerd, which is what made Applying the Universal Scalability Law to organizations such a fascinating read, because it puts statistical weight behind its arguments.

In the same vein, I thoroughly enjoyed the following two articles that take a mathematical approach to understanding variability in project estimation (a perniciously difficult problem in all technical work):

The latter’s provocative title hopefully piques your interest enough to read further. You won’t regret it!

Shakespeare On Tech

Shakespeare On Tech

Yesterday I got to integrate one of my favorite idioms into a conversation: hoist on his own petard. I was discussing ways in which less technical folks can still evaluate an interview candidate’s technical competency.

Not the world’s safest weapon, to be sure

Look, if you’re going to try to impress someone with your vast knowledge of all things computing, you better be able to back it up. Because it’s easier than you think to detect BS. One of the simplest ways that an evaluator of any level of technical depth can detect a fraud is to ask them to explain their solution as if their audience was a smart fifth grader. If they can’t map the details to metaphors in a comprehendible way, it’s unlikely they truly understand them either.

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.