In b-school, we talk a lot about political risk - mainly in terms of emerging economies. The US government's actions are resulting in events that will heighten investor perceptions of political risk here too.
I implemented Bresenham's algorithm in ARM assembly on the gameboy advance based on reading his 'zen of graphics programming'. Great writer, the anecdotes at the beginning of each chapter really hooked me in.
Jack was my graphics professor. After taking his class, I realized that I was never going to be a guru in the subject. :( But I did learn that a v1.1 of a C compiler (Borland Turbo C) produced much slower code than the highly optimized Turbo Pascal, then at v4.0
I've written production firmware (computer engineering background). In my experience EE's don't usually write production firmware, but are responsible for writing non-production verification loops and code.
Usually a computer engineer or software person works with the EE who developed the board level hardware + ASIC engineers.
Of course, there exist EEs who are talented at writing software, but I wonder how often EEs are tasked with writing production code.
I was an embedded contractor for 8 years. It was a huge majority of EEs writing the production code at every company I worked with. I probably worked closely with about 300 engineers in that time, and fewer than 20 of them had Computer Science backgrounds. This was especially true in aerospace/defense, where I very well might have been the only CS guy in the (large) building.
And, no, most weren't "EEs who are talented at writing software" :)
I am an EE, and I wrote several thousand lines of production code for an airborne radar system. It wasn't even firmware; it was signal processing application code running in RTLinux on commercial server hardware. Our firmware was all written by EEs, though I ended up having to help the EE tasked with the C code quite a bit.
For example, if the firmware is controlling a device that does not typically include higher-level computer systems. For example, an ECU originally designed for a non-hybrid vehicle, there will likely be no CE/CS people involved.
This is an excellent framework Slava. Succinct and pragmatic. Thanks for sharing it.
As you state, a big problem is developing enough of an intuition about how to slot features into these buckets. Founder preference for given features can be a good thing, but we have to be aware of this bias as we slot features into these categories.
Slotting properly is especially important when you don't have many 'feature arrows' in your quiver due to a lack of resources, morale, etc.
The other side of this coin is in measurement - each feature is in some ways a test of a hypothesis. And you should have some idea of which metric matters and how a given feature will move the needle.
It would be cool to hear how you approach this for RethinkDB -- since you are appealing to developers, perhaps tracking how quickly devs move to a new version for example.