Wednesday, February 10, 2016

Benefits of Pure Functions: Memoizable

We touched on how pure functions offer referential transparency in the previous blog. In this blog, we discuss another benefit from this list: pure functions are memoizable.

Let's start with a little exercise.

What's 2 + 3?

Don't be shy, please do the math.

You got the answer, of course.

Let's try that again, what's 2 + 3?

Obviously, the answer is still the same. That's because pure functions produce the same result for a given set of arguments, no matter how many times they're called—we discussed this in a previous blog. But, we can use this property of pure functions as an advantage. Let's see how.

What's 332 + 544?

This involves a bit more effort that the previous arithmetic required. Once you complete, move on to the next step.

OK, once more, what's 332 + 544?

You got it again. Though, I bet, this time you were way faster than the first time. You've become so good at this so fast!

You're probably saying "I cached it!"

Sure, but there was more. You cached the result only because you knew that + is pure and the operands are immutable in that expression; otherwise, you'd not be caching.

What you did—caching—is called memoization.

Memoization is an optimization technique. The main goal is to reduce the computational time at the expense of space, that is, by storing or caching the results of computations based on the values of the operands or arguments.

Memoization is an example of referential transparency. That is, when we use memoization, we're replacing an expression with its value. However, referential transparency does not always mean memoization. For example, referential transparency may use expression substitution, like replacing 2 + 3 with 5 at compile time. On the other hand, memoization involves maintaining a cache table.

When programming, we may implement a Map to store the operands or arguments as keys and the corresponding result of the expression as the values. Some languages also provide specialized library functions for memoization. Let's take a look at a couple of examples.

Here's an example in Groovy:

def fib;

fib = { n ->
   if (n < 2)
     1
   else
     fib(n - 1) + fib(n - 2)
}

def start = System.nanoTime()
println(fib(40))
def end = System.nanoTime()

println((end - start)/1.0e9)

fib is a variable that refers to a closure. The closure recursively computes the Fibonacci value for a given position n. Running groovy sample.groovy produces the following result:

165580141
16.15600300

The code took a little over 16 seconds to run. It performs repeated calls to the function fib for different positions when the recursion unfolds. Momoization will save time.

The Groovy library provides a convenience function to memoize. Let's change the previous code to use that.

def fib;

fib = { n ->
   if (n < 2)
     1
    else
      fib(n - 1) + fib(n - 2)
}.memoize()

def start = System.nanoTime()
println(fib(40))
def end = System.nanoTime()

println((end - start)/1.0e9)

The call to memoize() returns another closure. This closure will check if the value for the given parameter has already been computed. If so, it will return the cached value instead of executing the underlying closure. If the value does not exist, it will compute, cache, and return.

Here's the output of the modified code:

165580141
0.042137395

Thanks to memoization, the code took significantly less time to produce the same result.

Groovy provides a few variations for the memoize() function, with various options to tailor the memory usage.

Clojure also has a memoize function. Here's an example from Clojure.

(def fib (fn [n]
  (if (< n 2) 1 (+ (fib (- n 1)) (fib (- n 2))))))

(time (println (fib 40)))

(def mem-fib (memoize (fn [n]
  (if (< n 2) 1 (+ (mem-fib (- n 1)) (mem-fib (- n 2)))))))

(time (println (mem-fib 40)))

fib is a variable that refers to a lambda expression. The lambda expression computes the Fibonacci value. mem-fib, on the other hand, is a variable that refer to the result of calling memoize on a lambda expression. Within the second lambda expression, the anonymous function calls the memoized version.

The call to fib will take way more time than the call to mem-fib, as we can see from the output of running the code:

165580141
"Elapsed time: 2217.313342 msecs"
165580141
"Elapsed time: 1.070711 msecs"

Convenience functions like this can greatly reduce our efforts to memoize. The degree of support, however, varies across languages.

Memoization makes sense only if the result of the function will be the same for a given set of arguments or input. Since pure functions have this property, they're readily memoizable.

In this series of blogs, we've looked at four benefits so far. In the next blog we'll look at another benefit: easier to parallelize.

Wednesday, January 20, 2016

Benefits of Pure Functions: Offer Referential Transparency

In the previous blog we discussed how pure functions are easier to test. In this blog, we focus on the third benefit listed here—pure functions offer referential transparency.

Referential transparency says that an expression or a function may safely be replaced by its value.

You can replace the sentence

Elvis's birth city is a nice city
with
Tupelo is a nice city

Likewise, the expression

input + 3 * 2

can be rewritten as

input + 6

since the sub-expression 3 * 2 is referentially transparent.

Pure functions or pure expressions are referentially transparent.

However, that does not mean all impure functions exhibit referential opacity (the opposite of referential transparency).

For example, the expression

input + 10

is not pure and can't be replaced with it's value. It's not referentially transparent. But, even though the expression

input * 0

is not pure, it can be replaced with the value 0.

If you know that a function is pure, then you know that it is referentially transparent.

Why should we care?

Proving correctness of complex mathematical functions is challenging. Rewriting the functions into a simpler form may ease the pain, but that rewrite has to be proven correct as well. This is one of the places where referential transparency helps.

In programming, referential transparency plays a significant role in program optimization. The ability to replace a function or an expression with its value, at compile time, where possible, can save quite a few cycles during runtime. Likewise, JIT compilers can use that information to perform runtime optimizations where desired.

Referential transparency says it's safe to replace a pure function with its value. Idempotency say it's safe to recompute the function any number of times. These two features combined says that pure functions are easy and safe to play with—they offer the most flexibility for program optimization.

In the next blog, we'll discuss how this benefit leads to another benefit of pure functions: memoizable.

Friday, January 15, 2016

Lessons: Concurrency without Pain in Java

A previous blog referred to Lessons on Software Design: An Agile Approach. Another topics that intrigues developers is concurrency and agilelearner has lessons for that.

The topics discussed are:

  • Perils of Concurrency
  • Synchronized and Suffer
  • Software Transactional Memory
  • Actor Based Concurrency

The lessons also include hands-on labs for you to try.

Access requires regular subscription. If you're new to the site, try out some free videos here.

Wednesday, January 13, 2016

Three fundamentals for presentations

A young developer emailed "presenting for the first time at a conference, very very nervous, can you share some tips..."

This is a topic of interest to a lot of us, we all present often, in conferences, at the user groups, at work, at a social event, the list goes on.

Being nervous is a good thing, that means we care about what's ahead. That's a way for the mind to tell we better give this some thought and put in some efforts, to get ready.

Here are three fundamentals that may help deliver a presentation, from the first to the hundreds that follow:

  • Help, not impress

    The main goal of a presentation should be to help the audience learn, not to impress them. If we try to impress them, we often try to compress a lot of stuff in a short time, the result, a confused, frustrated, and lost audience. When we try to help them learn, we start thinking about the topics that are the most valuable for them to learn, that can be reasonably covered in the given time. It's all about what they get out of the presentation.

  • Walk with the audience

    At every minutes of the presentation, make sure the audience are with you, not by asking them if they follow, but by structuring the flow of topics in a way that they do. If we jump in and around complex topics, throwing concepts at the audience, they're soon lost. When this happens, most audience are left behind near the start of the talk while the speaker runs around frantically from topic to topic.

    Write down on the right side of a paper what a single objective of the presentation is. Then, on the left side write down the starting point, what everyone in the room will know. Draw an arc between the two points. Then jot down on the arc, in short intervals, the topics that will walk the audience from the starting point to the end. This is the knowledge curve and walk that curve with the audience, in a pace reasonable for them.

  • Be honest

    You've read, prepared, and practiced a lot. That means you know a lot. But, no one knows everything. When someone in the audience asks a question you're not comfortable with, be honest. It's perfectly OK to say "sorry, I don't have a clue" or "sorry, I've never run into that issue at my work." The benefit of being honest and short is two fold. One, your honesty gives you credibility as a speaker. Second, you can move on to focus on other questions or the topics that most people in the room are interested in.

Happy Presenting and learning.

Wednesday, December 30, 2015

Benefits of Pure Functions: Easier to Test

In the previous blog we discussed how pure functions are idempotent/nullipotent. In this blog, we focus on the second benefit listed here—pure functions are easier to test.

There are several factors that make a function hard to test. For example, long functions are hard to test. They do multiple things and hence fail the single responsibility principle. The more a function does, the more effort it takes to test it. Beyond a certain complexity it seems almost impossible to test. In short, low cohesion makes testing harder.

Another factor that makes testing hard is dependency. If a function depends on many things, it takes more effort to get all things setup before the function can be tested. In other words, high coupling makes testing harder.

Mutability also makes testing hard. If the value of something changes during the execution of a function, that makes the function's result rather non-deterministic from the testing point of view. Let's take a look at a couple of examples to illustrate this point.

Here's a function that computes the area of a circle, given the radius.

var areaOfCircle = function(radius) {
  return Math.PI * Math.pow(radius, 2);
}

Let's think through the tests we'd have to write to verify this function's behavior:

  1. Send a positive value for the radius and assert the result is correct.
  2. Send another positive value, a decimal, and asset that the result is correct to the desired precision.
  3. Send a large value, but within reason for the application on hand.
  4. Send a zero
  5. What if we send a negative value?
  6. What if we don't send any parameter at all?

May be you can think of a few more tests, but that's pretty much. Writing these tests are pretty easy, the result for each one of them is very predictable. Even though the function depends on the Math library, PI is a constant and pow is a pure function. Also, the parameter radius is passed by value. That makes areaOfCircle a pure function. No worries.

Let's take a look at another function, one that returns a greeting message.

var greet = function(name) {
  var hourOfDay = new Date().getHours();
  
  if(hourOfDay > 4 && hourOfDay < 13)
    return 'Good morning, ' + name;
  
  if(hourOfDay > 12 && hourOfDay < 17)
    return 'Good afternoon, ' + name;
  
  if(hourOfDay > 16 && hourOfDay < 20)
      return 'Good evening, ' + name;

  return 'Good night, ' + name;
}

If a name Jane is passed to the function, it should return Good morning, Jane in the morning, Good afternoon, Jane in the afternoon hours, and so on.

The world does not agree on what evening hours are or morning hours for that matter. My friends generally consider my early morning hours as their late-night, for example. However, the issue with testing this function is not as much that we can't agree what those hours are. For a given application, that hours for each part of the day can be clearly define. If we decide to change that definition we can change the test accordingly. That's all the more reason to have tests to make sure the code is dealing with the hours properly.

The main issue here is if we pass a name to the function we have no clue what will be returned as it depends on the time when the function is executed.

We may argue that the test knows when it is running. So, it could call the function, get the salutation, and if it is morning, for example, then assert that the message has Good morning. This line of thinking has at least two main problems:

  • First, how does the test know what message it should expect? If it will do the computation, then the test becomes complex and also how then is the test different from the code being tested?
  • Second, suppose the test calls the function at 11:59:59 and the function returns Good morning..., but by the time the test computes the message to compare it may be the afternoon. The test, in this case, will report a failure even though nothing may be wrong with the function. If you run the test again, without any code change, it may pass. These kinds of tests can drive us crazy, really quick.

The culprit here is that the function depends on something that changes—this function is not pure. Let's change this function to make it pure.

var greet = function(hourOfDay, name) {
  if(hourOfDay > 4 && hourOfDay < 13)
    return 'Good morning, ' + name;
  
  if(hourOfDay > 12 && hourOfDay < 17)
    return 'Good afternoon, ' + name;
  
  if(hourOfDay > 16 && hourOfDay < 20)
      return 'Good evening, ' + name;

  return 'Good night, ' + name;
}

The modified version of this is pure. It takes values, returns a result, and as long as the arguments are the same, it will produce the same result. It's much easier to write tests for this function. We can pass different sample hours for different part of the day and around the boundary hours. We can pass a few different names, an empty string, and no name. We can try testing without any parameters, and so on. No worries again writing tests for this function—each test is easy to write and we clearly can tell what the function should return for each call.

We shifted the query for the date from within the function to outside. The caller of this function now has to get the date. That's a small extra effort for the caller, but it makes this function, which has the various conditional logic, so much easier to test.

We discussed how pure functions are easier to test and how mutability makes testing more difficult. In the next blog, we'll discuss the next benefit of pure functions—referential transparency.

Tuesday, December 29, 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.

Automated testing slows us down when we code, speeds us up when we refactor.

We should take as much care about how we present as to what we present.

Don't bother testing software, if it does not work your users will tweet about it.

Software development is no longer a game of hobbyists. It affects humans in many ways. High time we improve our practices and discipline.

Open and timely communication is a reflection of mutual respect.

Nature has wired us to thrive on feedback, right from our first moments. Make active use of it in every form possible.

I hated Haskell's static typing until I realized it infers the type and I don't really have to mess with that detail for most part.

No success ever emerged from staying comfortable.

Lack of professional discipline is an sign of occupational stupidity.

Of all the journeys, the one from confusion to clarity is the most enjoyable.

Writing is addictive.

Programming is a wonderful act of continuous discoveries.

Writing is like the morning fog, rewriting is like the Sunshine that follows.

Writing does not consume time, it consumes you.

Improving oneself each day is the most enlightening part of living.

The toughest part of writing is mustering courage to delete an entire chapter and start over. The best part is the result.

Success is important. But, an organization's desire to succeed at all cost, by sacrificing their employees' living, is morally wrong.

After all it really takes PHD to succeed, no not a degree, but Perseverance, Hard work & Determination.

After all it really takes PHD to succeed, no not a degree, but Perseverance, Hard work & Determination.

JavaScript is like an infant. It's cute to play with, but you have no clue why when it begins to cry.

Friday, December 25, 2015

2015 Top Viewed Presentations @agileLearner

The following were the five most viewed presentation on http://www.agilelearner.com in the year 2015:

November and December have been the most active months so far in subscriptions. Very encouraging. More videos coming ahead in 2016. If you like to get a taste of the site, please check out the free videos at this link.

Wednesday, December 23, 2015

Benefits of Pure Functions: Idempotent and Nullipotent

Pure functions provide many benefits—here's a list in a previous blog. Pure functions are idempotent; in fact they are nullipotent. In this blog we'll discuss what that means and why we should care about that.

The word idempotent has a few different meanings, but the one we'll focus on here is the one most commonly used in programming. A function or operation is idempotent if the result or effect of executing it multiple times for a given input is the same as executing it only once for the same input.

If we know that an operation is idempotent, we can run it as many times as we like. In other words, it's safe to retry.

The function a + b is pure and it can be executed any number of times. For a given value of a and b, it would produce the same result no matter how many times we call it. That example is trivial, but let's look at a more practical example of idempotent operations.

During testing, I've noticed that Google Chrome may make more than one GET request for a single visit to a site. However, for a POST method or verb it makes only one request per visit. While I may be tempted to complain about this behavior, I have no footing—in HTTP the verbs GET, PUT, and DELETE are assumed to be idempotent; POST is not considered to be idempotent. Let's explore this further.

When we make a GET request, we often request for some data. For example, given a presentation id, we may ask for details about that presentation: title, author, duration, keywords, link to the video, etc. It does not matter how many times you ask for that detail, the result is going to be the same for a given id (assuming the presentation is not deleted between calls to GET). Ignoring the overhead of making a call, we can call this any number of times.

Likewise, PUT which updates a piece of data, and DELETE that remove it, are idempotent. In the case of PUT, whether we set a data to a specific value once, or multiple times, it would be the same after the first PUT (assuming no DELETE or another PUT with a different parameter is interleaved). There's no harm in repeating PUT. Likewise, whether we ask a piece of data to be deleted once or many times, the result is the same, it's gone. On the other hand, POST is intended to change an existing data to a value based on the current value and the parameters. For example, if a POST request charges your credit card for a certain amount, you'd not want that to be repeated multiple times!

At first sight pure functions appear to be idempotent and they are. If we call a pure-function once it yields a particular result based on the input. If we call it many more times, with the same input, it would return the same result as the first time.

If we only look at the result of the call then pure functions are idempotent, much like PUT and DELETE are. From the point of side-effects, they're more than idempotent—they're nullipotent. A function is nullipotent if the effect of calling it multiple times is the same as not calling it. That is, if we consider lack of side-effects of pure functions, they're more like GET than PUT or DELETE.

Knowing that pure functions are idempotent gives us some nice capabilities. Since we can safely call them multiple times, we're not forced to hold on to the results of a previous call. If we need the result of a function again, we can simply call it again—assuming the execution time is insignificant.

Knowing that pure functions are nullipotent also gives us some nice capabilities. We can decide to not call a function if we know that we won't need its results further down in our computations. As we will see in a later blog, it's this property that makes lazy evaluations possible.

The net benefits of idempotent and nullipotent behavior is that pure functions may be safely retried any number of times or their execution may safely be skipped entirely if we know we don't need the result after all.

We discussed the first benefit of pure functions in this blog, in the next blog we'll look at the second benefit—easier to test.

Wednesday, December 16, 2015

Benefits of Pure Functions

In the previous blog we discussed the two rules that pure functions should follow. Those two rules may appear rather restrictive, but those lead to greater good.

Pure functions:

That's a lot of benefit for following two rules. We will explore each one of them in the following blogs, starting with a discussion of how pure functions are idempotent in the next blog.

Monday, December 14, 2015

Lessons on Software Design: An Agile Approach

Have you seen the collection of 84 recordings on the topic of Software Design?

The presentations include topics on:

  • design concepts
  • evolutionary architecture and design
  • design principles
  • TDD
  • mocking
  • code quality
  • design patterns
That's a total of 37 hours for a small price of $10.99 (actually you can download any or all of the 120 hours of recordings available as of today on https://www.agilelearner.com—yes, that's insane).

Happy Coding.