Somehow I came across a link to this one episode of a podcast called Reply All. That particular episode is about Anxiety Box, a delightfully odd project by Paul Ford. He was dealing with some pretty serious anxiety and being a nerd, decided to write a program to be anxious for him. It’s a really interesting story, and while Anxiety Box is now defunct, all the code is available so you can run your own external jerkbrain if you like.
Today’s link is a reminder that no matter how great you think your favourite language is, every language has flaws. Some people like to go around talking about how their favourite language is the best language and every other language sucks, but that’s much more about personal preference than it is about any one language being objectively better. Different languages are good for different things anyway.
Read a little YourLanguageSucks and don’t be a jerk about other people’s favourite languages :)
Today’s link is a companion to my earlier post with resume advice. After resumes come interviews, and in those you’ve got to ask your interviewer a few questions. When you’re just starting out it’s really hard to know what’s okay to ask or what you would even want to ask. Fortunately Jen Hamilton compiled a fantastic list of questions to ask interviewers from various sources (they’re linked at the bottom) and her own interests and experiences.
A couple of questions I’d like to highlight are these ones:
Flex time/core hours? Is variability tolerated or is everyone expected to be on the same schedule?
Is it possible to work from home, say, 1 or 2 days a week? Does anyone do this?
Just because a lot of companies that hire developers work normal 9-5 hours doesn’t mean they all do. I’ve heard enough horror stories to strongly recommend asking exactly when you are expected to be in the office/available online and whether it’s going to be a big deal to work from home to let the field tech in to fix your internet connection.
Today’s link is a set of nifty Chrome dev tools tricks. I don’t know about you but I haven’t done much front end work lately, which means I keep forgetting that things like DOM breakpoints exist. Even if you work on front end code all the time, maybe you’ll find a useful tip in there too :)
Getting really good at asking questions is also a great hack for looking like a better developer (it’ll also help you actually become better, but in the short term it’s a good hack). When you ask a bad question, like “My code isn’t working, can you help me?” people have to wonder what you’ve tried already or if you tried at all before giving up and asking someone else. If you ask the exact same question with more detail, especially about what you tried already, like “I’m trying to send an email but I’m getting an error message I don’t understand. I tried googling it but I got a bunch of different answers and I don’t know which one applies to my problem. Can you help me sort through them?” then it’s obvious that not only did you not immediately give up, but you also respect your answerer’s time enough to make it as easy as possible for them to help you. Telling them what you’ve tried already means they can skip suggesting things you already did, and asking a specific question means they don’t have to do the work of figuring out what the question actually is before they can even start thinking about how to answer it.
People love it when you make things easier for them, and when you show them you’ve put some effort into doing so, they’ll think you’re a better programmer than the person who makes getting the real question out of them like pulling teeth even if both of you are around the same skill level. That’s the hack part :) The becoming a better programmer part is that stating a question really clearly (yay rubber ducks!) and listing everything you’ve tried already may trigger that flash of insight about what you haven’t tried but should or what assumption you made that could be wrong. If you get into the habit of reflecting on what you’re doing, you’ll learn a lot faster than someome who sits around and waits for help.
This post titled How I Ruined Office Productivity With a Face-Replacing Slack Bot (Without Really Knowing What I Was Doing) has been floating around the internets lately so you may have already seen it. Even if you have, it’s an interesting example of how a programmer breaks down a new problem and experiments with the pieces before putting it all together. I especially like how that post shows the tiny experiments Jason started with and how those built on each other.
Check it out, I’m part of Sravanti Tekumalla’s collection of interviews with programmers called Always Be Improving: Curating Developer Experiences (I bet you can guess what they’re about :) )
Hey nerds are you taking care of yourselves? Check out this great list of self care resources for devs and others. Even if you already feel good, it’s worth taking a look at. I mean, it wouldn’t exactly be terrible if you felt even better now would it ;)
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!
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.