Happy Programmer! 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 sample 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 as many as we do), “Well, you will do everything, and I will choose” (it’s expensive to make several program options 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 the 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 the 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 UML, and for him 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 field 1 field 2 field 3 ". This is just unreadable nonsense, which does not conquer the IT service, and at best laugh.
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 run a project, are responsible for it and handed the task to the programmer, have a conscience to answer any questions that arise on time. You do not 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 working 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 has been working on the code for so long,” “IT people have a deadline,” “Something a programmer has been digging in for so long” is familiar, right? It is easy to blame the problem on the person who interacts with the equipment - 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 their work.
Another extreme - in case of customer dissatisfaction, sprinkle ashes on your head and shout:“What the hell are you there for! 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 search, Yandex turned on Alice, Habr launched a new mobile version, Salesforce turned on artificial intelligence, RegionSoft released CRM v.7and now you are already rushing along the corridor in order to propose to introduce these technologies into your company's project, because this is what the IT giants do. 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 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 it’s half a day, let's sit down!”- the marketing specialist 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. A programmer has working tasks, current issues, a bugtracker is hanging over him and backlocking winks at the side, so it is between them that he will look for time to solve the problem. And it’s not a fact that a problem solved in 15 lines of code can be solved during the set of these lines - time takes away 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 here he was also presented with a teddy Gofer. And now he is standing in front of the IT department, stroking the acquired gopher and telling him about the benefits 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 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 make me unload in an hour)))))))))))))))" or“I would have implemented it better, it seems to me that it slows down)))))))))))) , the brackets will not save you - the main message will be considered. Any working questions describe clearly and unemotional. If you like the work, you can give a chocolate :-)
After the query "why are russian programmers so good" left to be 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 report on payments for the first half"Lost in discussion threads of the Sunday hike. Therefore, it is better to write about it in work programs and not 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 ranked among 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 are working 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, did you learn our little lesson? And now write congratulations to your developers.
Happy holidays, 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 send 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 sample 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 as many as we do), “Well, you will do everything, and I will choose” (it’s expensive to make several program options 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 the 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 the 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 UML, and for him 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 field 1 field 2 field 3 ". This is just unreadable nonsense, which does not conquer the IT service, and at best laugh.
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 run a project, are responsible for it and handed the task to the programmer, have a conscience to answer any questions that arise on time. You do not 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 working 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 has been working on the code for so long,” “IT people have a deadline,” “Something a programmer has been digging in for so long” is familiar, right? It is easy to blame the problem on the person who interacts with the equipment - 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 their work.
Another extreme - in case of customer dissatisfaction, sprinkle ashes on your head and shout:“What the hell are you there for! 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 search, Yandex turned on Alice, Habr launched a new mobile version, Salesforce turned on artificial intelligence, RegionSoft released CRM v.7and now you are already rushing along the corridor in order to propose to introduce these technologies into your company's project, because this is what the IT giants do. 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 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 it’s half a day, let's sit down!”- the marketing specialist 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. A programmer has working tasks, current issues, a bugtracker is hanging over him and backlocking winks at the side, so it is between them that he will look for time to solve the problem. And it’s not a fact that a problem solved in 15 lines of code can be solved during the set of these lines - time takes away 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 here he was also presented with a teddy Gofer. And now he is standing in front of the IT department, stroking the acquired gopher and telling him about the benefits 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 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 make me unload in an hour)))))))))))))))" or“I would have implemented it better, it seems to me that it slows down)))))))))))) , the brackets will not save you - the main message will be considered. Any working questions describe clearly and unemotional. If you like the work, you can give a chocolate :-)
After the query "why are russian programmers so good" left to be 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 report on payments for the first half"Lost in discussion threads of the Sunday hike. Therefore, it is better to write about it in work programs and not 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 ranked among 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 are working 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, did you learn our little lesson? And now write congratulations to your developers.
Happy holidays, 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 send 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!).