melreams.com

Nerrrrd

Terrible ironies of programming: people

in opinion, terrible irony, Uncategorized, unsolicited advice

In my last post about the terrible ironies of programming, I foreshadowed the next terrible irony:

Plus being at a computer and away from people is pretty attractive for weird little nerds who aren’t good with people

So many people go into programming thinking they’ll be left alone to code then find out programming is fundamentally a team sport. Even I used to joke that I didn’t decide to work with computers because I like people so damn much (I’ve since knocked that shit off because it’s obnoxious). I’ve come a long way, but I was an extremely shy child. One of the things I love about computers is that they make sense to me in a way that people just don’t. While I eventually came around to the idea that getting people to work together is a really interesting problem, it took over a decade.

But that’s a separate blog post! Let’s talk about one of the reasons software is a team sport: software these days is just too big for one person to build the whole thing and hold it all in their head. I say “these days” like have things have changed since software engineering first became a thing, but the top performers have always been the people who can get their questions answered faster* – it’s just more of an issue now as systems become larger and larger.

You might think that the answer to systems being too large for one person to hold the whole thing in their head is to split them up into microservices, but that just makes the people problem worse. It’s incredibly common for two people (or teams) to have slightly different understandings of what they’re building, and the more interfaces you have with other systems the more likely you are to slam face-first into that problem. Oh and if your microservice only interfaces with one other system, you should be thinking about whether it really needs to be a separate service.

Anyway, the fun thing about people having slightly different understandings of what they’re building is that you think everything is fine until everything is merged and you try to use it and surprise! It’s broken! Wheee! Building to a spec is not that hard. Making sure everybody on both sides of the spec interpreted it in exactly the same way is that hard.

Also like I said in my last terrible irony post, humans just kinda suck at programming. We need each other’s help constantly. Even if you never speak to anyone outside of your dev team and manager, you’ll still have to talk with them constantly. The lone programmer in a basement office may have been a thing in, like, the 80s, but the 80s are over, man (in case that link stops working, it’s the scene from Formula 51 where the state trooper tells Samuel L Jackson’s character that “the 60s are over, man”).

Even then, programs were getting too big for one person to know everything and even then the top performing programmers were the ones who a) knew who to ask when they had a question and b) were nice/known enough that the person they needed an answer from would get back to them in a timely manner instead of whenever they damned well felt like it.

I’m not convinced there has ever been a time where programmers didn’t need to talk with other people, we just wish there was because a lot of us nerds fantasize about being left the hell alone to code. I’m not even saying I’m not one of them, one of my favourite coding days in recent memory was when I got to put my headphones on and spend a day banging out a Python script to parse a particularly uncooperative set of log files and not talking to anyone. The thing is, that’s the exception, not the rule. As uncooperative as those log files were, they were based on an extremely detailed spec and once my tech lead told me which characters should be parsed into which field, I was good to go. Normally software isn’t nearly so well defined.

And anyway, that’s just between devs. If you have a separate QA team you need to talk with them too, both to make sure they understand how to test any given ticket and to make sure you understand what’s wrong when a ticket fails QA and comes back to you. If you have a product owner or product manager you’ll need to talk with them a lot to make sure you’re actually on the same page.

One of my big fuckups at a previous job was getting together with another dev and our manager and deciding without the PO that integrating our project with a certain existing feature we knew a big client wanted the new feature to work with was just not going to happen. Yeah it turns out that feature was a massive part of that company’s business and there was no point building the new thing if it could never work with that particular existing thing. Our poor PO sure loved that surprise when she looked at my edits to the internal wiki page for that project. There’s plenty of blame to go around on that one but as the acting team lead on that project I should’ve known better than to make a decision that far-reaching without the PO.

If you’re doing any frontend work talk with your UI/UX/designer too! I haven’t done much UI lately but even I know it’s important to be on the same page as the designer. You need to make sure you understand what the design is meant to accomplish, not just what elements you see on the wireframes or mockups. And show your designer your progress as you work through the ticket, that can uncover misunderstandings you didn’t think to ask about.

Don’t forget showing your work to actual users too. Nothing you build matters if nobody can figure out how to use it if they even wanted to in the first place. Coast Capital’s old useless activity log, I’m looking at you. I promise you it’s okay to display table data in a fucking table, you don’t have to show me almost nothing and make me click on things over and over to get any details. Also if you’re going to display a small and largely useless subset of data that appears in another report, just add another filter option that report. Between design and implementation that activity log burned at least a week of time that neither the designer or developer is ever getting back.

Your application doing the wrong thing very quickly and accurately isn’t actually useful at all. It’s not useful either if everyone hates it so much they just won’t use it. Coast Capital’s old  nearly content-free activity log, I’m looking at you again. You really do have to talk to people to build anything meaningful! Even if you build a small app all on your own and can hold the code in your head, you still need to talk to your users.

The extra fun part is that even if you personally accept that you have to talk to people to get shit done, you’re probably working with people who haven’t accepted that yet and you’ll have to pull teeth to get them to tell you wtf they’re up to, wtf their problem is with your code (ask me how much of a disaster code review can be, I dare you), and why the hell they did it that way when you told them already what you were planning and now nothing works because their part doesn’t integrate with your part correctly.

And that’s assuming everyone you work directly with shares your goal of producing realiable software that makes users’ lives a little bit easier. I have another blog post coming about coworkers who couldn’t give less of a shit about users, the company, their coworkers, or anything except getting their way.

* The Psychology of Computer Programming, Gerald M Weinberg. I’m entirely too lazy to look up the page number but I swear it’s in there.

Link of the day

in link of the day, opinion, selfcare, unsolicited advice

Persistence is enormously valuable, I even believe it’s more important than intelligence if you want to a programmer, but knowing when to quit is valuable too. That’s why I like I successfully chased my Big Life Dream, and I hated it by Rowen, so much.

Their dream was to travel the world in a sailboat, yours might be to become a freelancer, to start your own business, to switch to game development, or something else entirely. If you try something and it turns out to make you miserable, it’s okay to stop and do something you actually like. I’ve read a lot of sad stories about people who made themselves miserable, put themselves under so much stress it wrecked their health, or financially ruined themselves pursuing a dream that just wasn’t working, and I really don’t want that for any of my readers.

On a lighter note, if you do New Year’s Resolutions, consider quitting something you don’t actually like instead of trying to squeeze more and more activities into your life. If that feels selfish to you, think of it as setting a good example for others :)

Parallels between writing and programming

in becoming a better programmer, development, opinion

Unrelated image from pexels.com to make this post look nicer in social media shares and because I just like lilacs.

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.

“Does working at a bad company damage one’s career?”

in career, culture fit, opinion

A view down a long concrete staircase. A person walks by at the end of it.
Unrelated image from pexels.com to make this post look nicer in social media shares.

Another blog post inspired by a question on The Workplace, specifically: does working at a bad company damage one’s career?

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.

Repetition is underrated

in development, learning, opinion, unsolicited advice

a brown-skinned woman wearing a dark blue top and a white skirt plays an electronic keyboard
Loosely related image from pexels.com to make this post look nicer in social media shares.

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.

Be a better programmer while still having a life: part 8

in becoming a better programmer, development, opinion, productivity, unsolicited advice

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.

And no, I’m by no means the first person to connect Pratchett-style witchery with programming or design. Hint: go read that blog post, it’s really good.

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 :)

Unrelated image from pexels.com to make this post look nicer in social media shares.

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.

Rest is good for you

in career, opinion, productivity, selfcare

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.

And take a break, it’s good for you :)

Talk of the day: Be Awesome By Being Boring

in best practices, development, learning, opinion, talk of the day

Because I’m a Katrina Owen fan, I’ve watched a bunch of her talks. Recently I was watching her talk on Therapeutic Refactoring (it’s great and you should watch that one too), saw that it was from Cascadia Ruby Conf, and decided to see what other talks from that conference were recorded anywhere. One that grabbed my eye right away was called Be Awesome By Being Boring by John Hyland.

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.

Be awesome by being boring, it’ll make your life easier!

Trick yourself into getting stuff done

in development, opinion, productivity, unsolicited advice

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

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.

Should you get a certification?

in career, opinion

Unrelated image from pexels.com to make this post look nicer in social media shares.
Unrelated image from pexels.com to make this post look nicer in social media shares.

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.