Growing up my mother would frequently tell me, "You're too literal."  I'd often says things in perfect seriousness and be surprised to get a resounding belly laugh in response.  In my twenties, I taught myself Japanese and it opened my eyes to aspects of human interaction that I had been quite oblivious to.  Japanese is a high context language.  It's far less explicit than English.  The onus is on the listener to understand rather than the speaker to make themselves clear.  It's consequently far less verbose.  In fact the ability to communicate significant meaning in only a few words gives the speaker a touch of sophistication.  In fact this is largely the point of Haiku, to conjure a romantic image of nature while being constrained to a terse form.  The culture is rather homogeneous so there's a shared common knowledge.  It's a far departure from the heterogeneous, chaotic, and therefore necessarily direct style of communication we have in the Unite

I always enjoyed math as a kid.  The objectivity of the content pushed opinion to the margin.  All I had to do was understand and repeat the steps to do well.  Unfortunately, that's how I approached learning.  Understand the logic and repeat the steps.  Goal focused grade optimization helped me perform well on paper without thinking deeply about the topic. After entering the work force I had the good fortune of working with people who had developed a strong intuition with math.  Watching them solve problems made me realize the power of having an intuition around mathematics and CS concepts.  Considering the prevalence of computers in our lives, repeating the steps of a formula is a skill that's been commoditized. What's left for most of us engineers is the creative application of tools to solve problems. In this article I want to consider hashing with the purpose of gaining some intuition.  While it's a familiar everyday concept, it's a largely solved proble

There's a misconception about engineer quality that states that good engineers are orders of magnitude better than average engineers..  As I understand, it began with  Bill Gates  saying, "...a great writer of software code is worth 10k times the prices of an average software writer." I've known a lot of smart people, but in my experience genius itself is a bit of a suspect concept.  Everyone has their gifts and weaknesses.  Even those publicly labeled as genius may simply be freed by eccentricity to express themselves openly when others would hold their tongue.  In my mind "genius" is really a parental strategy to propel children toward survival in a world of scarcity.  An extreme variant of what Japanese call "親バカ" or "imbecile parent," a parent so lovestruck by their child that they're incapable of seeing their faults. Let's say we take "genius" as a concept at face value though.  Even geniuses are not 10k mo

As engineers, it's a good idea to get exposure to some business concepts.  Even if you were a born coder and want to eventually be buried with your laptop, taking the opportunity to work in a product and/or management role during your career can really boost your effectiveness.  Once you understand the basics you can often predict features and risks and design to accommodate them before ever being asked.  You can also contribute to the partnership from both sides of the table, offering strategic insights that the business themselves may not have considered. We engineers are doers.  We're usually workhorses, not show ponies and we often pride ourselves on this spartan aesthetic.  There's all kinds of speculation as to why Steve Jobs always wore a simple t-neck and jeans.  Part of it's surely attributable to brand building and decision fatigue  but part of it's probably because if he was dressed to the 9s like 007 he'd likely lose credibility among his fell

If you're like me your parents tried to teach you not to lie.  As you grew into an adult you started to notice that most adults do lie.  In fact you could go as far as to say that most utterances contain only partial truths.  To quote Gracian, "The truth is generally seen, rarely heard."  So when your parents told you not to lie were they just indirectly asking you to hush up?! While your parents offered idealistic, age appropriate advice, Gracian offers the practical .  Like the lyrics to the Depeche Mode song Policy of Truth , "You'll see your problems multiply...(when you follow) the policy of truth.  So "...hide what you have to hide and tell what you have to tell." We are living in what Alvin Toffler calls, The Third Wave or Information Age .  As he describes in Powershift , mankind has progressed from using violence, to wealth, and finally knowledge to attain power.  In this era of Fake News, I find myself frequently hesitating

If you haven't heard about the Unification Church (aka The Moonys) you may be surprised to hear about their  mass weddings .  They'll fill a stadium with perfect strangers and in one stroke marry the lot of 'em. Considering the divorce rate for romantic marriages (~50% in the US), I shouldn't criticize.  It's just an unexpected way of approaching matchmaking.  I'd be really interested to learn about the success rate of these marriages.  After all traditional, arranged marriages work out more often than romantic ones, boasting a divorce rate of only ~4%. In coding, I sometimes come across another kind of unlikely pairing.  I thought it an obvious anti-pattern but as we'll see there are tools in some languages that make it all too easy a choice. For those of you who've spent some time with C++ "passing by reference" will be familiar.  C++ allows you to do cool stuff like: Pass by Copy int doSomething(int y) A separate copy of y m

I recently read this blog about Tech Debt  and really liked the authors point.  To paraphrase, "Bad code isn't tech debt it's more like an all-or-nothing bet with a hard payout date." While debt can be slowly paid down and may carry with it some upside like tax deductions, bad code does not.  It usually has a near term payoff and a long term bleed.  Once the benefit has been realized, it's rarely cleaned up.  New code has to straddle old, messy code and thereby become messy and suboptimal itself.  Subsequent growth now faces the same challenge to a greater extent. The growth is exponential in nature, not linear. Like a tree that grows around an obstacle, it follows the path of least resistance, getting the job done but eventually sacrificing its structural integrity.  Things progress status quo until something catastrophic happens causing people to take notice. Convincing the business to pay for the cleanup is difficult and usually the level of eff

The Converter Looks like this: public static class Converter {    public static  Product  toProductFromWidget(Widget widget) {       return  toProduct( widget.getLength(),  widget.getHeight());    }    public static Product toProductFromThing(Thing thing) {       return  toProduct( thing.getA(),  thing.getB());    }    private static Product toProduct(int x, int y) {       return new Product(x, y);    } } What does it do? The converter is useful when you need a uniform treatment for disparate inputs.  One example would be if you're receiving data from multiple vendors but need to assure that regardless of upstream, the treatment and output must be the same. In this way, a converter rather resembles an inverse Factory pattern.  Whereas a factory takes a uniform input with variance in its values and produces a range of disparate outputs based on those values, a converter takes disparate inputs and produces a uniformly formatted output.

The Telescoping Constructor Looks like this: Widget(varA) {...} Widget(varA, varB) {...} Widget(varA, varB, varC) {...} or Widget widget = new Widget(x); widget.setVarA(...) widget.setVarB(...) widget.setVarC(...) There are both shared and specific problems for each variety.  Let's talk about both. The 1st case, supernumerary constructors. What's wrong with this? Well, the good news is you provide  quiet consumption since there's a bespoke constructor for every use case.  Rather than have noisy construction, where the consumer must fill in a bunch of nulls, you move the noise into the implementation.  We shouldn't make assumptions on how many times the class will be used, so keeping the complexity to ourselves is generous and will lead to a more maintainable macro system. However, one problem here is that the end consumer is not restricted in their choice of constructors.  Like shopping at the super market, somet

The Nonce The English language is immensely flexible.  Perhaps one of the reasons it's been adopted as a global language for business is its versatility.  We've got words like thingamajigger and cattywumpus.  We even celebrate our Xtreme freedom by naming things after our made up words. Particularly here in America, where things aren't so formal, one can see  great liberties being taken .  Sometimes bad grammar is actively  sought out in order to grab the audience's attention. It's said that art imitates life, and even upon the canvas of the IDE one can observe this phenomenon.  A coder doesn't know how to get from A to B so they just shoehorn the thing in, plucking qualities that seem okay-ish from context.  This is the Nonce class, like its English sibling, an object "coined or used only for one particular occasion."  An improvisation.  An expedient. If applied with discipline, this may appear in the form of an anonymou