Every now and again, I try to do at least one thing that reminds me in a visceral way, just how much stuff I don’t know. I find no tool is more effective at this, than a coding challenge.
These days, most people bristle at the idea of a coding test, particularly as part of an interview process. There are some good reasons for this, but mostly I think people avoid these because It’s painful. It’s nausea inducing. It’s often embarrassing and sometimes leaves you sitting neck deep in a tattered mess of broken code and mixed emotions afterward.
But I’ve come to like these tests for precisely this reason. Not “like”, in the sense of liking Oreos or liking Star Wars. But “like”, in the sense of liking the occasional cold shower, or good hard slap. They sober you up. Coding tests are a giant wrecking ball crashing through the edifice of arrogance and complacency. They remind me that, no matter how smart I might think I am, there is still more to learn.
It’s important to be reminded regularly of what one doesn’t know. In addition to the reorienting value of a reality-check, It clearly points the way to new experiences and new challenges. Knowing what you don’t know, makes it possible to grow. And that makes all the difference for me.
The best coding challenges will teach you about what’s really important to software engineers, and will give you an opportunity to spend a little time in their skin, as it were. You learn what motivates them, where the corner-cutting impulses lurk, as well as what the worries about efficiency, architecture, and “clean code”, really mean pfizer viagra 100mg preis. It will give you a clear idea of what it means to write “buggy” code, the ways in which those bugs are most likely to occur, and how programmers try to deal with them. You’ll also learn about just how hard it is to build something both useful, and beautiful.
The implication I am leading up to, is that coding challenges provide an even more important lesson than humility. They offer an opportunity to grow your empathy for your fellow teammates. This lesson alone is worth far more, in my view, than even the coding skills themselves (although, those are important, and a subject for a different blog post). Empathy opens doors for communication, negotiation, and collaboration that were not available before. It changes the nature of your relationship to your teammates, and in doing so, ultimately improves the quality of the product by improving the quality of the lives of everyone around you.
This new found empathy reminds me that I don’t always know what is going on inside the heads of my teammates. And the humility of that realization inspires me to temper my relationships with curiosity and patience. And this begins a feedback loop of continuous improvement within my working relationships.
One important insight this feedback loop offers, is the knowledge of whether or not your teammates are willing to grow with you. This is vitally important for your own development. But more to the point here, it will tell you where the boundaries of quality are in the team, and in the product. These boundaries are the frontier you must press toward, if you are to have any lasting value in the organization.
The most important relationship you’ll ever have within any organization, is your relationship with yourself. By working to stretch your own inner boundaries, and being willing to bear the emotional challenges that comes with it, you’ll be leading by example and providing your team with a value that extends far beyond simple bug reports.