5 things I learned as a software engineer

I started my Ruby on Rails adventure in the summer of 2017. I love and hate my job simultaneously. If you imagine the programmers writing only clean, working code, your imagination is impressive. Programming is actually a laborious occupation. The number of code lines is sometimes inversely proportional to the time spent on thinking about the complexity of a given problem, and finding the solution. Sometimes the most effective code has two lines, and a task entitled "simple UI changes" takes eight days on a backend - and a display of additional column in a table is its visible final effect. This is not a hyperbole, but a genuine life example.

I used to consider programming a cushy, not stressful, well-paid, office job. Now I know only the last one is true. Maybe it's a matter of approach but I can't go out of the office when my code is not working. I need 1:0 for me, full stop. On the other hand, I receive my work colleagues' support. It doesn't work? Oh well. QA will push Rejected button with joy. We must also learn by our mistakes, and I think I've learned a lot indeed. I acquired a huge number of technical skills, discovered the real meaning behind teamwork, and some things about myself. 

I think I can share with you the remarks I had after the first six months of my adventure as a software developer. 

Project size

During my studies, I wrote several projects. Apart from my dissertation, during these five years there were several more or less complex final papers. But none of them was close to even 1% of the way the system we develop now works. To develop one product, 59 people work with code. There are almost 200 repositories. The project's excerpt I am working on - an administrative side of the main product - is so vast that during nine months I had no chance to take a peep into all of its files and functionalities.

Finding a proper place in a code took more of my time at first than repairing a bug. Conclusions: keyboard shortcuts in an editor, fuzzy search or plugins for tools are an absolute must-have.

Starting in the middle

We should start everything from the beginning - even a child in a kindergarten will tell you that. Unluckily, it's not always possible. 

I joined my company and started developing the code that somebody's been working on for several years. We add new functionalities, repair the bugs, the old code needs refactoring, another one should be deleted. It's totally different than getting credit points during the studies - where we get a finished problem, and then design and implement its solution.

It's also totally different from agency work where www or application are custom-made for the client. The budget is specified, there's a vision of the effect we want, and a limited time. We end one project, and start another one. Every project is started from the very beginning - we choose the tools, or make a plan (at least partly similar to the ways we're taught about it at school).

Here, I started in the middle, and I'm in the middle all the time. 

When to ask for help, and how to solve problems?

Learning when to ask for help is a crucial part of being a junior. I never wanted to be someone incessantly asking silly questions. On the other hand, I didn't want to spend several hours on something and get a breakdown whereas little help from a more experienced developer might simply save a lot of time and stress.

When starting an internship, I heard I should spend 20 minutes to find the solution. If I don't find one - just ask questions and don't waste the time. Things get worse if you even don't know what question you can ask. It made me rediscover a rubber duck method. Really! Talking to the duck seemed a joke for me but it made me realize that when I dispose of thought, I get the solution. And when we introduce another developer to the task - we're forced to retell everything we know. Chances are, this way we'll get a solution.

Sometimes we don't need to open the mouth and talk to another person - or a duck. I was waiting for a senior dev to find a moment for me, and thinking what to tell her when she'll come. Simultaneously, I didn't want her to listen to my incoherent talk :) And that was the reason I found out the answer. 

Writing down the steps or creating block schemes of problem solving might be helpful. It's also a good foundation for discussion with another developer when something doesn't work. Sometimes I realized I was lacking a particular information - that I could never get. Or the process of finding it would take a lot of time. I just needed to ask.

I try to write down interesting replies that I got, or interesting fragments of code. I gather all pieces of advice, tips, useful information in my notes. If I stumble across a similar problem again, I can come back to it. There's even more - when my teammate has a similar problem, I can suggest a solution. 

Believe in yourself

I learn it all the time, and probably it will be a long process. I recently found out there's something like an impostor syndrome. But I would really flatter myself thinking it already afflicts me.

I felt unsure with Rails - and the fact my commercial experience with programming wasn't too large when I got the job. I met the people whose experience with various technologies would suffice several senior developers. The people leaving me the impression that even my computer skills aren't proper enough. 

There's immensity of languages, frameworks, methodologies and nuances. It's not possible to know everything. It's perfectly okay to hear about something for the first time or see a tool, and not be sure how to use it. 

The studies and practical knowledge? The most practical projects during software engineering studies were as close to the reality as Need for Speed game was helpful for me to get a driving licence.

It's good to know that it's okay not to know something. More important than a whole data set in your head is being able to find the most optimal solution. And even more important: even if you don't know, you're eager to know. I can learn, and being surrounded with experienced people makes it easier. I don't need to reinvent the wheel. A knowledge transfer and good practices are what I already got - since I started in the middle of a project. Now I need to develop my skills to contribute to the team the best I can. Talking about that... 

You'll never stop learning

There are so many technologies worth knowing that as a programmer you will never stop learning. It doesn't mean you should know all the languages ever invented. I also doubt that one beautiful morning, I'll be able to recite all JS/Python/Ruby built-in functions. But it's good to know different languages, technologies and tools to have something to choose from - depending on your needs. Be up to date with fashionable or prospective stuff, and to hone your present skills all the time.

Before I started my job, it seemed to me I'm able to write clean, logical code, and I create complex websites. When I finished my studies I thought I know how to execute complex questions in SQL or I'd be able to design a huge database. Probably I still can - on a piece of paper. Anyway, you get to know something new, study it, and see it's just the tip of the iceberg.

In IT, you can't say:

OK, I will learn Ruby on Rails and I'll write applications until I retire.

That's simply not possible. IT market changes quickly. New technologies, trends, and languages appear - leaving no place for boredom. 

I have a feeling that during the last six month I've learnt more than during the last three years.



The article is also available in Polish on Flynerd.pl blog.