Nebojša Stričević wrote this on February 29, 2012

First month at Rendered Text

After a year and a half of work at university as a teaching assistant and a PhD student I grew tired of constant multitasking and context switching between lectures and lecture preparations, science stuff reading and my path to learn something practical. I couldn’t find time for dedicated coding and I dreamed about making something useful and finally using some of the knowledge I tried to gain through years. So I started looking for an alternative… And finally, I quit.

I found my place at Rendered Text. Now, after a month of work here I’m trying to collect all my impressions. And how they met my expectations…

Too good for standard interview

The first thing that caught my eye couple of months ago was the Rendered Text job notice on the web. They weren’t looking for an experienced programmer or one dedicated to a particular technology but someone willing and able to learn and adapt to different scenarios. As they worked with stuff that I find interesting I applied, and went to the interview.

And there I was all dressed up and shaved, a bit nervous on my first real job interview, but mostly calm in front of two guys sitting on pink lazy bags and asking me questions. After a couple of expected questions - an insult. They asked me to write a function that reverts an array! Two guys in pink lazy bags asking me, a PhD Computer Science student, to revert an array?!

And then it came to me… These guys don’t care who you are exactly. They don’t care much about your degrees. They care about what you have done in the past and what you know. And since I didn’t do much real work and my knowledge about technologies used at Rendered Text was very week, I knew I should just shut up and try extra hard to impress them. At the end, I really wanted to work for someone with that attitude.

Rest of the interview was different. They showed me what they are working on and what technologies and tools they use and how the typical workflow looks like. They also asked me to do a test week of building a small Ruby on Rails web app and I agreed.

And I threw everything at them. I used Ruby on Rails, but also RSpec and Cucumber. Although I didn’t have previous experience with BDD I knew that my standard practice won’t impress them. At the end I don’t think they were impressed with the ball of muddy code I finished with, but maybe with my courage to use couple of technologies whose names I didn’t even knew at the time.

Loud lazy bag office

When I stared working at the office there were many things that were new to me. The first impression I got when I started working at the office was that it is very quiet in there. Before then I worked mostly alone and although I can focus very easily I wasn’t thrilled that there is going to be four of us in the one room. I expected noise. Talk. But later I found out that loudest thing in the office is my over heating laptop.

Now, you can have false impression that there is lack of communication in the office. But you would be wrong. There are couple of well chosen, interconnected communication tools that make all the communication quiet and non disturbing. You are able to know what is going on around you without much talk. And the talk is also well spent. There are a number of small, focused meetings through a day. And if you need help you can just ping someone, send him a message and the help will be there soon.

You can learn so much at the office by just being quiet and listening. After a year and a half spent as a teacher and being paid to talk the best thing I could do was to shut up and learn. And it paid off. With every line of code where you step into a territory that you haven’t visited before - you learn. With every session of pair programming your knowledge boosts intensively. And the best way to learn to code with style is to embrace the power of pull requests.

Boring, slow learning start

Whenever I finish a meaningful piece of code, I make a pull request. At least one of the more experienced coders makes his remarks. And I refactor. And again. And again… Code never reaches development branch until you meet the standards of the rest of the team. This is amassing way to learn and to improve your coding style. It’s just important to remember that you don’t know much. To be open to listen to more experienced ones. And to learn. I don’t think I’ve ever learned at this speed in my life.

Another important practice to embrace and learn is BDD. I didn’t find it hard to make myself to throw out my old habits for a couple of reasons. Since standards in the firm assume BDD I don’t event think about returning to my old mode. I think it pays off to stick to BDD as much as you can, since that is the only way to really learn it.

As I’m working with more than one technology that I didn’t use earlier I find BDD more then just helpful. Rails can be magical at times for someone who is starting with it. And since your change can potentially propagate to some different part of the system, it is a relief to let tests take care of your code. I feel much more confident about what I write. And I’m not afraid to refactor.

If you really stick to the BDD practice, you can feel how it will guide you through the building process. I find this to be an excellent way to work with new technology as you can really feel how the system works and how parts fit together.

Happy to be wrong

So… I’m beginning to fit in. And I’m glad it happening much faster than I thought. I got used to the excellent set of the tools that make our toolbox. Mainly because I share minimalistic preferences with the rest of the team. And I got used to the workflow. Everything that seemed odd at the beginning seams logical now. And I continue to learn.

I’m really eager to see what the next few months will bring.