Reflections on Dealing With Complexity
After spending just a year and a half reading and writing code, I’ve become very aware of how important it is to know how to work with (and deal with) complexity.
Like a lot of junior developers who are just starting their careers, my run-ins into more complexity that I know how to handle can feel overwhelming. Almost oppressive at the beginning. It’s easy to get lost in it, like a traveler without a map.
But, of course, as a junior developer, I learned that I can ask the oracle, the source of all answers: Google and Stack-Overflow.
A minute or two of googling and reading Stack-Overflow usually gives me enough information to take the next steps. But it also introduces me to concepts in software architecture that will take me a while to fully understand.
I thought it was as simple as turning right instead of left, but I needed to take a winding path full of choices I didn’t even know existed.
It’s still overwhelming, but I take comfort that the path exists. Other developers have been through here and carved the path before me, reduced the complexity of the task, so I can walk through it in a tenth (maybe even a hundredth or thousandth) of the time if took them.
I don’t know them, but I trust them.
Every time I write something as simple as
I’m walking on the shoulders of giants. And thanks to them, now that string is
converted to binary and stored in the memory of the computer I’m working on.
And in order to get there, it went through several transformations.
Transformations that I didn’t have to work on, or even understand.
When creating anything, I know I’m going to deal with complexity. That’s the job. Most of the time, the bigger part of the complexity has been worked on by the developers and engineers that came before me. However, I know the complexity will be there. I will face it and learn from it.
The more I think about all the things that are going on behind the scenes, the more I realize how complex everything is.
I heard Uncle Bob say once, I forget where, that programming is all about managing complexity. That’s the job of a programmer: to manage complexity. The more I learn the more I realize he’s right.
Thinking about complexity is making me a better programmer.
I find myself thinking “How could I make this easier? How could I make this simpler? What could I abstract away?“.
I think of all the countless abstractions that other programmers created to let me do things with a few lines of code that used to be near impossible before. Time being the only resource I know I’m not getting more of. Time spend coding these marginal but necessary things would mean time I don’t spend time with my family, or writing the code I want to write. I am very thankful to all these developers that wrote thousands of lines of code so that I could do in one line what they had to do in a thousand. Because of that, I also feel responsible for leaving a clear path for the programmers that will come behind me.
I used to be in love with the clever line of code that was as compact as it could be. No wasted character or space. Even if it meant that the line ended up being inscrutable. Now I realize that that line made things more difficult to understand, not only to others, but to myself. I was wasting time trying to understand what I had written. That’s not a good sign. As a new developer, I want to take on the responsibility for the code I write, making sure that it’s easy to read and understand, so that others can easily build on it.
One day, I may get to a point where the path in front of me hasn’t been fully formed, and I’ll then have the privilege of opening the path for others. If I work hard at it, I can make it so that others that come behind me will have a better experience moving through their journey, creating things that are beyond my imagination.