A few quick comments on the excellent paper from 1997, "Why Engineers Should Consider Formal Methods".
Here is my first attempt at putting together some thoughts on a computer science paper, in this case Jim Gray's A Transaction Model from 1980. It is an excellent paper which pushed me to think about my current work project in a broader light, and also inspired some ideas about potential future side-projects to experiment with.
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.
Genetic Algorithms are one of the most natural approaches to optimization. Did you learn about evolution in grade school? Then you already "get" GA.
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.
All Rights Reserved, Will Larson 2007 - 2014.