One of the most destructive ideas is that you can dig out of a hole by doing what you're already doing, but doing it harder. This doesn't work, but it does breed and kill your heroes, and alienate everyone else.
As become further and further embroiled in my current project cycle, I am starting to view everything in terms of feedback loops. Is the project working well? Feedback loops. The guy who is having trouble with implementing part of the system? Feedback loops. Effective communication between product manager and engineers? Feedback loops. Beyond merely being possible to view the world in terms of feedback loops, I've found it rather useful as well.
A look at the frontend engineer's primary pain point: product skew. While skew impacts everyone, it beats on the frontend engineer early and frequently. Think frontend engineer's have the easy half of engineering? Well, let's talk about that.
When things get bad, people start complaining about percieved social hierarchies. Few things piss off the already angry engineer like knowing they're less important than an architect.
The aim of a development group is to build business value. Building technical leverage is the focus on increasing the business value a development group delivers over time.
As the SocialCode engineering team pursues building technical leverage, one of the ideas we've been exercising is configuration driven behavior. This post discusses what configuration driven behavior entails, and why we think it's a useful idea.
Once again we're experimenting with a paper reading group for our engineering team, this time with more success than previously, albeit in an unintended direction.
My second paper review, in which I review Butler Lampson's Hints on Computer System Design, an excellent paper which takes a look at a variety of hints for good software engineering.
A few quick comments on the excellent paper from 1997, "Why Engineers Should Consider Formal Methods".
All Rights Reserved, Will Larson 2007 - 2013.