Wednesday, November 25, 2015

Functional Specialized Functions and Immutability

The previous blog ended with the question: if the specialized functions used in functional programming are using mutability under the hood, did we really avoid mutability or did we merely push it under the rug. We will discuss that in this blog.

Given a collection of numbers, here's a small piece of code to iterate and print the values.


The code is functional in style—no explicit mutability, tells what to do, and relies on the underlying function forEach to take care of the iteration.

But, here's a quick look at the implementation of the forEach function in the JDK:

default void forEach(Consumer<? super T> action) {
    for (T t : this) {

That's imperative style in full glory. A number of higher-order functions in the JDK use imperative style and also involve mutability.

Then, we may ask, what's the point of enforcing immutability and purity in our code when the underlying library functions may not be pure.

We'll get to that question in a few minutes, but first let's discuss something else from a different paradigm as that will help us draw some parallels.

Edsger Dijkstra wrote Go-to statement considered harmful. In structured programming we avoid goto statements and instead use block structures with well defined entry and exit points.

Languages that are predominantly touted as object-oriented also use block structures, so they're inclusive of structured programming concepts. Let's explore the following Java code:

public class Sample {
 public static void main(String[] args) {
   for(int i = 0; i < 10; i++) {
     if(i > 5) System.out.println(i);

A for loop that iterates and displays values greater than 5 in the given range. That's structured blocks, as we see through our naked eyes. Let's compile this code using javac and then take a look at the bytecode using the command

javap -c Sample.class:

Compiled from ""
public class Sample {
  public Sample();
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
       0: iconst_0
       1: istore_1
       2: iload_1
       3: bipush        10
       5: if_icmpge     26
       8: iload_1
       9: iconst_5
      10: if_icmple     20
      13: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
      16: iload_1
      17: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V
      20: iinc          1, 1
      23: goto          2
      26: return

Perched amid the bytecode is that little four-lettered command goto. Is the source code we wrote still structured if the generated code contains goto?

goto is like matches. You have matches at home, but, I hope, you don't give it to children and say "Kids, play with these matches while I go take a shower." We have matches at home, but only adults get to use it. Use of goto is something like that.

If our source code contains goto statements, then it can easily turn into a messy spaghetti code—as Dijkstra cautioned. As application programmers, the source code is our direct responsibility. The bytecode, well that's the responsibility of folks creating the compiler that generates the bytecode.

We can draw parallels between goto and mutability. If we use mutability in our code then primitive obsession, garbage variables, reasoning, bugs that crop up, difficulty to parallelize,... all become our problems. Instead, if we avoid mutability, and even if there's mutability under the hood in the functional libraries we use, then those are not our problems—they become their problems. In coding, as in life, we always want to avoid making problems for ourselves, as much as possible.

goto is to structured programming as mutability is to functional programming

Our goal is not a world without goto or mutability, it's a world where we don't have to directly deal with them.

Don't worry that the underlying library is mutating stuff. Focus on your code and take comfort in that they guarantee thread-safety and are reliable to use. Keep your code pure and functional. Talking about purity, we'll discuss that further in the next blog.

Wednesday, November 18, 2015

The Power and Practicality of Immutability

In the previous blog we discussed the difference between statements and expressions. Any non-trivial statement will involve mutability or side-effects. Functional Programming favors expressions and immutability. In this blog we'll discuss the practicality of programming with immutability. In a series of blogs that follow this one we'll discuss why immutability is so critical—the benefits, as we'll learn, are far reaching.

Mutability is a way of life in imperative programming. Mutability in itself may not appear really that bad. What gets us into trouble is shared mutability—that's devils work.

Shared mutability is where a piece of code mutates variables or objects outside its immediate local scope. We're so used to shared mutability that it may appear impossible to implement some logic without mutating variables. But, it's really not hard.

Let's take a look at an example.

Let's start with a Person class with a few properties including age.

public class Person {
  private final String name;
  private final int age;
  public Person(String theName, int theAge) {
    name = theName;
    age = theAge;
  public String getName() { return name; }
  public int getAge() { return age; }

First, here's the code to create a list of friends:

import java.util.*;

public class Sample {
  public static void main(String[] args) {
    List<Person> friends = Arrays.asList(
      new Person("Sara", 20),
      new Person("Jill", 25),
      new Person("Siva", 30),
      new Person("Raj", 40));

    //...more code goes here...

Now, let's compute the total age of all people among the friends collection.

    int totalAge = 0;
    for(Person friend : friends) {
      totalAge += friend.getAge();
    System.out.println("Total age of friends: " + totalAge);

We first initialized a variable named totalAge with a value of 0. Then, using the imperative style loop, that is an external iterator, we get one person at a time, get their age, and add it to the totalAge variable. The += is where mutation is happening.

Why is mutability not a good thing? Here are a few reasons:

  • The code suffers from primitive obsession, we had to convey every detail: get the value from the person, add to the total, set it back into the variable. Changing the variable from one value to another is our responsibility here, that's a low level detail.
  • The variable totalAge is often referred to as a garbage variable. It's there to hold the temporary transitional state through the loop. It adds to the noise in the code.
  • The more mutability we have in code, the harder it is to reason the code. In such a simple example as the one above we may not see the burden, but imaging having more variables. We may have to make sure the states change correctly and in the right order.
  • Often has more bugs. The more mutability in a piece of code, the higher the chances of bugs. Mutability introduces moving parts, and since they are hard to reason, it's easier to make mistakes with state transitions.
  • Hard to parallelize the code. Suppose the computation for each element were expensive and we want to speed up the computation by introducing multiple threads. Creating threads is not that hard, but we'll quickly run into thread safety issues due to the mutable variable. Shared mutability means lack of thread-safety. In order to make this code thread-safe we have to put locks or synchronization primitives around the change to the mutable variable. This introduces accidental complexity in code, makes it harder to understand, and leads to more bugs as well—it's the start of a vicious cycle.

We should avoid shared mutability as much as possible. Thankfully, that's not hard in most languages today. Let's refactor the code to a declarative and a functional style without any explicit mutability.

    System.out.println("Total age of friends: " +

The code is a lot more expressive, concise, has fewer moving parts, and favors immutability---there is no explicit mutability.

So, how did we eliminate mutability? By using some specialized functions. The mutability, if any, is hidden inside the sum function.

How is this better than the previous imperative style code with mutability?

  • The code tells what and not how. We ask for all the age values to be summed. We did not have to tell how to get each element, what to add, where to put the result, etc. In particular we did not spend any effort telling the code how to update any variable's values.
  • There is no garbage variable. Less noise.
  • Easier to reason/explain what the code is doing. Give a collection of friends, get their age, and sum (total).
  • Less code, fewer moving parts, fewer bugs. Easier to trace what's going on.
  • Easier to parallelize. Since the code is not performing any explicit mutation, there's nothing to protect for thread-safety. So, it's easier to parallelize. Go ahead and try. Change .stream() to .parallelStream() and the computations will run in multiple threads. In the Person's getAge() method add try { Thread.sleep(1000);} catch(Exception ex) {} and run the code using the stream() function first. Notice the time taken to run. Then change it to use the parallel version and observe the time the code takes. Instead of taking around 4 seconds, the code now takes about 1 second. We got faster response with parallel, but without having to make significant change to do, especially to the structure of the code. Immutability for the win.

In short, we can avoid mutability by using specialized functions.

But, if the specialized functions are internally using mutability, did we really avoid mutability? We'll answer that question in the next blog post.

Friday, November 13, 2015

You hurt my heart more than my pocket: Stiffed by CodePaLOUsa

I stepped in to help out the CodePaLOUsa conference (@codepalousa) at the last minute. Didn't ask for any fees to speak, genuinely wanted to help, and they promised to reimburse for the travel expenses. Sadly I got stiffed by them and my repeated requests for payment have been ignored. With this treatment, they've hurt my heart more than my pocket.

I speak in a lot of conferences each year. I want to say that almost all the conferences I speak at have treated me extremely well, they make me feel quite welcome and welcome back—unfortunately that has not been my experience with one conference: CodePaLOUsa (@codepalousa).

On April 22, 2015, when I was in India teaching a course, I got an email from Wes Reisz (who is not a member of the organizing committee or involved in any capacity—he was a speaker who knows the organizer and was trying to help), with an urgent request for a conference the following week:

 From: Wesley Reisz
 Subject: Hope your Well
 Date: April 22, 2015 at 11:31:24 PM GMT+5:30
 To: Venkat Subramaniam

 Hope you are well. I have a horrible request.

 Andy was going to keynote in Louisville on Wednesday at CodePaLOUsa
 (650 in size 2 day developer focused conference), but he had a family
 emergency and had to cancel. That leaves the organizer (a friend of
 mine) without one of his major headliners. I've been trying to figure
 out if I could find someone on short notice. Is there any chance you
 might be available next week? ...failing that, do you know anyone who
 might be able to?

 Sorry for being absent for so long and then this request. I do hope
 you are well.

I have known Wes for well over a decade, I have had a number of discussions with him about software development, teaching, etc. So, when I got this email my immediate response was, of course. I only had a couple of days at home in that month, but if an old pal needs help, I am not going to say no. So, I responded as soon as I saw that email:

 From: Venkat Subramaniam
 Subject: Re: Hope your Well
 Date: April 23, 2015 at 2:26:44 AM GMT+5:30
 To: Wesley Reisz

 Hi Wes,

 Hope things are going well.

 Will be glad to. I do have to return home to Denver on Wednesday night.

 Please pick any keynote from . The Art of Simplicity may be a good one to select, if I may suggest.

 I am currently in India, returning to Denver on Sunday night, with limited internet access between now and then. Sorry if I am slow in responding.
 Please let me know if you need any additional details.



Wes is asking for urgent help for a friend. This is not a time to negotiate pricing and pay. I took the high road, with the expectation that travel expenses from my home near Denver, CO to Louisville, KY will be paid. Chad Green (@chadgreen), the organizer of the conference responded confirming that I will be speaking and he'd take care of the travel expenses.

 From: Chad Green
 Subject: RE: Hope your Well
 Date: April 23, 2015 at 6:46:14 AM GMT+5:30
 To: ""
 Cc: Wesley Reisz

 Thank you so much for your wiliness to come to Louisville on such short notice.  We are looking at scheduling you at 8:00 am on Wednesday morning (April 29), so there is no problem getting you home Wednesday evening.

 I watch the first couple of minutes of you’re the Art of Simplicity talk from COHAA and liked what I saw and that is what I would like to see at Code PaLOUsa.

 Obviously we will take care of your travel costs.  I can either book the flight for you or I can reimburse you the cost.  Your hotel room will be our master account, so there will be nothing for you to take care of there.  Just let me know how you want to book your flight and dates (so at the least I can have your hotel room ready).  If you want to book the flight yourself, we have arranged for discounts:

 - Delta Airlines: Reservations and ticketing are available via When booking online, select Book A Trip, click on Advanced Search and enter the meeting code NMK9J in the box provided on the Search Flights page. Reservations may also be made by calling the Delta Meeting reservations at 800-328-1111 Monday through Friday from 7:00 am to 7:00 pm CDT. Please note that there is a direct ticket fee for booking through the reservation number.

 - American Airlines: Tickets may be purchased by calling American Airlines Meeting Services at 800-433-1790. You will need to reference the Code PaLOUsa 2015 authorization number which is A3945BR.

 - United Airlines: You may book online at and enter ZTH9585816 in the Offer Code box when searching for your flights. If booking through a travel professional or United Meetings at 800-426-1122, please give them Agreement Code 585816 and Z Code: ZTH9.

 Please let me know if there is anything else you need for me.

 Thank You,
 Chad Green
 Conference Chair
 Code PaLOUsa

Flight charges are often high if travel is booked within days of travel. I did go ahead and book the flight and the cost was $843.31. So, at this point in time I was signed up to deliver a keynote on the following Wednesday. Then I got this email from Chad Green (@chadgreen):

 From: Chad Green 
 Subject: Code PaLOUsa 2015 Speaking Slots Available
 Date: April 26, 2015 at 11:32:03 AM GMT+5:30

 We have had some speakers that have had to drop out of Code PaLOUsa, so we have some empty slots.  Please let me know if you would like to pick up another speaking slot and we’ll get you put in everywhere.  These will be first come, first served.  Here are the open slots: 

 Tuesday, April 28 at 9:45 am
 Tuesday, April 28 at 11:00 am
 Wednesday, April 29 at 9:45 am
 Wednesday, April 29 at 3:30 pm

 Thank You,
 Chad Green
 Conference Chair
 Code PaLOUsa

Again, I responded right away with an offer to given a technical talk, in addition to the keynote, again at no charge for speaking (other than the expectation to be reimbursed for travel). Chad Green (@chadgreen) responded with:

 You are the best, I am adding this to the schedule now.  Thank you so much.

 Thank You,
 Chad Green
 Conference Chair
 Code PaLOUsa

 From: Venkat Subramaniam [] 
 Sent: Sunday, April 26, 2015 5:16 AM
 To: Chad Green
 Subject: Re: Code PaLOUsa 2015 Speaking Slots Available

 Here’s the abstract, if you decide to go with this topic:

 Functional programming is receiving much attention recently. Most mainstream languages, including C++, Java, and C# now support lambda expressions and functional style. Why is there a sudden interest in adapting something that was largely ignored for decades? What are the technical reasons, how do we benefit, in what ways can using these techniques make our applications better and our development efforts easier as well? In this technical presentation we will learn about the technical underpinnings of functional programming, the fundamental problems they address, and the large impact of those on application development.


 On Apr 26, 2015, at 8:54 AM, Venkat Subramaniam  wrote:

 I can take Wednesday 9:45 AM. 

 How about Functional Programming- Technical Reasons to Adapt. 


I spoke at the conference on Wednesday April 29th, delivered a keynote and a technical talk. I did a decent job, as we can see from these tweets.

On April 30th I sent an invoice for the travel expenses: flight, taxis, parking at local airport, total of $890.30.

 From: Venkat Subramaniam 
 Subject: Invoice for travel
 Date: April 30, 2015 at 5:29:02 PM GMT+5:30
 To: Chad Green

 Hi Chad,

 It was a pleasure interacting with the developers at the conference.
 Please find attached an invoice for the travel expenses. If you like for me to 
 make any changes, please let me know.

 Congratulations on running a very successful event, I heard many good things about it.



There was no response to my email, not a thank you for stepping in at the last minute, not a payment, nothing. I emailed him on June 2nd:

 From: Venkat Subramaniam
 Subject: Re: Invoice for travel
 Date: June 2, 2015 at 7:25:52 AM GMT+5:30
 To: Chad Green

 Hi Chad,

 Could you please check on the payment for this invoice, I’ve not received it yet?



Then again, on July 29th:

 From: Venkat Subramaniam
 Subject: Re: Invoice for travel
 Date: July 29, 2015 at 5:52:44 PM GMT+5:30
 To: Chad Green

 Hi Chad,

 I’ve not received the payment for the invoice yet. I am not sure if my two previous emails reached you?
 Could you please follow up on this for me?

 Thank you


Then on July 31st I sent an email to Wes and copied Chad:

 From: Venkat Subramaniam
 Subject: Re: Invoice for travel
 Date: July 31, 2015 at 4:49:36 PM GMT+5:30
 To: Wesley Reisz 
 Cc: Chad Green

 Hi Wes,

 Sorry to bother you. I think my emails to Chad are not reaching. I’ve also left a phone message yesterday but 
 I’ve not received any response yet about getting the expenses reimbursed. Is there an alternate way to reach him?



Chad responded this time:

 On Jul 31, 2015, at 5:13 PM, Chad Green


 I apologize for not responding the other day, I'm on vacation and this morning is the first chance I've had and you were just 20 minutes too quick for me.  I know we sent out a payment but I'm guessing it got lost somewhere in the mail - and USPS wonders why the public is losing faith in them.  Is there an electronic method I can use to get you paid so there is some more assurance that it is received?  With that said, I do not have my Code PaLOUsa banking information with me so I will not be able to make a payment until I get back on August 9. 

I will give him the benefit of doubt that he did mail the check to me and it was somehow lost. So, I responded:

 On Jul 31, 2015, at 5:34 PM, Venkat Subramaniam  wrote:


 Here’s the banking details:

 Bank Name: …removed...
 Account Number: …removed...
 If you need additional details please let me know. August 9th is quite fine.



The last communication I received from him was:

 On Jul 31, 2015, at 5:35 PM, Chad Green  wrote:

 That should work.  I'll get this processed once I get back, sorry for the trouble. 

I waited until after August 9th to send a reminder:

 From: Venkat Subramaniam
 Subject: Re: Invoice for travel
 Date: August 16, 2015 at 8:39:18 PM GMT+5:30
 To: Chad Green 


 Could you please update me on the status of this payment?



No response. Then I emailed again on August 25th:

 From: Venkat Subramaniam
 Subject: Re: Invoice for travel
 Date: August 25, 2015 at 9:06:16 PM GMT+5:30
 To: Chad Green
 Cc: Wesley Reisz

 Chad, what’s blocking? No response either! I emailed you on the 16th, left a phone message for you on the 20th as well.

 Wes, FYI, I have a feeling I’m being punished for stepping up and helping out here. I am honesty disappointed. 
 Not what I expected. Quite unhappy with the way this has gone.


I did not hear back from Chad. Wes responded:

 From: Wesley Reisz 
 Subject: Re: Invoice for travel
 Date: August 26, 2015 at 3:52:26 AM GMT+5:30
 To: Venkat Subramaniam

 I'm sorry about this. I'm pinging Chad as well to see what's going on. If you don't mind, can you tell me the amount you asked to be reimbursement? I ask because I referred you to them, so I feel responsible. You absolutely bailed Codepalousa out of a spot. I will help make this right.

I am thankful to hear this from Wes, but I don't think it is right for me to expect payment from him. I would have done the same as he did, to help a conference organizer, especially if I considered them a friend (as he does). I apologized for bothering Wes at this point.

My last email to Chad was on October 9th:

 On Oct 9, 2015, at 6:33 PM, Venkat Subramaniam wrote:

 Hi Chad,

 Any updates on this invoice? I have not received payment, would appreciate a response to let me know when I can expect the payment.
 If you need additional time to pay, please let me know so I can note on my calendar to touch base after that date.



And, still no response.

I am quite unhappy the way I have been treated by CodePaLOUsa and Chad Green (@chadgreen). For stepping up at the last minute to speak at an event, for sacrificing the only few days I was home that month, to offering to give an extra talk, the least I would expect is a response. It breaks my heart that such people are around. Thankfully, I meet so many wonderful people each day and this is more of a bitter exception than a norm.

If you are a speaker, sponsor, or an attendees at CodePaLOUsa (@codepalousa), please be aware of how I was treated. I sincerely hope you are treated way better than the way I have been treated.

Update: On Friday November 13th, 2015, Chad Green (@chadgreen) emailed saying "part of the budget I have put together has you being paid first" (he's referring to the budget for CodePaLOUsa 2016. This tells me that his earlier claim that the check was mailed and the USPS lost it seems to be false. He's lost my trust and it's hard for me to believe anything he says. I will believe his words when I receive the payment. I will post an update on this blog a month before CodePaLOUSa 2016, if he pays my expenses, as he says he would.

Sunday, October 25, 2015

Discounts during JavaOne

Greetings. I'm excited to be at JavaOne. Looking forward to listen to a number of talks and give a few as well.

I have a few discount codes, thanks to those who asked for them.

My Books at The Pragmatic Bookshelf

Please use the discount code JavaOne2015 for a 30% discount during check out at for any of my books. The books include:

Agile Learner vidoes

Please use the coupon ALSC-JAVA-ONE-2015 at checkout to get a 50% discount on a 1-month subscription to Agile Learner Videos.

The discounts expire on October 31st.

Enjoy the conference and hope to see you there.

Friday, September 18, 2015

Thoughts through Tweets

This is a collection of some thoughts expressed by Venkat Subramaniam over tweets...

Using profanity doesn't make us expressive, it simply shows we're vulgar and lacking.

I think, history will say, Scala & Clojure are to FP as C++ is to OOP.

"safety" in type safety is as comforting as "security" in social security.

Design patterns are the cliches of software design.

I've found intuition and gut feeling to be the most useful tools for design so far.

I don't want my project stakeholders to be guests on my projects, I want them to have a "skin in the game," investing their time & effort.

Learning a lib, a lang is easy. To improve code & change development style is hard-requires discipline & great self awareness.

"My boss is not convinced" is euphemism for "I'm not convinced, but I'm in denial (& it feels good to blame it on the boss)."

Relying heavily on some of our key strengths sometimes tends to be our major weakness.

I prefer a healthy dose of skepticism over naive optimism or incessant pessimism.

As engineers, we're good at telling boss what won't work. We should learn to explain what'd work & how it'll help the business.

Jumping into Scrum without practices to promote sustainable dev is like jumping into marriage with no real commitments.

There's usually a point in time when a project can be turned to success, but that opportune moment is rarely at the end.

Each time someone hears the words "best practice" God kills a few neurons.

You know you work for an enterprise when you dial long distance to schedule guy in the next room to fix your projector.

If work is not "having fun" you're likely holding on to a stinking job than being in pursuit of a passionate profession.

When getting into TDD, be prepared not to learn, but to unlearn; the more experience writing code, the more unlearning there is.

Architecture for a product is like salt for a meal–essential, must be in right proportion, & can't be self-serving.

Shaving head, losing shirt, walking barefoot doesn't make us Gandhi; at best only a cheap imitation of a 1/2 naked fakir.

A professional who doesn't learn to fail, fails to learn.

Given a choice between code that's simply sensible vs. hypothetically extensible, I prefer the former any day.

Let's be driven by inspiration, and not desperation, to attain that success that we can relish.

The words static and synchronized are menace to TDD.

Be opinionated, but unbiased. "The man who never alters his opinion is like standing water, and breeds reptiles of the mind" William Blake.

Continuing to use miserable developer tool is like being complacent in an abusive relationship-why not get out for a better life?

They say "end does not justify the means." But, in agile development, do we expect means that justify the end?

"We learn more by looking for the answer to a question and not finding it than we do from learning the answer itself." Lloyd Alexander

The irony of our industry, we brave to automate the world, yet we fear automating our projects.

IMHO, a great talk/book has both high information density & velocity; how much quality info is given & its pace.

If your company wants you to follow only standard practices, they're asking you to follow the path to mediocracy.

Dear company, owning code your programmers can't understand is worst than losing the code.

Zinnser: "Easy writing makes hard reading; hard writing makes easy reading" Not just writing, it's apt for coding.

If your code is not testable, it simply means your design sucks.

Ignorance is a tumor, remove early.

The only little predictable aspect of our lives is its unpredictability.

"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle.

In Java, you work for the compiler; in Scala the compiler works for you.

Trying to release product fast by compromising quality is like trying to lose weight fast by smoking.

"Methods to gain wisdom: by reflection (noblest), by imitation (easiest), and by experience (bitterest)"—source unknown.

What's the difference between a mafia and the government? Mafia doesn't require you to do paper work for the money they take away from you.

Dear developer, pride not developing complex software; strive instead to develop a capable and useful software.

Two sets of people scare me: those who can't follow instructions and those who can only follow instructions.

A good programmer should never fear throwing away code.

A framework that's your darling today is the one you'll hate in two years (make that four if you're a fanboy).

Some people teach me how to live; others how not to. I learn from both. Thankfully, however, each day I get to meet more of the former.

My mentors did not change the word, but hey they changed my world. Be a mentor.

You can't be Agile if your code sucks

If you think a piece of code is unusable, design for reuse to remove all doubt.

Complain to the one who can fix, praise to the one who can benefit.

It's not a mistake that the design has to change, it's a mistake not to make it feasible and cost effective to evolve (within reason).

"Yes" is nice to hear, "No" not so much, but "Yes" followed by inaction is the most difficult to deal with.

Decades ago I wrote bad code without knowing, today there's no doubt anymore, what a difference :)

If programmers are like (aspiring) musicians, some create music, others merely noise.

Stuff we create deserves checkin, not when it's perfect, but so we can evolve it fearlessly.

Checkins also serve as a form of information radiator.

What surprises me the most is not the realization I was wrong, but the strength of the conviction I had before that.

It's funny that most of us think the world has to change, but rarely think twice about ways to change ourselves.

Learning's like peeling the onion, you have to go through layers, & it involves tears...of frustration and then of joy.

Sometimes the hardest part of solving a problem is realizing and accepting the simple solution that's been there in front of you all along!

Depth of knowledge + ability to communicate + with a touch of humor + engaging the audience == a great presentation

If there's one thing we can learn, it's that we can't achieve desired results, leave alone perfection, in one try; results evolve.

hope is contagious

Success comes not from agreement, but from alignment.

There are no good people and bad people, three are only good behaviors and bad behaviors through the eyes of a context.

A key design skill we need to develop is the ability to discern accidental complexity from inherent complexity.

Theory is to programmers as vegetables are to children, essential but you can't just feed them bland.

Why do companies waste time asking questions in interview? Ask candidates to do real work, that's what you're hiring for.

A great business touches many pockets, a great person touches many hearts.

Passion is necessary but not sufficient; passion in the absence of hard work is like a seed with no soil.

Knowledge is a wealth that grows as you give.

If all we care about is speed, be prepared to end up fast in the ditch. Agile's about both speed & direction or relevance.

When problem solving, half the solution, an essential skill, is to eliminate unnecessary details.

I love it when someone, instead of complaining, takes time to research & sends a solution to problem. Lots of respect for folks like this.

The only constant is that Heraclitus quote about the only constant.

I admire the human quest to create new powerful devices, so fellow humans have options like never before to play solitaire.

Every moment, every interaction is an opportunity to learn, some teach us what we could be, other what not to be.

Greater the ignorance, larger seems to be the conviction.

Languages we learn should fundamentally change the way we think, challenge, shake the roots we've come to believe & rely upon.

Seems to be nothing more fulfilling & motivating than writing a todo list on a piece of paper & striking items off as they're completed.

The effort is not in writing, it's really in rewriting.

Rather than searching for agile practices to follow, pick a problem worth fixing & look for ways to realize that.

I find it helpful to understand the economic reasons for actions and the economic impact of the change.

TDD is a skill, it involves a decent amount of unlearning, relearning, and reevaluation. Let's not expect to get good at it instantly.

Sure TDD requires discipline, its a way of thinking, and all that, but I feel programmers need a sense of awareness to benefit from it.

The rigor in development must be in proportion to the cost and consequences of failure.

Languages are like vehicles, they all help us get around, some better than others. Travel on a few, based on the needs.

Curiosity - it's the pathway from good to great.

Everyone's complaining about someone, so collectively we all suck. Now that we got that figured, can we do something useful?

It's perfectly safe, no one has ever died of an extra act of kindness.

How others acts is not in our control, but how we react is entirely; We have the right of way on the civil parkway.

Quietness is a state of mind that can be experienced even in a noisy environment.

Most humans seem to be much better at critiquing than creating. We can channel this wisely thru feedbacks for a greater good.

It's much more fun to laugh with people than to laugh at them.

Does anyone keep track of their MTBYS - Mean Time Between Yak Shaving .

Conflicts & war arises, not due to respect for one's belief, religion, group, gender, or sect, but from the lack of it for the others.

My marriage has matured to the level that my wife and I can now fluently communicate... using airport codes.

Number one rule of collective ownership, we should never get into merge hell... we should only give it... with frequent check ins.

Those feeling strong that an organization must change, seriously start & follow the answers to question "how can I change."

Kicking ourselves often out of our comfort zones is a safe way to broaden that zone.

No matter where we reside, lets avoid living in the state of denial.

A better measure of audience or colleagues is not the answers they give, but the questions they ask.

A great leader, rather than instructing, motivates people to realize their organization's goals.

The first step in effecting change is to give it a fighting chance, most people seems to be convinced system's too rooted to change.

Each of us is living a dream, we just have to check often that it's ours and still ours.

Can't pause the passage of time, but every moment's an opportunity to turn growing old into a fruitful act of growing up

Sure there're so many things we can't change, but let's improve things_ however small_that's glaring at us and we 'can' change.

Good habits don't come from simply talking about them, but honed by sincere, disciplined, continuous, and deliberate practice.

Each day seems to be a realization of this inequality: Know < things forgotten << ignorant

a functional language in the hands of a dysfunctional team is like my junk in the hands of the TSA-it's not solving the real problem.

It's really not about what we learn, but how we learn it. So much of what we know builds and feeds on each other.

Failure is the stepping stone of success, but look up frequently to ensure the stones lead us in the right path & not in circles.

Speaking and writing, like any activity, gets better once we begin to enjoy it.

Use of the word "they" in the same sentence as "build" or "test" is a sign the team needs to improve the ways.

So much code being developed "design by accident" rather than "design with intent."

Agile in the absence of disciple and commitment is like marriage in the absence of love and trust - not sustainable.

We all want to create simple design, but the act of creating such a design is not that simple.

The mindset I prefer is to have a mind that's not set in ways.

You know it's time to stop and get back to important stuff when you hear yourself say "aren't these yaks cute."

Experience is not the passage of time but a measure of how our efforts have critically altered the ways we think and act.

Each generation faces atrocities of madmen & their group of thugs, only to prove that kindness & courage of the common hardworking prevails.

For a programmer, a day without a yak to shave is like a day without sunshine.

Some are too eager to teach lessons, not realizing, the student for lessons is not someone else, but the deserving inner self.

When will the software industry realize that the only true measure of estimates is in units of yak shavings.

I admire the innate resilience of programmers, without it the first set of compiler errors would have put an end to the field.

It's been discovered the darkest place in the world is located in the state of denial.

An important skill for programmers to develop is their sense for code and design smells, especially in their own code.

Best practices are like pills, targeted prescription with expiration date. Not wise to swallow them, ignoring the label.

learn to practice, practice to learn.

Everyone has three ages: the calendar age, the how-I-feel age, and how-others-feel based on the maturity they display.

writing is throwing the ingredients together, rewriting is seeing it turn into a sauce.

There are no good people and bad people, only developed minds and developing minds.

The weak put up with bureaucratic nonsense, the brave fight it, the wise simply work around it, never taking eyes of the goals to realize.

Having observed multiple enterprises I've come to realize that "stage-gate" is where their process and productivity goes to die.

you are the stories you tell.

A sense of prolonged professional comfort is a sign of setting into complacence.

The more I interact with organizations, the more I realize how important competent people are to the core of their success.

It's not much of a charm, but emotional stability and willingness to make things work, are essential qualities for customer-interacting jobs.

The most difficult to learn aren't the ones that add to our knowledge, but those that demand changes to our habits and behaviors.

convention over configuration is awesome when we know and can remember the conventions.

Reboot seems to be a proven solution, not just for windows, but from treadmills to airplanes!

it's interesting to meet organizations where management wants devs. to create quality code, but devs feel their management won't let them.

We looked at this problem and said we can solve it using a pool of threads. Now we have a pool of problems.

I really hate being distracted from my distractions.

It's quite clear how poor my design abilities were 10 years ago. What's not clear is how it sucks today, what I'll tell 10 years from now.

Weak can turn strong with diligence while the strong may turn weak from complacency.

Our field has fundamentally transformed in the last two decades, from devs fighting DLL hell to fighting assembly and jar hell.

It's quite dangerous when the experts quit listening and insists on the world accepting their dogmas and prescriptions.

Those who can't spend time and effort on automated feedbacks have to expend a greater magnitude on the aftermath.

If they hear you say "change" they ask you "Why?" If they see you succeed, they ask you "How?"

Have scientist figured this phenomenon that slows time to a crawl when you get on the treadmill?

You know it's time to take a break when you're fixated to review and fix code printed on the back of someone's T-shirt.

Good communication skill is not just having a nice fluency of words but must be accompanied by fervorous good attitude.

Software development is not an act of spewing code but a balanced art and economics of evolving and refactoring just enough code.

I fear my children becoming programmers one day, and start to ask questions, and discover my dark past—coding with COM and CORBA.

It appears, most of the "we can't convince our management" comments come from those who've not taken the time/effort to convince themselves.

Code smell is a wonderful metaphor (coined by @KentBeck); the more we put up with bad smell, the sooner we impair our senses to recognize.

The first step in paying technical debt is to check if we're actively acquiring avoidable new debt each day.

Professionalism is an act where we openly compliment and critique our ideas in a civil manner and end the day with a cheerful handshake.

There's cure for ignorance, and even incompetency, but all is lost in the presence of complacency.

A good learning should not merely fill our brains with more knowledge, but influence a change in our behavior, so we can achieve more.

A perfect way to fail is to be bent on making things perfect instead of valuable.

The biggest challenge is not the availability of tools or techniques, but the strong resistance to explore, experiment, & adapt.

It's critical to know if a low cost service is a result of higher efficiency or lower quality.

Son: "Dad can I have it?" Me: "302" Son (to my wife): "Mom?" Wife: "404"

So many of us confuse listening with agreeing, but they both are quite orthogonal.

There are but two constants, the first, as Heraclitus said, is change, and the second is the inborn human resistance to it.

One of the biggest services a mentor can provide is help people quickly get out of their comfort zone.

I am, but a work in progress, being debugged and evolved every day of my life, with a few bugs in me fixed, and a few new ones added.

Automated test is an act of self discipline where we're willing to invest time now for a greater saving later. Reaping that benefit today.

I think it takes some courage to invest in ourself.

Worry not if the American dream is dying, instead wake up to realize your dreams.

Asking someone to comment poorly written code is like asking them to take a higher interest loan to play their current debt.

Create fast should not imply drop quality, but to focus on the most essential features and business value.

Why do people speed like crazy on the roads and stand still on escalators?

Passion is the alarm that wakes you up, so you can go realize your dreams.

Let's give variables the names they deserve.

Expect a good mentor to serve as a ladder than as an escalator or an elevator/lift.

Each of us have two personalities, one before we have our first caffeinated drink of the day, and a gentler one after.

Let's judge code, not people.

There's often a tradeoff between more vs. better of something.

Ruby: 'Hey dude, we're about the same age :snicker' ~ Java: "eh, you're as cool as you think?{grunt}" ~ Lisp: (damn juveniles)

The problem with those of us who strive for perfection may be we believe we're perfect in defining perfection.

It's not the syntax or the idioms that we should pickup first in programming, but a sense for code smells.

My estimations skills are only surpassed by my ability to produce bug free software.

Giving in to the fear of failure is the biggest of all failures.

10% of the time, we write ugly code for performance reasons, the other 90% of the time, we write ugly code to be consistent.

Software is never written, it's only evolved.

If we ever figure a way to time travel, I will go back and stop that dude who put space in the directory name "Program Files"

Exercising is hard, but it makes the rest of the day so much easy.

The most important investment we make each day is on ourself, for if we don't trust, how silly to expect others to.

The irony of software dev_a field where most practitioners claim things change real fast, and, yet vehemently resist that very change.

Martin Luther King effected change, not by yelling America sucks, but by telling the dreams he had for her better future.

Oh, the pattern name you're looking for is "coding in desperation."

So many of us are eager to find an answer, but without knowing the question.

Instead of hearing "we're agile!" I'd like to hear "we're successful and here's why."

A programmer's command of the computers is in proportion to how often, and how comfortable, they're on the command line.

An expert is shaped, not by all the answers they've learned, but by the questions they've not been embarrassed to ask.

My days would be so much better if I don't have to constantly deal with… myself.

In programming, the variable flag is pronounced "smell."

The problem with most of us is not the one of misconception, but the one of conviction, that what have it all figured out.

Jealousy's a feeling we don't wanna work hard to attain what others have. Inspiration motivates us to attain & exceed. Cultivate the latter.

change is easy when we change often.

I like meeting someone negative and snobbish from time to time, they remind me, and make me thankful, how wonderful rest of the world is.

Let's not confuse experience & comfortable. One requires constantly getting out of the comfort zone, the other settles in.

programmers should care about warning as they care about errors.

Flying worldwide has given me insights on how reservation systems handle concurrency. It's called "yell out the passenger's seat number."

Ego is like cholesterol---there are good parts and bad parts.

The word to define the behavior of postponing to the last minute is not agile. It's called unorganized, lack of discipline.

Education is not a pursuit of a degree but the elevation and broadening of ones mind.

In programming, exceptions have become anything but.

I don't mind people talking to me when I'm working, as long as they don't expect me to actually listen. :)

I realize I can never convince anyone. At the best, I can merely lay down good reasons to help others convince themselves.

More advices are given than taken.

We may get better results if, rather than appraising employees' performance, managers focus on nurturing a good team culture.

It's an irony that fields where rapid feedback's hard are longing while the field where it's largely affordable's wants all up front.

You've shown what great things a simple man with discipline and perseverance can truly achieve. You live in our memories. #Mandela

Few things are satisfying as literally seeing tears of joy fill the eyes of someone, at the moment of their hard earned success.

There's no excuse worst than the one we give to ourself.

Quality of a presentation = inspiration * information

One of the easiest way to reduced quality of any activity is to cram it all on or near the due date.

We have no way to influence the state of the world we enter, but, I hope, we can do something good about it before we exit.

It's better to be an exceptional you than an average imitation of someone else you consider exceptional.

I don't take new year resolutions, I prefer more frequent, everyday resolutions. It's lot easier and fun to fail each day than once a year.

On any given day, I meet two sets of people: those living to die and those dying to live. The latter is so much fun to hang around with.

Every design, I bet, looked like a good idea at that time, however long ago and short lived that time period was.

Any seemingly good set of practices may yield better results when used contextually instead of prescriptively.

Experience is the passage through time where we gain the ability to look at our own past and say "what the heck was I thinking then?"

I hear that TDD is mainstream, most organizations follow Threat Driven Development.

In the digital age, developing the skills to ask the right questions is more important than having the right answers.

Success is a garland of small failures tied together with a thread of perseverance.

Teaching is not only about helping students acquire knowledge, but help them pick up better learning skills and work habits.

It's unintelligent to repeat the mistakes of yesterday. Get creative, go make new ones for today.

Trust is like hard earned wealth, we have to work each day to build it and use caution not to lose it all in one foolish act.

I think that authors who write more than one book suffer from short term memory. Why else would they take on the pain yet again? :)

What's being spoken is often not what's being heard.

It's not about fixing a bug, but learning how things actually work.

A good mission in life is not to rush to perform what others do, but fill the gaps in a passionate area where others won't.

The hardest step in solving any problem seems to be asking for help.

Functional programming is cool, but the real charm is in what it makes easy—lazy evaluation.

A design lesson I've learned over the years: behavior over state.

Most of us have to fix just one thing - attitude - rest of it gets fixed fairly easily.

When coding, null should be pronounced smell.

I really like TV... turned off.

agility is about delivering value early without compromising a reasonable quality of the product or the heath of the developers.

I don't prepare for talks, the talks prepare me—there's so much learning that happens.

Strive to be an informed constructive critique and a contributor, not a troll.

Know thy audience.

The best gift I've received from anyone is the warmth of their company and the lasting memory of good times with them.

Sorry, you have to wait, I will get to complaining about your flaws as soon as I fix mine.

Never deprive people the pleasure of enlightenment through discovery.

At some point we've to realize that effecting change in an organization start with us overcoming our own fears.

Efficiency is attained not by doing tasks better or faster, but by avoiding those that shouldn't be done in the first place.

always fun when in a room with two people, one telling the code is terse while the other pointing it's verbose.

There are only two options: adapt or perish. The first one's really fun once we break the inertia.

Complain as much as possible, but armed with facts, not with prejudice.

Let IDEs minimize typing not remove thinking.

Being content with available language/lib capabilities is as dangerous as being ignorant of them, given how nascent our field really is.

Every day is an opportunity to refactor our minds.

A good code should read like a story, not like a puzzle.

History bestowed us with Lincoln, Gandhi, MLK, Theresa, Mandela,... wish the world was truly blessed so these heroes were not needed.

what if we quit coding and start expressing?

The most rewarding, yet the hardest, part of writing seems to be the willingness to remove words to strengthen the sentences.

Values are not what we teach about, but the ones we live by.

It's not the failures that leads to success but the perseverance to apply the lessons learned.

A maintainable code is a gift we give ourselves for the future.

Most of what we reject is not due to the lack of viability of an idea, but one of fear from unfamiliarity with it.

Lesson this morning: Sometimes if it seems hard it may not need an added thrust but an extra thought.

The first human who turned noise into music is the true genius.

If there's is a lesson life has thought me, it's that there's no single way to ever look at anything.

Education shouldn't be an attempt to fill heads with knowledge, but an act of maturing minds to continuously learn & adapt.

Let's not compromise quality in favor of quantity.

I'm honored to have great students who teach me well.

If it's getting hard to effect change, chances are the organization may be stifled by a big circle of finger pointing.

It's quite ironic, but anything (tool, API, library,...) with the word 'simple' in its name rarely is.

You won't pick dentist based on their "money back guarantee." Don't pick a vendor based on strong SLA, but on reputation & relationship.

You doing the right things today is a good way to earn a sincere 'thanks' from the future you.

It's amazing how technology has evolved. We've gone from calling the wrong person to texting the wrong person.

You don't need anyone's permission to be professional.

When that urge to comment strikes, see how to express that thought in code instead of comment.

People often are not as convinced about things as they think they are.

If only we could compare the cost of quality with the cost of not having it...

Poor quality is like crime, there will always be someone willing to commit it. But, we can hope & nurture, so more of us have better values.

Speed without discipline is the fastest way to wreckage.

Tools or techniques used blindly do not create good design, programmers being conscious, making good decisions, applying right tools, do.

Some organizations try to breed programmers in captivity; they can't survive outside of their frameworks or IDEs.

Treating someone nice is not an act of respect but of self-respect.

Most programmers seems to be bothered by syntax; get past that soon, the real scare is in the semantics.

There are two kinds of people we run into each day: those we work with and those we work around.

indirection is the ultimate sophistication in programming.

The four uses of frameworks: reuse, confuse, misuse, and overuse.

Somewhere in the transition from childhood to adulthood, quite a few humans go from "I don't know" to "I don't care to know."

A sentence with "I don't like..." should not end in period, but continue to suggest why and offer some constructive alternatives.

I know for certain that the rest of my day can only be better, for I am starting by writing a regular expression.

It's little things that make a big difference in the hearts.

Geeks complaining about technology is far more pleasant to hear than folks complaining about people.

The lessons from history are filled with wonders, from what the heck was wrong with people, to awe about small group's heresies & tenacity.

After traveling thru much of this world I've discovered there are only four major religions: cricket, soccer, football, and hockey.

After roaming several parts of this world I conclude there's actually a universal form of expression. It's called graffiti.

Confusion may arise in the presence of complexity but it also appears in the case of unfamiliarity.

I've taken a few decades to acquire great wealth that's in the form of friendship with some beautiful minds.

Coding in dream is fun.

We are but victims of poor designs.

The net effect of complexities and ceremonies is multiplicative, not additive.

A true appreciation/understanding of a language emerges when we dig into its semantics, not just its syntax

We can't make legacy code better by writing more of the same way; it needs change in behavior and practice.

The biggest impediment to learning is the reluctance to interact. Good work cultures break such barriers, making it safe to communicate.

When I was young, I was told there's heaven and hell. As I got older, I learned that to be true and both coexist here on earth.

When learning new constructs I wish more developers ask "how do we test it" instead of asking "how do we debug this"?

aspiration without perspiration --> unfulfilled dreams.

Often questions seem more interesting than answers.

t seems like writing the introduction is the hardest part of writing a book. Coming up with a good subtitle, the second hardest.

automated tests are but one of many means to an end—rapid useful feedback. If there are better easier ways in a context, go for it.

Until we've fully immersed in both an exceptionally static typed & a superb dynamic typed lang, we have no rights for opinions on typing.

what makes both writing and coding so interesting and challenging, at the same time, is there's simply no one way to express.

sometimes it takes years to realize how suckish some practices are.

When did presentation get attached to slides instead of communication?

If employees are reluctant to express their view, and discuss issues, an organization has a bigger problem to tackle first.

Better feedback comes, not from demos, but active use of an application while being developed.

It's important to learn from mistakes quickly, so we can move on to make new ones.

Writing code is a lot of fun, but throwing out code is pure bliss.

I'm shocked that they'd actually number a flight 404, don't complain if no geeks board.

When selecting a language, library, or a framework, it's vital to evaluate the ability to automate tests at various levels.

A field improves, not from corporate mandates, but when its practitioners grow up to act professionally.

Nothing exposes ones ignorance of a topic than an attempt to teach it.

Java came late to the party, but they brought great desserts

Life's too short to be complaining about things we can't also help improve.

I really like the sense of humor my friends have. They endorsed me on Linkedin for XML.

I like going to foreign lands so I can learn first hand how ridiculously I've been pronouncing their town names.

A poor performing unreadable code is hard to cure on both fronts.

What a teacher teaches is far less important that what a student learns and how it's applied.

There's humor in life, wherever we look.

Let not the current employment restrict professional and personal interest, growth, and freedom of expression outside of work.

Don't turn your problems into your customers' problems.

The true pleasures of meeting someone is hearing their stories of life and their perspectives.

Every day is bright, as I find someone random, who's better than me in some way, and quietly helps me improve myself.

Both in coding and writing, experience takes us from the anxious state of trying to figure out "what to write" to "what to remove."

Frequent travelers are never in jet lag, they're only in denial.

A programmer though "I could solve this problem using a monad," now has a sequence of problems.

When we focus on what we don't really need, it takes away time, money, effort, and focus from where it's really needed.

When we compromise quality for speed, we end up losing both.

I feel like all my code is like Benjamin Button, from the way it's created to how it turns with each refactoring.

By nature we're wired to mistake familiar as simple and the unfamiliar as complex.

A bright day will come when software developers treat errors as normal instead of as exceptions.

Nothing helps make things fall in place better than an approaching deadline.

I call on restaurants to reduce serving size. You will help reduce waste and waist.

"temp" is the name of a variable that's crying for its dignity and recognition.

There comes a point in time when it's more prudent to deprecate a language than deprecating some of it's features.

Experience is developing the courage to realize we were wrong so many time over the years.

I've come to realize the struggle to write automated tests come from lack of understanding & poor design than lack of tools.

Poor quality code is a reflection of lack of respect we carry for what we do, often with out realizing it.

self-realization is the best realization.

The easiest way to learn a new language quickly is to keep learning new languages. It raises our bar so unfamiliar turn to similarities.

What we say is a reflection of the subject, how we say it is a reflection of us.

Life, love, and time - can't think of anything more precious than that.

I have a feeling that each task I strike off on my todo list gives birth to a few more tasks.

A good code invites the reader.

If we're in a course, conference, or a workshop and we stare at our own monitors, that's called being at the wrong place at the wrong time.

It's hard to effect change when the key participants do not truly understand its impacts and benefits.

A good professional places quality over quantity.

It's through struggles and failures that real learning happens.

The hardest things to explain are the ones we've not understood well.

Mind, the tricks you play!

Family: A small group sent to planet earth to be brutally honest about you.

Nothing brings comforting smile out of a C++ programmer as an unhealthy dose of type coercion.

A sense of urgency should help us create relevant things with better quality, not lot of things with poor quality.

when nothing else works…. reboot

No timeboxed activity that improves our learning and influences steps forward can be a waste of time. It's a necessary investment.

When I hear someone say "hi baby" I wonder if the subject is addressed that way for possible cuteness or probable behavior.

Three levels of programming competency: "it's all magic" -> "here's how it works" -> "here's how it should work"

Programming with locks is not concurrent programming, it should be called congestion programming.

Concise vs terse: short enough, transparent, easy to read -vs- short, opaque, hard to understand. Let's favor concise, not terse code.

Ah, caught myself creating a Rube Goldberg machine, thankfully sanity kicked in.

Perseverance is not the determination to stick with the current plan of action but the will to adapt so we can reach our goals.

I'd rather hear a "no" than a "yes" followed by inaction.

It's not just about speed, agility is also about heading in the right direction.

If we mostly follow what the masses do, we will mostly get only the results that everyone gets.

When young, we figure out it's a struggle to change the world, but as we get older we realize the real struggle is in changing ourselves.

Test code now or detest it later.

big change, big fail

make it work, then make it better real soon.

Let the tools make us productive but not ignorant.

Love them bugs that teach a lesson and set me straight.

Weigh in the potential productivity gain from an external dependency with the probable cost to maintain it along.

Exercising is a practice that turns from aversion to addiction.

In a world that seems to honor complexity & clutter, shredding the shame of simplicity is the first step to creating better design.

Feedback empowers those willing to listen.

Some organizations practice what I'd like to call "agile by convenience."

We're victims of our own complexities.

Writing gets better, with each writing, and each review.

A good design is not the one that correctly predicts the future, it's one that makes adapting to the future affordable.

After traveling to many parts of the world, I've discovered there is one common language. It's called giggles.

big wins are built from small successes.

Career is like a vehicle you operate, not hard to get it moving, but you still have to start, accelerate, steer, and decide where to go.

That desire, to solve problems without understanding them.

Q: "What to do if our designers create detailed design, insist we code it?" A: Start by confiscating their cassette players & floppy disks.

Comments that tell us what the code means is not a form of documentation but a cry for refactoring.

The more time-sensitive or mission critical a project is the shorter should be the feedback loop.

Experience does not teach us to write different code, it teaches us to write it differently.

Life's easier if, instead of the attitude of drivers, we've the agility of bicyclists who get around blocks than being stuck complaining.

Our field has turned good ideas of OOP into unnecessary pollution & excessive mutation of state. Often don't need as many object nor state.

Coming from the OO background, I feel that lazy evaluation is the polymorphism of FP, equally exciting and all the more powerful.

Rewrote a piece of code three times in flight. Now that I closed the laptop, a much better implementation comes to mind!

A well written code deals with failure. A poorly written code is a failure.

The true value's not in the different, but in the difference; not in how different you are, but in how you make a difference.

Anyone who thinks they have a sense of humor has never tried to be funny around their teenagers.

I don't really give tech talks, I simply drag my able body to the podium, then the languages and tools take over to do the rest.

I have a feeling that the current times will be referred to, not too distant in the future, as the stagecoach days of programming.

It's that feeling all over again, when the answers are waiting for you to ask the right questions.

If there's just one thing programming has taught me, it's the value of perseverance.

Most projects would be dead if there were no deadlines.

We all suck when we start something new. The easiest way to address that—suck soon, suck often.

Running a code to prove its thread-safe is like proving that someone is not guilty by asking them if they are.

Refactoring is not only about transforming code, it's equally about how it transforms the coder.

The difficulty to solve a problem increases with our level of stress.

Easy to write is important, but not more than easy to test and to maintain.

Learning good practices can help turn teams 180 degrees, but they have to practice to avoid turning another 180 degrees.

We can't fix punctuality issues by starting late. Everyone has reasons for their delays. Value and respect those who show up on time.

The best moments, however short, are when an adult reveals the child in them.

I know of only one way to write readable code—ask a colleague to read it.

Learn for school, you're a student. Learn for a living, you're a professional. But learn to share & enlighten, you become a great teacher.

Talent is a gift that comes wrapped in hard work.

With Java 8 we don't do any thing different than before, but we do it differently, for the better.

Don't let other's behavior define your character.

If you mostly talk to me negative about others in their absence, I've to assume you do the same about me in my absence.

Professionals don't compete to show who's better; they collaborate to make the world around them better for everyone.

Exercise does the mind good, it's effect on the body is a bonus.

Programmer: one who can name their children quite easily but has a hard time naming their variables.

learning is empowering.

Coding beats any other form of inflight entertainment, hands down.

Being a programmer is like a kid in a candy store, every single day.

Clear head and dirty shoes; the effect of getting out into nature.

When a test fails the programmer succeeds in learning a bit more.

A smile is worth a thousand words.

Things are often not as complex as we make them to be.

we often perform poorly when trying to anticipate and identify performance problems.

Sentences with 'always', 'never', and/or 'only' are most often wrong.

Don't let programmers watch movies w hacking. While the audience go "how cool," the geek's like "eh, wrong options, missed a -r. sigh."

Code quality is the professional responsibility of the technically savvy—the onus is not on who lacks the knowledge, details, or skills.

It's OK to create unmaintainable code, that's if you work with people you hate.

If you don't test the software you create someone else will, with a negative impact on both cost and reputation.

Lambda expressions should be glue code. Two lines may be too many.

People don't fear failure. They fear being seen as a failure.

documenting is so much easier than self-documenting, but not as effective.

No need to carry along that bag of hate through the journey of life, travel light, especially if you like to reach some heights.

Learning is a process by which a curious mind transforms a set of unknowns to knowns in a way that it exposes an abyss of unknowns.

Developers are often taught to write code, but not how to write code.

Think more, type less. Aim for minimalism, fewer states, less mutability, and just enough code for the known, relevant parts of the problem.

Functional is declarative, but declarative is not necessarily functional.

It's the struggles that make us stronger.

Typed "code is composable" and got autocorrected to compostable; love it when autocorrect knows about the state and quality of my code.

"I've set the wedding date. I've not asked her out yet."---how software projects are managed.

Whatever it is the you want to do, put your heart and soul into it. Not because it deserves better, it's because you do.

Software field has evolved. Decades ago some programmers wrote bad code. Now they most copy and paste it.

A passive teacher focuses on teaching the students. An active teacher focuses on learning with the students.

The quality of code is inversely proportional to the effort it takes to understand it.

The toughest part of testing JavaScript is shaking the belief that it is impossible or unmanageably hard.

If current dir path has space in its name, Karma does not auto run tests on file change. Proves that space in file names is bad karma.

The main problem with most products is not their capability, but one of imposed complexity beyond reasonable need.

desire improvement than perfection.

True freedom can be cherished when what a human can do, out of their own good will, isn't judged and restricted by the biases of another.

Eating is good, eating a lot in one sitting, not so much. Same with coding.

Best time to change what we do is when things are going well. Let go of what's working, with confidence, to reach for a greater good.

Get very uncomfortable when things begin to feel quite comfortable.

A very pleasing moment is when I hear good things about people I know, especially friends, from total strangers.

If you're right, you learned it well. If you're wrong, you're learning it now. Either way you come out winning.

Both in life and in writing, would be nice to favor more discussions and fewer bullets.

Programmers: A group of people who create puzzles, they call code, for each other to solve.

Just realized that typing the word "intimidating" is in itself intimidating.

It is so much fun to start something and see it quickly take shape in ways never imagined. A humbling experience.

Some of our weaknesses, when cautiously channelled, can turn into a strength.

put the effort to get the result.

There is so much we can give, each one of us, way more than we realize or will.

Much like how quality of code varies, quality of automated tests vary too. Don't assume all is well if tests are being written.

What's separable is more easily testable. That's another reason cohesion and modularity matter.

significant whitespace is a feature some languages provide as a way to mess with developers' sanity.

Don't measure someones capability based on your ability.

Time's wasted when we argue and correct every fool that comes along. Wise to focus on helping those who genuinely desire to improve.

Quick fixes may appear as short cuts in the near term but we end up cutting short in the long run.

Programming is an act of rewriting our assumptions.

The sad part of middle age is watching the people you looked up to when young fade away into history.

Either lead or follow, don't stay put.

"What do I want to improve today?" is a great thought to start the day.

Good habits and practices, like success, is not for everyone.

Software development: a profession where people get paid to write poor quality code and get paid more later to cleanup the mess.

Those who can't design are condemned to document.

Automation is easier if we aspire to automate, but equally loathe manual efforts.

Happiness: moment when what you enjoy meets what you do.

Software development involves both innovation and productization. Our practices need to facilitate both.

Never cease an opportunity to influence a young mind.

We seem to be driven largely by the fear of short term gains than the pleasure of long term wins.

There seems to be nothing so greatly motivating than a fast approaching deadline.

There are good times and then there are interesting times.

Development mindset in the last few decades has been CRUD. It seems to be shifting to streams… we're at the cusp of newer abstractions.

The ease of testing a function is inversely proportional to the number of levels of abstraction it deals with.

The first step in becoming a better programmer is to let go of the conviction that we can code it once and get it right on the first write.

The answers are all around us, waiting for us to simply pop the questions right.

Willingness to adapt and deal with the situation on hand is not agile, it's called attitude.

I dare software products to change their "Accept the Terms and Conditions" to "tl;dr"

There's one student I really care to teach everyday, it's the one within. The fact others learn along is a nice side-effect.

I'm shocked. I accidentally looked up & saw a man, walking with head straight up, facing forward, with no device on hand, like it's 2005.

The best way to kill a great idea is to ask for the permissions to implement it.

Forget cholesterol levels, doctors have found a new measure of people's health. It's called CPM or complains per minute?

Look but take time to see, hear but be keen to listen, touch but the heart, speak but as wise, and laugh but not at others.

The more we taken on the less we're able to deliver and the quality suffers too. Manage time & task wisely.

Quick to judge, slow to understand - we can do better than that.

A better person is not the one with fewer faults, but one who finds fewer faults in others.

We can't call our times modern, no way, while humans constantly provoke & fight each other rather than joining hands for a better world.

quick or quality—choose one.

Design is problem solving. Solving one problem often exposes other problems. Need desire, perseverance, and focus to forge ahead.

Good music does the mind good.

Those who sacrifice quality to get performance may end up getting neither.

Funny we complain software's not extensible, yet we're comfortable dining in restaurants that can't deviate the slightest from their menus.

The biggest impediment to FP is lack of familiarity. Code with that style in anger and it begins to get easier in no time.

fp != cryptic code — languages should promote meaningful syntax, programmers should choose sensible parameter names.

When will humans learn, imposing your ideology, however great you may perceive it to be, on others is a terrible act.

Everyone's emotional, but we express it differently. It's that difference that makes life enjoyable.

When our own money and personal reputation is involved in what we create, we think differently.

Wednesday, August 19, 2015

Functional Programming Favors Expressions over Statements

Statements perform actions, expressions perform computations.

Languages like C# and Java make extensive use of statements. We often program with if statements and for statements. At the same time, we also use expressions that often involve operators, like ?: (the ternary operator), +, and *, for example.

Statements and Side-Effects

By nature, statements have side-effects. Statements perform actions, but they do not return any results. Unless it's a no-op, statements have to cause side-effects to let us know what they did, i.e., they've to make change to one or more memory locations or external resources. Expressions, on the other hand, have no compelling reasons to cause side-effects. Good expressions don't change a thing—they do some computations and politely return a result.

There are a few downsides to the behavior of statements:

  • Forces mutations Since a statement does not return anything, its gotta modify variables or mutate external state to communicate it's effect.

    In the code below we want to compute the amount based on a discount. The discount that may be applied depends on the age of the person.

    int discount = 0;
    if(age <= 12) {
      discount = 10;
    if(age > 70) {
      discount = 15;
    int amountDue = amount - amount  * discount / 100;
    Since if is a statement in Java, the only way we can know what it decides in this example is by mutating the variable discount.

    On the other hand, here's the same code in Scala which offers if as an expression instead of a statement:

    val discount = 
      if(age <= 12) 
        if(age > 70) 15 else 0
    val amountDue = amount - amount * discount / 100

    While the Java if statement had to mutate the discount variable, Scala is able to treat that variables as an immutable val (final).

  • Not safely repeatable Since statements cause side-effects they're generally not safe to repeat. For instance, if a statement increments the value of a variable, calling it multiple times is not the same as calling it once.

  • Hard to compose Multiple expressions can be composed or chained in sequence. The result of one expression can become the operand for another. Here's an example:
  • sqrt(frequency) * 2 + abs(offset)

    Functions that do not cause side-effect are also a form of expression. We can compose or chain a sequence of functions to form highly fluent and expressive code.

    Statements don't offer that convenience since they don't return any results. First, you'd have to setup variables for a statement to mutate. Then you'd call the statement. Then you'd invoke the next statement subsequently so it can operate on more variables. That makes the code verbose and also error prone.

  • Dangerous to reorder The order of execution of statements is rather strict. Since statements cause side-effects, changing their order of execution would produce a different outcome. For instance, given a statement to read a user's name and another that prints a message to greet the user by their name, you can't reorder the sequence of their execution.

  • Hard to parallelize Statement have to mutate variables or cause change outside of their bounds to survive. If such statements are run in a loop, we can't readily call them from multiple threads. The result would be unpredictable and may cause race conditions. Extra code would be needed for thread-safety. There are no such worries for expressions, they're trivial to parallelize.

Expressions Rock

Expressions are good citizens—they don't mutate, they compose nicely, are less error prone, less verbose, fluent and expressive.

  • Idempotent Unlike statements, expressions don't have to change anything and can be called once or any number of times. Expressions are idempotent. They produce the same results, for a given input, no matter how many times they're called. This can lead to some nice optimization.

  • Easier to test Since expressions are idempotent, they're easier to test. For a givrn input, you can pretty much tell what the output would be. The expression does not give a different result because you called it twice, or you called it at a different time, or you called it before or after another expression.

  • Offer referential transparency Compilers often optimize code for better performance. Referential transparency is one such effort where an expression may be entirely replaced with a value that represents the result of that expression.

  • Can be reordered Consider the following expression:

    expr1(input) - expr2(input)

    The compiler can order the evaluation of the above in any one of the following order:

    In the first scenario, the expr1 is evaluated before expr2. In the second scenario, their evaluation order is reversed. Yet, in the third scenario, both the expressions may be evaluated in parallel, if it makes sense to. The result of all these options are the same. Expressions give language compilers and JIT compilers more room for optimization than statements do.

  • Memoizable Work with a piece of paper the following example. What is 123 + 527? Go ahead, jot down the value. You got 650. Now, what is 123 + 527? You got 650 again. You took less time than the first time. But why? That's because you're smart. You realized that the expression has no side-effects, it does not change its operand, simply retuns the sum of the given values. Furthermore, you glanced over to see that the input values are the same as in the first time. Putting these two together you realize you don't have to recompute the expression. You returned the cached value of the expression. That's memoization. You can't memoize statements, each time they're run the result may be different, so you have to run them for each call. Expressions are idempotent, so there's no reason to run them again if the input is the same and you memoized the result.

We discussed why expressions are so much better than statements. Functional programming languages lean more towards expressions than statements. When creating our own code and API, we should favor expressions more than statements to enjoy the benefits we discussed.

In the next article we will take a closer look at the power and practicality of immutability.

Tuesday, August 11, 2015

Prefer a Functional Style over an Imperative Style

In a series of blogs, we discussed:

Programmers, Languages, and their Styles

Most programmers (me included) are very familiar with imperative style. Also, most mainstream languages have promoted imperative style. However, imperative code is often verbose, involve variable mutations, use garbage variables, and take more effort to understand and maintain.

Even thought functional style has been around for a long time, most programmers (again, me included) are relatively new to it.

A functional style, which is also declarative in nature, is less noisy, more concise, more expressive, avoids variable mutation, and uses fewer garbage variables. It let's us focus on what while delegating the how to the underlying libraries. Functional style takes declarative style further by making use of higher-order functions.

Until a decade ago, programmers did not have much choice. Those coding in mainstream languages were forced to use an imperative style. The majority of programmers did not get exposed to functional style unless (a) they took college courses on languages that favored this style (they mostly forgot about it after school) or (b) worked on projects that used some esoteric languages.

Thankfully, most mainstream languages have now evolved to make programming in functional style commonly possible. C# has had LINQ and lambdas for a few years now. Both Java and C++ have also evolved to make functional style quite approachable for a large number of programmers.

That brings up the question, should we continue to use the all-too-familiar and comfortable imperative style or make an effort to program using the functional style.

In Defense of Imperative Style

The imperative style has one significant benefit—almost every programmer knows it. It's the de facto standard today. Most educational institutions teach this style and programmers gain significant experience with this style on their projects. Most people know to work with loops, conditions, assignment, and there's no fear of the unknown. Familiarity carries significant benefits.

On the other hand, not many programmers are familiar or as comfortable with functional style. It looks weird, seems complex at first sight, appears hard to debug, makes us feel rather uncomfortable. Besides, what's all those new functions, they don't make sense like the familiar for and if statements.

In Defense of Functional Style

It's human nature to associate the unfamiliar with weird and complex. Imperative style is familiar, but it has many moving parts. The moving parts increase accidental complexity. Functional style may be unfamiliar now, but is less noisy and has relatively less accidental complexity than imperative style.

It's quite normal for us to feel a bit apprehensive when we're new to something. Remember the first few days at the new job compared to a year later. Remember how you felt learning to ride a bide, to drive a car, those skiing lessons, or the first few days of learning that musical instrument. All those things felt weird until one day you felt at ease.

The more we start to read functional style code, and to write, the faster that strange foreign looking code becomes the new comfortable and familiar syntax.

Having programmed in both styles, given a choice, I prefer functional style over imperative stye. That does not mean I can write any code in both styles with the same ease. Imperative is still relatively easier for me to write, I've done it much longer; I am certainly getting better at writing functional style code each year. On the other hand, functional style is a lot more easier for me to read, it takes less time and effort, in general, compared to the imperative style code. This is especially true when I have to read other people's code.

Learning from an Uncontrolled Survey

I sought the help of programmers around the world, to get a feel for how we respond to the two styles. On August 6th, 2015 I posted a short survey. In random, the programmer taking the survey saw either an imperative style code or a functional style code. They were not warned about difference in styles, they were not even told that they would be seeing one of the two styles. All they were asked was:

What's the value of result in the code below?

Right below that question, some programmer saw the following code:

while other programmers saw the following code:

The value of result for both the code is 8, but the programmers had to figure that out. The time they took to respond was recorded by the survey. The survey presented the programmers with the current overall response, they were not shown their individual time or response.

Quite a few people pointed out that the imperative code can be refactored to make it more readable. I agree, but the sample is not very different from a lot of imperative code that I often see. Besides, such refactoring would stil not get rid of the core concerns mentioned in the previous blogs. One person even suggested that I should make the functional code worse to setup a fair comparison. But, the Java coding convention for function composition is something that I use a lot and also strongly believe that each line of code should really be cohesive as mentioned here. If I am writing functional style, I will follow those conventions.

The survey was uncontrolled, we could argue it was flawed in many different ways. I did not collect any personal data. So, I do not know who took it, where they took it from, what languages they were familiar with, their level of experience, the list goes on. It was a quick effort on my part to get a feel for how we respond to these two small pieces of code.

Initially the data from the survey was a bit surprising. The functional code did not do well, it actually did pretty miserable, as you can see from this Tweet and this one too. But, it took some interesting turns along the way, before the survey was closed on August 10th.

The survey received a total of 1114 responses—sincere thanks to each and everyone who took it. Out of which a total of 500 answered the imperative style code while a total of 614 answered the functional style code. No one was asked to respond to both style of code, they were presented only one of them.

About 82% of the programmers who read the imperative style code got it correct. However, only about 75% of the programmers who read the functional style code got it right. In spite of the functional style being easier to read, the lack of familiarity may be the reason for this.

Strangely though, among those who got the answers wrong, the median time difference is surprising. The median time to get the imperative code wrong was nearly 20 seconds more than the median time to get the functional style code wrong! Something that I have never thought about, but it seems that the functional style fails fast?!

Among the programmers who got it right, the time taken varied quite widely. The figure below shows, for each second, the number of people who took that amount of time to get the right answer for the imperative style code.

The figure below shows similar details for the functional style code.

The functional style may be unfamiliar to a lot of programmers, in spite of that, the median time for correct response was a good 30 seconds less than the median time for the imperative style code. The reason for this may be the more intuitive and expressive nature of the functional style, especially for those who more readily abstract out and grasp the details from code.

Here's a summary of the findings:

Total number of responses1114
Total responses for imperative style code500
Total responses for functional style code614
Style% of correct responsesMedian time for correct response
Imperative82%85 seconds
Functional75%55 seconds

The figures also show that relatively more people took longer to answer the imperative code correctly compared to the same for the functional code.

By no means do I claim that this study has yielded an authoritative or conclusive result. However, it seems to be pretty indicative of the reasons we have heard and learned in favor of functional style.

I hope this helps you to conduct your own surveys within your organizations or user groups. Also, I hope it motivates more developers to learn and get better at functional style of programming.

In the next blog we will discuss some of the underpinnings of functional programming.