melreams.com

Nerrrrd

Rest is good for you

in career, opinion, productivity, selfcare

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

No not the architectural style (although I am a fan), I’m talking about taking a break once in a while. I’ve already talked about how churning out work isn’t everything, but it seems like a good time for a reminder. Actually, the ideal time for a reminder would have been last Monday, but I didn’t come up with the idea for this post until last Sunday and it seemed hypocritical to write about how people should take a break by, uh, not taking a break even on Christmas day.

So I hope you did get a break sometime between Christmas and New Year’s Eve and I hope you actually rested instead of pressuring yourself to build a side project or learn something new. If you didn’t get a chance to relax, and not everyone does, I hope you can make some time to relax soon. Not just because working all the time is no way to live, but because rest is necessary if you want to be productive.

At this point I could reel off a list of links justifying the idea that rest is necessary, but that’s really not the point of this post. We all know rest is necessary, we’ve all gone through a crunch at work or poured way too many hours into a college/university/bootcamp project to get it done in time and ended up mentally exhausted and unable to think clearly for days afterward.

The point of this post is to try to convince my readers that it’s okay to take a break. We all know we should, but we put it off and put it off because of the pressure to keep up, to always be coding, to prove that we’re good programmers by grinding ourselves down and sacrificing practically all of our waking hours on the altar of being the best. It’s easy to feel like you’re falling behind, it’s easy to think that everyone else is hacking away every night while you cook dinner and hang out with your friends like a chump, it’s so easy to feel like you’re not doing enough.

Well, programming is all about tradeoffs so let’s talk about tradeoffs. You could spend the vast majority of your non-work waking hours doing more work in the form of personal projects and learning more programming languages, and that would probably make you a better programmer than you would be with less practice. There’s also the fact that practice doesn’t make you better unless it’s the right kind of practice, but let’s ignore that for now. If you generalize a little, I think it is true that more practice is likely to make you a better programmer. But the question is, is it worth it?

Just because you can do something doesn’t mean that it’s worth the trouble or that it’s ever going to be your highest priority. That’s one of many frustrating things about programming that I only learned after I graduated – being able to fix a minor bug doesn’t mean that bug is ever going to be more important to the business than a new feature, so that bug can hang around for years, annoying you every time you see it.

How you spend your free time is a tradeoff like any other in programming – spending that time coding on side projects means you can’t spend it with your friends and family, or going for a walk, or learning how to make pottery or do some basic plumbing or on reading a novel. Of course, if you spend some of your free time learning to dance, that means you can’t spend those hours learning a new technology, so it comes down to what’s worth it to you. And by that I mean what really matters to you personally, not what you think you’re supposed to want, not what your parents want, not what your boss wants, what you want.

And then there’s the available resources part of the tradeoff: you may be able to spend your free time on programming projects at the cost of dumping childcare and the work of maintaining your home and your social life on your (probably female, let’s be honest) partner. That’s a choice you can make, but it’s unlikely to be one you can make and still be a good person.

Is being the best programmer you can possibly be really more important than anything else in your life? If that’s really and truly what you want then go for it with everything you have, but if it’s not, then go after what you really do want and don’t forget that you’re not obligated to want to be the best programmer you can be. Obsession is not required, you’re allowed to be a human being with more than one interest.

And take a break, it’s good for you :)

Tip of the day

in tip of the day

Haven’t finished your Christmas shopping yet? Haven’t started? A really convenient last minute gift is giving to charity in your gift-getter’s name. CharityWatch has a great list of trustworthy charities and GiveWell will give your donations directly to the charities that they’ve found to be the most effective.

Or you could just go to the liquor store if you’re not worried about looking classy ;)

Talk of the day

in Uncategorized

So it turns out there are a lot of keynotes I like, and one of them is from Keep Ruby Weird 2015 by Sandi Metz. Fair warning, parts of that talk hard to listen to – she plays recordings from an old psychological experiment that would absolutely never pass ethical review today. However, even if you skip that part (she warns you when the hard bits are coming up), there are some really excellent points in that talk about community and how to good ideas rather than conformist ideas out of your team. Seriously, it’s really worth watching.

Talk of the day

in talk of the day

I really enjoyed this keynote from PyCon 2015 by Jacob Kaplan-Moss and I think you will too. He makes a really great point in particular about how statistically, the vast majority of us are average programmers. That’s why they call it average! As much as we’d all like to be amazing programmers, I find something really comforting in knowing that realistically, I’m a perfectly normal programmer and so are you, particularly when I’m having a bad day and nothing works and I feel like a complete fuckup.

When you have a day like that, give that talk a listen and remember that statistically you’re probably just fine :)

Link of the day

in development, link of the day

We talk all the time about how often code is read vs written and how important it is to be good at reading code, but I’ve hardly ever seen anyone talk about how to get good at reading code. This excellent slide deck by Josh Matthews called How to Read Unfamiliar Code is one of the only times I’ve ever seen anyone even address learning how to read unfamiliar code, and it has a great case study with a really clear step by step method for understanding a feature in an unfamiliar codebase. I recommend checking it out!

Link of the day

in link of the day

One of the hardest parts of programming is when you’re just starting out and don’t even know the word for what you want to google. Wouldn’t it be great if there was a list of all the words and phrases you needed to know to even ask an intelligible question? Of course it would be unspeakably boring to read but that’s beside the point :)

If you’re interested in functional programming, some fantastic person did make a list of at least some of the terms you’ll need to know. It’s a work in progress and I would be surprised if it was even possible to make a list of every single term you’ll ever need to know for functional programming, but there’s still a lot of good stuff in there. Even if you’re not currently doing any functional programming I think it’s interesting to know what’s going on in there.

To comment or not to comment?

in Uncategorized

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.

One of many things nerds like to spend far too much time debating is whether or not to comment their code. On one hand, comments make code a lot easier to understand, but on the other, many people claim that good code is self-documenting.

If you haven’t been writing code professionally for long, it probably seems totally obvious that comments help you understand code you’re new to or haven’t looked at in a while. For the most part, they do help. The problems are that bad comments really don’t help and that comments only help if they’re correct.

What makes a comment a bad comment? If you’re going to add comments, they should explain why the code does what it does, not what it’s doing. Take the examples in this reply to a reddit thread – it’s totally unhelpful to add comments like “//Reduce’s player counter by 1” to a line of code like “mageCounter–;” That comment doesn’t add any information that isn’t in the code. Of course the counter is being reduced by 1, that’s obvious. What’s useful is knowing why the counter is being reduced.

Not only is that comment not helpful, it wastes space. The more comments like that you have, the less code you can see on the screen at once. Yes, that sounds really trivial, but seriously, it’s incredibly annoying to have to scroll up and down to see the whole method.

How can a comment be incorrect? If the code changed and the dev who changed it forgot to update the comment. Out of date comments can waste huge amounts of your time when you need to change a piece of code because everyone naturally assumes the comment is correct. If it wasn’t, why would it be there? Sadly, developers are only human and sometimes we get so excited about the code finally working that we forget to update the comment.

That’s part of why some people say that you should not have comments, that they’re a sign you didn’t name your variables and methods and classes well enough. It is true that if the names in your code are their own comments, then they won’t fall out of date the way actual comments can. On the other hand, there are limits to what variable names can tell you. I think the most important comments are the ones that explain weird code that works around a bug in an API or something strange you did for performance or just a workaround for a design choice that didn’t pan out long-term.

Those are the kind of things that self-documenting code just can’t document. There’s no method name that can explain why some of your tests use one dummy mailserver and other tests use a different one because there’s no single dummy mailserver that handles all of the test cases you need. At least, not without that method name being terrible code on its own and at that point, you might as well use a comment no matter how much you normally oppose them.

My view of comments is somewhere in the middle – I think they’re a great tool for keeping track of what you’re doing while you code, but once you’ve written the code you should only leave in the comments that are important to help understand it. As much as possible, you really should rely on good naming, if only because good names are always a good idea :)

And in general, I think absolutism is a waste of time. Even otherwise excessive “here’s what the code is doing” style comments could be really helpful if you’re working in a low level language or doing something clever with pointers where it’s just not immediately clear what the code is doing, let alone why. It’s more about context than it is about hard and fast rules. Surely you didn’t go into programming because you ever wanted to be certain about anything ;)