Coffee break #48. 9 useful habits for a junior developer

Source: Free Code Camp Have you ever analyzed your habits? The good ones help you become who you want to be. Bad habits will gradually transform you into whoever you want to become. Having worked as a software developer for over 12 years, I've developed certain habits that I'm proud of, and some that I'd rather break. At first I didn’t realize their significance, but then it became clear to me which of these habits helped me grow and which hindered me. This prompted me to take inventory and write about something that might inspire you to do the same.

Voluntarily take on things you don't understand

At the beginning of your career, you don't know much. Therefore, you will probably feel like an impostor. After all, the company pays you a salary as a specialist, and you don’t even know half the names of the technologies and frameworks that your colleagues work with. And you only heard about the second half because you searched on Google in time. If you replace the words “at the beginning of a career” with “at the beginning of any new project,” you can get a pretty accurate picture of a career in software development. Every new project is the beginning of something new. We meet new people, understand new requirements, learn new frameworks. And so every time. This is why it is so important to constantly learn new things. If you only do what you're good at all the time, you won't be able to confidently take on a new project. The fear of the unknown will always appear before you. By making it a habit to take on tasks on your own that you know nothing about, you can gain new skills and knowledge. If you need to fix something in an assembly, and you have never encountered such work before, take on this task! You will gain the necessary experience and new skills. If there's a bug in your frontend JavaScript code and you've only worked with the Java backend so far, fix it! Doing things you're not sure about is a great way to grow professionally. But do not deceive the expectations of others. Don't pretend to be an ace in everything. Be honest that you haven't done this before but would like to learn.

Ask to work with someone in pairs

If you're stuck on something or don't know how to complete a task, ask someone more experienced to work with you. Pair programming is a great way to get things moving. Discuss the requirements with your colleague: this will make it easier for you to understand what the result should be. Then start discussing solution options. You can go even further and offer to work in pairs, so that you write code, and your colleague gives you hints, and vice versa. This will help you learn how to think about and solve problems. For a beginner, pair programming is very beneficial. A note about working from home. When we switched to a remote work format, I faced completely new problems for me. I began to doubt whether I should ask my colleagues to work in pairs with me. In the office, everything was simple: you can just go to the next table and discuss this issue. With remote work and communication via video conferencing, everything has become noticeably more complicated. If this is also a problem for you, talk about it with your colleagues. You just need to change your usual approaches a little and develop new habits.

Report what you do (and don't do)

I can’t remember how many times I enthusiastically took on a task, thinking I could do it in a day, only to finish it in a week. With experience, I have become less likely to find myself in such situations, but sometimes I am still too optimistic in my assessments. There are several reasons for this time estimate:

• management demands that a new feature be completed quickly because the deadline is close;
• I want to look good compared to my office colleagues;
• many things simply don't work as expected;
• and many many others…

In general, it is quite likely that your time estimate will also be overly optimistic. How to fix this? You can manage expectations as you go! Constantly talk about what you are doing and always communicate what it is that is holding you back. I don't mean that you need to issue a task status update every 15 minutes. Just make sure that the people concerned know where you are in the process. It is best to communicate this at the beginning and end of the working day. If your boss or team/project manager expects results from you, report to him daily: “I’m working on such and such. I came across such and such a problem. Here are the options for solving it." This way, everyone interested will know about your progress. No one will blame you if you suddenly encounter a problem - as long as you keep people in the loop. An additional benefit: by reporting the current status of a task, you can hear from others recommendations or solutions to the problem. Make it a habit to regularly update your stakeholders on the results of your work.

Start a blog

I'm probably not the first person you've heard this advice from, but I'll say it anyway: blog! It is not necessary for your blog to be public. This could be a couple of pages on your company's wiki or a collection of GitHub repositories with code examples and a few lines of explanatory text. Why is this necessary? Because when you write something to teach others (even if those “others” are your future self), it is a great way to learn and grow professionally. Write about how you were able to solve a difficult problem. Or about how a new framework works, the release of which you have been waiting for a long time. You can also keep a journal of what you did during the week. By the way, this will help you develop the habit of communicating what you are currently working on. I have started blogging several times. At first, of course, it is very difficult to maintain motivation and force yourself to write, realizing that hardly anyone reads your posts. It's quite strange to write into the void. For this reason, I abandoned my blogs. And three years ago I started my next blog . I wrote without any audience for six months. And then I discovered that I had no readers because my robots.txt file did not allow search engines to index the blog! Long story short, I changed the settings in robots.txt and people started reading my articles. There weren't many readers, but they still gave me an incentive not to stop. Gradually I improved my writing skills and now my blog has up to 200 thousand views per month. And all this is due to the fact that I once decided to start writing about new frameworks and problems that I managed to solve. And I did this in order to be able to return to my notes when I needed them, and not at all because I wanted to gather a large audience. Blogging may seem like a boring chore at first, but over time, if you don't stop, it will start to bring you satisfaction. If you start writing with a desire to learn and teach, you will not only learn a lot, but you will also become interesting to many people.

Get yourself a notebook

I've only recently become a big fan of notebooks. Not in the form of programs, but real, paper ones. Wherever I go, I take a notepad and pen with me. This way I have the opportunity to write down what comes to my mind at any time. I take notes when I'm listening to someone's talk, when I'm waiting for the bus, or when I'm thinking about what to make for dinner. I also use a notepad to create a list of books I want to read, frameworks I want to learn, features I want to add to my personal projects. And, more importantly, I take notes when reading books because it helps me better retain what I've learned. I write down everything that comes to mind. And if for some reason I fail to write something down, I feel anxious to the point that I can’t even sleep. The whole point is that I don't trust my memory. If you have a good memory and you perfectly remember everything you thought about a week ago, then you probably won’t need a notebook. But if you have trouble remembering, like I do, then taking notes in a notebook will significantly change your life for the better. To make sure your notebook is as useful as possible, you need a systematic approach. You have to reassure yourself that whatever you write down in your notebook won't get lost. Separate the first couple of sheets of your notebook into a table of contents so you can easily find the information you need later. Make it a habit to review your notes regularly. Take, for example, notes made while reading a book. When I finish reading a book, I look through my notes and write a review of it on my blog. Although almost no one reads this text, the very process of writing a review forces you to think about what you read and, as a result, remember it better.

Document your victories

Notebooks are also necessary when developing the habit of documenting your achievements. As I already said, my memory is bad. Sure, I can remember what I ate yesterday at lunch, but when I'm focused on a complex task, my memory power noticeably decreases. That's why I have a rule of writing down my achievements at the end of each day. We are not talking about any outstanding deeds, but simply about small victories. For example, fixing a bug, taking another step towards creating a new feature, etc. I also write down personal victories, such as completing my morning workout. In the evenings I simply make a list of what I have done during the day and write it all down in a notebook. You can make such entries in a tablet or use some special program, if that is more convenient for you. Over time, there are more achievements. You can even somehow mark the most important ones so that you can easily find them later. For example, before preparing for a performance review, you look through your list, find relevant achievements and list them in a separate list. This will make the review much better. A list of accomplishments is also useful for communicating what you've done.

Find time for important tasks

At the end of the day, I often feel like I haven't accomplished anything today. And while documenting your victories (or at least completed tasks) is important, the most important thing is to complete those tasks. It happens that one meeting gives way to another and suddenly the end of the working day comes. After a meeting with colleagues, you would like to continue working on your task, but just as you have time to warm up, a new video conference begins. And after that you need to “warm up” again, because you have already lost the context. This reduces your productivity. If I've learned anything about being productive, it's that it's important to reserve time for important tasks. If you don't make it a habit to set aside time for important tasks, there's a good chance you'll never get around to working on them. Your time will be eaten up by normal daily activities. Managing your time can be done in a variety of ways, and to be honest, I jump from one approach to the other every couple of months. But the point remains the same: for tasks that you absolutely need to complete, you need to reserve a chunk of time in your schedule. I set aside one hour in the morning, before work, to write articles for the blog (or other sites). I also set aside one hour in the evening (when the kids are already asleep) to work on a personal project. I currently have a Trello board with a column for each day of the week where I list the tasks I want to tackle in the morning and evening. Once a week I update this board and write there what I need to accomplish in the next week. This way I don’t have to waste precious time thinking about what to do next. In addition, I set aside two hours in my schedule every day for work that requires special concentration, so that my colleagues do not try to schedule any meetings during this time. All this helps me cope with the tasks planned for the day. In general, it is not so important how exactly you manage time. The main thing is to do it in principle and create a habit out of it. Otherwise, your days will be consumed by things that are not very important to you.

If you're stuck, take a break

Developers very often reach a dead end. And these situations are terribly annoying. In such cases, everyone often advises taking a break from work. But sometimes it is very difficult to follow such recommendations, because “the decision is already close, I cannot stop now.” And if I take a break right now, then after it I will again have to “intervene” into the essence of the matter. Why voluntarily waste time? But the fact is that when you are stuck in work, it prevents you from thinking straight. You think that it is very stupid to get stuck with such a problem. After all, your colleagues could probably handle it easily (another option is that they always get easier tasks). At the same time, you don’t think about how to actually solve the problem. Take a break and work on something else for a while. Or (even better) come back to this problem tomorrow. Taking some distance from the problem will allow you to see solutions that previously escaped your sight. Maybe this hasn’t happened to you yet, but I assure you: very often the right solution comes to mind by itself. If you don't have extra time, you can use the Pomodoro method - dividing the task into 30-minute segments with a short rest in between. After each step, I ask myself if I'm in solution mode or if I'm stuck and should do something else. The Pomodoro Method has the added benefit of using the end of each step as a trigger for other habits. For example, to form the habit of getting up from the table and stretching, drinking water. This is sometimes called a stack of habits, because you sort of stack one on top of another, and as a result you get a good effect.

No need to look for a magic wand

I once wrote a book about a certain style of software architecture and regularly receive emails with questions like “I really like this style and want to apply it to all my projects! How to do it?" And do you know what I answer? There is no one architectural style that is suitable for solving all problems. When you have a small project, you create a simple CRUD API. And if you have a complex model, you build a more complex hexagonal architecture. And when creating microservices in each individual context, you use one of hundreds of architectural styles. There is no universal framework that can be used for any project. Just like there is no single programming language or coding style. Don't try to find a magic wand. She doesn't exist. Having your own opinion is good when there are worthy arguments behind your opinion. “This is the best architectural style” and “I always do this” are not worthy arguments. Just imagine that there is a developer on your team who always has his own preferences and who always foams at the mouth to prove that he is right, “because it is best.” You will get tired of it very quickly. Don't be that type of developer.