I’ve seen various posts from a diaspora of “entrepreneurs” that have resulted in nothing more than a cacophony of conflicting advice. Some of that advice was (in my opinion) bad. What better way to fix this than add my own!
I started by first business OmniTI in 1997 and then proceeded to found three other companies: Fontdeck, MessageSystems, and Circonus. I’ve been around a bit and understand the stresses of growing a company from nothing (no funding) as well as from taking rounds of financing and leveraging debt.
Open plan offices are bad. Breaking my concentration is wasteful. You hired me to code, so don’t interrupt me. I keep reading statements like this and feel compelled to supply a counterpoint. It isn’t that these are lies, it is that the are immature perspectives on a complex set of circumstances that clearly only represent a certain type of coder. In fact, I’ll claim that “coder” is either junior or selfish or both: immature.
Business is king. Customers rule. Service is everything. Yet every organization I go into has an engineering group that can’t see outside their bubble. Perhaps they can, but they certainly choose not to.
I’m an engineer, I write code. I’ve written approaching 100k lines of C code in my life time, I’ve administered tens of thousands of systems in my career and I’ve help plan some of the largest customer-facing infrastructure ever built.
Peaches and pecans on vanilla ice cream is a wonderful thing, but get some perspective on how you came to enjoy it. I have heard (and have told others), “life is too short to do something you don’t enjoy,” but the truth is there is no way to revel in everything you do at every moment; not even the most ambitious and determined hedonist can achieve this. While I don’t think he was right about everything, I feel confident Sigmund Freud nailed this one: “We are so made, that we can only derive intense enjoyment from a contrast and only very little from a state of things.
At OmniTI, I’ve been a part of writing a lot of open source software, my fair share of closed source software. Some of it has been shipped and some of it has been operated as a service. While it is possible (and quite useful) to take what one learns in one scenario and apply it to another, some things simply translate poorly.
I do a lot of consulting with traditional software companies that are looking to make a transition to the new world of SaaS.
Defining the term: I recently used a term and was hit with a lot of out-of-band requests for explanation. It’s a good one and excellent food for thought.
ywahusty (yuh-wuh-hus-tee): you will always have users smarter than you.
This basic concept is one of sound, pragmatic systems engineering that might appear to fly in the face of traditional product engineering… but doesn’t.
In traditional product engineering, there is a goal to produce a product that is both accessible and useful to the largest subset of the predefined audience of the product.
There is a pleasant dream where the world is black and white, problems are discreet, and solutions are straightforward. People that live in this dream are an obstacle unto themselves. The harsh reality is that we struggle daily to simplify things because they tend to be so complex. Most choices lead to outcomes that have both positive and negative aspects. This includes the choice of inaction (wrongfully referred to as "
