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 :)
You might have guessed from my extremely wordy blogposts that I like writing as well as programming :) Aside from having a personal interest in writing, I think there are some really useful parallels between writing and programming.
Let’s talk about one of them: separating writing and editing. This is a pretty common piece of writing advice, I’ve seen it all over the internet.
More specifically, what separating writing and editing means is that when you start a piece of writing, you don’t edit, you just get your ideas out onto the page. Only after you have a complete first draft, whether that’s a blog post or a novel, do you edit it. Editing can be as simple as fixing typos or as in-depth as moving whole chapters around.
Why is editing while you write such a bad idea? We’ve all written essays for school and edited while we wrote and we survived, right? Well, we did, but we also put in way more effort than we had to. It is totally possible to edit while you write and turn out a perfectly good school assignment, or even a professional article or book, it’s just way more work than it has to be to do it that way. It takes for-freaking-ever too and we’ve all got other things to do :)
Separating writing and editing makes you way faster. Yes it works better if you have a little space between the writing (drafting/outlining) and editing steps, but you’ll spend less time altogether on a piece of writing if you put a day or two between those steps.
But why is that? Writing isn’t that hard, and editing isn’t that hard (to be fair, I’m saying that as someone who has always had an easy time with writing), so what’s the problem?
Part of it is that people just suck at multitasking. Fiddling with your words is a very different task from getting them down in the first place, but I think is the real issue is that editing and writing at the same time is mixing two steps that need to be done one after the other.
It doesn’t actually make sense to worry about how you’re saying it before you’re done sorting out what you want to say in the first place. That’s just going to make a mess.
Okay great, how does this relate to programming?
Programming is in many ways a very similar process to writing. You need to know what you want to do before you can figure out how exactly to do it. Programming is certainly more rigid, with writing you can still make yourself understood with a misspelled grammatical trainwreck, but it’s not so very different either. You can start a piece of writing and know just what you want to say and then discover it just sucks and you have to scrap it and start over.
What you want to do with a program can be more tightly constrained by what’s feasible given the existing system/libraries available/limitations of the language you’re using, but in some ways that makes it easier because there’s no debate over whether your program works or not, you can just run it and find out.
When you’re writing code it’s very simple to separate writing from editing: write pseudocode first. Figure out what you want to accomplish (yes that’s a big enough problem for many books on its own, but that’s another blog post) first, then break it down into simple steps, then start implementing it after you know what you want to do. It may turn out that there’s a technical reason your original plan won’t work, but you can still iterate on that and make a new plan before trying to implement that one.
If you find yourself stuck on a problem, you might be trying to do too many things at once. Try separating what you want to accomplish from how you want to do it.
Yes, but not the way the questioner seems to think. The bad company in this case is very disorganized, which I’m sad to say isn’t exactly unheard of. That company does sound like an especially bad example, but if you get a few developers together you’ll hear plenty of very similar horror stories. However, I don’t think a company like that will necessarily hurt your career, especially if you’re a junior like the questioner. No reasonable human being would blame a junior dev for not being able to completely change the culture of a company.
However, I do believe there are other kinds of bad companies that can hurt your career: companies with extremely low standards, and companies with such extreme culture problems that only terrible people succeed.
Companies with extremely low standards can really hurt your career if you stay there too long. If you stick around too long at a company or other organization that has a reputation for low standards, then people start wondering if you haven’t left because you can’t do better. The longer you stay there, the more it looks like you know you can’t get a better job and the harder it becomes to find another job. It doesn’t even have to be true that your company has low standards – if it used to be true or if it’s that one department giving the place a bad name or if people just believe it’s true for whatever reason, your resume is still going in the nope pile whether that’s actually justified or not. You don’t need to panic immediately if your new job turned out to be easier than you were expecting, but I strongly recommend leaving before too long. Of course, it can also make you look unreliable if you have a lot of very short stints at different jobs on your resume, but that’s a separate blog post :)
Companies where terrible people succeed (I’m looking at you, Uber) make people wonder if you’re terrible too. That’s very bad for your career in a field where you basically have to change jobs to get a meaningful raise or title bump. To be fair, Uber is a large company and it would be surprising if every last manager/executive/team lead/other influential person was a complete trashfire of a human being, but if I interviewed a dev from a questionable company I would have a lot of pointed questions. In particular, I would want to know how well they did in terms of promotions and other recognition, and what they think makes someone a good developer and a good team member. Getting regular promotions at a terrible company might be innocent, it could mean you worked with one of the few decent managers, but it probably means that you got along well with a terrible manager. You know who gets along well with terrible people? Other terrible people. I’d also be very worried that someone from a terrible company thinks it’s okay to be a total jerk as long as you write a lot of code. Not only is that terrible for team productivity, but it’s also just wrong to make your teammates spend eight hours a day with a jerk.
On the upside, as long as you don’t work for a company that’s known for never firing anyone or for being gross and awful, your career is going to be fine. Over the long term a disorganized company can do some damage – it’s not going to look good if you end up with five years of development experience and no idea how to use version control, for example – but that takes quite a while and you can mitigate it with side projects.
In short, it’s very hard for any one company to wreck your career. Ten years from now nobody is going to care who you worked for in 2017.
The more I read about the struggles beginner programmers have and the more I mentor at Ladies Learning Code workshops, the more I think that repetition is seriously underrated when it comes to teaching anything technical.
When you’re learning a language or an instrument or a sport or a physical skill like plumbing or carpentry or even math, which is similar to programming in a lot of ways, you expect to have to repeat the same thing multiple times before you remember all the details and get it right every time, but somehow when you’re learning to code we assume you should only need to be told how a for loop works once and you’ll understand it perfectly right away and remember it forever. That’s just not how our brains work and that’s why I think repetition is so underrated.
It is completely normal to need to write a lot of for loops before you get it right every time. Some people do pick up programming concepts very quickly but that doesn’t mean you’re dumb or abnormal if it takes you longer. Something like a for loop (or anything programming construct) seems simple once you understand it, but there are actually an enormous number of fiddly little details you have to keep track of to get your loop to work. You know what’s a great way to learn all of those details so thoroughly you hardly even think about them anymore? That’s right, repetition!
Programming isn’t just a matter of understanding the concepts, you’ve also got to learn them so thoroughly you don’t have to think about how to write a loop, you just write one when you need it. Without that thorough of an understanding, programming is like trying to speak another language by looking up each word individually in your [other language] to English dictionary. That’s one way to learn, but you’ll probably just be miserable and frustrated and forget what you were trying to say in the first place before you’re even halfway through your sentence.
Come to think of it, maybe the kind of drills you do when you’re learning a language could help people learn to program without spending so much time worrying that they’re just not smart enough.
Anyway, repetition is seriously underrated and I wish we collectively talked more about how much practice it takes just to pick up the basics of programming, let alone the complicated stuff like deciding how to structure your code or what to name things (still one of the hardest problems in programming :) ) I think a lot of programming tutorials assume that you know you need to practice without explicitly saying it or without making it clear just how much practice you need. I have to admit I wouldn’t want to write pages and pages of very similar programming exercises either, but it’s not so hard just to say that programming takes practice and you’ll probably need to go through the tutorial a few times before it sticks.
If you did a tutorial or a workshop just once and didn’t instantly become a good programmer, congratulations, you’re normal! If you keep at it, you’ll get there.
The big tip for post #8 in the be a better programmer while still having a life series is to become a witch. A Terry Pratchett style witch, to be precise. Terry Pratchett’s witch characters are really great at two things: first sight and second thoughts. To quote him directly:
First Sight and Second Thoughts, that’s what a witch had to rely on: First Sight to see what’s really there, and Second Thoughts to watch the First Thoughts to check that they were thinking right.
Back at my original point, first sight is seeing what’s actually there, not what you wish was there or what you thought was there or what you meant to put there. Does that remind anyone else of debugging?
Fortunately for programmers, we have tools like debuggers and IDEs to help us see what’s actually there. We also have techniques like simply getting up and taking a walk, or explaining our problem to a rubber duck (or maybe another programmer if it’s a really hard problem), or commenting out half of our code and then half of that half and so on until we find the problem line. Let’s just not think about how much programming must have sucked in the days before friendly IDEs that highlight mistakes for you :)
Another part of first sight for programmers is also your attitude. If you don’t want to see the problem, you’re just not going to no matter how observant you are normally. I’m by no means perfect at it myself, but I’m convinced the most useful attitude you can bring to debugging is the simple acceptance that you got at least one thing wrong. The longer you spend insisting that your code should work, the longer it takes to figure out what’s actually wrong with it.
Moving on, second thoughts are thoughts about your thoughts. When you think you know the best way to build something, why do you think that? How do you know you’re right? Is that actually the best way or is it just the first way you thought of? How would you know either way? What constitutes the “best” way to do something? Is “best” the most performant, the easiest to read, the easiest to change, the quickest to write, the easiest to test? If “best” for your project meant quickest to write yesterday, does it still mean that today? How would you know when that changes?
Checking up on yourself like that is really hard to do and that’s why this post is more for me than for you – I’m trying to remind myself to question my assumptions.
One of the traps I fall into most often is looking for an example of what I want to do in our existing code and then assuming the first thing I find is the right way to do it. Shockingly enough, codebases change over time. Just because something worked well when it was written doesn’t mean nobody has thought of a better way since then or that the rest of the app hasn’t changed enough to make the old “right way” completely different from today’s “right way.” Just like you look for a couple of sources that agree with each other when you’re Googling what an error message means, look for a couple of examples in your codebase and if they’re different, check which one is newer.
Getting into the habit of thinking about how you think is not easy (at all!), but it’s useful and, like the other installments of this series, not something that you have to devote all of your free time to. It’s also useful in pretty much every area of your life. When you have any problem to solve, how do you know you’re right about how to solve it? For that matter, how do you know you’re right about what the problem is?
When I’m stressed out, every little thing drives me absolutely crazy. I can end up convinced that what’s bothering me is that this stupid freaking feature won’t work no matter what I do when the real problem is that I’m trying to hit a tight deadline and marketing keeps changing their minds about what’s important and half the QA team is sick so they need extra time to test everything and that means I need to deliver even sooner and everything is terrible!
Okay, so what do you do about that? For starters you really should read that blog post I linked earlier, Amy Hoy goes into a lot of detail about learning to notice yourself thinking. My big tip is just to get into the habit of asking yourself “Why? Why did I decide that? Why is that the best way? Why is that bothering me so much?” Sometimes the answer is going to be stupid simple: I decided to go to cafe at the front of my building for lunch because the weather was hideous and I didn’t want to go outside. Sometimes the answer will lead to more questions, like when you ask yourself “Why did I decide to put that config file in that directory?” In my case the answer was “Because that’s where the other config file lives” which leads to another question: “How do I know both config files should go in the same directory?” From there I learned all sorts of stuff about which files were supposed to go in the original directory and why, and where the other file that was related but not the same type of config ought to live.
This is the kind of thing that takes a lifetime to master, so don’t feel bad if you don’t get it right away. Asking yourself those questions is still worth it even if you only remember to do it sometimes.
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.
The gist of his talk is that “boring” (stable, commonly used, not shiny and new) technology is awesome because you can trust it, you can get help when you need it, and you can focus on building something useful instead of fighting with your tools.
Even if you’re a beginner programmer and nowhere near ready to worry about whether your production database is going to crash, it’s still good advice. Well known, commonly used tools are way easier to learn because they’ve been around long enough to have docs written for them and to have the majority of the bugs worked out of them, they’ve been used enough that somebody else has probably run into the same problem and asked about it on stackoverflow already, and because so many people use it, even if your exact question hasn’t been asked already somebody out there can answer it.
For example, take a look at the number of questions tagged Java on stackoverflow versus the number of Kotlin questions. When I wrote this post, Kotlin was closing in on 4k, where Java had 1.1 million. I’ve heard good things about Kotlin and I’m not saying it’s a bad language to learn, just that you’re going to find answers a lot more easily with the language that has over 200 times more presence on stackoverflow. Not that stackoverflow is the be all, end all of programming language popularity, but I think it’s a decent measure of how many people are using a language.
You know that feeling when you need to get something done and you just don’t want to? Considering this post was published on a Monday, I bet you do :)
When I don’t feel like doing something, I find it can really help to trick myself. That is, I do a tiny little piece of something that’s related to the thing I need to do but that I can tell myself isn’t the real work. For example, if I’m starting a new feature, I might tell myself I’m not really starting it yet, I’m just poking around in the existing code a little and seeing where I could put it if I actually was starting that feature. Or I might tell myself that I’m not really building that feature, I’m just stubbing out a class and writing a few comments about how I would build if it I were doing that, but I’m totally not, I’m just writing comments, nothing to see here ;)
Minus a certain amount of flailing around trying to figure out the best way to do something, this is basically my process when I’m building stuff:
Don’t do the thing, just poke around in the code a little.
Don’t do the thing, just make notes about what you find.
Don’t do the thing, just write down ways you could do the thing if you were going to (but you’re not).
Don’t do the thing, just stub out a class (if needed) where you would do the thing.
Don’t do the thing, just write some comments where you would do the thing.
Don’t do the thing, just stub out a method.
Don’t do the thing, just pseudocode one method.
Don’t do the thing, just fill in one method.
Don’t do the thing, just write down one thing you’ll need to test.
Don’t do the thing, just pseudocode one test.
Don’t do the thing, just fill in one test.
Honestly, that’s the core of software development. Software design and architecture are certainly important too, but I’m convinced the single most important part of actually building stuff is breaking down problems into manageable little pieces. If we had to think about the entire application all the time, we’d all end up under our desks weeping quietly. Only the ability to ignore the big picture for a while and focus on one tiny piece allows us to actually get anything done.
Of course just because “break the problem down into tiny pieces” sounds simple doesn’t mean it’s easy. It’s really common to get side-tracked trying to figure out how something unrelated works (I have the worst time leaving stuff alone even it’s probably not relevant to what I’m currently doing), or to spend far too much time trying to figure out what the best way to do something is (that one’s so common we have a word for it), and sometimes you just don’t know where to start or the problem has so many moving parts that you feel overwhelmed and quietly freak out a little.
On the upside, learning to break problems into manageable pieces gets easier with practice. For me it’s mostly a matter of reminding myself that I’ve done this plenty of times before and I’ll solve this problem too.
If you’re having trouble getting started, see if you can trick yourself into doing something. Remember you don’t have to solve the whole problem at once, you can start with a tiny piece of it.
A question I’ve seen a lot on java programming forums is “Should I get a certification?” Like every other programming question ever, the answer is “it depends.” Don’t worry, I’m going to explain what it depends on and how you can figure out whether or not it makes sense for you to get a certification.
First of all, I want to admit up front that I’m skeptical about programmer certifications. I’ve seen excellent programmers with certifications and I’ve seen far from excellent programmers with certifications, so I don’t believe having a cert tells me very much about whether you can code. That said, it’s not going to hurt you to have a certification on your resume, so if you have access to funding for retraining or anything, go for it!
What I believe most people really want to know when they ask if they should get a certification is “Will it help me get a job?” The answer depends on what companies in your area want, but fortunately, that’s really easy to figure out. Research! Hey, I didn’t say it was going to be fun :) What companies want is not some big secret, it’s going to be directly in the job descriptions they post. The trick here is not to look at two or three postings from companies you’re already interested in and call it a day. You’ll get a much more complete picture of the qualifications that companies in your area want if you look at a wide range of jobs both at your current level and above it – you’re not planning to be a junior forever, are you?
Another way you can research is by going to user groups and meetups and asking around. People who already work in the industry are going to be able to tell you things that aren’t in job descriptions, like “the last person company x hired who didn’t have a certification was the boss’s niece” or “company y’s job description mentioned certifications were a nice to have but they were actually perfectly happy with my example code”
Speaking of interviews, they can be a reason to get a certification even if local companies don’t specifically ask for them. If having a certification would make you feel more confident and you can get one for a reasonable price, go for it. The more prepared you feel going into an interview the better you’ll do answering questions, which a cert can help with even if you never get asked about it directly.
Whether you should get a certification also depends on what kinds of credentials you already have. If you have a programming related degree or diploma, I wouldn’t worry about getting certified unless local companies really want certified employees. If you’re trying to switch careers, a cert could really help and is likely to be a lot cheaper than going back to college or university.
It’s a little bit of a tangent, but something certs can legitimately be really helpful with is telling you what to learn. It’s totally overwhelming to do a couple of tutorials online and learn just enough to freak out about how much more you have to learn. Certifications can narrow that down by giving you a nice tidy list of stuff you should know. Fortunately, you don’t have to actually get the cert for that, you can just read the list of topics the exam covers and learn them on your own. Then you can prove you know them by building something that uses those concepts and/or writing about them. As a bonus, nothing convinces an interviewer you can code like showing them your code.
Should you get a certification? Will it help you get a job? You can find out yourself by reading job postings and going to user groups and asking around.
Not long ago I read this blog post Why Learning to Code is So Damn Hard, which makes a really interesting point about the “desert of despair” between beginning to learn to code and having the skills to build a complete project on your own. The desert of despair, according to the post (which I agree with) is a combination of lack of resources for learners who are between beginner and expert, and having learned enough to know how much you still have to learn. Many aspiring coders get lost in the desert of despair and never find their way out.
I also read Amy Hoy’s post 5 Things I Wish Somebody Told Me Before I Founded My SaaS. One of the points I found the most interesting was that there’s always another inflection point. By inflection point, she means “those knife-edges you tip toe along, when things could go either way, when you are, say… trying to grow your team but lack the time/revenue to do it, but growing your team would help increase the time/revenue to the point where you could grow your team. Ouch. To me, that’s the prototypical inflection point.”
Where this ties back to the other post is where Amy says “Over the last 8 years running this biz, I have said so many times: “We just have to get through this $INFLECTIONPOINT and then things will get easier.”” Doesn’t that remind you of programming?
If I can just learn enough to get my code to compile then things will be easier.
If I can just learn enough to add a feature to an existing project then things will be easier.
If I can just learn enough to start a project on my own, then things will be easier.
If I can just learn enough to break my code down into good methods, then things will be easier.
If I can just learn enough to break my code down into good classes, then things will be easier.
If I can just learn enough to break my code down into good layers, then things will be easier.
If I can just learn enough design patterns, then things will be easier.
If I can just learn this new framework, then things will be easier.
If I can just learn this new style of programming, then things will be easier.
If I can just build enough different projects, then things will be easier.
If I can just learn enough…
There’s always going to be something else to learn, it’s never going to become easy and stay that way. Things do get easier once you find your way out of the desert of despair, but initially learning to code just leads to worrying about whether your code is good leads to worrying about design and architecture and scalability and reliability and security and those are seriously hard problems.
Despite how it may sound, I’m actually not trying to say that coding will suck forever and you should just give up. I’m saying that it’s normal to feel like you still suck at this even after years of working as a programmer. You don’t actually suck, it’s just normal to feel that way. What’s really happening is you’ve levelled up. When you do that you see the problems that used to give you trouble as too simple to count and focus on the stuff you aren’t good at yet, which can easily make you think you suck.
The thing I struggle with is design. I’ve been at this for ten years now and I’m still never sure if I’ll regret the design I’ve come up with the next time we add a feature to the system. Plenty of times I’ve come up with something that seemed like a good idea at the time, only to find out that it had serious flaws when I came back and changed it later.
It’s tough sometimes but on the upside, you will never ever run out of things to learn as a programmer :)