The right frame of mind is important for your overall health

I’ve been holding off on writing about this, but what happened to me is an important story to tell, and a cautionary tale for others who might be going through the same thing.

The photo you see above is me lying in a hospital bed about a month ago. And I want to tell you how I got there.

I have made no secret about how much the experiences of the past year have stressed me out. When I keep a regular schedule (and when I’m working), I have a routine that I maintain. And as long as I stick to the routine, I tend to do pretty well. If my routine gets upset, that’s when I get into trouble.

Well, the stress that I’ve endured upset my routine. My sleep schedule had been irregular. And I’ve been doing a terrible job of taking care of myself. The pandemic closure, in the early months, shut down gyms, which meant that I stopped going to CrossFit (which had been part of my routine). To make up for it, I started doing a Couch to 5K program. I had been doing pretty well with that program, until about halfway through, I was beset with injuries which also upset my (now new) routine. (The injuries were bad enough that I ended up going to PT to address them.) My extracurricular schedule, also part of my routine, had been disrupted because of the pandemic. I was stressed and overwhelmed. Things that I used to enjoy now suddenly seemed like a chore. To sum it all up, I had stopped taking care of myself.

About a month ago, I started having problems eating. Twice within two weeks, I got sick after eating. After the second time, my wife insisted that I go to the ER. Upon being examined, I was told, “we’re admitting you.”

For the sake of my personal privacy, I won’t say what it was that I had, except that it was not COVID. I will say that I remained in the hospital for a week. I barely ate anything during that week. My only diet was bags of IV solution that they sent through my system.

That was not a pleasant experience. I would not recommend that to anyone.

I have been home from the hospital for almost three weeks. I am slowly (emphasis on slowly) getting back to normal. Even as of this article, although I feel much better than I did, I still have not recovered 100%. My energy level is not what it was, and I get tired easily. And it all came about because I had become overwhelmed and had stopped taking care of myself.

The moral of this story is that your emotional and psychological well-being is just as important as your physical one; in fact, it can directly affect it. Your morale is important; in fact, it’s one of the things that I address in my job hunt presentation.

So take it from me. Take care of your mental well-being, and make sure you’re in the right frame of mind. Do what you need to do to roll with the punches. If you need to occasionally let off steam, do so. Get help if you need to. Get yourself to where you need to be, mentally and psychologically. Once you do that, you’ll be able to take care of yourself. Don’t end up like I did last month, and spend a week in a hospital bed.

Advertisement

#SQL101: Raising awareness of SQL injection

(Image credit: XKCD.com)

I don’t think there’s an experienced web developer or DBA who isn’t familiar with the classic “Bobby Tables” XKCD cartoon above. Just about any time you mention “Bobby Tables” to most experienced IT people, (s)he will immediately know to whom you are referring. Most experienced web developers and DBAs are aware of SQL injection and will take steps to ensure that it’s addressed. Grant Fritchey has a presentation about SQL injection (you can view and download his slide deck here) in which he’s not shy about his desire to “kill Bobby Tables.” I’ve seen him present it at SQL Saturday, and I highly recommend it.

Of course, the keyword here is “experienced.” For people who don’t have that experience, and who build websites that connect to databases, I think it should be lesson #1. Today, I had an experience that reminded me of that.

Earlier today, my sister texted me, asking for help with editing SQL code. She asked me what I use to edit SQL. I told her I generally use SSMS, although you can edit SQL code with a straight-up text editor, if necessary (she is not a DBA, so I felt somewhat comfortable telling her this). She told me she had to clean up spam comments in her data.

That last comment immediately grabbed my attention. I then asked her, how are your security settings, and do you have data backups.

She told me: that IS her data backup.

If her earlier comment had gotten my attention, this one immediately set off alarm klaxons in my head.

I started thinking about what could have corrupted her data to this extent. I started asking questions about her admin setup (I should’ve asked her to make sure she wasn’t using “sa” or “admin” as her admin login — Sis, if you’re reading this, make sure you check this!), including her passwords. Her admin password was pretty secure (thankfully).

She then mentioned her website. I asked if her website was accessing her data. She said yes.

I asked her about Bobby Tables (admittedly, in my advancing age, the term “SQL injection” didn’t immediately come to my mind). Her response: “who?”

At this point, I was convinced that I had my answer. Her database had been corrupted through SQL injection attacks. I told her to make sure you address your SQL injection issue before you even think about your data backups. Worrying about your data backups before addressing your SQL injection issue is like trying to rebuild your house before you’ve put out the fire.

I’ve been talking about SQL injection all throughout this article. For a brand-new web or database developer who has no idea what SQL injection is, here’s a quick primer: it’s a data security attack in which a hacker breaches your database by sending SQL commands through your web interface. I won’t get too much into how it works; instead, here are a few links that explain what it is.

• SQL injection (Wikipedia)
• SQL injection (OWasp)
• Running an SQL Injection Attack – Computerphile (YouTube video)

And make no mistake: SQL injection attacks can cause major damage.

So consider this a warning to any fledgling developers who are interested in web or data development: data security issues, such as SQL injection (and there are many others) are a big deal and need to be considered when building your setup; it’s not as simple as just setting up your website and connecting it to a database. By not considering this when you first assemble your system, you might be setting yourself up for major issues down the road.

Communication lessons from air disasters

I’ve always had a morbid fascination for air disasters.  (Don’t ask me why; I have no idea.)  I’m fascinated by shows such as Air Disasters, Why Planes Crash,  and Mayday: Air Disasters.  Whenever I hear about a plane going down, I’ll start thinking about what happened, clues, what might have caused it, and so on.  There are times when I think I should have gotten a job with the NTSB.

Greg Moore has some publications in which he talks about lessons learned from aircraft accidents; his book partially discusses these lessons.  He also has an excellent SQL Saturday presentation titled “Who’s Flying The Plane?” which talks about lessons learned from air disasters and how they can apply to IT.  Go check it out if you have a chance; Greg gives a great presentation!

For the purposes of this article, however, I want to concentrate on a particular topic: how communication — or, the lack of — either contributed to or was the root cause of a disaster.

Last night, I watched an episode of Air Disasters that talked about the plane crash that took the life of professional golfer Payne Stewart. The plane went down after the cabin depressurized (the cause of which was never determined), the crew became incapacitated, and the plane ran out of fuel. What made it interesting to me was that bad documentation might have been one of the contributing factors to the accident. After the cabin lost pressure, the crew likely consulted a checklist, as is standard procedure for nearly any cockpit activity or incident. The checklist was poorly written and unclear. What should have been the very first instruction was, “put on your oxygen mask.” It was not. By the time the crew got to that instruction, it was too late; they were overcome by hypoxia.

It reminded me of a tenet that I preach in my documentation presentation: if, in a step-by-step instruction, an instruction cannot be understood within a few seconds, it has failed.

I also remember another Air Disasters episode that focused on Avianca Flight 52.  In January of 1990, the plane, a Boeing 707 carrying 158 people, crashed on approach to Kennedy Airport in New York after running out of fuel, killing 73 people.  There were numerous communication issues during the flight.  Had any one of them been addressed, chances are the disaster never would have occurred.

How often have you been involved in some kind of activity where things were miscommunicated?  How well did those activities go?  I’m guessing that they didn’t go well.  How often have they happened when deadlines were approaching?  What was the mood of your organization?  I’ll guess that it was likely one of high stress and low morale.  And during that time, how smoothly did things go?  Probably not very.  I’ll bet that plenty of mistakes were made.

I’m painting this picture within a business environment.  Imagine what these conditions are like when people’s lives are at stake.

The number of disasters that have occurred from poor communication are countless; entire studies have been dedicated to the subject.  Indeed, numerous solutions and subcategories related to miscommunication have been devised.  The airline industry developed the process of crew resource management.  Extensive research has been done on the phenomenon known as groupthink.  Even simple measures such as checklists have been studied and implemented.

The moral of the story: good communication, including documentation, is critical. The consequences of it can have adverse effects. At best, bad communication can disrupt your business. At worst, it can cost lives.

Leaping before you look

(Image courtesy of The Telegraph)

Not long ago (I don’t remember how long — I’ll say a couple of weeks), I stumbled across a ‘blog post that someone had written. Apparently, this person was a new SQL Saturday speaker. I don’t remember his name, and from what you’re about to read, it’s probably just as well.

I don’t remember exactly what was said, so I’ll paraphrase: “I just applied to speak, and was accepted at, a SQL Saturday in (some city that’s not local to me). Now I have to figure out how to pay for my trip! Can you all help me? Here’s a GoFundMe page to help me out!”

I resisted the urge to write him back to say, “you’re a f**king moron. You’re not getting a single dime from me. Poor planning on your part does not constitute an emergency (or charity) from mine!!!”

SQL Saturday is an all-volunteer event, and organizers go through a great deal of time and effort to plan it and ensure that the speakers are lined up to the schedule. Committing to speak at SQL Saturday and not keeping that commitment disrespects the organizers, and it does not reflect well on you. If you renege on your commitment to speak at SQL Saturday, try seeing if you’re ever invited again.

It’s not just about travel planning, either. If I was interviewing this person for a job (note: I’m in no such position), I would highly question his ability to make smart decisions. Unless he could demonstrate to me that he learned from this mistake, I would not ask him back for a second interview.

Clearly, this person leapt before he looked, and in my mind, he has no common sense whatsoever. Whenever I apply to speak at a SQL Saturday, the first thing I do is check to make sure that I can do the trip. Among other things, I make sure the date is clear on my calendar, and I make sure that I can actually get there (there’s a reason why the large majority of SQL Saturdays where I present are ones to which I can drive).

On March 21 (a few weeks from today), I will be speaking at SQL Saturday Chicago. I Googled the driving time from Albany to Chicago, and it told me it would take 12 hours, which is much longer than I am willing to drive for a short weekend trip. I put together a hypothetical itinerary using Amtrak (I love traveling by train — I prefer it over flying whenever possible) and Chicago-area public transportation, Lyft (which I tend to prefer over Uber), and hotels. (I also looked into renting a car, but there were very few rental agencies near Union Station that were open for the hours that I needed it; besides, I didn’t want to deal with traffic in a strange city, and it was also more expensive than the other options.) I came up with a game plan that was workable and would not break the bank. When I realized that the trip was do-able, I went ahead and applied to speak (and was accepted) at SQL Saturday #945 in Chicago!

I wrote a previous article about choosing which SQL Saturday to submit. You can read the article here.

So before you commit to anything, make sure you can honor that commitment. It does not reflect well on you if you cannot keep your word. Don’t leap before you look.

It’s okay to say “I don’t know”

If you ever have a chance, I recommend sitting in on Thomas Grohser’s presentation called “Why candidates fail the job interview in the first minute.”  (Tom is a great speaker, and I suggest you go hear him talk, anyway!)  In his presentation, he discusses a number of reasons why job candidates often blow the job interview.  The first time I sat in on his presentation, I asked him what I thought were some good questions — so good, in fact, that the next time I attended a SQL Saturday where he gave that presentation, he asked me to sit in just so I could ask those same questions and make some comments as a talking point for the audience.  (He even joked about utilizing me as a prop for his presentation!)

One of the points that he makes in his presentation is that a candidate is not expected to know everything.  We are human, and we are not perfect.  Nobody is all-knowing, and as well-versed as we try to be on a subject, we won’t know everything about it.  Even experts in a subject field won’t know every little thing about their subject

Tom mentions that when he interviews a job candidate, he will ask at least one question that either does not have a correct answer, may have multiple correct answers, or is ambiguous.  (For those of you who are not DBAs, data professionals often joke that the standard answer is, “it depends.”)  He is not looking for a singular correct answer; rather, he is looking for how the candidate answers.

This brought to mind a memory of a class I took in grad school.  I missed a class because I was out sick, and it turned out that the material covered that day ended up as a question on the mid-term exam.  I don’t remember exactly how I answered that question, but I remember starting it something like this: “I don’t remember going over this subject, but based on the nature of this question, this is what I think it means…”  Not only did I end up answering the question correctly, I ended up getting a 97 (out of 100) on the exam.

So if you don’t know the answer, how would you go about getting it?  These days, technology makes it easy to look things up online.  “Google it” has become a part of our lexicon.  Trying to find answers is our basis for research; if we don’t have the answer, we try to figure out what it is.  That is how we learn.  I’ll go as far to say that not knowing an answer is better than trying to fake your way through providing an answer.  Would you rather give an answer you don’t know and end up giving a wrong answer, or would you rather take the time to do your homework and give a better answer?

Too many of us stress ourselves out because we try to be perfect.  Any time we are tested — whether it’s on an exam, a job interview, or any instance where we are expected to give testimony — we expect ourselves to be perfect.  We expect to have the answer to every question.  The reality is that this is impossible.  We won’t have every answer, and we shouldn’t expect to.  “I don’t know” is a perfectly acceptable answer, and too many people don’t realize that.  Just say that you don’t know, and explain how you’d go about finding out.  And the next time you’re asked the question, you’ll have a better answer.

Want to get ahead? Don’t get comfortable

“Moving me down the highway, rolling me down the highway, moving ahead so life won’t pass me by…”
— Jim Croce, “I Got A Name”

“It’s important to be able to make mistakes.  If you don’t make mistakes, it means you’re not trying.”
— Wynton Marsalis

“Don’t look back.  Something might be gaining on you.”
— Satchel Paige

“Insanity is doing the same thing over and over again and expecting different results.”
— unknown

Late last Friday afternoon, our manager stopped by our workspace for a chat.  Some of it was just small talk, but he also wanted to give us a reminder of something, which is what I want to write about here.  I don’t remember his exact words, but the gist of what he said went something like this.

“We want you to develop personally and professionally,” he said (or something to that effect).  “The way you do that is to take on tasks that you know nothing about.  Volunteer to do things you wouldn’t typically volunteer.  If you see a support ticket, don’t worry about looking to see whether or not you know what it is or if you know how to handle it.  Just take the responsibility.  That’s how you develop.  If you want to move ahead, you need to step out of your comfort zone.”

Indeed, these are words to live by, and it isn’t the first time I’ve heard this.  I have had countless experiences where I’ve been told that I need to step out of my comfort zone in order to improve.  In my music experiences, especially in my ensemble performance experience, I’ve often been told by good music directors that I need to attempt playing challenging passages to get better.  When I first started doing CrossFit, one question we were asked was, “would you rather be comfortable or uncomfortable?”  The point was that in order to get better, some discomfort would be involved.  I also remember one of the points of emphasis back when I took a Dale Carnegie course; each week would involve stepping a little more out of our comfort zone.  We would do this gradually each week until we reached a point where we had drastically improved from where we had started.

Falling into a rut is common, and while it happens in all different facets of life, it is especially easy to do in the workplace.  Sometimes, the work environment can slow down, and you have a tendency to fall into a routine.  I’ve had this happen more often than I want to admit, and more often than not, I’m not even aware that I’m doing it.  Every once in a while, a pep talk or some kind of a jolt (such as a kick in the butt — whether it’s from someone else or myself) reminds me that I need to branch out and try new things if I want to get (and stay) ahead.  I am well-aware that I need to step out of my comfort zone to get ahead, but I am also the first to admit that I will sometimes forget about this, myself.

Too often, I see people who fall into ruts themselves, and who have no desire to step out of their comfort zones.  As much as I try to tell these people to at least try to do something about it, they insist on remaining where they are.  These people strive for mediocrity, which is a major pet peeve of mine, and something for which I have no tolerance or respect.  People want to remain in their “happy place,” but what I don’t understand is how these same expect to get ahead, yet refuse to leave their comfort zones to do it.  These people will be stuck in a rut forever, and they have no right to complain about it.

Everyone has a dream, or at least some kind of goal they want to achieve.  The fact is, if you want to reach that goal, or at least take steps toward it (whether you reach it or not), you need to get uncomfortable to do it.

Instant decisions

(Source: New York Times)

A NY Times recap of a ballgame got me thinking about instant decisions.

I watched this game on a TV at a restaurant where I was having dinner with my wife.  I remember watching Brett Gardner getting thrown out as he was caught in a rundown between third and home.  I remember thinking, “now the man on third is erased.  What were you thinking, Brett?”

As the Times article points out, it ended up being a fateful decision by (Orioles pitcher) Dylan Bundy.  Had he thrown the ball to the shortstop instead of his catcher, he potentially could have turned a double play to get his team out of the inning.  Instead, the Yankees, with an extra life, rallied in the inning to go up by a score of 5-0 (highlighted by a Tyler Wade grand slam).  The Yankees ended up winning, 9-0 (making me, a Yankee fan, happy).

But this article isn’t about the game.  It’s about the instant decision.  In this case, a quick decision ended up affecting the outcome of a ballgame.

Think about all the times in your life when you’ve had to make an instant decision on your feet.  We’ve all had them.  How did they turn out?  Good?  Bad?  Did they end up changing the course of your life, or were they just blips on your lifetime radar screen?

I’m sure there’s some kind of psychology as to how your background — upbringing, education, etc. — might play a role regarding the kinds of split-second decisions you make, but this is a subject about which I know nothing.  Rather, it got me thinking about the idea that quick decisions can have consequences.  In the scheme of things, many of them might not have any effect.  But depending on the time, place, and circumstances, such decision-making could have disastrous consequences — or result in the opportunity of a lifetime.

Always ask someone to test your product

This morning, one of my colleagues posted this message to our Slack channel:

please ask someone else to test your code before pushing it

It brought to mind an important thought (and more ‘blog article fodder): any time you produce something, regardless of what it is — a software application, documentation, a presentation, a music composition, a dish you cooked, etc. — always ask someone else to test it out before you send it out for public consumption.

That testing could take several different forms — it could be an end user trying your application, somebody reading your document, listening to your presentation or your music, trying your dish, and so on.  Testing results in feedback, which results in improvements to your product.

Whenever we produce something, we have our own vision — and our own biases — as to how the product should come out.  We expect our products to be perfect as resulting from our own visions, and we expect (and demand) that the consumers adhere to our visions and how we expect the products to be viewed or interpreted.

Unfortunately, we are blinded by our biases.  The world does not share our same visions.  People who use our products will never, ever, perfectly interpret how our products should be consumed.  More often than not, we’ll find that what we produce will be used or interpreted in ways that never occurred to us.

Even in my own workplace, I write and edit a lot of online documentation.  Much of what I write comes from other sources, often about topics about which I know little (or, sometimes, nothing).  I try to write material based on the information I have at hand.  Very often, I come across gaps that need to be filled.  I’ll do my best to ask original authors what was intended, or to dig for information to fill those gaps.  But in absence of those resources, I end up making assumptions and using my own intuition to fill in the blanks.  Those assumptions might not necessarily be correct, and what I write could end up being different from what was originally intended.  It is for this reason why I am constantly asking my colleagues, “take a look at what I wrote.  I want to make sure what I wrote is accurate.”

In a manner of speaking, creating products is a form of communication — in that what we produce results from an idea in our heads, and the end users — the consumers — are the ones “listening” to the communication — in this case, the end product.  If you are familiar with the basic communication model, a sender creates a message, a receiver interprets the message, and the receiver reacts to the message in the form of feedback.  Producing a products works in exactly the same way — a producer creates a product, a consumer uses the product, and the consumer reacts to the product, generating feedback.  In between the sender and the receiver is “noise” that degrades the message or the product (it is not literally noise — the “noise” can simply be the fact that the sender’s and receiver’s interpretation of the message are not one and the same).

So, any time you create some kind of product, always ask someone else to try it out.  You’ll find that the person’s feedback will result in tweaks to your product.  And you will end up with a better product.

Blind spots

“All I want from tomorrow is to get it better than today…”
— Bruce Hornsby (or Huey Lewis — whomever you prefer)

“You’re only human; you’re allowed to make your share of mistakes…”
— Billy Joel

One of my favorite books is The Sword of Shannara by Terry Brooks.  For the benefit of those of you who’ve never read it (spoiler alert: if you’ve never read it and want to, I suggest you stop reading this paragraph and move to the next one, because what I’m about to say doesn’t get revealed until near the end of the book), the book involves a magic sword that has the ability to reveal truth.  When the sword’s magic is invoked, both the wielder and the recipient are forced to confront the truth.

There are many times that I wish I had a Sword of Shannara.  I can think of many people who would benefit from its magical power.  And I put myself at the top of that list.

An incident that occurred last night served to remind me of the blind spots that I have.  I don’t care to talk about the incident (the details aren’t important here, anyway), except that I felt as though I’d taken a big step backwards.  It’s not the first time that I’ve taken a step back, and as much as I try to avoid it, I suspect that it will likely not be the last.

We all have blind spots; it’s a part of being human.  More often than not, we aren’t aware that those blind spots are there — hey, there’s a reason why they’re called “blind” spots.  There is no magic sword to reveal those blind spots.  The best mirror we have for those blind spots is each other, in how we behave and react around one another.  If someone is smiling, laughing, or nodding his or her head around you, you’re probably doing something right.  If that person is frowning, yelling, or criticizing, then probably not.

As much as we try to do our best, inevitably, we will stumble somewhere down the line.  I admit that I’m probably still dwelling on it — I probably wouldn’t be writing this article, otherwise.  I’ll eventually get over it.  All we can do is to recognize our blind spots — once we recognize that they’re there — keep an open mind, learn from our mistakes, and keep moving forward.

Don’t be afraid to screw up

“If you’re not making mistakes, you’re not trying.”
— Wynton Marsalis

“I get knocked down, but I get up again; you’re never gonna keep me down…”
— Chumbawamba

“You’re only human; you’re allowed to make your share of mistakes…”
— Billy Joel

“It’s not how we fall.  It’s how we get back up again.”
— Patrick Ness

It’s been said that (baseball) pitchers need to have short memories.  Whenever a pitcher makes a mistake — say, gives up a home run — he needs to shake it off — forget about it and move on to the next batter.

That being said, he needs to remember it as well.  He needs to figure out what he did wrong (e.g. “okay, he likes the fastball down and away”) and remember not to make that same mistake the next time that batter comes up to hit.  In other words, he learns from his mistake.

This pretty much happens to all of us.  We’re human.  We’re not perfect.  We’re going to make mistakes.  The issue is when we become afraid of those mistakes.  We become so afraid of mistakes that it discourages us from doing things.

Let me make one thing clear.  I’m not talking about people who willfully make mistakes, don’t care, or strive for mediocrity (which, by the way, is a huge pet peeve of mine, and one that I do not tolerate.  That’s another ‘blog post for another time).  I’m talking about people who genuinely care about what they’re doing, who want to do a good job or get better, and are putting in an effort to reach that goal.

As a part-time musician who holds a leadership position, this particularly troubles me when it comes to making music.  Someone doesn’t want to play something because he or she is afraid of screwing up.  Why?  Music is an area where it makes the most sense to make mistakes.  The time spent practicing or rehearsing music is when making mistakes makes the most sense.  It’s called practice for a reason.  It’s time spent to address areas that need to be improved — hence, why it’s important to make mistakes.  Mistakes tell us what needs work or what needs to be addressed.  Mistakes are why we rehearse.  We don’t — and shouldn’t — practice what we’re doing right; we need to practice what we’re doing wrong.

When it comes to music, I attribute part of it to stage fright.  People don’t want to make mistakes in front of other people.  I say, who cares?  So what if you make a mistake?  What’s going to happen?  Are people going to think less of you?  In all likelihood, probably not.  For what it’s worth, I’ve heard — and even seen — professional musicians make mistakes during concerts or live performances.  More often than not, they’ll keep going as if nothing happened.  No big deal.  It’s funny, but I lost my fear of performing (or speaking) in front of groups a long time ago.  I attribute it to realizing that making a mistake isn’t the end of the world.

The same holds true on the job.  Many of us are afraid to make mistakes at work.  Why?  Are we going to get fired?  Unless the mistake is either (1) very large, or (2) numerous, it’s unlikely.  How many of you have had bad days at work?  It happens sometimes.  How many of you have lost your job because of them?  I suspect, not many.

The thing is, we always want to be better at something.  Getting better means getting out of our comfort zone.  When that happens, we’re going to make mistakes.  I’ve often said that “perfection as a goal is okay.  Perfection as a standard is not.”  We’re not built for perfection.  That’s what being human is all about.  Someone once said that “one of the worst quotes ever coined is ‘get it right the first time.’  It’s stupid, because almost nobody ever gets it right the first time.”

Well, someone might say, “what about a profession where you can’t afford to make mistakes, where making a mistake can cost lives, such as doctors and airline pilots?”

For this, I point out a couple of things.  First, there’s a reason why jobs like that require extensive training and practice.  Pilots practice in simulators.  Doctors practice on cadavers and dummies.  In both cases (and probably others as well), students are closely supervised.  These days, virtual reality contributes to these practice scenarios as well.  And even then, mistakes will be made during practice.  Second, professions such as these are becoming increasingly reliant on checklists.  Checklists decrease the probability of mistakes, and are becoming increasingly prevalent in numerous professions.  (I have an idea for a presentation and a ‘blog article about checklists; hopefully, this will be coming soon.)

The ability to make mistakes is important.  We learn from them.  We get better because of them.  They make us stronger.  And once you can address them, overcome them, learn how to recover from them, or eliminate them, chances are that people will say that you’re the master at your craft, whatever that craft may be.