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.

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.

Wednesday, August 5, 2015

Significantly Reducing Travel in 2016

It all started with an invitation to speak at NFJS back in 2001. It's been an amazing 15 years of conference speaking—literally hundreds. Truly thankful to have been bestowed this fun experience. I have learned so much from meeting so many great developers around the world. Irrespective of what we mostly hear in the news, the world is full of simply amazing people who are bright, smart, passionate, kind, and very hard working. I could not have asked for a better experience than this, I'm thankful to each and everyone with whom I had opportunity to interact, exchange ideas, share a meal or sit down for a cup of coffee.

With such extensive travel, sadly though, comes a large sacrifice—lack of time with the family.

Traveling extensively for 15 years means missing a lot of events: birthdays, anniversaries, parties, award ceremonies, recitals, and the list goes on.

Thankfully there's still some time for me to catch up. With my children getting ready for college in the next few years, it's a last opportunity for me to be with them. I'm also eager to enjoy the company of my parents a lot more than I have been able to for decades.

So I've made a hard decision. I will be significantly cutting down on travel starting January 1st, 2016.

I will still be traveling for my regular client work—corporate training, consulting, coaching, mentoring. I plan to speak in may be one or two conferences that I have already accepted to speak in 2016. My #1 priority for the next few years, however, will be my family. They have been very kind and patient with me, way more than I deserve.


The Functional Style

In the previous blog we looked at the declarative style. In this blog, we'll discuss functional style and how that differs from the declarative style.

We used an example of finding the minimum value from an array of numbers. We first wrote that in imperative style and then in declarative style. Let's take a look at those two versions for comparison:

public static Integer findMinImperative(int[] numbers) {
  Integer min = null;

  if(numbers.length > 0) {
    min = numbers[0];
    for(int e : numbers) {
      if(e < min)
        min = e;

  return min;

public static OptionalInt findMinDeclarative(int[] numbers) {

The declarative style is concise, expressive, uses no garbage variables, and has no explicit mutation. Let's change the example slightly to see where functional style comes in.

Instead of computing the minimum value among all the values in the array, let's compute the minimum among only even values. Here's the imperative style code for that:

public static Integer findMinAmongEvenImperative(int[] numbers) {
  Integer min = null;

  if(numbers.length > 0) {
    min = numbers[0];
    for(int e : numbers) {
      if(e % 2 == 0 && e < min)
        min = e;

  return min;

The only difference between this code and the earlier imperative version is (other than the function name) an added condition in the if statement---they both are familiar, noisy, verbose,...

Let's reduce the code and make it expressive:

public static OptionalInt findMinAmongEvenConcise(int[] numbers) {
               .filter(number -> number % 2 == 0)

The code is expressive, concise, does not have any explicit mutation, uses no garbage variables,... has all the traits of a declarative style. This version, however, differs from the previous declarative version in one significant way. Let's take a closer look at the call to the filter function:

.filter(number -> number % 2 == 0)

This function call is quite different from what we're used to in earlier versions of languages like Java and C#. Instead of taking primitive values or objects as its argument, this function is accepting an anonymous function. That makes this function functional in style.

In functional style we use higher-order functions.

Higher Order functions may

  • receive functions, much like how functions can receive primitives or objects.
  • create functions, much like how we can create primitives and objects within functions.
  • return functions, much like how we can return primitives and objects from functions.

Functional style has all the benefits of declarative style plus we can use function decomposition as a design tool. In OO programming we use objects to model separation of concern. With functional style, we can delegate different concerns or responsibilities to different functions. For instance, the filter function takes the responsibility of weeding out elements that do not meet a particular criteria. However, it delegates, to the function that it receives as an argument, the responsibility of deciding which actual elements to pick.

We looked at three styles: imperative, declarative, and functional. Imperative and declarative are quite distinct. However, functional style and declarative have much in common. All functional style code is declarative, but not all declarative code is functional style.

In the examples, the functions findMinImperative() and findMinAmongEvenImperative() are imperarive style. On the other hand, the function findMinDeclarative() is declarative. The function findMinAmongEvenConcise() is both declarative and functional—uses higher order functions.

Functional Style == Declarative Style + Higher Order Functions

Much like how functional style carries the benefits of declarative style, functional programming carries the benefits of functional style further, but we'll discuss that in subsequent blogs.

In the next blog we will examine the functional style further to get a feel of what it means to write in functional style and the direct benefits it brings.

Wednesday, July 22, 2015

The Declarative Style

In the previous blog we looked at the imperative style. In this blog, we'll rework the example from that blog to a declarative style.

Here's the findMinImperative from the previous blog, copied here for easy comparison:

public static Integer findMinImperative(int[] numbers) {
  Integer min = null;
  if(numbers.length > 0) {
    min = numbers[0];
    for(int e : numbers) {
      if(e < min)
        min = e;
  return min;

Given an array of numbers, the findMinImperative method computed the minimum value among them. The code was not long, but can be made concise by refactoring to a declarative style. Let's rewrite that method, but first let's modify the main method that's using the function.

public static void main(String[] args) {
  int[] empty = new int[] {};
  int[] values = new int[] {5, 2, 3, 6, 1, 8, 3, 11, 10};



The declarative version of the function is called findMinDeclarative. Let's implement that method next.

public static Integer findMinDeclarative(int[] numbers) {
  OptionalInt min =
  return min.isPresent() ? min.getAsInt() : null;

A quick glance at the two functions above shows that the declarative version is a lot more concise than the imperative version.

In the declarative version we got an IntStream from the array, using the method. Think of a stream as a fancy iterator. We then asked the stream to compute the min with merely one call. Finally, if there was a result, that is, the given array was not empty, then we obtain the value from the OptionalInt; return a null otherwise.

What, not how, that's the biggest change. A lot of effort went into the imperative version compared to the declarative version—loop, initialize, compare, mutate,... In the declarative version we only had to tell what. We then rely on the library of functions to take care of the details.

Previously I mentioned that coding in the imperative style is like talking to a toddler. The declarative version is like speaking to a responsible adult—convey your need and trust that the details will be taken care.

Besides being concise, the declarative code has quite a few benefits compared to the imperative version:

  • More Expressive

    The declarative code is more expressive. We can quickly grasp the intent of this code compared to the imperative version.

    Watch the eyeballs of programmers when they read the imperative code, they oscillate and settles on a point called the state of confusion. Now watch them read the declarative code—it's a single top-down pass through the code. The code reads like the problem statement.

  • Concise, not terse

    Both concise and terse code are short. Concise code is transparent and easy to understand. Terse code is short and waiting to hurt when you least expect. Declarative style may not be fewer lines of code all the time. We want less code that is easier to understand, that is, concise and not terse.
  • No explicit Mutation

    In the imperative version we initialized the variable min and continuously mutated it through the iteration. In the declarative version, no variable was tortured in the making of the result—it's a humane code.
  • No Garbage Variables

    The imperative style often uses garbage variables, like e in the example. Since we don't get into the how, those garbage variables often disappear when writing in a declarative style.

Let's run the modified version to see the output:


The declarative version produced the same output as the imperative version, but the code is a lot better. But, we can improve a bit more. null is a smell, let's get rid of that.

public static OptionalInt findMinDeclarative(int[] numbers) {

We changed the return type of the method from Integer to OptionalInt. That moves the check we did in the end to the caller of the method now. The caller can decide what to do if the value is empty, for example:

public static void main(String[] args) {
  int[] empty = new int[] {};
  int[] values = new int[] {5, 2, 3, 6, 1, 8, 3, 11, 10};
  System.out.println("Min value in empty:");
  System.out.println("Min value in values:");

Here's the result of running this modified version:

Min value in empty:

Min value in values:

We discussed the benefits of declarative style. In the next blog, we will take this further to discuss functional style.

Wednesday, July 15, 2015

The Imperative Style

Imperative style is the mainstream today.

Imperative style is prescriptive. Most of us are familiar with and used to this style. However, programming in this style requires quite a bit of effort.

Let's learn about the nature of imperative style with an example:

public static void main(String[] args) {
  int[] empty = new int[] {};
  int[] values = new int[] {5, 2, 3, 6, 1, 8, 3, 11, 10};


In the code above we're calling the method findMinImperative() twice, first with an empty array and again with an array of numbers. Let's take a look at the findMinImperative() method's implementation.

public static Integer findMinImperative(int[] numbers) {
  Integer min = null;
  if(numbers.length > 0) {
    min = numbers[0];
    for(int e : numbers) {
      if(e < min)
        min = e;
  return min;

That's imperative style in full glory.

There are a few smells of imperative style:

  • Variable Mutations

    Imperative style often involves mutating variables. In this style, we generally initialize variables to some default or initial value. Then, as we iterate, we often modify these variables. In the above code example, the variable min is being mutated, most likely multiple times. If you turn up the volume of your computer and run the code, you may hear that variable exclaim ouch, ouch, ouch,... as we iterate through the values.
  • Use of Garbage Variables

    When programming in imperative style, we often create garbage variables. These are temporary placeholders, the lowest life forms, those that often don't deserve good names, so we end up calling them flag, temp, or min in this example. More garbage variables, more garbage to collect.
  • Exhibit Primitive Obsession

    Imperative style is directed, prescriptive, and so involves giving commands or instructions. This means we often write code to provide every piece of detail—create a temporary variable, initialize loop variables, step over to the next element, assisn to a temporary variable, break, continue,...

We often feel that imperative style is easy to understand. But, that's because we're familiar with it. The downside to using this highly familiar style is it involves quite a bit of effort, we type more, the code is verbose, and often takes more effort to change as well.

Writing imperative code is like talking to a toddler—"hold it with both hands, watch where you're going, don't step on the cat,..."

Talking to a toddler can start out as a fun experience, but when you realize that you've to repeat the same things over and over again, every single day, for the next 18 years, it begins to become tiring. Programming in imperative style is much like that.

Thankfully there is a better way to write code. In the next blog we'll discuss the declarative style and then take that further to functional style.

Wednesday, July 8, 2015

Keep Lambdas Cohesive

When teaching courses on Java 8, I hear a common question: "should I combine expressions or computations into a single or fewer number of lambdas?"

The short answer—no. Let's discuss why, with an example.
      .filter(person -> person.getAge() > 17 && person -> person.getGender() == Gender.FEMALE)

In the example above the lambda expression passed to filter() is doing two checks. That lambda expression lacks cohesion, it has taken on more than one responsibility. The code takes more effort than needed to understand and will take more effort to change.

If a function is highly cohesive, it does one thing and one thing well. That is, it's narrow and focused on a single operation. Lambdas are functions—albeit anonymous—and should be designed with high cohesion.

Let's refactor the above code and discuss the merits.
      .filter(person -> person.getAge() > 17)
      .filter(person -> person.getGender() == Gender.FEMALE)

Instead of one call to the filter() method, we've made two calls. However, the lambda expressions passed to each of the calls are cohesive.

Instead of piling up the logic into one function, we have modularized it across the calls.

Now suppose we want to make a change to the logic, exclude any person older than 100 years of age. Let's make the change to the non-cohesive version first.
      .filter(person -> person.getAge() > 17 && person.getAge() < 101 && person.getGender() == Gender.FEMALE)

We had to step into the middle of the lambda to make the change. That one line of code became more complex. We have to put a bit more effort to read and figure out what that lambda is up to.

It's much easier to add a small piece of code than to change existing code. Let's now make the necessary change to the cohesive version, see how easy and elegant this is.
      .filter(person -> person.getAge() > 17)
      .filter(person -> person.getAge() < 101)
      .filter(person -> person.getGender() == Gender.FEMALE)

The change did not clutter the code or make it more complex. The code is still easy to follow. By keeping the lambdas cohesive, it's easier to add, remove, or alter the steps in the function composition.

Wednesday, July 1, 2015

Being Lazy in Java, like in Scala

Scala has a special keyword lazy that will bind a variable to a value only on demand. While Java does not have this keyword, we can easily implement this feature. Let's explore with an example.
public class Sample {
  public static int compute(int number) {
    System.out.println("assume expensive");
    return number * 2;

  public static void doWork(int input) {
    System.out.println("Processing " + input);
    if(input > 5 && compute(input) > 15)
      System.out.println("further processing with " + 
  public static void main(String[] args) {
Imagine that compute() is a fairly expensive operation. The doWork() method will invoke the compute() method only if the input is greater than 5. This we know as short-circuit evaluation—the expression after the && is evaluated only if the expression before it evaluates to true. We can see this behavior in the output:
Processing 3
Processing 6
assume expensive
Processing 8
assume expensive
assume expensive
further processing with 16
If compute() were expensive, we would not want to call it twice for the same input. Let's modify doWork() method just a bit to fix that:
  public static void doWork(int input) {
    System.out.println("Processing " + input);
    int temp = compute(input);
    if(input > 5 && temp > 15)
      System.out.println("further processing with " + 
We introduced a temporary variable, temp, to hold the result of the call to compute() and replaced the calls to that method. Logically this version of the doWork() method is equivalent to the previous version. However, the behavior is different—the compute() method will be called eagerly even though the result of its call (temp) may not be used:
Processing 3
assume expensive
Processing 6
assume expensive
Processing 8
assume expensive
further processing with 16
It would be nice if temp is not bound to a value until it's really needed, in other words, would be nice to make that variable bindind lazy.

In a previous blog on "Lazy<T> in Java" we created a class that will lazily evaluate the variable it holds. Here's that class again:

public class Lazy<T> {
  private Optional<T> instance = Optional.empty();
  private Supplier<T> supplier;
  public Lazy(Supplier<T> theSupplier) {
    supplier = theSupplier;
  public T get() {
    if(!instance.isPresent()) {
      instance = Optional.of(supplier.get());
    return instance.get();
Let's make use of this class and rework the doWork() method.
  public static void doWork(int input) {
    Lazy<Integer> temp = new Lazy(() -> compute(input));
    System.out.println("Processing " + input);
    if(input > 5 && temp.get() > 15)
      System.out.println("further processing with " + 
After this change, the value within the lazy variable temp is bound to the result of a call to compute() only on demand. If the value is not used then the computation is skipped, as we see in the output:
Processing 3
Processing 6
assume expensive
Processing 8
assume expensive
further processing with 16
Thanks to Java 8 facilities like lambdas and Supplier we can easily implement lazy evaluation in Java.

There is a caveat to using lazy evaluation—the computations have to be pure, i.e., they should not have any side-effects. In the examples I used println for illustrative purpose, in reality, we should not perform any such operation that has side-effect. The outside world should see only of the final result and not know whether the computation was performed, skipped, or ran lazily.

Wednesday, June 24, 2015

Lazy in Java

In a recent workshop on design patterns, the developers—with Java and C# background—were hacking away an example on virtual proxy. We were writing code in C# and Java, side-by-side, when one of the developers asked if we can implement in Java something similar to C#'s Lazy<T>.

Within minutes we put together a fairly simple code for it. Let's take a look at this with an example.

Consider two classes Heavy and Holder.
class Heavy {
  public Heavy() { System.out.println("Heavy created"); }  

class Holder {
  public Holder() { System.out.println("Holder created"); }
  Heavy heavy = new Heavy();
  public Heavy getHeavy() { return heavy; }
Now, let's create an instance of Holder and get a reference to the instead of Heavy from it.
public class Sample {
  public static void main(String[] args) {
    Holder holder = new Holder();
    System.out.println("Get Heavy instance");

    Heavy heavy = holder.getHeavy();

    Heavy heavy2 = holder.getHeavy();
If we run this code, we'd see the output:
Heavy created
Holder created
Get Heavy instance

The instance of Heavy was created eagerly, at the time of the creation of the Holder instance. The output also shows that both heavy1 and heavy2 refer to the same instance.

It would be nice, especially if Heavy were an expensive resource, to create it only on demand. That is, we want to be lazy about creating it.

Before we fix the code above, let's create a helper class, one that will encapsulate the object creation and, at the same time, create the instance lazily.
class Lazy<T> {
  private Optional<T> instance = Optional.empty();
  private Supplier<T> supplier;
  public Lazy(Supplier<T> theSupplier) {
    supplier = theSupplier;
  public T get() {
    if(!instance.isPresent()) {
      instance = Optional.of(supplier.get());
    return instance.get();
The helper class Lazy<T>'s constructor receives a Supplier that knows how to create an instance of the target class T. In the get() method, if the instance field is empty we assign it to an Optional holding an instance of the target type T obtained from the supplier.

Let's use this helper class in the Holder class.
class Holder {
  public Holder() { System.out.println("Holder created"); }
  Lazy<Heavy> heavy = new Lazy<Heavy> (() -> new Heavy());
  public Heavy getHeavy() { return heavy.get(); }
In the Holder class, we replaced the field heavy's type from Heavy to Lazy<Heavy>. Also, in the getHeavy() method we invoke the get method on the lazy helper instance. The change to Holder was pretty minimum. There's no change to the Heavy class and also there's no change to the Sample class.

Let's run the modified version of the code to see the effect of this change:
Holder created
Get Heavy instance
Heavy created

Thanks to the Lazy<T> helper, the instance of Heavy is created lazily, only on demand. We can also see that the first call to get created the instance, but the second call to get is returning the pre-created instance. The Lazy<T> helper does a good job of encapsulating and lazily creating the instance. This implementation, however, does not guarantee any thread safety (the C# Lazy<T> does).