The more I work with deep inheritance hierarchies, the more I wonder if inheritance is actually a good idea. If you’re looking to avoid the trouble overusing inheritance can get you into, this article has some handy tips: Inheritance is evil. Stop using it.
We all know we have personal biases, but have you ever thought about your software design biases? I certainly didn’t until I read this article about Software Design Bias by Sandro Mancuso. If you’re having trouble with the design of a piece of software, it’s worth taking a look at Sandro’s handy list of biases and thinking about whether the way you prefer to design software is actually the best one for the particular thing you’re trying to build.
Persistence is enormously valuable, I even believe it’s more important than intelligence if you want to a programmer, but knowing when to quit is valuable too. That’s why I like I successfully chased my Big Life Dream, and I hated it by Rowen, so much.
Their dream was to travel the world in a sailboat, yours might be to become a freelancer, to start your own business, to switch to game development, or something else entirely. If you try something and it turns out to make you miserable, it’s okay to stop and do something you actually like. I’ve read a lot of sad stories about people who made themselves miserable, put themselves under so much stress it wrecked their health, or financially ruined themselves pursuing a dream that just wasn’t working, and I really don’t want that for any of my readers.
On a lighter note, if you do New Year’s Resolutions, consider quitting something you don’t actually like instead of trying to squeeze more and more activities into your life. If that feels selfish to you, think of it as setting a good example for others :)
Learning Fluency, by Sara Simon is a really interesting article and you should definitely read it. It’s kind of hard to summarize, what I got from it was that there are a lot of parallels between learning natural languages and learning to program, one of which is that rote memorization is both really useful and really underrated. Variables and loops are really boring for experienced programmers (which I’m suspicious is why most programming tutorials zip past them pretty quickly), but just like it’s really hard to tell someone how to get to the grocery store in a new language until you’ve memorized enough words, it’s really hard to build a program before you’ve memorized enough programming constructs.
Another good point Sara makes is that not everyone learns the same way. Some people are happy to jump into a project and learn as they go, and other people need more structure to get started. That doesn’t make anyone wrong, but it does mean we need resources for more than just one kind of learner.
Learning Fluency is a bit of a long read but it won’t take your whole lunch break either.
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 :)
Julia Evans has a great guide to asking good questions, you should read it :) Asking good questions is such a useful skill, I wish programming education spent more time on it.
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.