I’ve been in a Senior Developer role for a little while now; long enough to start thinking about how to convey the usefulness of experience to more junior developers. There are a lot of jokes in our profession about being really good at using Google, or copying and pasting from Stack Overflow. Humor is important (arguably), but I think there is something lurking below the surface that might be useful to address.
Searching for the Answer
I certainly still look up a lot of stuff, and I don’t think that will ever change. Of course, one of the first counterpoints that come to mind is that experience simply allows you to be better at contextualizing and filtering the results you come across while searching.
But perhaps a more important counterpoint is that the nature of what you’re looking for will gradually change as you gain more experience and work with a given technology day in and day out. Speaking personally, I’m not looking up very much about the nuts and bolts of C# on a regular basis anymore, and haven’t done so for a while.
Further, the nature of the results you gravitate towards will change over time as well. Documentation and blogs that go in-depth on a particular subject will become dramatically more valuable to you as you move beyond the basics. The first time I found myself looking directly at the EcmaScript language specification nothing seemed special about it until I thought about it in retrospect – that was a resource that would’ve been too specific to be useful for me earlier in my career.
There are some things for which the internet may not provide you with a useful answer. The best it may be able to do is give you some clues as to the nature of the solution you should be pursuing. These are frustrating times, no doubt. They also happen to be the most valuable times!
By this, I mean that you will remember the kinds of problems that you were forced to puzzle your way through on your own. Why is the employee time clock system crashing so hard when it behaved itself perfectly in a test environment under a simulated load? Why does a data gathering application crash after an arbitrary amount of time, but only when deployed on the target machine? How might you obtain a deep copy of an object represented by several tables without manually allocating every attribute to a new instance of that object?
Those questions pose scenarios from my own experience, and those scenarios were so specific to my experience that the best the internet could do would be to equip me with as much relevant information as possible, but it could not give me the solution. I came through these situations with so much more knowledge about programming in general, though the immediate issue I was trying to solve was specific to one particular problem. Analogously, if you run up a flight of stairs, a hill, and a ramp, then you’ve run up three specific inclines. But, you’ve also gotten better at running, in a general sense!
The most useful thing that experience across many projects has taught me is that writing code is the best way to get better at writing more code. That statement is almost laughably self-referencing, though, and doesn’t mean much without further explanation.
At some level, any time we’re writing code, we’re looking to solve a problem. In the course of writing a bunch of applications, either maintenance or greenfield, I would have a lot of time to stare at the screen and think really hard about just what it was I was trying to solve. I also had time to walk away from my desk, go home for the day or the weekend, and operate some sort of biological background processing on a given problem. Over time, I noticed that a lot of the same classes of problems showed up and I eventually developed my own go-to boilerplate, approach, or tool to solve them. Only when teaching a newer developer did I realize that I had an enormous amount of mental shorthand that I could explain and share.
The mental shorthand manifested itself in many “I’ve seen this before” moments, as I quickly solved an issue a junior dev was experiencing. The most important next step, in my opinion, was to provide useful context about why I did what I did. There’s definitely no reason to leave new developers in the dark, after all!
Most of all, what I’m trying to convey is that there is no substitute for experience. I distinctly remember getting my start in professional software development and how lost I felt. The very prospect of producing an entire application that people would then use, something that would be responsible for generating income or adding business value, was overwhelming. It certainly doesn’t feel that way anymore. It’s also useful to keep in mind that things will eventually become more clear if you keep developing and asking questions. The exciting part comes when you realize that this process never ends – you simply keep accumulating really useful things!
If nothing else, I wanted this to serve both as a letter to myself and a short word of encouragement to any other developer that might be feeling overwhelmed by the sheer depth of the profession. Experience will make it all seem so much more manageable!