Crafting Code Across the Stack: 3 Benefits of Cross-Technology EngineeringPosted: July 7, 2011 | Author: yeeguy | Filed under: consumer internet, engineering, product management, social apps, startups | Tags: consumer internet, engineering, startups | 8 Comments
One of the engineers in my startup asked some thought-provoking questions in a hallway conversation today:
Should engineers own end-to-end implementation of features that cut across multiple layers of our technology stack? Or should engineers focus/specialize on specific layers of the stack and collaborate with each other to develop each feature?
I’ve repeatedly observed that small teams of developers run circles around large teams in every company I’ve ever been in. [Caveat: I focus on consumer internet software, so my observations will be biased towards that industry.] I have a strong preference for company cultures that encourage individual engineers to develop as much of a featureset as they can on their own. If there’s a front-end user interface to be created as well as a backend API required to support a particular feature, I’d like to see the same engineer coding it all. Obviously this isn’t always possible for either technical or personnel constraints, but it is the ideal in my mind.
Seeing that reminded me of the three main benefits of getting engineers to own entire featuresets, even (or maybe especially) if they cut across multiple technologies…
When an individual engineer works on a feature that they know is going to impact large numbers of users, they viscerally feel the huge contribution they’re making to their company (and society!). Nothing is more motivating than feeling like your work really makes a difference.
An engineer who really understands an entire featureset front-t0-back is able to grok critical dependencies between technology layers more effectively than a team of multiple individuals. I assert that the ability to see the whole picture enables the single engineer to more effectively write test cases, identify likely breaking points, and ultimately deliver higher overall quality code that is defensively coded against future commits.
This is a key advantage for individual engineers: the engineer who designed and coded an entire featureset on their own will be more likely and much faster to modify/iterate their designs when presented with market feedback from real consumers. In contrast, a team of engineers who each only coded parts of a feature (and therefore relied on some other person, usually a project manager or a product manager, to provide a holistic view and integration guidance) will be much slower to collectively process market feedback and iterate.
Now, this may all be much easier said than done… For one thing, it’s hard enough to recruit great engineers in any given technical area, much less a team of cross-technology superstars. And in practice, there are significant friction points to the lone-ranger style of development. E.g., if every engineer is a gun slinger they may unwittingly produce a lot of conflicting or redundant code that at some point needs to refactored. Furthermore, even if an engineer is capable of contributing code across many different levels of a tech stack, that doesn’t mean they will always *want* to do so…
Have you ever worked in a company that had a policy of “single engineer owns an entire feature”?
Three user-generated content UX principlesPosted: April 29, 2011 | Author: yeeguy | Filed under: Uncategorized | Tags: consumer internet, design, user experience | 1 Comment
Three UGC UX principles that I’m working towards in my products:
1) Fast — sub-200 millisecond response time to any user input
2) Assistive — give users something to react to; rather than forcing them to generate their own novel content
3) Learning — system improves with every user click or action
What are your top three?