Tag: Customer Obsession

Livin’ On A Prayer

Livin’ On A Prayer

Today marks a unique milestone. It’s exactly halfway between the day I started my professional career as a software developer (June 4, 2001) and the same date the year I turn 65 (June 4, 2044), ostensibly about the time I retire (though who knows, I’m a bit of a workaholic).

Richard Rohr, the Franciscan priest and writer, speaks of “the two halves of life” in his book Falling Upward. Indeed, midpoints are a common moment to reflect on how far one has come, and how far one has left to go. I’m no exception to that. I’ve been blessed to have been in the tech industry for over 20 years. Done some fun work. Some interesting work. And I hope, some work that’s used technology to improve people’s lives while having a positive influence on those around me along the way.

It’s a common refrain that technology in its myriad forms has ruined humanity, whether it be social media and cell phones in 2022, the printing press back in the 15th century, or even agriculture in ages past. Maybe I prefer to see the bright side in things, because I believe that despite our faults in wielding it, the evidence shows that technology has unlocked human potential and made lives better in innumerable ways. I wouldn’t wish any of it away, and moving forward it still can, should, and must be used for the betterment of us all.

This will require us to remain vigilant and disciplined, ask tough questions, and apply our knowledge well, but I believe that it’s possible to do so. I’ve tried my best these first twenty-one and a half years. Here’s to twenty-one and a half more!

Adventures With APIs

Adventures With APIs

I’ve written before about the advantages of knowing how to dig around in DevTools to reverse engineer website interfaces. This week I’ve had three further instances of doing this work to good effect.

The Friendly Skies

Firstly, I travel a lot, enough that I now have Executive Platinum status on American Airlines. This means I’m first in line for complimentary upgrades, but only if there are seats available. So I wanted an easy way to go straight to a complete seat map to look at availability without needing to go through a full search on the website. Turns out there’s a magic URL that does just that, and all you need to do is pass it some parameters. So I present to you, a quick and dirty seat map lookup form. Give it a try!

While that’s cool, I wondered if I could make it simpler by leveraging a flight data API like the one from FlightLabs. That was pretty straightforward as well. Though I couldn’t embed it in WordPress, I did script it up in Python for your enjoyment. Just pass it a flight number, and it’ll do the rest. Neat!

Shake It Off

This week Taylor Swift tour tickets went on sale, and needless to say it broke Ticketmaster, despite their best attempts to add friction via pre-registration to enter a lottery to win a code to join a queue to enter a room to maybe get lucky enough to click fast enough to buy tickets. Sadly I was unsuccessful at securing seats despite dozens attempts across several days. But I did learn something about the API Ticketmaster used to check queue status, so all was not lost.

When I first joined the queue, the following was displayed:

Of course I was curious: how many more than 2000 people were there… 5000? 25000? A million? So I opened up DevTools, and took a look at the calls coming back from the server to check status. Lo and behold, there was a wealth of info in an easily digested JSON block:

Wouldn’t it have been helpful to display that information to the user? At least the exact users in line, and the expected service time value. No idea why it wasn’t shown, other than Ticketmaster not being known as a terribly customer obsessed company.

Automating ******** Across ****

The final example can’t speak of publicly other to say my penchant for automation will save my employer a sizable amount of money. In these uncertain economic times, that’s always a good thing.

A Tale Of Three Meeting Invites

A Tale Of Three Meeting Invites


Subject: Planning document

(body of invite is blank)


Subject: Discussion on planning document

Agenda

  • Review document content
  • Finalize edits
  • Action items for customer review

Subject: Internal discussion on planning document

Purpose of this meeting is to finalize the document that will be presented to the customer next week. Please read in advance of meeting (link).

Agenda (unless you know a better one)

  • Review comments made on document content
  • Finalize edits in real-time as a group
  • Decide on action items for customer review

It’s Not Personal

It’s Not Personal

I love Raising Cain’s. Their chicken fingers melt in your mouth, their sauce is top-notch, and the Texas Toast is a perfect bonus. I give it the edge over Chick-fil-A for best fast-foot chicken joint (though it’s close).

A few days ago I stopped by to get my typical 3 Finger Combo (with a lemonade and extra sauce, natch). It was pretty crowded and noisy, with many folks waiting for food, either to eat there, take with them, or to deliver on behalf of another (thanks to services like DoorDash, GrubHub, and UberEats, one can no longer make assumptions about how busy a restaurant is by the line at the counter, which is another customer experience post worth writing, but I digress). After saying what I wanted, I was asked to provide my name for the order. I did so, carefully pronouncing the short u in Jud which I’m regularly doing (it’s not a reference to the 2nd greatest Beatles song of all time, instead it’s pronounced like the country singing mother-daughter duet from the 90s, though only spelled with one d). I think they heard it right, but I couldn’t be sure.

While waiting for my food, I reflected a bit on this experience. I get the objective: make the experience more personal, so that when my order is ready I’m called by name and I thus feel like it was specially prepared. But that approach is flawed, because it fails to work backwards from actual customer desires. I suspect I’m not alone in that I don’t want a “personalized experience” at Raising Cain’s like I do at my job; I want to get the delicious chicken that I ordered quickly and accurately. An order number not only suffices, it does the job better than a name, for numerous reasons:

  • A number guarantees uniqueness in a way names do not, decreasing likelihood of an order mix-up.
  • Numbers are more easily distinguishable audibly compared to names. My name is often misheard, and it’s not nearly as tricky as many others.
  • Gathering a name requires an extra step in the ordering process, slowing it down. A number can simply be assigned.

These benefits have analogs in computer science, for example the advantages of searching a database using a unique identifier vs free text fields. Which someday when I need to explain the latter to someone who’s less familiar with the technology, I might just use the former as a metaphor: the act of ordering is adding a row to a data table of “customers waiting for orders”, and the person calling out the order once it’s ready is querying that table. A good database design seeks to make such queries unique and performant.

Further, the model of indicating a parking space number when getting curbside delivery is remarkably similar to hash-based lookups. Hmm, I probably need to turn this into a larger talk someday.

But in the meantime, when I’m asked for my name at a restaurant checkout counter? Call me “three one four” thank you very much.

That Personal Touch

That Personal Touch

Meeting regularly with your direct manager is an important mechanism for ensuring your work stays customer focused, getting actionable feedback and advice, and ultimately helping you achieve your career goals. This page captures a few of my thoughts on making them effective.

Firstly, you as an individual should own these conversations. Take the lead in setting an agenda, and come prepared with discussion topics. Your leadership has limited time, so use it wisely. Frequency and duration are up to you as well, though generally I’d say more frequent and shorter is better than one marathon session per month. However, there are times when longer discussions are needed, especially when goal setting and discussing performance.

Discussion topics can vary, though generally as a manager I’m less interested in discussing status on your day-to-day tasks and projects, unless you need advice or guidance on a specific issue you’re facing. I have other mechanisms to keep tabs on project health, so I’d much rather focus on personal development and goals. That being said, if you really want to give your manager a dump of what you’re working on (or just vent) that’s fine, but be careful not to use up all your time in this way.

Finally, I recommend taking notes during all 1-on-1 discussions, and especially having a mechanism for tracking action items for both yourself and your manager. I do that on my end for all my team, and share these notes in an email after each meeting, but using something more rigorous (like a ticketing system or task board) might be even better

Possible Agendas

Here is an example agenda I’ve used successfully:

  • Highlight / lowlight since we last talked
  • How can I help you this upcoming week?
  • What’s the status of your current annual goals?
  • Open discussion (you pick the topic)

And another agenda that also works well:

  • Personal check-in: how are you feeling?
  • Quick updates
    • Previous 1-on-1 action items
    • Tasks and projects
    • Current goals
  • Discuss current challenges and potential solutions
  • Recognize successes with gratitude
  • Create and review action items

And a third one:

  • Personal check-in
  • Task/project/goal progress
  • Review of priorities
  • Workload and expectations
  • Blockers
  • Feedback
  • Concerns

Discussion Questions

These are some questions I like to ask during a first 1-on-1 to learn more about how a person prefers to be managed:

  • What do you most need from me as a manager?
  • How do you prefer to receive feedback? In writing? In person? Another way?
  • How can I know when you’re struggling and need help?
  • Are there any manager behaviors that particularly bother you? If so, how can I avoid them?
  • What ongoing 1-on-1 cadence would be most helpful for you?

More generally, these are question I ask to help me as a manger how to make work more enjoyable:

  • What motivates you to perform at your best?
  • What do you wish you could spend more (or less) time doing?
  • At the end of the month/quarter/year, what would you like to say you’ve accomplished?
  • At the end of your career, what would you like to say you’ve accomplished?
  • If you could change one thing about work that would improve your life, what would it be?

These questions help me ascertain and guide someone’s career growth:

  • What impact do you think you’ve had so far? What additional impact would you like to have?
  • What aspects of your role do you love (or hate) and why?
  • What are you learning, and how are you growing here?
  • Is there a new project you’d like to work on? Or new goal you’d like to work towards?
  • What do you need training on? What do you need experience in?

Finally, these are question I ask to get feedback on my own performance as a manager:

  • How can the team improve its communication?
  • How can I help you be more successful?
  • How can we help you do more of what you enjoy?
  • How am I doing? What can I be doing better?
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.

Small Things With Great Love

Small Things With Great Love

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

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 say some development time, but is it best for the customer?

Takin’ Care Of Business

Takin’ Care Of Business

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

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.