![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sparrI often make the comment that "I can debug software written in languages I don't know" is a very hard thing to put on a resume. Recently I made this comment in the context of potentially applying for a job where an acquaintance works. She is somewhat technically savvy, and understood the thought I was trying to convey, but she was incredulous. It took me longer than I'd have liked to explain it, and I didn't do a very good job, so it occurs to me that this is a subject I could do with some thinking and writing on.
First, let's talk about debugging software. At the most basic level, this means the software is doing something it shouldn't (or not doing something it should, but that's trickier), and I want to figure out why and fix it. Maybe the software crashes. Maybe when I click Plus it does Minus. Maybe when it saves a file in format X, another program says the file is not in format X. Maybe it runs slowly, or skips steps that I expect it to take, or produces output that is not optimal. The problem could be any number of other things, but the core point is that I can see it happen and I don't like it.
Second, on the subject of languages that I don't know. I know, well enough that I can and have taught classes on, C, C++, ARM assembly, and PHP. Well enough to complete a task given a reference and some time, or to make a decent code golf showing, I also know perl, Python, Lua, javascript, Java, and a random assortment of other languages. Then there are languages that I only know anything about because I've had to deal with them once or twice due to the subject of this post, and some of the languages I listed above started in this category. I learned Lua while hacking on other people's WoW add-ons. I learned javascript while fixing broken websites.
On to the part about actually solving problems in unknown languages. Computer languages have things in common with each other, some more than others. With some accuracy it is possible to illustrate the evolution and relationships between languages (here, here, etc).
Languages that are explicitly and directly based on each other are the easiest example. If I already know language X, there's a really good chance I can dive right into code written in Visual X or X 2.0 or X++ and understand most of what is going on. Given a Visual Basic application (back in the 90s when I knew BASIC but not VB), I didn't really need to know how the GUI for the "Save" button works if the save function was misbehaving, and once I found the save function in the code it looked very similar to the non-Visual BASIC dialects I was already familiar with, and whatever the problem was had nothing to do with the Visual part. I started learning C++ by jumping into C++ applications (Mozilla was my first, I think) that I wanted to tinker with. I didn't know C++, but I knew C, and the vast majority of C++ code is also C code. When I encountered things from the STL, or any OOP, then I had to stop and learn something new, but I could accomplish a lot just by making C changes to the C-like code. After learning AutoLisp so that I could write scripts to automate tasks in CAD programs I found other Lisp dialects relatively easy to pick up, and Scheme wasn't much harder. I didn't learn those while solving problems, but I could have.
Beyond directly related languages there are language concepts and constructs. Control structures look similar in a lot of languages. If I don't know the syntax of a specific kind of conditional or loop in the language I'm looking at, but I know what the code does, figuring out the syntax is usually not hard. I know what "for(x=1;x<5;x++)" does in C, so when I see "for(1..4)" in perl in a function that I know does something five times I can assume (and check, now or later) that it does what I think it does. Some languages use {} to make code blocks, some use indentation, some use if/fi or while/wend, but in every case there is some recognizable bit at the top or bottom that says to me "hey, there's gonna be a code block near here" so I know to look for some lines that are differentiated somehow.
And, even when all of that fails me, I have the internet and a compiler or interpreter for any language is just an apt-get/yum/ports away. The first time I encountered "map" in perl, which was part of the first time I ever dealt with perl, a long time ago in a galaxy far far away, I was completely stumped. It is increasingly rare that I look at a line of code and have no idea whatsoever about what it does. In this case it was half because I hadn't encountered the map concept before (applying one operation or function to each entry of a list, one at a time), half because perl allows some unusual syntax variants that made it hard to tell what parameters were being passed. However, all I had to do was look up map in perldoc to get a bunch of great examples that made it very clear, and then I could tweak the code and make sure that the new behavior was what I expected to confirm that I understood the syntax correctly.
All of this comes together to form the skill that I can't put on my resume. I've learned almost every language that I know by diving into an existing program that wasn't behaving correctly (or I wanted to improve) and making the necessary change. I wish there was a way to convey this concept succinctly, because I think it's one of my most employable traits. Unfortunately I'm stuck hoping for the one in a hundred development jobs where management recognizes that being a good developer has nothing to do with the language being used, or for a chance to get my foot in the door somewhere as a PHP developer (note to self: pick up Django or Ruby on Rails, over half the jobs I didn't apply for today required proficiency in one of those). If anyone out there has feedback on how I can better describe this concept, or needs further clarification, please comment here or elsewhere or contact me privately.
First, let's talk about debugging software. At the most basic level, this means the software is doing something it shouldn't (or not doing something it should, but that's trickier), and I want to figure out why and fix it. Maybe the software crashes. Maybe when I click Plus it does Minus. Maybe when it saves a file in format X, another program says the file is not in format X. Maybe it runs slowly, or skips steps that I expect it to take, or produces output that is not optimal. The problem could be any number of other things, but the core point is that I can see it happen and I don't like it.
Second, on the subject of languages that I don't know. I know, well enough that I can and have taught classes on, C, C++, ARM assembly, and PHP. Well enough to complete a task given a reference and some time, or to make a decent code golf showing, I also know perl, Python, Lua, javascript, Java, and a random assortment of other languages. Then there are languages that I only know anything about because I've had to deal with them once or twice due to the subject of this post, and some of the languages I listed above started in this category. I learned Lua while hacking on other people's WoW add-ons. I learned javascript while fixing broken websites.
On to the part about actually solving problems in unknown languages. Computer languages have things in common with each other, some more than others. With some accuracy it is possible to illustrate the evolution and relationships between languages (here, here, etc).
Languages that are explicitly and directly based on each other are the easiest example. If I already know language X, there's a really good chance I can dive right into code written in Visual X or X 2.0 or X++ and understand most of what is going on. Given a Visual Basic application (back in the 90s when I knew BASIC but not VB), I didn't really need to know how the GUI for the "Save" button works if the save function was misbehaving, and once I found the save function in the code it looked very similar to the non-Visual BASIC dialects I was already familiar with, and whatever the problem was had nothing to do with the Visual part. I started learning C++ by jumping into C++ applications (Mozilla was my first, I think) that I wanted to tinker with. I didn't know C++, but I knew C, and the vast majority of C++ code is also C code. When I encountered things from the STL, or any OOP, then I had to stop and learn something new, but I could accomplish a lot just by making C changes to the C-like code. After learning AutoLisp so that I could write scripts to automate tasks in CAD programs I found other Lisp dialects relatively easy to pick up, and Scheme wasn't much harder. I didn't learn those while solving problems, but I could have.
Beyond directly related languages there are language concepts and constructs. Control structures look similar in a lot of languages. If I don't know the syntax of a specific kind of conditional or loop in the language I'm looking at, but I know what the code does, figuring out the syntax is usually not hard. I know what "for(x=1;x<5;x++)" does in C, so when I see "for(1..4)" in perl in a function that I know does something five times I can assume (and check, now or later) that it does what I think it does. Some languages use {} to make code blocks, some use indentation, some use if/fi or while/wend, but in every case there is some recognizable bit at the top or bottom that says to me "hey, there's gonna be a code block near here" so I know to look for some lines that are differentiated somehow.
And, even when all of that fails me, I have the internet and a compiler or interpreter for any language is just an apt-get/yum/ports away. The first time I encountered "map" in perl, which was part of the first time I ever dealt with perl, a long time ago in a galaxy far far away, I was completely stumped. It is increasingly rare that I look at a line of code and have no idea whatsoever about what it does. In this case it was half because I hadn't encountered the map concept before (applying one operation or function to each entry of a list, one at a time), half because perl allows some unusual syntax variants that made it hard to tell what parameters were being passed. However, all I had to do was look up map in perldoc to get a bunch of great examples that made it very clear, and then I could tweak the code and make sure that the new behavior was what I expected to confirm that I understood the syntax correctly.
All of this comes together to form the skill that I can't put on my resume. I've learned almost every language that I know by diving into an existing program that wasn't behaving correctly (or I wanted to improve) and making the necessary change. I wish there was a way to convey this concept succinctly, because I think it's one of my most employable traits. Unfortunately I'm stuck hoping for the one in a hundred development jobs where management recognizes that being a good developer has nothing to do with the language being used, or for a chance to get my foot in the door somewhere as a PHP developer (note to self: pick up Django or Ruby on Rails, over half the jobs I didn't apply for today required proficiency in one of those). If anyone out there has feedback on how I can better describe this concept, or needs further clarification, please comment here or elsewhere or contact me privately.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-01-22 04:40 am (UTC)no subject
Date: 2012-01-22 05:47 am (UTC)no subject
Date: 2012-01-22 08:54 am (UTC)no subject
Date: 2012-01-25 08:27 pm (UTC)Personally, I list programming competitions that I have won, and hope that can convey the idea. But lacking that, I'm not sure how I'd try to convey it. "Firm grasp of ubiquitous programming and debugging principles," or something like that, perhaps?
no subject
Date: 2012-01-25 08:27 pm (UTC)