My dad is an engineer. Looking back, there was a dominant engineering atmosphere and attitude in our house. Of course, I didn’t know that, to me it was just normal. But my wife, who does not come from an engineering family, noticed it right away. It’s not all bad, nor is it all good, it’s just different. But I do remember hearing laments about how if there weren’t sales people, life would be a lot easier (a sentiment I no doubt have uttered at times as well.)
When I was 21, I was doing an extended internship and we were talking about some problem. I made some comment like “No way is that going to happen.” My boss and the others looked at me and said “You’re way too young to be that cynical.” I then explained that my dad was an engineer and they all responded with “Oh, well, that makes sense then.”
As I started my career, I was fairly pessimistic. I was no Debbie Downer, but I often doubted that timelines would be met, or that what our internal customers said they wanted was actually what they wanted. As I worked with more engineers, I saw that this was a common trend. We’d been burned in the past, and it had jaded us. As a group, in my opinion, we were pessimists.
But every once in a while, I’d come across someone who would say something like “I can do that in an hour. It won’t take long.” And I thought, “Wow, this guy must be a lot better than I am because that would take me a 1/2 day by the time I got all the way through it.” So my worldview began to change, maybe there were optimistic engineers. However, they seemed to be few and far between.
It wasn’t until this past year that I was able to reconcile the predominance of pessimistic engineers with the occasional, or even often, optimistic engineers. As a team lead, I’ve spent less time coding in the past year and more time clearing obstacles from my team, among other tasks. This has lead me to observing the team dynamics more than I ever have, and I’ve come to this conclusion: Software engineers are long term pessimists, but short term optimists.
What do I mean by that? If you ask a software engineer how likely it is that they’ll meet a deadline that is 6-8 months in the future, you’re going to get responses like “It’s possible”, “Maybe”, “Not likely”, “It depends” or even “No way”, and “I doubt it.” But ask those same engineers how hard the next story in the backlog is and you’ll hear things like “I should have that in PR today”, “I can overhaul that module in a week”, “Doesn’t look too bad.”
In the end, if you don’t recognize these differences, it’s going to cause confusion and frustration. For example, if you base your project health only on what the team is doing next, you’ll think “This is great, we’ll be done 3 months ahead of schedule.” However, if you base your sprint progress off of long term estimates, you might be left wondering if there will be anything to demo at the end of the sprint.