Becoming a real software developer, using SAS, or whatever

God spare me from the self-taught software developer who knows only the latest thing.

I’m not against the latest thing, whether it is react or ember or Python games on Raspberry Pi or whatever it is today. My objection is to the fallacy that it is the only thing or even the most import thing.  Let me enlighten you with why I am loathe to hire self-taught programmers no matter how many of the ‘most elegant’ techniques their example project showcases.

There are several things you learn as a grown-up programmer (which The Invisible Developer tells me I should not call myself because it sounds lower than software developer. Again, I ignore him. Do not be misled by this to believe he is not high on my list.  He just brought me a martini, with bleu cheese stuffed olives. )

What Self-Taught Programmers Aren’t Taught

If you taught yourself to code by some online coding school or watching videos or reading books from Safari O’Reilly that shows an admirable amount of motivation. If you already have some experience as a software developer and this is how you learned a new language, that’s great. Maybe we can hang out and work together. If, however, that is your ONLY source of knowledge and experience, probably not. There are a few things self-taught programmers are generally not taught simply because they are not working as part of a team.

1. Testing. Testing. Testing. I said it three times because it was important. I think  I will say it again. Testing. Testing. This is why I need the martini. If you are developing an application, you need to test EVERYTHING. If I had a dollar for every time someone told me, “I tested everything but …” I would never need to seek investor funding again, I would just pull money from the piles in every room in my house. However much you think you need to test your software, you are wrong. The answer is, “More.” You need to test it on other machines besides yours. I learned this from SAS code that ran on Mac (yes, there was SAS on Mac a very long time ago) but not on Windows or on Windows but not on Unix. You can’t look down your nose at those people who aren’t running Windows 10 because that is only half of people who run Windows and less than 20% of the total market. SAS is actually a good starting point for learning this because it runs on a lot of devices with few changes but you do need to change the LIBNAME and FILENAME statements, for example. Similarly, we make games now that run on Mac, Windows, iOS and Android . At a minimum, you need to do a separate build , but sometimes you need to make major changes. For example, Android has some limitations on app size that iOS does not. Test whether your software installs. Test whether it opens. Test the most basic applications. For SAS, this would be creating a temporary data set, reading in data with a DATALINES statement and doing a PROC MEANS. For our educational games, it might be playing all the way through getting all of the answers correct. Test extreme cases. For S AS this might be merging several enormous datasets, applying user created formats, calling macros to manipulate the data and then performing a multivariate analysis of variance.

   For our games, it would mean getting every single problem wrong and quitting the game and logging back in many times, maybe after every problem. It would include entering completely illogical numbers, say, that you had picked 9,145,087 berries and and seeing if the program really tried to put over 9 million berries in the baskets.

   I’m sure you can think of some more extreme cases, but you get the idea.

   I can’t emphasize testing enough. The problem with someone who creates applications on his or her own is that person understands completely how the software is supposed to work. Real testing includes things like wandering off the path in a game with the path clearly marked, “just to see what would happen”. It is having people enter “as often as I can” instead of male or female for sex.

   I once asked someone how he managed to test a game where the image that showed the key for deciphering the message was missing and he said, “I knew what the image was supposed to be.” This was not the answer I was looking for.

2. Debugging is most of your life as a software developer. Basically, you write code for a few minutes and then swear and debug it for hours. Once you have a little experience, you learn to test and debug as you go and never write huge blocks of code that you then find doesn’t work and you have to figure out where in there the bugs occurred. You will learn all types of tricks of the trade for debugging. These include, printing out the first few records of a data set to make sure it looks like you expect. With JavaScript it might be writing the value of a variable to the console. Either way, the point is the same, you are testing little bits of code as you go and seeing that the result is what you expected. You also learn to debug all the way through. With SAS, you might apply the statements you have written to a data set in the documentation and verify that you got the same results. With a game, you might collect all of the objects in a scene and then check that the variable recording the number of objects is equal to what you expect.

   In any program that you are writing, you learn to break it into modules and test each of those modules. So you are debugging it in chunks by writing out the values of some number both in small steps, say even after each statement if you are really running into problems, and also in medium steps, say, at the end of each S A S data step or procedure, or after the execution of each function.

   I’m not saying that self-taught programmers don’t debug their code because obviously they do. No one always writes code that works perfectly the whole time. What I am saying, is that if you are self-taught, you only know the debugging techniques that you have figured out for yourself, as opposed to picking up ideas from your colleagues.

3. A third part of being a grown-up software developer often missed by those who are self taught is how to document the software. Comments are your friend. I had a colleague who made fun of me for how much I would put comments in the code but when the next year we had to do a similar project again I could turn to him and say, “who’s laughing now, bitches?” I have never met the programmer who enjoyed writing documentation. I have met a lot of programmers who were happy they had written it. if you are always chasing the latest thing, you might not be in that situation where you need to revisit something that you did a year or two ago. If you are not part of the team, you probably are not worrying whether some nonexistent team member can understand your code. On the contrary, you might be trying some really cool new ideas just because they’re interesting. I’m not against that, in fact, I completely understand. However, you need to document those cool new things. And if you take the attitude, “well, everyone should be expected to know the function call to integrate Lua with PHP”, come here little closer so I can slap you.

Here’s why being part of a software development is usually a crucial aspect of your career progress – all of the things I mentioned, most people don’t really want to do. Testing isn’t nearly as fun as writing code. No one likes to write documentation. Everyone knows that debugging is crucial but it usually seems at the time as if putting in all of those statements to check every single variable’s value after every manipulation is so time-consuming when you are just sure it was correct anyway. When you’re on a team, you can’t get away with cutting corners and skipping the not fun parts nearly so much. You also realize how crucial those parts are when other people on the team have no idea what in the hell you were doing when you wrote that function or macro or nested do loop.

Sorry, but I don’t think a weekend hackathon is any substitution no matter how many prizes you won. Not unless you had to return to the same hackathon six months later and update the project with a completely new set of people.

I don’t want to leave you all depressed, though. So, I do have two pieces of advice. For the debugging part there are plenty of software conferences you can attend, and find sessions on tips for debugging software. you may also meet people at those conferences that you could end up working with on a team for some project interests all of you.

Blogging – is a great way to document what you have been doing. On this blog, and my other company blog, I often write down what ever I have been working on lately just so I remember when I run into a similar problem six months down the road. You’d be surprised how often I Google a question and one of the first answers that pops up is a blog post I wrote years ago.

Speaking of  games – check out Making Camp, you can get it here for free. Play it and learn stuff because maturity is overrated.

If you want to learn even more stuff, you can get a bilingual version of Making Camp for your iPad for only $1.99 and brush up on your Spanish like you always said you were going to do but didn’t