What's taking so long? (a question every dev gets.. and even asks themselves)

Over time, my attitude and expectations as a developer have changed, sometimes in surprising ways. Some are pleasant, like realizing that with each problem solved, I can be more confident that I'll solve the next one too. It's not a matter of if now, but when. And that confidence pours over into other areas of my life. If I can solve a complex problem in a complex app tied to a complex infrastructure, maybe I can solve a problem on my car or home that I wouldn't dared to have attempted a few years ago.

Others are unexpected, like learning to value communication and documentation, things that used to seem like a time suck that got in the way of the real work. Or that writing code is only one part of the job of a software developer... and possibly a small part of being a team lead, but that's a post for another day.

And then some things don't ever seem to change, like that unsettling feeling that I should somehow be moving quicker, solving problems faster. And when I'm done, it's difficult not to look back and wonder why I didn't see the solution sooner, or understand the impediments earlier. What if someone asks me to justify why it took so long to figure a thing out? I might not have a satisfying answer for them... or myself.

The truth is, these things take time because... they just do. Most of us will work in applications that are years old, with tens of thousands or even millions of lines of code, written by dozens or hundreds of other developers. When we open up a project, we're wading through the minds of all those developers, the story cards of all those projects, and trying to make sense of everything that came before us. That ramping up, that ingesting of logic and layout and frameworks - entire little worlds made of 0's and 1's - takes time ..... and is invisible to everyone but ourselves.

Exploration and wrong turns should be an expected, even necessary, part of what we do. The less we understand the complexities of something, the more we tend to oversimplify it. The devil's in the details. Whatever problem you're trying to solve, if it came packaged in a neat little box you could just drop it in and be done! It takes time to go down this path and that one, getting the lay of the land, discovering and learning more and more about what's already there.

I was reading a piece on the Lewis and Clark expedition that happened over 200 years ago, and the opening paragraph caught my attention.

The excursion lasted over two years: Along the way they confronted harsh weather, unforgiving terrain, treacherous waters, injuries, starvation, disease and both friendly and hostile Native Americans. Nevertheless, the approximately 8,000-mile journey was deemed a huge success and provided new geographic, ecological and social information about previously uncharted areas of North America.

Despite setbacks and injuries and unexpected surprises, the journey was in the end a success. Our unforgiving terrain is the infrastructure the app depends on, that we must conform to. Our treacherous waters is the logic we're trusting works correctly, which is only as perfect as the developers who wrote it and the business folks that defined it. Our injuries are the bugs just waiting to rear their ugly heads when we happen to poke them with new code. Our starvation is that friggin forum thread where the only reply from 10 years ago is, "nevermind, figured it out!"

Maybe instead of worrying about things taking too long, we should more concerned with explaining why things are taking longer than expected. Maybe we're doing a little too much wandering. Or maybe our own President Jefferson, whoever that is, didn't understand nearly as much as they thought they did when they gave us a month to cut across 8000 miles of wild and untamed terrain.

At least Lewis and Clark could've texted a pic of that terrain... maybe tweeted some panoramic images of that harsh weather rolling in. Who could argue with their slow progress, when they could so obviously see what they were dealing with?

We don't have that luxury, when everything's in our heads. So maybe the answer is to get it out of our heads. Kanban boards and the like are one way to make things visible. Like explorers creating maps as they go forward, we could create our own style of maps too.. flow charts and network diagrams, visio docs and whatever else, to make the invisible visible.