Business and salespeople are optimists. Well, perhaps that’s painting with too broad a brush. Maybe it’s safer to say that, at the very least, their jobs require some degree of optimism regarding the raw probability of things like a sale closing or a business venture succeeding.
On the other hand, programming is an inherently realist (if not slightly pessimistic) endeavor. Well, maybe that’s painting with too broad a brush again and it’s safer to say that it should be a realist if not slightly pessimistic endeavor. (If you’re skeptical, just spend some time working on a behind-schedule software project and you’ll very quickly get in touch with your realist/pessimistic side.)
And what is the constant tension between business/sales and the dev team? How often as software engineers are we asked to help with setting deadlines or estimates for software deliverables? For me, it’s a weekly if not daily occurrence. And, nine times out of ten, business and salespeople would like things completed yesterday and often want to talk about best-case scenarios.
In my career as a software engineer, these discussions have often left me with a queasy stomach – I’ve often both been asked for an estimate and to agree with a predetermined estimate practically in the same breath. In the past, this has caused me to feel bad about myself both as a professional and as an employee. Why do I so often come away from estimation sessions feeling like all I did was drag my feet? Why was everyone else so confident painting the ideal picture and all I felt was apprehension?
Honestly, I think it’s because:
- I work with really good business and salespeople who are inherently optimistic about their life and work. And,
- It’s a sign that I’m probably a decent if not good software engineer. This means I’m a realist if not a bit of a pessimist.
So what it really boils down to is the fact that our jobs pretty much require that we approach situations and tasks from completely different mindsets. And I’m realizing: This is OK!
If I were an optimist about my work it could lead to some dangerous behavior like a lack of thorough testing or trying to cram too much work into too little time. On the other hand, if business and salespeople were as realist as I am, it’s doubtful that they’d even bother getting out of bed in the morning.
This is probably why I have a business degree but I’ve never enjoyed business. I can’t dig deep into my soul and find optimism – I tend to think about all the ways things could go wrong. But, on the other hand, and when balanced with other positive traits, I think this fact about myself does help me deliver high-quality code that is generally pretty bug-free.
So yeah – to any realist/pessimistic software engineers out there, don’t feel bad for not seeing the world in quite the same light as your often more optimistic business and sales colleagues. When presented thoughtfully and respectfully, your insight and feedback is very valuable.
And don’t neglect to learn from the optimists either. They can help you realize that risks are sometimes worth taking and that you’re often capable of a lot more than you might think if you just keep at it and don’t give up.
I can give you some suggestion, it is not about “optimism”, it is two unrelated worlds.
Basically the sales people don’t care about the product or service they sell, then they don’t care about you and your work.
They can move from selling software to selling fridges or boats or, I don’t know, ice creams. What they do care of is the “situation” in which they can “make some business”, sign some “deal” or even build some “relations” that can pay afterwards for they own personal interest, for example when they jump from selling software to selling boats. Note that companies are usually managed by sales people, so when the company fails employees and stake holders lose jobs and money while management and sales have already jumped elsewhere. With bonuses.
The product or service (software, fridges, boats, etc) is just one of the “excuses” that bring people together in the context of that “situation”. The most fun is when “sales” from your company meet “buyers” (who are just a different kind of sales, the mirror image of your people). Both ends don’t care of the product or service, they care only about the “situation” where they meet and make some business. Note that they don’t even care who gains and who loses, basically because they are not judged by medium or long term consequences of those deals.
Features you have in your software and the timeline are just more excuses to have some meeting, talk, build the “situation”, move it back and forth. Since they are just talking of software while thinking totally unrelated things and both sides don’t care what the software is, what it does and so on, they write down un-realistic stuff knowing the actual product or service will be something different and/or will not meet the ends.
Actually it is some sort of miracle that things more or less work, banks don’t lose money somewhere, planes don’t fall from the sky, cars don’t come out from factories with 3 wheels instead of 4. My guess is things more or less work because after the “sales meeting” technical people on both sides are forced (forced because technical people hate people and when left alone they would not speak with the guy next to them) to communicate and one end provides something that resembles what it should be and the other end hammers that thing into production. There is always something missing, something that breaks badly, deadlines are not met but things somehow keep moving on. They say you should never walk in the kitchen of the restaurant, because you don’t want to know what the cooks actually do there. The same thing goes for software.