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.
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.
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.
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.