melreams.com

Nerrrrd

Best Practices

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.

Impressively evil

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.

Fiddler rocks

Fiddler rocks. Fiddler is a free web debugging proxy for any browser, system or platform. I’ve only ever used it on Windows so I can’t speak to how it performs on any other OS, but on Windows it’s pretty great.

To go into a little more detail, Fiddler captures every request your browser makes and lets you save, retrieve, and analyze them. Mostly I use it for simple things like seeing the full error message and headers returned by a failed api call when all my javascript is telling me is that “something went wrong.” Thanks js, you’re a big help.

A lot of why I like Fiddler so much is just personal preference. The network tab in Chrome dev tools does a lot of the things I use Fiddler for, but I like Fiddler’s interface better. Fiddler does have some differences, though. If you want to save a few rounds of requests across page refreshes so you can compare them to each other, Fiddler lets you do that. It also has a more powerful filtering system than Chrome dev tools, so you only have to see the requests you care about.

Another awesome thing you can do with Fiddler is set up a mobile device to use it as a proxy. Logging from a mobile app is all well and good, but sometimes it takes much longer to add logging, rebuild, and redeploy than it does to just update your mobile network settings to use Fiddler as a proxy.

While I mostly use Fiddler for very simple request/response viewing, you can do some pretty cool stuff with it like performance testing, session manipulation, and security testing. There are also lots of add-ons you can try if Fiddler doesn’t already do what you want, plus you can customize it on your own.

As much as I love Fiddler, there is one caveat I need to mention. Firefox is totally incapable of coping with Fiddler unless you change some settings. I strongly recommend that you do that immediately if you install Fiddler because you will forget that you have Fiddler running, try to test something in Firefox, and freak out because everything is suddenly broken (not that I’ve ever done that. Repeatedly). It’s not, Firefox should just be ashamed of itself. Even IE can handle a freaking proxy. You used to be cool, FF. Now you’re like a broken down racecar that’s getting lapped by a go-kart. With square wheels. That’s been set on fire.

Why should you care about Fiddler? It might be better than what you’re doing right now. Having better tools to do the tedious stuff for you means more time for actual development, even if you have to invest a few minutes up front to figure out if Fiddler is actually better than what you’re using right now. It won’t magically make you a better developer, but it will give you more time for development, which can be pretty close to the same thing :)

Android tip of the day

There’s this really awesome utility for Android called Tasker that lets you automate all kinds of stuff on your phone. I love how much stuff I can do with it, but the interface doesn’t just fail to be user friendly, it’s actively user hostile. Every damn time I set up a phone I forget how to configure Tasker to automatically unlock my phone when I’m at home. This little how-to guide explains it all really clearly and (at least for now) matches Tasker’s interface.

It’s normal to feel stupid

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.

 

SICP: first impressions

Not so long ago I decided to try working my way through Structure and Interpretation of Computer Programs, hereafter referred to as SICP because that’s an awful lot of typing. Why SICP? Because I hear it will make me a better programmer and because I’ve heard about it enough times that I want to know what I’m missing :)

Thanks to the wonders of the internets, you can get the book at the link above and MIT-Scheme or SCM scheme. If you’re running windows like me, I don’t so much recommend MIT-Scheme. I have heard that it’s the only one you can do all of the exercises from SICP in (I haven’t gotten far enough into the book yet to see if that’s true, but I’ll let you all know when I do), but the documentation for it is kind of painful and in general I’d rather take up cottage cheese sculpture than learn emacs.

SCM is much less painful to run once you get it installed, but that isn’t as easy as it looks. The quick start for windows section currently says to install slib-3b4-1.exe and then scm-5f2-1.exe, but that’s the wrong version of slib. You want slib-3b5-1.exe from http://people.csail.mit.edu/jaffer/SLIB.html, then you can install scm successfully. After that make sure scm scheme has been added to your path, then you can use whatever editor you want to work with your scheme files and run them from the command line with scm -f <filename>

For an editor, I personally like Sublime, although I’ll be honest, I’m cheap and I think $70 is a bit steep for a text editor. It does have excellent plugin support though, as well as a much nicer interface than free editors like Notepad++.

If you decide to go with Sublime, I recommend installing Package Control and then the scheme package to add scheme syntax highlighting. Once you have package control installed, go to preferences->package control and click “Package Control: Install Package” in the menu that will pop up. It lags a little bit on my machine but in a second or two a new popup will appear that lists all the packages you can install. Search for scheme and install that package. Once you restart you’ll have scheme syntax highlighting and paren matching, which is pretty handy.

When you’re editing your scheme file, it will probably be helpful to know that you print to standard out with (display <arg>) and print a carriage return with (newline). You can skip printing your output if you use the MIT-Scheme interpreter, but then you’d have to use the MIT-Scheme interpreter :)

My workflow so far is edit in sublime, run the file with scm from the command line (scm -f <filename>, don’t forget), then look at the output and go back to sublime.

Now that the environment setup is out of the way, let’s talk about scheme. It’s been almost ten years since I touched any dialect of Lisp and it’s incredibly weird working with it again. Normally I write methods/functions from the top down, but scheme forces me to write them from the center out. It’s also pretty strange to work in a language with so little syntax. There’s almost nothing to scheme but a few basic functions and shit-ton of parens. It’s kind of beautiful, but compared to java’s creepy obsession with boilerplate it’s really, really weird. I don’t know yet if SICP will actually make me a better programmer, but it’s definitely forcing me to look at problems from a different perspective.

So far SICP has covered pretty basic parts of programming, but if it’s been a while since you used scheme I recommend plodding through the refresher. And check your work with google, there are a ton of solutions out there for all the exercises, including this handy wiki. There are a couple of tricky questions about normal-order and applicative-order in the first chapter that I got completely backwards the first time, so check your work and run an example to make sure you’ve got a handle on it.

Expect to hear a lot more about SICP from me in the future, I have plenty of chapters to go.

Showing up is my secret superpower

Or, networking for misanthropic nerds.

I’m shy, awkward around people I don’t know well, and honestly kind of a dork. So how is that I got three of the four jobs I’ve had since college by knowing people? I show up. That’s seriously it. Physically show up to events, make a minimal effort to be friendly, and you will get to know people who will either introduce you to someone who will offer you a job or offer you a job directly.

So let’s get into details. When I say “events” what am I actually talking about? User groups, code camps, meetups, developer get-togethers, conferences, etc. Victoria is not a large city and we still have a wealth of meetups, your city almost certainly has some too. Google is your friend here, as is twitter and other social media. I found out about whiskydev because a friend tweeted about it. At whiskydev I met a friend who introduced me to my new boss, and now I work at an awesome startup.

If you’re particularly shy, I recommend user groups or meetups where someone gives a talk. How do you know the group is having someone give a talk? They’ll usually announce the speaker and topic ahead of time because they’re excited about having an actual speaker (depending on the group’s topic, it can be a huge pain to find someone to speak so organizers are usually pretty stoked about finding someone) and so that people who either don’t care about or love that topic can make plans accordingly. Talks are easier for shy people because a) you can spend most of your time at the meeting quietly taking notes, and b) afterwards you can ask people how they liked the talk instead of agonizing over how to start a conversation. Not that I’ve ever done that.

Another tip for shy people or for people who are really serious about networking is to volunteer. I volunteer with a number of organizations and I speak from experience when I say there is no such thing as too many volunteers. Come early and help set up, stay late and help clean up, or ask the organizers if they need volunteers for anything. The answer will almost certainly be yes, and now you’ll have a defined job to do which makes it way easier to talk to people.

It’s great if you can be friendly and talk to people, but the first step is just physically showing up. Start there and you’ll be fine.

But to be fair, I have to mention that it is possible for showing up to backfire horribly. If you show up and act like an asshole, word will spread. Victoria in particular is a very small town when it comes to tech. The person you’re a jerk to today could easily be friends with the team lead who’ll be interviewing you tomorrow. On the upside, you kind of have to work at it to be enough of a jerk that someone would tell a friend not to hire you. People are generally pretty forgiving and we all know what it’s like to put our foot in our mouths. Just don’t be a dick and you’ll be fine. That doesn’t mean you can’t have opinions, just that you should phrase them as opinions. For example “I hate working with javascript” is just an opinion, but “javascript sucks and only shitty programmers use it” is going to make you look like a jerk.

And one more tip, particularly for students: class counts as networking. Your professors have probably had students before you, and certainly know people in the industry. Those former students may be the ones interviewing you or asking your professor about you. People your former classmates work with might also ask them what you were like as a classmate. Think about what you want them to say before you show up late and blow off assignments. This applies to your current job as well – just like you aren’t going to stay in one place for your entire career, neither are your coworkers. If you interview somewhere a former coworker now works, what are they going to say about you if the interviewer asks them?

To summarize, my tips for networking are:

  1. Show up
    1. Try to be friendly
  2. Don’t be a dick
  3. For extra credit, volunteer

That’s all you need to do to make contacts who might one day help you find a job. “Networking” can sound like something only slimy salesdroids do, but it’s really just showing up and trying to be friendly.

How javascript is like a board game

Javascript is much more like a board game than you might think. Let me tell you a story to explain what I mean.

I used to be convinced I just didn’t like board games. I’d played the usual Snakes and Ladders, Sorry, Risk and Monopoly as a kid, and I could happily go without playing any of them ever again. Especially Monopoly. At least the other ones had an end in sight, even in Risk there was the hope of a quick and merciful rout, but Monopoly always seemed to end with people forfeiting just to get the game over with.

Then friends of mine started introducing me to board games that didn’t suck. Games like Clue and Red November and Space Alert and Ticket to Ride. It turns out I like board games after all, I just don’t like shitty board games.

Javascript, as it turns out, is remarkably similar. I used to think javascript just sucked, then I started working with ember. It turns out I don’t hate javascript after all, I just hate shitty javascript. All of the javascript I’d worked with pre-ember was a totally structureless mess – which I freely admit was partially my own fault. The vast majority of my programming experience is in java using frameworks like struts and spring which enforce a lot of structure. Server devs, myself included, don’t always know what to do without a framework enforcing some structure on our code.

Ember is an extremely opinionated framework, which as a veteran of rigid java frameworks I find comforting and familiar :) It also takes quite a few architecture decisions out of the developer’s hands, which is tremendously helpful if you’re a server dev with no interest in reinventing the wheel. Ember certainly isn’t the right choice for every single project, but it works very well in the context I’ve used it in and lets me get my front end tasks done quickly so I can go back to the server side development I prefer.

The moral of the story, in case you haven’t been paying attention, is that before you decide something sucks make sure you’re not just using it wrong.