Knowing how to code well isn't enough anymore. The engineers who grow fastest are the ones who manage their own priorities, communicate in a way that lands with different audiences, and make sure the right people know about their work. None of that comes from a productivity app — it comes from habits you build over time. In this article I'm going to share 7 of those habits I picked up the hard way over the years as a senior iOS engineer. No Pomodoro timers, no morning routines — just the things that actually helped me ship better, get noticed, and not burn out. Let's see how you can start using them today. 1. Keep your internal backlog Jira and other tracking systems are great, but they are designed for your team first, not just for you personally. Everyone uses it to check your progress on sprint tasks, but it’s not granular and not tailored to your goals. You don’t need another sophisticated tracking system here. It can be just a notes app on your device or a simple task manager, to-do list or any other way of structuring your tasks. Here is a step by step example of how it can work: Take the sprint tasks from your favorite Jira, look at them and prioritize. What should be your primary task? Hint: usually it’s something business related, maybe a new feature your team expects to be done by the end of the sprint. What are the tasks that can be safely postponed for later and completed if you have some time left? It’s always a good idea to clarify and share your understanding with a manager or a product person. It can be done during sprint planning if you have them. Break down your tasks by days, allocate more time and efforts for your main ones and leave less space for those you deem not so important. Add team meetings and other activities to your list. For example, I find it a good practice to have a dedicated time slot for code reviews every day. This way you don’t need to rush your comments, and there are more chances to contribute better. I published a separate piece on getting the most out of your PR reviews here. Add some other todos to your list that are not included in your sprint. For example, “ask Tom about a change we did last week to see if there is something I need to do next time“ Corporate responsibilities should be in the list, as well. Example: “update my goals”, “respond to a company survey request”, etc. Finally, keep track of all these things at the beginning of the day. Take the sprint tasks from your favorite Jira, look at them and prioritize. What should be your primary task? Hint: usually it’s something business related, maybe a new feature your team expects to be done by the end of the sprint. What are the tasks that can be safely postponed for later and completed if you have some time left? It’s always a good idea to clarify and share your understanding with a manager or a product person. It can be done during sprint planning if you have them. Break down your tasks by days, allocate more time and efforts for your main ones and leave less space for those you deem not so important. Add team meetings and other activities to your list. For example, I find it a good practice to have a dedicated time slot for code reviews every day. This way you don’t need to rush your comments, and there are more chances to contribute better. I published a separate piece on getting the most out of your PR reviews here. here Add some other todos to your list that are not included in your sprint. For example, “ask Tom about a change we did last week to see if there is something I need to do next time“ Corporate responsibilities should be in the list, as well. Example: “update my goals”, “respond to a company survey request”, etc. Finally, keep track of all these things at the beginning of the day. This internal todo helps you to not forget about small things you might miss otherwise. 2. Be proactive at team meetings It might sound tempting to be present at your team’s meeting, but at the same time try to finish that annoying task or follow up with someone in Slack. But, believe me, it is not the best time to lose focus. Your team members, especially both engineering manager and product manager expect you to be vocal and present. Share your ideas and opinions, ask questions on why and when, take initiative. It is a hard work, and I know, there are days you want to sit through quietly with low energy levels. But these efforts usually pay off in the long term. 3. Communicate clearly Communication is crucial for software engineers. Try to find a balance in what exactly you’re saying to other people and how. For example, during a cross-functional team standup where you have a product manager, a designer, a QA engineer — meaning, people with different backgrounds and responsibilities, — it’s better to filter out in your speech the things they won’t understand. Let’s look at the difference: Yesterday I was applying a patch to our delivery endpoint, when the Cosmos database got corrupted entities inside. I had to roll it back and change the way we insert the hash values in its tables, adding better sorting algorithms. Yesterday I was applying a patch to our delivery endpoint, when the Cosmos database got corrupted entities inside. I had to roll it back and change the way we insert the hash values in its tables, adding better sorting algorithms. Yesterday I was having a hard time while working on a delivery task. There was a problem during a rollout which I immediately fixed. It was a beta environment, so we’re completely fine. In fact, I improved the way we work with it which we will see in our metrics next week. Yesterday I was having a hard time while working on a delivery task. There was a problem during a rollout which I immediately fixed. It was a beta environment, so we’re completely fine. In fact, I improved the way we work with it which we will see in our metrics next week. Notice how the second version leaves the tech terms out and focuses on the results that are perfectly clear to everyone? To practice this simpler type of communication try to ask yourself these questions: What do they really want to know? What I am really trying to say? What do they really want to know? What I am really trying to say? It is a virtue to explain a complicated tech stuff in simpler terms. But the better you do it, the better is understanding of it by other people. In the end you’re gonna have less miscommunication problems, less uncertainties and less concerns. At last, you can always dig deeper into the tech things if it’s needed or asked. It is the perfect place to do it on the tech syncs with other engineers. 4. Build a bridge with your manager This one does not depend entirely on you, of course, but in general, a good manager is someone who advocates you and your stakes in the eyes of the business. They are the ones who discuss promotions for teammates with upper management and make judgements on whether you are ready to take a bigger role and responsibilities. Hence, it’s in your interests to be in good relationships with your manager. How exactly can you plan on doing that? Well, try to put yourself into your manager’s shoes. What are their goals and what does the upper management expect from them? Plan a set of goals for you to achieve in the upcoming performance cycle and commit to them. Present them to the manager, discuss together and see them through. For example, take on a good refactoring project that will improve the product performance. By the way, a good sign of experienced engineer is to be able to delegate some tasks to others, be able to control the process and get the work done. 5. Focused work over constant multitasking Let’s talk about the actual coding routine. Let’s say, you have a task pending to be done from our first tip. How do you approach it? Everywhere around you there are “noise“ factors: meetings, constant Slack messages, etc. I find it to be more effective to shield yourself from external non-important things and let yourself to be in the context of your task preferably without unnecessary interruptions. Get rid of these non-mandatory meetings if possible and do not rush into answering on every Slack message right away. Of course, it doesn’t mean you should ignore DMs all the time, but it’s better to avoid disruptions of your “thinking cycle“. What do I mean by that? Here’s an example of how it can be done: You have an important bug to solve. There is a couple of theories you want to try. You’re working on the first one. You applied a fix and ready to test if it works. Then you receive a Slack message. By skimming through a notification (literally a second of your time) you know that it can wait. You finish testing the theory. It doesn’t pan out, so next you’re gonna try the second one. Then you take a break and answer on that message. After coming back to the bug you’re ready to work on the next theory. You have an important bug to solve. There is a couple of theories you want to try. You have an important bug to solve. There is a couple of theories you want to try. You’re working on the first one. You applied a fix and ready to test if it works. You’re working on the first one. You applied a fix and ready to test if it works. Then you receive a Slack message. By skimming through a notification (literally a second of your time) you know that it can wait. Then you receive a Slack message. By skimming through a notification (literally a second of your time) you know that it can wait. You finish testing the theory. It doesn’t pan out, so next you’re gonna try the second one. You finish testing the theory. It doesn’t pan out, so next you’re gonna try the second one. Then you take a break and answer on that message. Then you take a break and answer on that message. After coming back to the bug you’re ready to work on the next theory. After coming back to the bug you’re ready to work on the next theory. In my experience it’s much harder to come back to something that you left partially unfinished, just left in the middle of the change. The more time in between the breaks, the harder is to get back that context later, “load it into your RAM“ if you will. This approach doesn’t mean that it’s ok to ghost your colleagues. No, but in many cases no one expects you to write back instantly. There’s definitely some grace courtesy period, so try to not overreach it. Sometimes, if they ask me to check something, and it takes time whereas my task is more important at that moment, I would let them know that I will check that and come back in an hour or so: Hey, sure, I’m gonna check this and come back to you in an hour. Hope it’s ok with you. It’s just that I have this high-priority task I’ve been dealing with the whole day, and I need to finish it first. Hey, sure, I’m gonna check this and come back to you in an hour. Hope it’s ok with you. It’s just that I have this high-priority task I’ve been dealing with the whole day, and I need to finish it first. This way you’re giving an actual ETA to your colleague and don’t leave them hanging while being polite and friendly in your communication. 6. Showcase your work I’ve known very talented engineers with diverse technical backgrounds who were of tremendous help to me. It was a delight to learn from these knowledgeable people. But have they done great in their careers moving up the ladder? Maybe earning a promotion, more responsibilities and a bigger paycheck? Surprisingly, not all of them. One of the reasons it happened this way is because almost no one knew about their work except for the people in their small dev teams. Honestly, if you work at a decent company with no micromanaging, no one is watching your pull requests under a microscope 24/7. And that small change that may be saved a company a significant amount of money can easily go unnoticed if not told properly by you to the stakeholders involved. Quite often these people are managers, product owners or heads of departments… Meaning that they are not the tech people in the slightest. So, I advise you to not just show your golden PR, but present it in a way everyone in the company outside of your “tech bubble“ would understand the meaning of it and more importantly, the company value. Presentation, nice graphs, real numbers — all of that. Which leads us back to the 3rd point about soft skills and communication. There is a different side to this point that I hear sometimes in complains from fellow engineers. Like that person in your company who is good at self-marketing themselves and makes everything a much bigger thing than it actually was. They might have been praised more by leadership teams just because of their showcase skills. And just because of that it can be looked down upon. But hey, it will be beneficial to pick up a marketing trick or two from them, as well. Yes, “selling” your work is also important. If your presentation skills are lacking, think about the ways you could improve it. I would make it as one of personal goals with a clear set of action points. See whether your manager can be of help here. Winking at the 4th tip over there 😉 7. Value your time Last but not least, do not crunch extra hours. Do not overwork. Period. It depends on your company culture, but in some places management can be very manipulative in creating the “hurry hurry hurry“ type of atmosphere where NOT staying late in front of your screen is frowned upon. The bottom line is that I would avoid such companies in favor of a better work-life balance. In a nutshell, it means that the company does not value its employees and does not care about them. I used to work extra hours before in my early years as an engineer. One time, we were told to release a huge and complicated feature in some fixed amount of time. The deadline was not realistic in a first place. We all knew about it, but for some reason that I already don’t remember of, the team had to get along with it. We crunched through multiple weekends, working at nights. Can you guess what was the result? We couldn’t make it, naturally. In the end, no one actually did anything about it, but I needed a month of no-work weekends after it to get recovered. As our team leader nicely said to me: “This company would take as much of your time as you allow it to“. After that incident and many similar ones before, I put my own personal boundaries of where and when the work that I’m being paid for starts and stops. Remember, if you work 5/7 officially, you have a number of hours you are paid for. Even if you work as a freelancer, it’s basically the same thing. There is always a “money per hour” relation. If you do extra hours without extra pay, in most cases you do a disservice to yourself. Trust me, all this can easily lead to a burnout at some point that will be hard to come out of. In some rare occasions, it can be beneficial to do extra time, but only if there is a real profit out of it on the horizon. Extra pay, promotion, extra vacation days or some other form of retribution that is actually worth to do it for. But take it as a rule of thumb: make the most out of your working hours and work hard, but at the end of the day, when your clock is up, leave it to the next day. Value your time. Conclusion I hope that these tips were somewhat of help for you. Maybe some of them you already know about, but others did get you thinking on making improvements with. And that was the reason for writing down these thoughts — to share my experience and see if it can be useful to others. Till the next time, keep growing and be better versions of yourselves!
