5 sins of Junior Ruby Developer

Vlad Dyachenko
3 min readJun 10, 2019

During my career, I had a chance to work with different developers. Besides that, I was able to watch a probation period for a lot of new interns to the companies. Based on my experience I’ve built a list of sins that, almost every junior Ruby on Rails developer had made (or currently do) through his own career.

We read Medium stories not only for the knowledge, but also for strange memes.

1. Don’t blindly follow TDD

Testing is a very common approach for projects built with Ruby on Rails.

And all Ruby/Rails learning courses promote the idea of writing TDD as a commandment. And this learning way sometimes creates plenty of developers writing 5–6x more specs than writing real code.

Of course, it is impossible to write even medium-sized projects without specs at all. Tests are good and it is a correct idea to write them, but you need to know the measure. It is not necessary to cover each feature with tests. It is important to check only critical functionality.

One’s job is to find that sweet spot in which our tests bring a lot of value while not taking us many extra hours of work just to maintain the suite after each small change.
Dozens of integration tests of clicking buttons in the interface take hours to develop, but as a result, they will miss a minor bug and will become useless.

2. Please, learn some SQL

Paradoxically, but now very few people know about SQL. Everyone relies on ORM, and nobody really thinks about how it works.

Even if you don’t have to write any SQL because ActiveRecord do that for you, you still need to read logs to understand what happened.

3. Plan your architecture

It is necessary to understand how your application will be built, what will be its requirements at the initial stage, not to do over-engineering, which at first is not really needed, but it still takes time.

But at the same time, it is necessary to understand and predict what will be needed later -> so not to rewrite a whole application to make an insignificant new feature.

4. Be in technologies

It should be comprehension, what is better to use in each case. Don’t be attached to one gem, lib or technology that you know well and trying to add everywhere.

For example, when developers using devise for any authorization case or using old unsupported gem (while a better new one was realised) just because they are familiar with the old one.

5. Think about the business

Well, you need to understand the objectives of the business. You can become a stupid coder who just does what he was told, or you can do something yourself that improves the business for which you work.

It’s nice to be a good engineer, but it is better to be the engineer who is involved in the business.

Finally

Do not be scared of “I don’t know” phrase.

From one side, as a junior developer, you have to know where to find answers to your questions. Get familiar with StackOverflow, forums, Google, docs, etc. Only if you admit, that you don’t know something, you can learn it.

But from the other side, be communicative. Usually, more senior colleagues will be happy to help you with something if you say that you don’t know it. You don’t have to be shy because of that. It’s a normal process of learning.

So, I would simply advise to make your own projects and break away from the label “Junior”. Don’t be a junior.

--

--