Jon Daniel dot Net

I came across some “interesting” code today at work, and while I can’t share the actual code snippet I can share something similar. This is what I call 1337h4×0r code, because it works by basically subverting the intended use of the control structure.

1
2
3
4
5
6
7
8
9
10
11

if(($ok = $obj->Check1()) !== true) {
} else if(($ok = $obj->Check2()) !== true) {
} else if(($ok = $obj->Check3()) !== true) {
} else if(($ok = $obj->Check4()) !== true) {
} else if(($ok = $obj->Check5()) !== true) {
} else if(($ok = $obj->Check6()) !== true) {
}
 
if($ok === true) {
  //then do some stuff.
}

Upon first looking at it, I wanted to cry because of how unreadable it was, but after some code review I had a basic understanding of what was trying to be accomplished. Quite clever, but here is how I would have achieved the same result, and a bit more down the 1337h4×0r lines.

1
2
3
4
5
6
7
8
9
10
11
12
13

$ok = true
$methods = Array("Check1","Check2","Check3",
                 "Check4","Check5","Check6");
foreach($methods as $method_call) {
    $ok = $ok & $obj->{$method_call}();
    if($ok !== true) {
      break;
    }
}
 
if($ok === true) {
   //then do some stuff.
}

Why do I get that feeling that in PHP 6, this will all stop working?

A common problem with software engineering is that after someone spends so long on the job they begin to get a bit too comfortable in their ways.  This is epically common is smaller organizations where the development team may be made up of one or two individuals, but it can also occur in larger shops where the focus is shifted on finished the project and not nessisarily finishing it well.

While existing methods and practices may get the job done, they are usually outdated and inefficient compared to newer techniques.  Unfortunately it can be quite difficult for an engineer to be able to properly stay informed because of how broken and scattered the software engineering community exists by it’s very nature.

The first, and easiest method of keeping engineers informed on new techniques is to arrange a “tech-talk” program in your organization.  Basically, once a month the engineering staff meets to discuss a new piece of technology.   The best way of arranging this is to have a “tech-talk leader” assigned each month and their job is to be in charge of researching and presenting this new technique.  Topics can range from different styles of design patters to new features in the next Linux kernel, basically anything that will get people interested (and maybe even a bit excited).

The second method is to get out and join some kind of professional group.  Find and local users groups and try to attend some meetings or get involved with some activities.  Linux, PHP, Java, C#, Perl, Python all have users groups in just about any city so finding one shouldn’t be too difficult.  If there is nothing in your area of interest then feel free to stay your own.  A sense of community among IT professions will only help increase your potential.

Another method, and by far the most useful, is to find an open source project you would enjoy working on and start contributing.  The best way in better yourself is by peer evaluation and review, and what better soruce of (not work) evaluation is there than the general open source community.  While people may take things a bit too far sometimes, it should always be considered in good nature.  And what better experence is there than to contribute to a piece of code which will be poked and prodded by the entire community.

In my opinion, one of the biggest problems with the software engineering community in most cities is lack of community.  Nobody really seems to communite and get involved outside of their social circles, and that does nothing but hurt everyone.  Go, meet new people, start new groups, talk to a professional you normally wouldn’t assoicatie with (.NET and Java developers I am looking at you), and most importantly… learn!

One of the biggest problems with programming in general is that it requires a great deal of concentration on a personal level. Even the slightest distraction can completely throw your “code-fu” and cause a great deal of lost productivity. Throughout the time I’ve been working I have noticed a lot of disturbing trends that have taken place and many of them are causing massive amounts of productivity to be lost.

The first, and most solvable problem is giving a programmer a task, but not explaining to them what is needed for the final deliverable. Anytime you are given a task like this I would highly recommend you immediately stop and not write a single line of code until you know exactly what is required of you. If the party assigning you this project cannot fully explain what is desired than you should immediately begin questioning if this is the best use of your time. If not even the client knows what they really want then there is no real purpose in working on that project.

Secondly, if you are anything like me, than you are probably distracted by shinny things. Such as, when you hear the IM sound you probably feel the urge to respond immediately. This can be a major killer of productivity, so my advice to any programmer is to shut off anything that creates an unwarranted sense of urgency. Coworkers can e-mail you or walk over to your desk, friends/family can wait until later and will call you if it’s truly an emergency. I have found that when I don’t have Pidgin and Thunderbird open I am much more productive because I have much less to take my focus away.

Lastly, maximize all your windows! Some people refuse to run their web browsers / development environments in full screen but I’ve got to attest to their productivity gaining values. The old phrase “out of sigh, out of mind” really works here. If you are working on a peice of code, then you really should be looking only at that piece of code. When you have many visible windows open at any given time you mind will inadvertently start looking around the screen. Maximizing your windowns will save you from this because you can only look at one thing at a time.

Not too long ago I was sitting in my dorm room working on a paper and it dawned on me that within the next year I would be a professional software engineer. Now this was no uncommon occurrence for me, seeing as how every few months I still can’t believe it’s the 21st century. But this time a feeling of pure terror struck me, because I felt that I knew nothing about computer science. Sure I knew a bit of C, some more C++, a dash of Java, and some decent PHP skills, but not much else. Fast froward six months later and I was working (and become quite proficient) as a professional software engineer. So for all you up-and-coming software engineers, here are some of the thoughts I usually had in college, and how they turned out in reality.

1. I only know one language, I’m so screwed! - This is completely untrue. There are plenty of people who graduate college knowing only Java and score perfectly good jobs. Now this is no long term solution, as you will likely have to program in something else at some point in your career. But if only knowing one language is your curse, then be sure you are the best at that language you can possibly be. Learn the benefits and drawbacks, learn about different implementations of the language and what makes them different, and learn how the language itself works at the compiler / interpreter level.

2. There is no real experience on my resume! - Sadly very few computer science students have any real experience on their resumes, but this can be easily corrected. On my resume when interviewing for what became my first job, the only bit of professional experience I had was working on a defunct web application for The Pittsburgh LAN Coalition, a LAN Party group in Pittsburgh. While the application never officially saw the light of day, I did learn a great deal in the process, which I was able to communicate to my prospective employer quite well. Also keep in mind that there are a number of open source projects listed which could use a hand, don’t be shy to contribute.

3. My code is so simple compared to other programmers, my code must suck. - Not true one bit. Try to keep in mind who you are comparing yourself against. I remember during my sophomore year of college when I first learned C, I downloaded a tarball of the Linux Kernel and fooled around with it. After a number of hours I was still unable to make heads or tails of anything.  Keep in mind that you are still a novice, and these people are masters at their craft.  Keep that piece of code in your mind, and after you have a few months of experience under your belt go back to see if that code is really still that complicated.

4. I don’t know any of the industry standard tools. - A common misconception many students have is that they will either not be hired for a job, or look foolish on their first day because they know very little (or nothing) about industry standard tools like Subverion, CVS, Code-Sniffers, etc.  When a company hires an individual straight out of college they are expecting to have to train them before they become proficient.  Just focus on being a good programmer now and worry about working within a company’s parameters when you start the job.
5. My school didn’t teach me anything. - Remember, if you are going to school to become a programmer you are not going to school to learn skills, you are going to school to essentially learn how to learn.  A good CS curriculum should be teaching you the basics of programming theory and practice, but beyond that it is up to you to find you niche and grow in it.  Just worry about completing your coursework and make sure you stay up to date on the latest happenings in the programming world and you will be fine.

Just keep these in mind while working your way through the educational process and you’ll be fine.