Tuesday, April 28, 2015

Tabs! No, SPACES!! NO!!! TABS!!!!11111one..dot..

A recent discussion with my mentee touched on something I've been thinking about for a while. What's the difference between a scientist and an engineer? Scientists and engineers employ many of the same techniques and skills in their work. However, it's important to remember what a scientist does and what an engineer does. As far as I'm concerned, the simplest description is that engineers turn discoveries made by scientists into "something" useful. Scientists don't usually ship products. An extremely successful career in science may involve never shipping a single thing or perhaps one or two epic discoveries. The usual terms for an engineer who doesn't care about shipping a product are homeless, broke, or professor.

So, where are the major arguments in software engineering? Here's a few I've encountered and how I feel about them. (I'm not a journalist; I can offer up my opinion. Most journalists seem to offer up their opinion as well these days so whatever.) Of course, I try to temper my own opinions when discussing this with my mentee.

Tabs! No, SPACES! No, TABS!
This isn't as prevalent as it used to be. Other than at my university over 10 years ago I've only encountered it once in actual industry work. An engineer absolutely insisted on using tabs because one tab character took up less space on disk than four space characters. I prefer to be able to print code, open it in ANY text editor, or various other things that pretty much require uniform spacing -- which means spaces rather than tabs. The engineer who argued vehemently for tabs was also the kind of guy you'd probably expect to find hand-tuning assembly to optimize the E_UNIVERSE_HEAT_DEATH error handler mentioned below. In my opinion, one of those kind of engineers you wish would just stay in his corner mumbling about punch cards, FORTRAN, and the origin of the term "core dump."

Crystal palace coding
The idea your code (and everyone else's) must be absolutely perfect. If there's a trailing space at the end of a line it's not a NIT1 it's a giant catastrophe and "people could literally DIE if you don't fix this space at the end of the line." There's also the issue where braces go, how case statements are formatted, CamelCase vs. under_scores and other naming conventions, and numerous other horrible things that are completely swallowed by the lexical parsing stage of the compiler. Don't get me wrong though, there are good reasons to have coding standards and the dev team should also stick to the coding standards. However, since the end customer doesn't care about the coding standards at all there are probably better areas to invest which will surprise and delight the customer. The best part about these coding standards is once you switch teams or companies there will be an entirely new set of them and arguments why the new ones are the best...

Handling every single possible error case no matter how ridiculous. Sometimes I'll hear someone ask how code will handle something completely insane. My favorite is out of memory issues. "You should throw an exception if this allocation fails." -- Really? We should try to allocate an exception object after an allocation failed? How about if we just crash instead? Is it really all that bad to crash during a catastrophic error? Is someone going to catch that OOM exception and do something insanely clever with it so we can continue proper execution again? The much more likely case is the error will bubble up a few callstacks below and then someone will spend hours binary-search debugging the originator of the error code. That's an unbelievable waste of time just to adhere to someone's (I'm looking at you Bjarne Stroustrup!) ideal method of error handling. Sometimes I want to ask in response, "How do we detect if someone jams their penis into the CD-ROM tray? Should we define E_PENIS_NOT_EXPECTED and provide an appropriate message file to display helpful error text to the user? Can we DCR the CD-ROM firmware to detect illegal penis insertions?"

In summary...
I'll probably come back to this post and update it with new insights. It'll be fun to see how my views change over the years.

  1. NIT is short for "nitpick" in a code review. Something that certainly doesn't need to be changed unless you're churning the code again. Basically, I prefer it this way but I don't really care.

Monday, March 16, 2015

Amazon: Why not outsource?

I got this email from a recruiter. Not very many people I know have had a good experience working at Amazon. I wonder if this will get me on their "do-not-email" blacklist...

From: Jon
To: XXXXXX@amazon.com
Subject: RE: Amazon's XXXXXXXXXXXXXXXXXXXX team is hiring!
Date: Mon, 16 Mar 2015 21:40:49 -0700

[TL;DR: Perhaps Amazon should outsource their engineering work.]
Thanks for contacting me.  I think it's wise to always be on the lookout
for new opportunities.  However, I think Amazon has some great challenges
with respect to staffing.  Here's a few reasons why I won't consider a
position there at this time:

First and foremost, I LOVE my current job and the company where I work.
It would take quite a bit to pull me away.  Not just money, but something
interesting, challenging, and fun.  I'm challenged daily, I get to work on
things I genuinely believe help customers daily, and I'm passionate about
what I do.
Amazon doesn't have paid parental leave.
At least it didn't when I asked ~12 months ago. This speaks a tremendous 
amount about the culture of Amazon.  An employee told me most managers are 
willing to "let you work from home for a few weeks."  The fact that paid 
parental leave isn't an official benefit at Amazon gives me the impression 
that Amazon doesn't care or acknowledge I may actually have a life 
outside of work.  It's also pretty much standard at the top end of the 
industry to offer at least 4 weeks...  If it's not a company wide policy,
then the company wide policy is that it doesn't exist.  Policy dictates 
culture; much the same way it dictates results.
I've heard that Amazon pays so well these other benefits aren't needed. I
should take my larger salary and apply it to the benefits I want.  I feel
the culture this policy dictates is one much more suited to an outsourcing
contract than a long-term employee/employer relationship. 
Amazon's attrition is insane.
I remember reading an article which reported the average employee tenure
at Amazon is 12 months.  This doesn't bode well for anyone at the company.
For new hires, it indicates they might as well start their next job search
the first day they are hired.  For veterans it means they will constantly
be ramping up new hires and imparting all that tribal knowledge which
inevitably grows up around a code base.  Once the veterans are lost all 
that tribal knowledge may very well be lost.  Nobody will know about the 
easiest way to plug in new feature ABC into the existing architecture or 
fix bug XYZ.  So now even the company doesn't make out well in the end 
because the new hires are grafting features or bug fixes onto a code base 
with no guidance.  I don't envy anyone who must maintain the patchwork 
disaster of a system that environment eventually fosters.  The only way 
this isn't an issue is if the work you're doing is so thoroughly 
uninteresting that no real engineering is required and cookie cutter 
templates apply to all the work.  In which case Amazon should outsource.
When I asked a manager what the deal was with the attrition I was told 
that "Amazon hires such good engineers that other companies constantly 
steal them away."  Amazon wants the very best in the industry but the 
compensation and/or work environment is such that it sends them fleeing
in the arms of another?  I understand Amazon pays quite well, so it must
be the work environment.  This statement is either part of an HR script 
or someone has their head stuck somewhere it doesn't belong -- hopefully 
in the sand since the alternative is most unpleasant.
I ran a quick search of my LinkedIn connections for those having worked at 
Amazon or currently working there.  Ten of my contacts have worked there 
and only one is still working there.  I'll be generous and say that's a 
10% success rate.  Or perhaps I just have sub-par LinkedIn connections -- 
they are after all, connected to me...
Amazon's leadership.
The one and only redeeming thing about Amazon is the focus on customers.  
Amazon loves their customers.  It's clear in the service provided.  It's 
clear in the leadership principals published on the careers page.  It's 
even clear in the story I've heard about those "banged" emails Mr. Bezos 
will forward when a customer complains.  However, if Amazon has a "1 out 
of 11 found this career acceptable" review.  Where's the banged email for 
that?  How vocally self critical is the senior leadership team of their 
atrocious employee retention?  Or is that not really what the senior 
leadership team cares about?  Do they actually want a workforce that 
churns every 12 months?  Do they really care little for the work-life 
balance?  If so, why not outsource the work?  Amazon doesn't seem to want 
long-term employees.  If cogs in the wheel are good enough why not just 
outsource the work?
-- Jon

From: XXXXXXX@amazon.com
To: Jon
Subject: Amazon's XXXXXXXXXXXXXXXXXX team is hiring!
Date: Wed, 11 Mar 2015 22:19:18 +0000

Hi Jon-

I came across your resume today and was impressed with your experience 
and your education. I am looking for senior talent such as yourself to 
staff a new initiative for Amazon’s XXXXXXXXXXXXXX team. The position is
located in Seattle. If you want to be where decisions are made and solve
problems for customers I think this is a challenge you would really enjoy.
Amazon's culture has been a great fit for me and one I think you would like.

I would love to talk with you further. Can you suggest a time to connect?

XXXX XXXXXX  |  Technical Sourcer  |  Amazon 
E: XXXXXX@amazon.com  

Phone: (206) XXX-XXXX

Work hard. Have fun. Make history.

Wednesday, February 11, 2015

I'd rather...

While chatting with a coworker about C vs. C++ he pointed out I can read a helpful whitepaper to help code C++ in a manner which makes it "sane." My definition of "sane" when applied to a programming language is that no hidden and/or unexpected behavior occurs from a statement. Most of my day-to-day work involves kernel mode coding. In this case I want the most "sane" behavior possible. Unfortunately, now that I'm used to logical things occurring as a result of my coding I even prefer C to C++ for user mode or other utility coding.

For example:
This should not throw an out of memory exception. Before opening the whitepaper I wrote:

I'd rather fashion a knife out of a salt block with an open wound and then stab myself repeatedly in the eye until brain matter leaks out than read up on how C++ can finally be made sane if we only follow these 40 simple rules.

Well the jokes on me because when I finally opened the whitepaper it was 72 pages long.

Also, I'm in pretty good company: http://harmful.cat-v.org/software/c++/