DEV Community: Milan Latinović

Your Career Doesn't Have to Be a Straight Line (And That's More Than OK)

Milan Latinović — Tue, 04 Nov 2025 21:31:34 +0000

I wrote about my non-linear career journey—from government department head to senior engineer to startup IC—and what I learned from stepping "sideways" twice. Read the full story on my Substack →

We're taught careers should be ladders. Always climbing up. More responsibility, bigger titles, higher salaries.

But what happens when the most exciting opportunity asks you to step sideways? Or even down?

I've made that choice twice. Both times, people questioned it. The heck, I questioned it. Both times, it was the best decision I could have made.

The Moves That Looked Crazy

Move #1: Left my Head of Department role in government to become a senior software engineer at a SaaS company. In a different country. Starting over completely.

Move #2: Climbed back up to Lead Integration Engineer, had a clear path to management... then joined a startup as an individual contributor during COVID.

What I Learned

Those "lateral" moves made me multidimensional. Government taught me structured thinking. Enterprise integrations taught me to solve complex customer challenges. Startup SaaS taught me to think on my feet and prioritize ruthlessly.

My hot take? Legacy code is often the money-making part of the machinery. People complain about "ugly code," but they're often hired with money earned by that same code. Sometimes the best architecture is the one that works and makes money, even if it's not elegant.

The Real Definition of Career Growth

Career growth isn't about always moving up. It's about moving toward what makes you better, more fulfilled, and more capable of doing work that matters.

My career isn't linear. It's a spiral—sometimes more technical work, sometimes more management, but the average is always going up.

If you're considering a non-traditional move, ask yourself: Will this let me learn what I'm hungry to learn? Will it give me ownership over work I care about?

If yes, then it's not a lateral move. It's strategic positioning for the career you actually want.

Want the full story with all the awkward moments, doubts, and specific lessons? Read it on my Substack →

Have you made a non-traditional career move? Drop your story in the comments 👇

Applying artificial intelligence in software engineering - our status and the future?

Milan Latinović — Mon, 15 Mar 2021 19:05:24 +0000

I know everyone's time is precious so I’ll cut to the chase:
I am doing a PhD research related to the future of AI-based tools in software engineering.

But to do this, I need experiences of my fellow software engineers, QAs, POs and managers.

Could you give 15-min of your attention and fill-in anonymous survey:
https://www.milanlatinovic.com/survey-artificial-intelligence-tools-in-software-engineering/

Almost all questions in the survey are optional, so you can skip those that do not interest you. Also, there are open-discussion fields where you can write longer comments if you find something that is very interesting for you.

This is a follow up on research which is already published at HICSS-54 http://hdl.handle.net/10125/70628

Thank you very much!

How is code review organized in your company?

Milan Latinović — Sat, 16 Jan 2021 10:37:54 +0000

Code review is a process, which has a goal to assure the quality of delivery. In this specific case, the team is reviewing the quality of the code. This is accomplished by one or more developers examining the code which their colleagues wrote.

How are you doing code review? Do you pick someone who will review your code or is it voluntary? How much time does it take? When do you do it?

Code Review Best Practices – Good, Bad and the Ugly

Milan Latinović — Fri, 15 Jan 2021 16:17:15 +0000

This article is about the code review best practices. It explains code review from the common-sense perspective. If you do not want to read through the whole article take a look at the table of contents and the summary for a quick overview.

What is a code review process?

Code review exists to prevent bugs from ending up in your production. But, it is much more than that. It has technical aspects, technologies, expertise, knowledge change, and feelings involved.

If you are the person being reviewed you want to know what can you do to make your code more understandable. On the other side, if you are a reviewer, you want to make a positive impact on the reviewed code.

A code review in its essence

It is a process, which has a goal to assure the quality of delivery. In this specific case, the team is reviewing the quality of the code. This is accomplished by one or more developers examining the code which their colleagues wrote.

Code Quality Measurement - Medium, unknown source

The quality of code review is hard to measure. However, a good code review should be able to accomplish several items.

Find potential problems/bugs in code and provide ideas on how to handle them.
Improve the structure of the code if possible (utilize proper software design patterns, refactor and better segmentation, etc.)
Check if the feature actually works, while trying to find additional test (and edge cases) to check if the code would work in specific situations.

What is a good code review?

First of all, a good code review is friendly, polite and it aims to help improve code and product or feature this code implements. Secondly, it is a process where knowledge and experiences are shared. It is where developers get dedicated time to communicate, raise concerns, consult, and try to discover problems before they happen.

A good code review is event where developers:

check code quality and ensure it is up to company standards
share their experiences and concerns, ask questions about possible impacts of new code changes
address concerns, compare coding approaches and most importantly share knowledge
build team, trust, and respect for each other
learn on their mistakes and get well-intended advice on how to improve

More importantly, a good code review is not, or at least it should not be, a place where anyone tries to demonstrate any kind of domination or does any ill-intended actions. It is a consultancy, an unwritten agreement between developers to help each other by double-checking what was done.

Common-sense rules and checks of a code review

Before starting with a code review, we should consider several important ugly truths.

Planning of reviews is important when describing tasks

Ticket planning should include the time needed for a proper review. The team should be aware of something called Definition of Done. This is a list of things that should be completed before the ticket is considered as finished.

Review tasks should be part of DOD and review time should add to that ticket. A team should calculate the cumulative expected time for this ticket. If 3 developers spend 2 hours that is actually 6 hours for code review, which is 1 man/day of the sprint.

Choosing the right reviewer or more of them

Original developers should test reviewed code before inviting others to review it. This is important because it will save everyone's time. Developers will always make bugs. The only question is when will the team discover these bugs.

Code reviews and the management

Managers will not always have an understanding of the time needed to do a proper review. It is up to developers and reviewers to communicate this properly. Other team members will not always have an understanding of long or complicated reviews.

People make mistakes and that is completely all right. Bugs might appear in code, even after a good review.

Bodith - First Time Managers

Furthermore, we are aware that different reviews can have different weights. For example, some reviews will be easy, while some of them will be hard.

Let's try to group these code reviews in categories, so we can establish code review best practices.

Are code reviews worth it?

Yes they are.

Really, no doubt about it, they are.

Yes, code reviews are worth it. I pinky swear on it.

OK, now when we have established that, let us elaborate on why code reviews are worth it.

Downsides of code reviews

Code reviews take time, sometimes lots of time. Multiple developers are reading code, spending time and focus on it. Management sometimes does not understand why this investment is important.

Sometimes, code reviews can block development. A common example is when one feature is not completed because something complex is discovered during a code review. This is blocking other features etc. However, this might indicate that planning was not done in a good way.

Different people do code reviews with different motivation, spirits and quality. We are not all equal and we should not be. Capable manager or team lead should know how to leverage their team and build code review process to focus on strong sides of team, instead on weak sides.

Upsides of code reviews

Code reviews are improving quality of code, reducing future technical debt and improving overall quality of software. Furthermore, they are in a way building a team, people communicate, share opinions, concerns, fears, advises and faith.

Without code reviews there would be less quality, structure and teamwork. Even time savings would not be there, because that time saved on code review is already lost and reserved for fixing issues and sorting our overlooked problems.

Code Reviews might take some time

Reviews won't happen in a minute, it takes time to do it properly. The team should plan proper time blocks, depending on the complexity of the review.

Categories of code reviews

Determining a type of review early is extremely important because it provides us with information on how to handle it. Furthermore, we should be able to compare our capabilities to properly examine the provided code.

Finally, if the review is too challenging we might decide to invite another reviewer or even ask to be additionally educated on technical topics from that review.

Code review is also called the pull request, I am using both terminologies in this article, depending on the sources that I am referring to.

Classifying by urgency

Ben Balter, a Senior Manager of Product Management at GitHub, wrote a fantastic post about The six types of pull requests you see on GitHub. This post classifies pull requests as:

Just a heads up
Sanity check
Work in progress (WIP)
Early feedback
Line-by-line review
Pull request to pull request

Furthermore, Ben described how each of these types works and when to use it. For example "just a heads up" would be a simple (one-liner) pull request where the author doesn't need review.

On the other hand, line-by-line is pull request which is used when product is ready to be shipped.

There is no denying that pairing is a highly visible cost to management: "Two developers at one workstation? No way! We already pay them a fortune!" - Paul Blair,
The Unnoticed Costs of Code Review by Pull Request

Classifying by size and familiarity

Firstly, when we examine new pull request, we need check number of changed lines.

If a pull request has more than 500 lines author of that request should consider splitting it into multiple parts or find a way to get involved in the code review process.

Furthermore, reviewers should check if tests are executed for big pull requests.

Otherwise, reviewer might find critical issue in the middle of review, and then everything would go back to start.

Classifying by impact

There are two ways to consider impact of a pull request:

What positive and fantastic things will happen when we launch this new cool feature?
What s*it will hit the fan if and when something goes wrong with this cool new feature?

The second one is the important one.

When measuring impact of pull request, team should think about several things:

Could there be any data corruption?
Will we be able to revert the problems if they happen?
How many users might be impacted by this?
What kind of policies might be compromised by this? (GDPR i.e.)
Is this feature related to SLA (Service Level Agreement)?

Who should care about code complexity?

But wait, should the developer or reviewer really be concerned about these items during the code review?

No.

Because these things should have been defined when a ticket is created and planned. For example, during the sprint planning phase, or even earlier during sessions between product owner and management.

However, developers should not close their eyes if they notice any of the mentioned issues.

On the other hand, don't overthink it. - Dilbert again

What are code review best practices?

Code Review Best Practices Checklist:

Keep it friendly and polite
Make test cases for all newly introduced or modified code parts.
Do syntax errors checker
Follow up on the latest coding practices
Pay attention to software design patterns
Consider legacy code and impacts to legacy features

Keep it friendly and polite

I can not stress this enough.

It is important to be friendly, professional, and polite during the code review process. The bigger the company, professional communication is more important.

It does not matter if you are the person who is reviewing or the one being reviewed. Keep an open mind, accept any and all comments with dignity and grace. Always think of what you can improve and what others might benefit off.

Don't try to be ironic or angry. If some comment is important clearly state it. On the other hand, if something is just your opinion and it does not hold objective improvement state that as well.

Test cases

Execute any available tests for feature which you are reviewing.

Think of manual (quick tests) which can be done. For example, if the feature changes the database connection function, simply try to connect to the database. If your feature is changing the BasicController component for API, just try to execute a couple of different API calls

I was already writing about clean code rules and how to improve the quality of your code. By improving the quality of your code in general your skills will get better both as a code reviewer and as the one being reviewed.

Syntax errors

Different developers use different coding editors. Some companies have policies about this and some don’t.

Therefore, it is expected that some syntax errors might crawl up to a pull request.

What does this means?

Don’t examine pull requests only trough pull request interface (i.e. bitbucket or gitlabs). You can also check out these branches and examine them in your trusted editor.

Coding practices

Most of the companies have some document with coding standards or best practices.

If such document exist, pull request should include comparing the latest code with these best practices.

If there is no such document, here are some quick things to check:

consistency in variable names
proper comment blocks on new functions
separation of concerns
code should not contain any sensitive data (i.e. access tokens)
your code should not contain any demo data (except inside of the tests, or where this is really needed)
code should be clean

Software design patterns

Depending on pull request and type of the change some software design patterns can be applied.

Also, if some design patterns are already inside code architecture they should be applied.

For example, adding a new function in all inherited classes of an abstract class would not make sense. Furthermore, having a strategy pattern in place and not creating a new strategy for some configuration would also be a wrong usage of that design pattern.

Legacy aspects

Your software will always have legacy software.
Meaning, your pull requests will affect this software somehow.
Therefore, you need to handle this. 🙂

Summary

The code review is an extremely important part of the whole software development process. Therefore, the whole team must make enough effort to properly plan the time needed for this.

Pull requests differ from case to case, but teams should always be aware of impacts and potential issues.

Mistakes will happen to those who work. Code review is essentially risk management, therefore it should be treated as such.

A good code review will improve the overall quality of the code, but it will also reduce the risk related to a new feature.

Automation and Artificial Intelligence in Software Engineering: Experiences, Challenges, and Opportunities

Milan Latinović — Sun, 10 Jan 2021 10:11:03 +0000

This article is about Automation and Artificial Intelligence in Software Engineering: Experiences, Challenges, and Opportunities. It represents a paper published at a highly ranked HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES (HICSS).

This paper was written with great help and supervision of prof. Viktoria Pammer-Schindler.

Given article and paper might be relevant for you as well.

Firstly, you might be the owner of a software development company thinking about improving your business processes.
Secondly, you might a researcher engaging in these topics and searching for relevant literature and references.
Maybe you are an investor thinking about engaging in this disruptive domain.
Finally, you might be a software developer curious about how your peers are doing development, what challenges, issues, and opportunities they have.

If any of these cases apply to you, you should read this article together with the paper which is presented here.

Quick overview of Automation and Artificial Intelligence in Software Engineering

If you don't have time to read through the whole article and paper, I made an up-to-point video presentation that gives you all the needed insights. Afterward, if you want more details you can read the official paper here.

https://www.youtube.com/watch?v=w5rbi0gZKg0

Transformative influence of the Automation and Artificial Intelligence

What Is our research about?

Automation and artificial intelligence have a transformative influence on many sectors.

For example:

Firstly, increased automation and deployment of data analytics and Artificial Intelligence has been coined Industry 4.0 or smart manufacturing
Secondly, in medicine - machine-learning computer-aided detection and automated diagnosis in radiology
Finally, auto-encoder neural networks can help financial auditors identify unusual journal entries in an audit context

We understand automation as a set of computational tools executing domain activities, based initially on conditional logic.

For Artificial Intelligence, we understand a broad range of technologies and technological capabilities based on processing natural language, audio, images, and video; formal representations of knowledge and automated reasoning; and machine learning.

What are the important questions?

So, from previous examples, we can clearly recognize that Automation and Artificial Intelligence have a transformative influence on many sectors.

We recognize Software engineers as the actors who engineer this transformation.

However, there is little knowledge of how automation and Artificial Intelligence impact them, meaning software engineering practice. We approached this problem with two research questions, presented on this slide.

First one, aiming to understand the current practice. So, we are asking:

What are approaches for automation and Artificial Intelligence enabled tools and practices adopted by interviewed software engineers?

The second one, aiming to understand the attitudes, hopes, and concerns of software engineers.
Here, our question is:

What are approaches for automation and Artificial Intelligence enabled tools and practices adopted by interviewed software engineers? The second one, aiming to understand the attitudes, hopes, and concerns of software engineers.

What kind of research we did?

In the early stage of our research, we were thinking about which approach to take. For finding answers to our questions we decided to conduct qualitative research, based on semi-structured interviews.

We wanted an opportunity to listen and take notes first and then discuss.

We did this by means of screen share, typing quasi-verbatim notes and sharing them with participants, so we can discuss, validate and agree on those.

Our questions started from common questions to get to know our participants better:

What is their job? What their company does?

Then, we wanted to know more about their environment. What did they automate in software engineering and in their work?

We were curious if they have automated something them selves.

We also wanted to know who initiated automation in their company.

Finally, we asked if and how is Artificial Intelligence fitting in their activities.

Once we gathered data, next step was analysis.

Here, we did inductive and reflexive thematic analysis.

Inductive means: Reading through notes. Identifying a priori unknown patterns in the described experiences of our interviewees
Reflexive means: Describing and summarizing the experiences of interviewees. We developed themes during the data analysis.

These themes, compared with the literature overview provided answers to our questions, but also triggered additional discussion topics.

Who we interviewed?

Related to interview participants' profiles. We interviewed experienced software practitioners across frontend, backend development, DevOps, R&D, and integration.

Diversity in gender and age, sector (industry or academia), industry domain (Software as a Service - SaaS, logistics, networking, software security, semiconductors, automotive, industrial automation, or computer hardware), professional position, and technology stack (ongoing experience with various technologies).

We recruited participants online through the Linked-In network and in-person within corporate environments and conferences.

Some participants recommended others for interview as well.

What were our results? What did we find out about Automation and Artificial Intelligence in Software Engineering?

commonly automated activities, tools, and challenges in software engineering

One of the first things we recognized, even during interviews, was enthusiasm toward automation.

Software practitioners have common activities they need to automate:

Environment configuration - for example, new developer setting up a machine (one script vs days of configuring and installation tutorials)
Static code checking - recognizing is code syntax is good, dead code, obvious bugs, bad coding practices, also known as a code smell. These things are closely related to code review best practices.
Especially, testing - running tests automatically when a new code is sent to the server.
Literature also states that Artificial Intelligence is helpful for writing technical specifications and estimates.

Developers use different tools and approaches to accomplish same automation goals.

Process bridging with micro-automation

Automation and Artificial Intelligence in Software Engineering in software development might appear in different processes.

Each process is set of steps that initially has to be done manually.

When developers have large number of manual steps, mistakes can happen and some steps can be forgotten.

Also, if steps are happening between different environments and systems, this can be time consuming.

This is why developers are writing micro automations to make their work easier.

Micro automation is usually implemented in form of custom scripts, automatic configurations, development helpers, testing optimizations, and so on.

In the given example developers want to make a backup on a specific server, and as a result, he needs backup hash.

He triggers script on server, which has automated backup procedure.

This procedure is connected with team chat where backup hash is delivered.

There are multiple benefits from this automation.

The developer does not have to do the backup manually.
Hash is saved in team chat where everyone can see and use it
Everyone is aware that backup activity is happening and there is a clear history of backup actions.

Automation of software engineering as a bottom-up driven side product of operative activity

One of our most interesting findings is that the automation of software engineering is bottom-up driven.

Meaning, our participants reported that top-level management was not the one who initiated automation.

Also, automation is usually side affect or bonus activity, but rarely the goal itself.

One of our candidates compared automation with defensive player in football.

Meaning, everyone knows that automation is important but there is no immediate cache returns out of it.

Most of our participants reported automation as quick solutions tailored to a specific context and need.

Automation and effects on work efficiency

Our participants also reported different effect of automation on their work efficiency.

What we need to understand here is that automation is usually a black box for person who uses it.

Automation does something for software developers but they want to be informed about it.

Still, not all automated tools are good at this.

We had reports of automated tools which were sending large number of notifications.

This required software developers to constantly get distracted, check or double-check some things they already know.

Sometimes, automation would send lots of data that is not useful or, at least, not structured in a useful way.

Our biggest takeaway from this is this.

Automation should communicate with software developers, but by providing good data with good context, if needed and when needed.

Unclear impact of Artificial Intelligence on the future of SW engineering practice

When it comes to Artificial Intelligence and impact on software engineering, results are unclear.

Our interview participants have not reported AI-enabled tools that are substantially changing their work.

When we asked them how they feel about AI as a helping tool or as a teammate, their responses were mixed.

Most of them were enthusiastic about having AI as a helping tool.

However, they did not see AI as an independent, final decision maker.

Let us make an example for this.

Having a smart coding assistant which recognizes issues and offers solution and advice is AI-helping tool.

Our participants would like to have tool like this.

AI-tool can also implement solution and deploy it to server, without consulting developer.

This is something our participants were not so enthusiastic about.

What do we make of these findings?

Bottom-up and Micro-Automation

Our research provided several interesting results. In the paper, we provided our interpretation of these results, also taking into consideration the existing literature review. This resulted in different discussion topics.

For example: How are bottom-up automation and micro-automation linked?

Is it possible that bottom up nature of automation leads to micro-automation.

This would make sense because is it not likely that a bottom-up perspective can result in a scalable solution that is implemented across a complete organization.

It simply might not have complete perception, motivation or required resources to do so.

On the other hand, we ask our selves what is causing automation to have this bottom-up nature?

Is the because of the nature of software engineering? Maybe because software engineers know how to automate they simply do it, but only within their area of work, without scaling it.

Finally, how to evaluate the socio-technical effect of automation? How to calculate the cost-benefit of automation?

We find these very interesting discussions with both theoretical and practical implications.

Future of AI-driven applications

Our interviewees were enthusiastic about AI-enhanced tools but skeptical about “AI being in a driver’s seat” and making decisions. Also, in literature research, we recognized different AI-driven applications.

For example, code error prediction, error localization to help developers write code, and assistance in effort estimation, to help project managers define efforts based on different algorithms.

We asked our participants what they think about these applications.

Answers were different, but the constant was enthusiasm toward AI-enhanced tools but skepticism toward AI-driven tools. This is something that requires careful interpretation.

We must take into considerations that our participants were NOT AI experts.

Still, maybe software engineers do not seriously engage in thinking about how is their profession affected by Artificial Intelligence?

On the other hand, maybe software engineering is moving toward the “skill diversity phase”. This would divide software developers between users and architects. Users would do programming supported by AI, while architects would create AI-enhanced and AI-driven tools.

These are all very interesting topics, where additional research should be conducted.

Kick-starting Your New Developer Job with these Essential Tips

Milan Latinović — Sat, 09 Jan 2021 23:54:43 +0000

This article is about kick-starting your new developer job based on my experience gathered in multiple companies and projects. Read it, prepare well and you will do great!

Introduction

Kick-starting your new developer job is very important. Different teams will have different expectations, but essentially you will be expected to find your place in the company. Are there any essential tips for doing this?

I am sharing my experiences based on several different companies and projects I participated in so far. In each of these environments, I had to start from zero, without any significant knowledge of a project or team.

There are experiences from projects and companies such as TimeTac, Codeable, ApiLayer, and Eversign.

By following these important guidelines, I was successful every time. But more importantly, focusing on these things made me feel professional, pushing forward, motivated and I enjoyed working on each of these projects.

Read them through, and share them if you find them helpful. Good luck in your new job!

Steps to kick-start your new developer job

Understand how your company work, how does it earn money, and why are you hired
Learn about the company product
Get used to company language and vocabulary
Ask about company processes and understand them
Set up your development environment, try being independent
Set yourself clear goals with (MIT) Most Important Task on a daily basis
Keep your code changes "diff size" small
Aim to be a positive zero at the beginning, reduce risks
Brush up on your social skills, understand company rituals and habits

Companies one on one, or how stuff works

Understand why you are hired

We are hired by a company or as a consultant for some project. Companies earn money by selling a product or service, or software as a service (SaaS) for that matter.

To make this happen the company hires different people to contribute to their teams. Everyone can contribute in their own way, but there is always some process to describe how things are done. Tasks are usually done in some specific way.

Understand company playground

Then there is the technical environment, which is a playground company set for a team. This environment can really be anything technical. Tools used for coding, debugging procedures, how to test, how to deploy code, who to ask, which tool to use for communication, etc.

Finally, there are open issues and challenges, things someone has to do. That is most likely why the company hired you.

Kick-starting Your New Developer Job, step by step guide

Learn about the product

The first thing you want to do is obvious, you want to read the product documentation. But, this can be tedious, because documentation can be overwhelming.

You should pretend you are a customer who wants to use product. There is no need to go into depths yet, there will be enough time and need for that later.

So, start small, find marketing and promo material, read through it. Then, find customer "how to get started" guides and go through them.

If your company is making software as a service, open a free account or ask someone to give you a user account. Play around, see what software does.

Finally, introduce yourself to sales and customer success teams, they are the closest you will get to customers.

In my experience so far, I was always meeting amazing people in these departments. They have knowledge of how stuff works and in most cases, they want to share it and make a good team.

Bonus tip: If your company has a backlog, read through it, actually skim through it. However, don't get scared or overwhelmed. Very likely 50 of the things in backlog will not be refined or over-scoped.

Understand company language

Companies use specific domain language to describe their products and needs. Very often you might fail to understand something only because vocabulary is not familiar to you. It might look like the team is much more knowledgeable than you, when in fact, they just have "the lingo".

There is no strict rule here, other than listening more than talking and asking whenever something is unclear.

Very important advice would be: Do not fake that you understand something if you don't, ask away.

There is an interesting article about Domain Driven Development, which is a beginner's guide to understanding Domain Driven Development. It is closely related to this topic and you might want to read up on it as well.

Learn about processes

Ask questions about anything you are not sure of, don't assume. If you will be working in a company, you need to know what to do, who to ask for help, and when.

Some things you might need straight away, how do you get tasks, is there a supervisor, who is your technical peer, how do you push code to production. Then, what chat tool do you use i.e. Slack), which channels are important, where can you ask for help?

Keep an open mind, some companies will not have ideally optimized processes for everything. You don't want to start suggesting process changes very early. Two reasons for this. Firstly, you don't know the reasons for these processes which might be very valid. Secondly, you don't know enough about the company to be able to suggest something useful at first.

In short, ask a lot of questions and, when it comes to processes, try to be the one who is listening, instead of talking.

The importance of the feedback

While you are learning about processes and trying to find your way around, you should ask your team to give you feedback on what you are doing.

This way you will know if you are going in the right direction. Asking for a feedback should be a common thing you are confident to do all the time.

As an example, when I wrote this article I asked few friends for a feedback. They shared many interesting insights, from technical to logical and cosmetic ones.

One friend told me that my LOTR (Lord Of The Rings) meme from previous section is outdated and that I should go with something more modern. This is funny, because I already got this comment once at work when I was using similar meme in a presentation.

Long story short, I took some time and make the best out of this comment. Here is a my LOTR meme updated for the 2020. :)

Setup your development environment

The most important thing for kick-starting Your New Developer Job is to, before starting with your first task, make sure your development environment up and running. This might sound easier than it is in reality. Here is a quick list of things you want to do:

setup development environment in full, do not just make it work in any way possible
ensure your debugging works, and that you can debug different things you need (i.e. frontend debugging, API debugging, console command debugging).
your company probably have testing and staging environments, ask about them and setup access to them
ask about different databases your product uses and set up access to them
understand how to debug and where logs are

Once you do the steps above, you are well prepared to tackle with your first task.

You also already learned about the project because you had to think about lots of different things while setting a development environment.

The collaborative environment is important

I think it is worth mentioning that collaborative environment is very important. You should understand "rules of engagement" meaning what tools are used for communication, how is testing coordinated and communicated across the team and what procedures are involved.

As a practical example, many teams have dedicated testing servers. However these resources are usually limited and time sensitive and there is some way of coordinating who is using what and when. These are the things you want to understand.

If you don't ask and don't understand these things, that means that you don't need testing environment. Furthermore, that means that you are not testing your code, or at least not testing it in a way your teams finds appropriate.

You don't want to be the person who is not testing your changes properly. :)

Technical vs organizational rules

This is a huge topic which probably deserves its own article. However, we need to at least mention it here. Technical rules are rules defining how to code, check code quality, test, which tools to use, how to debug, deploy, monitor logs, etc. All these things are important.

However, you are not alone in the company. You are not alone in the team. It it wrong to act like you are single person band. In short, there are some organizational rules you want and need to understand. What are these rules? Well, that is the trick, it depends on organization you are working for.

One thing I can promise, these rules will be a bit, or a lot different to what you might assume or what you had in your previous company or in the school for that matter.

Best advice here is to keep an open mind and assume that every rule has a reason (I already mentioned this once or twice in this article). Do not try to change organizational rules. Understand them, work by them, notice strong and weak points. Once you get some "seniority" in the company, you can propose changes to whole team.

However, to be able to change something for better, first you need to live trough it. Or, in words of my colleague, you can not solve a problem. until you spend some time with that problem and understanding what difficulties and pains it is causing.

Consider using Most Important Task (MIT) approach

Most Important Task, or shorthand MIT, is a very simple but powerful approach, which suggests that you should, at the beginning of your day, focus on the task that is providing the biggest benefits.

This approach is based on the fact that first 1-2 hours at the beginning of your day you are at your "cognitive best". Cognitive best means that you have the best chance of solving problems.

Most of the people use this time to read through messages, respond to emails, cleanup stacked questions, and similar. This is not what you want to do.

You want to plan your day and understand what is the most important task for you. The task is providing you the most benefits and that will make the biggest impact on your team and company.

Once you know what this task is, you want to focus and work only on it. You can go a step further and dedicate time slots to read through Slack and Mail messages, instead of doing constant content switching.

Keep diff sizes small

There are two important things here.

First one, when making new features try doing it in phases, document, and explain each phase. This will help your reviewers to recognize problems early and when they point them out you will easily fix them. If you make long and undocumented diffs, everyone will have a hard time examining them and once they find the problem you will have to do everything all over again.

Be smart, plan your features, and bug fixes. It is ok to do something in phases, even if these are small commits. It is not about the size of the code change, but about the impact.

I was already writing about keeping diff sizes small in two other articles. One is about Clean Code Rules and how to improve the quality of your coding. The other article is about how code-reviewers review your code, what do they actually check. You can read up on these topics as well, it can be helpful for your own code.

Aim to be at the positive zero

There is a concept called "Being a positive zero", which means that you did not make any fascinating breakthroughs but you also did not break anything.

When you start working on a new project, the chances that you will break something are bigger than the chances you will make some major impact. Don't take unnecessary risks or try to prove with huge changes. Make a small but positive impact, without causing more harm than good.

Read the room, understand climate and rituals

Soft-skills for Kick-starting Your New Developer Job

Soft-skills are very important and often neglected. When you are part of a new team, you need to understand the climate and "the rituals". Have fun, talk, and hang out with everyone. If you are remote, at least do it online, or if possible visit your team from time to time.

You will not match with everyone of course, but you do need to give chance to anyone to talk about technologies, life, hobbies.

Finally, learn from your mistakes, because you will make them, others will as well. Don't be judgmental and try to keep an open mind.

Most importantly, do not try to compete with others, your competition is with yourself.

Try to improve on a weekly basis, and always be better than your previous self. Other team members and friends are not there to compete against you but to share experiences. Sometimes this experience sharing will look like criticism, but that is perfectly fine. Keep an open mind, be honest and friendly and you will do good.

I wish you all the best!

Bonus tip: I got very valuable feedback on this article from few friends which opinion I appreciate a lot. One comment was very interesting and I am adding it as a bonus tip.

Also, a good tip, try to solve every problem by yourself. If it is not possible to get it done, write down what you did, describe the problem, and then ask your mentor. This way he will already know what you tried and he doesn’t need to try it again for you.

If you don't have a mentor, supervisor, or peer, try finding or asking for one. It doesn't matter if you are a junior, senior, or any other skill level, it is always good to have some supervision and someone to talk to.