Getting a job is the first step of your software development journey. The second step is becoming a great employee and growing.

It's not as easy as it sounds. I've seen many junior developers who got discouraged after a few months of work. They felt like unwanted underachievers and eventually quit.

So how do you achieve success in your first job? 

You have to adapt to the workflow of your team seamlessly. Teams and companies are different, but some rules and behaviors are universal. Let's explore some of them.

Learn to manage your time

Programming is all about tradeoffs. Early in your career, you'll discover you must balance different priorities — simplicity and performance, execution speed and ease of use, readability, and conciseness, etc.

But probably the most critical thing to balance is your time. Time management is one of the crucial skills in any field. Good time management is about estimating how long the things will take you and setting your priorities straight. You also have to plan and foresee problems before they occur.

The critical part of time management is understanding the requirements. You can't plan anything if you don't know precisely what you have to do. And there's nothing worse than spending lots of time doing something unnecessary just because of a misunderstanding. So take your time to understand what exactly is your task and when is your deadline. 

The second factor to consider is how much your work depends on other people. Are the designs ready, so you know what the user interface should look like? Is the backend prepared with all of the endpoints returning necessary data? Do you have access to all of the assets and copy? You want to know about all of the significant problems first. And the things (and people) you cannot control create the most critical issues. 

When you're confident, you've got everything, it’s time to get your hands dirty. Try working on the simplest possible solution, don't worry about elegance or edge cases. This step is crucial cause it will give you a general idea about the task's complexity. You'll know if the job is achievable for you within a set deadline. If you believe you can't do it, let your boss know quickly. Don't be afraid; most managers can handle respectful and sensible reservations. What they can't handle is a lack of reliable information on time.

In your work, you'll often bum into a problem you can't easily solve. You'll spend a few hours struggling, and eventually, you'll need to decide — should I work on this more or ask someone for help?

It's a moment to find a balance between the progress of the project and your growth as a developer. You will learn much faster if you get through difficult problems independently. But you have to be wary of slowing down the project too much. Usually, if you're struggling with a problem for a few hours, you'll not solve it in one sitting. So if possible, leave the task and return to it the next day, when you're fresh and rested. If you still can't solve it for a few hours, ask for help.

This way, you can get the learning benefits of struggling with the challenge but not slow down the project too much. Of course, if your team is working on tight deadlines, the project is the priority, and you'll need to ask for help earlier. But as a general rule, remember that projects come and go, but your knowledge stays with you forever.

Photo by Todd Quackenbush on Unsplash

Learn the tools

Joining a new team is overwhelming. You must get to know your new coworkers, understand how things are done here and dive deep into the codebase. 

There are many things starting from documentation, time tracking, handoffs, and standups. You'll apprehend most of these during your onboarding, but the most challenging part is usually on you — you have to understand the codebase.

You may not know it yet, but juniors rarely have the opportunity to work on a new project. Usually, they are assigned to the team working on some older and bigger product. If the company is reasonable, you'll get some easy bug fixes for a start — it will allow you to get some familiarity with the code. 

But even in the best companies, you'll have to do many things on your own. And it will be hard. Reading code written by multiple people over the years is much harder than writing the code yourself. And it's something nobody teaches you — no university, bootcamp, or course.

I've got a few tricks to help you understand the codebase effectively. Firstly, take your time. Don't expect to fathom everything in a few days or weeks. To deeply know the code, you have to understand the data, how it flows and transforms. But you also need some domain knowledge: familiarity is not something you build in a few days.

Secondly, focus on the architecture. Don't look closely at the contents of the files. Instead, focus on the structure. What kinds of files are in which folders? Are there separate files for styles, state management, and data fetching? With some frontend frameworks, like Angular, the architecture is more predictable as there are established ways of doing things. In others, like React, you must dig deeper. Understanding architecture will give you lots of information about the codebase and where to look for different things.

Reading tests is one of the best ways to get to know the project. They're much more straightforward than the code and have descriptions that make it easy to understand what's the expected behavior. Tests are one of the first places I go when I want to know how some project or library works. And if there are no tests in the project, you can volunteer to do some. It will give you an excuse to talk with more senior developers about the code. And more tests are always welcome, so people will let you do them.

Another trick to getting to know the codebase is to pick one of the main flows and try to follow it from start to end. Add logs or breakpoints in multiple places and see what happens. Where the data is fetched, how it flows through the app, and how it is transformed. When you're already there, try to break some things. See what happens when things don't go as planned. Often errors give you more insight than the happy path.

And the final tip — ask questions. People in your team are there to help you!

Communicate well

Soft skills are often undervalued in the software development community. It's a huge mistake. Often communication with the machine is the easy part of your work. Communication with your colleagues, managers, and clients proves to be much more difficult.

Professional programming is a team sport. Many people are involved. You spend more and more time talking or writing to others. You must convince them of your ideas, provide and receive feedback, and negotiate.

If you're a good communicator, your work becomes much more effective. And an additional benefit is it makes people like working with you. On the other hand, if you don't know how to communicate, you'll miss many opportunities — for a promotion, creating new relationships, or implementing your ideas.

How can you improve your communication?

Effective communication starts with listening. Try listening to others to understand them, not respond or prove them wrong. Assume the other side has good intentions. Your goal is not being correct; your goal is to achieve an outcome satisfying both sides. So leave your ego out and be slow to pass judgment.

Photo by Afif Kusuma on Unsplash

Understand what your company is about

I think programming is beautiful. And many developers share my sentiment. But most companies don't care about beauty or elegance — they exist for profit.

In real life, code is not the most important thing. You can write the cleanest, most maintainable code, and nobody will care. Because your job is not to write code, it's to solve problems and create products. 

It's all about providing value.

To provide value to your company or clients, you must understand their needs. It's their business goals that define what's essential. So you have to switch from code-oriented thinking to solution-oriented thinking. 

Take your time to understand what products are essential to your company. Check what technologies are used for these products and try to learn them. Prove to your managers you're able and willing to stretch yourself and help in critical projects.

Another great idea is learning skills lacking in your company. Maybe your company rejects many projects because they don't have experts in some framework, data visualization, or anything else. Ask your boss what they feel would be helpful. This way, you can show initiative and get guidance on which skills will be rewarded.

Developers who understand business are valuable on every level. It should be you who makes the difference.

Test your code

Your code has to work before a pull request or push to production. Always. Testing code is your responsibility. Not the reviewer or the QA team. The reviewer should focus on code quality, not basic checks if the code does what it should do. And QA is for edge cases, not the most obvious mistakes.

That's the case because your team's goal is to ship quality software as fast as possible. And for this to work, everyone in the team must focus on doing a good job.

Programming is tricky; if you don't test your code, it's almost certain you have made some mistakes. The reviewer will probably find these mistakes. So they'll create a ticket, and you'll have to fix some things. Unfortunately, it’s not the end of the story. After your fixes reviewer has to accept changes and move the feature to the QA. And as the reviewer usually doesn't check the functionality in-depth, so the QA will report some bugs. This is when the process starts again — you have to fix everything, the reviewer has to accept it, and QA checks it.

This bug loop often gets long and involves many people who are getting more and more frustrated. You can spare everyone the pain if you test your code carefully. And you should always do it.

Remember to test even minor changes. So often, I changed only one variable and assumed everything was good. It wasn't. Usually because of a typo made in a hurry. Programming is complex, and there are always chances you missed something—test for all different scenarios you can imagine. Look for edge cases. You know what your code should do and what it does, so you're the perfect person to test it.

Liked the article? Share it!