In need of a muse

You often hear about artists having a muse, someone or something that inspires them and pushes them to excel at their craft.  I think that concept applies to programmers as well, although I've never heard someone use it in that context before.

muse

 noun

Definition of MUSE

1

capitalized :  any of the nine sister goddesses in Greek mythology presiding over song and poetry and the arts and sciences

2

:  a source of inspiration; especially :  a guiding genius

(Source: http://www.merriam-webster.com/dictionary/muse)

I've had a few coworkers over the years whose excellence and creativity pushed me to try harder and push further than I expected myself capable.  I do have a fair bit of intrinsic motivation that sees me through in their absence, but sometimes I wonder how much more I could be if those folks were still around to push me further.  I don't know exactly what it is that makes the relationship so special, and why it doesn't seem to exist for most coworkers.  In those special cases, the coworker just seems to get where you're coming from, but rather than serving as an echo chamber helps you refine and improve your ideas.

The first muse I can remember really pushed me to understand the performance characteristics of the code I was producing.  He understood the internals of the programming language we were using better than I did, and the things he brought up in code reviews helped me to start really considering what my code was doing under the hood.

In another case multiple coworkers actively disliked my muse, but for me, he always cut through the BS and pushed me to do a better job, which is what I personally needed.  He was able to explain what I meant to others so that we actually made the tangible improvements I'd wanted to see but couldn't adequately sell.  He had great ideas but often would not get much beyond the minimum viable product before moving on.  But seeing what he started, I could easily envision where it needed to go and was able to more fully flesh things out.  And then he'd build on the ideas I added.  And so on.  I've always been fairly microcosmic in my approach, and he taught me to look a bit more at the macrocosm.

A different muse was able to talk me through my ideas and whittle out the weak points so I could both better understand them myself and better explain them to others.  He would often just ask "why" and that required me to think more objectively about the issue.  He pushed me to not give up on making improvements to the system even when I was initially shot down by management.  He taught me the value of teaching others, especially those with more decision-making authority, about the value of my ideas, that ideas don't always carry the same weight to others as they do to me solely based on their merits.  He pointed out the flaws in my logic and made me rethink some misguided decisions of my own.  He helped me put things in context.

Maybe calling them muses is inaccurate, but to me that's basically what they were.  I miss them.  I miss how great I felt learning and growing at such a rapid pace.  I miss the rapid feedback we gave each other.  I'm forever grateful for their influence.  I hope I was able to be for them even a fraction of what they were for me.

I'm not dissing my current coworkers; they are great and I'm glad to be on the team I am.  We really are doing some cool things, and the company is far better to work for than any of my previous employers. I guess I'm just feeling a little nostalgia for unreclaimable moments of great influence on my career and life.

Sentiment Analysis and so can you!

I wrote a 3-parter for the Rackspace blog about our Sentiment Analysis sample application.  Mad props to Pankaj Channe (scoring algorithm) and Jeremy Arntz (UI) for working with me on it.


Part 1 (how to set things up):
http://blog.rackspace.com/how-to-twitter-sentiment-analysis-demo-on-rackspace-cloud-big-data/

Part 2 (Spark code):
http://blog.rackspace.com/behind-the-curtain-twitter-sentiment-analysis-demo-sample-app-code/

Part 3 (node.js code):
http://blog.rackspace.com/behind-the-curtain-visual-sentiment-results-with-node-js/

Software Development Best Practices Aren't

Every once in a while I hear someone mention, in relation to developing software, that we should follow "best practices".  I often wonder if the speaker is just couching their suggestion in vague language because they have no idea what it means or if they really think there is some grand list of "best" practices that everyone should follow to guarantee success.  Really, there's two types of programming practices: "hipster" (or bleeding-edge, unproven, ooh-squirrel, or whatever you want to call the new shiny) and "legacy" (the stuff the old guys do because it works, but it's boring, and really a lot of times it's kind of crappy, but it's a known evil).  I think there's some imaginary middle ground there where "best" lives, but it's such a moving target that nobody can hit it.  Just in my time as a developer, web development has gone through at least these "best" practices:

1. LAMP stack (Linux, Apache, Mysql, Perl)
2. LAMP stack (P is now PHP)
3. MVC Frameworks (Ruby on Rails, Django, etc)
4. Async all the things (memcached, node.js, nginx, etc)
5. MEAN stack (Mongo, Express.js, Angular, Nginx? - I forget)
6. Single-page apps
7. MSA (Micro-Service Architecture)
8. I could go on, but I won't

Which of those is the "best" practice now?  I honestly don't know.  I'm totally ignoring the insane number of client-side frameworks that have come and gone (prototype/scriptaculous, yui, dojo, jquery, angular, gwt, meteor, I'm forgetting about a thousand).  RSS was cool, then it was all SOAP, but SOAP was too complex, so XML-RPC, but wait, we hate XML, so RSS again, wait Javascript is easy and XML is basically a piece of garbage, so JSON, and why don't we just use HTTP for its designed purpose, so REST all the things!  Chroot works for sharing hardware, but no we should use VMs because security, oh wait VMs actually have a lot more exploits than containers, and containers are more performant, and ooh neat, Docker makes them not painful, and ooh Google uses containers. Configuration management for a fleet of servers is hard, so cfengine, but Perl is icky, so Puppet/Chef, but Ruby is ugly so Ansible/Salt, but centralized servers don't scale that great, so Consul/etcd. And service monitoring, and metrics, and distributed filesystems, and and.

Don't get me wrong, a lot of the things in there are neat and could definitely prove themselves long-term, but just given how quickly the community has rallied around some of them and then dropped them like Neil Degrasse Tyson dropped the mic on that clueless rapper just as quickly, I'd guess that you shouldn't be adopting half of them just yet.  And often the better technology loses to the one with better marketing, or the one that's easier to get started with. 

So, the next time you say "best practice" about software development, you might want to clarify what you think is "best".  But be prepared for a lot of people to think you're the dumbest person that ever lived because you don't use whatever pet technology they think has redefined the game.  Because that will happen if you work with other developers or engineers.

Remember, when people say "use best practices", what they really mean is "do things my way".  Software engineering is a relatively young discipline, and technology moves so rapidly that there is no "best" way.  Build it the best way you know how and try to learn a few new things in the process.  Get feedback via code reviews to learn from others with different backgrounds.  Try new things, see where they improve upon the old and where they fall down because they haven't had the time to harden.  Keep moving forward, but don't abandon everything you already know to work well.  That's really the "best" practice you can do.

Good luck!