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.
Slightly related image from pexels.com to make this post look nicer in social media shares.
One of the most common misconceptions I’ve heard about programming is that you have to be a math whiz to be a good programmer. I’ve mentioned this before but I want to attack that particular stereotype more directly.
It is true that there are similarities between math and programming – programming uses some math terms like function and variable, it’ll be a lot easier to get things onto the screen if you understand coordinate systems, and of course to do math or programming you spend a lot of time manipulating symbols and thinking abstractly, but you know, programming is also a lot like language. I mean, they call them programming languages for a reason. To quote Hal Abelson, Jerry Sussman and Julie Sussman’s book Structure and Interpretation of Computer Programs:
First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
Programming is fundamentally about communication. Not only are you communicating with the machine, you’re communicating with your future self, the rest of your team, and potentially other teams if you end up working for a large enough company. And that’s just when you’re writing code! You’ve also got to make sure you’re building the right thing and let other people who are waiting for that thing know how it’s going. You know what’s great practice for communication? That’s right, English classes! Sarah Mei has a great blog post about the same point I’m trying to make in this one, here’s an especially interesting quote:
The students I saw – all adults – came from a wide range of backgrounds. People with a math background did fine, of course, but people with a heavy language background often did better.
Nobody seems to have an official study on this, but I think there’s something there. Language requires just as much abstract thought as math does, with the added benefit (to your communication skills) of failing your classes if you can’t make yourself understood to anyone else. As a bit of an aside, the biggest problems I’ve run into at work have never been problems of pure programming skill (although those ones do suck a lot), they’ve been communication problems with team members, other teams, management, other departments entirely and other offices.
And to stick another nail in the coffin of the idea that programming is math, I’ve been a developer for ten years now and the most complicated math I’ve ever had to do at work is stuff like “if I have a div that’s x pixels wide and y pixels tall and I want it centered inside another div that’s a pixels wide and b pixels tall, what should my margins be?” I used to believe that programming was math, and some programming is certainly math heavy, but it’s hard to argue with the lack of math in my day to day job over ten years and four companies.
So given that programming is not math, why do so many people think it is? I’m going to quote Sarah again because she already said it really well:
When programming was just getting started, early in the last century, we used it to solve highly mathematical problems like calculating missile trajectories and decrypting secret messages. At that point, you had to be good at math to even approach programming. Tools, such as programming languages, were designed specifically to solve mathematical problems, because those were the ones we thought it was worth spending money on. Computers were for doing math.
I think another issue is the way we teach programming (credit where it’s due, I stole that idea directly from a comment on Sarah’s post). Computers are great at doing boring and tedious calculations, plus it’s easy to tell them how to do it, so why not start teaching programming by having students make the computer calculate something for them? It makes it really easy for the students to check their work too – assuming they’re able to do the math problem themselves, they can easily check if the computer got the same answer.
That assumption can be a real problem, though. If you can’t do the math problem or don’t care about the math problem, you end up effectively shut out of programming, something you could very well be great at, because of something that has next to nothing to do with the actual job of software development.
If you can do basic arithmetic and deal with the concept of variables, congrats, you can be a programmer! That is literally all the math you actually need!
Unrelated image from pexels.com to make this post look nicer in social media shares.
Willpower is a big deal when you’re doing an inherently difficult and frustrating task like programming. It’s also something we tend to assume we either have or we don’t, but there are actually a lot of things we can do to improve our chances of making it through a willpower challenge whether that’s making yourself write boring documentation or resisting the urge to screw around on reddit all afternoon instead of doing your work.
Kelly McGonigal gave a talk called The Willpower Instinct (not so coincidentally also the title of one of her books) about that exact subject at Google. It’s a really interesting talk and I recommend watching it, but it’s also an hour long so I’m going to list the takeaways here. Full disclosure, some of these things will take up a little bit of time outside of work, but they will definitely not eat your life and will be useful for way more than just being a better programmer.
1 Sleep! Just getting enough sleep makes it much easier to make decisions that support your long term goals/resist choices that sabotage your long term goals. Meditation helps too, that was the tool used to improve sleep in the study Kelly McGonical referenced. That study was done on people in rehab for drug addictions, and even with an urge that strong to use drugs, simple sleep and meditation made the partipants much more resistant to relapse than the control group. Something really cool about that study was that the participants got those fantastic benefits from meditating for only 10-15 minutes a day.
There’s a lot of really interesting stuff in the talk about how different parts of your brain actually work together (or don’t) when you need to use your willpower to delay gratification or work toward a distant future goal, but I’m not out to transcribe the whole talk here, you’ll have to watch it for all the details :)
2 Stop beating yourself up when you make a mistake. Beating yourself up doesn’t actually improve your willpower at all. It turns out that the harder you are on yourself when you have a willpower failure, the sooner you fail again and the worse it will be next time. The worse you make yourself feel, the more you want comfort, and the more you want comfort, the more likely you are to turn to the exact thing you’re trying to stay away from, whether that’s chocolate, alcohol, cigarettes, or excessive youtubing. It actually works much better to have compassion for yourself and just try to do better next time.
3 Learn to identify with your future self. Most of us feel like our future self is a stranger, and the more you feel like that, the less likely you are to do things to protect that stranger’s health and happiness (like exercising or saving for retirement). Who here has cursed their past self for not commenting their code? We all know that we should, but we hardly ever do it. I think a big part of that is that we somehow don’t believe the frustration our future selves will feel when they have to work on another piece of badly commented code is as bad as the frustration our present selves feel.
One way you can get to know your future self is by writing a letter from them to your present self. This can either be a general letter about who future self is and what they’re up to, or a more specific letter thanking your present self for doing the work of exercising more, quitting smoking, or actually commenting that code even though it seems perfectly clear right now.
4 Imagine yourself failing. It’s totally counter intuitive, I know! The idea is to think about how things could go wrong for you so you can come up with workarounds. Say you want to exercise more, if you know that you’re likely to put things off until it’s too late at night to go for a run, you could leave yourself notes or set reminders to make sure you actually go for that run. If you keep track of what goes wrong for you and basically become a detective of your own failure, pretty soon you’ll have a comprehensive set of workarounds / ways to avoid the things that trip you up.
It’s also really helpful if failure doesn’t come as a shock to you – it’s easier to shrug it off and try again if you’re a little bit pessimistic and go “okay, I know I’m going to fail at this a few times, what am I going to do when that happens?” Sure, it seems obvious that the answer is “get back to the thing I was doing to reach my goal” but if failure is a surprise then it’s really easy to decide, “welp, I missed two workouts this week, I’m fundamentally a failure, no point in trying again so I might as well sit on the couch all weekend watching tv” even though two workouts are just not a big deal in the grand scheme of things and you could easily get back on the wagon by working out on the weekend.
5 Learn to tolerate discomfort. In her talk Kelly McGonical mentioned that the ability to hold your breath for 15 seconds is actually a very strong predictor of how well you will do in willpower challenges. There’s a technique called “surf the urge” that relies on that idea. When you “surf the urge” you give your full attention to your craving and trust that if you just sit with it for a while, it will pass. Immediately trying to repress the urge, whether it’s to have a chocolate bar or to screw around on reddit for three hours, just teaches you that the discomfort you’re trying to avoid is intolerable and you Absolutely Must Do Something About It Right Now. That’s just not true, you’re a grownup, you can ride it out. What you do by surfing the urge is break the link between feeling stress and opening that tab, which makes it much much easier not to give in.
And finally, here are some much less evidence-backed tips from me:
A Outsource your willpower if you can – browser extensions like stayfocusd (I haven’t found a really good mobile app yet, recommendations welcome!) that just don’t allow you to spend all afternoon screwing around on Facebook mean you can take all the energy you would have spent resisting the urge to open that tab and spend it on something else.
B Build habits. Once something is a good solid habit it takes way less willpower to keep doing it. Flossing, for example, is boring and a hassle but once it’s a habit it feels way more weird not to do it than to just get it over with. I recommend BJ Fogg’s Tiny Habits course if you want to make more things a habit so you can stop thinking about them.
Unrelated image from pexels.com to make this post look nicer in social media shares.
Today’s tip for becoming a better programmer while still having a life isn’t just good for you, it’s good for your whole team. That tip is documentation.
I know, nobody actually likes doing documentation. Fortunately, I’m not talking about dry design docs or endless specifications, I’m talking about a simple wiki (or whatever works for you), written by you and your team for you and your team. It doesn’t have to be polished, it doesn’t have to be formal, it doesn’t even have to be spelled perfectly. All it needs to be is correct and understandable. The idea is to explain things just like you would to another dev on your team, not to waste hours proofreading.
Great, but what should you document? In short, anything you’re going to want to know later. Especially useful things to write down are why architectural decisions were made, how parts of the system work at a high level, guides to testing certain features (great for complicated payment provider integrations, not that I’ve been fighting with those), and especially guides to setting up your development environment, whatever that thing is that you forget every time and have to look up again or ask someone about.
Just saving yourself time relearning parts of your codebase will help you get things done faster, which is basically being a better programmer, but explaining things (even if you’re writing to yourself) helps you understand them better. Explaining something forces you to think about every little detail, and putting something in your own words helps it stick in your brain – it’s the same principle that helps you remember things better when you take notes on them, whether or not you ever look at those notes. The better you understand your codebase, the better decisions you can make about how to add new features or fix bugs.
As a bonus, reflecting on why you made certain decisions and being able to go back later and see if the reason you did things the way you did holds up over time also makes you a better developer. You don’t even need to make a special effort to do this, if code gets used it gets changed. All you need to do is wait, eventually you will have to revisit the code you documented and by the time you do that, you will probably have forgotten the details and will need to go look it up in that handy wiki you created :)
Writing things down also helps you get that answer again without interrupting anyone, and the less you can interrupt teammates the better considering how expensive interruptions are for programmers. I couldn’t find a hard number, but I feel comfortable saying that it takes at least ten minutes to get back into a complex task like programming once you’ve been interrupted. It can be even worse if you get interrupted at just the wrong time. I have a terrible time getting into a task when I know I’ll have to stop soon for a meeting or appointment or whatever, which means an unfortunately timed interruption can kill a solid half hour of productivity even if it only took a couple of minutes to deal with the interruption itself.
All the benefits you get from making knowledge about your code available and searchable also apply to your teammates. If you just document how to set up your development environment, that can save hours every time someone has to set up their environment whether it’s a new employee starting or a long time employee getting a shiny new computer to replace an old one. It’s even better for everyone around you if the whole writing things down idea catches on – then they also get the benefits of explaining things and documenting the particular things they forget and need to look up as well.
And best of all, this is another work thing you can do at work that has no effect on your personal time.
Unrelated image from pexels.com to make this post look nicer in social media shares and because red pandas are adorable.
As much as we would all like to believe that programming is about logic, not feelings, being able to deal with your emotions is incredibly important if you want to be a better programmer. For example, one of the best things you can possibly do for you career is to learn to take criticism. Logically everyone should be thrilled to get feedback on their work but you know what gets in the way? Yep, it’s emotions.
It can suck to hear all about what’s wrong with your code, especially if you worked really hard on it and thought that this time you finally got it right. Hearing about what you need to improve is incredibly helpful (who has time to make every possible mistake on their own? that would take forever!), but that doesn’t mean it never hurts your feelings. And when people’s feelings are hurt, it’s really hard for them to listen. Sometimes emotions get in the way of your improvement as a developer.
So how do you learn to take feedback even when it hurts?
First of all, you’ve got to accept that it’s normal to have feelings about being told that your code isn’t good enough. There’s no fixing a problem that you can’t admit is happening, after all. That absolutely does not mean you should be ashamed of having feelings – not only is it just plain wrong to shame anyone, including yourself, for being human, but it’s a huge waste of time. All it means is that if your feelings are keeping you from being able to take feedback, you’ve got to get a handle on them. You would debug a program that couldn’t handle certain inputs, right? Sometimes your mind needs debugging too.
One way to do that is to remind yourself that feelings aren’t facts. Just because you feel attacked or like everything you do is stupid and terrible and you’re never going to be any good at this and should just crawl into a hole doesn’t make it true. That’s just your brain freaking out, if you give it a minute it will calm down. Yes, it sucks in the moment to hear that your code needs work, but you’re going to feel fine tomorrow. With practice, you’ll get used to hearing what you can improve and start skipping the boring angsting step to go directly to fixing things.
A common thing programmers do that makes that way harder is to get really really really attached to their code. You should absolutely care about whether you’re doing a good job but you’ve got to remember that your code is not you. The quality of your code has nothing to do with your worth as a human being and any one piece of code doesn’t even mean much of anything about your skills as a programmer. Everyone has off days, making a mistake does not mean you’re a bad programmer, will always be a bad programmer and should just go find a hole to crawl into. Everybody makes mistakes, you’re not that special ;)
Quick side note: code reviews are never supposed to be mean. Aside from being a tremendous dick move and thoroughly unprofessional, it’s a waste of time to be a jerk when you’re giving feedback. If people hate doing code reviews they will find ways to not do them and the quality of code on your project will suffer. If you can’t be nice because it’s right, be nice because it’s effective. And if your team lead/senior dev/whoever does your reviews can’t at least be civil, find a new job. Life is too short to put up with dicks.
Something else you can remind yourself about when you’re having feelings about a code review is that nobody gives advice to people they don’t believe can do better. If you believe someone can’t learn you don’t bother giving them a code review, you quietly fix what you can while they’re not looking and hope they eventually get fired. Bothering to give someone feedback is a statement that they’re worth the effort.
The most important piece of advice I can give you, though, is that you need to be able to take a step back both from your feelings. Meditation is great for this, by the way. I’m going to steal Headspace’straffic metaphor here because it’s really good: training your mind isn’t about forcibly clearing it, it’s about learning to watch your thoughts and feelings go by like cars on the road and not needing to run out into the street and direct traffic. Having a feeling doesn’t mean you have to do something about it right then, you can wait a bit and see if it’s still important.
That stepping back thing is useful for more than just code reviews, too. Professional software development can be really frustrating for reasons that have nothing to do with writing code. Features get changed or cut, projects get dropped, companies change direction, sometimes things never make it into production no matter how much you believe in them or how hard you try. If you can’t step back from your attachment to a project and accept that things don’t always go the way you wish they would or even the way they logically ought to, you’re going to have a bad time in this field (or any other for that matter).
While you’re at it, literally step away from the computer now and then and do something else. Not only can you become a better programmer and still have a life, but having a life will make you a better programmer. Nerds tend to hyperfocus, which is great when you have a concrete task to get done but not quite as great when you lose all sense of perspective because you do nothing but code all day. Having other things you’re good at and other things to look forward to really helps put that one bad code review into perspective.
Unrelated image from pexels.com to make this post look nicer in social media shares.
More stuff you can do to be a better programmer while still having a life!
The core of programming is really problem solving, but we’re kind of expected to pick it up as we go while we’re learning specific skills like programming in java. I have a strong suspicion that’s why so many new developers feel totally lost when they try to build something on their own: we’ve collectively done a bad job of teaching them how to break down problems and solve them.
Problem solving is a gigantic topic so I’m not pretending this blog post is going to be comprehensive, I’m just aiming to share a few tips to get you started.
First of all, don’t just start coding. It really helps to have some sort of plan for what you’re going to do. If you dive in and just start coding without any sort of plan you’ll often end up lost in the weeds because figuring out how to solve a problem and how to code that solution at the same time is so much harder than doing those things one at a time.
Ironically, it’s also hard not to do those things at the same time. It’s really common to feel like you’re wasting time planning and making lists when you should be writing code, or that planning is boring and no plan is ever perfect so why bother? It’s also not at all unusual for programmers to start coding without a plan because they’re worried about whether they can solve the problem, so they just start writing code and hope the complete solution will come to them.
Having a plan actually speeds things up because it cuts down on the feeling your way around in the dark that you end up doing when you don’t know where you’re going or how to get there. If you really can’t stand the planning part, programming may just not be for you – solving problems is the real job, code is just the tool we use to solve them. Making a plan may force you to admit that you just don’t know how to solve a certain problem which sucks, I’m not going to lie, but isn’t it better to figure that out right away instead of potentially spending days or weeks coding only to find out that your partial solution is never going to work? Trust me, that sucks way more.
So that’s all great, but how exactly do you break down a problem and make a plan to solve it?
One example is laid out in 5 Steps to Solving Programming Problems by Adrian Prieto. The step I want to concentrate on is “2. Solve the problem manually.” Seriously, write it down exactly the way you would do it if you had to do it manually. If part of the problem involves looking things up in the database, just pretend you have a gigantic binder or that you can call another department for the data you need. The imaginary manual procedure might sound really awful and tedious but that’s fine, computers are great at boring and tedious.
Example time! A common programming challenge question is to write a palindrome checker – you give it a string, it tells you whether or not it’s the same backwards and forwards. It’s really easy to look at a short palindrome like racecar and see that it’s obviously the same backwards and forwards, so let’s imagine we have a much longer string. Now how do we tell whether or not it’s a palindrome? One way is to look at the first character and see if it’s the same as the last character, then the second character and the second last one, and keep doing that until we get to the middle of the string (let’s assume for now that we don’t have to worry about spaces or punctuation). If we make it to the middle of the string it must be a palindrome, so we can return true. If any of the pairs of characters don’t match then it’s definitely not a palindrome, so we can stop checking right there and return false.
Now that we have a manual process, we can start adapting it for a computer to run. The thing you have to remember is that computers are really dumb. If you tell a person “stop when you get to the middle of the string” they’ll know what you mean and what to do if the string has an odd number of characters so there’s only one in the middle. Computers, on the other hand, don’t know what a “middle” is unless you tell them and don’t know what to do with a string with an odd number of characters either. For that matter, they don’t know how to tell they’ve gotten to the middle of the string.
In the interests of not making this post 5000 words long I’ll skip the specifics of telling a computer how to find the middle of a string, the important thing to know is that once you have an overall process you can dive into subproblems like “how can the computer tell when it has checked enough characters?” without losing sight of why that problem even matters and how it fits into the rest of your solution.
It really doesn’t matter how bad your first try at a process is. Writing down how you would do it manually is always good enough for a first try, and once you have a basic process you can start improving it or even trying totally different algorithms. The great thing about a simple set of point form instructions or even pseudocode is that it’s much quicker and easier to change than actual code, so you can mess with it to your heart’s content.
That works great for straightforward problems, but what do you do with an overwhelmingly large problem where it’s not obvious where to start? Let’s say you want to build a todo list app. Should you start by designing the UI? Or by figuring out what your data model should look like? How do you decide which features your app should have?
The question about what features you should have is one of the simpler ones: build the tiniest thing that could possibly work. You can always add more features later. In the case of a todo list app, I would start with being able to add new todos and being able to cross off existing ones. Don’t worry about subtasks, don’t worry about due dates or recurring tasks or anything else, just start with the simplest thing that could possibly be considered a todo list.
As for where to start, if I knew the right way to approach every problem I’d be a millionaire :) I personally like to start with the UI so that once I get down to the data model I already have a list of all the visible information that I definitely need to store. On the other hand, if you’re especially comfortable with data modelling it can be easier to start there. That can also save you from building a database that’s perfect for one screen and kind of terrible for everything else. It really doesn’t matter where you start as long as you remember to look at your overall design from different angles and see if it still makes sense.
At the “boxes and lines” diagram stage just like the point form description of a manual process stage you lose hardly any time at all if you sketch out a solution, figure out it doesn’t handle something well, then throw it out and start over. The important thing is to learn more about the problem, not to come up with a perfect design on the first try.
Like communication, practising problem solving doesn’t have to take up a single hour of your time outside of work. You can get all the practice you need on work problems while you’re at work and still have a life outside of work :)
Unrelated image from pexels.com to make this post look nicer in social media shares.
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.
Unrelated image from pexels.com to make this post look nicer in social media shares.
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:
Communication!
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!
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.
I first learned about the concept of funnels from sales funnels, where you start at the top with lots of people who are simply aware your product/service exists, and work your way down through getting them interested in your product to making a decision about whether to buy to eventually making a sale, with fewer people at every level. That’s normal for sales (and for any other funnel, like hiring), not everyone who is aware of your product is going to want it. Many of them may not even have a problem your product solves. Some people go with competitors, some people just keep doing what they’re already doing, some people are ready to buy but at the last minute they lose their budget or their boss decides to change direction, all sorts of things happen. Because of that, you need a lot of potentials at the top of the funnel to make sure anyone makes it all the way down to the bottom.
Sounds a bit like hiring, doesn’t it? ;) The big difference with hiring is that you either need to get people into the top of the funnel before you have an open position for them or you need to fill that funnel up extraordinarily quickly once you do have that open position.
The big thing I learned about that is that lots of people don’t think exactly like me. I’m sure that’s all kinds of helpful :)
More precisely, what I learned is that it’s normal to start talking with people before you actually have a job to fill and that doesn’t make you a time-wasting jerk as long as you’re honest about not having an open position right then.
The reason I had so much trouble with that idea was because I don’t usually bother talking to other companies until I’m Capital D Done with my current company and am actively interested in a new job. Since I thought that way I assumed everyone else did too, and because of that I figured talking with potential hires about a job that didn’t exist yet would be a mean-spirited waste of their time. I mean, they could have been talking with someone else about a job that actually existed and started making real progress toward their goal of finding a new job instead of wasting time on maybes with me. I’m not saying it was perfectly rational to be that worried about wasting people’s time, just that it was a thing I worried about.
But apparently it’s also normal for people to start talking to other companies well before they reach the Capital D Done stage, which makes it not a jerk move to talk with them about a job that doesn’t exist yet – as long as you’re clear about the job not existing yet, of course. I’m harping on that point because I feel very strongly about not jerking people around and because that’s the big thing that makes talking with people without having a job opening to interview them for work for me – I have to know I’m not jerking them around or I just feel weird about the whole thing.
Honestly, it’s probably smarter to start looking around before you desperately need a change, but the flip side of my not wanting to waste candidates’ time is that I don’t want to waste hiring managers’ time either. I assumed they only started talking with people because they had a job they needed to fill, which would make it a waste of their time to talk with them before I was sure I wanted to leave my current job.
I never really thought about how much time it takes to fill a hiring funnel (have you ever tried to hire an experienced developer in Victoria? It’s hard!), so I never realized how useful it actually is for hiring managers to have some people already in the funnel. If you have that then when it’s time to hire you don’t have to start from scratch, you can interview people who you’ve already talked to, who you already think could be a fit, who are already interested in your company. That sounds pretty great if you’re looking to hire, which makes it not at all a jerk move to talk to hiring managers before you’re sure you want to change jobs – again, as long as you’re honest.
In short, the moral of the story is that not everyone thinks the exact same way you do and that as long as you’re honest about what you have to offer you’re not being a jerk :)
