Happy Programmer Day! Love your developers
Today is the day of the programmer, the 256th day of the year. And we decided to write a post not for our fellow developers, but for those who are close to them and with us. For those who bring us to a white-hot, it makes the brain boil, let off steam and nervously talk about the entities, the interface and the reasons for the broken deadline. For you, dear managers, commerce, analysts, managers without an IT background, and other office friends.
If you read Habr, then most likely you have to communicate with programmers, ask them to finish the front-end or backend of the site, change the analytics code, hang another code snippet in the site header, make software improvements for the client and much more. So how to find a common language with the developer, so as not to quarrel? We know something about this.
So, immediately list.
')
Be clear about your requirements. Always: it doesn’t matter whether you ask for a tiny database selection or prepare a serious software project for a client. There is no description of the tasks in the form “Make me an event card as a VKontakte profile” (VKontakte works a lot of programmers, hire the same and do it), “Well, you will do everything, and I will choose” (to make several program options is expensive, you CEO agreed?), "Let's make this ball here" (this is a ribbon and its implementation requires special libraries). First of all, you need to understand what you want to get, and this is what the programmer needs to translate. Formulate the requirements in Russian, without clerk and pseudo-technical statements - and yes, preferably in writing.
Speaking of writing. This is the greatest invention in the history of mankind, nowadays optimized by computer. Feel free to use the paper in a conversation with the developer:
If it seems to you to be some kind of complex science, google what the system analyst does and what he uses in his work - a lot can be adopted.
No need to use UML diagrams, flowcharts and pseudocode if you do not own them. There was more than one manager on the way who was fascinated by UML diagrams and drew everything he needed into them: from the meeting plan to the marketing campaign description. Indeed, the tool seems logical and convenient, however — a surprise — UML was created to design software architecture, and each designation is not just an arrow or a circle, but a very meaningful component. In addition, your programmer may not know the UML and for it it will be completely meaningless blocks.
The same story with block diagrams, in which different forms of blocks exist not for beauty, but with pseudocode. It is not necessary to write in the style: “ IF a month = April, then a data plate with a field 1 a field 2 a field 3 ”. This is just unreadable nonsense, which does not conquer the IT service, but at best laugh it.
Answer questions on time. Everyone knows that programmers are idlers, they sit and saw their code, they will never reach managers with a hundred tasks. OK. But still, when you lead a project, are responsible for it, and transferred the task to the programmer, have a conscience to answer any questions that arise on time. No need to avoid calls and chats, mark emails as important and put them in a separate folder. A programmer spends his work time interacting with you, it is possible for him to be simple because of an unanswered question - and this is your fault. Please be in touch during work hours on issues that you have put to fellow developers. By the way, third-party customers are also concerned.
And also - if you were asked to see what happened, evaluate the prototype, or test the functionality to see if it meets your requirements, do not go to the ten neighboring employees and do not do it together. So you significantly increase the time to complete the final version.
Heading "Their morals." Let's compare similar requests in Russian and English. Work, love, money - just like everyone else. But most importantly, how do they see the users?
Do not blame the developers in all the problems. “The IT service had been working on the code for so long,” “IT people had a deadline,” “Something a programmer had been digging into TK for so long” is familiar, right? It is easy to blame the problem on the person who interacts with the technology - well, in the same place, something could be a mess. No, keep a strict record of time, record the fact of the transfer of tasks (you can do this, for example, in CRM or on the Gantt chart), let everyone be responsible only for his work.
Another extreme - in the case of customer dissatisfaction, sprinkle ashes on his head and shout: “What are you talking about there! I deliver criticized and translate to you! We lose money and reputation! Urgent! ” Panic is easily picked up by colleagues and management, the programmer’s nerves are at their limits. And in fact it turns out that the client has dropped the port or dropped the connection speed. Learn not to blame, but to ask: “Vas, LLC Volga addressed a problem: there is no connection to the database. Can you tell me what could be there, where to dig? ” Do you feel the difference?
Do not pull into a working draft ideas from around the world. Google added filters to the search, Yandex turned on Alice, Habr launched a new mobile version, Salesforce turned on artificial intelligence, RegionSoft released CRM v.7 and now you are already rushing along the corridor in order to offer to introduce these technologies into your company's project, because they do IT giants. However, any changes should be implemented in terms of feasibility, demand and payback. And if the improvements do not benefit the end user and do not lead to a profit, their implementation will become an extra burden for the developer. Prepare a justification, calculations, calculate the cost of implementation of the features and only then decide to start a discussion.
Do not assess the complexity of the programmer , if you are not a team leader. “We need a module for calculating the volume of the box for sending a parcel, here is a half-day deal, let's sit down!” , Marketer Masha is optimistic and rushes to drink tea before the third meeting. At the same time, Masha herself does not know where she got such a standard of time. The programmer has work tasks, current issues, the bugtracker hangs over him and backkill winks at the side, respectively, it is between them that he will look for time to solve the problem. And it’s not a fact that the problem solved in 15 lines of code can be solved during the set of these lines - time takes the choice of algorithm, search for a solution, selection of libraries, debugging code, auto tests, etc.
Best of all, if you have a company in your company, it will prescribe the procedure for applying for extraordinary modifications / uploads / placements, etc. In this case, everyone will feel confident and know the approximate timing of the problem. And yes, put a real time frame.
Do not try to influence the development technologies stack if you do not develop anything yourself. The situation is banal: the manager goes to the next intergalactic IT conference, listens to the reports and his brain suddenly cuts off that there is noise everywhere around the Go language, and then he was also presented with a teddy Gofer. And now he is standing in front of the IT department, stroking the acquired ground squirrel and telling him about the advantages of Go and how to use it in our bloody enterprise.
The answer is simple. Programmers are extremely inquisitive guys and they will learn about programming languages, DBMS, new operating systems, libraries and frameworks much earlier than a regular conference participant writes about them. At the same time, they are not just curious, but they are looking at whether this or that technology can be useful to facilitate work and strengthen belief in the product (because programmers are also extremely lazy in the good sense of the word). Therefore, it is up to them to decide what to drag into the development stack, and let them rest until better times and new tasks. And you will hardly surpass them in this.
Be careful about writing , it does not transmit intonation (however, this applies to all colleagues and others in general). If you write “And do me an unloading in an hour))))))))))))))” or “I would do it better, it seems to me, it slows down)))))))))))) " , Brackets will not save you - the main message will be considered. Describe any working questions clearly and unemotionally. If you like the work, you can give a chocolate :-)
After the query "why are russian programmers so good" left proud
Do not impose your methods of communication. Today, each of us has about a dozen of communication tools on a working PC and on a mobile phone: Telegram, Skype, SMS, telephone, Viber, mail, Slack, Jira ... And each of them has its own range of tasks and subscribers. Therefore, if a programmer asks to write only in a cart on weekends, to set tasks only in Jira, and to call only via Skype, he has good reasons for this: he knows for sure that he will not forget to do the work associated with these contacts. But your SMS “Start on Monday the report on payments for the first half of the year” will be lost in the discussion thread of the Sunday hike. Therefore, it is better to write about it in work programs and not to consider yourself exceptional and most operational in communicating and setting tasks. Believe me, it's easy.
If you work with programmers and make programs for external customers, ensure release. That is, at the moment when the program is ready and launched in the production, you should have all the promotional materials, visuals, presentations, agreements and so on. This is respect for the work of the developer - after all, in such a company he performs the function of a production unit. If you customized the programmers, they did everything in time, and the release was postponed for three months, it is great to demotivate and devalue the team as such. There is rarely a programmer who doesn’t care what will happen to his program in the future and is not interested in how it behaves in the market and among customers.
Domestic Yandex has a completely different view of things: even Ada Lovelace is counted among the 1C programmers, and in the top of the Assembler and Delphi vacancies (if anything, we searched in an anonymous browser). But the main thing is that there is 256 days - and today it is :-)
Learn from programmers and learn terminology. A person who can program, thinks systematically and logically, knows how to set priorities, sees the essence of things and knows the subject perfectly (no, well, in honor of a holiday, you can exaggerate a little!). He has a lot to learn - all the more, since you work in the IT field, you need a decent mastery of the conceptual apparatus and professional vocabulary. Communicate about work, clarify controversial points, ask, memorize terms and their definitions - this will definitely not interfere with your career. But understanding with the programmer will definitely be better.
At least, you will not write on the corporate portal “Happy Programmer Day to All Those involved"! But you can write something like this:
"Guys! Happy programmer! It's great that there are you who commit the code in time, perform refactoring and make our software even faster and more intuitive, build builds in time and launch them into production. I wish you successful commits, reliable libraries, convenient frameworks and us, adequate users. You are making the present world a bit of a future. And we love you! ”
Well, have learned our little lesson? Now write congratulations to your developers.
Happy holiday, friends! Team RegionSoft Developer Studio , developers of powerful CRM and other business software, who know a lot about communication between users and programmers
Our telegram channel
We convey greetings to the main Nizhny Novgorod channel about events in IT and their website it52.info . Go to the event, be in the subject.
If you read Habr, then most likely you have to communicate with programmers, ask them to finish the front-end or backend of the site, change the analytics code, hang another code snippet in the site header, make software improvements for the client and much more. So how to find a common language with the developer, so as not to quarrel? We know something about this.
So, immediately list.
')
Be clear about your requirements. Always: it doesn’t matter whether you ask for a tiny database selection or prepare a serious software project for a client. There is no description of the tasks in the form “Make me an event card as a VKontakte profile” (VKontakte works a lot of programmers, hire the same and do it), “Well, you will do everything, and I will choose” (to make several program options is expensive, you CEO agreed?), "Let's make this ball here" (this is a ribbon and its implementation requires special libraries). First of all, you need to understand what you want to get, and this is what the programmer needs to translate. Formulate the requirements in Russian, without clerk and pseudo-technical statements - and yes, preferably in writing.
Speaking of writing. This is the greatest invention in the history of mankind, nowadays optimized by computer. Feel free to use the paper in a conversation with the developer:
- make sketches and prototypes of what you want to see (if we are talking about a program or a separate interface) - today there are many tools for this
- use mind maps to plan work and create a project plan
- describe the desired functionality as simple and detailed as possible
- make a technical task (TZ).
If it seems to you to be some kind of complex science, google what the system analyst does and what he uses in his work - a lot can be adopted.
No need to use UML diagrams, flowcharts and pseudocode if you do not own them. There was more than one manager on the way who was fascinated by UML diagrams and drew everything he needed into them: from the meeting plan to the marketing campaign description. Indeed, the tool seems logical and convenient, however — a surprise — UML was created to design software architecture, and each designation is not just an arrow or a circle, but a very meaningful component. In addition, your programmer may not know the UML and for it it will be completely meaningless blocks.
The same story with block diagrams, in which different forms of blocks exist not for beauty, but with pseudocode. It is not necessary to write in the style: “ IF a month = April, then a data plate with a field 1 a field 2 a field 3 ”. This is just unreadable nonsense, which does not conquer the IT service, but at best laugh it.
Answer questions on time. Everyone knows that programmers are idlers, they sit and saw their code, they will never reach managers with a hundred tasks. OK. But still, when you lead a project, are responsible for it, and transferred the task to the programmer, have a conscience to answer any questions that arise on time. No need to avoid calls and chats, mark emails as important and put them in a separate folder. A programmer spends his work time interacting with you, it is possible for him to be simple because of an unanswered question - and this is your fault. Please be in touch during work hours on issues that you have put to fellow developers. By the way, third-party customers are also concerned.
And also - if you were asked to see what happened, evaluate the prototype, or test the functionality to see if it meets your requirements, do not go to the ten neighboring employees and do not do it together. So you significantly increase the time to complete the final version.
Heading "Their morals." Let's compare similar requests in Russian and English. Work, love, money - just like everyone else. But most importantly, how do they see the users?
Do not blame the developers in all the problems. “The IT service had been working on the code for so long,” “IT people had a deadline,” “Something a programmer had been digging into TK for so long” is familiar, right? It is easy to blame the problem on the person who interacts with the technology - well, in the same place, something could be a mess. No, keep a strict record of time, record the fact of the transfer of tasks (you can do this, for example, in CRM or on the Gantt chart), let everyone be responsible only for his work.
Another extreme - in the case of customer dissatisfaction, sprinkle ashes on his head and shout: “What are you talking about there! I deliver criticized and translate to you! We lose money and reputation! Urgent! ” Panic is easily picked up by colleagues and management, the programmer’s nerves are at their limits. And in fact it turns out that the client has dropped the port or dropped the connection speed. Learn not to blame, but to ask: “Vas, LLC Volga addressed a problem: there is no connection to the database. Can you tell me what could be there, where to dig? ” Do you feel the difference?
Do not pull into a working draft ideas from around the world. Google added filters to the search, Yandex turned on Alice, Habr launched a new mobile version, Salesforce turned on artificial intelligence, RegionSoft released CRM v.7 and now you are already rushing along the corridor in order to offer to introduce these technologies into your company's project, because they do IT giants. However, any changes should be implemented in terms of feasibility, demand and payback. And if the improvements do not benefit the end user and do not lead to a profit, their implementation will become an extra burden for the developer. Prepare a justification, calculations, calculate the cost of implementation of the features and only then decide to start a discussion.
Do not assess the complexity of the programmer , if you are not a team leader. “We need a module for calculating the volume of the box for sending a parcel, here is a half-day deal, let's sit down!” , Marketer Masha is optimistic and rushes to drink tea before the third meeting. At the same time, Masha herself does not know where she got such a standard of time. The programmer has work tasks, current issues, the bugtracker hangs over him and backkill winks at the side, respectively, it is between them that he will look for time to solve the problem. And it’s not a fact that the problem solved in 15 lines of code can be solved during the set of these lines - time takes the choice of algorithm, search for a solution, selection of libraries, debugging code, auto tests, etc.
Best of all, if you have a company in your company, it will prescribe the procedure for applying for extraordinary modifications / uploads / placements, etc. In this case, everyone will feel confident and know the approximate timing of the problem. And yes, put a real time frame.
Do not try to influence the development technologies stack if you do not develop anything yourself. The situation is banal: the manager goes to the next intergalactic IT conference, listens to the reports and his brain suddenly cuts off that there is noise everywhere around the Go language, and then he was also presented with a teddy Gofer. And now he is standing in front of the IT department, stroking the acquired ground squirrel and telling him about the advantages of Go and how to use it in our bloody enterprise.
The answer is simple. Programmers are extremely inquisitive guys and they will learn about programming languages, DBMS, new operating systems, libraries and frameworks much earlier than a regular conference participant writes about them. At the same time, they are not just curious, but they are looking at whether this or that technology can be useful to facilitate work and strengthen belief in the product (because programmers are also extremely lazy in the good sense of the word). Therefore, it is up to them to decide what to drag into the development stack, and let them rest until better times and new tasks. And you will hardly surpass them in this.
Be careful about writing , it does not transmit intonation (however, this applies to all colleagues and others in general). If you write “And do me an unloading in an hour))))))))))))))” or “I would do it better, it seems to me, it slows down)))))))))))) " , Brackets will not save you - the main message will be considered. Describe any working questions clearly and unemotionally. If you like the work, you can give a chocolate :-)
After the query "why are russian programmers so good" left proud
Do not impose your methods of communication. Today, each of us has about a dozen of communication tools on a working PC and on a mobile phone: Telegram, Skype, SMS, telephone, Viber, mail, Slack, Jira ... And each of them has its own range of tasks and subscribers. Therefore, if a programmer asks to write only in a cart on weekends, to set tasks only in Jira, and to call only via Skype, he has good reasons for this: he knows for sure that he will not forget to do the work associated with these contacts. But your SMS “Start on Monday the report on payments for the first half of the year” will be lost in the discussion thread of the Sunday hike. Therefore, it is better to write about it in work programs and not to consider yourself exceptional and most operational in communicating and setting tasks. Believe me, it's easy.
If you work with programmers and make programs for external customers, ensure release. That is, at the moment when the program is ready and launched in the production, you should have all the promotional materials, visuals, presentations, agreements and so on. This is respect for the work of the developer - after all, in such a company he performs the function of a production unit. If you customized the programmers, they did everything in time, and the release was postponed for three months, it is great to demotivate and devalue the team as such. There is rarely a programmer who doesn’t care what will happen to his program in the future and is not interested in how it behaves in the market and among customers.
Domestic Yandex has a completely different view of things: even Ada Lovelace is counted among the 1C programmers, and in the top of the Assembler and Delphi vacancies (if anything, we searched in an anonymous browser). But the main thing is that there is 256 days - and today it is :-)
Learn from programmers and learn terminology. A person who can program, thinks systematically and logically, knows how to set priorities, sees the essence of things and knows the subject perfectly (no, well, in honor of a holiday, you can exaggerate a little!). He has a lot to learn - all the more, since you work in the IT field, you need a decent mastery of the conceptual apparatus and professional vocabulary. Communicate about work, clarify controversial points, ask, memorize terms and their definitions - this will definitely not interfere with your career. But understanding with the programmer will definitely be better.
At least, you will not write on the corporate portal “Happy Programmer Day to All Those involved"! But you can write something like this:
"Guys! Happy programmer! It's great that there are you who commit the code in time, perform refactoring and make our software even faster and more intuitive, build builds in time and launch them into production. I wish you successful commits, reliable libraries, convenient frameworks and us, adequate users. You are making the present world a bit of a future. And we love you! ”
Well, have learned our little lesson? Now write congratulations to your developers.
Happy holiday, friends! Team RegionSoft Developer Studio , developers of powerful CRM and other business software, who know a lot about communication between users and programmers
Our telegram channel
We convey greetings to the main Nizhny Novgorod channel about events in IT and their website it52.info . Go to the event, be in the subject.
If you are from Nizhny Novgorod
Guys, a non-standard request for Habr - we in Nizhny Novgorod are looking for a sales person, but, as it were, a sales person ++, for an innovation company. If you have a young resident of Nizhny Novgorod (alas, only an office), who dreamed of entering IT, but did not sign in, please drop the link to the vacancy - we are cool and after us the person leaves with a chic experience (though something isn’t leave, work for 10-15 years, and it's cool!).
Source: https://habr.com/ru/post/423159/
All Articles