Tag: Customer Obsession

Small Things With Great Love

Small Things With Great Love

By | | Comments 0 Comment

Given my occupation and its dependence on typing, I’m terrified of hand injuries (one episode of Game of Thrones I’ll never rewatch is Walk of Punishment, it creeped me out for weeks, even though I knew what was coming; and ugh, now I just read the wiki, and I shouldn’t have).

But it turns out there exist reasonably powerful solutions, such as one that Josh Comeau described in a post on Hands-Free Coding. Not so bad, and a useful reminder that assistive technology isn’t just for “the other”. It’s hard to get right, but it’s worth the effort.

On a related note, mid-last year Amazon added two new leadership principles. They’re slowly being integrated into our culture, and I’ve been hesitant to add them to my post tagging scheme. But today felt the right time to apply one.

Don’t Be Late

Don’t Be Late

By | | Comments 0 Comment

I’ll be the first to say that UX is hard, but honestly now, do I really need to specify a dinner reservation time-of-arrival down to the second?

If I had to speculate, the implementor probably just copied an existing time input widget without consideration of the use case. Situations like this are a reminder of a downside of code reuse; yes it might save some development time, but is it best for the customer?

Takin’ Care Of Business

Takin’ Care Of Business

By | | Comments 1 comment

Love them or hate them, ticketing systems like Jira or Asana are an essential part of modern software engineering. Misuse is rampant, but wielded well, ticketing systems align teams around common goals, unburden them from pointless status meetings, and unlock accelerated development with better accountability and fewer defects.

What are some ticketing best practices, you ask? I have thoughts:

  • Work of any significance should be captured in a ticket. My rule of thumb is anything that takes longer than a few hours.
  • Tickets are not a substitute for good requirements and design documentation. Instead they should capture specific tasks to be accomplished, including links to other docs as needed.
  • Writing tickets is not only the responsibility of the team lead or product manager; a team should own its ticket board. If the current set of tickets does not match the reality of what is being worked on, make it so be rewriting, breaking up, and deleting tickets as appropriate.
  • Being assigned a ticket is a form of promise. It says to the team “I will accomplish this task in this amount of time.” Each engineer should thoroughly understand all of the tickets assigned to them, proactively seeking out guidance if they don’t, and making clarifying edits as needed.
  • Know how metrics such as velocity and completion dates are computed. Their value is only as good as the ticket data used to calculate them (garbage in, garbage out), so ensure values like story points are accurately tracked.
  • Avoid Bricklin’s Law by embracing healthy use of a ticket system, and others won’t feel the need to add more status tracking. Done perfectly, it renders other status checkpoints redundant, maybe even those daily standups you dread.
  • Finally, tickets are a means, not an end. Don’t lose sight of your ultimate goals. If your ticketing process isn’t helping you achieve those goals, change it.

The above list is far from exhaustive. Any other suggestions out there?

I Appreciate You

I Appreciate You

By | | Comments 0 Comment

Technology-related work, like all work, is primarily a social endeavor. It’s surprising that so little effort goes into preparing aspiring technologists about this side of the business, especially given our propensity to be singularly bad at it. Hence this article.

Along related lines, I found the suggestions in What Makes a Great IT Consultant completely applicable to a broader set of technology roles, and would highly recommend it.

I’ve also finally started digging into The Architecture of Open Source Applications; it’s been hit and miss, but more of the former, so definitely worth the time investment. A statement that jumped out at me today (from the chapter on Eclipse) was that an API is a social contract just as much as it is a technical one. I like that way of looking at it; seems a natural corollary of Conway’s Law.

In tangentially-related news, season 2 of Ted Lasso comes out today. You should watch it.


Slip Of The Finger

Slip Of The Finger

By | | Comments 0 Comment

Don’t run your tests with production data. Just don’t. Otherwise, your customers will end up with delightful emails like this:

In jobs past I was pretty cavalier with production data. I was never part of a major incident, but that was more due to luck than strong security controls and separation of concerns. Really thankful that my current employer takes this stuff as seriously as it deserves.

Word Salad

Word Salad

By | | Comments 0 Comment

Yesterday I was notified via email that some of my personal information had been compromised by the ParkMobile app. Besides the obvious question of why it took them two months to contact users proactively (vs a post on their website), I found this paragraph a blend of confusing and concerning:

Encrypted passwords were accessed, but not the encryption keys required to read them. We protect user passwords by encrypting them with advanced hashing and salting technologies.

So many things wrong with the above. First, passwords should not typically be encrypted, and certainly not in a way that would allow a company to read them. The better approach is to hash them, which ParkMobile mentions later, but encryption and hashing are not the same thing. It’s hard to trust an organization that doesn’t know the difference.

Additionally, the adjective “advanced” gives me pause. It’s not communicating anything of value. Why not instead tell me the exact algorithm used, such as bcrypt, Argon2, or PBKDF2? Most likely the person writing the response doesn’t really understand the technologies used to protect passwords. And claiming something is advanced when one has no ability to know if such a claim is true screams Dunning-Kruger effect.

Ironically in an attempt to express competence, ParkMobile has done the opposite.

Sweat The Small Stuff

Sweat The Small Stuff

By | | Comments 0 Comment

Details matter.

I’ve been enamored recently with building little Python packages that provide useful capabilities for my colleagues. Things like a client for our internal ticketing system, a convenience wrapper to interact with our LDAP servers, etc. And I talk about them non-stop with anyone who will listen, because I truly believe they are helpful for automating mundane tasks across the organization.

But a pesky thing happens when actual people try to use your code. Bugs pop up. Installation errors occur. Weird behaviors manifest. Whatever can go wrong, will go wrong, and if you’re lucky, you’re going to hear about it from your users. If you’re unlucky, no one will bother to contact you or use your code again.

The gap between a toy script you write for yourself and a full-fledged tool usable by others is vast. Numerous compatibility and usability considerations must be considered: differing hardware, operating systems, language versions, user familiarity, probably even more things I’m not thinking of.

Case in point. A few weeks ago I added @functools.cache to a couple packages in key places where expensive API calls were being made. It’s a rad little annotation, but was new to Python 3.9. Didn’t take long before someone hit an error message that was anything but clear to them. Quickly I patched the code up by replacing with @functools.lru_cache which does basically the same thing and has been around for a while longer. But did I bother to test on the older version? No I did not (and shame on me, because tox and pyenv make doing so easy). Once again my user was thwarted, because while Python 3.8 allowed the use of this annotation without a parameter, Python 3.6 and 3.7 do not (and he was running 3.6.9). Once again, I had to quickly patch, but this time I made sure my tox setup tested across versions.

The worst part of the above is that I could have better guarded against an esoteric error message by specifying precise compatibility in setup.py (in this case with a python_requires='>=3.6' instead of python_requires='>=3'). If I’d have done that, my user would have still gotten an error, but it would have happened at install time, and been much clearer as to the cause. Two extra characters in an install script, but hugely improved customer experience.

Like I said, details matter.

A Plethora Of Potpourri

A Plethora Of Potpourri

By | | Comments 0 Comment

During interviews, a common question directed at me is what my day-to-day looks like. While it feels like a cop-out, the answer is that I do whatever my customers need me to do. Some days that might mean writing Python, Node.js, or Java. Other days it might mean terraform, CDK, or (ugh) CloudFormation. Still other days it might not mean code at all, but leading daily stand-ups, drawing architecture diagrams, writing documentation, giving training, or planning long-term goals. And that’s not to mention all my managerial tasks like 1-on-1s, goal setting, performance reviews, an mentoring, since I view my team as customers of a sort.

We talk at AWS of being comfortable with ambiguity. It’s a posture that doesn’t suit everyone, but pretty much any technical job of worthwhile complexity requires the ability to deal with unknowns. There are no hard and fast rules. No absolutes. System design, software development, team leadership, they are all just as much art as science, requiring both good intuitions and good data to get right.

Don’t believe me? Then consider how Stack Overflow tells it.

It’s The Little Things

It’s The Little Things

By | | Comments 0 Comment

We talk all the time about customer obsession, it’s the first amongst equals of our Leadership Principles. The general idea is that you always imagine the customer is in the room with you when making decisions, and consider their preferences when implementing a feature.

As email got more prevalent (and with it, junk emails), one feature that came along in the spirit of customer obsession was one-click unsubscribe. Me being a person who strives for inbox zero, stopping email subscriptions easily was a welcomed capability. But who knew it could be done even better. Behold, zero-click unsubscribe:

How cool is that? Recognizing that I haven’t interacted with any of their emails or visited their site, they automatically unsubscribed me from their lists. That’s customer obsession in a nutshell.

The really surprising thing about this capability is that it’s surely dirt simple to implement. I bet I could pseudo-code it off the top of my head in one minute. Ready, go!

all_emails = database.get_mailing_list()
for email_address in all_emails:
last_contact = database.get_last_contact(email_address)
if datetime.today() - last_contact > ONE_YEAR:
database.remove(email_address)

See how easy that was? Any marketing email system worth its salt already knows when you click on a link in any of their mailings, so the data is there. Just takes a company thinking more about their customers than the size of their distro.

The Lies We Tell Ourselves

The Lies We Tell Ourselves

By | | Comments 0 Comment

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!