A colleague recently asked my opinion of the most desirable skill I looked for in a software engineer. Without hesitation I replied with the ability to learn new concepts, technologies and code. Basically the skill to “figure it out,” whatever it is.
This is an ambiguous answer, I know, but it’s valid. The ambiguity comes from the skill itself. It means having the ability to analyse a situation, be it a requirement, bug, or problem not yet solved, and come up with the mental plan to learn what you need to accomplish the goal. It is similar in mental processing to the way a running back decides to spin left away from his blockers, or the quarter back who decides to throw to the 3rd receiver underneath because most of the defenders have dropped deep with the wide outs.
Football anaologies aside for now. let’s examine what I’m trying to describe. Suppose you are give the task of writing a function that receives the path to a compressed file and a destination path and the function simply uncompresses the contents of the file to the destination. Sounds easy enough however you have never done that before in code and to add to the requirement, the files will all be using the gzip compression format. How do you go about it?
Of course I’m not going to go into detail, but this scenario should spark in your mind the steps you would go through to identify the libraries you need to to perform the function. The question is how did you know these steps, or did you know these steps?
This is one of those skills that is hard to teach. Of course you can ask someone, but the answer you get may not help, or the person asked may not have the time to help any more than “check out SharpZipLib” leaving you to figure it out.
This may seem to be common sense, and in truth it is, but it is still a skill and needs active development for improvement. How do you do it? Returning to the football example, the same way the running back or quarter back develops their vision of how to run or throw of course!
One of the best practice methods that I have used for years is simple. Always keep a side project going. This project should have a few qualities.
- It should be something relatively small.
- It should not be too important. Many of my side projects end up getting thrown out once I’ve learned what I wanted to from them, while others have evolved into great utilities.
- It should be something that is useful. It is always easier to work on something that you can see value in rather than something that is just a test bed, even if that usefulness is never completed.
- It should not be one of your primary projects.
- It should contain an aspect that forces you to use a new technology, pattern or library. Sure, you may be able to accomplish that decompression by using Process.Start() running a command line utility, but you should not do it! Force yourself to learn how to use that library to do it elegantly!
- You should abandon it after you have learned what you needed to unless the value in completing the project is large enough. This lets you move on to learning something new.
That last step is optional and it depends on the time that you have to put into it. In my situation it seems like there is never enough time, something I am sure a lot of people feel. I do not feel the need for closure on many of these small projects that I start. Frequently I know of or discover some utility or macro that is already available and stable enough to suite my purposes which frees me from taking the time to finish off the project and move on to learning something else.
Of course this is all the opinion of one humble developer. What do you feel is the most valuable skill for a software engineer. I would love to hear what you think is important.