How to solve any programming problem

Hello everybody!
 
 
Today, your attention is invited to translate in its own irreplaceable article, which will help you correctly approach even the most insidious and non-trivial TK, which you at first glance do not understand the point of view. The main thing is not to surrender and to formulate questions correctly. Mr. Justin Fuller of the Bank of America kindly explains how this is done correctly.
 
 
How to solve any programming problem  
 
Enjoy reading!
 
 
 
So, this day has come. Maybe this is your first working day, and maybe you have been working at this place for ten years already - it does not matter. With each this happens: you finally got a task that you just do not understand.
 
 
What to do? Just start and hope that everything will work by itself? Or to admit to the chief that you can not do this because you do not understand?
 
 
I think you guessed that the correct answer is neither!
 
 
I noticed that in programming, as in any other profession, it is almost impossible to live a working week (and sometimes a working day) without facing a completely incomprehensible task.
 
 
But do not worry! There is great news. Not only are you able to solve this problem - in addition, it can also do you good.
 
 
After all, you will have to expand your knowledge and skills in comparison with everything you did and knew before.
 
 
Next, I'll tell you how to bridge the gap between the requirements that you have set, and the knowledge you need to perform the task.
 
 
On the "requirements"
 
 
As you have already noticed, I use the word "requirements". Depending on where you work, this word may have some connotations.
 
 
In my experience, in large companies the requirements are loved, and in small cases they sometimes "do not make demands". I think that's what we should talk about here.
 
 
The matter is that, eventually, all programmers do the same thing: they solve problems.
 
You can get an exhaustive one-page TZ on how to solve this problem (I once visited an hour-long meeting about the text on the button). And maybe so: the CEO walks past your desk and as if inadvertently asks - "and by Friday you will cope with this task?"
 
In both cases, the task is set before you, and you must be sure that you fully understand it; only so you can properly approach it!
 
 
On the stages
 
 
 
 
Not all of the steps listed below will be required for any task. Only the most complex tasks may require careful execution of all the steps that will be considered in this article.
 
 
Perhaps, many questions can not be answered, based only on the voiced requirements, or because of the lack of your personal experience.
 
 
Perhaps you need to consult with other developers, with timlid, with the owner of the product, a business analyst or even with a grandmother! And maybe with each of them, before the task can be solved!
 
 
However, this is normal. This means that you will gather disparate knowledge and assemble them into a single whole - and so you can achieve the best possible result!
 
 
Finally, the last warning: do not overdo it with formalization! The most important thing here is to quickly understand the task. Do not need any artificial barriers and red ribbons! We need only a systematic plan to solve a problem that you do not understand at the moment.
 
 
Stage one: analyze the problem
 
 
At this stage, we are trying to understand what you were asked to do. While we are not trying to decide how we will do it!
 
 
It is important to catch this difference. It can be dangerous from one place to another to go to realization without thinking through all the consequences or, worse, not completely figuring out what exactly you were asked to do.
 
 
We classify the problem
 
 
Classify the task - means to determine what kind of work will have to be done to solve it. Here are some examples of task types:
 
 
 
Correction of the bug
 
The new feature
 
New application
 
Research assignment
 
Performance optimization
 
 
 
Remember that this list of options is not exhausted.
 
 
In this case, we need to decide which type of work is expected of you. This is important, because it directly affects what kind of work you will do.
 
 
This stage is especially important for fuzzy requirements, for example: "We need a way to somehow clean up our client caches after updating the site".
 
 
Here are a few possible interpretations of this requirement.
 
 
 
You must quickly implement a mechanism for clearing the cache, so that customers always receive the most current updates.
 
It is necessary to study all ways of storing these client caches and determine the best option (s) for getting rid of these caches after each site update.
 
Client caches should already have been cleaned, and you are required to find and fix a bug that hinders this.
 
 
 
At this stage, if you are not absolutely sure what the interpretation meant - you need to seek clarification, and only then continue to work.
 
 
Formulate the essence of the problem in the form of one or two simple statements.
 
 
Summarize a complex demand, as if answering the question "what are you working on today?" Maybe it will not be so simple, but you should try and reduce the essence of the problem to one or two sentences.
 
 
If it is not possible to summarize the task in this way, it can mean that it should be divided into several sub-tasks. In principle, this step turns into a litmus test, signaling whether you managed to organize your tasks in the form of small enough fragments.
 
 
Here's a good example of this summary: "Updating the site, we attach a unique number to the files, so the browser understands that it should use the latest version of the code."
 
This task has passed the "litmus test" for simplicity and, perhaps, it is not required to break it into smaller fragments.
 
 
But a bad example: "Updating the site, we attach a unique number to the files, so the browser understands that it must use the latest version of the code. Also we need to send a message to our CDN network, notifying it in this way about the need to update the files. Still, it will be necessary to provide that the applications under iOS and Android send an update to the application market. More "
 
 
In this case, the test is clearly failed. It takes a lot of work, and, perhaps, each task needs to be identified and monitored separately.
 
 
Highlight the most important details
 
 
Now you should (in free form, the most convenient for you) make a list of the main things that need to be done.
 
 
This, again, should be very simple squeeze of each of the main stages.
 
 
It's not about step-by-step or detailed guides to fix the problem.
 
 
Remember that while you continue to analyze the task before you. At this stage, I recommend writing notes. Personally, I use Notes for this application.
 
 
Our task with caching is very simple and, quite possibly, it is not required to depict it in this way. Let's consider a more complex example in this case.
 
 
Our next task is to realize a new opportunity: "Each user should receive targeted advertising of our internal product. This advertising should be adapted to the needs of the user, based on the data we collected. "
 
 
In order to isolate the main elements of this task, we must clearly present what needs to be done to implement each element.
 
 
 
We have the advertisements we need to distribute in such a way that they correlate with some specific user parameter.
 
For our marketing department, we need to provide a method that would allow us to correlate new advertisements with one or more pieces of user data (while marketers should not program anything!)
 
The system will have to aggregate such user parameters that are relevant in the context of our advertising.
 
Finally, you need to create a system that will receive a user ID and display ads.
 
 
 
The beauty of such lists is that they can be quickly coordinated with the team or boss! So, in this example, you could show this list to your timelid, and he decided that there was one more, very important point missing in the list:
 
 
 
Users should be able to tell us that they no longer want to see certain advertisements.
 
 
 
After all, in the end, the least we want to annoy our favorite users! Having given time and pondering over the task of just a couple of extra minutes, we will save ourselves from hours and days of trouble in the future. So, it is important how to formulate and plan an important task, and only then proceed to the code.
 
 
Before moving on, I would like to answer your possible criticism.
 
 
Perhaps, you think: "In a normally-run business, this kind of work must be done before the requirements fall on the table to the developer" - and I will definitely agree with you!
 
 
However, no matter how sorry, our world is not ideal. Sometimes the requirements that fall to the developer are by no means laid out on the shelves. Therefore, we must make every effort to properly assess the requirements before proceeding with the development.
 
 
Identify the problem (s) that you are trying to solve.
 
 
Answer the question: "Why would anyone have to use this?" Or "what is the real or perceived problem that I'm trying to correct in this case?"
 
 
I hope the answer is obvious. In our first example given here, the answer is: "Users will always see the latest updates." In the second case, with advertising, "users will always see relevant notices, not those that do not interest them."
 
 
Proc of both of these answers should be obvious! Deeper understanding of the task and its goals, you will be able to make more reasonable decisions and make such an implementation that will properly meet your business goals. If it is possible to identify bad decisions and meaningless tasks, then it will be possible not to waste time and effort in searches, which by definition will not help to solve the problem.
 
 
Stage two: we interpret and evaluate the requirements of
 
 
At this stage, you must already represent what you have to do and why.
 
Next, you need to understand the details of what you are going to do, how you are going to do it and why you will do it this way.
 
Clarify important terms relevant to your task.
 
 
Probably, this step is more important for the beginning developer in the team, or if you work in a large company. In both situations, it is very likely that you will find unfamiliar terms in the requirements.
 
 
These may be concepts from the field of business, for example, the names of products, customers or processes. There may be terms related to development - for example, the names of tools, applications, models, services or libraries.
 
 
You need to make sure that you understand all the important terms absolutely clearly, so that you can be sure that you are implementing the task correctly.
 
 
Perhaps you already understand that you need to invent a way to access aggregated user information, but do you understand what it means to "add it to dao"?
 
Probably, you understand that you need to format advertising data, but do you represent what "MADF" is (a markup of an advertising news tape)?
 
 
I do not understand either.
 
 
That is why it is necessary to isolate and define all important terms. To get confused in the definitions is the correct way to solve the problem incorrectly.
 
 
Decide how the task should be done.
 
 
At this stage, you already have to figure out how the task will be executed. The details of this process can vary greatly depending on where you work, and what specific task is set before you.
 
 
In some teams, no one will explain to you how to implement the requirements, they will simply say which functional should be output.
 
 
In others, each step will be detailed.
 
 
Most likely, you will find yourself in some intermediate situation.
 
 
If the team did not provide you with instructions, at this stage you will not be able to do much. If you received instructions - then start to get acquainted with the stages that you have to go through.
 
 
This step seems quite natural, but it is important to pay attention to the order in which we proceed to it.
 
 
Naturally, we want to plunge into all the details of the problem right away and study them until the goal is completely understood.
 
 
However, since you have already spent time to understand the problem, you must now clearly visualize the whole task, assessing the steps that need to be taken to achieve it.
 
 
Determine whether the assigned tasks
 
 
At this stage, the stages of analysis and interpretation are merged. At the analysis stage, you focus on a holistic picture and large-scale goals - what we do and why.
 
 
At the interpretation stage, focus on the details - how we do it.
 
 
The second stage is called "interpretation and evaluation", because now you can correlate "how" and "what and why". You interpret the details based on the overall picture. You evaluate the details and determine whether the original problem was resolved.
 
 
Ask yourself: will the steps that I was instructed to do lead to a result that was designated as the ultimate goal of the task? In fact, does the planned result solve the original problem?
 
 
If you are sure that all problems are solved, and the details are meaningful, then you can start working! Otherwise, it is necessary to go to the third stage to resolve all conflicts.
 
 
Stage three: we approach the problem critically
 
 
At this stage, you must be able to confidently assert that you understand both the task and the solution. It remains to be seen only whether this is the right decision.
 
 
To create the highest quality product, we all need to be able to take responsibility and speak out if some things are clearly wrong.
 
 
On the other hand, we are not going to make inappropriate claims. You can not say that something is wrong, because "it seems so" or simply "does not like". It is necessary to put forward specific and well-thought-out arguments.
 
 
So, we will outline the basic rules of literate disagreement
 
 
Know when to disagree
 
 
 
Disagreement is unacceptable, until I understand the problem thoroughly.
 
It is possible to say "this is not true" only with absolute certainty that you understand what exactly you do not agree with /
 
If you can not confidently formulate the problem and the planned solution, then you can not disagree. If you are not sure that you understand everything correctly, you can not disagree. Only being confident that you understand the problem to the smallest detail, you can afford to disagree.
 
If you feel that you do not have all the necessary information, then perhaps it's time to stop and review all the steps that have been taken before claiming that the requirements are wrong.
 
It is impossible not to agree on subjective reasons. Pay attention to genuine potential problems.
 
"I do not like how it's done" - a subjective judgment. "This will lead to performance problems, since so many operations are involved" - an objective reason. Examples of other subjective reasons: "And on another project we did it differently" or "I would have implemented this decision a little differently, but this, of course, is a matter of taste".
 
You should have a well-thought-out explanation at the ready, supporting your claims.
 
If you can not explain why something is wrong - can you be sure that you are really right? I advise you to write down the reasons why the decision seems wrong to you, and to formulate how it can be corrected.
 
 
 
If you can not offer such a solution, tell us clearly from the very beginning.
 
 
Be careful when expressing disagreement with others. It is necessary to spend a lot of time to listen to everyone and understand everything - and only then you can disagree.
 
 
If up to this point you have carefully followed all the described stages, then it is very likely that you have understood everything well. However, try very hard not to shut yourself up in your calculations - you could have missed something!
 
 
I like to start the discussion with the words: "It's not that I do not agree with you, I just do not understand yet." Later, if necessary, you can express a strong disagreement, but first of all - to figure it all out.
 
 
Know how not to agree correctly
 
 
To ensure that our disagreement is objective, we will take a number of measures that will help us to understand whether our arguments are legitimate.
 
 
Objective disagreement allows us to demonstrate at least one of the following facts:
 
 
 
The solution is not sufficiently informed
 
The solution is misinformed
 
The task or solution is illogical
 
The solution is incomplete
 
 
 
Uninformed is not an excuse for insult; it simply means that, when creating a solution, you proceed from incomplete data. Perhaps the compilers of TK did not know about the already existing system, capable of performing the necessary actions.
 
 
Being misinformed means creating a solution based on incorrect information.
 
 
It is a case of a case where, in the opinion of the TK compilers, a system that has a system can do something, but in reality this possibility is not envisaged in it. For example, the SEO team asked you to get Google to index a page with a user account in your application. Google can not do this. Hence, your SEOs misconstrue the functions of Google's search robot.
 
 
An illogical task or an illogical solution is simply meaningless. A typical example (from the developer's point of view) is to implement a feature that will crash some other feature. Such a requirement can be considered illogical, since it will rather harm than help.
 
 
The decision is incomplete, and sometimes it is done intentionally. In software development, we often try to create MVP (a minimally viable product). This means that in the first operation, you can purposely postpone the implementation of the functionality, which is not absolutely necessary.
 
 
In fact, an incomplete solution can be considered only if it does not solve the very task that is set before you, or if the steps listed above are not enough to create a workable product or a full-fledged opportunity.
+ 0 -

Comments 1

Offline
Jacelyn
Jacelyn 24 September 2018 21:08
You know, it is not  easy being true to oneself. But if you manage to build that link, there is  nothing stronger than that. That is when you realize you can overcome  anything you wish to.

Add comment