DEV Community: Andrii

Where do you see yourself in 5 years?

Andrii — Sun, 14 Jun 2020 19:39:07 +0000

I know it is quite a popular question on the interview, but do you think about this in everyday life or only during interview preparation?

Have you set goals for the next several years?

Are such thoughts/questions becoming less relevant over time, e.g. after 10, 15, 20 years of work?

P.S. as for me, I think about it quite often, and I plan my future as I still have opportunities for growth.

Do we really need getters/setters?

Andrii — Tue, 09 Jun 2020 14:56:35 +0000

In 99% of code, I haven't seen any logic in getters/setters, so it is literally the same as using public fields.

For me, nowadays, it looks like unnecessary stuff that we use out of habit.

So the question is, why do we continue using them? 
What do you think?

How to sell your idea to the team

Andrii — Thu, 04 Jun 2020 18:19:34 +0000

The key is to be prepared.

Everything can be changed or improved. Sooner or later, you will have ideas for improving something in the project you work on. Maybe you read something, watched something, or just had time to think about the current situation, and an idea came to you.
It can be anything:

how to improve code
how to improve processes
how to improve the design
etc.

It can be small and big. It is not so hard to convince someone to make some minor changes.
But it is more challenging to do it when it requires fundamental changes.

Don't be afraid to present your idea to the team, just make a preparation.

Ok, let's go.
Imagine that you have an idea of how to improve current software architecture, and you think it is good and brings lots of advantages. Now the time has come for hard task: remember all your technical and soft skills and convince others that it makes sense.

How to promote your idea?

Analyze the current approach

First of all, you should analyze the current approach and understand how and why it was implemented or designed it. Most probably, this knowledge will help to convince others.

Find the pros and cons of the current approach

You can't just say that your idea is better than the current process/approach/architecture. It does not work like this.

Prepare a list of the advantages and disadvantages of the current implementation. This list will help you and others to make a decision.

Prepare pros and cons in your idea

Yes, your approach can also have drawbacks, there is nothing ideal, but your approach can have fewer drawbacks or less critical. This will show which problems of the current process will be fixed in a proposed approach.

Prepare step by step plan

Prepare a list of steps or tasks that should be done to implement your idea. First, it helps others to see the scope of changes and will show that you know what you are talking about.

Don't forget about estimation

Once you have a plan, you should estimate how much time it will take.
How much time from implementing real business tasks will be taken for this improvement. It should not be a precise estimation, but it shall show which numbers you are talking about.
It's essential, without it, nothing can't be decided.

Make a presentation

You definitely need to present somehow your approach to the team/ team leader, and it is impossible to do without any prepared materials: pictures, presentation, etc.
So yes, prepare a presentation or anything that helps you keep the presentation's structure and give more visual information to the team.

Be prepared to questions

They will definitely be.
When your team sees your approach, they will ask questions, and challenge your proposal, to understand if it will cover their needs and improve the process. You should test your own approach as well and have your answers to such questions.

Don't give to many options

You should analyze and present only one, two options to the team, as you already did the analysis and made a better decision. Otherwise, it will be harder to decide and will take ages.

Give people time to think

Give people time to think about your proposal. Maybe they find something that would need to improve, some new cases that should be covered, or perhaps they just realize that yes, it is good and should be implemented.

But don't give an unlimited amount of time, organize a follow-up meeting with them in a week or two.

Feel satisfied that you did it

Even if your idea isn't implemented, you already have "+" to your karma.

In the end

Don't be afraid to improve processes, architecture, etc. It will show to others that you are not only a code writer but also can do more complicated things. Presentation and soft skills will definitely be useful for your career.

P.S. Have you ever tried to present your idea to the team? Did it work? What other tips can you add?

I don't want a higher salary...

Andrii — Wed, 03 Jun 2020 18:10:56 +0000

What would you choose and why:

15-20 percent salary increase(or your own percent here)?
4-day work week while retaining current salary?

From microservices to ...

Andrii — Mon, 01 Jun 2020 13:57:26 +0000

Why are there almost no stories about

moving from microservices back to monolith?
merging microservices?
redesigning them?

Is it just not so popular, exciting to tell about as moving from monolith to microservices?

Do you always make correct division into microservices?

Keep an eye on small teams

Andrii — Mon, 01 Jun 2020 10:26:19 +0000

There is always safety in numbers

In the era of microservices, teams become smaller and smaller.
It is understandable. If you have microservice, you don't need a big team to work on it. But sometimes it becomes too small, and it brings problems.

It is just my vision on this, if you agree or not, please leave your comment.

Why don't I like super small teams?

#no second opinion
don't know like others, but I like when other developers challenge my code or architectural approach. Another opinion on the problem can help to build better solutions and help you to become better.

#software architecture problems
basically, issues are the same as above. Without another pair of eyes, you can build something that only in your mind will look great.

#no real reviews
if you have only 2-3 people in the "team", it becomes tough to do proper code review. Especially if the team is split to FE and BE developers. Most of the time, FE cant check more than fields name, method size in BE code, and visa versa. And some real conceptual issues won't be found.

#project can easily be stopped
If the team is tiny, simple vacation or sickness can stop work on the project. Imagine what will be if the member decides to leave the company. It's a huge risk for the project.

#a bargain with conscience
when you work alone, it becomes easy to skip tests, make a nonoptimal solution, don't cover some corner cases that you know about.

#boring
for me, sometimes it is boring to work in a small team, especially if there is no communication with other teams.

Is there a way to improve this?

__#no less than 5
from my perspective, the minimum team size is five members. Let's consider a simple web application. To develop it, the optimal would be 2 FE dev, 2 BE dev, and team lead in such case we won't have problems related to small teams.

#bigger team working with several services
if you have two small groups working on two small products, make a bigger team that maintains several. In such way, you mitigate risks and avoid problems related to small teams.

#full-stack developers
try to grow or hire a team of full-stack developers. You can cover problems with reviews, with a second opinion. If one of the teams cant work, another developer can build the whole E2E as he can cover both BE and FE parts.

#reviewers from other teams
ask members from other teams to review your code. You will have another view, and understanding that someone else will check your code will keep you in shape.

#big design team, small development team
sometimes the problem can be not on implementation level but the design level. If the team is really small, it hard to have discussions that will help to challenge your architectural decision and identify hidden corner cases that could lead to changes in architecture.

#team mixing
if you are switching members periodically between projects, more and more people will be familiar with them. It will be easier to find a replacement for a person going to leave or for the vacation period.

In the end

The micro team is a risk and can cause problems. Don't forget about it.
If you can improve situation, do it.

P.S.:

What size of the team do you work in?
Have you ever worked in teams with less than four members?
Do you like to work in small teams, or you prefer a big one or several small teams that work on the same product?
Can a group of 2-3 people be considered as a team?
Is it reasonable to have such small teams?

They know better or why are we afraid to change someone else's code?

Andrii — Sun, 24 May 2020 16:23:08 +0000

We all don't like to look at the code that we wrote half a year ago. More than that, we don't want to work with code that someone else wrote. This article is about the fear of refactoring someone else's code that some developers have. It's my observation and thoughts based on work with different people in different teams. I will try to answer questions: why some developers doubt against refactoring, why is it wrong, and how to overcome it. Small spoiler - team lead is responsible for this.
The article may be useful for self-doubt middle SE and team leads.

Sooner or later, we all find ourselves on a project that has already been partially written. It can be at the production stage; the person who started the project can already not work on it. Some people will quickly start to change and figure out the new code. But there is another type of people: if they do not understand something, they simply pass by this section of the code. They do not notice flaws in the code, and even if you show them that something can be improved, they don't want to do it.

I want to talk now about the reasons behind such behavior. After all, such an attitude will not lead to anything good.

I have seen such excuses:

#they know better or code-trap
Seeing a strange, incomprehensible code, they are trying to justify it somehow, come up with sometimes weird reasons why it is written in such way and that if they touch it, the application will fall apart like a house of cards.

#i'm not that good
or if you exaggerate, the thought "I don't know anything," an inferiority complex, an impostor syndrome. Call it as you want, but it does not change anything: you doubt yourself, your knowledge, and experience. At the same time, you think all others are smarter than you. And most importantly, you believe that person, who wrote that code, is a better developer than you. This is all because the new project is not yet familiar to you, codebase seems complicated, and the person, who wrote this code, obviously looks like a genius.

#laziness
There's no need to explain; often, you don't want to touch any part of the code because it will take some time to rewrite and test it, even if it will take a really short amount of time. And the developer eventually ceases to see problems because he does not want to.

The following two reasons are the lack of team lead.

#we were not told that it is possible
Sometimes developers are afraid to take a step to the left or the right of their task, because nobody told that it is welcomed and allowed, and sometimes even necessary to refactor code, that you see and touch, while you are doing your task. In small steps reducing technical debt and making the code easier to understand for yourself.

#fear of reducing their productivity
As you don't know if you can or not refactor code, you don't want to spend some extra time improving something, as you don't want to look like low-performer in team lead's eyes.

What will it all lead to:

#black box
Without dip dive into code, you will not figure it out, and some parts will be a black box for you. If you don't know how it works, then this is fraught with pitfalls during the development of new functionality.

#eternal code
Such code lives for a very long time, and fixing and refactoring it becomes more and more difficult.

#chaos
Such code may begin to grow with crutches; you fix errors with workarounds, introducing even more chaos into the codebase.

#the technical debt in itself will not be fixed.

The way out or how to improve the situation:

#team leader should do his work
The team leader should be the main driver, it is his task to straight people in the right direction and set up processes.
He should share with developers, that refactoring is not bad, that fresh ideas are good, that you can change written some time ago code.
The team lead should make it clear when you can spend 10-20% more time refactoring the code that accompanies your task.

#you should eradicate your impostor syndrome
Accept that everyone has some experience, and even geniuses can write imperfect code.

#you should be proactive
With each code change, make it a little better than it was before. No one forces you to redo the whole application. Just understand the incomprehensible code, make it more readable, even this is enough.

#conspiracy theory does not exist
Do not search for the deep purpose of the weird code; in most cases, it is the result of a compromise between "make it quickly" and "make it work".

#write it down
If it's not possible to refactor it now, do just a little - document it. Once created, a ticket will help you know the amount of technical debt and know the weak or gray parts of the project. Also, such tasks can be suitable for a beginner to start to understand the project code.

#your code your responsibility
Do not treat the code already written before you as something alien. You are now on this project, so now this is your code, and all bugs are your responsibility.

In the end

Every leader's task is to establish processes and let the team members know that they can refactor the code. The responsibility of the developer is not to be afraid to do this. For you, the code that your predecessors or current colleagues wrote is one big technical debt, and you need to figure it out.

Write a code, overcome fears.

P.S.: What do you think about it? Have you ever observed such situations in your teams?