How do you make a bowling ball curve?

Bowling, a game played simply for the fun involved in it. An indoor game which is presumed to be too easy and of course without strategy. Just aim and throw a ball, right? A wrong presumption without a doubt! It is important to maintain proper holding position, as well as avoid injuries through slipping or twisting.

Curving a bowling ball is one of the common strategies used in quite a few games. To a first timer, it might seem like a wow! How did you do that’ moment, but it actually is quite doable. Holding the ball in the “hand-shake” position and maintaining it during the release, without slacking your wrist can be deemed the easiest way to curve the bowling ball. But to achieve it, safety of your wrist and ankle should be a priority.

Maintaining proper balance while bowling is of as much importance, as rolling the thumb (or pinkie in very expert cases) at release over the ball to make it curve. Though for wrist protection, it is only your skill, practise and presence of mind that you can use, but for your ankle and balance, proper bowling shoes are a necessity and very important aid. More info about bowling shoes here.

Finding your perfect bowling shoes is a beginning of ensuring an injury free bowling session. With the weight of bowling ball and lack of high friction of the shiny wooden floor, a proper pair of bowling shoes are your only defence against broken bones and ruptured muscles.

The next to last step as we all know is a ‘power step’, so a proper pair of bowling shoes have one sliding and one traction shoes based on your bowling hand. This is usually not the case with the bowling shoes they provide you at bowling alleys as they need to cater both right and left handers.

Apart from safety point of view, a proper feet positioning and thus effective bowling shoes are essential. To maintain a proper grip, to provide the friction enough to keep the player from slipping, bowling shoes need to well acquaint to your feet. Thus using the bowling shoes provided at the bowling alleys are avoided by the regulars, who without fail get their own bowling shoes.

When you rotate your thumb over the ball at release to curve the bowling ball, your bowling shoes need to maintain a perfect grip or this could not only cause the ball to go in a completely different direction, but also cause your body to go in the direction of the floor.

So especially for a beginners, having a nice pair of bowling shoes is a necessity simply to avoid falling on their backside or injuring a wrist trying to attempt a fancy curved bowling ball.

How to be Creative

Remember what it was like to be a kid? Adults always told me that I could be anything I want when I grow up. And having a strong imagination was considered a good thing. Of course, as an adult, imagination tends to be looked at as a distraction from real work at best.

I may groan about this from time to time, but there’s good reason for this. I can imagine the neatest castle, but it does me no good if I just have enough wood to build a trailerhome.

Here’s the thing though, being creative requires that you unlearn the things that make you a practical adult from time to time. I think this is why creative types can earn a reputation for being so impractical: they are. In fact, it’s part of the job description.

So how does one remain practical while being able to unlock their inner childish creativity? Personally, I’m more concerned with losing my ability to be childish as I age. No matter what you do, there’s always someone to remind you how to be an adult. When was the last time anyone told you that you need to be more immature? Or that you are too practical?

I think the key is to keep in touch with what excites your inner child as you become a wise adult. What can be more powerful than someone with the imagination of a child and the adult wisdom required to make it real?

Programming’s dirty word

Programming

Us programmers tend to be a logical, pragmatic bunch. We’re good at choosing the option that is strictly speaking the most practical. And yet, I have yet to hear a programmer ask the question “Will anyone want to work with this?”

And there’s the dirty word: want. Many times, we get so caught up in finding the way that will be the most efficient that we forget why we became programmers. I don’t know about you, the reader, but I became a programmer because it’s fun. The moment I stop enjoying what I do is the moment I stop being a programmer and start being a paid coding monkey.

And here’s the kicker: this rabid focus that we have on the practical isn’t practical. It’s quite idealistic in fact. Looking back, the best projects that I’ve completed aren’t the ones where I had an easy, efficient way out. In fact, they’re frequently projects where I get to try something new out or get my hands dirty discovering better ways to solve old problems. In short, as long as you don’t get too distracted from the task at hand, wants are practical.

Now, I already know what counterarguments I’m going to receive from this post, so let me take a moment to address them:

  • You can’t always get what you want. And you would be absolutely right to make this point. No matter what you do, you’re always going to run into a situation where you have to do something you don’t want to do. However, you don’t completely abandon the idea of life just because you’re going to die at some point. Instead, you focus on living as long and enjoyable a life as you can.
  • You’re putting your own desires ahead of your team’s. I’m certainly not arguing that any individual programmer needs to be able to sabotage the rest of the team just because they want something. It is extremely important that you take what others want into consideration in addition to what you want.
  • Programmers need to focus on building a product, not the code. This sounds like something a Product Manager or startup founder would say. And I would agree with it to a certain point. It’s important to work on a product that’s important to you. However, I’m not a Product Manager or startup founder. I’m a programmer, and product design really makes up about 10% of my overall job (and that’s being generous). The rest of that time is spent coding. And programmers shouldn’t have to apologize for wanting to make that time as pleasant as possible.
  • You’re not being pragmatic. You’re right, I’m not being completely pragmatic, and neither should you. The ideal solution is one that is pragmatic and enjoyable. Given a choice between a pragmatic solution and fun one, you should always choose the pragmatic one. After all, a fun but completely impractical idea will never see the light of day. However, things are rarely so black and white. You have to learn to balance tradeoffs. Such as the tradeoff between practicality and enjoyment.

I suppose the main thing that I’m trying to say here is that what you want is an important consideration in addition to what you need (despite what the Rolling Stones would have you believe).

Persistence is a subset of immutability

Whenever I tell someone I’m working on a persistent data structure
library for Python, I almost always get the same response:
“Persistent means that something is stored across process boundaries.
I think you mean to say immutable data structures.”  In fairness, this
response is understandable.  But it’s not quite right.  I’m going to
address both of the points in the above statement.

Persistent means that something is stored across process boundaries

Did you know that letter can mean a note you send through the mail or a thing you use to make up words?  Did you know that programming can mean writing computer programs or mathematical optimization?  I’m sure if I sat down long enough, I could think of more examples.  The point is that the language we speak is full of ambiguities and whatnot.

Before we consider the computer science meaning of persistence, let’s
look at the common meaning.  If we look at the word persistent in
Merriam-Webster, the first two definitions we run into are:

1 : existing for a long or longer than usual time or continuously: as
a : retained beyond the usual period  b : continuing without change in
function or structure 

The meaning Python programmers tend to think of is the definition in
part a.  That is, a persistent data structure is stored beyond the
usual period (the process’s lifespan).  However, when I talk about a
persistent data structure, I tend to mean the definition in part b.

Going with definition b, we can see that lists for example aren’t persistent:

  1. >>> a = [1,2,3]
  2. >>> b = a
  3. >>> b.append(4)
  4. >>> a
  5. [1, 2, 3, 4]

Tuples, however, are a different matter:

  1. >>> a = (1,2,3)
  2. >>> b = a + (4,)
  3. >>> b
  4. (1, 2, 3, 4)
  5. >>> a
  6. (1, 2, 3)

 

Ah, but here’s where the second part of this post comes in.

I think you mean to say immutable data structures

In the case of the tuple, you are correct to say that a tuple is
immutable.  And I’m correct in saying that a tuple is persistent.
Just like I’d be right to say that I own a car while someone else
claims that I own an automobile.  However in both cases, they can’t
quite be used interchangeably.  After all, an automobile isn’t
necessarily a car.  It can be a truck or a van or an SUV.

In the same sense, a persistent data structure is effectively
immutable.  But an immutable data structure isn’t necessarily
persistent.  Let’s consider the definition of both of these words from
wikipedia:

Immutable object

In object-oriented and functional programming, an immutable object is 

an object whose state cannot be modified after it is created. 
Persistent data structure

out site In computing, a persistent data structure is a data structure which 

always preserves the previous version of itself when it is modified; 

such data structures are effectively immutable, as their operations

do not (visibly) update the structure in-place, but instead always

yield a new updated structure. 
These definitions have a lot of common ground, but there is some
difference between them.  Let’s consider a data structure that is
immutable but not persistent.  Prepare yourself.  This will be
complex.  Ready?

  1. >>> 1
  2. 1

 

Has your mind been blown yet?

In this sense, the number 1 is definitely immutable.  You can’t change
it.  It’s always the number 1.  However, it’s not persistent.  How do
you update the number 1?  No matter what you do, it will always be the
number 1.  Sure, you can get 3 by adding it to 2.  But in a
mathematical sense, that’s not really changing the number 1.

In this sense, the number 1 is atomic.  It simply doesn’t make sense
to modify it.  Heck, you can’t even copy it:

  1. >>> from copy import copy
  2. >>> a = 1
  3. >>> a is copy(a)
  4. True

Conclusion

With this semantic difference in mind, remember that it’s just that:
a semantic difference.  Call them Bob if you want to.  However, bear
in mind that when someone uses the word persistence in this way,
they’re not being inaccurate.

Embrace quirks when working with others

Pygmalion

For me, learning to work with people was a two-step process:

  1. Realize that other people are different from me. And I don’t just mean that other people just act differently. I mean they are completely different with different motivations.
  2. Realize that this is actually a good thing.

It seems to me that Derek Sivers has learned the first lesson, but I’m not sure that he’s learned the second. When we realize the first lesson, most of us try to avoid the issue. If people are different, the goal must be to suppress those differences. Unfortunately, people just don’t work that way. David Keirsey would describe this as a Pygmalion Project.

For those of you who aren’t familiar with Roman Mythology, Pygmalion was a sculptor who could not find the perfect woman. Solution? He sculpted one. Venus was touched by this story, so she turned the statue into a real woman.

This is a cute story, but it parallels reality more than we realize. Like Pygmalion, when we encounter someone who’s different our first instinct is to shape them into something that’s the same. Keirsey talks about this as the downfall of many relationships: we go to great lengths to find somebody who is different from us, but then we try to make them into ourselves. Of course Derek shows that one can have a Pygmalion project on themself. If we view ourselves as abnormal, the solution is to be more normal.

This tends to have the effect of lowering one’s self esteem. No matter how hard you try, you can’t make yourself be something you’re not. If you try to suppress your quirks, you will either fail or become a mediocre version of what you perceive as “normal”.

I would argue that not only is it not feasible change peoples’ personalities, it’s not preferable. Your quirks are what make you unique, and they are the reason your coworkers need you. Quirks are different ways of looking at things. Rather than suppress them, learn to appreciate them. Most importantly, become proud of your quirks. Other people may not understand them, and that’s the point.

The only time quirks become problematic is when you turn them into Pygmalion projects. If you expect others to share your quirks, you will quickly run out of friends. However, when you learn to appreciate quirks in yourself and others, you become a better person. You begin to appreciate peoples’ strengths and weaknesses. If you pay attention, you might even discover that the person you thought was incompetent is really just different from you.

The moral of this story: Embrace quirks, but don’t enforce them.

REALLY Caring for Your Introvert

Joel Spolsky

After rereading my last post, I realized that it didn’t really paint introverts in the best light. It makes introverts seem selfish. That’s actually a good thing because that’s how introversion tends to look to extraverts. But that’s not really accurate.

Here’s the funny thing about personality: disputes tend to happen between people when they have opposite ways to do the same thing. Whereas extraverts respect people by integrating their thoughts into the whole, introverts respect people by leaving them alone. They view trying to merge peoples’ thoughts into one big whole as an attempt to “water them down”. Thus, introverts will constantly try to differentiate themselves from the common point of view.

That said, introverts would do well to heed Derek Sivers’s advice that sometimes Persistence is Polite. People aren’t usually as put off by an introvert’s “intrusion” as they imagine them to be.

Thus far, I’ve only focused on applying the concept of introversion and extraversion to how we make decisions. But they also affect perception.

Let’s look at Joel Spolsky. If you look at Spolsky’s famous “Don’t rewrite your software” blog post, you can see that Joel is obviously extraverted when it comes to making decisions. It might be easier to see this if you realize that psychologists refer to extraverted attitudes as “objective” and introverted ones as “subjective”. In other words, extraverts tend to look for the “one true” plan or way of seeing things while introverts will be focused on trying to find a plan or truth that works for them. You can see Spolsky’s extraversion in decision-making when he says things like:

They did it by making the single worst strategic mistake that any software company can make

out site or

The old mantra build one to throw away is dangerous when applied to large scale commercial applications.

or

But throwing away the whole program is a dangerous folly

Heck, even the title of the blog post (“Things you should never do”) is extraverted. These are all couched in very logical language, but taken together you can see an overarching theme: “There’s one true way to write software, and the only way to figure it out is for everyone to add their little piece of the truth. Here’s mine.”

However if you look, it’s clear that Spolsky also has an introverted side. Consider the following phrases:

The reason is that they think the old code is a mess.

or

The consensus seems to be that the old Netscape code base was really bad. Well, it might have been bad, but, you know what? It worked pretty darn well on an awful lot of real world computer systems.

or

“Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.”

You can see that Spolsky has an introverted way of perceiving the world that complements his extraverted decision-making. The hallmark of the introverted attitude is the desire to separate oneself from others. The overarching theme of these phrases is “they see the world like this, but I see the world like this”, which is introverted. That the others are wrong is just a side effect.

Again, even though I’ve pointed out Spolsky’s introverted side and extraverted side, remember that this is still oversimplified. I’ve pointed out what I see as his primary ways of looking at things, but you can see others in the rest of his text.

So how can an extravert get along with an introvert?

  1. Agree to disagree. Extraverts tend to dislike ending a conversation without everyone coming to a consensus. Unless the matter is completely trivial, introverts dislike ending a conversation without having differentiated themselves from the other person somehow. If possible, try to find a happy medium. End the conversation by pointing out things you both agree on (carefully: make sure to couch this with phrases like “It sounds to me like you agree with me on x, y, and z”), but acknowledge that there are areas where you both disagree and that’s ok.
  2. Realize that when an introvert is quiet, that doesn’t mean they don’t respect you. If you need feedback from them, try to do so in a way that is respectful to them. For instance, say something like “Hey, whenever you have a moment can we discuss x?”
  3. Don’t go too far in accepting their worldview. Some people (both introverted and extraverted) might try to take advantage of your desire to connect with other people. Always be skeptical of someone whose judgement of you is dependent upon you giving them (or not giving them) something they want.