In my last post about becoming a better programmer while still having a life, I talked about communication. Specifically, making sure you understand why you’re doing a task and what the eventual user of that feature wants to accomplish. That’s far from the only thing communication is good for, though. It’s not just about clarifying tasks, it’s also important to communicate status. Strictly speaking, this may not make you a better programmer in terms of getting things done. It does, however, make you easier to work with and that’s a big part of being a professional. And in the interests of full disclosure, I’m not always great at this, especially when I’m busy, but I try.
If you use slack, a good solution for my team and maybe yours is to post little updates about what you’re working on and how it’s going in your dev channel. When you share what you’re working on, people will have something useful to tell you surprisingly often. I’ve had coworkers tell me about existing code I hadn’t seen before that applies to my problem, ways they had already tried to do something and failed (super helpful because it narrows down what I have to try), or bring up potential issues I hadn’t thought of.
Team leads also really seem to like having a running list of what you’ve been doing and if you’ve hit any snags lately. In my office it’s common for people to work from home, which means my team lead can’t always rely on chatting with people in the lunchroom or on the way to get coffee to figure out whether our tasks are going well or not. My last set of updates were a series of complaints about how badly I was getting along with play 2.5’s requirejs plugin, don’t feel like you have to have positive or even particularly well thought out updates.
Nobody particularly likes to post a bunch of updates about how badly things are going, but that’s actually really useful for your team lead and the rest of your team to know. They can’t make plans about next week if they have no idea how much stuff is going to get done this week. Your team lead doesn’t just know what you’re doing or if you need help, you’ve got to tell them directly. If your updates are always about how badly things are going that’s a useful sign that something is wrong. It could be that you and/or your team lead need to find another solution because the current one isn’t working, it could be that your assignment isn’t at the right level for you and you need some help, it could just be that it’s an especially hard task and you’re not going to be available to do anything else for a while.
If something is going poorly, it’s always better to talk about that sooner rather than later. Seriously, waiting too long to raise the alarm kills projects. Now, it is true that in dysfunctional workplaces you may be blamed or punished for bringing up perfectly reasonable concerns. I’m not going to pretend that every boss you’ll ever have will be the perfect manager, but if you bring up a concern and get ignored or punished for “being negative” I want to reassure you that you are not the problem and didn’t do anything wrong.
If things are going well, you should talk about that too. Just like your team lead needs to know if they can’t give you another task, they need to know if they do need to get another feature specced out and ready for you to work on next.
Whether or not you ever show anyone else your list of things you got done (and it’s not a bad idea to have that handy for when annual review time comes around), just looking back at your list can help motivate you. When I feel like I haven’t been accomplishing anything, it can be really helpful to scroll back through the updates I’ve given and remember that while I maybe didn’t end up with a lot to show for my fight with requirejs, I did learn a lot about play 2.5 plugins and build processes and that will definitely be useful later.
If ongoing updates throughout the day are too much information you can do daily or weekly updates, the only essential part is giving updates on a regular basis. Definitely don’t feel like you need to write a novel for every update, status updates are meant to let people know what you’re up to, not to eat up time you could be using for your actual work.
Giving status updates regularly probably sounds like a really small thing, but it’s been incredibly useful for me.
In my last post I said that being a better programmer wasn’t worth sacrificing your entire life outside of work, but that doesn’t mean being a better programmer isn’t worth some work. Also, sacrificing all of your free time is simply not necessary. There are lots of things you can do to be better that don’t involve never seeing your friends again and/or being a bad partner. Lots of them!
Here’s tip #1 for being a better dev without killing yourself over it:
Specifically, when you get a task, ask some questions to make sure you understand it. Some of the most important questions are the ones you’re scared to ask because you don’t want to look stupid. Like “What is feature x for?” Just because the JIRA ticket says to build an x doesn’t mean the business really needs an x. They might actually need outcome y and think that building an x is the way to get it.
Once you understand why the business needs an x you might be able to suggest a simpler solution – sometimes you don’t need a week of dev time, sometimes all you need is a cron job. Sometimes there’s a library that can do what you need quickly and easily. Sometimes there’s a product or service that does what you need for less than the cost of the dev time, plus if it breaks you may be able to make it their customer support’s problem instead of yours :)
Even if you don’t have a better solution, it’s really helpful to understand why you’re doing something and what you’re really supposed to accomplish. No spec is ever perfect, you’re practically always going to have to make some decisions on your own – knowing the reason behind what you’re doing lets you make way better decisions than if you’re just trying to guess what might make sense. That’s how things nobody wants get built (well, one of many ways they get built, let’s not pretend there’s only one cause) – somebody gets a vague spec, takes their best guess, maybe runs into some problems and has to cut part of it, maybe some of the parts that get cut are actually really important but the dev didn’t know that and now we’ve got a feature nobody wants.
Another good reason to ask questions is to clarify the spec. If you run into anything that needs more details or contradicts some other part of the spec, it’s better to know that before you start building. Nobody likes having to go to their boss after days of development and tell them that they just realised that to build the feature properly they need to build z too and that means they have to throw out the code they already wrote that only supports x and y. Nobody likes hearing that either, so think of the time you spend asking questions as an investment in not disappointing your boss/missing your deadline later.
You might find a whole extra set of problems that need to be figured out before you can build the thing you were originally supposed to. On a large project at work I found out partway through that I hadn’t put nearly enough thought into how new settings for an extension of an existing feature were going to work with the original settings. I could have saved myself a lot of time building and rebuilding handling for that if I had asked more questions in the beginning (and done a better job of planning everything out before I started building it, but that’s a separate blog post).
Not only are complications like that really useful to know about for the sake of building something only once, but the feature might get scoped down or cut entirely if it’s too much of a hassle to do it properly. That might sound disappointing but how much more would it suck to waste days or weeks of time on something that’s never going to work correctly?
And the bet part? Asking questions about work while you’re at work doesn’t touch your free time at all!
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!
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.
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 ;)
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.
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 ;)