Optimism is absolutely a double-edged sword. It can keep you motivated during difficult tasks, make you a better/more positive teammate, and encourage you to look for the better ways of doing things that optimists, by definition, believe to exist.
On the other hand, it's also the reason behind most of my missed deadlines ("Oh yeah I can do that in a week, no problem"), burnout ("I've got nights and weekends, I can take on this project"), and disappointing/unrealistic projections ("I don't want to slow myself down with research, I KNOW people are going to love this product").
In my previous role, I was paired up with a developer whose natural tendencies were to pessimistically look upon each new feature request like a minefield. Having someone to negate the negative aspects of my optimism was a godsend, and we had one of the most productive working relationships I've ever had. I would unfairly get a lot of the credit for my positive, can-do attitude, but I've never forgotten the benefits of having a healthy dose of skepticism on a team, nor the absolute havoc that an unchecked optimist (like myself) can cause.
we had one of the most productive working relationships I've ever had
Finding a dynamic like this is a treasure.
My version of it was working with someone who had an inclination to solve all problems on the "algorithmic level" so to speak. Every time we worked on a feature, no matter how big, he would start with the hard CS problems and never really leave that head space. I thought of it as a "bottom up" approach. I on the other hand always took the "top down" approach and focused most of my efforts on APIs and architecture.
In his view, if you don't correctly solve the "real problem" (the hard CS problem) then everything else will fall part. If you base your architecture on the wrong solution then your layers of abstraction won't make any sense.
In my view, you should take the naive approach with the CS problem and focus mostly on the interface and system level architecture. If the interface and architecture are a mess, your application is going to be a buggy mess everywhere else too (death by a thousand cuts).
At first working together was so painful! We argued about everything. Worse, we'd be arguing about completely different things because our points of view were so different!
As soon as we recognized our differences we became a well oiled machine. A new project came in, he focused in on the CS problem, I focused on the architecture, and we'd (usually painlessly) merge our solutions.
The balance was even useful when we worked on separate projects. I knew that if I had a very narrow complex problem
then I could come to him for a brilliant solution. He knew that if he got stuck trying to design a system with lots of moving parts that I'd offer a solid robust and fault tolerant systems level solution.
Another side effect of optimism that you didn't mention is that it makes it far easier to fall for bad tooling, libraries and patterns. I find most devs default approach to new stuff is wildly optimistic ("X will solve our problem perfectly", "X is popular so it must be good") and only positive outcomes are really considered ("We need to use X, Y and Z to avoid falling behind").
There's a lack of skepticism in general when it comes to tooling. Every one of those points is void of information without context because they each have a pessimistic counterpart that could be equally true. "X will introduce more technical debt than the problem it solves would", "X solves too broad of a problem and will bog us down with a huge API surface area we don't need", "X, Y and Z will provide negative value and we will miss an opportunity to outskill our competition", etc.
A lot of people, even senior staff, seem to forget that their job is about weighing pros and cons, or costs and benefits. In a lot of work places, mentioning the costs is seen as pessimistic or defeatist. You can see the imbalance by looking at the kind of language that's in vogue. I have a fair sort of a repertoire for accusing someone of being too skeptical of tooling ("reinventing the wheel", "why don't we just build it in assembly?", "10,000 people starred it on GitHub for a reason"), but I find it much harder to come up with opposing examples. The ones that are used aren't as widespread, and are more used as attributes of a codebase rather than as an assessment of someone's approach ("overengineered", "npm salad", "wrong abstractions" etc).
Love your post. On a guttural level-- At my last employer, I was known for rigorously exploring failure scenarios of our products and demanding they be mitigated.
After years someone asked why I was "so negative" and I said, I'm not negative, I'm, "planning for success."
The Nokia CEO, Risto Siilasmaa describes "Paranoid Optimism" as being prepare mentally for the most negative outcomes, and at the same time, be enthusiastic about the most positive outcomes.
I'm a fairly optimistic person and I run into the missed deadlines issue with anything non-work related with some regularity. I underestimate the amount of time something will take me or overestimate my ability to start the task.
At work, basically, if there is a monetary value attached to the task, I have no issue. I've tried to analyze this but it seems to come down to things that I don't really HAVE to do will get pushed because I'm optimistic they will work out, as they have in the past, and if they don't then there is no real consequence. Those that are work-related have a direct consequence, less income, so they feel more critical. I'm not a developer so it's easier for me to draw a line from my work to monetary value but this may be a perspective to bring up if you are working with a similar personality type in the future.
Comments
Optimism is absolutely a double-edged sword. It can keep you motivated during difficult tasks, make you a better/more positive teammate, and encourage you to look for the better ways of doing things that optimists, by definition, believe to exist.
On the other hand, it's also the reason behind most of my missed deadlines ("Oh yeah I can do that in a week, no problem"), burnout ("I've got nights and weekends, I can take on this project"), and disappointing/unrealistic projections ("I don't want to slow myself down with research, I KNOW people are going to love this product").
In my previous role, I was paired up with a developer whose natural tendencies were to pessimistically look upon each new feature request like a minefield. Having someone to negate the negative aspects of my optimism was a godsend, and we had one of the most productive working relationships I've ever had. I would unfairly get a lot of the credit for my positive, can-do attitude, but I've never forgotten the benefits of having a healthy dose of skepticism on a team, nor the absolute havoc that an unchecked optimist (like myself) can cause.
Finding a dynamic like this is a treasure.
My version of it was working with someone who had an inclination to solve all problems on the "algorithmic level" so to speak. Every time we worked on a feature, no matter how big, he would start with the hard CS problems and never really leave that head space. I thought of it as a "bottom up" approach. I on the other hand always took the "top down" approach and focused most of my efforts on APIs and architecture.
In his view, if you don't correctly solve the "real problem" (the hard CS problem) then everything else will fall part. If you base your architecture on the wrong solution then your layers of abstraction won't make any sense.
In my view, you should take the naive approach with the CS problem and focus mostly on the interface and system level architecture. If the interface and architecture are a mess, your application is going to be a buggy mess everywhere else too (death by a thousand cuts).
At first working together was so painful! We argued about everything. Worse, we'd be arguing about completely different things because our points of view were so different!
As soon as we recognized our differences we became a well oiled machine. A new project came in, he focused in on the CS problem, I focused on the architecture, and we'd (usually painlessly) merge our solutions.
The balance was even useful when we worked on separate projects. I knew that if I had a very narrow complex problem then I could come to him for a brilliant solution. He knew that if he got stuck trying to design a system with lots of moving parts that I'd offer a solid robust and fault tolerant systems level solution.
Ah, I miss it.
Industry rarely requires solving hard CS problems, can you share what kind did you guys encounter?Most of the times its APIs and database calls, iirc.
Another side effect of optimism that you didn't mention is that it makes it far easier to fall for bad tooling, libraries and patterns. I find most devs default approach to new stuff is wildly optimistic ("X will solve our problem perfectly", "X is popular so it must be good") and only positive outcomes are really considered ("We need to use X, Y and Z to avoid falling behind").
There's a lack of skepticism in general when it comes to tooling. Every one of those points is void of information without context because they each have a pessimistic counterpart that could be equally true. "X will introduce more technical debt than the problem it solves would", "X solves too broad of a problem and will bog us down with a huge API surface area we don't need", "X, Y and Z will provide negative value and we will miss an opportunity to outskill our competition", etc.
A lot of people, even senior staff, seem to forget that their job is about weighing pros and cons, or costs and benefits. In a lot of work places, mentioning the costs is seen as pessimistic or defeatist. You can see the imbalance by looking at the kind of language that's in vogue. I have a fair sort of a repertoire for accusing someone of being too skeptical of tooling ("reinventing the wheel", "why don't we just build it in assembly?", "10,000 people starred it on GitHub for a reason"), but I find it much harder to come up with opposing examples. The ones that are used aren't as widespread, and are more used as attributes of a codebase rather than as an assessment of someone's approach ("overengineered", "npm salad", "wrong abstractions" etc).
Love your post. On a guttural level-- At my last employer, I was known for rigorously exploring failure scenarios of our products and demanding they be mitigated.
After years someone asked why I was "so negative" and I said, I'm not negative, I'm, "planning for success."
The Nokia CEO, Risto Siilasmaa describes "Paranoid Optimism" as being prepare mentally for the most negative outcomes, and at the same time, be enthusiastic about the most positive outcomes.
My father use to always use this sentence:
"Hope for the best, but prepare for the worst."
I'm a fairly optimistic person and I run into the missed deadlines issue with anything non-work related with some regularity. I underestimate the amount of time something will take me or overestimate my ability to start the task.
At work, basically, if there is a monetary value attached to the task, I have no issue. I've tried to analyze this but it seems to come down to things that I don't really HAVE to do will get pushed because I'm optimistic they will work out, as they have in the past, and if they don't then there is no real consequence. Those that are work-related have a direct consequence, less income, so they feel more critical. I'm not a developer so it's easier for me to draw a line from my work to monetary value but this may be a perspective to bring up if you are working with a similar personality type in the future.
Nice. It's a good co-founder relationship too. I'm super optimistic and my co-founder is pretty skeptical, which is definitely a beautiful balance.