Becoming a programmer? What a funny idea! Or is it?
Hi, nice to meet you, I’m Marina, a bootcamp graduate with 2 years (and counting) of dev experience in a Parisian startup.
I don’t know about you, but my idea of a great career path has greatly evolved since I was 5. I used to think there was nothing better than becoming a circus acrobat, than I wanted to train cats, then (an unexpected shift!) become an interpreter for the president of Russia, then… Well, lots of other professional options which never included being a web developer. And nevertheless, here I am and, as of now, I think it’s pretty much the best job one could have (at least right now, which is already a lot).
Since this opinion has been all but unpopular lately, I thought that some of my observations might be interesting to those who are considering coding as a full-time job after graduating from a bootcamp or a similar institution. Much of what I had to say has been perfectly formulated in this post, but I’ve still got a couple of things to add. Also, as a former copywriter I have an itching need for self-expression, so…
…naturally, all of it is going to be my personal feeling based on my personal situation, so no offense if you’ve got a very different experience (please share!).
So, does it get any easier? Can you recode Google? Is it even worth it?
Well, to be honest, no, no and…
That was a little spoiler, now let me tell you something (hopefully) more useful.
You will suck (no offense)
At first your work won’t be any good. In fact, it’ll be straightforward bad. The truth is you’ll probably be ashamed of what you wrote a couple of months ago. But it’s actually very good news, it means that you’re getting better. Speaking of how much time you’d need to recode Google — let’s say after two years I’m not even close and chances are you won’t be either. And that’s perfectly ok, there’re lots of other cool things to code.
I don’t know how coders learnt new things 20 years ago. From books? from their mistakes? from fellow programmers? God, I wouldn’t want to be a programmer 20 years ago. Today is a completely different story. You have the above-mentioned Google, you have Coursera, Khan Academy, Codewars, Stackoverflow (!) and Reddit and Quora…
I mean, it’s part of the job description to learn new things every day, which is good news for those who like to learn. And luckily, this knowledge is (largely) free. Imagine a lawyer giving you thoughtful and relevant advice in a forum discussion thread. I wouldn’t trust that advice — but for coders it totally works, probably because teaching and explaining is actually another popular technique for learning. This weird world of programming!
You probably don’t realize trying new coding languages and frameworks could be fun. At the beginning you’re struggling with just one — but it’ll pass. Choose something you’re interested in doing (responsive sites with a ton of animation? machine learning? internet of things? there’s always something that makes your eye spark) and experiment with it, even if it’s too complex and incomprehensible at first.
The more personal projects you have the better, and who cares if they are perfect. In the worst case scenario no one will ever use them (did you actually want anyone to?) Think of them as your personal nuclear test sites and feel free to blow them up in all ways possible. Sometimes (oftentimes when you code) breaking things only helps to make them better in the end.
There’s a caveat, though: during the intensive phase of your coding training you might get used to a very steep learning curve. Don’t get discouraged if it’s going to get flatter, cause it will. Nothing will compare to the day when you learnt what a string or an array were, but there’re definitely one or two other things that are as exciting.
There’s good style and BAD STYLE
Day 1 after your bootcamp course is over (or even before, ideally) start thinking as a part of a team. Unless you’re planning to be a solitary nomad freelancer who moves to another continent once his project is over — your code should be easy to read and to maintain.
Several examples of what is not easy to maintain:
- one-letter variables and method names (no, you will not remember that
astands foraverageand `x` for `period`) - method definitions that span for hundreds of lines
- doing the same thing in 10 different ways within the same application
- copypasting badly indented code…
Well, you get the idea. Try to avoid those as early as possible. Your future colleagues (and your future debugging self) will thank you and even buy you a drink maybe.
You might say that as a self taught prodigy you don’t know anything about good coding practices. It’s ok, just install a linter for your chosen language or languages and read recommended style guidelines. Once you get a grasp of it, set up your own coding conventions and stick to them.
Another important thing. By convention, all coding is happening in English, even if the coder is not an English native speaker. Can happen to the best of us. I’m not one, for this matter. Unfortunately, however, it’s not an excuse for bad and non-explicit naming. execute, do_something, change are all signs that not enough effort has been put into formulating what your method actually does.
Testing makes perfect
Most bootcamps don’t teach testing. When you only have a couple of months for everything, TDD is usually out of the scope. But it’s definitely not out of your job description! When you accidentally break everything by a line you wrote 5 minutes before deploying your code, you’ll be happy tests are here. They aren’t the most fun part of the day, but think of it as an insurance for your work. You won’t want to see your boss furious when an important client who was about to sign a million-dollar deal discovers a 500 page. Just write these tests, will you?
With continuous integration tools you don’t even have to launch your test suite. Once the configuration is all set up, when your code is pushed to the remote repository, everything will happen by magic. Some of such services are free for non-commercial projects, so you really have no excuses to ignore them.
Everything will take longer than you think
From day 1 start any task by first estimating how long it’ll take. Half an hour? A day? Two weeks? Now that you have a number, multiply it by 3. Your first estimations are probably the last thing you should rely on. It’s not just about one most likely scenario, it’s also about edge cases, weird user journeys, code readibility, smoke tests, debugging…
Actually, know what? Multiply your original time by 4. Better be safe than sorry.
RTFM
Oh, you know this one. Ok, how about WTFM? Write the fucking manual. Yep. Chances are you’re not going to recognize your own code in a couple of months (cause it’ll be bad, see above), so for the sake of your own tranquility, make notes of how things work in your app. If you aren’t working alone, clearly documenting things should become a reflex.
This habit will also be of use to keep track of your coding discoveries. You just can’t put all the cool tricks you see in blogs, newsletters and tutorials into your current project. But when you actually need something you spotted in a couple of months ago, you’ll never remember where you saw it. Unless you write a blog article about it, or a gist with a some examples, or at least bookmark it in some relevant folder (RELEVANT, not the general dump of your browser’s bookmarks!). Don’t rely on your memory or google, please.
Don’t forget to talk
When I was looking for a job, some recruiters were shocked to meet a coder who can clearly articulate her thoughts and answer human questions. For a lot of people, it’s obvious, but some underestimate the importance of personal interaction for a developer. Yes, even developers should be nice to work with, unless they are called Linus Torvalds or similar, in which case they can completely stop speaking. Otherwise, try to be a coder people won’t be afraid to talk to.
A part of the “Be a normal human being” advice is “Stay in touch with your classmates and colleagues, harness the power of local and online coding communities”. It’s not only a humanly nice thing to do, it can also help you big time one day.
By the way, don’t feel obliged to be always talking about coding. You might find it interesting how others work, what sprints and pocker planning are, how to organize a better git flow… Lots of other amazing subjects to discuss that will also contribute to your overall startup culture and make you a more attractive candidate at your upcoming interview!
Let’s get paid for coding!
Let me put it straight: employers prefer engineers with all this classical C and Java background and those endless algorithm classes behind their belt. So, if you are coming from a bootcamp and you’re not an engineer, you’d better be good, curious and damn lucky.
If you feel you aren’t good (and that’s what you will be feeling anyway), do everything to become good. After all, you already know quite a lot and if you’re willing to learn more, for lots of companies you’re a catch, don’t forget it.
At the same time, for lots of other companies you aren’t. Just relax and accept the fact that most coding jobs aren’t for you. Don’t apply for all developer positions you come across. Some of them require very specific experience, in others you won’t be interested yourself. You’ll soon learn to understand what projects you are personally drawn to, so stick to them; otherwise you’ll hate what you do. As a fresh developer, I was once asked to design business cards — you have to use some mysterious software, so it qualifies, right? I mean, it’s ok to say no to things that just don’t fit. At some point you risk having too many offers anyway, so take it easy.
If you’re serious about getting a developer job, an important thing is to prioritize. Select several offers you’re really passionate about and… don’t apply for all of them at once! You risk getting several voluminous tests with tight deadlines. And it’s definitely not the best environment for showcasing all you’re capable of!
Lastly, who the hell am i to be giving you advice?
Well, I spent 8 years of my life writing advertising for some brands you probably know. And then I felt I had had enough of huge corporations and signed up for Le Wagon bootcamp in Paris(best bootcamp ever, in case you were wondering ❤).
This was my most fulfilling educational choice ever, after 3 poorly chosen master degrees in some very literary fields of study. I know it might be hard to overcome your fear of changing everything, but I also know what a rewarding experience it is to deploy your code into production and see it work. So I just thought I’d share some of my observations, hopefully they would help someone make their important decision and become a better coder.
