melreams.com

If you celebrate Christmas, here, have one of the very few Christmas carols I can listen to without wanting to run howling into the wilderness. And if you don’t celebrate Christmas, at least it’s almost over.

 

 

 

Zsolt Nagy has some great tips on javascript debugging. I’ve been using chrome dev tools for ages and I had no idea that DOM breakpoints were even a thing.

Let’s talk about questionable code and the best practices to fix it. Even if you’ve been a developer for years it’s good to do a quick review once in a while and make sure you haven’t picked up any bad habits.

Commenting out code instead of deleting it

I’m as guilty of this as anyone else, but honestly it’s a waste of time. If you ever actually need that code back you can pull it out of source control, that is what it’s for. As much as I’ve wanted to hedge my bets and just comment out that block so it’s easier to put it back if I need it again, I’ve almost never actually needed to do that. The commented out code just hangs around in your file forever, confusing new developers and forcing you to wonder if you should update it every time you work on that method. That’s a lot of trouble to go through over code you’re never going to use again. Just delete it, it’s easier. If you’re really worried about getting it back, put the delete in its commit and add a good descriptive commit message.

Cryptic variable names

This is a huge pet peeve of mine. Characters aren’t rationed! You can use as many as you need to make the purpose of your variable clear, nobody’s going to come and take them away. Excessively long names are annoying too, but they’re not nearly as bad as wasting time figuring out that “un” actually means user name. Autocomplete has been around for a long time, the excuse of not wanting to type long variable names is not going to fly. Give your variables meaningful names, the inconvenience will pay off in the long run.

Long methods

Again, there’s no rationing! You do not need to stuff everything and the kitchen sink into one method, you’re allowed to have more than one. Refactoring has been around for a long time too, any reasonable IDE should let you extract a method in a few clicks. Even if you have to manually refactor, the pain is worth it. With smaller well named methods, you can quickly skim through code and figure out what’s going on. Without them, you can waste a whole lot of time trying to figure out which part of that ginormous method you actually need to change.

Methods with huge numbers of parameters

This issue is closely related to the last one. If your method has an excessive number of parameters, it’s probably doing too much and it’s likely too long as well. This one can be painful to fix depending on the rest of your architecture, but if you can manage it without tearing everything apart it’ll make things much easier the next time you need to look at that code or use that method. The more parameters you have, the more changes you have to mix some of them up and introduce weird bugs into your code. If you really do need lots of parameters, at least bundle them up in a <your method>Config object to make it harder to mix them up.

These are far from the only problems you’ll see in your code, but looking out for these simple issues is a good place to start cleaning up your codebase.

I’ve seen bad things done in java. The kind of things you can’t unsee. But I’ve never seen anything quite like this java program that makes 2 + 2 = 5:

import java.lang.reflect.Field;

public class Main {
    public static void main(String[] args) throws Exception {
        Class cache = Integer.class.getDeclaredClasses()[0];
        Field c = cache.getDeclaredField("cache");
        c.setAccessible(true);
        Integer[] array = (Integer[]) c.get(cache);
        array[132] = array[133];

        System.out.printf("%d",2 + 2);
    }
}

Thanks, codegolf user MichaelT, I didn’t need to sleep again anyway.

This interview with Saron Yitbarek is really interesting and you should read it. Saron currently leads the Tech Jobs Academy program at Microsoft and she founded CodeNewbie.org.

My favourite part of her interview is:

What advice would you give to a younger version of yourself starting out in development?
You’re going to feel stupid most of the time, and that’s ok. Also, don’t go at it alone. Things are much easier when you do it with a community of people who are just as passionate about coding as you are.

The terrible irony of programming is that programmers love feeling smart and somehow we choose a profession that makes us feel stupid most of the time. Seriously, I’ve been at this for nine years and I feel stupid very very often. Just the other day I spent a couple hours fighting with a CSS issue that turned out to be a min-height on the containing element issue, it wasn’t even near the sidebar that I was trying to change. Feeling stupid is completely normal and probably an inevitable part of learning any complicated skill, not just learning to code.

It does get better, though. With experience you learn that even though you feel stupid for a while (maybe a long while) eventually you figure it out. To quote Cecily Carver’s Medium post Things I Wish Someone Had Told Me When I Was Learning How to Code:

I’ve found that a big difference between new coders and experienced coders is faith: faith that things are going wrong for a logical and discoverable reason, faith that problems are fixable, faith that there is a way to accomplish the goal. The path from “not working” to “working” might not be obvious, but with patience you can usually find it.

It’s kind of like levelling up in an rpg – you just have to grind through the boring low level part until you gain enough XP to get to the next part of the story. Just like being at a low level in a game feeling stupid doesn’t mean you’re bad at the game, it only means you haven’t been playing for very long. If you just keep trying for long enough you eventually learn that even though you feel stupid now that doesn’t mean you’ll never figure it out.

As a little bit of an aside, there’s a theory going around that if you were praised for being smart as a child rather than for trying hard (which I hear is pretty common for girls) then running into a task you aren’t instantly great at is a terrifying blow to your identity as “the smart kid.” It’s totally possible, even likely, that there are all kinds of issues with that study and the conclusions drawn from it, but that theory rings absolutely true for me. Every time I run into a problem I can’t solve right away, I get scared that this is the problem that proves I was never really all that bright. It sucks but it’s totally normal. I’m still struggling with that myself, the only answer I have is to keep trying anyway.

Feeling stupid absolutely does not mean you’re just not cut out for coding. It’s a totally normal stage that everyone goes through. Everyone feels stupid most of the time when they start coding and anyone who says they never feel stupid is a liar (pants on fire!) and not even a good one. Even when you’re experienced you will still feel stupid pretty often.

If you see people around you who don’t seem to be as bothered by feeling stupid, either they’re good at hiding it or they’re just more used to it than you are because they’ve been doing it longer than you have. Once you spend enough time feeling stupid you stop getting very worked up about it. That’s not to say it doesn’t still suck (see my CSS story above), but once you go through the cycle of getting stuck, feeling stupid, and figuring it out enough times it doesn’t seem like such a big deal anymore.

Feeling stupid doesn’t mean you are stupid, it just means you’re like every other person who has ever tried to learn to code.