Mel Reams

Nerrrrd

Passion isn’t everything

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

This post is a bit of a counterpoint to my previous post about why I love programming even though it’s frustrating as hell sometimes. While I feel very lucky that I get to make a living doing something I love, I really don’t like my industry’s obsession with passion. It’s great if you feel passionate about programming, but it’s simply not necessary.

“But Mel,” you say “do you really want to work with some checked-out code monkey who half-asses everything, doesn’t give a shit about technical debt, and counts the minutes until it’s time to go home?” That’s a false dichotomy right there. There are many, many more choices than “passionate programmer” and “checked-out code monkey.” No, of course I don’t want to work with someone who doesn’t care about doing a good job. Fortunately, there are only about a zillion other points on the spectrum of “total passion” to “no passion at all.” Not being the most passionate programmer who ever lived in no way means you don’t care about doing a good job or want to improve. It just means you have other things going on in your life. Honestly, I think that’s healthier than being obsessed with just one thing.

Not to mention having other interests actually makes you a better coder. Seriously, go read that article it’s really good. Having just one obsession makes it much more likely that you approach problems from just one direction where having other interests allows you to come at problems from a different perspective. Take Adam Tornhill for example, he took ideas from forensic psychology and applied them to code analysis to get some really interesting results.

Obviously you can be passionate about more than one thing, but that still doesn’t mean passion is necessary to be a good programmer. You can take pride in your work even if you aren’t in love with what you’re working on. Using myself as an example, I stocked shelves at Wal-Mart before I moved to Victoria to go to Camosun. Was I passionate about taking things out of boxes and putting them on shelves? Of course not, but I still took pride in doing a good job. I went home every day knowing I made the department manger’s lives easier, not harder. Pro-tip: doing nothing is more helpful than leaving a mess someone else has to clean up.

Or to use a more relevant example, I don’t like doing front-end layout. The endless fiddling and wondering if that element would look better where it is or 5 pixels to the right isn’t satisfying for me, it’s just annoying. But if you give me a screen mockup, the end result will match it no matter how much swearing it takes. I don’t enjoy the process, but I do enjoy knowing I did a good job.

What’s really important is caring about the quality of your work, we just use “passion” as a proxy for that because we don’t know how to measure it. Unfortunately, we don’t really know how to measure passion, either. Sure, somebody who has side projects or contributes to open source is probably passionate about programming, but that doesn’t mean someone with no public git repos doesn’t give a shit. Simply having the time to work on side projects is an enormous privilege. People who have kids, or sick relatives they need to take care of, or who need to freelance to bring in extra cash, or who have disabilities or are neurodivergent, or would rather spend time with friends and family than do more work outside of work, or just have time-consuming hobbies may simply not have the time or energy to perform passion by working on publicly shareable side projects.

None of those things mean you don’t care deeply about programming, they just mean that you have other responsibilities or interests. Hint for employers: people who have responsibilities are more focused when they’re at work because they know they can’t put in a few extra hours later and they really hate changing jobs because it’s even more of a pain in the ass. That 20-something rockstar (ugh) dev who has no serious ties to the area might decide to move to San Francisco tomorrow. Your 30-something dev who has a mortgage and a kid is a lot less likely to randomly sell their house and uproot their family. Not that you shouldn’t trust single 20-somethings, but can we please stop pretending they’re the only worthwhile devs?

If you must look for passion, at least look for actual passion and not “free time and nothing better to do”. Ask candidates what they love about programming. Ask them if they have opinions about tools and languages and programming styles. Ask them what they would learn if their job gave them some free time and a resource budget.

But if you’re realistic about what you need, I think you’ll agree that passion is a red herring and what actually matters is caring about doing a good job. Fortunately, that’s a lot easier to find.

Does it actually need to be optimized?

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

Learning to focus on one tiny part of your problem and ignore everything else is a really useful skill as a dev, but ironically it can also get you into trouble. It’s just as important to keep the bigger picture in mind as it is to break your problem down into little pieces and do them one at a time. Why yes, this is one of those posts that is as much for me as it is for you :)

Just because a process is slow doesn’t mean it needs to be optimized. If it hardly ever gets called, who cares if it’s slow? I know, I know, it feels wrong to see something that’s slow and leave it that way, but it’s not worth the dev time unless the process gets called often enough. Slow alone isn’t necessarily bad, it’s slow and called a lot that’s a problem. If you’re lucky you have metrics to look at and know for a certainty what gets called often, otherwise you’ll be making an educated guess. This is where understanding your application and thinking about how all the different pieces fit together comes in handy.

For example, anything you can do asynchronously is not going to be your first priority for optimization. If you can hide the processing time from the user, you may never need to optimize it. Initialization, while it is the user’s first impression of your app, also happens only once a session. First impressions are certainly important, but other actions in your app will happen much more often which makes them better targets for optimization. Assuming your load time is reasonable, of course :)

Of course, learning experiences are important too, so don’t worry about this too much if you’re a junior developer. The way you learn what isn’t worth spending time on is by messing up, it’s an unavoidable part of the process. If in doubt, talk it over with your team lead/dev lead/someone with more experience, learn as much as you can from other people’s mistakes. You’ll also learn more about programming by optimizing, so even if the end result isn’t exactly critical to your application, the practice you’ve gotten means it wasn’t a total waste of time.

One of the concepts I’m still mastering as a programmer is that nothing exists in a vacuum. Context is much more important than any individual piece of code – it’s not, “speed this thing up or let it suck” it’s “speed this thing up or do one of a dozen other things that could be more useful.” Remember, your time has a value. Speeding up one piece of code, as personally satisfying as that can be, may mean much less to your users and your bottom line than a bugfix or a new feature. Developer time is expensive, it just makes sense to spend it on the things with the greatest returns.

The next time you’re about to optimize something, ask yourself how often that code is going to be called. It might sound too simple to be useful, but trust me, it’s a very easy question to forget.

.NET JWT library tip of the day

If you use JWTs (JSON web tokens) and need to generate or consume them in .NET, you might get the idea that the Microsoft library listed on JWT.io is the way to go. It’s by Microsoft, that means it’s official and trustworthy, right?

Don’t be fooled! I mean, it is official and trustworthy, but I had a horrible time trying to use it. Save yourself the trouble and use jose-jwt if you need to handle JWTs in .NET. The readme alone is a thing of beauty, it has a shockingly comprehensive set of examples for pretty much everything you would ever want to do with a JWT. The library really is as easy to use as the examples make it look. I was able to generate a JWT with it in just a few minutes and as you might have guessed from my posts about switching to Linux, my .NET experience is extremely out of date :)

Learn from my mistakes, just use jose-jwt and pretend you never heard of the Microsoft library.

Merry almost Christmas, everyone!

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.

 

 

 

Debugging

There’s no way I can possibly say everything about debugging in just one blog post, but I can certainly share a few useful tips.

First, let’s talk about what debugging fundamentally is. It’s the art of seeing what actually is, not what you meant or what you thought. It’s going to be uncomfortable, and if you get too tied up in your own ego you won’t be able to do it at all. Years ago one of my teachers at Camosun told us (I’m paraphrasing heavily here because I don’t remember the exact words) that there’s no point insisting you didn’t change anything. If it used to work and now it doesn’t, you obviously changed something. Just accept that you broke it and start trying to fix the problem.

One of the first things you need to do when you’re debugging is to make sure you can reproduce the problem reliably. If you can’t do that, then you don’t really know what the problem is (or you’ve got some sort of unholy race condition bug and you’re beyond my help :) ). If you’re not the one who found the bug, ask the person who did if they can show you, or ask for more information if it came through a helpdesk and you don’t have direct access to the user who found the bug.

Once you can reproduce the problem, you’ll be able to track down what’s going wrong and figure out whether a fix actually… fixes the problem. The first step I recommend after reproducing the issue is double checking all of your inputs, even the most stupid simple stuff you’re sure you couldn’t possibly have gotten wrong. Last week I thought I had broken staging when I actually just hadn’t chosen the right value in a dropdown box. Garbage in, garbage out, as they say.

After that, you’re going to be very tempted to just read through your code and hope you can spot the problem. Resist this temptation! I’m always pretty sure I know where the problem is or that it’ll jump out at me right away, but it almost never does unless it’s an extremely simple bug. Read over the code once if you really want to, but then move on to narrowing down exactly where the bug is. Believe me, it’s faster than staring blankly at your code and feeling dumb.

If you have a particularly chatty log, you may be able to start narrowing things down while you reproduce the issue. Start looking after the last log message you see before the bug happens. If you’re very lucky something will be obviously wrong close to the log line you were looking for.

If you’re not quite as lucky, you’re going to need to run the code locally and start commenting things out. Assuming you have some idea where the problem is happening, start dividing the method it could be in, in half. Either comment half of it out or add a log line half way through and see if you see that log line before or after you reproduce the problem. Keep narrowing it down until you know exactly where the problem is. Once you know exactly where the problem is, you should now know what’s going wrong if not exactly why. It’s not unusual to have to trace back through your code to find the place that set up the issue that wasn’t triggered until later. Bad config, for example, may not cause an actual bug until long after it’s saved.

The most important things you can remember when you’re debugging are to be systematic and to not make assumptions. Don’t assume that your input is good. Don’t assume that a certain piece of code can’t be the problem because it hasn’t been changed in ages/just passed testing/doesn’t seem to be related. Don’t assume that your config is what you think it is. Don’t assume that you know what’s going on – if you did, you wouldn’t have written a bug in the first place :)

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.

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.

 

WordPress Appliance - Powered by TurnKey Linux