Monday, September 7, 2015

Myth of the Myth of the Uber Programmer


Try not to become a man of success, but rather try to become a man of value.
Albert Einstein

Is there such thing as an Uber programmer - one who is so talented, he or she is 10 times more productive than others on the staff?  Or is this just a myth and the gap between developers is really just one of perception or hard work?  Jacob Kaplan-Moss, one of the creators of Django, believes this is really just a myth.  He believes this myth creates stereotype that alienates potential developers who otherwise would be quite successful.  He bases his deconstruction of the Uber programmer on developer productivity and the difficulty in measuring it.   On this particular point I agree with him, it would be rare to find a developer who is 10 times more productive than most other developers if we use simple productivity measures (lines of code, User Stories, etc.).  But I do believe in the existence of Uber programmers who produce 10 times (or more) VALUE with the code they write. Not only do I believe they exist, but Jacob Kaplan-Moss is an Uber programmer by all appearances.  His users certainly feel his software provides great value.  Why should any other measurement matter?  Value encompasses all those characteristics we want in a developer: innovation, quality, and delivery.  What other KPI is able to quantify these?  This is why KPIs, stack ranking, etc. all fail to identify the best developers.  When you measure lines of code, you get more lines of code.  When you measure unit test coverage, you get more unit test.  When you measure hours, you get more hours.  When you measure value, you get more value.  Only one of those tells me who the Uber programmer is. 



Now the tough question, how do you measure value?  Value has 3 possible measurements: increased revenues, decreased cost, customer satisfaction.  If a feature set address one of these 3, value is achieved.  If it addresses more than one, then it provides transformative value.  There are developers who understand value and deliver on it time and time again.  You inherently know who they are and  when you have a mission critical application to be done, you do not pour over the KPI reports to find out who should do the work. You go right to the person you know will deliver value, even if you do not consciously think of it that way.  

Surprisingly value is the least discussed measurement of  developers and really all employees. Everyone who manages people should strive to identify the value brought by individuals and find ways to document it.  Once you can document value, you can get the recognition necessary to hang on to business critical employees.



Thursday, June 4, 2015

Why are smart TVs so dumb?


I find television very educating. Every time somebody turns on the set, I go into the other room and read a book.

Groucho Marx

Not so Smart Hub: My frustration with my so-called smart TV has reached a breaking point.  I have a Samsung TV and their Smart Hub software is awful.  Since Smart Hub is proprietary, the apps have to be specially written for it, so the quality is hit or miss.  The performance of Smart Hub itself is also sketchy at best.  Smart Hub updates all the time and I am always hopeful that this will be the version that works. But no it usually just means I have to reconfigure / reinstall the apps I use; that is if the WiFi connection works. Why Samsung spends so much money developing bad software is beyond me.  Do they think it is a differentiator when someone buys their products?  I can assure you it will be on the next TV I buy. 

The Solution: That concludes my rant on Samsung's Smart Hub. I hate it when people complain but provide no possible solution, so let me propose how smart TVs should perform.  Currently smart TVs are designed to be a television with some software that allows you to consume web based content.  It should be just the opposite. It is quite simple actually.  We already have the example in our pocket.  Our phones act as portable TVs (in a way) so why not duplicate that experience on the big black screen in our living rooms.  What I mean is the TV should be another device designed to consume web based content and the regular TV content should be just another app within that context.  When I pull up Netflix on my tablet, I can still browse the web in a separate window.  Why does it have to be an either / or proposition?

Its the Remote Dummy: Of course the answer is the remote control.  How will I move windows, click on icons, type text?  Let's face it the current remote designs are terrible.  Again the answer is in our pockets.  Why not mirror the screen on our phone or tablet via a simple app.  There are tons of these apps available already, but they mostly just duplicate the remote on your screen.  I have one of those already and I hate it, why would I want a virtual one?  What I want is my TV screen duplicated on my phone? Then it becomes a sudo touch screen for my TV.  I can do this through Chromecast screen mirroring.  This  should be the way I interact with the TV all the time. Just imagine how powerful this would be as I watched my regular TV shows.  Currently shows provide content while the show is airing, but I have to use my tablet.  What if I could pull it up next to the window running my TV stream? Imagine watching the live stats for a football game or scores from other games on the side.  I could also run multiple games at once, moving from one to another as I liked. It would be easy to navigate as I just move the apps around on my phone. And I could use my phone / tablet's keyboard for typing. That alone would be worth not using the regular remote.

Flip the Paradigm: One last big idea for those who find this interesting.  Companies could change the way they advertise.  Instead of commercials that interrupt the program, ads could be displayed next to the TV window and you could purchase items from your remote app while the show is running.  Following the lead of mobile games, product placement would allow for in program purchasing.  You like the geek shirt Sheldon is wearing on this episode of The Big Bang, just click on the ad and buy it.  It would not be that difficult to use episode metadata to feed the ad stream and those ads would be available even during the re-runs. The pizza ad make you hungry? Just click on it and order.  All without interrupting the program.

Everything I proposed is available with current technology.  As users, we are already very comfortable with the UX.  I imagine the amount of money Samsung spends on Smart Hub could be much better spent creating my vision of a smart television.  Then maybe my family could spend a quiet evening without listening to me swear at the TV, well at least until football season.




Tuesday, April 28, 2015

MOTO 360 / Android Wear Review

The first step in exceeding your customer's expectations is to know those expectations. - Roy H. Williams

I have been using the Moto 360 for about 4 months and I feel I have enough experience to now give a worthwhile review, although I think at this point most of my opinion is based more on Android Wear and wearables in general.  First the watch.

I purchased the Moto 360 for two reasons.  First, I am very
interested in wearables and I wanted to understand the experience as a user instead of just reading what others think about wearables.  Second, I picked the Moto because of its aesthetics. I did not want a something that looked liked a calculator watch from the 1970s. I am an Android guy, so there was no waiting on Apple's version of a 1970s calculator watch :-).  

My expectations were to have a tool that would reduce the number of times I pulled my phone out.  I wanted something that could provide the information I needed (i.e. who is calling, meeting alerts, etc.) at a glance.  Android Wear seems designed for just this use case.  It compliments, not replaces your smartphone. You might think the Moto 360 has a hefty price tag for to solve such a specific need, but based on the number of the interruptions I experience every day, it has been well worth the price.  

As I mentioned before I was willing to pay the extra price for the look of the watch.  I have received as many comments on the watch's appearance as its functionality.  That requirement ruled out purchasing a Pebble or one of the Samsung watches.  Once the now famous patch fixed many of the performance issues, the watch has worked great.  I did have a few glitches, but subsequent software releases resolved these issues.  Now the watch performs very well.  It is clear, responsive and performs the basic functions I want.  That does not mean it is perfect, but that brings us to Android Wear.

Much has already been written about Android Wear so I see no need to do an in depth analysis.  What I do want to touch on is what I feel is missing: user context.  Specifically, I want to touch the watch as little as possible. Think about it; a wrist watch was developed to provide the time at a glance.  Eventually a little more information like date was added.  Everything was available at a glance, not an extended period of holding your arm up and swiping through menus or interacting with an app.  Sure Google Now provides some of that functionality through voice and previous behaviors, but it still has a long way to go.  The watch (phone) needs to understand where I am in order to provide the right information.  

I have a new app Stocard which tries to do this very thing.  It stores my rewards cards; in a recent update, when I am in a store it gives me the option on my watch to open that store's card .  Exactly what I need and when I need it.  It is still buggy, but they get the idea.  Now the app or Android Wear needs to know when I leave the store.  Why should I have to swipe it away?  

By far the best app for the watch is Google Maps navigation. 
I am prompted on the watch prior to a turn and the direction notifications auto clear as I drive.  That is the model other apps should use in order to maximize the wearable aspect.  Calculators and games really don't hold my interest.
The latest version of Wear will at least allow me to hide the notifications with a flick. 

According to the app developers at Tesla, the Apple Watch will be very app driven. I think this will be a major flaw with the Apple Watch. After using a smart watch for several months, I cannot imagine using it this way. Every time an app requires me to touch the watch, the less likely I am to use it in the future.  


Overall I am very happy with the watch.  It significantly reduces the amount of interaction I have with my phone.  For that I very pleased.  I really like apps like Stocard and Maps navigation. I am excited about where this technology can go, but first developer have to break out of the mindset that the watch is just a smartphone for your wrist. 


Finally I mentioned the latest release of Android Wear and I would be remiss if I did not comment on one of the most important features in this release: Wi-Fi connectivity.  This sounds minor, but it will allow your watch to connect to your phone from anywhere.  This could lead to some very interesting apps.  I am anxious to see what developers will create now that this tether has been removed.

Wednesday, April 1, 2015

Open Letter to Third-Party Technical Recruiters


There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded. - Mark Twain

To All Third Party Recruiters:

As a follow-up to my Open Letter to Developer Candidates, I thought it would be appropriate to tell third party recruiters how best to get you candidates picked when submitting them. I feel a great deal of time is being wasted due to a lack of understanding about what is important to me as a hiring manager when I am hiring a developer.  The advice given is not meant to be insulting and hopefully it will not be taken that way.

Send good candidates, not gifts: Third party recruiters and their account managers spend a great deal of effort trying "build a relationship" with me.  To be blunt, this will have zero impact on the candidate hired for the job.  Once you are on the approved vendor list (just so you know, I have no input as to who goes on the list), the only priority for you should be finding great candidates. I refer all request for my time back to our in-house recruiters because I don't want to waste your time or mine.  Hiring managers who take you up on your lunch invitations are using you.  I appreciate the effort, but you are better off spending this time schmoozing highly qualified candidates. Those are the important relationships.

Pre-Screen means pre-screen: I cannot tell you how many times I have interviewed so-called pre-screened Senior Developers who could not answer basic programming questions.  This is infuriating.   You don't even need to know the specifics of the job to do a basic pre-screen. A developer claiming 8 years of Java experience should be able to explain polymorphism regardless of the job description. Your company has relationships with previously placed developers who can quickly screen applicants for you. If you test applicants, do it on site.  I can assure you that cheating is rampant. Submitting unqualified candidates does you no favors in the eyes of everyone involved.

Not all candidates are good candidates: Building on my last point, just because someone applies does not mean you should submit them.  No amount of coaching or resume cleaning is going to get them past the interview if they are not qualified.  You are better off submitting 2 good candidates rather than 8 bad / mediocre ones.  If you have a reputation for of bringing superstars, your submissions will move up to the top of the list.

Research the candidates:  Do a Google search. Find them on LinkedIn.  The good ones will probably have GitHub accounts. Read what they post on Twitter.  I am going to do all these, so if you don't want any surprises you should take 5 minutes to research your candidates online profile.  You will also begin to see similarities in the profiles of superstar developers.  I still get calls from recruiters wanting me to apply for developer positions.  It would be clear to anyone who spent 30 seconds looking at my LinkedIn account I have not coded in years.

This letter was meant to be taken as a positive guide to getting your candidates placed.  We both want the same thing, a position filled.  For this to happen, your candidate must be the most qualified and best fit.  From my perspective, third-parties spend too much time on building a relationship with me as opposed to finding superstar candidates.  I interview a great deal of unqualified candidates who should have never been submitted. It becomes very clear after the interview that the resume had been professionally scrubbed.  All this does is damage your reputation.  Bad developers are not going to slip through our screening process and they should not slip through yours.

Thanks and good hunting,

Real Steve Vaughn

Sunday, March 1, 2015

Open Letter to Developer Candidates

Resume: a written exaggeration of only the good things a person has done in the past, as well as a wish list of the qualities a person would like to have. - Bo Bennett

To All Potential Candidates:

As a person who hires software developers I felt it was time someone let you know why you are not getting job offers.  The market for developers is extremely tight and companies are in dire need for talented people, but for some reason you are not getting the offers you expect.  In order to save both you and I time, I have compiled a list of tips from the other side of the interview table to help you get the job you really want.

If it is on your resume, it is fair game:  This seems like an obvious point but it is surprising how many candidates cannot answer the most basic questions about resume items.  If you put it on the resume you better be prepared to discuss it.  The worst thing you can do is lie.  That might work in a different profession, but a technical interview is a means to measure your technical knowledge.  If you are misrepresenting yourself, it will come out. Finally, do not let a recruiting firm present you for jobs for which you are not qualified.  You will not get the job anyway and you might ruin your chance at future opportunities.

P.S. J2EE is now Java EE.  Change it on your resume.

Develop your skills:  Programming is a dynamic field.  The most desired skills are constantly evolving, but the excuse that your company is not using that technology is no longer valid.  You can contribute to open source projects, develop apps, operate a side business, etc.  At my company we ask developers what they do on the side; no answer, no offer.  This goes double for developers right out of college.  I don't care what projects you worked on in class.  What did you do when you went home? Come to the table with demonstrable skills.  All the best candidates have a GitHub account and are more than happy to discuss the code they have there.  Own your skill set and do not be bound by what you do on your job.

Be professional:  You don't have the job yet, so act like it.  Enough said.

Give me a reason to hire you: If I have an open position, I want to fill it.  Interviewing candidates and talking to recruiting firms can be a tiresome process.  Technical interviews take development time away from my team and an open position means diminished capacity on one of my teams.  These are both cost. Give me a reason to hire you; I want to.  We are talking because something told me you might be a fit for the job.  All you need to do is make me feel comfortable hiring you.  Many candidates think we are looking for a reason to reject you, but the reality is really the opposite.  Find your value proposition and sell me on it.

Answer the question I ask:  Sometimes I feel like I am talking to a politician.  I ask a specific question but get the answer to something completely different. I asked the question because I want to know something.  If you don't know the answer, say so.  Also, when I ask what your specific responsibilities were on a project, starting your answer with "we" is not answering my question.  It sounds like you are hiding behind other developer's work.

Have a passion for programming:  As mentioned before, the best programmers code on the side.  They do this because they love coding.  If you come work for me, you better love coding because you a going to a lot of it.  I like to ask candidates why they first started writing code.  The best ones have a very clear reason and usually started very young. Passionate programmers bring new and innovative ideas to the company.  We need these ideas to compete in the market place. If you don't love programming and are doing it for the paycheck, go work for a bank.

Hopefully this post will help you present yourself in the best possible light and land you the job of your dreams.  At the least it should make you a better developer.

Thanks and good luck,

Real Steve Vaughn


Monday, February 16, 2015

Orwellian Agile

There are some ideas so wrong that only a very intelligent person could believe in them. - George Orwell


Anyone reading this blog post is probably very familiar with Agile development and the Agile Manifesto The manifesto is intentionally short and to the point.  It is a counter to years of very complicated development processes used to try and control every aspect of development; usually resulting bad code, excessive spending, missed dates and unhappy users.  Companies have embraced Agile and by embraced, I mean have added layers of controls, analytics, processes, did I mention controls?  The results have been bad code, excessive spending ... well you know where this is headed.  I recently saw a document outlining a company's Agile process.  The document was more than 30 pages long and included a laundry list of standards.  These standards even defined the length of a stand-up and specified which order the Scrum Master should get updates (clockwise if you are curious).  Thankfully, the last item in the list declared that scrum teams are self organizing and should manage themselves.  Of course there  was not much left to "organize" or "manage" at that point.  I found the idea of a self-organizing team adhering to these specific standards as a great example of Orwell's doublespeak.  The funny thing is companies really believe they can be Agile, while still maintaining a command and control culture.

For agile to be successful, there is only one requirement - trust.  Command and control is the absence of trust. The document I mentioned needed only one standard, the last one.  Is is perfectly acceptable for companies to require some outputs from the teams, such as roadmaps, defect rates, etc.  These aid in planning and quality control, but dictating the internal workings of a team yields no positive results.  The actions associated with agile become rote steps that must be checked to satisfy the overseers.  Giving over control allows teams to excel and leaders to emerge.   High performing teams becoming self-correcting and anyone who slows them down can be quickly identified.  This results in a higher quality product and happier employees. But it does require letting go, something many managers find hard to do.  Realize that control breeds control.  It is a never ending process that eventually leads back to the waterfall.

Sunday, January 25, 2015

The Unified Theory of Resource Management

While the law of competition may be sometimes hard for the individual, it is best for the race, because it ensures the survival of the fittest in every department. - Andrew Carnegie

In most companies there is a constant competition for development and QA resources.  The fight to get the most skilled of these resources can be downright vicious. We all believe the best people should work on the most important projects, but what is "most important" can be very subjective. Often it is politics that takes precedence when making decisions around resource allocations. 

To further complicate things, now that these resources are sequestered in scrum teams or scattered geographically, having a full understanding of who is really good and who is not can be challenging. We are often reduced to relying on the opinions of others.  

These two task occupy a great deal of deal of time and money in organizations.  They destroy productivity as well as employee morale.  What if it were possible to clearly know who the best resources are and easily assign them to the most business critical projects? Fear not, I have created a method for doing just this; I call it my Unified Theory of Resource Management (UTRM). 

UTRM is built around one central tool: a quarterly resource draft. At the beginning of every business quarter, all development and QA resources are put into a pool to be drafted by the Product Owner / Scrum Masters of the different scrum teams.  The order will be determined by the team's impact on the bottom line (profit or savings) the previous quarter. Those with the greater impact will pick first.  Obviously the teams that are performing financially should have their pick of the best resources.

 The teams can draft any available person from the pool or trade their pick to another team for whatever they deem valuable (server space, office location, cash, etc.).

The immediate impact will be the allocation of the best resources to the most valuable teams.  Product Owners will prioritize their work based on the greatest financial impact.  Scrum Masters will be focused on their team's productivity and making sure to document the most meaningful metrics as a means to show productivity gains (cost savings).  Business sponsors will understand  (or quickly learn) the impact of not having the best possible resources and will accept their role in helping the team succeed financially. In other words teams will now be more strongly motivated to ignore distractions that come up in every organization.

The secondary impact will be the ease in which managers can identify high and low performers.  In fact the entire organization will clearly know who is who in the organization.  This will pertain to all employees as the draft order will reflect the success of Product Owners, Scrum Masters, business stakeholders, etc.  There is nothing like a public evaluation of a person's performance to elicit change.  A couple straight quarters of being the last developer picked should send a clear signal to the developer and manager alike.  The NFL is a great example of a public performance appraisal.  There is no hiding on a Sunday afternoon and if you don't perform you are gone.

This is a radical change and many people would not be comfortable in such a transparent and competitive environment.  But those who are comfortable would be very competitive and relish a challenge.  Quite frankly these are most likely your high performers now.  They are the ones who work best when the pressure is at its highest.  They are the ones you call when no one else can get the job done.  UTRM will allow these people to receive the recognition and rewards they deserve.  On the other end of the spectrum, those awkward conversations with a low performer, who has delusions of their own work quality, will no longer be a surprise.  It is impossible to argue with the results of UTRM drafts. Most would see the writing on the wall and move on.

UTRM takes Jack Welch's performance ranking to the next level by providing a transparent and uniform measurement which everyone can understand. It will only take a company brave enough to implement it to see just how effective it will be.

Sunday, January 11, 2015

Users are Idiots

     A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams 

1.       Users are Idiots: Keep your designs simple, because even the most obvious Use Case will be misunderstood. Imagine your users as a grandmother with ADD. Remember this, McDonalds put the pictures of their menu items on the register to simplify checkout for their employees; all of their employees still have to go through training.  

2.       Users are Idiots: Ignore their design suggestions.  If they had good ideas, they would be UX professionals.  Don't ignore their incessant whining because they do know what they don’t like.  Unfortunately, the gold nuggets of good design are hidden in those complaints. Listen to users when they explain what they do and then design the best possible interface to accomplish it.  Users are not designers and they should not design systems.

3.       Users are Idiots: Make no assumptions of any actual business knowledge.  Most of the drones simply do the same thing every day without a thought to why. When you change something (anything) they will complain.  They will ALWAYS prefer the old way, even if it involved physical pain. Expect this reaction, no matter the change. Just because users initially hate something, does not mean it is actually bad. Focus on making the task simple and the interface intuitive. If you accomplish these goals, your design will easily fit into their daily task and will soon become indispensable. 

4.       Users are Idiots: Never forget, we are all users. We all want systems that solve OUR problems without any real regard for the bigger picture.  This focus blinds us to the needs of other users.  Keep this in mind when you find yourself on the other side of the UX discussion. 

The purpose of this post is to define the role of a user in the system / UX design process.  I used a certain amount of hyperbole to make   my point, but with the growth of Agile development, a huge emphasis has been placed on receiving feedback from users as part of the development cycle.  It is important to keep a perspective on the type of feedback that is appropriate.  I have been part of product demos where users made design decisions.  This is a sure path to creating an piece of useless software to all but those making the suggestions.  

The user is critical to defining what it is they need to do; it is up to the designer to best define how to do it.  

Tuesday, January 6, 2015

Latest APP update

Finished the coding on Sunday, but I need to get it loaded on my watch to test.  I don't trust testing the sensor on an emulator.  The latest version of the Android Wear APP is VERY buggy and is inhibiting my ability to get the code on the watch to test.  Hopefully I can get some time this weekend and get it resolved.  I would like to test it out a couple weeks in the "wild" before uploading it to Google Play.