This is something I wrote which was inspired by something jrgp (Joe) wrote up. I didn’t care for it but thought I’d write my take on a lot of the same points he touched on. His was originally entitled “What makes real programmers real programmers.” I wrote it up over the course of 45 minutes or so but still managed to start getting a bit tired towards the end, so please excuse me if it gets less coherent as you read on. Content in quotes are Joe’s words, not mine.
Some talking points of programmer/technical peoples’ attitudes -
1. “Understanding Microsoft’s talents and faults”, and understanding their roles in where Microsoft is today. As anyone technical knows, Microsot dominates most parts of the computing market. Some people may think that Microsoft is (and should be) the One and Only. Others think that Microsoft should be done away with, and Linux, BSD, or $OSOfChoice should rule the world. There are probably quite a few people like myself who started out knowing only about Windows, then heard about something called BSD or Linux, then thought that $OSOfChoice should be the only one and did things the “right” way and nobody else, and then settled into a position where everything seems to have its place. Starting out on Windows, I didn’t hear about anything else until someone at a computer programming “camp” for kids (~5th grade maybe) mentioned it to me, telling me how great BSD (specifically FreeBSD) was. He showed me some screenshots of a really pretty interface. I tried installing it once on an old laptop, but couldn’t figure out how to get from the plaintext interface to the gorgeous GUI he had. I gave up for the time being (I was maybe 15 years old at the time). Some people get stuck in a rut (in my opinion) at any one of those points. I have no reason to think that where I’m at now is the correct position, but it seems to be the most balanced and where a lot of the more successful people in the field end up. I don’t mean successful in terms of “makes the most money,” but successful as in “has the most stable and interesting jobs, enjoys their job and things the most, and/or overall seems to be putting their computing knowledge to the best use”
2. “Avoiding hungarian notation like the plague.” This is something Joe listed in his original draft. Not being a developer by trade, I admit I actually had to look up what this meant. I’m not even gonna bother touching on the matter.
3. “Not being afraid of GOTO statements. They have their place.” Same here, I don’t really care.
4. IDEs
Technical people have their environments they feel most comfortable in. Just like a choice of operating systems, some people feel like IDEs are the devil, some think that maybe they’re the best thing since sliced bread, and some people prefer them for certain projects but not others. Again, not being a developer by trade I don’t really care but can appreciate whatever people choose. When writing GUI apps in Delphi, VB or their more modern relatives I can see how it’d be pretty much mandatory to use IDEs since you need to physically lay out the forms and whatnot in order to get any real start in developing the application. At least, that was the case when I meddled with VB and Delphi from 1997 to 2006 or so. As for non-GUI apps? I can see IDEs being useful for managing a large codebase, but at the same time some people may not need or want that to help keep things straight.
5. Libraries and frameworks versus original wheels and in-house code.
Some people prefer to write everything from scratch thinking that they can do it better and faster than the developers that came before them. Most of the code I write is to just get a job done and not spend any more time on something than is necessary (not saying I do a shoddy job). The C++ STL is probably one of the better examples to use for this matter. In some cases you may want to write your own very lightweight doubly-linked list when your dataset is always going to be of a specific nature and you have found that the SDL’s implementation is too slow for a use case you’re banging on repeatedly. On the other hand, if you’re just managing some data and that’s not the core part of your application’s functionality, odds are that the STL, external libraries or whatever are just fine. Some people think it’s better to write all of the code for your application from scratch, either out of some undying need to be completely original or a misplaced arrogance that they can do everything better. Again, a matter of “to each his (or her) own.” I tend to use Ruby for a lot of the work I do. Recently I wrote a tool to help profile the HTTP load hitting our ad-serving frontend so as to help judge whether our performance-testing environment accurately reflected the real-life load we were seeing. To make a long story shorter, I used the hash implementation in Ruby and believe that I am having some performance/scalability issues with it when I start tracking tens or hundreds of thousands of connections through millions of captured packets. I have reason to believe the hashes generated don’t have enough buckets, so I’m going to pursue reinventing my own wheel for this niche case – either by using tries, tiered arrays, or my own hash table implementation. That said, Ruby’s base implementations provide the features needed for 99% of the tools and quick scripts I write in any given week.
6. Coding, commenting, indentation style
I have a feeling that amongst developers a lot of these matters are like the debates between emacs vs vi, top vs bottom posting on mailing lists and similar. If someone’s writing their own code just for them then it honestly doesn’t matter what they are doing. If the code is being shown to other people then it should be understandable or more preferably easy to follow. If it is being worked on collaboratively by multiple or many people then there’s a pretty good case for establishing agreed-upon standards/conventions that scale to the amount of code and number of people involved.
7. “Programming with money being the sole motivator encourages bad code.”
This was something on Joe’s list, hence the quotes. I agree with it. If someone is coding just for the paycheck, has no interest in the code or what it does, or coding as a whole — odds are that their code will be of a lower standard (by any metric) than someone who is passionate about writing high-quality, high-performance code. On top of that there are people who have an interest or some kind of investment in what the code is aiming to accomplish. These things said, this doesn’t apply just to coding, this applies to just about anyone doing most jobs imaginable. If someone is only doing a job for the money, they likely won’t do nearly as good of a job as someone with a personal interest in the job or the end goal.
8. “Also being a grayhat. Knowing how software vulnerabilities work with first hand experience.”
“Being a REAL PROGRAMMER, you not only understand the code you write but also how it affects the system on which it runs. You understand how hex editors and packet sniffers work; you know the ways of injecting DLLs and poisining memory address space; you are also quite good with a proper debugger. You take all this into account when you write your own program, and also while editing others’.”
This point is Joe’s, as is the quoted text above. While I disagree with his use of the term “grayhat,” I think that any coder should have at least a working knowledge of the layers of computing beneath that at which their application operates. I am at odds with the user of the term grayhat here because just knowing or having an interest in how security vulnerabilities are found and work does not make someone a grayhat. A grayhat, by my definition, is someone who does questionably legal things all or part of the time, as they persist to computing (a white hat being one who is always legal/on the up and up; a black hat being someone whose operations are ethically and legally dubious most or all of the time). I have seen a number of cases where developers or coders are writing network code but don’t understand how the network works. Or are writing code to do intense operations to a filesystem/disk/ without knowing how that hardware operates and interfaces with the computer. Knowing the vulnerabilities of a system really is a reflection on someone’s understanding of how something operates; to know something is insecure or not operating safely requires knowing first how that system is designed, intended to operate, or performs. This in turn determines how you write your code, how your code runs, and how your running code impacts the performance and possibly stability of the system it is running on. This is at least semi-related to why a number of courses at RPI start out with discussions of how fork bombing works when topics such as process management come up (which in turn leads to an interesting few days on the shared Computer Science remote access machines).
9. “Education alone is no where near as useful as self education and experience. ”
Joe’s words above, mine would be a slight variation: “Education or experience alone are rarely as valuable as a mix of the two.” I guess in this post there’s an emerging theme of “everything is good in some kind of balance” and this is no exception. People such as Joe are great coders and emerging developers. I was a computer-savvy geek through high school and my interests in networking and the like evolved on their own, and would have ended up growing even if I hadn’t gone to college or gone to RPI. The fact is that what I learned at RPI helped me understand important aspects of computer functionality, scalability, and other topics which in turn influence many aspects of what I still continue to learn, do and find fascinating. For people such as Joe and myself who may have done some programming leading up to college (and plenty of others that I have talked to and/or mentored over the past few years), one of the most important topics to be educated on is algorithmic complexity. Many teenagers keen in computing can tap out code, but few would pursue the knowledge on how to write efficient and intelligent code without a formal education on the matter (even if it just led them down that path). This is not only in regard to big-O notation, but things like the difference between passing by reference, busy waiting, forking versus threading versus blocking code, and easily a dozen other topics that aren’t evident to the hobbyist coder. Just the same, you can be taught “coding” every day but never really get anywhere until you start writing your own tools to accomplish real world tasks, participating in an open source project, or similar “experience.”
10. Getting the job done
Joe’s name for this last bullet was… less than savory to say the least. The gist of it really comes down to getting the job done. Over the past few years I’ve had my share of projects which have gone incompleted, and it doesn’t feel good to start thrashing between incomplete tasks. In my case the responsible thing to do was to give up some of them that I was not as well suited for (maintaining/developing the new Soldat lobby server codebase, for example). However really it is important to finish what you’ve started. My problem wasn’t that I stopped working on something because I hit a challenge, it was that I shouldn’t have taken on responsibility for that project in the first place. What I believe was Joe’s original point here was “Don’t give up on a project just because you’ve encountered a hurdle. Push on, keep going, get it done.” Just because there may be one small task of a project which is being problematic doesn’t mean you need to put the whole project down for good. The better solutions are to work on another part of it, or put it down for the night and come back to it the next day. The latter part in particular has helped me fix and complete projects on a number of occasions. Experience comes from completing tasks of ever-increasing magnitude and levels of challenge. If nothing got harder, then there would rarely be anything of value learned. Sometimes projects just seem to get dull after a while, which is a challenge in itself. I’ve had this happen to me plenty of times, but what it has really come down to is finding a reason to pick it up and complete it. For me this reason has often been “because I told someone I would do it”, “because I told myself I would do it”, or “because now that I’ve started I want to find the best way to do it.”
Now at the conclusion of this list I’m probably supposed to have something insightful to say. Really everything discussed above comes down to moderation along with a healthy mix of experience and education, cricital thinking and open-mindedness. At the surface it may not seem like these really relate to all of those points, but looking over them it really does, whether it is the experience you’ve gained working on computer-related projects, experience in the work place on an assembly line or at Taco Bell, education in college or from those around you. Granted I’m only 24, I have a lot to learn, but I have come to start recognizing the value that comes from working at different jobs, talking to different people (even unsavory coworkers from different backgrounds), and discussing differing viewpoints with others who are open to a good and thought-provoking conversation. I can only hope I continue to pick up more from the people around me as time goes on, regardless of who they are.
