Random thoughts on code errors after teaching two different languages in one semester

When I was a bit younger we used to play a game called Pitfall where you would guide your player across various obstacles, including chomping alligators, deadly quicksand, and rushing rivers. In programming there are also pitfalls, and they may not be as bad as an alligator pit, but they will consume your time and leave you drained at the end of the day.

Software errors will always happen, it comes down to how quickly you can identify them and correct them that make all the difference. Those that argue that code should be written error free the first time have obviously not written much code. We can all agree that production code should be error free, but to achieve error free code means you will have to identify and eliminate errors.

I wanted to share a few thoughts on how to cut down on errors in your code.

Use proper indentation, and formatting. This is almost never taught in class, and most of the books that I have seen even contain code that runs and is compact but is not really easy to read.  It’s important to write all your code as if you are going to spend the rest of your career maintaining it.

This sounds great but how can I implement it? Let’s take a look at some code.

I like to use a tab for each block of code. Look at the difference between block a and block b.

A

Ext.override(Ext.form.Radio, {
        setValue : function(v) {
            if (typeof v == 'boolean') {
                Ext.form.Radio.superclass.setValue.call(this, v);
            } else if (this.rendered) {
                var els = this.getCheckEl().select('input[name=' + this.el.dom.name + ']');
                els.each(function(el){
                    if (el.dom.value == v) {
                        Ext.getCmp(el.dom.id).setValue(true);
                    } else {
                        Ext.getCmp(el.dom.id).setValue(false);
                    }
                }, this);
            }
            return this;
        }
    });

B

Ext.override(Ext.form.Radio, { setValue : function(v) {
if (typeof v == 'boolean') {
Ext.form.Radio.superclass.setValue.call(this, v);
} else if (this.rendered) {
var els = this.getCheckEl().select('input[name=' + this.el.dom.name + ']');
els.each(function(el){
if (el.dom.value == v) {Ext.getCmp(el.dom.id).setValue(true);
 } else {Ext.getCmp(el.dom.id).setValue(false);
}}, this);}
return this;
} });

Hard to believe that’s the same code right? Now imagine this throughout a file containing a thousand, ten thousand, hundreds of thousands of lines of code.

Use curly braces even when you don’t have to. Wait won’t that bloat my code? I’ve been taught that I should keep things as compact as possible what’s up with this. Let me explain in code:

A

if (condition1)
{
    if (condition2)
    {
        statement1;
    } else {
        statement2;
    }
}

B

if (condition1)
if (condition2)
statement1;
else statement2;

To the compiler, both pieces of code above will achieve the same result; however, the top block is far easier to read for us humans. Which code would you like to maintain.

Don’t use variable names that have no meaning – remember comments in the code should not be used to explain what your variables are, let their names tell all. This rule needs no code explanation, just stay away from one letter variables like a, b, or c and try to spell them out like

A

        double    a;
        double    b;
a = (b - 32) * 0.555555556

 

B

 

        double    celsius;
        double    fahrenheit;
celsius = (fahrenheit - 32) * 0.555555556

Bet you didn’t know that example A did until you got a look at B, right.

Test often and test early. How many lines do you write before you stop and see if what you have compiles. Do you write test cases for all your functions when you code them and actually test them before connecting them to the user interface? This helps you tackle bugs close to the source without wading through hundreds of lines of code.

If your IDE does not have a nice auto save feature like Jet Brain’s WebStorm, then please remember to save early and save often. There is nothing more frustrating than losing hours of good code.

Nobody ever wanted an app that ran slower, keep that in mind and optimize, optimize, optimize. You can use tools like Page Speed, or Chrome’s Developer Tools to get your JavaScript on track. In addition Google and Yahoo have written detailed articles that are essentially a lessons learned document

Some advice on IT management from a marketing pro

I noticed that Seth Godin posted a piece on the tendency to take star programmers and transform them into mediocre managers, it’s a mistake that cuts you twice, once with the loss of the key performer, and twice with the fact that you now have a management problem to deal with that may impede more key performers from joining the team. I asked and received permission to post the piece here in its entirety. The original can be found at this link, and a lot of other stuff on management and marketing that may be of intrest.

The extraordinary software development manager

Being good at programming is insufficient qualification for becoming a world class software project manager/leader. Too often, we take our best coders and turn them into incompetent managers because it seems like a logical next step, and because we don’t pay adequate attention to what we really want from these critical executives. (Hint, this is about many fields, not merely software).

1. Clients want useful visibility into the future in terms of costs, timing and deliverables

in fact, it’s almost impossible to be too clear, to benchmark enough and most of all, to overdo the work of identifying forks in the road when it comes to decision making. When a client hires a developer or a company embarks on a software project, they are lost. Even something as complex as building a house is dwarfed by the rapid change, shifting priorities and most of all, the requirement for the new, that’s involved in even a simple software project.

The indispensable software development manager is aware of this and lays it all out for us.

2. Code is going to be used, reviewed, updated and inspected by people other than the person writing it

At some point in the next [insert time frame], a dozen people we have never met will either be updating or using this code, whether they are people we hire or people we partner with. It’s tempting to question the value of an organized architecture and clear code commenting, but again, it’s almost impossible for an organization to overdo this. We don’t have time to do it over so we have to spend the time to do it right. In software programming only the amateur’s approach rewards speed over long-term usability.

3. A great programmer is worth thirty times as much as a good one.

Which means that hiring a good programmer in a competitive field is a killer error. It also means that managing a programmer in a way that accepts ‘good’ will lead to a fail as well.

4. Programming at scale is more like building a skyscraper than putting together a dinner party

Architecture in the acquisition of infrastructure and tools is one of the highest leverage pieces of work a tech company can do. Smart architecture decisions will save  hundreds of thousands of dollars and earn millions. We’ll only make those decisions if we can clearly understand our options.

Or, you can have some newbies hack something together real quick. Up to you.

Forget you identity, what about your pacemaker

The video below highlights a serious problem with medical devices that are as sophisticated as a large computer was just a decade ago. Dr. Rubin of Johns Hopkins outlines the hacks that the academic community have taken against implanted medical devices. Six years ago implanted devices were outfitted with wireless capabilities so that the devices can be updated without surgeons having to open you up.

Some of the devices include defibrillators, pacemakers, embedded insulin pumps.

The beauty of open data one year after the post that started it all

How to train to be a better programmer :-)

If a runner stretches before a race, or a martial artist meditates before sparring, what should we do as programmers to reach that state of mind that puts in the ‘zone’. It must be logic tests judging by all of the famed interview tests that come out of the large software companies.  One of the trickiest logic tests is said to have been invented by Einstein when he was a boy, and there are claims that only two percent of the population can solve the puzzle, so could there be a better test to spring on candidates for development positions? If there are any reservations that it would be too difficult for the potential candidate, given the 2 percent completion rate, I was surprised to see a variation of the puzzle come home with my daughters 7th grade math homework as extra credit this past year. Try and see how you make out with this, without the help of any internet searches. I would be interested in knowing how you solved the puzzle.

  1. There are five houses.
  2. The Englishman lives in the red house.
  3. The Spaniard owns the dog.
  4. Coffee is drunk in the green house.
  5. The Ukrainian drinks tea.
  6. The green house is immediately to the right of the ivory house.
  7. The Old Gold smoker owns snails.
  8. Kools are smoked in the yellow house.
  9. Milk is drunk in the middle house.
  10. The Norwegian lives in the first house.
  11. The man who smokes Chesterfields lives in the house next to the man with the fox.
  12. Kools are smoked in a house next to the house where the horse is kept.
  13. The Lucky Strike smoker drinks orange juice.
  14. The Japanese smokes Parliaments.
  15. The Norwegian lives next to the blue house.

Now, who drinks water? Who owns the zebra? In the interest of clarity, it must be added that each of the five houses is painted a different color, and their inhabitants are of different national extractions, own different pets, drink different beverages and smoke different brands of American cigarets [sic]. One other thing: in statement 6, right means your right.

— Life International, December 17, 1962