October 2, 2017, I got my first paycheck as a Rails-developer. I’ve been working in a web-development company that uses only Rails for a month and a half. I was excited to hear about such an approach on an interview. But I calmed down since then. I tried to explain why and analyze the reasons in this article.

Looking back

I’ve been working as a web-developer for some time. But I was in a very weird situation at the beginning of this year. I worked remotely and had a decent salary and a flexible schedule, but I wasn’t happy with that. And I wasn’t happy for the last three years of my professional life. I was jumping jobs, looking for the one with the biggest salary and less of the captivity. I thought that if my work would allow me to have enough time for my personal life, it would be fine for me. There are a lot of people indeed, who look for joy outside their work: in their hobbies, traveling, family etc.

But I couldn’t get anywhere from there. I was still oppressed with my work situation, as I wanted to do everything well, make good money and enjoy the process. And in February I came across a Victor Shepelev’s article Three types of programmers, and reading it turned the tide completely for me.

A programming language (or rather language + instruments + infrastructure + community) imposes a specific model of thinking, and a programmer’s well-being and productivity deeply depend on whether his model corresponds with the model of the language and environment he has to work with.

Maybe this is the case? I like it when my text looks good, be it an article or a program code. When I was at the university, I was reading Code Complete with an absolute admiration.

But when I started working, I found out that it was unimportant for a client if the code was good-looking as long as it worked. He didn’t also care how everything functioned. What he needed was that:

1. It worked correctly;
2. It was in due time (which usually means ‘yesterday’);
3. It was good-looking from the outside (interface).

Thus I got only humdrum and decay instead of joy of creating good-looking texts and perfect code. That’s what we got:

• If it crashes, you fix it;
• ‘We have to start a promotional offer on Monday’ and you sit and get it done all your weekends;
• ‘We have moved to a new server, the integration will work, right?’ — ‘Give me access, I’m gonna check all the settings.’

And you do all of that in PHP, which makes you nervous and suspicious, and on top of that also repetitive.

I wanna be a Rails-developer!

So I started exploring Ruby, inspired by Victor’s article. He helped me to get my joy of programming back.

The learning curve was steep, which meant on the one hand, less of vacant job positions, and on the other hand, less of bad jobs and higher salaries. Then I got acquainted with Rails, which is considered to be the love of all the startuppers. It turned out that it’s possible to do something that works fast and like a normal person.

I came to an understanding that I should start working with Rails instead of PHP. I kind of wanted to start my way of a programmer from a clean slate and finally stop to sacrifice code quality in favor of tough business requirements. Changing to the new language, I decided to develop a habit to use best practices. It meant always testing the code, devoting enough time to contemplate any decision and using of advanced technologies. Thus I will finally start sharpening my skills instead of being only a laborer. I will also become more happy and more of a valuable asset, having increased my skills. That was my plan.

During the studies my hopes were cherished by many highly experienced people. We started with Victor who was carefully reprimanding me and showing me the beauty of Ruby for 10 weeks. Then Anton introduced me to Rails, and it turned out that if I have a task I can myself create a working thing within a reasonable period.

Well, the time has come for me to be working again. It took me some time to find a job and I had to make do with the lower salary than I expected. I had to forget about all the good things and projects I did in the past. But I was sure that there was a dreamjob just in front of me!

I had an interview on Wednesday night and on Thursday at 10 a.m. I was expected to turn up at the office with a laptop. I was told that my knowledge was ‘just a little bit not enough for a Junior position’ and invited to the project with the words like ‘we’re shot of hands and that would be cool if you managed.’

And then, all my ideas started being ruined one by one, just as the sandcastles on the beach are destroyed by tidal waves.

Working life

My first working day was full of unpleasant surprises. It turned out that the project I was invited to started as early as 2014. Do you think it means that it’s big and complicated? Then you’re right. And it’s also really old. I had a look at the project code and found there Rails 4.1 and Ruby 2.2.3.

First of all I created an empty database. But it was a mistake of mine to try to get rid of data migration. When the database was restored from dump, I tried to install gems. And I failed again. There are some links to this particular commit with in Gemfile with the note ‘correct it when committed into the master branch.’ It was a year since the commit was done, but it wasn’t corrected. And when I opened the test folder, I discovered that nobody had been testing anything for a long time. There are some tests, but only a few and it’s obvious that they were done on early stages of this project.

By the end of the first day I managed to finally see the login page in the browser. It should be mentioned that since then we have updated to
Rails 4.2.7. Not without difficulties, though.

Apart from the technical problems, there were some troubles with the management. The development process was divided between several teams, which lead to the situation where the deadline and the requirements ignore real programmers’ possibilities. A developer has time only to code. Strategic thinking phase, testing and debugging are set aside in favor of the deadline. Thus the task is finished badly tested or not tested at all. Moreover, all the old parts are never refactored. They are temporarily patched, because ‘we have no time, there are deadlines.’

Such problems are more than likely not unique, and most of you face the same stuff every now and then. The question is what we should do as developers? Or, in other words...

How to endure all of that and not to become a code monkey?

There are definitely two levels of problems:

1. Problems on the level of company/project;
2. Personal problems on the level of skills and work process and time management.

It’s certainly easier to start with yourself. The company takes a hefty dose of responsibility too, but I think that the developer should be even more concerned with his or her own self-development.

The thing is that the brain creates the pattern out of any recurring actions and it’s going to use this pattern whenever possible. That’s why mountain climbers stop exercising when they start moving inadequately because of the muscle fatigue. The programmer who has to compromise on code quality on multiple occasions, after a while will start to write dirty code by default due to the same reason.

An idea like ‘to write a quality code for myself and only finish the tasks at work’ leads to the same situation. The bad behavioral pattern will begin to form, as the amount of work time exceeds the amount of personal time anyway. That’s why we need to think of something.

I’ve found five key problems that might turn up and transform me into a code monkey. When I solve them, I master my skills, do not devolve, enjoy the process and in general stick to the plan I drew up for myself changing from PHP to Ruby. That’s how I do it.

1. Big unfamiliar project

A lot of time is usually spent on searching for the information, trying to understand what a project is and how it works. You might think that after getting acquainted with the project, you will get rid of the problem. But that’s mostly an exception. Examining the code of some stranger and unfamiliar project is very common.

So first and foremost I more or less explore the subject field. That helps to know the base terms I will definitely come across with in every task. Then I search for the matches with the entities (such as models and tables in databases) for the very same terms. And then I can analyze the entities and look for any connections between them.

The second phase is the moment when I receive a specific task. First of all I ask the manager or the tester to show me where it is in the interface. It’s possible to find all needed code parts there. If I have problems with understanding what’s going on in the code, I consult the ones who have been working with the project for a while.

2. Not enough time for testing

Even if the client pushes the date of the deadline, testing is highly needed for development and time should be provided for it while evaluating the tasks. Even if the employer says something like “You need to write not the tests but bugless code”, I don’t listen to them but write tests. When I estimate the time for completing the task at hand, I also provide some time for testing. I just don’t say that this time also includes testing time. This is easier :)

3. Insufficient task specifications

Sometimes some requirements are mentioned only at the development stage. Moreover, there’s a huge gap between how the interface looks and how it actually works. If the manager doesn’t realize how big this gap is, he either sets impossible tasks or gets nuts why ‘that tiny thing took so long.’ It’s really annoying for me.

So to prevent some explanations and rewritings, it’s better to clarify everything during the task evaluation process. Along with that I also check if all the materials are ready before the task, despite the fact that it’s not the part of my job. I think that it’s better to make everything clear than to be the one to blame later. This is particularly true when the task is not completed on time, because we are waiting for some interfaces or texts.

4. Code review at the end of the task

It’s often done at the very end of the deadline. And in case of any identified problems, you have to make everything over in a rush. Furthermore you have no opportunity to discuss the decision made.

I solve this problem in a rather crude way. I ask for a code review for every part I pushed to PR. Thus, when there’s a deadline, I can be sure that everything is checked and I shouldn’t rewrite anything.

5. I don’t see a development path for me as a programmer

Here I mean that my working process is more about enduring than development. There’s no comprehensible mentorship. When I solve small problems, I learn to put the patches and work by analogy (actually, using the analogy is a usual practice, but only if you have a quality example in front of you.)

This issue might be solved on the level of the company. For instance, you can raise the question to your employer or find a job where the professional development of the workers is more important. But none of it has happened yet for me, so I solve everything on my own.

You need to improve your efficiency and quality of your work during your working time exactly. Weekends and free time are not enough, don’t even count on them.

You should also have a global self-development plan. If you can’t put it into practice under the scope of the project, you should spend your free time on it. But you have to remember that any skill not connected with main project might remain only an academic one for ever.

I made a decision: I need a mentor, so I can improve my work efficiency. You might be wondering why I’ve chosen a mentor, if I have lots of colleagues around? The thing is that my colleagues are usually so busy with their own tasks that they don’t have time for me. Furthermore, a mentor can undertake strategic missions of your self-development, while co-workers give you the tips on how to create something that will work.

When the working tasks are done with the proper labour costs, I will be able to improve my overall level outside of the project. I guess that mentor can show me my blind spots and how to advance professionally. After that I might speak with my employer about a pay rise.

Problems on the level of the company

It seems that some companies which develop customized software transform their programmers into assembly line workers. They do some simple procedures at their sites, while CEOs think that the effectiveness might be improved just by increasing the number of workers, instead of evolving the ones who already work.

I’m not a manager yet and make judgments as an amateur, but to my mind, any development company should pay attention to these things:

• Build up personnel pool regularly;
• Outline the professional development plan inside the company, clear for both employee and employer (referring not only to the career ladder, but also to the skills quality);
• Not to shift responsibility for problematic projects onto the developers only.

There will be dire consequences ahead, if one turns a blind eye on these questions. The developers who chose their work with the utmost seriousness, will eventually leave. The ones who are more concerned about the stability or the specific company, will stay, but work with careless attitude. This way efficiency will stay low no matter how much people they employ.

At the moment I can see how people try to build up personnel pool by employing students. On the one hand, it’s easier to teach the minds of the ones not corrupted by the business life. But on the other hand, students are not the workforce that can form the backbone of the company.

When developer-student ratio becomes 50/50, everything gets weird. There’s enough workforce, but they often fall behind the schedule, as there’s a lot of rewriting. The elder developers are busy on the other projects, so they also don’t have any time to teach those students.

The case is that there’s no ubiquitous answer to the question: “What should we do for a developer to advance?” Some achieve great results through communication with the others, while bombarding them with questions day and night. And that would be enough for such a person to advance. There are times when the question is fairly special, but there’s no possibility to ask colleagues, as they might be busy or work with other project. If the person is persistent, he or she will google, ask friends, search through Github, but will solve the problem single-handedly.

But not everyone is like that: some can conquer a peak, while some just give up. For some people it’s easier to pay and receive fast and quality answers from an expert. Some solve the problems they couldn’t solve during their workday in their free time.

There’s always an answer, but each should look for it bearing in mind his own case. And the employer should be interested in handling the problem
with the developers.

Who is responsible?

I suppose that here ‘both are to blame’, as in any other relationship. But we should also take the level of commitment of both sides into account. When you start working in a team, you expect overprotection. You expect them to nurse you, motivate you, so you advance hands down. But this idea is na?ve and rather infantile. And at the same time, if I do everything by myself, why do I even need workplace relationship? If there’s a possibility to freelance, why do we even form teams? To a wide extent, because we don’t want our skills to go downhill while doing tedious tasks from the freelance marketplace.

To my mind, partnership is the only possible interaction type here. When we’re talking about work relation, we might have different duties, but a shared goal. In every company every developer might clarify what kind of career progress they provide. The less alternatives the company proposes, the more self-development will be expected from the employee.

But if the management has just a tiny bit of flexibility and is ready to communicate, you can together reflect on how to help employee to advance and how many ways for that they need. Maybe they need to hire some mentors from third parties or maybe let the talented workers slack off a little, so they can teach the others? Maybe they need to give workers some free time for self-education?

It’s worth paying attention to the fact that there is also the issue of the advancing of the full-fledged developers, as it’s more difficult to find mentors inside the company in such case. But even this might be solved by common effort.

This is an mkdev article by Natalya Maksimenko.