Software development is very challenging. Firstly you have to understand the problems you are solving. Then you need to think of the solution. Depending on the solution, you have to research proper technology. During the process, you need to have a clear perception of the system you are working on and to think longterm. If not any future changes will be hard to pull off.
It’s not enough to be a great engineer to develop and maintain the software. The effort you invest in the process has to be excellent too. I’ve made tons of mistakes only because I’ve lost the focus. So I’ve been looking at different techniques to get faster into the state and to preserve it.
Why do we need to focus?
I believe this is quite obvious, nevertheless, let’s point out a few facts. When you focus, it means you direct attention to only one duty. You make decisions quicker, and you absorb and process information faster. Focus is the first step to get into the flow state. Flow is an optimal state of consciousness, a peak state where we both feel our best and perform our best. It’s hard to get to the state, and if we disrupt it, we need much time to get back, if we get back. That’s why we need to focus intensely on our work so we could perform better.
Have clear goals
Focus here is on the clear, not on the goals.
I’ve seen many developers who think that sprint planning and defining tasks are in some sense, a waste of time. You have to go into the details of every single one; there are discussions about the parts of the software you won’t develop; it’s better to spend time on development because we can make small decisions along the way; assignments seem clear already.
All these reasons are wrong, or the person who is defining the tasks is not doing his/her job adequately. First, you have to have a broader picture of the software, and you never know which feature is waiting for you to maintain. Second, the goal of planning is to save time. If you don’t make all the small decisions, you will have to pause your work either to think of a solution or to ask someone to clarify the problem. Either way, you are losing the focus, and not just that, you are disturbing someone else’s.
If you work in an environment where you don’t have proper product specifications, try to write them out yourself. If the feature you are working on is complicated, split it into chunks. Now you can focus on work not on developing a product. Majority of us are bad multitaskers. We should do only one thing at the time.
Don’t let anything disturb you.
How many times did this situation happen to you?
During the workday, you should have time only for yourself. So there are no questions from other colleagues, no social networking, no fantasy football, or any other distractions.
In that part of the day, my phone is on the silent mode, desktop apps for chatting like Viber or Whatsapp are off. If you are the team lead, I encourage you to make this a team policy so everyone would know not to disturb others and to focus on the job. After this period is over, that’s the time for questions and discussion.
This policy is hard to implement in open space because there are many people and many teams. My former colleague had a great solution. He had some USB lamp, and if it were on, everyone would know not to bother him.
Some people will think this is a selfish approach. I don’t agree. I believe it’s selfish to ask for something that you need a few minutes of analysis or not to wait for a few hours to get an answer. If someone’s dedicated full attention to solving a problem, we should respect that. It maybe feels like he needs only a second to give us the solution, but as I already said, it’s very hard to get into the flow but very easy to get out of it.
Organize code well
Imagine you are writing a new service or control for your app. Everything goes as planned, and the new component is working great. Next step is to integrate it. You open some older class, look at the code, and can’t understand a thing. You don’t want to work anymore. I had a fair share of those situations.
Working with old or other people’s code can be very frustrating. You can avoid the problem using coding standards. When code is clean, organized, easy to read, understand, and navigate, or as we call it beautiful, you won’t lose much time searching for the parts you need. Also, understanding the code is more comfortable. Therefore it’s easier to maintain the focus.
Organized code has other advantages too. I have already written about it. Check it out.
Organize your tasks
During the sprint, you probably get several tasks. Firstly you have to prioritize what’s essential and make sure you can deliver it on time. Afterward, you have the flexibility to arrange others as you prefer. Some tasks are challenging, some relaxing and some just boring. Don’t do all the enjoyable stuff and leave the dull for the end. No matter how exciting the job is, the quality of the code has to be identical.
Focus, and particularly the flow state, are very expensive. They take much energy from us, and we need to regenerate. So if you have more than one fun task in the sprint, after you finish first, next one should be dull one or relaxing one. You don’t want to overload your brain and burn out.
If you leave all boring ones for the end of the sprint, you won’t have enough energy, desire to complete all of them. I like to leave the relaxing ones for the end of the week, so I don’t get exhausted before the weekend.
To get a maximum of yourself, you have to understand all responsibilities and to know your ability. If you are too ambitious, you’ll burn out. If you are too relaxed, you’ll stagnate. So, be cautious with the organization of your tasks.
There are occasions when there are no fun tasks in a plain sight. Everything we get is either dull or well above our skill level. Even if we use all pieces of information above, it’s hard to focus and be as productive as you can be. Sometimes coding is a stressful process, and effort we need to invest is enormous. Unfortunately, there is no practical advice that can help us. We have to struggle well.
Stop perceiving struggle as something negative. The struggle is a test of character and creativity. In those moments, to keep myself motivated, I repeat that there is no avoiding pain, especially if you’re going after ambitious goals. Eventually, you’ll have a breakthrough, and those responsibilities won’t look so difficult anymore.
The last point I want to add is about perception. A few days ago, there was a discussion about the article I wrote on Twitter, and some guy said that creating a modular app is hard. My response was that it’s not hard; it’s challenging. Having that positive mindset help you to overcome many obstacles and get into a productive state.
To focus and to get into a flow state can be very difficult. However, we should do our best to get int those state. Then we learn faster, make better decisions, and solve problems quicker. Software development is quite challenging, and competition is enormous. We should use any tool or method to be as productive as we can so we can stay relevant in the industry.
Want to find out more?
Or you want to discuss swift and technology? Follow me on Twitter. You’ll find additional content, reading recommendations, and much more.