The title of the SEP Blog Battle for this week is “Weapon of Choice”, and I thought I’d provide what insights I have on the topic as it relates to Programming Langauges.
Origins for this Post
In an effort to more effectively convey my thoughts on the matter, I thought I would provide a precursor – a recommended read which may well serve as a better means to convey my thoughts. This essay on generalizing specialists, which I originally discovered via this post, has been a model for my technical skill development in my time out of school.
Apprentice’s Crutch
As an Apprentice Software Engineer I have my own weapon of choice to solve problems in the realm of Software development (C#), though I am aware of how this limits me. As a result of this limitation, I’m actively pursuing means that will improve my prowess in other languages (in fact, I have a running list of technologies posted at my desk to help motivate me to do so, but that’s another post). Beyond the languages that I use on as part of my work, I’m taking opportunities to learn languages outside of that realm, and though I’m focusing on other languages and technologies we utilize inside the company for other projects, that is mostly because these languages are therefore potentially more useful to my current career as a software engineer.
As a beginner – I rely on my (limited though it may be) expertise in my first real language to contribute as I grow further knowledge in a wider variety of languages. Though I believe I’ve exceeded the point at which I used my “hammer” (square peg -> round hole) of C# to force work items into the code base, I would still be approaching all problems this way, if I had never taken the time to expand my horizons beyond that first language and would therefore be a much less valuable asset to my company.
Would I more quickly be able to master the language if I focused on utilizing it? Yes, but the learning curve is steep at this point, and I would be unable to take some of our user interface tasks, due to a lack of knowledge in Javascript. I would also be unable to do some of our more data intensive tasks, due to a lack of knowledge in SQL. In doing some generalizing after gaining some depth in my first language, I am able to do some of our most complicated tasks in one language, and at least some of the simplest in the others we use. If I had focused on a single language, I would potentially be able to do all of our complicated tasks, but none of our others, and any software developer can tell you that the times when a true expert are needed throughout the course of a product life-cycle are extremely rare at best.
Master’s Arm
That said, having an expert available to spend some time is an extremely valuable asset – one worth seeking out and spreading around (so long as they aren’t spread too thin). The master utilizes this language as an extension of himself. He/She wields this language as a powerful tool, laying the framework upon which can be built. A master is sought for his expertise and instead of utilizing a hammer to force the problem into his known domain, the code created by the master adds to the net value of the project. Of course, a master has many tools in his belt, some more specialized than others, but each has its purpose. Just as when driving a nail, you wouldn’t reach for a screwdriver, the master knows which tool to use for the job at hand.
In Clean Code, you can find the following insight. “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.” Almost everything created by the master falls into that second category, and even if he/she is more of a specialist (which may or may not be the case), with this expertise the project couldn’t be in better hands.
TL;DR
As a developer, when you write your first computer program you’re using the least specialized tool known to man. Let’s say its a sledgehammer. As you get better and better, you unlock newer and more precise tools. So while the first program you created was like building a house with a sledgehammer; you slowly discover as time goes on that a hammer is more effective at driving nails. Eventually you’ll learn that you can’t build a house with nails alone, and your tool belt will grow to accommodate more and more tools – thus allowing you to undertake more and more complicated tasks. The more you write the better you’ll become.
At least, that’s how I think about it. I’ve noticed my techniques becoming more and more refined as I’ve grown as a software developer. All the while, I’ve tried to continually expand my horizons. As I spend my time at work on the same project, I continue to gain depth in those languages and techniques I’m using as part of my job, and while that depth isn’t necessarily a bad thing, I feel that each bit of increased depth allows for more breadth and vice versa, allowing me to be a more well-rounded developer. So while I still have my weapon of choice (and I no longer believe it to be a crutch), I am far from being an expert sought for his expertise. As a result, I need to gain other skills outside of my primary language to account for my lack of great technical skill to keep myself relevant and valuable as a developer.
