While I’m a fan of watching (well, mostly listening to) talks on YouTube, not everybody learns well from audio or hears well enough to deal with not-always-perfect audio. Fortunately, if you like text better Matthias Nehlson had some transcripts made for talks he was interested in and put them up on github so everyone can use them. Enjoy!
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.
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 ;)
In the spirit of thanksgiving (and not making you read too much when you’re just going to end up in a turkey coma), here are some things I’m grateful for:
Being lucky enough to enjoy doing a job I can make a good living at. The tech industry certainly has its flaws, but it beats the hell out of the jobs I had between high school and college where the only reason my employers didn’t pay me even less was because they legally couldn’t.
Incredible free resources like Khan Academy and the many, many MOOCs out there. It’s incredible how much stuff you can learn at no cost but your time.
Conferences that record their talks and put them online. Most of them have excellent sound and video quality too. Look at how many Sandi Metz talks you can watch without ever buying a conference ticket or even putting on pants!
Beginner friendly communities like Code Newbie and Java Ranch/Code Ranch. I love that there are places online where it’s okay to not know everything already.
Learn to code/learn to code better resources like Free Code Camp, Exercism, Programming Praxis, Code Kata, and so many more. People put incredible amounts of work into these tools just to help other people become better programmers and that’s awesome.
JSON – working with XML is generally terrible and I’m delighted JSON has become the new standard. It sounds petty but seriously, any day I don’t have to fight with XML is a good day :)
What about you, readers? What nerdy stuff are you grateful for?
If for any reason you ever need to center a circle inside of a another circle using CSS, here’s how. That delightful person even created a jsFiddle so you can test it out yourself. And in the spirit of almost-Canadian-thanksgiving, I give thanks for stack overflow :)
I was listening to the Developer Tea podcast the other day and caught a re-air of an episode about how to handle questions that you don’t have good answers to. The very short version of their answer (which I totally agree with) is don’t say “I don’t know” and stop there, follow it up with “but I can find out.” And then, you know, actually find out and follow up with the person who asked the question :)
It’s been such a long time since I worried about that that I forgot it was still an issue for people. I’m not saying I feel great about it when I get asked a question I can’t immediately answer, but my perspective is that my job as a developer is much more about knowing how to figure stuff out than it is about knowing the answers off the top off my head. I’m not Google, and it’s not reasonable to expect me to be.
My theory (and readers, if you think I’m out to lunch here, I’d appreciate you letting me know in the comments) is that newer devs are more likely to freak out about not knowing the right answer because they’re used to having to produce an answer right away or lose marks on tests in school. One of many, many ways being a professional developeris different from school is that there’s no time limit and everything is open book.
Seriously, no reasonable person is going to react badly if you tell them you’re going to find the answer and get back to them. And if they do react badly, they’re a jerk and if that jerk is your boss, you should seriously consider finding a new job. Production applications are just too complicated for any one person to remember every detail of the back end, the front end, the database, the logging, the monitoring, the API, the deployment process, or whatever other pieces you deal with. It’s just not possible for a person to memorize every detail of a complex system and if you think it is you have no business managing developers.
Speaking of complexity, a completely reasonable answer to a question might be “Amy built that feature, she would know better than I would.” Just telling someone where to look or who to ask is really helpful, it’ll make it easier for them the next time they need an answer. Sometimes, say if your boss asks you a question, they might need you to do the legwork and go ask Amy for them, but that doesn’t mean it’s not helpful for the next time they have a question about that feature.
Unlike school, very few parts of professional development involve a time limit. Sure, if production is down you’re going to want to figure out why as quickly as possible, but even that is more about problem solving skills than it is about having stuff memorized. If my boss asks me a question, it’s far more useful to them to take five minutes to go look it up and make sure it’s right than it is to spit out an answer right then and there.
Basically none of professional development is closed book, either. That’s one of the reasons for my very limited interest in general knowledge questions in technical interviews (the other one is that a stressful, high stakes situation like an interview is going to give you false negatives because people go blank when they actually know the subject perfectly well). Not remembering the difference between a StringBuilder and StringBuffer is never going to matter in my career, that takes about 30 seconds to Google.
“That’s great,” you say, “but what if I do all my research and I still don’t know what the best option is?” That’s totally fine! Write down what you learned and share that with your boss/whoever asked you the question. I’ve had plenty of conversations with my boss where I showed them what I found and straight up told them “I don’t know what the best thing to do is, but here’s what I found.” As long as you’ve done something to help find the answer you’ve at least saved your boss the time it took to research it, that’s still helpful.
Not knowing the answer is just not an issue as a developer. The issue is if you don’t make an effort to find the answer, and making an effort is something anyone can do.