Introduction
Hey, DEV people! 👋 It's time to share my experience on the topic of task analytics for programmers to execute them as efficiently as possible.
Originally, I was inspired by this article on Habr (in Russian) and thought that I could modify some points from it a bit with my experience.
And here you are reading what I got!
📝 Table of contents
- Analyzing the task and trying to identify the final needs
- Exploring a subject area
- Matching solution options
Analyzing the task and trying to identify the final needs
We read the task, think about it and try to understand what the programmer ultimately wants to get. It is not always possible to do this immediately, because other people think differently, while programmers often have a "professional deformation", which makes it more difficult to understand what "non-programmer" is thinking.
And here we have only two options:
- If the task refers to any part of the product being developed, then go there, "click" the buttons and see what happens, re-read the task, check it against what you see on the screen.
- If the task concerns some new direction or function, or does not concern the developed product at all, then we study the business process. Here the base is the business process.
☝️ Although the first option also has a business process, but it's not immediately visible.
As a result, the puzzle must come together in your head. I don't know about others (please, share your experience in comments below), but in my head immediately arise possible solutions.
Even without the period of understanding the task as such: if there are options for a solution, then the task is understood and the goal of this stage is achieved!
Exploring a subject area
This is more complicated and easier at the same time. At this stage, you don't have to think much, you have to research:
- First, the business process (in the context of the stage, the business process is the environment in which the task will work).
- Then, the software products.
- Next, the implementation of existing parts.
- And finally, the environment in which the code works and dependencies.
It's important to know the architecture of the application. Especially, if you haven't worked with it before. But anyway, you must see if the architecture has been modified, and if so, what kinds. Over time, the architecture of the application, its external dependencies will always be in your head.
☝️ This does not exclude the existence of documentation. It must be! There is simply no other option.
Only after all the parts of the subject area have been put together in your head can you move on to solution options.
Matching solution options
Hopefully, you have previously researched and understood everything that is required. OK, now you can start thinking for real.
Yes, choosing the right option is sometimes extremely difficult, because for the chosen variant it's necessary to be responsible.
🤔 Responsibility is the biggest fear of almost everyone.
Each option must meet several requirements:
- Solve the problem.
- Must be implementable in adequate time.
- Not "break" the architecture of the application.
- It should not introduce "trash" and unnecessary "crutches".
- Easy to use for the end users.
Have you chosen your options? Now, try to choose the one that is more useful. There are two frontier states here:
- It's done quickly, but it's a one-time solution;
- It takes longer, but it's universal;
Oh, but we need to choose something in between... To make it as efficient as possible, there are some little tips I've learned during more than 12 years of development in different teams.
Do not put into your code features that you do not need now
Immediately cut off the idea of features that you do not need now, but may need in the future. Usually, these features will "dead load" with ~70% probability.
Trying the chosen option on your picture of understanding
And if I tell you that the chosen option is wrong? You will, of course, answer that it cannot be, because you have already gone through a bunch of options and chosen the right one.
OK. So be it! But what happens if we start to implement it? What are the odds that nothing will break? Just these questions need to be answered at this stage.
For a better understanding, I will give you an example of the Ansible approach.
☝️ For those who are not familiar with Ansible, it's a tool to automate the processes of deploying off-the-shelf infrastructure on a remote server. Please, read the official docs for more information!
Ansible has a special mode of operation, called "dry run", where it "plays" the given playbook (file in YAML format), but does not make any changes. After making sure that the option does not "break" anything, Ansible runs the real change process on the target server.
Similarly, you need to "dry run" in your head the chosen implementation and see what it will affect. And if there is a chance to "break" something, we go back a step and look for new options.
Specifying details
Some additional data or examples may be needed before implementation.
If you have gathered everything you might need, you are ready. At this point, you have to understand that nothing is stopping you from writing code:
- Network works.
- Software licenses are alive.
- Your chair and table are comfortable.
- Coffee or tea poured into your favorite mug.
- ...and so on 😉
Implementing
At last, we're writing code! Don't get too excited, this has its own pitfalls. It's highly probable that you will find things you haven't considered while writing the code.
🤷♀️ Well, it happens! But let's not stand still and move on. It's important not to panic and not to consider it your fault.
Just answer the question: does the new data interfere with realization, or is it just a correction? If they only make clarifications, then you are lucky, and you can move on.
But if they interfere with the implementation, then we go back at least three steps. Yes, you read that correctly. In a critical scenario, it's better to go back and go all the way again with changed data.
OK. But what about task's deadline, if I've to turn back?
That's exactly what many people are afraid of and can't accept responsibility for the implementation option they've chosen. And there is one simple recipe that has more than once saved me and my development team from inevitable technical debt and bad decisions.
🎯 Let's take our time and do it right, not the way they make us do it.
Just talk to the person who gave you this task and try to explain the difficulties. Learn to assert your right to create truly great code!
☝️ I assure you that no project manager would want to explain to a client after the project is delivered that the resulting product (although it works now) has many unaccounted for moments that may be a problem for the project's development in the future.
Photos and videos by
- Thought Catalog https://unsplash.com/photos/Nv-vx3kUR2A
- Avi Richards https://unsplash.com/photos/Z3ownETsdNQ
P.S.
If you want more articles (like this) on this blog, then post a comment below and subscribe to me. Thanks! 😻
❗️ You can support me on Boosty, both on a permanent and on a one-time basis. All proceeds from this way will go to support my OSS projects and will energize me to create new products and articles for the community.
And of course, you can help me make developers' lives even better! Just connect to one of my projects as a contributor. It's easy!
My main projects that need your help (and stars) 👇
- 🔥 gowebly: A next-generation CLI tool that makes it easy to create amazing web applications with Go on the backend, using htmx, hyperscript or Alpine.js and the most popular CSS frameworks on the frontend.
- ✨ create-go-app: Create a new production-ready project with Go backend, frontend and deploy automation by running one CLI command.
Top comments (0)