Practical guide "How to deduce a programmer"
Developers and non-developers think in very different ways. Therefore, what seems to everyone else to be normal (questions, comments, and just phrases to support a conversation) can bring a specialist to a white-hot. Managers note: if the programmer nervously twitched the eye after your question, perhaps you should reformulate it or even no longer ask.
Such questions, in addition to a nervous tic, lead to other consequences: programmers have no choice but to lie. Because to give a person, far from programming, an express course “How to write code” in a few minutes, is not an easy task.
So, meet the top 7 phrases of managers who do not leave a choice to programmers.
')
/ Flickr / Kenny Louie / CC
When the manager confidently declares that there is nothing to do here, then, most likely, everything will be quite the opposite. Therefore, sometimes an expert is forced to refuse to perform such a task, referring to the fact that it is not within his competence. The “right” manager should ask himself how long it will take and how much it will cost. It is also a good idea to inquire about the programmer’s opinion on the advisability of making any changes, and then you don’t have to use the programmer’s translation label, because with such a question wording the answer is unlikely to be: “It cannot be done now.”
But when working with new programmers, such a phrase can have the opposite effect, which is perhaps even worse. When yesterday's high school graduate at work is assigned to do something with such a wording, he would rather agree with the fact that this is a damn thing than to admit that he has no idea how to perform such a task.
Of course, this is not so bad, everyone learns from their mistakes. For example, describing his experience as a junior developer in an interview, Jonathan Barronville says that it’s normal to err and not to know something in the initial stages of work. But in order not to hear lies in response to an unfulfilled request or an incorrectly assigned task, managers should discuss the conditions and listen to the opinion of experts.
Even if the code, the site or the program works fine, they have a convenient interface (what users see), behind all this there can be so many errors that it remains a mystery how this all works. And in general, as the well-known Dutch computer scientist Edsger Dijkstra said, if debugging code is the process of eliminating bugs, then programming is the process of introducing bugs.
But to explain to a person far from the development that it is not so easy to avoid errors in the code, the task is almost unreal. Therefore, a programmer would rather say to such a person about his work: “There are a couple of shortcomings here” (something like “Bugs are in my code” from the language of programmers).
Communicating with people far from programming sometimes gives developers, well, you know, “pain”. And when the manager asks you to think like these people, it becomes even worse. Therefore, when a developer says that he understood what the client wants, this is not always the case. The developer knows only what the client said, and what he thinks, and even more so how he thinks, is often incomprehensible.
It’s not for nothing that there is both the manager himself and the quality control department, whose team acts as the third impartial side and ensures that what the programmer does corresponds with the wishes of the client. In addition, they are responsible for figuring out what the user can mess things up. And their job is to behave like the worst user you can imagine.
The programmer will not be able to think like such a user, as he himself knows everything about the code, and the user knows nothing. (Read more about the work of the quality control department here, “How the QA Process Works” and “QA Teams Are Responsible For Keeping the Site From Breaking”).
In general, the client's view of the work perfectly reflects the old, but not losing, video about 7 red perpendicular lines, some of which should be drawn in green ink and some transparent.
Customers and bosses want to see right away that the programmer has started working. More precisely, he sat in front of the screen and began to write code, sure the world famous IT expert David Strom. He made a list of 10 things that non-programmers like to say to programmers, where in the seventh paragraph he explains that such people do not understand the importance of preliminary work.
Writing code is generally the last stage of the work, the preparatory part before this consists of very different things that can seem to idleness to outsiders, MacLeod Sawyer explains in paragraph 4 of his article. To think about the implementation of certain tasks and requirements, sometimes you need to relax, look out the window, hang around, sleep or even play Halo - you never know at what exact moment the decision will come.
Harlan Mills, founder of Software Engineering Technology, once said : “Programming is like playing golf. The goal is not to drive the ball into the hole, but to do it in the fewest strokes. ” To achieve the goal faster, it is necessary as well as possible to think through all the steps and “strikes”. It remains only to explain this to the manager.
Of course, your boss has the right to think so, but he did not have to work with the code without comments. While their presence greatly saves time, if someone else has to work with this code, and even you yourself after a few months or years, writes blogger Jake Rocheleau (see paragraphs 20 and 25). Sometimes the programmer is forced to agree to work without comments (referring to, for example, short deadlines), which complicates the subsequent elimination of errors in the code.
When the programmer himself declares that the code does not require comments or is self-documenting, at the moment he perfectly understands how everything works. But it’s still worthwhile to dwell on some important points: for example, to show that the unusual order of performing a certain operation is not erroneous, but was redone intentionally due to some bugs.
Another issue with comments is that they are rarely updated with fixes to the code. In this case, they can even become dangerous and lead the developer not at all there, explains the author of the books and the founder of Simple Programmer, John Sonmez, in 4 programmer rules (out of 11 existing). But writing or not writing comments should be decided by the programmer, not by the manager or the client.
A phrase that can ruin almost any developer. Explain to the manager that it is simply impossible to calculate all possible errors and problems in advance. Hence, for example, myths are born that the two greatest fairy tales are Tolkien's “The Lord of the Rings” and the schedule of any programmer (such an example is given by Quora user Scott Gardner). Perhaps, sometimes the understatement is peculiar to developers. In this case, the Swedish programmer has prepared a special plate for translating programmer time into real time.
However, if we throw all the jokes aside, the point is not at all that programmers are not at all friendly with time or live in a parallel reality. An excellent explanation for this phenomenon was given by the expert of Electronic Auction Services Brad Landers (Brad Landers), who is sure (the first comment in the source) that the main problem is in the formulation of the task. The more vague a manager or client draws up requirements for a project, the more unforeseen circumstances may arise. Therefore, it is completely dishonest to shift all responsibility for failure to meet the deadlines on the programmer’s shoulders.
It is very difficult to explain to mere mortals that testing any changes (even better step by step) is an indicator of professionalism and will save a lot of time in identifying bugs. But managers are very often sure that they are asking for a minor change that will take a few minutes. But there are no small changes, says Des Traynor, co-founder of the Intercom messaging service. In his article, he gives an example of such a “small” change: the client is asked to limit the writing of the product feedback to 140 characters.
The specialist will immediately see that everything is not so easy and simple, and this change will entail dozens of others: for example, you need to decide what will happen if you exceed the limit of 140 characters? Will the text be cut off, or will the user see an error message? What will be written in this message? What will it look like? Who will design it? Questions, and with them the new small changes, are rolling like a snowball. And each one requires testing.
So, the main thing when communicating with programmers is to have an idea about their work and thinking. Of course, to demand this from all people (no matter how desirable) is meaningless. But from those with whom the developers work side by side, I would like to understand the specifics of the work, which will help to avoid misunderstanding and sometimes conflicts, make the working environment more comfortable and strengthen relations in the team.
We in 1cloud strive for this when organizing work within the team and talk about these and other improvements in our blog on Habré:
Such questions, in addition to a nervous tic, lead to other consequences: programmers have no choice but to lie. Because to give a person, far from programming, an express course “How to write code” in a few minutes, is not an easy task.
So, meet the top 7 phrases of managers who do not leave a choice to programmers.
')
/ Flickr / Kenny Louie / CC
“We need something to look at. It's quick and easy. ”
When the manager confidently declares that there is nothing to do here, then, most likely, everything will be quite the opposite. Therefore, sometimes an expert is forced to refuse to perform such a task, referring to the fact that it is not within his competence. The “right” manager should ask himself how long it will take and how much it will cost. It is also a good idea to inquire about the programmer’s opinion on the advisability of making any changes, and then you don’t have to use the programmer’s translation label, because with such a question wording the answer is unlikely to be: “It cannot be done now.”
But when working with new programmers, such a phrase can have the opposite effect, which is perhaps even worse. When yesterday's high school graduate at work is assigned to do something with such a wording, he would rather agree with the fact that this is a damn thing than to admit that he has no idea how to perform such a task.
Of course, this is not so bad, everyone learns from their mistakes. For example, describing his experience as a junior developer in an interview, Jonathan Barronville says that it’s normal to err and not to know something in the initial stages of work. But in order not to hear lies in response to an unfulfilled request or an incorrectly assigned task, managers should discuss the conditions and listen to the opinion of experts.
“You wrote the code for so long, are there no more errors in it?”
Even if the code, the site or the program works fine, they have a convenient interface (what users see), behind all this there can be so many errors that it remains a mystery how this all works. And in general, as the well-known Dutch computer scientist Edsger Dijkstra said, if debugging code is the process of eliminating bugs, then programming is the process of introducing bugs.
But to explain to a person far from the development that it is not so easy to avoid errors in the code, the task is almost unreal. Therefore, a programmer would rather say to such a person about his work: “There are a couple of shortcomings here” (something like “Bugs are in my code” from the language of programmers).
“You have to think like a client”
Communicating with people far from programming sometimes gives developers, well, you know, “pain”. And when the manager asks you to think like these people, it becomes even worse. Therefore, when a developer says that he understood what the client wants, this is not always the case. The developer knows only what the client said, and what he thinks, and even more so how he thinks, is often incomprehensible.
It’s not for nothing that there is both the manager himself and the quality control department, whose team acts as the third impartial side and ensures that what the programmer does corresponds with the wishes of the client. In addition, they are responsible for figuring out what the user can mess things up. And their job is to behave like the worst user you can imagine.
The programmer will not be able to think like such a user, as he himself knows everything about the code, and the user knows nothing. (Read more about the work of the quality control department here, “How the QA Process Works” and “QA Teams Are Responsible For Keeping the Site From Breaking”).
In general, the client's view of the work perfectly reflects the old, but not losing, video about 7 red perpendicular lines, some of which should be drawn in green ink and some transparent.
"You should not be distracted - otherwise it will not work"
Customers and bosses want to see right away that the programmer has started working. More precisely, he sat in front of the screen and began to write code, sure the world famous IT expert David Strom. He made a list of 10 things that non-programmers like to say to programmers, where in the seventh paragraph he explains that such people do not understand the importance of preliminary work.
Writing code is generally the last stage of the work, the preparatory part before this consists of very different things that can seem to idleness to outsiders, MacLeod Sawyer explains in paragraph 4 of his article. To think about the implementation of certain tasks and requirements, sometimes you need to relax, look out the window, hang around, sleep or even play Halo - you never know at what exact moment the decision will come.
Harlan Mills, founder of Software Engineering Technology, once said : “Programming is like playing golf. The goal is not to drive the ball into the hole, but to do it in the fewest strokes. ” To achieve the goal faster, it is necessary as well as possible to think through all the steps and “strikes”. It remains only to explain this to the manager.
“I pay for the code, not the comments”
Of course, your boss has the right to think so, but he did not have to work with the code without comments. While their presence greatly saves time, if someone else has to work with this code, and even you yourself after a few months or years, writes blogger Jake Rocheleau (see paragraphs 20 and 25). Sometimes the programmer is forced to agree to work without comments (referring to, for example, short deadlines), which complicates the subsequent elimination of errors in the code.
When the programmer himself declares that the code does not require comments or is self-documenting, at the moment he perfectly understands how everything works. But it’s still worthwhile to dwell on some important points: for example, to show that the unusual order of performing a certain operation is not erroneous, but was redone intentionally due to some bugs.
Another issue with comments is that they are rarely updated with fixes to the code. In this case, they can even become dangerous and lead the developer not at all there, explains the author of the books and the founder of Simple Programmer, John Sonmez, in 4 programmer rules (out of 11 existing). But writing or not writing comments should be decided by the programmer, not by the manager or the client.
"Tell me exactly when you're done."
A phrase that can ruin almost any developer. Explain to the manager that it is simply impossible to calculate all possible errors and problems in advance. Hence, for example, myths are born that the two greatest fairy tales are Tolkien's “The Lord of the Rings” and the schedule of any programmer (such an example is given by Quora user Scott Gardner). Perhaps, sometimes the understatement is peculiar to developers. In this case, the Swedish programmer has prepared a special plate for translating programmer time into real time.
However, if we throw all the jokes aside, the point is not at all that programmers are not at all friendly with time or live in a parallel reality. An excellent explanation for this phenomenon was given by the expert of Electronic Auction Services Brad Landers (Brad Landers), who is sure (the first comment in the source) that the main problem is in the formulation of the task. The more vague a manager or client draws up requirements for a project, the more unforeseen circumstances may arise. Therefore, it is completely dishonest to shift all responsibility for failure to meet the deadlines on the programmer’s shoulders.
“Stop testing, it's time to start.”
It is very difficult to explain to mere mortals that testing any changes (even better step by step) is an indicator of professionalism and will save a lot of time in identifying bugs. But managers are very often sure that they are asking for a minor change that will take a few minutes. But there are no small changes, says Des Traynor, co-founder of the Intercom messaging service. In his article, he gives an example of such a “small” change: the client is asked to limit the writing of the product feedback to 140 characters.
The specialist will immediately see that everything is not so easy and simple, and this change will entail dozens of others: for example, you need to decide what will happen if you exceed the limit of 140 characters? Will the text be cut off, or will the user see an error message? What will be written in this message? What will it look like? Who will design it? Questions, and with them the new small changes, are rolling like a snowball. And each one requires testing.
So, the main thing when communicating with programmers is to have an idea about their work and thinking. Of course, to demand this from all people (no matter how desirable) is meaningless. But from those with whom the developers work side by side, I would like to understand the specifics of the work, which will help to avoid misunderstanding and sometimes conflicts, make the working environment more comfortable and strengthen relations in the team.
We in 1cloud strive for this when organizing work within the team and talk about these and other improvements in our blog on Habré:
Source: https://habr.com/ru/post/314586/
All Articles