For me, programming almost always feels like working simultaneously inside two different worlds. First, there is the world in which we craft software. It is arduous work. The work that no one else sees. Nonetheless, it is work that most of us really love.
Second, there is the world that consumes our software. Our work is marketed, used, critiqued, and quite often bashed. For this, we need thick skins. Not everyone will love the product of our work. Many will find fault in seemingly obvious deficiencies. Software development is a tough job for the emotionally weak.
In the first world, we are mired in code. It is the underground world that no one outside of the development team knows much about, yet it makes everything we produce possible. This is juxtaposed by the second world, where we are judged by the end result of our code---that thin, top-level layer where interface meets user.
When the end result succeeds, programmers are rarely the ones showered with accolades. When a piece of the system fails, well then, of course the programmers are the ones stuck with the blame. Who else is writing that code?
The hard truth is that there is nothing wrong with this. This is the way it should be. It is simply the fate of the programmer. You have to love toiling away in the first world enough to make up for the emotional grind of the second world. Surely, the longer you do this, the more you succeed at producing good results. But, really, it's the fruit of the first world that keeps us interested, isn't it? There are far less mentally taxing things we could be doing with our time.
Most every process in a development team exists to mitigate mistakes. These include code reviews, writing tests, continuous integration, test harnesses around deployments, branching strategies, pull requests, and so forth. This too, makes complete sense. We are naturally conditioned to sift out all the vulnerabilities that come with our job. But, where does the recognition of a job well done come in? A bunch of green checkmarks on a screen only tells us that there's a good chance we didn't break anything. Not exactly the high-five or pat-on-the-back every human craves for succeeding in their craft.
This is why the culture of a development team is paramount to its cohesiveness. And a cohesive team of developers---one that has worked together for years---is paramount to the successful delivery of software to this second world. It is within our own development circles where we must remember to praise each other.
Laud the elegance of the code someone writes. Praise someone for their timely refactor. Keep each other's passion for writing beautiful code running high. At the same time, when something's feeling not quite right, huddle the team together and hash the issues out live.
Processes and tools usually get all the technical headlines. But, the emotional support within a development team is just as important. Nobody else understands your job as well as your fellow developer.
