8 Tips for Debugging using Top-Down Techniques and Divide and Conquer

Here we go.  Debug.  People love to write about software methodologies but rarely about debug.  Yet, it’s one of the most important skills any developer needs to have.  I was once asked about my typical debug strategy in an interview, so we know it’s important and says a lot about where we are on our programming journey.

First let me say, before you get involved with doing debug, make sure you’ve reviewed your code.  I don’t know how many times I’ve taken a shortcut and jumped right into debug only to find out that the error would have popped out at me if only I would’ve reviewed my code first.

So, now, assuming you’ve reviewed your code.  What then are some good tactics to employ when doing debug.

Well, of course, a lot of that depends, right?  I mean, what kind of software are we talking about?  Is there a server or database involved?  Are we dealing with a mobile app, or are we talking about an old-fashioned desktop program?

Let’s speak in generalities since we won’t define anything too particular in order to keep this post fairly general and high level.

Do you remember when you first learned to program?  Maybe it was in BASIC or C?  Probably Python, nowadays.  Anyway, my first language was BASIC in high school.  My first “real” language (compiled language) was C in college.  I remember my great dependence on the printf statement when problems occurred, and they will.

Of course, we were told that more sophisticated methods of debug would later be taught.  Turns out the old print statement still is very useful though, and I have no shame in admitting it or using it.

Well, of course, now you can put in fancy try/catches in many languages, which can be helpful too.  Did your teachers ever really explain how to use a debugger?  The tool that often is integrated within the IDE or in the case of GNU comes in the form of GDB (to support GCC).  That little tool, albeit a bit cryptic, is so powerful especially for finding memory-leak related stuff and pointer issues.

Let’s first review some of the more common errors that we might find before we get to some debug tips.

  1. Segmentation fault (memory or pointer issues).  This usually occurs when you step on memory that doesn’t belong to you (a misuse of pointers), or you run out of memory all together — i.e., you haven’t released unused memory or tried to acquire more memory than exists.
  2. Stack overflow.  This usually results when your function calls go too deep.  For example, when you call a function recursively and it takes too many recursive calls before the exit criterion is met.
  3. Overflow, underflow related errors.  Overflow usually means you divided by zero — or a number close to zero — or you are trying to represent a number bigger than your data type allows.  Underflow is the opposite of overflow.  Imagine dividing a number by something close to infinity.  The result is an extremely small number that can’t be represented by your data type.
  4. Allowing your algorithm to blow up.  Common issues are underflow and overflow, and stack overflow.  Exceeding array bounds, etc. (Related to 1 above.)
  5. Precision errors.  Say you use floats instead of doubles.  The accuracy of your answer will be compromised, or the algorithm may become unstable and cause an underflow or overflow error.  This tends to be more of a problem in math and numerical-type programs.
  6. Input related faults.  Faults related to not checking for the proper input data types or bounds on the data, etc.  These can cause all sorts of different kind of errors or faults.
  7. Logic errors in your program.  You implemented an algorithm incorrectly, for example.
  8. Communication errors.  Say you are trying to communicate with a server that is offline and didn’t write code to deal with this condition.
  9. Errors in a library, plugin or API, etc.  These can be hard because you often aren’t expecting it.  OK, if it’s a WordPress plugin, you probably expect it.
  10. Less likely, but sometimes the OS or browser can even cause problems.  Say a systems call has a bug in it, or a bug exists in the browser where you run your webapp.  These are even harder because you aren’t expecting it.  This can happen more so on custom operating systems or an OS that doesn’t have a large market share (same with browsers).
  11. Output error.  Say you are trying to print or control something that is experiencing an error. (This is similar to 8 but it can communicate.  Instead, it just doesn’t know what to do when a fault occurs.)

Of course, with some languages, like Java and C#, you’ll never have pointer issue as you don’t have that kind of control.  Same with memory on the heap.  You can’t acquire memory from the heap, so you never have to worry about releasing the memory back to the heap (garbage collection does it for you).

Java and C# has some nice abilities using the try/catch related constructs as well.  These can often allow a programmer to catch underflow or overflow issues, as well as deal better with unexpected or “bad” input, etc.

Well, that’s a nice review of some of the common errors one might have to deal with.  So what can we do if we have one of these errors.  Sometimes the program (and/or operating system) will tell us which error occurred, but often we don’t really know.  Say it’s a bug in a library, the browser or even the operating system itself?

So here are the options I usually employ — first assuming I’ve reviewed my code and don’t see anything wrong with it.  And when I say review my code, I use a two-step approach.

First, I do a quick review, and then, if that doesn’t help, I scrutinized every line as if I’m back in grad school and analyzing a math proof for correctness.  (I had a rule of thumb that if the professor was over 70, I would assume he had one or more bugs in his proof —  actually, usually just omissions.)

  1. I revert back to dropping a couple of print statements in areas of the program where I have some suspicion.  Here, I use the divide and conquer approach.  The essence of divide and conquer is to continue to break down the problem into smaller pieces unless you find the root cause.  If you are familiar with binary search, you are familiar with divide and conquer.  In binary search the data set is continually cut into half until you find your search item or determine it’s not in your data set.  I’ll write more about this general approach in another post.  What do I print?  Sometimes just statements that say I am on line 333.  At other times, I print out variables that I suspect are related to the problem.
  2. If the language has try/catch constructs, I add a few in areas where I think the problem may reside.  Again using divide and conquer.
  3. If step 1-2 didn’t work, I pull out the bigger guns and invoke the debugger.  I set break points and inspect variables where I think the problem may be occurring.
  4. In this step, I may create several print statements that print to a file.  Hence, print a log file while the program is running.  Often the bug was discovered using earlier steps and I never even have to use this approach.
  5. I decouple the program as much as possible.  I test each module/class/file as much as possible outside of the program using a small test-suite driver program.
  6. I further decouple the program by doing unit tests on each method or function outside of the program using a small test-suite driver program.
  7. I ask a coworker to review my code and the issue I’m having.
  8. I set up a code inspection with the team.  I consider this an all-hands approach.  Sometimes this can work when you have a really tough one that you and your code buddy can’t figure out.

Generally the tips come down to top-down strategies and employing divide and conquer, decoupling the problem, and putting your ego on the back burner and asking for help.

Other things to consider before enlisting help.

  • Take a break from the problem or bug.  If you can, work on something else for a while.  Give your brain a break.
  • Maybe even tackle it the next day after you’re more rested and have cleared your head.

Of course, a no-brainer is to Google any error message(s) you get.  I figured that was too simple to add to the list, but let’s face it, it’s often a smart idea before going too far down other paths.

We’ll there you have it.  These are my usual go-to strategies I employ.  Of course, these are meant to be rather generic.  If I was doing embedded software, for example, I would probably set up an emulator. And if I was doing some web stuff, MUCH different — like hanging out in the browser, forever. But, nonetheless, many of these debug principles should carryover across various areas of programming.

Don’t Compile Your Code Until You Do This

It’s 8:01 AM. Your boss says you’re late. He wants the code built that you were working on the other day. (You don’t do continuous anything there except whine about your job for not having any tools.) He said the testers need your latest build. He’s pissed. He always seems pissed though.

He’s married to a real bitch, a beautiful bitch who rocks his world (she’s read Fifty Shades of Grey, twice), however, so it’s all worth it he thinks. When they were courting, to win her heart he had to promise her a comfy republican lifestyle, which he later delivered on.

He also had to promise her dad a 40 acre parcel of land that the dad wanted to use as a hobby farm. His wife can never find out though because she is a modern woman (she just read Lean In) and would be furious if she knew her father and husband made a gentleman’s agreement.

Your wife, however, is really sweet, so life is good for you other than your boss and not having any tools at work. (You’re lucky because your father-in-law didn’t require a parcel of land – or a cow.) You tell your boss you added just a bit more code the other day, and you’ll compile it now.

Wrong! Tell the asshat to wait. You need to review your code before you compile. Tell him it’s a practice that is commonly recommended by some of the greats in programming and software process. Mention Watts Humphrey who developed the Personal Software Process (PSP) – among many other software process ideas – who was a software process leader from Carnegie Mellon University.

He will have never heard of this person, of course. See, the manager only golfs on weekends and watches the sports channel, NASCAR and lots of Fox News. His wife is always at the spa or on an expensive shopping spree, so he often has lots of downtime on the weekend.

But he still hasn’t picked up a book about software in 21 years. That’s when he read the first edition of Code Complete. A lot has changed since then like there’s Agile and Scrum and other process goodness and the second edition of Code Complete. He’s never visited a software blog, either.

See, I once worked at a ginormous company that had two camps when it came to doing a code review before compiling. We would have rancorous debates about it – no shanks were ever pulled though. Then a high-level manager would walk by and we would say, “Reviewing code before compiling is the booooomb – we love it fearless leader.”

Yet you think it sucks eggs. The first camp was the managers. They all thought it was the cat’s meow. If Watts Humphrey recommended it, they said it was an edict, a must. It became codified in the software process.

You do realize when you become a manager there is one person that manages and a whole team of management cronies that are “yes men and women to the big dog.” (Management sheeple, I call them.)

Well, the other camp was all the working bees, the grunts. Or what I like to call the cubicle-bound indentured servants who have sold their souls to a greedy evil company controlled by Wall Street pigs – you know, the evil one percenters we all love to bash, until we become one percenters, too.

They thought the practice of doing a code review before compiling was plain stupid. They would argue why do what the compiler can do easily for you – find common syntax errors.

Of course, doesn’t that mean you are using the compiler as a crutch though. I was torn. Higher-ups wanted this to be a best practice that we had to take like caster oil. But the peons were revolting. I was a peon being groomed for leadership. They gave me a catalog from the BMW dealership for when I finished my master’s. I was going to get the red one as my wife is a bit of a ginger.

At the time I straddled the fence. I guess I was more of a politician – the perfect fence sitter. (A cross between a Blue Dog and a RINO. Can you tell the mid-terms are approaching, and I’m also a politics wonk?) I have since decided it is best to do a code review before. I admit I often don’t though. I love the immediacy of seeing the compiler tell me how stupid I am.

Sometimes I use different compilers to get different people – I mean compilers – to tell me how stupid I am. Clang is very clear and meaningful about my stupidity. GCC leaves me wondering if it was an insult or a compliment. A bit cryptic in the error message department, wouldn’t you say? I can almost hear Richard Stallman lambasting me for thinking I’m smart enough to use his compiler.

See, I formed this new opinion after studying math at a deeper level. When you study math, such as doing derivations and proofs, you quickly learn the value of scrutinizing over your notation and symbols – the totality of the proof. It is more like doing an inspection than a mere review. Yet, that is the only way I’ve ever been able to do math proofs and ensure they are correct.

If the compiler tells me it passed compilation and gives me an executable. I’m like great. Where are the balloons or where’s my BMW? Let’s run it “bitches.” (I watch too much reality TV.) But what the hell am I running. Most likely something that isn’t what I intended.

Without doing a review before compiling, I likely will have code that compiles that is simply not what I intended. Hence, I get a false warm and fuzzy feeling only to run it and get a stack fault. Oops, my bad. Worse yet, not get a stack fault and inject a frigging bug that is very intermittent and ends up shipping to the customers since it was never detected.

So in the same way that I used to review my exams in college before submitting them to the math professor with his amazing footlong beard, reviewing code before compiling makes sense, too.

(A note to men with awesome beards: some wives won’t let us have beards, so you’re killing us with jealousy. When you stroke your beard, do you realize you are rubbing this in, and we hate you for it? Stop it.)

Yeah, but what do I know? I only have a master’s in software engineering and was a disciple of Watts (maybe I’m biased because of that, however). I’m PSP certified from Carnegie Mellon and the Software Engineering Institute with a former employer – no, I didn’t say certifiable or am I? Doing three weeks of intensive software metrics analysis as part of the certification though may make you certifiable.

Don’t Let Your Rockstar Programmers Define Your Stack

I know it gets tempting to do whatever he or she wants. You value them so much. They are innovators and technical leaders in your organization. Yet, when we choose a stack for our next project or start-up, we must think more strategically.

It’s not just about keeping your rock star programmer(s) happy. Often you can achieve that by just taking him or her to a Star Trek or Star Wars movie — and supplying all the Mt. Dew and pizza the team can handle. No, you have to think about lots of other things, too. For example, will using this stack cause any vendor lock-in?

Using the Microsoft stack is notorious with vendor lock-in. Yet sometimes the cost of lock-in is simply a necessary evil. What about support? Here is where you’ll see more benefits going commercial. The Linux or open source LAMP stack, not so much. Yet, if you go with the LAMP stack, lock-in becomes less of an issue, but where do you get support? Sure there are some companies out there but not the size of Microsoft, Apple or Google.

Running a successful project, team or company is more than just having a cool language or stack behind it. You have to think about other things: like support, test tools, and how hard it is to find talent related to the stack.

I know Haskell is super sexy and all the kids are “doing” it. But guess what? Ruby might be a much smarter option — especially if we’re talking about the web. Are you making software that will run on the cloud or a native desktop app? Well, all of this has to be thought out. What cloud will your software run on? Or what operating system. Who are your customers? That is where it all starts. What are they using?  Is this a mobile market?  These are the things that should dictate the stack you use.

If you want to placate your rock star programmer, there are other ways: tell him or her they can write that unique test tool in Haskell or whatever language floats their boat. But don’t let them drive your stack for production code. Accept some influence and hear them out. But know they have a vested interest: playing on a really cool stack that they can brag to their friends about.

The problem is the rock star programmer has a lot of pull in your organization.  They might not be the “typical” leader, but if the rock star is moping around because you didn’t pick his favorite stack, you will need to do damage control.  The morale of the company is very influenced by your rock stars.  If they are unhappy, it is harder for others to be happy.  Besides they probably are doing about three times as much work as the others.  You want them at top form.

So listen to your rock stars, accept some influence (perhaps a lot), but ultimately be strategic about your stack — from a business point of view.  Once you commit to a stack, it becomes hard to reverse the decision.  Just remember to break the news to your rock star gently if you choose a different stack.  And take him — and the team — to the new Terminator movie to make amends.

Just an FYI … I’m still a programmer advocate, but this is one area where I support the business/management decision makers more. Sometimes we need the MBA weenies, too. Like to help keep us grounded!

Is Your Message Being Heard?

Trying to get your message heard, organically, whether you are a startup founder or run a nonprofit can be difficult. Which blogging and/or social media platform(s) should you use? Long-form blog posts or short videos? Hum…

The Universe is Multimedia Rich Baby

Well, do you remember back in the day when keyword stuffing was the thing. OK, I never did that, in fact, it kind of predates me but I do remember seeing lots of web pages stuffed with them in the early web 1.0 days. Now it’s all about engagement and multimedia rich content. If you simply write content, unless it’s highly controversial and/or engaging, you likely won’t get a lot of traction with long-form blogging anymore–as traditional blogging is kind of dead…more on this later.

Just look at what gets in your feed on Facebook or Twitter. Almost all the content you see is in the form of videos nowadays. For people that have jumped on the platform early AND are being noticed because they write good content, they can still write regular blog posts, perhaps even long ones, and likely get great results. But for the rest of us or anyone joining a new social media platform, the way to get noticed organically is with video. And I’m not just talking about putting a video up on YouTube and sharing it on Facebook rather uploading video on every platform you are on should be your strategy.

And why is this? Well, it makes sense if you think about it from the perspective of the social media company. They are essentially crowd-sourcing content creation in order to bring eyeballs to their platform–and you thought they were trying to just create a space to share photos with your friends and family and had no hidden agenda.

But, in fact, the more eyeballs and the longer their users stay on the platform the more ads they can put in front of them. And that is what attracts the advertisers. Advertisers can then target their audience with great specificity too since Facebook knows so much about their users; it’s pretty scary how much they know isn’t it.

Look at the time you personally spend online. Likely more and more of it involves consuming videos. I know that’s true for me. Sure, I like to read and read a lot but a bigger slice of the pie with my own content consumption is video.

So my suggestions for anyone wanting to get their message out there and be heard is to incorporate video in your content creation. I believe writing should still be your primary focus as it’s the foundation of ideation and can function as the outline or script to more media rich content, but video is way more likely to get you noticed (organically) and in front of your ideal audience.

And don’t just host it on YouTube. Host it on all the social media platforms you are on. Why? Think in terms of the social media company again. They want the media hosted on their own site so they have control of its playback such as quality, metrics, speed, server hosting locality, etc. There doesn’t seem to be a penalty to host on multiple platforms so why not.

Oh, by the way, my videos are coming soon. Stay tuned!

(Another anecdote… I had a math blog a couple years ago that I put together as a hobby. It had a web presence and a YouTube channel. The YouTube channel got 100s to 1000s of views a day and they were of friggin’ math proofs, hard sh*t. My web content got single digits to perhaps 20 views a day. Video is king!)

It’s All About Engagement

If you make amazing content but aren’t getting much engagement, you likely will have a problem getting attention to your work as the social media algorithms are all tuned in on engagement now more than ever.

Say you are a poet that writes about love–what else do they write about ..ha ha. If your posts involve mostly beautiful writing with lots of metaphor and personification (remember rocks can cry) and the most engagement you get is an occasional reader saying, “Beautiful, well done,” you likely will have trouble getting traction. Sure, engagement is more than comments; it’s shares, likes, etc.

But content that is more personal to a reader, like a lot of art is as in this example with the poet, tends not to get shared as much as the classic how to or a controversial post on politics. How tos and the writer’s creative nightmare, the listicle, are probably the most shared articles there are. They bring value that is immediate and indisputable–depending on its source!

So what to do? Make sure some of your posts are a bit controversial or more engaging. Ask questions to get more engagement? If you are a poet hoping to get more readers to your work, ask them if your use of metaphor tickled the underside of their fleshy frontal lobe or add allusion to other creative works that pique their interest and may be interesting for them to comment on. Or write a how-to post before Valentine’s day that would be geared toward the mindless men without whom a woman’s world would with certitude wither away without the wacky words penned by their beloved men with whom they are betrothed–huh?

The bottom line is to write content that makes an impact, resonates and causes them to take action; perhaps it helps them solve a problem, a problem that maybe their buddies have as well and so they would want to share. Make a mark on them.

So whether you are a poet hoping to gain fans of your work, or an entrepreneur with the coolest new communications app that connects cougars to their sought after stud-muffins, produce content that creates engagement. Make an impact with your words and don’t forget video. Make it and get it out there, pronto. Eyeballs are awaiting!

What tricks or tips on getting your content noticed have worked for you? Share in the comments below. And if you liked this post, please like/comment and/or share.

Writers & Entrepreneurs … Find, Then Delight in Your Blushing Bride, the Muse

Is your muse hidden, nowhere to be found?  Has she grown tired of seeing you lick your war wounds.  Or has she escaped your, figuratively speaking, drunken tirades that you delight in when you’re feeling infinitely insecure, seeking refuge in some other great vessel.  Is she a he?  Is she a cause?  Is social justice, perhaps fighting the patriarchy, your light?  Or has the muse of your passion tree not yet born fruit.

Maybe your muse is like a delicious Colorado peach, just not yet in season but waiting to be playfully plucked.  Before you achieve greatness, you must identify your muse.  Your muse is that which lights your fire and excites you to get out of bed at 3 AM, despite Fido giving you an evil eye for disturbing his sleep.  The muse may pull you even from your real-life naturally naked bride during your hedonistic honeymoon.  The muse is that perpetually powerful and fierce force.

Step 1.  Identify your muse.  What spurs you to smile, cry, yell or fight?  In a hundred years time, how would you like to be known?  Are you hopeful of becoming a healthy healer, gushing-with-ideas guru or titanic-sized thought leader?  You can find the root of your muse, namely, by flushing out of your mind that which pulls at your heart’s desire?

Pull harder if you need to.  Ask your family of friends and friendly family for clarity, too?  But trust your gut.  Only you know wherein lies the muse.  You can beckon her but not they.  For they don’t know your spirit, your soul or your inner workings.  Only you can shine a light on that.  And when you find her, she will most naturally be in repose au naturel and waiting for her lover — you.  (This was added to wake up the male readers!)

Beyond a query of the deep recesses of your mind, look at your surroundings.  Artifacts of what she had for breakfast and likely lunch will be evident.  Put on your discoverer’s hat and investigate these territories.  What bodacious books are on your beautiful bookshelf?  What art or posters are on your walls juxtaposed with your favorite female nudes? (I’m assuming you’re French. Ha ha.)

Where do you currently invest your time and treasure?  What cause would you spill blood for or have?  When you’re ecstatically elated, what triggered this?  Angered by societal and social matters?  Ask a social justice warrior if they’ve found their merry muse?  You’ll see it in their acts, at least for the ones that have found her.

When you find your muse, she will punch your creativity into high gear, and your innovations will spill over.  Writer’s and/or entrepreneur’s block, etc., no more.  She will be your nuclear fuel.  Mars awaits.  Strap in because there’s no off switch.

Step 2.  Nurture and make love to your muse.  Yet now you’ve found her, and she is beautiful.  So now don’t lose her, because she may be foolishly finicky and not want to waste time with someone who would sinfully squander her gifts of gold.  Water the garden of love for her, pull those weeds, and stay focused on the mission guided by your muse and mistress.

Take care of yourself as not to burn out.  So take your new bride out and love her.  She is yours as long as you lavishly heap love on her.  And don’t be naughty or neglectful or you’ll wake up in the night all alone, once again, with nothing but wonderment and wishes. All that will be left will be your memory of her and the echo of your still voice in that dark chamber of your inconsolable mind.

The muse is our gift from above, but she must be cherished, nurtured, and loved on a daily basis or suffering will result.  She drenched you with her light, hope and dreams that they may be fully transformed to you.  It’s time to stop the silly suffering and win at life and with your art and innovations.  Your impact.  There is no more time now for drunken eyes and thoughts — no self-pity.

Now take your muse to the corner bistro and show her off.  You’re now a richer person than Donald Trump.  As with her by your side, no one can claim a better life.  Your impact on the world will be known.  Just keep watering that garden and the fruits shall soon bear.  Trust in that.

Impressions Versus “Impactions”

For us entrepreneurs, writers and creators, the question is should impressions really matter to us? An impressions is that little number that Twitter reports to us regarding a particular tweet, allegedly how many people “may” have seen your tweet. (Most other social media platforms report this as well.)  Should we care?  And if so how much?

For starters, generally speaking, the number of impressions is beyond fuzzy. What, in fact, is an impression? Perhaps it means “some” people caught a glimpse of your post in their feed but never even read the headline.  Does that count? What kind of impression was that? Probably not so good.  Oh, but let’s say they actually clicked on your tweet and maybe even read your post that you linked to.  Or let’s say they liked it or even shared it.  Now we’re getting somewhere, right?  Well, yes and no.

If impressions — and even engagement — aren’t necessarily what’s most important, then what is most important?  Well, getting someone to read your article AND have it impact them or leave a mark!  As in, having them take action because of it.  And how do we describe that?  I call this impactions — just made up that word.

The best way to describe “impactions” aren’t in how many people may have seen your tweet, or how many likes or favorites you got, or shares for that matter, rather, it’s about putting the focus on making a direct impact on the reader.  For example, it’s someone who meets you or writes to you about how your blog or book, product, or service, has made a substantive impact and improvement in their life; now that’s the impact we should be going for.

Shares, likes, etc., are nice — and even simply impressions — and we do need to get our message out and engagement is taking us in the right direction, but we first and foremost should be focusing on making an impact with our message.   Our focus should be on our reader and improving their life or business.

The impact is the secret sauce to getting passionate fans (super fans) or building up a readership.  Because if you have or create an impact in someone’s life, they are much more likely to share your message, buy your books, use your service, and generally be allies or partners in your mission.

Think of the teachers who you most remember.  Were they the teachers who just showed up and so-called “punched in?”  No.  I bet they were the teachers who went the extra mile with you and helped you with a caring and compassionate heart.  They were other-focused and serving their students by being great and caring teachers.

So if you’re a nutritionist blogging about health and nutrition, you should hope to get comments like, “Since I started reading your blog six months ago, I’ve being eating healthier; I lost 20 lbs, and I feel so amazing now. Thank you!”

So don’t “phone it in” with your content.  Your message is too important for that.  Connect on a deeper level with your readers, build relationships, and with it trust by being immensely helpful and work to make an impact in your reader’s life.  Because if you can make an impact, you will likely see your own bottom line grow the most as well.

So it’s not enough to just get a bunch of impressions or even the more elusive engagement. Instead, focus on making an impact in your reader’s life.  Focus on “impactions.”

When or If You Criticize Someone, Do This

Being critical of things, people, services or brands is the American way — OK, the way of the world.

Like what newly married husband hasn’t said to his wife, “Honey, you weren’t in top form tonight. Is everything OK?” Yeah, not the best post-coital convo. Or dinner conversation like, “Honey, did you forget to salt the matzah ball soup? It tastes bland. And oh, by the way, my mom is coming over tomorrow and wants to help you arrange the furniture. That’s OK, right?” As she proceeds to chuck a bagel at you.

Well, if you feel the need to critique, especially a person, here are a few tips to be most effective. And stay away from critiquing the Mrs. — ever! Well, unless you have really good healthcare.

  1. Criticize the ideas or behavior, not the person.
  2. Value the relationship and the feelings of the person you’re criticizing over the message.  Make sure your criticism is constructive, not destructive.  Blogging, for example, is a form of social media — I think of it like long-form social media opposed to micro-blogging, like Twitter.  The operative word, however, is social. So in the social media spaces, be gentle — especially with those whom you don’t know well.
  3. Ask yourself, would Buddha or Jesus — insert other guru or perhaps Gandhi, Mandela or MLK — say what I’m saying … in the way that I’m saying it?  If not, consider how they might say it.  So, sure, 99% of others don’t do this you say.  I say resonate higher and be a model to others.  Words matter and how you say or write them matter.  Words can be weapons.
  4. Recognize the law of reciprocity (kind of like karma).  If you want greater _____, serve others first and the rest will follow.  Is your critique serving them or tearing them down?  Either your critique will bring you closer or push you apart.  There’s rarely a middle ground or neutrality.  All the spiritual gurus speak of love, reducing suffering and healing the world — uniting yourself with your fellow man or woman.  Is your critique doing that?
  5. Put yourself in the other person’s shoes.  Try and develop empathy.  Would you want to receive such a critique?
  6. It is not the intent of your critique but the perception that matters.
  7. If you’re commenting on a forum or blog, read your comment before posting it in the worst possible tone — same when tweeting or emailing.  Because that’s the tone most likely to be perceived by the reader.  Online communication lacks nonverbal cues, tone, etc.
  8. Preface your critique with something positive or affirming.  Similarly end your critique with the same.  Hence, sandwich your criticism in kindness.
  9. As much as is possible, criticize in private, not public.  Of course, online, this is all by definition public and expected on forums, blogs, etc.  If a serious conflict occurs, however, you should go private and in-person if possible, phone or worst case use email to try to resolve it.
  10. Assume the person you want to critique is already suffering and doesn’t need any undue pain.  I can assure you they probably are.

Constructive criticism isn’t designed to wound, but to help.  To serve.  Don’t try to destroy someone who most likely is already suffering by heaping on your destructive criticism. Develop compassion and empathy.  Play your part in healing the world.

So in the case of commenting online, try to have SOME positivity.  A comment that is 100% critical would appear too negative to the reader — it doesn’t feel good. Us geeks hang out a lot online. We need to improve our etiquette in this space. We are the worst offenders of online behavior. We all need to file down our tongues and get Buddha-like. Doesn’t his following say you shouldn’t even harm a mosquito?

Anyway, although we can often learn the most from our strongest critics, if the message isn’t packaged well, it is often lost on the receiver.  If you offend, you likely won’t influence.  You likely will create more distance with the person and create more suffering.  And the world doesn’t need more suffering.

If you wound someone with your criticisms, you only increase the likelihood of getting wounded in return.  Hurt people, hurt people.  In other words, the hurt person may seek revenge.  The cycle of conflict requires one to break the cycle and not contribute to it.

Caveat:  I want to clarify a point before leaving this post.  There are times where your ideas or message must be of the highest priority, and the feelings of the receiver, second.  Say I love robbing banks and you are challenging me on this.  You say, “It is wrong, immoral, etc.”  Then I say, “Stop it, you’re hurting my feelings to try to shut down the debate.”  So, yes, there are times where your ideas or message must come first, and the feelings of the receiver, second.

Yet, most of the time I believe it’s best to be mindful of the person’s feelings and put them first.  I believe you will have more influence with that approach.  The reason you have a favorite teacher or professor, etc., is likely more than just they had great ideas.  Often it is because they cared about their students AND had great ideas, etc.  Great leaders also care about those they lead. Caring about the feelings of others is actually win-win.