So you want to be a Ruby developer?
Some time ago I was asked to try and organize the codequest’s Ruby team into a more cohesive unit, which meant I got to be called a Team Leader (hell yeah!!!), and — more importantly — effectively became the go-to person for all the HR guys trying to recruit new devs (uhm…). Obviously, most of those devs were juniors with a sprinkle of mids. I try to approach every interview remembering that not so long ago I myself have been the aspiring junior sitting on the other side of the desk, so I do my best to be patient, kind and give every candidate an honest and helpful feedback, even if we decide that they need some more experience under their belt to be accepted. However I do see some patterns — a lot of developers, especially juniors, make mistakes that not only make their start harder, but are also quite easy to avoid, if only someone told them that early enough. I have made most of those mistakes myself in my time and it would probably save me a lot of frustration if someone warned me — or maybe they did and I didn’t listen closely enough — so to make someone else’s life easier I will try to point out what a junior dev (or even a mid dev) can do better, if they want to effectively grow as a programmer in a decent software house.
GitHub
Everyone in the community knows that your GitHub repository is what really matters for the future employer. Or is it? If you’ve written an open-source library that people use, or contributed to one, yes, it can be a pretty valuable bargaining chip. If you’ve written an app, even if it’s a training app, that solves some everyday problem you have — that can also show your skills. However if all repos you have to show are half-finished recruitment tasks from other companies, not touched once in the last nine months, or super-basic Rails scaffolds from when you wrote your first ‘rails new’, is it really something you want us to see? You might be much better now than you were nine months ago, hell, you probably are, but we don’t know that, and when you send us a link to a code graveyard in your CV — well, as the saying goes, you only have one chance to make a first impression, right?
And it’s not just junior devs — if you looked in my GitHub repos, you’d find exactly the same kind of all-over-the-place stuff — recruitment tasks from years ago, some abandoned experiments in languages I was learning along the way etc. I commit to GitHub every day — but I commit to private client repos, thus not really having a lot to show for it. What I’m trying to say is: it’s OK to not have a lot going on in your GitHub account — but if that’s the case, don’t use it to show us where you are as a software developer.
Ruby
We all love Rails! And we also hate it. And sometimes we love it and hate it at the same time. Or sometimes one day we love it, only to hate it and curse it the next. However we all agree that Rails is the industry standard when it comes to building web applications in Ruby — it takes a lot of dedication and effort to work in this business and not touch it even briefly (even though I’ve met people who claim to have done so!). So it’s only natural that when you decide to become a Ruby web developer, you learn Rails. However, it’s not so good, when you learn Rails without learning Ruby! You might think that it will speed up your progress — after all, setting up a basic Rails app is very easy — but you’ll find very soon that you don’t really understand WHY it works, you’ll only know THAT it works when set up in a certain way, and the first bug you encounter will leave you just sitting there and browsing Stack Overflow looking for someone who’s had a similar problem.
Think of it this way — you wouldn’t try to write a book in a foreign language using just Google Translate and movie quotes, right? And that’s what writing an application really is — you literally write something that has to make sense, and the better you know the language, the better you can convey the intended meaning, the more efficient you become in putting together sentences — the more sense it makes. When you only know Rails, your vocabulary is very limited and you can really only do one thing. And I can assure you — you don’t want to work in a company that wants someone like that, because very soon you’ll be reduced to a robot that churns out basic CRUD views, which is exciting for, like, two months, but then quickly becomes a programmatic equivalent of brushing your teeth — you have to do this and you do this, but it’s not really something to look forward to, is it?
I have learned to start every interview with a super simple, basic question:
- In Ruby, what is a class, what is a module, what’s the difference between them and what are they used for?
You’d be surprised at how many people don’t actually know that! And these are people who want to be software engineers. They all can set up a Blog with Posts and Comments in minutes — and that’s about it. I’ve had one candidate for a mid dev position, who claimed to have worked for over a year on client’s app as a team lead — and still he didn’t know what a Ruby module is.
Do not become that person. Learn Ruby. There’s a lot of resources for you to do that. One of the best I know is The Ruby Reference — an online book that takes the knowledge from Ruby docs and organizes it into simpler, easy to read format. Read it, learn it, and feel your programming power grow!
Rails
Having said the above, let’s not forget that Rails is the Ruby go-to framework when writing a web app. There’s a big chance it will become your everyday basic tool — so take the time to learn how it works! Rails Guides is a very approachable and quite extensive piece of documentation — take the time to read it and learn it as well. A lot of it will not make much sense to you in the beginning and there are big chunks of stuff in there that you will use very seldom, maybe even never — but just knowing about them gives you a much bigger toolbox for the solutions you’re going to come up with at work.
Tutorials
Tutorials are great — everyone uses them! However following someone’s instructions is not enough — remember, the goal of the tutorial is not to end up with a working Blog with Posts and Comments, but to learn how to build your own app. And that is exactly what you should do as soon as possible. Think of all those moments when you thought ‘If only I had an app for this!’. Or maybe ask your friends and family if there is an app that they would use. It can be anything — a simple todo organizer, a present wish-list, really anything. My first app was a kind of notebook for my wife’s experiments in her lab (she’s a scientist and yes, in case you’re doing years math right now, I started programming in my thirties). I never finished it, but it doesn’t matter — in this case it’s about the process, not the result. When doing a tutorial you are dealing with artificial problems and ready-made solutions — when you’re building your own thing you’re forced to really think about how to build it. You have to find solutions to your problems on your own — and I firmly believe that there is no better way of learning how to build things than to actually go out there and start building them, because that’s what you will be doing as a web developer in a software studio. Tackling difficulties will give you an enormous sense of satisfaction, build your confidence and ignite that spark of excitement that drives us to sit for hours hunched over our keyboards just to see a correct JSON or a working registration form. It will give you experience and something to show. Your code does not have to be pretty or flashy — you’re a beginner, nobody expects you to write an operating system! But as a person who recruits juniors, 10 times out of 10 I will choose someone with a piece of programming of their own, even if ugly and lame, over someone who can only show me some paint-by-numbers tutorial apps.
Mr. Nice Guy
This last point is something that doesn’t really apply to one specific level of experience, but to essentially everyone who works in our industry. It’s very simple — don’t be an asshole. Be nice to others. Be helpful. Smile. Ask if you don’t know, explain if asked. Don’t look at people down your nose if they don’t know stuff, because every single one of us can be humbled very quickly by someone else at any moment — computer science, programming and IT in general is such a broad field, that it’s virtually impossible to be an expert at everything. Accept that you can learn from anyone, even if they have a fraction of your experience. Teach others, because teaching others is one of the best ways to verify what you really know. And accept that if you’re the smartest person in the room, you should switch rooms, because that’s the only way to grow and not become complacent. Test your knowledge and your skills and leave your comfort zone as often as possible, because as the common weightroom catchprase has it — ‘if it hurts, it’s growing’.
If you’re also into the front-end stuff, make sure to check out a comprehensive list of most common mistakes of junior front-end developers, by our front-end Team Leader Piotr Kabaciński.
