Showing posts with label thinking. Show all posts
Showing posts with label thinking. Show all posts

Sunday, July 19, 2015

Always Bet on Math

"If we offend it is with our good will.
That you should think we come not to offend
But with good will. To show our simple skill,
That is the true beginning of our end.
"
-- Shakespeare, A Midsummer Night's Dream
Act V, Scene I, Lines 108-111


Last week at work we did Pascal's Triangle as part of our weekly Code Dojo.  We followed the animated image on the Wikipedia entry as our guide to the algorithm.



This worked OK and we were able to solve it fairly quickly with something similar to the C# entry on Rosetta Code.  Something like this:


        public static void CreateTriangle(int n) {
            if (n > 0) {
                for (int i = 0; i < n; i++) {
                    int c = 1;
                    Console.Write(" ".PadLeft(2 * (n - 1 - i)));
                    for (int k = 0; k <= i; k++) {
                        Console.Write("{0}", c.ToString().PadLeft(3));
                        c = c * (i - k) / (k + 1);
                    }
                    Console.WriteLine();
                }
            }
        }


This code works but it does not really give the reader of it any idea as to what the code is for.  In order for someone to be able to follow this code they would have to run the algorithm a few times (in their heads, on paper, ...) to prove to themselves that it actually works.

In Rich Hickey's talk, "Hammock Driven Development", he talks about taking time to think.  Which reminds me of a quote often misattributed to Einstein:

Some years ago the head of the Industrial Engineering Department of Yale University said, "If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is."
-- Robert E. Finley and Henry R. Ziobro, The Manufacturing Man and His Job
as quoted by Garson O’Toole at http://quoteinvestigator.com/2014/05/22/solve/

Let us spend a few minutes looking into what the problem actually is.

If look further down in the Wikipedia entry we see the following.


taken from https://commons.wikimedia.org/wiki/File:PascalsTriangleCoefficient.svg

Awesome, Pascal's Triangle can be reduced to binomial coefficients!  Since it has been about 13 years since I got my degree in mathematics I'll need to look up how to use and solve a binomial coefficient.  Luckily MathWorld give use the following:
Great, now all we need to do is have a way to solve for factorials, which we can also find on MathWorld!

We are now all set to solve the problem.

Here is my solution in Clojure:


(I did this as part of my daily kata)

We see in the Clojure code that I TDDed my way into: first a function which will find factorials, then a function to solve for binomial coefficients, and finally I a function which will give Pascal's Triangle.  Solving the problem in this way gives us not only a readable solution which allows someone reading the code to follow the solution but now we have a function for factorials and one for binomial coefficients!

Do not misread this blog post I am not saying that the solution given in C# above is wrong or bad, but only that by spending time to research a problem can often given a much more rich solution to the problem.

As IBM would say, "Think".

taken from http://www-03.ibm.com/ibm/history/ibm100/images/icp/P496146V03975A59/us__en_us__ibm100__cult_think__think_sign__620x350.jpg

Sunday, March 29, 2015

How to Attend a Programming Conference

"Cannot induce you to attend my words"
-- Shakespeare, Othello
Act III, Scene III, Line 278

Tis that time of the year.  A time when a developer's thoughts turn to conferences.

The following is about how I attend conferences.  The most important thing to know first is that I attend conferences to learn.  If your goal in attending a conference is to party it up in a fun location then this post is not for you.

First, know what type of conference it is that you are attending.

  • Is it single track or multi track?
  • Is it local, regional, or global?
  • Is run for profit or is it sponsored?
  • Is it a single day or multi day?
  • ...

For the most part when you are attending a conference the only real difference is if it is multi track or single track.  The other questions are all around what type of travel plans you will need to make, how much will it cost, and what type of other activities it will have outside of the sessions.  As such I will just focus on the differences around the number of tracks for the rest of the post.

Single track conferences often have a theme which maybe language, technology, or topic based.  This is great if you want to get really in-depth.  You'll find lots of people who are interested in the same theme.  That being said when you go to this type of conference it will most likely be on you to make the most of it by getting out there and talking to other people.  I have two tips for meeting people at a conference like this:

  • Stand/sit at an empty table during breaks.
    Often people will come over and join you (even if just to find a place to rest their snack), this is a great chance to strike up a conversation.  Remember you have at least one thing in common, you have both just seen the exact same session.
  • Join a table during breaks.
    Some times you will strike out doing this and join a table of friends that will not talk to you much, no big deal just head over to a different table.  Remember you have the conference in common, so it should be easy to find things to talk about.
Multi track conferences are a great way to branch out and learn something completely new.  With a multi track conference you can often find sessions in areas that you only have a little bit of knowledge of.  That being said it is up to you to pick the sessions and make the conference your own. I have a few tips for a conference like this:
  • Everyday go to one session in which you have no knowledge of the topic.
    Multi track conferences are a great way to get a glimpse of another world.  If you are a backend developer, go to an UI design session; if you are a front-end developer go to a session on databases.  You have a great opportunity to learn what other people are dealing with and care about.
  • See "famous" speakers.
    Not all speakers have the same speaking style or are at the same level.  Go see a "famous" speaker even if they are talking about a topic you do not care about.  If the speaker is "famous" because they are good, you'll learn something and who knows you might be able to use that new knowledge latter on.
  • See a first-timer / newer speaker.
    Everyone has their first time that they are doing something.  Uncle Bob was not born an accomplish public speaker.  Go see someone that is new to the scene, they might not be as polished as a "famous" speaker but they might have more in-depth knowledge about their topic.
  • Make sure to ask questions at the sessions.
    There is almost always time at the end of the session to ask questions, do so.  Asking questions is a great way to make sure that you understand what you just saw, it is also a good way to get advise from an expert.
A bit of warning around sponsorship and conferences.  Beware at conferences of speakers that work for sponsors of the conference.  Some of these speakers get their spots based on their own merits and may even get their company to sponsor the conference because they believe in it and want to help even more, but there are times that speakers get their spots because they work for a sponsor, this is not to say that they are a bad speaker or that the session will be a sales pitch, just beware and know that you might be getting a sales pitch in your session.

I hope you find these tips useful and if you see me at a conference stop by and say hi.

Sunday, November 10, 2013

Code is Part of the Programmer and the Programmer is Part of their Code

"My songs cease, I abandon them,
From behind the screen where I hid I advance personally solely
    to you.

Camerado, this is no book,
Who touches this touches a man,
(Is it night? are we here together alone?)
It is I you hold and who holds you,
I spring from the pages into your arms—decease calls me forth.
"
-- Walt Whitman, Leaves of Grass (1891-1892, Deathbed edition)
So Long!, page 382

Being a programmer, a creator of worlds, is both humbling and invigorating at the sametime.  Everytime that I work my craft, I truly have endless potential, I could create something which changes lives or I could write a shitty monkey patch to just get something "done".  Even if it does not seem like it, the choice is always up to me.

Today, more so than any other time in human history, we software developers have created a small part of the world that exist.  Our creations have influenced and altered human civilization.  Don't believe me, post something to your Facebook that you know will get a response from family or friends.

When my first nephew William was born, my wife and I were let to see him only an hours or so after he was born.  I did what anyone else would do of my age group, I took pictures of him and us which I shared on Facebook.  Almost instantly I got a ton of likes and comments attached to these pictures, it then dawned on me that these were most likely the first images of Will that a lot of people would see.


And if you gaze for long into an abyss, the abyss gazes also into you.

-- Friedrich Nietzsche
Beyond Good and Evil, Aphorism 146
(generated from The Nietzsche Family Circus)

We creators of programs become part of our programs, which become part of us.  These programs become part of the user and the user becomes part of the program.  Thus, we programmers much like a poet, become one with our users and they become one with us.  This is really a humbling thing to think of.

Most of us do not work for Facebook or on code which is released to the general public, but our code is hopefully used.  When our code is used by someone or something it becomes a small part of that someone or something.  The point being, we become one with the world we consume and it becomes one with us.  When you stare into the abyss it stares back into you.

So what does this mean?  Which would you rather be associated with?


I have used my share of crappy software and third party vendor add-ons, when I use these "products" I cannot help but feel that the people who created them simply do not care.  I know this is faulty logic, in fact it is the fundamental attribution error, but still, WTF!  I am not alone in this feeling, in fact Uncle Bob recently blogged about his experience with Healthcare.gov and upgrading his Mac (neither of which were good experiences).

Becoming one with the world is not limited to programmer's end products!  This oneness with the world extends to their code they commit to source control!

At SCNA this Saturday, (November 9, 2013), Katrina Owen in her Here be Dragons talk linked the Prisoner's Dilemma to the development of software.  You see everytime you check in code you can either check in something that will be a pleasure for someone in the future (which might be you) or something that will cause a ton of swearing.

The choice is up to you, but the choice is even deeper than simply what you d.  Believe it or not what you check in influences other people.

Humans generally want to be cooperative and helpful to each other, but when crossed, O-boy the claws come out!  This applies to your code in the following way.  

Say that you are generally careful with your code and do all kinds of well thought of things (today that would be BDD, unit testing, "clean code", ...).  Others will see this and will most likely than not follow suit and raise the bar even higher.  The code base will generally become better overtime and general happiness will ensue.  The team will get along and will become happy with their code and the code will become better ...

What happens if someone has a bad day and checks in some crappy code?  One of two things could happen: either people retaliate with crappy code which could cause a downward spiral or they could let it slide, fix it, and continue checking in careful, well thought out code.


This my friends is the Prisoner's Dilemma!

With just one commit we have a simple Prisoner's Dilemma, but most programmers will work with each other for an undetermined number of commits across many days, months, years, and sometimes even decades!  This moves us from a simple single round of the Prisoner's Dilemma to that of an Iterated Prisoner's Dilemma.  In this type of game, the best strategy is what is known as tit-for-tat.

A tit-for-tat strategy:

1) start by being cooperative
2) do what the other player did

Tit-for-tat starts by being cooperative, thus starting things off on the right foot.  After the first cooperate, the tit-for-tat player will do whatever the other player did previously, thus if the player was cooperative the tit-for-tat player will be cooperative, if the other players defects, then the tit-for-tat player will defect. Defecting when the other player defects can lead to hell  A slightly more efficient tit-for-tat strategy will cooperate at random when in a defect spiral, this will allow for one to get out of a defect spiral, if one can.

With code (and everything else) things are not as simple as cooperate and defect, this is for many reasons, the most important one being not everyone agrees on what "Clean" and "Crap" code is, but we are humans and have a sense of being treated fairly and not fairly.  Thus, one can know if they are in a defect spiral or not.  If you find yourself in a defect spiral you can either see if things will change by issuing a corporate or simply leave.


Whoever fights monsters should see to it that in the process he does not become a monster.

-- Friedrich Nietzsche
(generated from The Nietzsche Family Circus)

If you are in a defect spiral, leave before you to become a monster and always start by committing well thought out clean code.  Thus, be what you want the world to be, for your code is more than just code, it is part of you and you are part of it.

Monday, October 28, 2013

Hope Cocktails OR Why We Love Guides

"Rome, thou hast lost the breed of noble bloods!"
-- Shakespeare, Julius Caesar

Friends, coders, methodologist, lend me your ears;
I come to bury experience and knowledge, not praise it.
The work that men do lives after them,

The glories are interred with their retirement parties;
So let it be with experience and knowledge.  The noble methodologies
Hath told you that experience and knowledge are not needed.
If it were so, it was a grievous fault,
And experience and knowledge have been replaced.

Good sir, they say, have you mocked methodologies?!?  Have you gone mad?!?  We sir, like our hope cocktails and will not stand to hear your mocking!

Riddle me this methodologist, why should we follow these principles?!?  What are their genesis?!?

Sir, they say, these were handed down to us from above, we do not question them.

Friends this is a sad, sad, sad state indeed.  Drunken on hope cocktails, these methodologist come and say to us, "Follow me and I will lead you to the promise land, I have access to the secret doctrines and only I can interpret them correctly."

All these statements may be true, they may have access to the "secret doctrines", they may have the ability to "interpret" them correctly.  There is just one thing:

"Where is the master who could have taught Shakespeare?"
-- Ralph Waldo Emerson, Self-Reliance

Who could teach Shakespeare to Shakespeare?  Who taught Virgil to be Virgil?  Who told Homer the Iliad and the Odyssey?

The ancient Greeks having no history or doctrines were able to be truly beautiful.  They were able to soar to heights never reached before or since.  They did not blindly follow, they led and are still leading!

"Sing, O goddess, the anger of Achilles son of Peleus, that brought countless ills upon the Achaeans."
-- Homer, The Iliad
Book I, Line 1

Sing goddesses of men that were truly beautiful.  Men that gave us the Sciences.  Men that gave us the very idea of History.  Men that gave us hope.

"Only Hope remained there in an unbreakable home within under the rim of the great jar, and did not fly out at the door"
-- Hesiod, Works and Days, Line 96

Hope not in a cocktail, the thing itself, the authentic thing.

True experience and knowledge, the kind which builds worlds, cannot be drunken down, it can only be lived.  True experience and knowledge, my friends, becomes one with us.  It is created, not drunken in.  It is made true to oneself.  It cannot be disproven since it is part of one, it becomes one's duty.

"It is far better to discharge one’s prescribed duties, even though faultily, than another’s duties perfectly. Destruction in the course of performing one’s own duty is better than engaging in another’s duties, for to follow another’s path is dangerous."
-- Bhagavad Gita, 3:35

It would be better to be destroyed than to follow!  For blindly following is worst than not existing, it is not even being.  To follow another's life, to not be authentic, is to not even exist.  Live your life, your experience, your knowledge.

Fellow developers, do you know why you do a daily stand up?  Is testing first part of who you are as a developer?  Is continuous integration part of your definition of done, even if it is not required by your team?

Beware my friends for it is far easier to drink down hope cocktails than to gain true experience and knowledge.  It is often hard to tell at first who is buzzed on hope cocktails and who actually has true experience and knowledge.  You can tell a drunkard when they pererrat to another cocktail and quote new sages, this herd will be moving to new pastures, grazing on new hope cocktails, worshipping new idols.

"Man is timid and apologetic; he is no longer upright; he dares not say 'I think,' 'I am,' but quotes some saint or sage."
-- Ralph Waldo Emerson, Self-Reliance

Sunday, October 20, 2013

How to Become Like Uncle Bob

"Here's the challenge, read it. I warrant
there's vinegar and pepper in't."
-- Shakespeare, Twelfth Night
Act III, Scene IV, Lines 142-143

How does one become what one is?  Better yet, how does one become what one should be?  Even better, how does one become what one must be?!?

A challenge was fired straight across the bow! Just a little less than one year ago, Uncle Bob in his
"The Reasonable Expectations of Your CTO" stated that software professionals need to be spend 20 hours a week honing their craft! Sir you say, 20 hours is a lot, this man is surely joking!

Nope, Uncle Bob was serious, in fact he gave away one of his secrets.  This secret was how to become an Uncle Bob.  Yes sir, Uncle Bob has given away a secret of how to become like him in abilities and knowledge.

No surprise Uncle Bob has stated that it takes in a different way that it takes 10,000 hours to become an expert.  Wait you say, 10,000 hours where did that come from?

Let's see, take the 20 hours per week that Uncle Bob is challenging us with and multiple it over a whole year which we'll say it is 50 weeks, that give us 2 weeks of vacation!  20 * 50 = 1,000.  Hmmm, 1,000 well if we did this for 10 years that would give us 10,000 hours of practice.  Surprise, surprise, just as Dr. K. Anders Ericsson has found in his research on experts!

In fact as any weekend golfer that has not improved in 20 years of play will tell you, 10,000 hours of practice by itself is not enough!  No, sorry sir, it take deliberate practice to get better, practice in which one climbs mountains!

What?!?  Surely I am mad, surely I have fallen from the great height of my rocker!  Surely I am an anarchist that laughs as the world burns!--and thus with some silly jesting in my writing I have left a quote that could easily be taken out of context and used against me!

Sorry my friends, but traveling to great heights takes great amount of effort and determination, but boy is the view great!

A poem of old reads:

"The aspen plum blossoms!
Bent towards me it waves!
It's not that I do not think of you.
But that your home is too far away."

Confucius said, "The writer of this poem does not really miss his beloved.  If he did, how could he feel that his beloved is too far away?"
-- Confucius, Analects of Confucius, Book 9
(other translation 1, 2)

As Confucius has shown us what we do truly speaks as to what we really mean and feel.  If we really want to be better, we really want to be professionals, we really want to better than average, we really want to soar to greater and greater heights, if we really want to become an Uncle Bob, we'll have to get good, we'll have to get really good!  It will take much more than wishing, it will take blood, sweat, and tears.

Laugh at his challenge.
-- Shakespeare, Antony and Cleopatra
Act IV, Scene I, Line 6

Laugh for how could one every stand up against such overwhelming work without laughter?!?  Furthermore, what truth could ever be spoken without laughter?!?

This challenge is great, it takes a lot to transcend the bonds of the normal everyday.

But sir, you say, this challenge is too great, too terrible!!!

A young man can be most surely corrupted when he is taught to value the like-minded more highly than the differently minded.
-- Friedrich Nietzsche, The Dawn of Day, Section 297

We are not talking about the average.

What is being talked about is moving beyond the herd, to the heights of what can be.

O-but good sir you have surely forgotten about the plague!  The plague you say?  You are right I have forgotten about the "Sam's Teach Yourself C++ in 21 Days" and its bothers.  I have forgotten about Wizard Schools, boot camps, and sheep dip training!

Yes, my fellow adventures of knowledge we have a plague on our hands, the Get Knowledge Quick Plague!

You see learning can be done in the 21 Day route or the Oxford Complete route.  The authentic subject in itself or the Cliff's Notes?!?  The choice is yours, one path leads to new heights, the other to the same-old-same-old.

When a war breaks out, people say: "It is too stupid; it can't last long." But though a war may well be "too stupid," that doesn't prevent its lasting. Stupidity has a knack of getting its way; as we should see if we were not always so wrapped up in ourselves.
-- Albert Camus, The Plague, Part 1, Chapter 5

No one asks for the plague, one is just thrown into it.  Lucky one finds that one has choices even in the darkest mist of the plague.  One can fight the monsters or one can be the victim of monsters!

"Look here, Monsieur Cottard, why don’t you join us?"

Picking up his derby hat, Cottard rose from his chair with an offended expression.

"It’s not my job," he said. Then, with an air of bravado, he added: "What’s more, the plague suits me quite well and I see no reason why I should bother about trying to stop it."

-- Albert Camus, The Plague, Part 2, Chapter 9

Cottard, Cottard, it is so easy to see the plague and think hmmm, I will dip the sheep!  I will profit from this plague!

My friends this is the enemy.

Through me the way is to the city dolent;
  Through me the way is to eternal dole;
  Through me the way among the people lost.

Justice incited my sublime Creator;
  Created me divine Omnipotence,
  The highest Wisdom and the primal Love.

Before me there were no created things,
  Only eterne, and I eternal last.
  All hope abandon, ye who enter in!
-- Dante Alighieri, Inferno, Canto III

There is no profit to be made in plague!  No greatness to be found in the plague.  The plague is the same, everyday in the plague is the same, the same joylessness, the same hopelessness, the same misery!  Only fighting against the plague can bring about greatness.  Greatness is not found in profiting from the plague!

"You're right, Rambert, quite right, and for nothing in the world would I try to dissuade you from what you're going to do; it seems to be absolutely right and proper. However, there’s one thing I must tell you: there’s no question of heroism in all this. It’s a matter of common decency. That’s an idea which may make some people smile, but the only means of fighting a plague is—common decency."
-- Albert Camus, The Plague, Part 2, Chapter 9

Like Sisyphus, we found that we are pushing our rock up a hill to only have it rollback.  For every Clean Coder there are three Teach Yourself x in 21 Days!  For every Elvis there are three Morts!

Sir, you say, you have gone mad.  You have wanted to set the world on fire!

Do you remember when you were young and you wanted to set the world on fire?
-- Against Me!, I Was a Teenage Anarchist

Perhaps I am being a drama queen, perhaps I have gone too far, perhaps I have lost sight of what the point was!  One must remember, while mountain climbing that one must get use to the air at higher heights, one cannot be simply dropped onto the summit and expected to survive!  No, one must work their own way up the mountain.  One must face their own challenges, one must meet their own monsters!

He who fights with monsters should be careful lest he thereby become a monster. And if thou gaze long into an abyss, the abyss will also gaze into thee.
-- Friedrich Nietzsche, Beyond Good and Evil, Chapter 4, Aphorism 146

20 hours a week or if it is easier to think of 10,000 hours of progressive deliberate practice and higher and higher challenges is what is needed to become an expert.

Sunday, October 13, 2013

A Kata A Day

"But such a day tomorrow as today."
-- Shakespeare, The Winter's Tale
Act I, Scene II, Line 64

"For ever and a day."
-- Shakespeare, As You Like It

A Kata A Day  

Epictetus, the Stoic philosopher, was record to have said,

"Practice yourself, for heaven’s sake, in little things; and thence proceed to greater."

Ever since Cory Foy's presentation at SCNA 2012 I have been doing a software kata at the start of every work day.  Yes, every single day with very few exceptions, even during the two weeks when I was putting in hellish overtime for a big release!  I find this practice is a great way to start the day.

Chong Kim recently blogged about using katas to improve one's coding.  I completely agree, in fact I have found that katas are a great way to learn new languages, styles, frameworks, ...

"Katas can stretch our abilities and, similar to how a kata would teach a martial artist to become comfortable with the uncomfortable, they help us write code we may not normally write."

So far in my year experience of daily katas I have used katas to learn: F#, Haskell, Clojure, JavaScript, node.js, SpecFlow, Mocha, continuation passing style, ...  So what sir, that is just a list of random programming languages and testing frameworks, have you actually gained anything?!?  Hmmm, that is a very hard question to answer, in order to truly answer it I would need to have done an experiment in which we have two programmers with equal ability and have one start their day with a kata while the other one gets an extra 25 minutes of sleep.  I did not set up such an experiment when I start around a year ago.  To make you for this lack of planning how about if we do a thought experiment?  Thought experiments were good enough for Einstein after all.

Say we have two programmers of equal abilities.  Elvis would like to take his programming to the next level and as such will start each work day with a code kata.  Mel on the other hand would just like to get to Friday and as such will sleep an extra 25 minutes each day instead of doing a code kata.  In a work month there are about 21 days, so in one month Elvis would have done 21 different code katas.  After about 3 months that would be about 65 katas which is enough practice time to learn a new skill or two.  In one year Elvis would have gained about 8 new skills while Mel would have slept around an extra 108 hours.  With 8 new or reinforced skills Elvis would find that he is well on his way to rock star status.

"Practice does not make perfect. Only perfect practice makes perfect."
-- Vince Lombardi

Here is the rub, those katas need to be deliberate practice, meaning they need to have goals, they need to push your skills, they need to expand what you think you can do, they need to make you better.  Merely sitting down and coding for 25 minutes is not enough.  You need to be mindful as you practice.  You need to have goals of what you want to do and you need to stick to them!  Use your katas as experiments.  Go to Rosetta Code and try something you have never done before.  Look up different programming language paradigm on Wikipedia and try them.

The principal of linguistic relativity comes in two forms: "(i) the strong version that language determines thought and that linguistic categories limit and determine cognitive categories and (ii) the weak version that linguistic categories and usage influence thought and certain kinds of non-linguistic behavior".  Regardless of which version you follow, the conclusion of our needs is the same, you are what you consume/do.  If you have used Higher Order Functions before in a kata then when you see a problem which is perfect for applying them you'll use them.

There is debate around if Eskimos have more words for snow than other cultures, but Kenneth Iverson inventor of APL and ACM Turning award winner and Paul Graham (all around genius) both believe that language influences how you think about a problem.  Graham calls this the Blub Paradox.

"programming languages are not merely technologies, but habits of mind as well"
-- Paul Graham, Beating the Averages

The programming language that you use to try to solve a problem not only dictates how you go about solving a problem but how you actually think about the problem!  Don't believe me, write the Prime Factorization kata in an Object Oriented language and Functional language.  What is the first hurtle that you hit in an Object Oriented language when solving a behavioral based problem?  Is it what type of objects do I need?  Does that really make any sense to think of when you finding the prime factors of a number?!?