Skip to main content

A late thank you, for Toni and Jeanie

We see many talents every day. Everyone who is doing a good job has skills that might be learned from. And finding out how they are able to accomplish their tasks will always increase our own skills, and help us develop an empathy for other people's challenges and tasks that might be invisible at a casual glance.

Since I am happily applying for jobs, the interview questions come at me in batches, and really don't give me the opportunity to think, at that time, about the origins of my outlook. And conversations recently have led me to look at "What is quality, and acceptability, to me? And who did I first learn these ideas from?"

I think the first one to give me the attitude of quality was a server at one of the restaurants that my father frequented for work purposes, and I occasionally was invited to join them. As a young person, the atmosphere of a slightly upscale eating area, with my father's coworkers around, was a treat – even if I was the youngest person in the room by a good 15 years.

Toni was the server that we most-often were seated with, when I was in attendance. She, to my young eyes, was a magical person: she remembered orders, favorite people, and pets names – plus was able to make everyone feel comfortable, important, and welcome. I never remember a glass being empty, nor a less-than-delightful experience – but that may be looking back many years.

In admiring her, and her work ethic, I added in getting what was asked for to the person that requested it, making sure that it was accurate, and as prompt as possible. Being able to sort multiple workflows, and engage with those that are around in a professional manner – these are things I learned from her.

A lesson was added, many years later, to what I learned from her. I was applying for jobs, and stopped in to ask if they were hiring. A very familiar voice was in that room – I still remembered Toni's voice. And she recognized me – by name. This made a major impression on me, again. It had been more than a dozen years, but she was able to recall many details about me. I have worked on that talent – and it's still a work in progress.

Well, I didn't get that job – mostly because I didn't turn in the application. My first case of Impostor Syndrome.

I did, however, find a waitress job a year or so later. I was new, and severely intimidated. The place was small – and there were two of us: I'd get some training and/or help the first few days, correct? That assumption was proven false rather quickly. After a month, I figured out being a server wasn't a good option for me – I was fine with dealing with the people, I simply wasn't good with some of the other aspects.

Thankfully, there was Jeanie on shift with me. She was in her late 60's, and had been a server for many places because she loved it. She had a slow gait, but had the experience to do many of the tasks that needed done as she went by. She wasn't the best teacher – to her, you either knew it or you didn't. But an after-shift cup of coffee, watching her and noting what she did taught me that rushing and getting things done without a plan was not efficient. And that knowing what you are doing, and what you are good at, are two of the things that make a job 'work'.

I have had many other inspirations, and may add them into future posts. Take time to look at how you formed your work ethic, and your foundation of the ideas you bring to work with you may prove instructive, and hopefully allow for some memories of those who gave you those ideas, or their antithesis, a bit of room to influence your growth.

Popular posts from this blog

30 Days of Postman - for Testers!

  https://www.pexels.com/photo/white-and-brown-cat-lying-beside-a-laptop-and-toys-5468268/ Photo by Karolina Grabowska from Pexels   Working with developer- focused tools can be a challenge for some testers: we may know what the words mean, but haven't used those skills recently enough to make the tasks simple. Or we may not have ever used them, other than at a quick glance to make sure that what we are getting matches what it should be sending. And some give results that require us to go find another team member to help interpret the results. Being a more-independent tester has always been one of my goals - being able to use the tools that are common in the team, and be able to do at least basic tasks that support my tests with them. Our team used Postman for many of the API tasks that we had, so exploring this tool was a natural fit. There are alternatives it there, both graphical and command line, so feel free to explore! The items that you can do, and tools that help

Where Is It? Part 1 - Inputs

Photo by Pixabay from Pexels     I am job-searching, and running into some coding challenges. Most of them are simple - some seem to want one-line solutions that require two cups of coffee and a half-hour to figure out what they want. Others are far above where my skills lie, and these I give a try for, and learn. And then there are the ones that offer, seemingly randomly, a challenge - within my skills (or at least my research skills) - that could be used as part of a larger project that I want to work on. This was the case last week, when I tried for a position that was a bit above what I felt I could do comfortably. The challenge was to let someone enter items, and then give back their location. In a language I am just familiar enough to be a danger to myself in. Happily, and thinking forward about how I could use this as a part of a larger program that would  use something like this to interact with the user. And also, this is command line, and thinking of how to set this up to

Do Your Tests Wobble?

Image by delo from Pixabay “The green reed which bends in the wind is stronger than the mighty oak which breaks in a storm.”  ― Confucius  I was asked to pair Blog with Lena Weiberg - much to my shock and delight. This was the perfect opportunity to hear another point of view on something, and share it with the wider community.  ~ Part of being a good tester, to me, is making sure I stay aware of the trends in development. Knowing  how the team is working can help get comments and questions to them at the proper times, and has  the information that can be acted on. In this quest, I attended a recent online conversation where the  topic was primarily on the size of 'steps' taken in software development: making sure each step takes  a reasonable amount of time, that it leaves the system in a state that isn't worse than it was before the  change, and that could - if needed - be deployed at this point.  The concept of “wobble”  (I'm not sure