Показаны сообщения с ярлыком development. Показать все сообщения
Показаны сообщения с ярлыком development. Показать все сообщения

воскресенье, 13 декабря 2015 г.

Focus

There was obviously little activity in this blog during the recent months and I feel great returning here. The blog always gave me an opportunity to step back and think over my actions and choices. However, this year I was so focused on a single thing - my day job - that only one post had made it here. Now I want to check with myself what this attitude gave me and what it stole from me.

Last February my priorities changed dramatically. In about two months after becoming a team-lead I discovered that whatever I was doing was not enough to do good with new duties. I was both overwhelmed with the tasks and problems that fell on our team and saw clearly that we don't perform as good as we could do. Part of my natural response to this discovery was to ramp up the amount of time that I dedicated to the job.

There are lots of reasons why I'm happy with this choice. Firstly, putting more effort into work made me learn a lot and build up new skills in the areas of my responsibility. Because it was my duty to process all the requests that arrived at our queue, I learnt to do this efficiently and obtained a lot of domain knowledge. In other words, it turned out that it's enough to push me into a partially familiar field and show no way out to make me learn it deeply. My expertise grew enormously over the last year and being really focused on the job helped here a lot (yes, there are lots of things in my field that I still don't know or understand not good enough - I'm speaking only of the delta). Moreover, spending a lot of time studying and resolving various issues - some being totally unclear at first - I not only learnt new areas of the domain, but also developed a skill of learning faster.

At the same time, through spending extra hours on duty I came to see clear that sometimes one cannot address problems by simply working harder. When you do a lot and it doesn't help, you start to see deficiencies and acknowledge the need for changes in one aspect of the job or another. A different edge of this same idea is that one cannot do everything on his own. No matter how hard you try, there is always less done than left to do. These discoveries, combined with high exposure to the issues that we face, constant analysis of our work and search for means to improve it - all of these being enabled by having extra time - certainly brought positive results and helped me develop myself both as a developer and as a manager.

On the other side, the same willingness to work more than 5x9 had a negative impact on the manager role of me, because having more time I could in many cases take the responsibility for any new urgent issue or task. While this attitude helped me tackle problems in time and develop my own skills, it hampered the team's collective progress. Any problem brings new knowledge and shows ways for development, so I simply stole a lot of opportunities from my fellow team-members and hampered knowledge distribution.

Generally speaking, while my attitude helped me grow in terms of knowledge, skills and career, it also shadowed both opportunities and problems. It is a very important lesson for me: whenever one decides to tackle a surge in the amount of tasks by throwing in more (his own) manforce, he misses an opportunity to find more intelligent ways to solve problems and to use them as the points of growth .

These are the effects of the extra work on my job, but there are also those that go beyond my office life. First of all, I left the attempts to do programming and software development in the outside - this means all side jobs and projects. While these used to bring new opportunities and ability to study unfamiliar areas, that's not something that I regret much. Being focused on one area allowed me to grow more than attempts to handle both the main job and one or two similarly looking activities would permit.

What I do regret is that leaving less time for myself I started to pay less attention to continued study and learning new things - both around software development and outside this field. I totally stopped exploration of new programming languages and tools and did much less learning in other areas than I used to - namely, I didn't complete a single online course over the recent months. That's certainly something that I shouldn't have forsaken:  these activities could both help me do my job better and make me expand my knowledge and interests.

Another thing that I dislike is that I quit writing for the blog. Here the reason is not only that the blog has become a silent and lonely place - it was never crowded here. The real problem is that writing less I lost the habit to deeply think over whatever I do and to search for interesting problems and irregularities in my activities. Of course, I do reflect on my decisions and actions, but without regular writing I hardly do it in a systematic and efficient way. Moreover, without posting to the blog I avoid sharing my ideas, which is not a big loss for society, but a shameful cowardice of me.

As with any choice, there do exist both positive and negative sides to putting most of your effort into one area of your life. I see these and despite the cons I am going to continue along the road that I started almost a year ago. However, even though I will continue to pursue that sweet feeling of exhaustion, I do need to make certain adjustments to address some of the problems. In particular I will certainly pay more attention to the supporting activities like learning and blogging - these allow to widen perspective and spot issues that stay invisible when you are constantly inside the problem-solving loop. At the same time, staying focused on my job I will have to pay more attention to the things that I am busy with. After all, being totally occupied with the day-to-day activities is a direct way to keep doing wrong things. So I only need more thinking, more analysis, more writing and the same amount of job. Good to know the solution to one's problems, huh?

пятница, 10 октября 2014 г.

User's Expectations and Business Process

During a recent discussion with my friends I have faced an interesting contrast between what looked like the right thing to do in a mobile application and what a more traditional UX common sense suggests. While the way I thought the application should work seemed pretty reasonable from the business point of view, my friends were reluctant to accept it. The strength of their resistance to my approach descended me into doubtfulness and made me search for flaws and the ways to align the app’s behavior to the expectations of potential users without losing the emphasis on the business process.

My task was very simple and can be described in general terms without diving into details. The application deals with jobs, which user is supposed to create. In addition to that, he needs to do some work with the existing jobs – particularly assign workers to them. In terms of UI, this boils down to several application pages, only two of which are of interest now. The first one provides the inputs to set various attributes of a new job. The second view comes with a list of jobs, which were just created but haven’t been assigned a worker yet – user picks one there and selects workers for it. Once this is done, the job leaves the list and moves further along the pipeline. The problem sits right between these two pages: views on how the transition between them should happen when user fills all the properties of a new job and presses Create  might differ a lot.

One approach, which you will find in many widespread feed-based applications and which looks quite natural, suggests that once the job is created it should appear on the top of the list and be the first thing to draw user’s attention there. That happens, for example, when you post something to Twitter or Instagram – when you tap Post in the corresponding application, you are transferred back to the feed and see your new photo or message added on top of it. This is the approach that my friends were proposing. It actually has lots of benefits: user sees the item they have just added and can not only check that everything is correct, but also take some action. For example, right after publishing this entry I will want to look through it to locate things like typos or extra blank lines between paragraphs, and it is great that the blogging engine shows me the latest post first. However, for my application it didn’t feel suitable.

What I have chosen to do instead was to keep the list sorted by creation time in ascending order – the older the job the higher it appears in the list. Moreover, the app doesn’t scroll the list down to the newest item when the user adds it. For my friends this made an impression that when the list is already long new jobs just vanish unnoticed somewhere under the tower of older ones. While that certainly looks like that, there are some reasons to lean towards this approach. In my opinion, these fully justify the initial confusion that can arise from the fact that the feed does not work the way Twitter does.

Firstly and most importantly, the application’s purpose is to assist an employee in their interaction with a queue of customers and the pool of workers. In such a situation, when service time is critical, the older jobs are likely the hotter ones, meaning that if you have a job, which lies unassigned for 30 minutes already, you definitely want to process it before the one created a moment ago. Furthermore, since customers are served in FIFO order, in a situation when the list of unassigned jobs is already long and all workers are busy, arrival of a new customer should not interrupt the ongoing process. Under these circumstances, the manager handling the queue – our user – only has to put the new customer on the queue and forget about them. It is not necessary and possibly even harmful to draw too much attention to this new customer – instead of messing with a client, who has to wait for their turn, we should first process the jobs, which entered the queue earlier. (Of course, I don’t mean that the manager should literally forget about new customers, but he must be focused on the ones who have already spent some time in the queue.)

These considerations make me confident about the second approach, which pays close attention to the process that the application is supposed to help with – maybe in favor of complying with user’s initial expectations. At the same time, the discussion that we had made me thoroughly consider the problem. The least important and most obvious thought that I had in relation to it is that our views on how something should work and look might be affected too much by the things, which we interact with on the daily basis, despite the fact that the difference between the two can be vast. Here I don’t mean that my friends are totally addicted to Twitter. Instead, when they voiced their concerns over my design I have found myself in doubt and seriously contemplating adoption of the more popular approach. It looks like we are too used to feeds of tweets, photos, links and news growing from the ground up and sometimes oversee the fact that not everything should work this way.

More important takeaway is that doing the right thing is not always the same as taking a popular and well-established approach to UI. This flows naturally from the previous paragraph and merely suggests that before jumping on the bandwagon of any time-honored and user-approved UX pattern we must carefully study the goals of our products and how they can help users achieve their own objectives. This means that behind any application there is a process, which we try to enhance, improve and optimize and it is vital to take every detail of it into account when designing the application.

Last but not least, what we face here is the contradiction between user’s expectations and the goals of the software. When facing something like this, we should not forget that keeping users comfortable and amused is not the only purpose of a mobile (or any other) application. It should be easy to work with a product and the latter must not stay in the way of doing one’s job, but a business app occasionally has to make the user uncomfortable and draw their attention to something that they might be unhappy about. In the end, kittens, food and beautiful landscapes are for Instagram, while business apps are all about doing business.