Category Archives: People Skills

My Old Master: On Optimism

The “My Old Master” posts are non technical posts in reference to my karate (shaolin kempo) teacher, and the things he taught my friends and I over a decade to be martial artists (peaceful warriors), instructors, and better human beings.

I’ve been in a funk for a few weeks – ever since the time change.

Several things have aligned just so to make things particularly shitty, such as the children being sick, them not sleeping, our son transitioning to preschool, holiday and other responsibilities eating up the almost non existent free time, and perhaps most of all, me missing/skipping my weekly exercise routine.

I’m starting to recover (sleep and exercise have been helping a lot) but in doing so, I’m reminded of some things “my old master” told me on the topic of optimism, that I think are worth sharing.

As time passes, I see more and more about how the most successful people use “brain hacks” to help them ensure success. It’s weird to think of your brain and your instincts as tools to leverage to your advantage but they totally are.

As a quick example, if you are aiming to eat fewer sweets, making sure you don’t have any around the house is a great first step to achieving your goal.

Ages and ages of evolution of our species have hard wired us to go after those calories so you don’t starve. It’s very very difficult (read: impossible) to combat that. The best thing to do is to not even have the option.

This is a hack to help you succeed in your goal.

Optimism, But Not Blind Optimism

Just like in the sweets example, optimism can be a great tool for achieving your goals, but as we all know, blind optimism is foolish and can definitely negatively impact your goals.

To reconcile these two things, we should “Expect the best, but plan for the worst”.

This makes us optimistic, but if things go wrong, we aren’t completely blindsided and unprepared.

Why should we be optimistic to begin with though?

Because: “You get what you expect”

Imagine your neighbors dog is consistently pooping near your house and the owner is not cleaning it up. You decide it’s time to confront them about it and go knock on their door.

There’s two ways you might go into this situation.

The first way might be, you are pissed, and you expect a fight. They open the door, see you angry, immediately their “guard goes up” and there’s little chance the outcome will be anything other than an awful experience for one or both of you. The person may even make it a point to have their dog poop on your lawn and not clean it up.

The second way might be that you realize you’ve seen your neighbor playing with their kids, being a good parent, and that in general they seem like a good natured person and a good neighbor except for this one issue. Because of this, you figure the conversation will be completely peaceful, it will be totally fine, and your neighbor will “get it”. They open the door, see you smiling and hear you using a friendly respectful tone, and they respond similarly. Perhaps they are embarrassed about it even, and profusely apologize.

It’s definitely true that neither of these situations are guaranteed to play out like this, but the odds are improved that they will.

Improving the odds for getting what you want is a good thing. If you don’t go into it blindly (prepare for the worst), you are also in a reasonable position if things don’t go like you want them to.

Finding The Positive

There are negatives and positives to every situation. Whichever you focus on is up to you.

Imagine yourself in a dark room where there is sewage in one corner and a pile of shiny gold in the other. You have a flash light. Which are you going to look at?

Whatever you choose to focus on will rattle around in your head and become amplified. This is the story about there being two wolves in us, and whichever we feed is the one that gets stronger.

You may notice this in yourself in fact. Have you ever dwelled on something negative only to have it get worse and worse in your mind, til it was unbearable and causes you to do something? Perhaps quiting a job, telling someone off, or similar? Maybe you have some of this going on right now somewhere in your life?

Recognizing and disrupting those patterns can help you keep from over-reacting or incorrectly reacting to situations, both of which are inappropriate because of the fact (and identified by the fact…) that they actually set you back towards achieving your goals.

Taking this mental life hack a bit further, there are concepts to help you visualize your goals, how you are going to achieve those goals, and constantly remind you of these things.

A vision board is one such example. You find imagery that speaks to you and reminds you of what you want, and how you are going to get there, and you put it somewhere highly visible to you that you see every day.

Seeing this stuff daily ingrains in your mind what it is you want to do and how you are going to do it. Any opportunities that come up that help you get closer will more easily be identified and you’ll be in a better position to take them. “Luck is where opportunity meets preparedness”.

For me, this blog is in many ways similar to a vision board. Besides being external memory (for me to re-learn things) and a resume helper, it also helps me remember that I am experienced, skilled and decently talented – or at least persistent enough to achieve meaningful things.

We humans sometime look at how others see us to get an idea of ourselves and base our self worth on that. That is a pretty awful idea though, as other people don’t know always what we are capable of, and frankly probably don’t even care, as they have their own agenda and goals.

Whatever you can do to help you visualize your goals and how you are going to achieve them is going to help you succeed.

If you ever find yourself in a funk, I highly recommend these three things:

  • Make sure you are getting enough sleep
  • Make sure you are getting some exercise (an hour martial arts class a week is enough for me to feel the benefits!)
  • Look to see if you are having any cyclical negative thoughts. If so, see if you can break out of them by turning your flashlight onto the gold, instead of the poop. Possibly using something like a vision board, or whatever works for you.

Thanks for reading!

A Tool To Debug Teams (Knoster)

In the professional world, programmers work in teams as a rule, with very few exceptions.

For the programmers aiming to remain programmers, and not going into management, we are often focused on our specific trade or area of expertise though, and so we spend less time learning about or thinking about what makes a team successful.

We learn some from personal experience – realizing that certain things are bad for a team many times by seeing the failures manifest in front of us – but we are definitely more likely to pick up a book on algorithms than we are a book on team management.

My mother in law is the opposite however, as part of what she does is mentor people to being leaders of teams and large organizations, and also consults to organizations in the field of education to fix budgetary and organizational problems they may be having.

She showed me an interesting chart the other day that is really eye opening. It’s a formalized look at how to identify some things that may be going wrong with a team.

The chart itself is from the educational sector (Tim Knoster in ~1990), and is meant to be used to “Manage Complex Change”, but looking at it, and having been a professional programmer for 16 years, it is definitely applicable to any team.

The chart is valuable whether you are leading a team, part of a team, or observing a team you are not a part of.

How you use this chart is you look on the right side to see what sort of problems your team may be having: confusion, anxiety, resistance, frustration, or false starts.

From there you scan left until you find the black box. That box is the element missing which is causing the problem for the team.

That’s all there is to it, it’s pretty simple. It actually seems like pretty obvious stuff too in hindsight, but I wouldn’t have been able to formalize something like that.

Obviously not every situation can be boiled down into a simple chart like this, and there are variations of this chart including more or different rows and columns, but this is a good start at trying to “debug a team” to figure out the source of an issue.

Want more details? Here are some links:

http://www.belb.org.uk/downloads/rc_knoster_managing_complex_change.pdf

http://www.d11.org/LRS/PersonalizedLearning/Documents/KnosterMANAGINGCOMPLEXCHANGE.pdf

http://nebula.wsimg.com/90f9e490329402583fea599cad009bb0?AccessKeyId=8AAC8D005153628DDDFA&disposition=0&alloworigin=1

My Old Master: How to Correct as a Mentor or a Teacher

Preface: I studied martial arts for a little over a decade (shaolin kempo at USSD) and learned a lot while I was there. Our teacher was a great guy who genuinely cared about his students, and in particular, taught my friends and I some really interesting things when we became instructors. I’d like to share some of that information with you in the “My Old Master” posts category. As cliched as it is, many things he taught us apply to all aspects of life, not just martial arts and I’d like other people to benefit from them.

My old master used to say…

“Praise, Correct, Praise. Even if you have to make something up, you need to say something positive.”

Let’s say that I’m teaching you how to punch and you aren’t quite doing it right.

Here are two things I might say to try and correct it:

  1. “Keep your wrist straight when you are punching so you don’t hurt your hand” or…
  2. “I really love how you are keeping your left hand up while you punch with your right. It’s doing a great job of protecting your head against your opponent hitting you back. Now try keeping your wrist straight when you punch so that you don’t hurt your hand.” Then I watch you try again and I say “Great, just like that, keep it up!”

Think about how those two responses make you feel for a second.

The first one likely makes you feel like you are messing up and need to fix it (a negative thing), while the second makes you feel like you were doing well and are now are doing even better.

What’s the difference? Well, like the opening quote says, I praised, corrected, and then praised. First I found something you were doing well, complimented you on it, gave a suggestion for improvement, and then praised you on doing (or attempting!) the correction.

This can be a great way to give people feedback, in a way that makes them feel better about themselves, and feel better about the feedback you are giving them. Instead of being a negative thing, it becomes a positive thing.

Pretty simple stuff, and if you practice this technique it starts to become second nature.

The quote says that if you can’t find anything positive to say, you should make it up. It shouldn’t be your first choice to make something up, because the more genuine you are about the praise, the better it will be. However, if you really can’t find anything nice to say, yes, you should make something up.

A person’s ego and self worth is a measurable quantity that is increased with praise and decreased with corrections or negative feedback (aka “you suck!”). When this tank of self worth gets too low, your student or mentee will feel worthless, get frustrated and/or start to get resentful at you.

This technique is useful because it allows you to give a correction while minimizing hit to the person’s self worth. In the end allows you to give MORE correction and help them more in the long run, just by phrasing your corrections differently. Another term for this is “complement sandwich” which you may have heard of before.

Another thing to be mindful of however is that you can only give so much feedback at any one time. The ego/self worth tank needs to refill after it’s diminished, and frankly, the person needs to absorb and internalize what you’ve taught them before they are ready for more.

Our teacher would say “it’s better having a mediocre black belt, than having a stellar white belt who quits out of frustration” and that’s very true. It’s better for them since a mediocre black belt is FAR SUPERIOR to a stellar white belt and much better able to protect themselves and their loved ones, but also better for the organization, since we are often teaching or mentoring in a “for profit” situation where the person we are trying to help is either a customer or a co-worker which the company is interested in keeping around.

Before wrapping it up, I heard a funny story regarding this topic about a special needs child and his or her parents. Just like everyone else, this child has a concept of self worth, however being disabled makes it very easy to feel depressed when you realize there are so many things you can’t do that other people can do. It’s difficult too for the parents to help the child feel better about themselves if they really can’t find an area he shines in. One day the parents noticed he loved to use tools and it clicked. They started loosening screws in the house and asking him to tighten them for him. “Jimmy, can you come tighten this screw up for us? You are so good at it!”.

I think that’s a cute story but really shows how we work as humans. Your job as (an effective) teacher, mentor, parent, boss or leader, is to teach whatever you need to teach, correct whatever you need to correct, but also to make sure you do so in a way that is least damaging to the person’s ego and self worth. They feel better about themselves, but you are also more effective at getting the job done. It matters!

So go out there and serve some compliment sandwiches, making sure to be as genuine as possible with your praise!

P.S. Yes people can have over inflated egos and feeding them more is only going to make things worse. That’s the topic of another post (;

How and Why Cleaning Up Code or Processes Gives Multiplicative Benefits

The engineering manager of my team Paul Haban (@XpresoAdct) mentioned to me once in passing that when you fix a problem, you often get multiplicative returns beyond the initial problem you intended to fix.

This is an idea from Kanban, and while it was in my best interest to believe this to be true, since it allowed to refactor personally painful inherited systems and code, it felt like a sort of mysterious voodoo and I wasn’t really a believer.

I recently experienced it first hand though. I refactored something and the benefits started multiplying. People from distant sub teams came out of the woodwork very excited to hear about my changes. Of course, this happens from time to time, and it’s a lucky break to get benefits beyond what you were planning, but looking at it in hindsight, there are some really good reasons why this happened.

This applies to source code, processes, etc, but for simpler language, we’ll focus on this being about code.

What is Bad Code?

Firstly, engineering is often about trade offs. You might see that solving a problem one way gives you certain benefits, while solving a problem a different way gives you other benefits. You weigh those things, talk to those affected to get their opinions in case you are missing information, and then you make the best decision you can with the information you have.

Sometimes you make a decision based on the current state of things, but then the situation changes, and the choices you make turn out to be bad choices for the new direction that things have taken. Now your code has turned bad.

Also of course, people sometimes people just make bad choices. We are human, we are learning, it’s how it goes. Sometimes people just make bad code to begin with.

A deeper chat of this sort of thing can be found here: No Bad Code, Creeping Normality and Social Structure Code Organization

But ultimately, here is what makes code “bad”: If it works less than ideally for someone or some thing that has to interact with it, it is on the spectrum of “bad code”, ranging from terrible code, to code that could be cleaned up, but doesn’t really matter enough to fix.

It also may be that code is bad for one set of interactions, while it is perfectly ideal for another set of interactions. This is the result of the trade offs weighed when solving the problem. That may just be a fact of life that you either can not really do anything about, or that in practical terms, you cannot do anything about due to cost versus reward analysis or whatever else.

Lastly, like in my case, you may have inherited some bad code from someone else. In this case, it could just be that you have different goals, or that you prefer a different trade off (pain flavor if you will) than the previous maintainer.

How Does Bad Code Affect Others

By definition, bad code is code that is less than ideal for a person, or code that has to interact with it.

That means that when they interact with the code two things happen:

  1. There are work arounds that have to be done to be able to get what is needed from the system.
  2. There may be perfectly reasonable things that interactions with the system may want to do that are not possible, or not practically possible with real world constraints.

The more central this bad code is, and the more people that interact with it, the more that there is both workarounds, and desired functionality that can’t be realized.

Refactoring

If you can legitimately refactor some code such that the result is decided to be better than where things are at now – say, there is less pain overall, or perhaps the pain is more concentrated on a group that nobody likes (hehe) – making that happen will make the code less bad.

Again, bad code is a spectrum, so it’s likely you’ll hit situations where the code will never be perfectly good code, but making it less bad is a good thing.

When you make code less bad, however you measure that, it means that the workarounds that needed to go up can start being taken down (simpler code, less maintenance, fewer things that can go wrong), and also, you open up the doorway for the improved functionality that was not previously practical.

Another way to think of it is that the optimist will say that fixing things gives multiplicative benefits. The cynic (realist?) on the other hand says that the less than ideal code has already incurred both a one time cost to the people that have interfaced with it, as well as a continual maintenance cost that is incurred by it existing, and that those costs are or were avoidable.

To me, this explains in a very down to earth way how the “voodoo” of multiplicative benefits actually comes about. It also shows a bit of how continual minor improvement really does add up (the main idea of Kanban), even when not taking into account things like the compound interest model (ie, saving you effort now allows you to save future effort sooner).

Go clean up some code, or fix a broken process. You will likely be surprised at how much benefit you get out of it!

I miss anything or you have a differing view? Let me know!

No Bad Code, Creeping Normality and Social Structure Code Organization

In the last post I said that another post was coming regarding using bilinear texture sampling for something interesting. Hopefully without sounding too pretentious, that interesting thing I wanted to write up has shown quite a bit of fruit, so I’m going to try to write it up and see about getting it put into The Journal of Computer Graphics Techniques. We’ll see how that pans out, and I’ll make sure and share once it’s published (or if I can’t get it published hehe) as well as a post on the process of trying to get something published, in case other people out there are interested in pursuing that sort of thing.

Today’s post is a bit different than usual. There are some interesting concepts that I’ve been exposed to that I think are worth sharing, and that I’m hoping you will also find interesting.

No Bad Code

One idea presented to me recently was the concept that there is no bad code. The idea being that people make decisions in code based on the situations at the time, and that as situations change, code that once was totally reasonable, and most engineers would likely have made the same choices, no longer is seen as a good choice in the new sets of circumstances.

I’m going to be a bit cynical here and mention that I do believe there is bad code, and that it comes around due to bugs, as well as lack of knowledge, lack of experience, and lack of testing before deployment. However, the idea of code that is now seen as bad, was once perfectly reasonable does make sense to me and is kind of interesting.

I know we’ve all hit code that we or others wrote that we despise, causes us grief, and gets in the way of us working what we ought to be working on. This concept definitely does absolve SOME such code I’ve personally had to deal with. But, there is definitely plenty of code left that it doesn’t. In my personal examples, this mostly comes from shoddy third party middleware software, and also, just a lack of knowledge or experience on the part of the implementer. I’m guilty of the second point, but I think we all are, and that is a sign we are learning and growing.

It’s probably good to keep in mind that lousy code of the present may have been perfectly reasonable code of the past, and before deciding that code was lousy, or that a specific engineer is terrible, that you have to judge the code in the light that it was put in.

… Then refactor it.

Creeping Normality

Creeping normality is an interesting concept. Basically, just like that old tale of a frog sitting in progressively hotter water til it boils (which by the way is debunked by snopes), it’s easy for individuals or companies to find themselves in situations that would NEVER be seen as ideal situations, but were arrived at by incremental mis-steps – or also just a changing landscape.

This relates to the last point a bit, because it can show how the needs of a piece of code can change over time, such that looking at it as a static snapshot in time, you might wonder why it’s so complex and trying to do so many different things needlessly.

This can also happen to a company on a more global scale, and can explain some really odd, less than ideal behaviors a company might be doing, where you are pretty sure the people involved know better.

How do you fight creeping normality? Good question… but when you are able to identify some oddness or problems that come up due to it, hopefully it’s as early as possible, and hopefully the people with the power to make things right listen to you (:

Social Structure Code Organization

The last topic is kind of bizarre, but totally makes sense once you think about it. The idea is that code will match the communication structure of the teams making the code.

This is Conway’s law which says: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”. Another good quote from the wikipedia page for Conway’s law states that (paraphrased) “if you have four teams working on a compiler, you’ll end up with a four pass compiler”.

This can be seen a lot in situations where you have a game engineering team and an engine engineering team. There will be a distinct line between the code bases, based on the responsibility of the teams. If instead, you have some code where the engine and game team are the same, there will be no such line, and if you then try to split that team into being a game and engine team, it’ll take some time to draw the line between responsibilities, separate the code along those lines, and possibly do something like get the code into separate projects and possibly code repositories, which all seems like a logical choice to do when you have separate teams.

I think this also relates back to the first point about “No Bad Code”, because were someone to come into a team where the organization had recently changed, they are going to wonder why the code doesn’t have nice abstracted API layers at the boundaries, like most folks would consider logical and good practice. Perhaps too, this would be a case of creeping normality, or at least, if the project organization changed, it could be the result of a reaction AGAINST creeping normality.

In short, there are a lot of ways in which perfectly good code can go bad, and it’s probably a good idea to think about that a bit before condemning code as inherently rotten.

HOWEVER, rotten code does exist. I’d name some names, but it would probably be classified as slander, so i’ll bite my tongue. I’m sure you have plenty of examples of your own (;

Lastly, if you are responsible for crimes against code-manity in days past, either due to any of the reasons above, or because you didn’t know things you know now, or even if you were just lazy or misguidedly purposefully malicious (?!), remember this: You are not your mistakes!

OK, enough of that, next post will be on some cool programming technique, I promise 😛

Situational Leadership

This is a little bit different than the normal kinds of topics I write about, but I found it pretty interesting so wanted to share with you guys. (Thanks for sharing the idea with me Paul!)

This is a “theory of management” type of thing that helps explain why people act certain ways in specific situations, and what sort of management style they need to be successful. I might butcher the details a little bit, but if you want to read about it in more depth, you might start with this wikipedia page: Wikipedia: Situation Leadership.

Let’s kick things off with a diagram:
SLChart

The idea is that basically, when someone is put into a new situation, they will generally progress from 1 to 4(*). This can be either hiring a programmer fresh out of college, or taking an experienced programmer from one team and putting him onto another team, or presumably could also refer to an entire team tackling a new type of problem.

(*) I sort of hate generalizing about how people act, and cookie-cutter-ing people and situations, but I take this as a sort of general guideline, instead of a hard and fast rule for every person and every situation.

Step 1

At step 1, a person is overly confident and think that they know what needs to be done, but in reality they don’t have the skills and/or information needed to actually do what is needed – but they don’t know it yet. A person at this stage needs guidance or pairing with another person to keep from doing reckless things and to keep them on the path towards success.

Step 2

At step 2, a person has learned a bit more about things and realizes it’s a bit more challenging than they thought. There is some drop in morale at this stage, and is where people might contemplate giving up, switching teams, switching companies, or switching careers. At this stage, a person needs “beer and hugs” I’m told. Maybe they also need some smaller, isolated tasks, to give them a sense of accomplishment. Maybe tasks drawing on their passions or previous experience to give them some victories to help them get over the hump.

How often have you found yourself in the mindset? Maybe on a new team, at a new company, working with new technology, and feeling completely overwhelmed, thinking things are too difficult and maybe even wanting to give up, or feeling like you are not preforming well enough?

Chances are, everyone’s felt that way. I know I have! I’ve worked at something like 7 companies in 13 years and early in my career i felt that way A LOT, and OFTEN. It happens less as the years go on, and I find that more skills carry over than in previous days, but it still happens from time to time. That’s a good thing though, because if it didn’t, it would mean I wasn’t learning and growing, and stagnation is no good.

The good news is that this feeling is normal, it’s typical, and if you have a good manager, they’ve seen it many times before and expect it. No, you aren’t under-performing, you aren’t under-qualified, and you aren’t a slacker. But keep working hard anyways so you can get out of this stage!

Step 3

At step 3, a person has begun learning more and is getting more proficient, and starting to feel better about things. Keep on trucking!

Step 4

At step 4, a person has mastery over the subject matter and is feeling good about things. At this point they know what they are doing and are confident, and need a bit of a longer leash to be able to go out into the weeds a little bit to feel good about their work, even if it seems a bit silly. People who are truly passionate about what they do want to be trusted to do the right thing, and they want the freedom to pursue their interests. They’ve worked hard, through challenges both with the work and psychological, and now they are effective and hopefully pleasant – so hopefully they’ve deserved a little bit of diversion time hehe.

Plus! if you’ve done any programming in the areas of genetic algorithms, or training neural networks, you may remember that if you only let the winners reproduce (in genetic algorithms), or you only activate the winning neurons while training (for neural networks), you will likely end up in a local minima, instead of the global minimum. That “longer leash” time of letting people wander into the woods a little bit is kind of like mutation, or letting some of the losers reproduce. They may very well come back with something way better than you ever considered.

Super tangent – someone recently told me that path finding has the same “local minima” problem, and that if you pursue some of the “not so great” paths while searching a pathing space, you can get better results.

Outside of the Box

Anyways….

While this may be a useful tool for helping to understand people’s motivations, and helping to give them what they need to succeed and be happy and effective, this isn’t the whole story of course. Just like there is no such thing as a straight line in nature (AFAIK, but not sure what happens below the plank scale!), this doesn’t exactly match reality. It’s just a useful guideline.

You might also find this interesting, as a different take on the transition from step 1 to step 2: Wikipedia: Dunning-Kruger Effect

Recently I’ve been thinking about a few topics like this that are game dev related, but not about specific algorithms. You’ll probably see some more of this sort of thing smattered in amongst the cool algorithms I stumble on going forward (: