At The Risk of Stating the Obvious

I am going to drop some exceedingly basic knowledge on you.  It’s so basic that 6 months ago, I would not have considered this worth writing.  But given the funhouse mirror of the 2016 U.S. presidential election, it feels to me like some simple ideas are worth reiterating.  One of those ideas is that white folks as a class of people in the United States do not have a reason to claim victimhood on account of their race.  In other words, the claim that there is systematic oppression of white folks in the U.S. is delusional.  This seems obvious to me, but I think to some folks for whom the whole alt-right schtick holds an appeal, this message has gone lost.

I will argue from my own experience.  I’m a white guy in my middle 40s who has lived all over the US, with long stretches in the South, the Midwest, the East Coast and the West Coast.  I’ve lived in small towns, suburbia, and big cities.  I’ve lived in neighborhoods that were predominantly white and neighborhoods that were predominantly black.  I’ve caught crawdads in the creek, worked in the “knowledge economy”, and gotten mugged on a street corner at night. There are many realities that I haven’t experienced, but I’ve gotten a decent sample.

I’ve also had the pleasure of working with people whose backgrounds ranged from Anglo-American to Zimbabwean immigrant.   More than a few of the managers that I’ve worked under have come from very different backgrounds than my own.   In fact, the most pivotal early career advice I received was from a fellow from Senegal who was one of the chefs at the restaurant where I waited tables in college, though he also had a degree in electrical engineering.  He told me back in 1996 that Java was the programming language I should learn, and that tip basically gave me a head start on the next 20 years of my career.

All of this is not to say that I can generalize with 100% certainty from my experience, but experience does count for something.  And I’ve lived to middle age as a white guy in America with a fair bit of contact with all the other types of folks that share this country.  I have never had the experience that my ethnicity was preventing me from an opportunity that I wanted.   I have encountered opportunities that I wasn’t ready for, for a variety of reasons.   And I have encountered people here and there that disliked me because I was white.  I also encountered a line cook named Neftali from El Salvador, who told me that white guys don’t know how to please a woman.  Whatever, Neftali!  But I have encountered no real opportunities that were denied to me because of the color of my skin, whether the hiring manager looked like me or not.  If you’re non-white, you might think of this as “white privilege”.  I sincerely hope that one day that is just the norm for everyone in this country.

I do believe people when they say they are hurting economically.  I know there are areas of the country and whole sectors of the economy where the opportunities are scarce and the situation looks grim.  But I have a difficult time believing that white folks who find themselves in that situation are there because they’re white.  And I think that if you’re going to spend your time worrying at that problem, you are wasting precious time that ought to be spent on other aspects of your situation: where you live, what industry you work in, what education might be needed for a change in career, or what else needs to change in society to open up those opportunities.

I don’t mean to sound callous to people’s economic suffering.  The tech industry where I work can be turbulent too, with a whole panoply of economic stresses — ranging from outsourcing to automation to just the vagaries of start-up life.   So I don’t pretend to have everything all figured out in life.  I’m always looking over my shoulder for my new robot master.  But I’m pretty certain that the worst thing in a bad situation is to delude yourself about the problems that you’re facing.  And likewise, I’m certain that being born a white US citizen should not be counted as one of your problems in 2017.  If that’s the chip on your shoulder, you need to brush it off.




The Business The Innerweb

Why I Do Not Yammer

Yammer, the enterprise social network, has an epic fail for a brand name.  Who in their right mind wants to yammer?  Is that a pleasant word?  No, my friend, it is not.  Here are some definitions found online for the word “yammer”:

  1. to whine or complain
  2. to make an outcry or clamor.
  3. to talk loudly and persistently.

So, this is supposed to make my work life better?  To have yet another channel of communication I must attend to — this one purpose-built for people to whine or complain loudly and persistently?

Yes, Twitter is also a silly brand-name, but at least the word “twitter” brings connotations of merrily chirping birds.  Yammer sounds like a headache.

Message to branding wizards: respect the meanings of words.  Yammer is a horrible name for something that you want people to like and use.

Message to the working world: if your boss tells you, “We’re all going to Yammer now, it’s some next-gen Internet shit that will help us synergize,” or something to that effect, please tell him or her, “Sorry, but I think that’s the dumbest name for a communication product I’ve ever heard.  In the name of intelligent life on Earth, let’s not use it.”

Now, I’ll admit, at least 95% of my irritation with Yammer is because their name is asinine.  But having actually used it at my actual job, I can also say that the marginal benefit of having a Twitter-for-the-enterprise deliver the random thoughts of my co-workers (who do, in fact, have high quality random thoughts) to my desktop or mobile device nearly instantaneously is far outweighed by the negative effect of distraction.  So, really, I’ve tried it and I can do without, thank you very much.

Also, to be clear — I wish the hard working folks at Yammer the best of luck.  I hope they’re all rolling in money, post-acquisition.  And I also hope that they all get to move on to something else soon and work on a product with a better name.

Java Open Source Ruby Software Engineering The Business The Innerweb

QCon San Francisco 2010 Redux

So, I just got back from QCon SF 2010 last night.  All in all, a very good conference.  Rather than write up any kind of extensive summary, I’ll offer up my rapid digest of the major themes from the sessions I attended.  Without further ado, here it is in outline form:

  1. Dealing with data at large scale
    1. OLTP
      1. Those who can get away with it are using systems that have more flexible consistency models than traditional RDBMS (CAP theorem trade-offs)
        1. Most using some form of eventual consistency
        2. Many sites implementing their own Read-Your-Own-Writes consistency on top of more general storage systems
        3. These systems must deal with data growth (partitioning data across nodes)
        4. Must deal with hot spots (redistributing / caching hot data across many nodes)
        5. Must deal with multiple data centers (some are simply punting on this)
      2. Twitter and Facebook both built their own key-value stores on top of MySql, Memcache
        • Twitter’s solution seemed a little cleaner, Facebook’s a little more crusty
      3. Amazon S3: also key value store with own caching, replication, consistency models
        • This one had the most sophisticated seeming solution for dealing with hot spots
    2. OLAP
      1. Lots of people using Hadoop to crunch offline data
        1. Good tools for workflow of jobs, dependency management, monitoring are essential
        2. Quantcast found that EC2 was not adequate for their needs in terms of throughput compared to an owned, highly-tuned cluster, though it has improved over time
          • still good to have on hand for surge capability
    3. Operating on the public cloud
      1. Increased demand for monitoring — and most monitoring tools not built for cloud instances that wink in and out of existence
      2. Increased demand for fault-tolerance — latency can vary more widely, hardware failures happen out of your control
      3. Increased demand for sophisticated deployment automation
      4. Motivation is that you want to use a cloud, not build one
        1. Capacity planning is difficult when you’re in a huge growth scenario
        2. Leverage the staffing and expertise of the public cloud companies (Amazon, Gigaspaces, etc)
        3. Data center is a large, inflexible capital commitment
      5. Traditional CDNs are still necessary and useful for low-latency, high bandwidth media delivery
      6. PCI compliant storage in the cloud is not a solved problem
    4. Serious interest in alternative languages, both on and off the JVM
      1. There are lots of serious choices available in this sphere (scala, jruby, javascript -> node.js, erlang, clojure)
      2. Lots of enthusiasm for JVM, less enthusiasm for oracle’s ability or intention to be good stewards of it
    5. Though there were many very good sessions, especially in the Architectures You Always Wondered About track, in terms of sheer rock-star appeal these two presentations appeared to be the standouts that had everyone talking:
      1. LMAX – How to do over 100k concurrent transactions per second at less than 1ms latency
      2. Node.js

jdb: pretty f#*king useful

I rediscovered the joys of using Java’s built in command line debugger, jdb, today.  I’d gotten so used to using the graphical debugger in Eclipse that I’d forgotten all about jdb, but lately Eclipse has been choking on debugging projects with many maven dependencies for me.  I really needed a low-tech, high-reliability solution for debugging and going back to the old “add logging statement, recompile, run” routine was not the answer (yes, it helps in production, but in your own dev environment you deserve better).  jdb actually does the job pretty well.  It could definitely do with some improvements, like more shell-like line editing behavior and the ability specify to specify alternate init scripts at runtime.  But like the can opener on a Swiss Army knife, it will get the job done.



Last week, I wrote a quick-and-dirty GUI application to help my wife count down the years, months, days, hours and seconds until the end of her professional training.  I’m posting the source code, licensed according to the Apache License 2.0.  This is trivial stuff, and I coded in the most lazy fashion possible (no unit tests, very little thought for reusability, etc), so your mileage may vary.  To be honest, I was kind of reveling in the freedom to be unprofessional.  So much for that ethos of craft I’ve been going on about, eh?  Hey — just like the occasional candy bar, late night bender, or evening spent watching trash TV, the occasional tossed-off project is good for your soul.

However, it does actually work well.  It builds via maven in the usual way, and produces an executable jar as it’s final build artifact, so in true GUI fashion you can double click it to start.   Enjoy.