Now, junior, behave yourself!

coco - Sep 11 - - Dev Community

September 12th. Today is the 256th day of the year. This means it is Programmer’s Day! 8 years ago, was the first day I did celebrate it, because I had been hired to do my first big project, on which I worked for more than two years. I remember feeling excited and proud. Especially proud! However, I was also reckless. I was hired to do something, I didn’t know how to do, but I knew I would be successful in the end. Of course, when they asked me if I knew, I immediately answered ‘yes, of course’.
That project got me into a path of many headaches, a little bit of burnout, and especially infinite coding hours. That was a huge learning path as well, and an inversion too. I think that I was being almost a senior dev, despite being junior. Therefore, as today is programmer’s days, I would like to give some advice for junior’s developers.

Being a software developer.

First, I would like to say that I live in Argentina, Latam. This is important, because I don’t know how being a developer in another country or region and these bullet points, I am writing below, may be different or not in other locations.

Second, this is what I think or believe because it is my life. Take what you want, and then readapt them for your own context. Sometimes what is good for someone is not for another person. There is a lot of advice over there and sometimes it is similar, sometimes is not. Again, I believe this today, but this is not math, you could do great as well if you won’t take any of them.

Third and finally, don’t re-invent the wheel. Try to take as much advice as possible. The more, the merrier. I know this is contradictory with the second one I wrote above, but that’s how life is.

What does a software developer do?

A software developer is a person who solves problems. If you want to be an artist, be an artist, not a developer.

What do I mean by this?

You need to focus on which problem you are solving. It is always one. It can be hidden or explicit. Sometimes, nobody is thinking about it, and the brief is about something else too. This is because it is difficult, as a person, to explain us, and sometimes also to know what we want. In our cases, the brief is usually made by account person who is listening to other people who don’t know exactly what they want, and the account are doing their best to make a brief. However, take my word, there is always a problem.
The issue sometimes comes from another team member. For example: You need to adapt that beautiful design to many screens, browsers, and devices in the world.

  • If you are solving a problem, it must be solved as soon as possible. Therefore, you must always keep as simple as you can. Because simple is faster and cheaper. That’s the main reason you need to focus on the main issue you are fixing now. If you are doing a landing page, perhaps, you don’t need to use React, NextJS or WordPress. Unless using one of these technologies makes you work -at least- 2x fast.

How can we be such simple?

DRY is a common principle in software development that reads, ‘Don’t repeat yourself’.
For example: if you are writing a program which calculates the distance between an element and another, a good practice will be to write a function to re-use it any time you need to calculate this.

However, there is another famous software principle: KISS. ‘Keep it simple stupid’.
If you need to calculate this only once, there is no need in making a function. Because you are making the code more complicated.

These two software principles show that being simple is the hardest thing ever. Anyhow, the only way to be simple is learning and gaining experience. Therefore, a good software developer must always be getting new techniques, new technologies, and especially new skills.

  • A new technique could be useful to make the same job faster. But it is not enough just to know it. Practice, and practice more, will help you to get better in your daily work.

  • A new technology could be useful to solve a problem in a different way. There are sometimes faster, sometimes slower, but there are always two or more solutions. Don’t forget: Technologies are just tools. Thus, if you have many tools in your toolbox, you will work faster, easier, and better.

  • Developers must develop new technical skills. If they are backends, they should learn frontend and the other way around. A developer must know about hosting, servers, domains, and networking. Not for changing their jobs, but it will be helpful just to know what happens when their job is finished. If they are making the front, it is useful to know where the data comes from. If they are making the backend, it will be useful to see how the user will interact with all the processed data. Besides, you will need to know how the data flows over the internet as well.
    However, everybody should be working on what they want. I am not trying to push everybody to do everything. I wrote before, you should only know. Because, sometimes, knowledge is enough. A developer mustn’t be an octopus but must be open-minded. “Curious” is the magic word. The more they read, watch, or listen to; the better prepared they will be.

We could learn all this by ourselves, though the best way to do it is by sharing experience with other people: our partners, but also designers, stakeholders, everybody…

Networking!

Soft skills are important too, don’t forget about it. Many people were born with soft skills included, but others, like myself, have to practice them a lot.

  • Good developers know how to express new ideas, explain difficult tasks, or tell a partner what we need to do.

  • We should learn to listen behind the words to detect what the problem is we need to solve.

It is useful to chat with everybody: Designers, stakeholders, account manager, QAs; ask many questions as you can. Everybody has a different point of view, and this is useful for us to see the whole picture.

  • And the most important: We must always transfer knowledge to new developers. Because someone helped us before, and we have to pay it forward.

Being a team player. This is the way!

. . . . . . . . . . . . . .
Terabox Video Player