Building Technical Sophistication as a Developer

I first came upon this term, “technical sophistication,” in Michael Hartl’s article in Learn Enough Society. The basic idea is, as a developer, one requires a certain set of skills which can elevate their overall vision and can see things in a broad sight. One need not be technically proficient at everything, but having a good understanding of the fundamentals enables us to debug and reach a solution faster. Just by digging through error logs, searching efficiently on Google or open source communities (GitHub, Slack Channels, etc.) a developer with enough “ technical sophistication” can solve his/her way through a problem in less time with higher efficiency.

I didn’t start out as a computer kid. Growing up in a rural village in Nepal, I wasn’t even familiar with computers. The whole decision to pursue computer science and engineering was not even a very well-informed decision for me. Looking back, I think it was a perfectly fine decision and this field even seems to be in compliance with my personality and mentality or maybe I have adapted myself subconsciously. The whole point is, the higher the exposure greater the sophistication. You have seen a bit of it here, a bit of it there, a similar thing happened when you were doing X, Y does this ‘that way,’ and so on. Over the years what I have realized that there are a lot of things which can be learned only through experience. But a common problem (and I'm included myself here) is that developers do not enough experience.

I have realized that for late-bloomers like me, the sure abd fast way to build technical sophistication is to move faster. If you are a core Java programmer, as an example, do the following:

• Go to GitHub (register if you haven’t already).
• Take a language/framework/technology that is vaguely related to your domain/preference (let’s say Ruby).
• Find an interesting Ruby pet project posted by some hobbyist (there are plenty of them for any language) with a good readme for instructions.
• Go ahead and try to run that project on your system.

Note: This is just an example. The basic idea is to try and do something which is fairly unfamiliar to you. I have found that the end results are always helpful and insightful in the long run.

Now, one thing is sure to happen. It won’t be a smooth experience. You will face some technical challenges while installing and running the project. You will understand how this particular language that you have never used before manages its libararies. Hopefully, you'll work OSS related issues, too. You thought you downloaded the correct package, but, oops, it was a non-compliant version. You messed up your package structure and might have to uninstall some and install them again the proper way. In my mind, this is how you build technical sophistication.

Freedom in Software Engineering

The software engineering field is very appropriate for experimentation. The amount of freedom and experimentation that we software engineers enjoy can’t be exercised in any other discipline of engineering. The hottest field in the software industry today, machine learning, is in itself a glorified experimentation, although there are tons of sophisticated mathematical and logical heuristics behind it. How much do we actually leverage the fact that we can experiment with our code and systems with such freedom? If you want to be a sophisticated power user of Linux who really understands the system, and not just the commands, set out on a journey and install arch Linux (you know, on the weekends).

As a programmer, I am constantly reminded of how learning was for the first generation of computer programmers. They learned in a hostile environment, so to speak of, where there was a huge constraint on memory and processing capacity, both of which are in abundance today. Software collaboration has never been easier with tools like GitHub and other communities. Free and open source software (FOSS) has kept growing and flourishing and communities around it are very welcoming towards whoever wants to venture into them.

This essay is more like a note to myself that I should keep the joy of software engineering alive and explore more.