clouds and compilers and startups

oh my!

stop holding your face so close to my face.

Media_httpdistilleryi_frpah

Taken at Home @ River View Landing
Posted
Views

Working at DuckDuckGo

So it's official, I work at DuckDuckGo!  I've gotten a lot of congratulations across a wide spectrum of mediums, but I've also gotten a lot of "how do you like it" and "how did you get it" questions.  This post aims to address working at DuckDuckGo, if you'd like to know why in Saint Peter's name Gabe picked me, see: ye.gg/inbound.

a hat trick 

First, I'd like to say that I've never done anything like this previously; working at DuckDuckGo is vastly different than (in my limited experience) any other place I've worked before.  People talk about wearing many hats at startups, and I too have experienced this before; but working at DuckDuckGo, you wake up and realize your whole wardrobe is made of hats.  At DuckDuckGo, hats are all you wear.

Today I woke up and realized we didn't get a discount we should have so I put on my financial-hat underwear.  I wanted to give some feedback to an API we use and put on my partner relations-hat on my left foot.  Gabe pinged me with a bug I introduced in our Punchfork integration on my dev machine late last night (wearing my insomnia-hat), so the debug-hat went on the right foot.  Then I found a bottle-neck in some core code from a while ago ... and having no other place to put the systems engineer-hat (not cold enough for gloves yet) it went on my head.  Working at DuckDuckGo is controlled chaos; and I love it.  

Story time! When I was in elementary school, it was clear to everyone that I had pretty fierce ADHD, and still have it now.  Then and now I combat it with a simple kitchen timer.  In grade school it helped me because I would start with a homework subject, put 30 minutes on the timer and start the pipeline.  When the 30 was up, I'd context switch to the next subject.  If I was having trouble focusing for 30, I'd mitigate it with a time decrease and recurse.  I still use this method to this day breaking it up into design and implementation intervals.  This method enables me to allocate my chaotic energy (entropy) into some useful work.

At DuckDuckGo, chaos and entropy are synonomous.  At least for long as I've been associated with the company, seeing people come and go, I've come to realize that how we harness this energy is based on mindset, where static tools arrive from an evolutionary cycle.

vision

This is super broad and gimmicky I know, but this company is an outlier.  So hear me out.  When I first started working on the core of DuckDuckGo (before I was hired) it was like entering Narnia.  It is a complex system.  One minute it was sunny and the next it was snowing and some bi-pedal goat was pissing me off.  Gabriel is a hacker, plain and simple; he get's the job done.  It's not always the prettiest, but it works and often works fast.  And yes, it has been a sink or swim kind of arragement.  But the best thing is, once your swimming or even just avoiding death, Gabe is all about learning.  To survive at DuckDuckGo you have to always want to be learning.  If something sucks or you can do it better, it gets replaced - period (hence evolutionary cycle).  Learning, working smart (more on this later), consistently trying to use things that suck less, and a zero-tolerance b.s. policy have served the company well.

trust

I know people at DuckDuckGo have my back and will do the right thing even if it's not in their best interest.  Enough said.

asynchrony and agility

Gabe and I are at different stages in our lives.  I stay up on 36 hour benders, but he has a whole family and a ton of responsibilities.  I'd be lying to you if I didn't say it frustrates me sometimes, but I totally understand.  To be honest, him being busy with other things has done more for me since it has accelerated my ability to be agile throughout the entire system.  We've grown to be a very asynchronous team with no explicit tasks.  If one person is sick the other person can pick up the slack, if one person is pissed off with too many emails the other can adjust.  It's really nice to know I can just stop everything else and ship something I've wanted to for a while and everything will be ok.  And if not, I'll know when I need to.  Having multiple mediums to broadcast share vs. direct share helps a lot too.  Skype versus Yammer etc.

get on with it... 

I'm really excited to be where I am at right now.  I have a lot of things to do and I really enjoy working everyday.  While the actual technical work is very rewarding (read challenging :) it's been fun getting to know Gabe and the rest of the team.  I expect to make a life-long friends from this job that I respect and can rely on.  In my roughly 1 1/2 years of contributions to DuckDuckGo I've learned a ton and expect to learn a lot more.  There is more to computer science than just understanding math, computer architecture and how to write a simple compiler or a driver.  I've come to understand that this company is going to give me one of the most important components to my career: shipping a product that I've helped build from the ground up.  It's one thing to work at a company and be told to spot-weld weaknesses in an I-beam all day, it's a totally different thing when you're boss asks you if you approve of the cement grade chosen for the foundation.
Posted
Views

and now back on topic....

now that those rants are out of the way expect stuff about Golang, Compilers, Crypto, and a dash of HPC

Posted
Views

damn you smartphone review!

Recently a common question I have been asked is "what smartphone should I buy".  This post stands to a) state my opinions and b) save me time in the future :).

There has been a lot of hullabaloo about which phone is the "best" phone on the market.  Since none of them do everything right (and since there is no answer to this) there is only one real thing that matters: what are you going to use it for.  Spending my time around engineers all day, I've seen them all.  Each owner raves about which phone they picked and the real reason why they kick and scream is because this helps to stifle the fact that they inevitably had to make compromises when choosing.  This post is not concerned with carriers, it is concerned with the technologies employed in the devices that make them specifically good for executing certain tasks.

RIM - Makez the Dataz

People who carry BlackBerrys (and like them) are constantly creating data on the go.  It is a hardcore communication device that is primarily designed to create and respond to content and then promptly get out of the way.  That's it.  Sure security could have been a pre-req, but now days everything is getting hacked into.  The BlackBerry is the get in get out phone that is capable of composing a long email on the go with minor frustration.  People just don't get them for Angry Birds or the latest social imaging app.

Android - I Can Haz Dataz?

Conversly, Android is excellent at putting data at the finger tips.  Sure there is the feel good opensource power to the people concept, but when you get down to what the platform really excels at, it's consuming data.  It was designed to be this way right down to the built in functionality.  What data you care about and it's presentation is totally customizable.  The browser resizes text to the width of the viewable display, services dance in the background polling and pushing data ready to notify you the second something new has arrived.  If confronted with the 3am unexpected "shit that condition I wrote yesterday should be an else if, now it could introduce use after free" wake-up call, Android might just be the thing to help you get back to sleep after reading a PDF or two.  I'm not saying the others can't do it, I'm just saying doing it on Android instead of going to the computer sucks less.

iPhone - I R Trendy and Pretty

The iPhone is without a doubt the easiest to use, prettiest platform on the market.  Users are often very satisfied and it shows.  The momentum behind Apple releases is that people like the new shiny, and it will also serve them for what they need (often being more than what they need).  The iPhone really shines because companies know that they are most likely to make money off the platform.  This really just leads to most mobile development companies deciding that, presuming you're within the bounds of the API, it is the correct platform to debut on.  This leads to all these new social applications and high profile games that just can't be found on the other platforms.  There are promises that they will come, but it's often six months to a year later.  If you like exploring new products instead of just sticking with your bread and butter, there is often no other real choice.  Again, their are outliers like Lightbox (which debuted on Android - very well I might add), but more often than not iPhone will see the new stuff.  The iPhone does a lot of things, but the fundamentals, be it hardware (keyboard) or software (services and tight integration), have to be so agnostic that it's hard to do everything just right.

These are just my opinions and I expect diehard fans to enumerate long lists of solutions for each case.  What remains is that the compitition amongst the mobile space is strong and that is great for the consumer.  Just because you read a blow by blow comparison on engadget about why a specific phone is best, doesn't mean that it is for you.  Just pick for your damned self and if you're fortunate maybe you wont have to.  And please please please realize that while the hardware is so great, the soul of these systems is the software.

 

Posted
Views

The Caustic Contractor and the Skittish Startup

Several of the start-ups that I’ve either consulted for or W-2ed for have employed contractors to write chunks of mission critical code quickly.  I am currently one of these programmers.  From my experience this is almost always a bad idea.  Often the start-up either is unable to hire a full time engineer or they simply think that they can get away without it.  Mobile applications have become a hot-spot for this kind of behavior since there are several platforms and each often requires a certain level of expertise to get the job done correctly.

 
As programmers we are taught early on (or learn the hard way) that a significant portion of the cost of any given program throughout it’s life span is attributed to maintenance (often ~3/4).  The inherent problem with inter-mixing start-ups and contractors is that often times the start-up will start with a given contractor and price the application as a project based piece of work.  Specifications are given and if it’s a mobile development firm a nice statement of work is drafted where and the terms, time, and total cost are agreed upon up front.  This usually looks and feels great for the start-up because the mentality is: “well we’ll pay 6k for this complete solution and that will be it!”
 
“LeBron! Late in the fourth! This could change the game!!! Oh no! He misses!! He missed it!  The Mavrick’s take the championship!”

Wrong.  When start-ups do this, they often only compound the cost of the application overtime.  API’s change, features are added, platforms diverge, and it results in one big spaghetti headache.

Let’s say for the sake of being optimistic that the contracted work really does help the company get to the next level.  The start-up was able upon, well, starting, to hire an iOS programmer full-time, but was unable to hire a programmer for the alternative platform and this resulted in contracted work.  Now that the company has gained traction and there are users of both platforms, iOS is tightly and neatly under control while the other platform is an orphan.  But wait!  We have traction now, we can just hire someone to adopt the other platform and run with it! Right?!

Let’s define a few terms before we continue.  There are contractors and there are craftsman.  In the tangible world, a contractor is usually responsible for one given thing, say laying drywall after the electrical contractor has already been through.  These contractors are certified, but they are also heavily scrutinized on their work by someone in charge that is capable of understanding all the facets of how a building goes together.  Alternatively, a craftsman is often a single person that is entrusted with a given project top to bottom akin to a skilled carpenter building a fine mahogany desk.  Starting to sound a little like Atlas Shrugged?  Yup.  Back to the world where the creative solution reigns.

The same is true of both worlds, there are more contractors to craftsmen.  If the application comes from a specialty firm, there is a vested interest in holding a maintenance contract with the company they are contracting out to.  This often results in custom frameworks, crazy design pattern usage, and logical obfuscation that makes it very difficult for a start-up to hire a full-timer to step in an take over that responsibility even if the new hire has been well screened (don’t laugh) for capability.  In this circumstance, it often takes the employee weeks of time to become acclimated to all the nuances of the application, he is at a distinct disadvantage and it results in a serious time sink.  Costs compound and the _new_ hire is already unhappy.  To get the ball rolling again, there is usually a hefty “refactor” stage, which really just translates to another few weeks where the application is rewritten.  This results in a lot of lost time most start-ups never saw coming.

The second, and probably more prevalent, situation is a single contractor writes the application top to bottom quickly and poorly.  No codereviews, no control, flailing of instance variables instead of properly parametrized functions.  Icky.  The problem is, that since the work is being contracted out in the first place, there is nobody at the start-up that will see the spaghetti code and subsequent freight train coming until the product is out in the wild.  A common manifestation of this can be found on Android.  The application actually does work in an extremely controlled environment, where controlled environment usually means something like: “Nexus” branded phones or Android >= 2.2.  In this case the author of the application just wanted to make some quick coin on the side and be done.  Upon termination of the contract, the start-up now has a huge new load of customer service to bear and the cost to benefit ratio of contracting this new platform plummets into the red.  Usually the platform is either abandoned for several months (read “pulled”) and if the company ends up being able to hire a full-time person everything is rewritten.

The final and rare case (mythical even!), is that a proper craftsman is found.  In the case of the prudent founder he understands that the initial cost will be higher, or better a retainer (~1/3 total cost) is put in place.  But what the founder also knows is that while the initial cost of the application is higher, the total cost is _much_ _much_ lower.  Here’s why.  First and foremost there is a sense of pride in the produced code.  Each piece just fits.  The craftsman isn’t reinventing the wheel with every file.  Blammo![1] there goes the Observer Pattern, because he knows about built in message passing facilities that Just Work.  And that isn’t the half of it sister.  This craftsman is here to stay until the company can _safely_ deprecate or hire him.  Oh, and he knows how best to deprecate himself when necessary.  Here’s how.  The new hire has arrived and since the maintenance costs of the project are way down the new guy has fun and exciting features to work on.  Better yet, since those costs are way down, there is still often some coin left to keep the craftsman around.  This makes the transition seamless.  A codereview system is promptly put in place and the new hire gets to work.  The craftsman is no longer at the wheel of the ship itself but looking at a map of the fleet.  From here the new hire is working on the exciting features with guidance from the architect.  Regardless if the hourly rate of the craftsman goes up by 50% the number of hours has been way down for a while.  The baton is passed, and that’s that.

To wrap-up I’m not saying that I’m better than anyone else or that I’ve reach enlightenment, because I’m young I still have a _lot_ to learn (Check out some of the Golang compiler specifically the goroutine and defer stuff[2]. Just wow.).  I’m just saying that I’ve been in this position (several times) where an application has changed hands so many times that it is impossible for the logic to be … logical.  A great way to hone these skills and become a better programmer altogether is to get involved in some well-maintained open-source projects where people _really_ care (up to and including color[3]) about what does and does not go into the repo.  It’s _always_ sad to see such great and creative ideas totally cranked because the founder was either penny-wise and dollar-foolish or too much was trying to be accomplished at once.  EOF

[1] http://catb.org/jargon/html/B/blammo.html
[2] http://research.swtch.com/2010/03/broken-abstractions-in-go.html
[3] http://catb.org/jargon/html/B/bikeshedding.html

 

Posted
Views