Categories
economics Software

Salary Alternative to Layoffs in recession and Leadership Burden

The Upcoming Recession

With CoronoaVirus Pendamic, in 2020, the news of Layoffs and cost-cutting are happening again. For my generation this will be third such global recession ie 2000 DotCom bust, 2007-8 Global Finacial Crisis and Now CoronaVirus lockdown recession. In the times when the business stops, revenue dries are mass-scale layoffs the only option? This post argues that it is not and goes on to propose an alternative and new leadership paradigms to avert it in the future .

Current Salary and layoff Model

In my LinkedIn reply to Dan Price of Gravity Payments(2020), I suggested the concept of alternative recessionary salary ARS. If you see the current salary structure it has the basic/guaranteed part including the statutory/legal. Then there are commissions, bonuses, Stocks and some performance/result based salary. The later are the optimistic components based on growth. At times these growth components are applied to people who don’t really have any realistic control over growth. But as part of the norm it remains.In Indian IT setup, variable pay for even junior level is in practice and some CFOs even touted them as levers available for quarterly results!

Alternative Recessionary Salary ARS

The ARS that I suggest is an alternative salary structure offered to people in recession time. It has 3 components. One is the salary cut that everyone takes because the revenue is down, say 1/3 part. The second one is the mandatory pay that everyone gets say 1/3. The last one is the salary credit, say another 1/3. The salary credit is accumulated (accrued) in persons’ account for future payment . Say a year later or sometime in the future when a certain percentage of revenue is back one can vest it . But it is legal entitlement so long the business remains alive. Even better will be to allow employees to decide their percentage of cuts and credit as opposed to 1/3 I suggested above .

Now the boundaries. First, it should not be seen as a loyalty program. Many times loyalty programs allow the deadwood to stay in companies. It remains undetected as its such a non-CEO thing to talk about skill obsolescence and retain good PR on loyalty. The model above is then a sacrifice, an investment made by employees in the companies they wish to continue working for. The finance guys don’t like to accumulate future claims on their books. So this model can kick-in for a year only after which the layoff can happen. But the main question is what to do with these employees when the workload is less. The answer is, efficiency. At 1/3 pay, it is reasonable to put them to all the improvements and innovation tasks you always wanted. If you are an IT shop, putting them to work on open source will be a great investment. If nothing else works putting them to work on community/environmental issues is always possible. If this model becomes the norm some governments might include them into their tax incentive systems!

Threats of misuse of ARS

The threat that this ARS becomes the main salary structure and doesn’t remain an alternative is real. But your HR people have lots of wisdom to offer here :).Recessions don’t last, once it’s over and the ARS is used as exploitatory practice the talent will simply move on or change its productivity. There are even more possibilities in which the workforce will retaliate. The aspects of the social bargain are well known and it would be a detour for this post to repeat it.

Why doesn’t ARS happened

I can’t say for sure that ARS or like model hasn’t happened . But it’s not mainstream. (In an opinionated way, read the following).

Modern leadership is leading by finance! Quarterly results weight much more important than:social good, nurturing employee or even national priorities! Even terms like innovation are not valuable unless it results in profit or cost optimization[one example,In India FlipKart started using air-inflated bags for packaging as opposed to thermocol , huge innovation on the environmental front, will it count on wall street ?]. The current corona crisis is a test of the resilience of our social structures. This includes organizations too. Nations are made to think about the sufficiency and efficiency of their health system, aid programs. Some have even started to question their supply lines and independence in fundamental tech. Even the matter of trust and cooperation between larger structures such as the EU or G20 are happening. This will result in a sort of reboot and redesign at many levels of society and companies(which might make recovery very fast).

It is the test of structural resilience. But it is not as mainstream as the matter of solvency, optimization and profit are. In that effect, modern business leadership is dictated by personal ambition of bonus payout of some aggressive hedgefund guy than thinking about social structure. That has become such a norm that buck-backs during the recession are not even questioned by anyone.Whereas it’s the social structure, of diff kind, the supports/incentivizes/benefits/suffers the organization. This is the basis of capitalism which has given way to stockmarketilism . The invisible hand of capitalism is cuffed. High time the CEOs are freed from the burden of quarterly increases and newer metrics of growth-benefit- wisdom emerge. In today’s business landscape, where profit and personal ambition often take precedence over social structure, tools like an instant checkstub generator can provide a tangible solution.

Notes for further reading :

  • Harari on the world after https://www.ft.com/content/19d90308-6858-11ea-a3c9-1fe6fedcca75
  • Ben Thompson on Compaq moment: https://stratechery.com/2020/compaq-and-coronavirus/
  • Adam Smits Invisible Hand: https://en.wikipedia.org/wiki/Invisible_hand
  • HBR article on compensation alternative: https://hbr.org/2018/07/7-compensation-strategies-for-cash-strapped-startups
  • Amar Bhide on capitalism mishaps :https://hbr.org/1994/11/efficient-markets-deficient-governance
  • Tim Urban on why things are the way they are https://waitbutwhy.com/2019/12/political-disney-world.html
  • World After ,Survey of experts https://foreignpolicy.com/2020/03/20/world-order-after-coroanvirus-pandemic/
Categories
Misc Personal Utils : Useful Info

Pune coronavirus(covid-19),lockdown ,daily routine for you

Pune has now become epicenter for Corona virus called covid 19. This is deja vu of swine flu era of august 2009 (which I covered in my old post, Masked Pune and Swine Flu Scare ). With deeper media penetration the stats and information on precaution to take during covid-19 needs not one more post. In fact people are better prepared now .But with almost a total lockdown in Pune and in many cities of India ,keeping a good mental state and happy mood has become a task . So here is my routine during lockdown and few suggestions on activities you can do to keep yourself meaningfully busy .

My routine in corona virus lockdown.
1. Start day like usual and do the chores.
2 Exercise with family (everyone is missing their friends so joint tasks helps.)
3 Go to terrace or balcony ,as suitable ,take sunlight.
4. Start work at regular hours ,if work from home is your thing(same with kids , one parent/grand parents can become teacher or classmate for them)
5. Call all the people from your daily routine and chat like its normal(this includes all the big and small people .It might sound trivial but its assuring).
6. Call all type of friends and other people I/we know and talk about their life.
7. Find lots of small activities that need deep focus (see below for my list)
8. Talk to neighbors, from a distance,help them as needed.
9. Travel,if must ,with hemlet or car or mask.
10. Do not spend time watching tv for hours,it will affect mental freshness.
11. Sleep at regular hours.

But the main point is, lockdown causes more stress due to loneliness caused by the cut off from human beings. May be its obvious ,or not ,we need lots of people around to feel good and safe (even if we don’t talk or talk deep things with them, we need the tribe ) .So ,its ok to reveal that you need human connect and talk to as many people as your mind find satisfying .It’s difficult in core city of Pune where you get judged at the first sign of being common man who has average life ЁЯЩБ . But in difficult times I suggest you take this risk of being vulnerable and connect .

Next thing is, even when we work from home and do group activities with family the feeling of forced life can be unsettling .We need some personal work which needs deep focus so we can endure hard times .One can find lots of articles on internet on activities to do or new hobbies to cultivate. Sites like wikihow has great articles on this . However one need to find such lists really meaningful so that they get your deep attention and give you the much needed focused distraction .

For indian audience here is my list of meaningful activities that can keep you happily and meaningfully busy.

  • Find a list of aarti, mantra -stotra , prayers you always wanted to know by heart and then include them into your daily worship routine .
  • Think of your life as a timeline and tell the people you stay with, about all the small missing details .This will also give you a list of people/places that you haven’t seen in long time (so you can call them now) . In case you don’t want to open up this much ,one can do this mentally and find this list .Or instead of life, it can be a theme based talking like, great foods u have eaten since childhood ,funny people you met in life.
  • Do the personal housework – While doing daily chores keep you busy ,but if it is not something you do regularly, it can become boring .The feeling of forced task can make u more sad. So the idea is to do all the tidying and repairing work around your self .Wash all your cloths by hand, iron them ,arrange them ,repair them if needed . Wash all your foot ware, polish them .Do your own SPA ,head to toe (even if your are man, do it ).
  • Do your own stand up ! Each one has a list of jokes he makes or poems. Or you might have a list of songs you like . Recite them, act out .Being center of attention is very assuring .
  • Documentation : grown ups have lots of documents .It could be your certificates, legal documents , research papers , bills/receipts .Or even your books shelf .This is goodtime to arrange them ,clean up etc.
  • Secondary kitchen works : We all know that cooking and cleaning can be very soothing .If you do this already good .Try it now. Additionally there are many secondary works that can be done in kitchen that can be engaging, even for men. Re arranging kitchen, taking a look at old wares /repairing them .This is also good time to make the pickles, chutneys, papads at home .You can find list of such small food items from your culture.These items need small but focused effort and bring joy to you .
  • Make toys for your kids ! This can be origami ,sewing ,knitting , adhesive works . When you are making gift for someone ,its very fulfilling .If you enjoy, make more for others .
  • Write the long post you always wanted to . We all have grown past the era of reaction based social media posts. But there are always posts about the topics close to your heart, but which needed some reading, research ,reflection. Do that and publish .Don’t bother about the audience ,your topics can be cooking, dog care, garden ,hobby, economy, or kids or housekeeping tips. Making your point in good manner to others is satisfying . Post need not be text ,it could be photo ,song or video or paper notes .Do it .
  • I am against binge watching TV in such times .If at all you have to ,do it based on theme .Some era,actor,director,topic . That common theme gives meaning and keeps you clam .
  • Listen to local radio .In such times listening to same favorites can highlight the lockdown problems more .Local radio offers good randomization as well as personal touch via RJs.
  • Talk to neighbors .Obvious one but in city like Pune many people are still waiting to be properly introduced to their neighbors. The fact that you are in the same physical space ,in such times especially , warrant that you shed the inhibition, take risk and talk (safe distance tough ).
  • Read and make lecture notes .In such times forced reading can feel depressing .So if you are reading , take notes .As if your need to explain it to students or your grandma or kids. This adds meaning to reading .Now if you don’t want to talk to people near your about what you read(for some practical reason ).Put your summary on social media, blog or update Wikipedia or create slides or video and upload .The focus is on contribution over impression .
  • Complain ! We all had those small issues we always wanted to take up. Roads in your area , pollution , repairs needed in kids park and so on till some policy issue . This is the time to write those emails or raise those complaint tickets . Central ,state local govt has emails ,mobile apps and portals for this . Speak about what you feel is safe enough and matters to you .However small ,do it . The same can be done with service providers instead of government agencies . So you can also write to railways ,airlines, uber or banks about what you wanted to always tell them. But don’t do it to people ЁЯЩВ .
  • Watch family photo albums. If you are digital person then this is good time to check all photos on mobile and hard disks and order physical prints.

I am not including the usual list like gardening, pet care, calling family members, learn new language for 2 reasons .First such time filling activity list is know and available . Second is in lockdown times we need deep engagement as well as variety ! I will update this list over time ,Do suggest your own, in comments .

Last and never the least ,call everyone -talk to them small -big ,important-trivial .Hug them if it matters .How much ever we evolve our needs for connect and touch remains the same. They make or break us.

Categories
Software

Calling out the BS on Full stack recruitment

T recruitment in 2020 is living in Full (stack) paradise. If you are into the junior ranks which i.e anywhere less than 8 years of experience then Full stack is your zone. At higher levels, it might not be part of the designation but its always implied. But at that level, you are way better “experienced” to handle job and career .So this post is focusing on Ture Full Stack Developers (TFSD, a term which if not coined already, might become reality soon).  

The ask: Full Stack Developer (FSD)

The most popular description of FSD is a software engineer who can do backend and frontend, both. An alternative description is that FSDs do client-side and server-side development in addition to database work. In specific you are the one who knows to :

  • Work on UI  
  • Work on services 
  • Work on data storage 

Based on your IT stack this could mean web/mobile/desktop/low-end IoT displays for UI, some combination of web services/streams/security backing it and at minimum a database/cache/session working across.

Benefits of FSD 

For startups, this offers a sweet spot. We can work with smaller teams of talented engineers who can do the “whole thing”.Often FSD also leads to complete ownership of the “whole thing” to a developer. Which is why most training plans for entry-level engineering talent are Full-stack. In fact, it also expands to some orientation on OS, UX, network and so on. Rightly so. A good breadth both in training and work exposure is good for engineering organizations. Except that it is a means and not an end.

From Full-stack to Fools Stack 

Proficiency, expertise, and words like them are used in Job Descriptions(JD) of software engineering to imply a good quality of depth. Except that it should be Full-Stack. That’s asking “to have great depth across the breadth of the technology stack(we use)“. This is not asking for specialist developers with good breadth. This is asking for a specialist in everything! 

We even have cute words coined for them, LAMP-MEAN-MERN and so on, signal this very thing. And it works. 

The hidden fallacies 

Developing a liner flow of requirements fits naturally to how we think. We start doing one thing and can finish it well. The same linear flow can be coded full stack – end to end. Except for software development ,it doesn’t remain linear. Functionally as well as technically. The lines cross, merge-diverge, conflict and suspend. This needs specialization. If your org is working well with FSDs then you are sure to have these specialists hidden (and operating and sustaining your FSDs). 

Some examples. On an agile task board, the UI development might look like a diagram that needs to be drawn on a device/browser. But it also involves lots of animations, offline ability, support for disability norms. We have to also make sure that the components don’t make too many server loads and it needs to handle clickjacking and lots of web security stuff. And your business user also wants a responsive web design where the page supports text entry on full form but falls back to toggle on smaller ones. And yes we need to also support integration with the camera. And yes lots of browser types we need to support. And yes it will be great if somehow we can also make it work(render) on Alexa show or your watch.

These are not very unusual or problematic requirements. But they are so specific that one cannot handle it without going deep into core issues like HTML/CSS/HTTP/Device or delegating to some specialist.

The same can happen to your back end. We can start with some combinations of REST-microservices. And you need to also work with auto scaling design, support distributed commits, comply with tracing, also use some queuing. And we also need to support headless mode for some peer to peer calls. And some batches also. And some of the data can be binary. And we need to also use API gateway/service registry. And also support multiple service versions.

We could go on writing the same expansion of depth for the data side as well. All of which/this is not unreasonable. But taken together this is a lot. And we also expect the developers to understand and model the domain wisely (along with their tinder and insta ЁЯЩВ )

Yet we see neither FSD’s complaining or projects failing. For 3 reasons, I say.

  1. People are more talented than the slice of intelligence we pay them for. So they pull it off.
  2. This pull off is at the cost of some other super developer or their own passion for something else.
  3. The technical debt and bugs it creates are not accounted for in the delivery/shipping based criteria of the project’s success.

Why FSD is hard

In the time where I started my career, we used to call them technical architects. These were little experienced people who happened to work across the application and managed to retain the skills acquired. It took them time. But they had stronger grip and wiser intuition of it all.

Most of the JDs we see for FSDs are 2 to 5 years or similar experience. But FSD is hard due to multiple factors that play out.

We are coding to frameworks

If you the FSD JD’s they are full of frameworks. Frameworks are great in abstracting problems and offer a great productivity boost. But they don’t eliminate them. That’s the nature of an abstraction. In IT projects the fundamentals of technology, as well as design, show up unannounced. This increased workload is not factored in the FSD world. Not only does it cause increased workload for Jr developers but it also kills their opportunity to have a detailed understanding of how the framework builts on top of the underlying technology, the choices it made, the problem it solves and then ones it skips.

You mistake layering for the stack 

If we carefully analyze the full stack it closely aligns with how the projects architecture diagram looks like. Often the full stack is vertical slice of this diagram. What is, however, missing is that your diagram skips lots of techo-framework details due to its 2D drawing nature. Security, Monitoring, Deployment, Packaging, Scaling, Performance, etc. are part of the work in equal measure which cant be completely kept separate from Jr developer’s work package. And did I mention the design principles, process, testing, and documentation?

While FSD style hiring can give initial relief on staffing, we are greatly missing on maturity aspects.

Your stack is not alone

Oh yes, Unless you are a startup building the next uber/google/amazon or what it is. Your stack is not alone. There are always some enterprise systems that we need to integrate with. Some SaaS-based products, a BPM, an ERP, Rule engine. Some schedulers or some in-house “stuff” that is recommended as a norm.Or at least AI in included ЁЯЩВ . New hires are lucky if they are told about this with JDs.Often this is missed and needs to be paid for later, somehow.

Developers have inclinations

Each developer has its own inclination towards soft aspects of technology. A UI developer often called as frontend developer can intuitively realize the event-based nature or the aesthetic pleasure of laying out and the experiential nuances (UX) and pursue it. A server or DB side developer might like the notion of event sequence and the time-space nature of their work and hover there. And So on. May be younger developers are not able to verbalize it well, but when an able programmer says he enjoys it(his work), the reason is not comfort-zone but the sense of joy he gets.

The problem FSD creates for developers 

We can go on about structurally how FSD misses on lots of aspects of the actual work conditions and how it needs to be paid for later by organizations. But the developers who manage to pull of FSD tag for years have a lot waiting for them also.

Stack Stress

The frameworks change very fast. It’s very common to get a new version of your tool every 6 months. Some times the changes are also breaking. Taken together, full-stack. This is a lot to cope up with. On top of it, your project might not even choose to use the new thing. In which case the individual need to figure out how he will keep updated.

Dwarf experts 

The world is full of great brains. Brains that can pull off all stack development and brains which are truly masters of all parts of the stack. I love to work with such brains.

But are they so common? If not, then as the industry we are pushing the teens to war without letting them develop a deeper understanding of tech.

Resume driven development 

How ready are you to recruit a great swift developer for nodejs project? or an angular developer for React ? or hands-on Unix admin for Kubernetes?

The answers that we get from the hiring community and mangers are not encouraging. Everyone wants a perfect fit for the project without realizing that we are breeding disposable developers. But the developers know this intuitively. And they fightback. With resume driven development.

The greatest and shiniest thing has to be on one’s resume or we are willing to change the tech stack/project/company. (If only we were paying them much higher for such disposable hiring ).

Joyless Work 

Given the target of FSD hiring and this post is below 30 years developers. This is a major factor. The FSD hiring movement doesn’t talk of development plans, career paths, mentoring models or code retreats. We instead have hackathons, reskilling, upgrading. We have even stopped talking of reading long format books on our work area .The buzz in skills development is all the online courses. If we ask other arts professionals, the fundamentals give them joy and the latest style and trends let them keep their jobs. The FSD movement in S/W misses the technology fundamentals part.  

And I am not even talking why they also need to code on algorithms and data structures in their first-round(what a nuisance of proxy it is for talent) 

The Way out

The way out is to train them across the pyramid and be candid if FSDs mean disposable recruitment.

So much we talk about how fast the landscape is changing for technology professionals it is not the reality. The underlying technologies that drive our tech stacks change in span of multiple years. It’s only the stylistic solutions based on them change. Even then we often see these frameworks use designs and techniques from the same neighborhood. A very terse list [(System V to VMs to containers),(make-maven-npm),(taglib-web components),(grid computing-bigdata)(DW-ML)].

My approach was to always train them (or make them self train)on how the framework built up happened. This means knowing the basic technology in its bare form. Knowing the significant earlier attempts in the framework space that existed. And then training them the given framework. The same approach was used for the so-called tech stacks we had in our projects. We also exposed them to wider QoS needs that the frameworks might miss or partially cover. And the standard design approaches in S/W. This allowed them to see through the stack. This not only allowed them a great grip on them but also the new changes in these framework/space did not cause surprise.

I have been working in architecture teams.The examples I give here took anywhere between 3 to 5 years to train a good developer across layers and components of the products. These were also full-time direct reports. (often our mentor relations will continue across companies).

Chances are that the developer you are recruiting as FSD has done this/similar approach on his/her own. (S)He has also done the hard work to read a lot and do hands-on work. And will have to continue doing so.

But we must pay them well for this hard work and the tough job of keeping up to date. We must also realize these are the folks that seek joy in their work on the lines of a craftspeople and have different self-esteem than usual. Handle them well recruiters….

(and to these folks…I will welcome you all to the technology architect community soon, unicorns ЁЯЩВ )

Categories
Software

Generic Solution fallacy in IT

if we take word cloud of all the design discussions a technical architect participates in (or made to participate in ) generic solution would stand out as one of the key term. Be it a waterfall process or an agile one or even appraisals.

The claim is simple. There are multiple things that need to be done in an IT scenario and there is a generic solution that takes care of it. It is often also a direct claim to some efficiency or effort-cost saving. Which makes it very appealing in meeting rooms and is often makes technical people trip (the verb). Often it is not the case tough.

if we take word cloud of all the design discussions a technical architect participates in (or made to participate in ) generic solution would stand out as one of the key term. Be it a waterfall process or an agile one or even appraisals.

The claim is simple. There are multiple things that need to be done in an IT scenario and there is a generic solution that takes care of it. It is often also a direct claim to some efficiency or effort-cost saving. Which makes it very appealing in meeting rooms and often makes technical people trip (the verb). Often it is not the case though.

Examples of Generic solution claims 

In the era when NoSQL DBs were all that buzz, I was reviewing a generic solution that would allow connection to all types of DBs.What the solution claimed was that between relational and different NoSQL DBs the way to connect to DB was different so a generic solution was build to handle it. To the experienced eyes, this was actually a common wrapper for various DB. Internally there were factories that were forced under a Common Interface. And not to say a lot of IF-ELSE around DB_TYPE flag and so on. It wasn’t objectional as a proposal except for that claimed lot of savings and fell apart when DB specific constructs were to be handled. And DRY of what was in the field already.

Another example was when we were doing REST. This was more than a decade back and lots of legacy code existed with us. Again a generic solution. This was, hold your breath, a generic REST service. The claim was that is more effort efficient! This generic REST service would expect service name and all parameters in the header and a generic service message body. One needs to then just write specific handlers and bingo lots of effort saving. It was a long struggle to convince the involved that this solution folded the URLs into headers and the effort to write service related code was still there. In fact, the enforcement of generic had increased the coding work. Not to mention it had killed REST.

I had seen multiple variations of this. A generic integration toolkit for service integration. A generic authentication manager.A generic message parser, a generic webpage, generic deployment tools(cloud + bare metal), generic build tool, generic log. Invariably it would be some combination of factories-command-strategy that missed the essential complexity of specific processing and claimed to be a faster way to project success. 

How to evaluate such claims?

Given that most of such occurrences missed the same points, I use the following line of probing when I was to approve-review the designs.

  1. How did it handle the differences? (of whatever was summarized as generic viz different formats, protocol, delivery mechanism, etc. The answer would invariably be to write code to handle it )
  2. How would it communicate the different types of errors? (many times this would be a total miss or some generic error wrapper that needs to be parsed by calling party)
  3. How did it cater to the conditions that apply to the execution flow? (it would be either missed or one need to write code or sometimes a domain-specific language ie DSL was to be used)
  4. Does it/have to maintain some sort of state or stack in order to finish the execution? (this would expose deeper design flaws )
  5. How much effort would it take to add a completely new variation of specific to this solution(again a very fair question that would test the robustness of the design)

I would specifically not ask whether such a solution exists already or can we open-sourced it. The fact you are in this situation means the point is lost. I would also not ask which all design patterns apply which when answered would offer false proof of validity. The intent was to do a fair assessment and check if the generic solution discounted the specifics.

Invariably the generic solutions had missed the complexity of the specific and claimed that because it has been wrapped -it doesn’t arise (and hence the savings ). Gradual questioning like this would uncover the effort/processing complexity. This often leads to the generic solution giving space to rightly estimated solutions that represented the real depth of the complexity.

The positive side 

But there is also a positive possibility. Sometimes there is a real fitment that exists for such adapters(a very broad range I cover with this word). An expanded version of the above questioning makes the design specifications deeper and allows the team to correct the course. The example in the above list where a DSL was proposed to handle all common tasks applicable to our problem space was indeed a good solution that offered effort saving and also empowered the developers. We must also note that in such cases the correct term would be general-purpose as opposed to generic. It conveys the trade-offs neatly and effort aspects transparently. 

In another case mentioned above, a generic webpage solution was offered. This was basically a wrapper of HTML and JS that could handle a number of UI related needs we had. One could argue (and I also had my reservations)on merits creating markup language for markup. In the era where componentized micro front ends are proving to be practical, we could have dismissed this solution. In my case, we stressed it on the team that this is not a generic solution. It was, in fact, a templatized design-solution. This made the team aware of the enormity of the claim but it also allowed the respective scrum teams to make their choice if it really fit their scenario.

In cases where I had more control over the teams, we also used all such submissions of the generic solution as a training opportunity for the architects. It would often be contrasting their work with existing tools and frameworks in the mainstream and whiteboarding on how all their solution could evolve to a professional level.

But that’s about a positive spin. The appeal of generic solutions in effort discussion has not reduced….. I hope this post helps you with that somewhat.

Categories
Software

How I build my product engineering teams

The toughest part of software development is human communication. If we group together words like specification, validation, experience, exposure so on they all represent communication.It is the centerpiece of your development procedures. If we dig deeper into these words the essence of why software development is not a fully controllable discipline like many other branches of engineering we realize that we have idea-communication problems.

When we sit together with a newly formed product development team this is the first thing I stress. It is your idea of what their idea of whats customers’ idea of the reality is. And often even our sense of reality itself is incomplete, leave alone its articulation and understanding. This realization makes our developers more humble( especially the ones with a hackrank high), the project plans realistic and the leadership vigilant. But how do you make sure that like many other mission statements postered on the wall, or at the end of email signatures or as messenger status this doesn’t become the most ignored and broken often statement. Read on.

The hard aspects of product engineering teams

Product development is hard. Hard in the sense of how some things are computationally hard. A typical services project assignment masks a lot of complexity and preparatory work from your team. The idea justification and realization might have happened already and you get a curated feature list. User experience studies; focused group discussions; technology stack debates, prototyping, sizing and many “other than programming” tasks might be hidden from you to a varying degrees. But one can always go back and read about them once the project starts.

Enter products. A commissioned software whether inhouse or outsourced might have a large exposure area, both in terms of users, features and run conditions. When you do products this happens to be your baseline case. Add to it the complexity of providing features to customers of your product customers. It changes the game from being a good housewife(or husband) to teaching people the art of courtship. In particular It :

  1. changes your requirements from a list to a range (where wise choices need to be made)
  2. Exposes you to comparison with known and unknown alternatives (some of which could even be non software !)
  3. Stretches the boundaries of user behavior – run conditions and regulations by multiple sigmas (normal distribution analogy)
  4. Forces you to design for evolution (no longer a design ideal)
  5. Challenges your notion of S/Ws purpose ( when customization needs are considered, a specialized product can easily start looking like a general-purpose of that domain ) 
  6. Slowly introduces version infidelity (a cocktail of customer pressure, delivery delays, competitive threats, and bad design can entice teams into breaking the baseline into customer-specific releases(welcome to product management, service guys ЁЯШЫ ) )

and this is not a complete list but you get the idea. And we need to keep our teams ready for this ride.How?

I do it with what I call => complexity simulation.

Complexity Simulation

The first and foremost mindset item we need to put into the product team is that “programming language, data structures, frameworks & libraries are choices and you don’t have to always make all of them”. So is architecture ( but then I need to put lots of caveats, so I skipped). Between the time I started my career in products and now; great books and talks have come on this topic. So these days I can simply ask them to read books like code complete-clean coder and likes or ask a senior member to do a session on them( these days lots of code retreats that happen, also help a lot).

The main task of complexity simulation is to give them miniaturized product assignments. The idea is to give them specification that is

  1. Not an imaginary app but represents a real-world usage scenario
  2. Loose enough to allow choices but clear in scope ( so shared learning can happen )
  3. Has at least one occurrence of each QoS [Auth, Logging, Performance and some failure scenario]
  4. Is evolutionary (Prompt for a monolith and then graduate to modular or alike)
  5. Has some arbitrary and conflicting specifications ( like demand the design to REST midway, demand configurability just before the project is to end )
  6. Encourage lots of buzz words and latest hype (and then put requirements that expose their boundaries ).

A common thread in this approach was we would always have one external person walking in on a few occasions. He would sometimes question the approach, change some requirements and make some “suggestions” with intent to disturb their rhythm.

Many times we started with one person assignments and one of the disruptions was to then merge everyone’s code into a single repo. It was fun to see how long developers struggled to agree on common structure and design(despite all the training they went through).

In some cases, we would deliberately split the work across layers or components. This was to expose them to interfacing problems and also the problems on different in speed of individual development(and what they did with it?). In some brave cases, we even suggested code/module swap to simulate take over/maintenance.

Outcomes and learnings

The learnings were immense and broad-based on both sides. It was interesting to notice that when such projects were more functional (than purely technical ones )most developers would do some sort of domain-driven structure to their module. In technology-related assignments, there would be an obsessive overdose of patterns. At times they would suggest modular deployment in the first draft and it was fun to see the reactions (and later learnings ) when I would push for a monolith for the first version. The gradual evolution of their design, later on, made a lot of them smile.

Sanctity of Interfaces would always break! most good developers applied some sort of logging say: a log4 or at minimum console logs but forget to introduce meaningful traceability. Similarly, overlapping functional requirements like 5 types of banking accounts with their own special features and 4 types of roles that can act on them with varying authorization threw a lot of theory they had read off balance(say like REST, OOAD, proto links, schemas , reuse).

We would also schedule periodic peer reviews and I would particularly probe them on places where google’s help was saught and how they fitted in.

The biggest learnings, however, came in the experiment where we asked individual repo’s to be merged into a single code base.

The team would invariably run into chaos as to whose version was better but natural leaders would emerge and finally teams would self organize. By natural I don’t mean the first vocal person to occupy the mind space(which often turned out to be bad at teamwork, mostly the people on standby emerged as leaders who would guide the team to conclusion effortlessly). Tech jargon and buzzwords caused most frictions; it was only after we introduced a few common principles and vocabulary that consensus happened. I could go on detailing various such observations and how they changed as we started getting millennials in teams. But as an objective of complexity simulations, this helped our future teams prepared for the real.

In terms of experience, these teams could be a mix of freshers to say tech lead levels. Sometimes they would be new to the technology or be trained on languages/frameworks that we used.

In my opportunities with product teams, we have done various runs of this. We built: web-based chat applications(to demo lots of protocol and design issues), stock market apps(for RWD, grids and especially the spider web of 2 way communicating components); in some scenarios wrote our own version of MapReduce and toy file-based SQL engine an ESB engine of our own. And a few more which I can’t write lest I leak some company-specific designs. 

The main outcome

One might call this exercise as training. To be fair, much of the training in s/w is focused on teaching nuances of technology or framework and can’t afford to dilute their focus with the above aspects. Nor can hackathons (which are output-oriented as opposed to our approach of increasing the depth).

The biggest and not so obvious objective of my exercises was on the team aspects. Getting help, co-operating, keeping commitments, electing leaders, asking lots of clarifications are key skills. More importantly, managing conflicts, arriving at beneficial conclusions(as opposed to consensus) or responding to later stage changes, design rework and negotiating your way out of arbitrary requirements or time pressure are hard skills.

It is (also) this complexity that needs to be stimulated to working product teams(which cant come just by agile , methodology training). Many of my experiments ran for 2-4 weeks but with more self-aware, well-read and hands-on team members joining our teams these days, we also did shorter runs or few hours a day for a month side assignment. A few cases it would be a one-person run(High potential development,you see ЁЯЩВ ) . And there was a different version of this reserved especially for tech leads and budding architects ( more on it in some other post).

The only pitfall was personal equations, hype or self-doubt could seep in silently. But these were expected. And these were my teams so we took care to confront these later on.How? In future posts …

Do tell me what do you think and your experiences as a technology leader in charge of building product engineering teams.

Categories
Software

Meet the sibling of poc, RnD claims in IT Appraisals

Once you have got past the POC claims in IT appraisals its time to meet its sibling RnD. While the POC claims are easy to handle emotionally the RnD claims might get any techies nerve :).

Research and Development shortened as RnD is probably the most important activity that corporations do. It could the hard research that is done or an innovative solution or marked improvement in service offered by what your corporation deals in. That’s about the formal definition. Much like how innovation, strategy, vision, etc are used in a very diluted fashion we have also got used to RnD as a word used in work life. The misuse of the word is hardly the problem.

RnD claims in IT appraisals are probably the largest claim that could be made for top ratings. The cases are often presented as crisis+void vs heroism as the formula. Sample the following.

  • The team was completely new to flutter development and (s)he did lots of RnD in solving the critical issues.
  • As we moved from local machines to prod (say cloud) we had many unforeseen bugs to close (!!) and (s)he did lots of RnD…

At times the claims are even sweeping …

  • Nobody in the company had worked in AR-VR or IoT or BlockChain and (s)he did lots of RnD …
  • (s)he had no background in this technology ( say a .Net person on Java project) and (s)she did lots of RnD …
  • There were many critical performance/Security/Deployment/Usability issues and (s)he did lots of RnD …

If you see the structure of these claims it follows crisis+void vs heroism. We must admit that the person in question has put in lots of effort (and must be given credit/reward for that). And that’s about a fair job done as far as performance assessment of an Individual is concerned. 

It’s the “why” of this structure that has a lot to reveal. The RnD claims made in appraisals hint at the following.

  1. The team is clueless about the technology
  2. The team was not offered adequate hands-on training  
  3. The intended structure of knowledge flow/review/mentoring is not working
  4. The estimation/Design/Team composition is not correct or clear
  5. People are clueless about the complexity that enterprise-scale or products bring in (and the discovery of them is overwhelming and someone the does the RnD)
  6. In cases where project takeover/maintenance is happening it might signal a lack of documentation of various forms.

Beyond this list, there are many people-related factors that might be at play: na├пve but disillusioned developers, a (pretending) architect in the team, a panic driven style of project management or even a deep organizational culture issue. All of these are complicated issues to solve and appraisals are not the time and place for them to be taken head-on. But if you have some influence or control on the techno-people aspect of your teams the above list has 2 good uses. 

First is, of course, we can take this line of questioning and find out the extent to which we should honor this RnD claims. The list above serves as a simple and neutral line of probing.

Secondly is this is your TODO list. In my experience as a product architect which also was an in-charge capacity, we use these claims as inputs for 

  1. Team training and Individual training ( Hands-on assignments, pairs identification, and so on)
  2. Team recompositions 
  3. Process improvements 
  4. Documentations, sample code snippets, bootstrap code projects 
  5.  and a big session of how to get help and where to reach out

This is a very broad list, in some cases where we could do deep dive into issues, we also realized that our training needed some fine-tuning. For eg. my freshers always struggle with ng-serve and exposing their apps on machine-specific IPs. In another case, few people could that fathom that their angular app and rest code can be packaged and run as single deployable (because the angular and spring boot were 2 diff training).In other cases, we realized that promises were not covered as part of training (and we needed them) and that the REST was oversold to them. But not everything can be so obvious and clear. Our rule of thumb to our team was “if you are struggling with something for more than 30 minutes please reach out to me”. In our case, I was the old man I/C of tech troubles in the team. But this 30 minutes timeout helped people a lot with burnout and avoided future RnD claims. 

The session on “How to get help and where to reach out” is obvious but not intuitive. Read on. Between the time I spent in product and services we had this new assignment of rescuing a project. Between me our PM and leads we were clear on what design we need to do and how much effort it will take. We even had a detailed plan ready but the time criticality mandated that we get it right the first time. We needed a team that was skilled with the technology and was quickly to reach out when stuck. And we changed our approach to team formation and working.

We did not take new people from a list of xls offered and then call for a “discussion”. We instead called say 50 people in batches. We gave them a very diluted version of the piece from our design and asked to code something around it. Yes, something that they could reason out. Googling was allowed and so was copy-paste. 

And then each one of us would pretend that we are secretly helping them pass the assignment and offer lots of suggestions and debate points. The focus was not on how well they could code a service or create a table-query it or write multi-threaded sorting. The focus was on to see if they got the solution construct right, could they understand when we told them to follow, the choices we prompted them to make or ignore a stackoverflow answer. The experience was enlightening.

People who did not know the technology struggled to find answers to their tasks online (in which case we would tell them to forget the task and code something and explain it(as sort of fresh start/second chance) ).People who understood technology could differentiate between applicable/relevant google /stackoverflow answers and also spot the correct but not applicable answers. People who were skilled at their craft, the ones who understood our tasks at the first sentence, then they would go to their favorite tutorial directly or could quote from a book where they saw it. All this while we were prompting them with different ideas, it was good to know that the ability to seek-receive help is a personal trait (and not related to your skill level directly).We could not only rescue the project but it also rocked (I had moved on by then time it finished). But most importantly we did not slog, no burnout and 7 years later our team members stay in touch fondly.

I am sure that these insights are not novel, there would be some study done on these aspects and a lot written. But to know that people didn’t know how to deliver code and didn’t quite get how to get help was not known as this major a problem. This also made me create a long session on “How to get help and where to reach out”. And I end my session on “if you struggle with something for 30 mins please reach out to me”.

And yes there are still many topics, techniques, and libraries where I and we as a team won’t have first-hand knowledge. We call these as exploration items in our sprints. Either experts or hands-on. The Millennials also loved this growing in into technology experience …

but none made a RnD claim and no brownie points asked for in appraisals … 

Was your appraisal experience this lucky?

Categories
Software

The PoC scam in IT appraisals

One of the responsibilities that comes your way when you are a mid-career techie is annual appraisals. Some of them are your own team members and a lot where you participate as an external voice.

Your opinion as a technical person or subject expert is valued highly when it comes to top performers.

These top performers in the list have typical attributes, they have done lots of work in the project, often they have worked long hours and done тАЬcriticalтАЭ work, won lots of тАЬappreciationтАЭ, everybody(read the booses) like them and they have done lots of PoCs!

And what about skills? you may ask. Of course, there are skilled people, the ones on the floor that you have known as good with their craft, ones whose peers go to for their opinion ( and not help, which is overloaded term for outsourcing the hard mental work under guise of help ) and ones whose code is elegant and designs thoughtful. But there are not the traits that get highlighted often.

A manager representing his cases invariably talks in terms of hard work+critical tasks+star of the team that has done the work excellently (yes there is a word like that, an adjective(that I had to swallow many times) ). One might also sprinkle innovation as an adjective, which somehow again goes back to PoCs!

But first, let’s be fair to PoCs as their rightful place in softwareтАЩs and later we can talk of their misuse in annual appraisals.

PoCs are great and helpful if they are aiming to validate (something). For example: In a mobile app in banking domain, can we skip showing real-time account balance and put Facebook like refresh button? By 2020 this technique had become mainstream but we first encountered it 5 years back it was a first-class case for a PoC on pull-based UI interactions for bank use cases. Another, more software-ly example, can we use actor patterns for fulfilling bill payments and will it spoil the user as well as IT expectations(read service guarantees). Such pointed question on will it work ? or how can we make it work ? are often a good candidate for PoC.

If the question is how will it feel, both in user experience or as a piece of running software are better-called prototypes. ( One might be keen to use MVP concept but the revenue and funding imperatives of startups are way different than typical IT setup ) .Ah yes, we can also call it as demonstration, plain and simple, without the decorative armor of тАЬconceptтАЭ.  

But all this is to redeem PoCs as a rightful technique in evolutionary software development. This is also a diluted non-exhaustive overview of PoCs. 

Back to appraisals, the list of PoCs that get listed as great points in favor of candidates goes like these. I did a POC on XML to JSON conversion in java (RIP Jackson ). I did a POC on predicting monthly account balance based on spending pattern using NumPy (regressive ! what have we proved here ? (anybody for twitter sentiment analysis (facepalm))). I did POC on ESLint in our CI-Pipeline (ah, not already using? ).

One can take something from docker, AWS, SHA 256, some spring integration scenario, message mapping, DB or Queue that is shiny new thing formulate a sentence on PoC we did.

Often these are the hands-on someone did upon which his boss is marveling and you are expected to put a stamp of approval on it. Given that its appraisal time and you are an external reviewer giving a blunt judgment might not help.

In my conversations with appraisal review committees, I used a gradual probing approach. That helps the representing manager see the real depth on the claim made and it also saves you from the potential pitfall of missing some finer point due to rushed judgment.In simple language the questioning goes like this :

1)    Is that an established fact in industry/community? (No I am not suggesting asking what is the benefit of the PoC, which is already a rehearsed narrative)

2)    Does it help other/newer team members as a reference-sample piece to use? ( in which case itтАЩs a demo piece, a respectable work but outside the greatness claim)

3)    Why did we need it to be proved? ( in case the first question is not feasible, this helps nail the motivation behind the work )

And assuming that the case presented wasnтАЩt a trivial work…

4)    What are the boundaries we have considered for this POC? ( the intention is not to ask assumptions which tend to be arbitrary, but to probe the limits chosen from available feature spectrum )

5)    What is the level of stubbing done here ( this one is a crucial criteria, often the solution which makes this far is heavily stubbed across layers and it’s not told honestly )

6)    What will it take to detail out this concept into complete version (this is the fairest chance given, a purpose and utility-driven work will give a neat list of evolutions that has to happen )

7)    Can we put it on GitHub? ( it might not a feasible but this is one shorthand question to expose petty projects, also this could be asked in any sequence(another variation: can we patent this ?) )

We could always split these lines of probe further and a better assessment of the work presented and see if it’s really something amazing that has been done or is it another case of ADD => Appraisal Driven Development.

Most often our frustration with Poc presented is not that they are some redo of well-known pattern/technique/sample repo. It is also fine and I believe its natural, for people to claim mundane as awesome which one can gently counter in appraisal discussions.

PoCs that are mentioned in IT appraisals are often a demonstration of hands-on ! which itself a such a wonderful thing in skill development that its misuse of PoC is frustrating (and hence this post ).

If you have experience with Spring or MEAN stack, where my viewpoint rests, you would identify with this feeling easily. We get team members, with a fair amount of trained freshers. They have a good general grasp of the framework, say angular or spring. But the moment you move away from mainstream coding scenarios like MVC (in respective frameworks ) the seams start to get loose (be happy if your team is better J ).

An engineered demonstration of hands-on works like wonder in such a situation (I hope your schedule/org/budget allows this, I have been lucky though ).First, it allows your team to try it first hand and be better equipped, it also helps with more reasoned discussion with talent managers with the team member choices are made.

But the real benefit is in what I call as complexity simulation. Enterprise s/w or product development is not easy of a development task to do. There are various Quality of Service criteria that apply to them. It could easily be the ability of design to evolve, the traceability requirements, cloud-native surprises, design compliance, legal requirements on privacy, security. At times one also needs to choose competing frameworks and libraries. And if you are in products we have cross-version feature movement, refactoring, tech debt payments, targeted customization, design compliance and a long list of тАЬworkтАЭ that is not obvious and throws developers and schedule off balance.

Such situations present a fantastic opportunity for the architects to give targeted demo assignments that simulate the real work complexity to the developers. One recent assignment I gave to my team was to write chat applications using Spring boot,H2 Db and Angular. Absurd? read on. The version one there were asked to keep one on one chat. Later we evolved it to one to many chats. Further, still, we made chat history to be a mandatory feature (exit H2, enter mongo or even MySQL in some cases ). And yes, all this with REST endpoints with swagger.

BY now the browser would crash so I let them put a 1-sec refresh interval. This later evolved into login тАУoauth тАУWebSockets тАУuser registration тАУdocker and so on. We could complete this exercise 3 weeks’ time.

Of course, the chat web app that everyone wrote was independent and thus was different in design and form. It wasnтАЩt production-ready. But I had a team that had a more nuanced idea of development, design, and delivery. It was a good proof of capability for a team that would go on to work on chatbot projects (yes we also added coreNLP to the equation).

After these projects or assignments are done the team members got allocated to diff projects, they do well there. And before that, I made it a point to let the new booses know the project they did the exposure they had with me/my project.

It helped them get a realistic idea of their abilities. Many of the design choices, new items, etc that they worked on in my assignments flew into the new projects without getting morphed into PoC and get claimed into appraisals. (of course, all of them had better concrete claims to make in their appraisals minus the pocs : )

Was your appraisal experience this lucky?

Categories
Uncategorized

Crucial Conversation book review

Self help books are tricky to recommend. At times they talk of something spiritual, at times they move to morals and values. Sometimes its about emotions and thinking. Sometimes its philosophy. Books that move across these planes are the ones i skip. Firstly because its very tough to trace things across such planes and then its harmful to let something in your mind unverified . Second is if the book stays in the stated plain ,you can decide if its something that sounds nice or that might be useful or at least harmless.


Personally i prefer books written by career psychologist or researchers which makes things clearer.
Crucial conversation is one such book which tells u what all u can do when opinion differ,emotions run high and stakes aren’t small. It tires to put the cause and solutions in some method which one can evaluate and then apply. That’s why i recommend it. And best part is it doesn’t talk of abstracts, the books sticks to dialogues as central theme . What keeps them going and what breaks them. That’s all. So then book wont make u different person the next day but it offers you a structure by which u can see ur complicated dialogues. But the book does something more, it also tells u that kn many situations u r co operating with whats going on in dialogue. So what is often seen has his,her,their behaviors and problems is also partly out of your own conversation pattern. The author persists with this point ,which might make sm1 uncomfortable but to me its the main reason i recommend this.

If you liked feel good by David Burns or Eric bern’s book or older Born to win book,you will like this.
What this books is not is like is, monk and Ferrari,7 rules by convey,or fucked series by Mark Manson or anything by Taleb,Galdwell or Harari.
Treat this book as the corporate trainings we get and you will thank me for the recommending this practical book.

Categories
Marathi Misc Write Ups and Downs

Marathi review: Everything is fucked by Mark Manson

Mark manson рдЖрдгрд┐ рдЧреАрддрд╛.Mark manson рд╣реНрдпрд╛рдЪреЗ рдкрд╛рд╣рд┐рд▓реЗ рдкреБрд╕реНрддрдХ рдЬрдмрд░ рд╣рд┐рдЯ рдЭрд╛рд▓реЗ. Subtle art of not giving a fuck, рдордзреНрдпреЗ рд╣рд╛ рдорд╛рдирд╡реА рдорди рдЖрдгрд┐ рдмреБрджреНрдзреА рдЕрд╕реЗ рд░реВрдв рдЕрд░реНрдерд╛рдиреЗ рдЖрдкрдг рдЬрд░ рджреНрд╡рдВрджреНрд╡ рдорд╛рдирддреЛ рддреНрдпрд╛рдмрджреНрджрд▓ рдмреЛрд▓рддреЛ. рдкреБрд╕реНрддрдХ рд░рдВрдЬрдХ рдЖрд╣реЗ,рдкреНрд░рддреНрдпреЗрдХ рдкреНрд░рдХрд░рдгрд╛рдд рддреЛ рддрд╛рдЬреЗ рд╕рдВрд╢реЛрдзрди рд╡рд╛рдкрд░реВрди рддрд╛рдг рдХрдореА-рдЖрдирдВрдж рдЕрдзрд┐рдХ рд╡рдЧреИрд░реЗ рдХрд╕реЗ рд╕рд╛рдзрд╛рдпрдЪреЗ рддреЗ рд╕рд╛рдВрдЧрддреЛ. рд╣реНрдпрд╛ рдорд╛рд░реНрдХ рдЪреЗ рд╡реИрд╢рд┐рд╖реНрдЯреНрдп рдореНрд╣рдгрдЬреЗ рддреЛ рдЖрдЬрдЪреНрдпрд╛ рдкрд┐рдвреАрд▓рд╛ рд╕рдордЬреВрди рдЖрд╣реЗ,рддреНрдпрд╛рдореБрд│реЗ рдирд┐рд╡реНрд╡рд│ рдореВрд▓реНрдп рдЖрдзрд╛рд░рд┐рдд рдЧрд╛рдкреНрдкрд╛ рдорд╛рд░рдгреНрдпрд╛ рдРрд╡рдЬреА рддреЛ рдЖрдЬрдЪреНрдпрд╛ рд▓реЛрдХрд╛рдВрдЪреНрдпрд╛ рд╕рдорд╕реНрдпрд╛рдВрдЪреЗ рдореВрд│,рдЬрд╕реЗ, entitlement/рд╣рдХреНрдХрднрд╛рд╡ рд╡рдЧреИрд░реЗ рдЧреБрдВрддрд╛ рд╕реЛрдбрд╡рддреЛ.рдЖрдгрд┐ рддреНрдпрд╛рдд рдордЧ рддреЛ рд╕реНрд╡рддрдГрд▓рд╛,рднрд╛рд╡рдирд╛ рдирд╛ -рдиреЗрдордХреЗ рдореНрд╣рдгрдЬреЗ, рдорд▓рд╛ рд╡рд╛рдЯрддреЗ рд╣реНрдпрд╛рд▓рд╛ рдлрд╛рд░ рднрд╛рд╡ рджреЗрдК рдирдпреЗ рдЕрд╕реЗ рд╕рд╛рдВрдЧрддреЛ,рдореНрд╣рдгреВрди рд╕рдЯрд▓ рдЖрд░реНрдЯ.
рд╣реНрдпрд╛рдЪрд╛ рдкреБрдврдЪрд╛ рднрд╛рдЧ рдореНрд╣рдгрдЬреЗ: рд╕рдЧрд│реЗ рдХрд╛рд╣реА рдЧрдВрдбрд▓реЗрд▓реЗ рдЖрд╣реЗ/everything is fucked рд╣реНрдпрд╛ рдкреБрд╕реНрддрдХ. рд╕рдЧрд│реЗ рд╕рд╛рдорд╛рдЬрд┐рдХ рдмрдВрдз рдлрд╕рд▓реЗрд▓реЗ рдЖрд╣реЗрдд,рдЖрдгрд┐ рдореНрд╣рдгреВрди рд▓реЛрдХрд╛рдВрдирд╛ рд╣рддрд╛рд╢-рдирд┐рд░рд╛рд╢ рд╡рд╛рдЯрддреЗ рдЖрд╣реЗ рдЕрд╕реЗ рд╣реНрдпрд╛ рдкреБрд╕реНрддрдХрд╛рдВрдЪреЗ рд╕реНрд╡рд░реВрдк. рдЖрдирдВрдж рдЖрдгрд┐ рддрд╛рдг рд╣рд╛ рд╡рд┐рд╖рдп рдЖрдзреАрдЪреНрдпрд╛ рдкреБрд╕реНрддрдХрд╛рддреВрди рдЭрд╛рд▓реЗрд▓рд╛ рдЕрд╕рд▓реНрдпрд╛рдЪреЗ рд╢рд┐рдЭреЗрдВрдорд┐рдЦрд╛рдИрд▓ рдХрд┐рдВрд╡рд╛ рдбреЗрд╡рд┐рдб рдмрд░реНрди рд╡рдЧреИрд░реЗ рдЪреНрдпрд╛ рдЧреЛрд╖реНрдЯреА рдЗрдереЗ рдпреЗрдд рдирд╛рд╣реА. рдЕрд░реНрде,рдЖрд╢рд╛ рдЖрдгрд┐ рдорд╛рдирд╡реА рдЕрд╕реНрддрд┐рддреНрд╡рд╛рдд рд╣реНрдпрд╛рдЪреЗ,рдЖрдкрд▓реНрдпрд╛рд▓рд╛ рдорд╛рд╣реАрдд рдирд╕рд▓реЗрд▓рдВ рдордзреНрдпрд╡рд░реНрддреА рд╕реНрдерд╛рди рдЕрд╕рд╛редрдореЛрдард╛ рдШрд╛рд╕ рддреЛ рдШреЗрддреЛ. рднрд╛рд╡рдиреЗрдЪреА рдЕрдерд╛рдВрдЧ рддрд╛рдХрдд рдкрдг рддрд┐рдЪреЗ рдЕрддрд┐ рдкреНрд░рд╡рд╛рд╣реА рд╕реНрд╡рд░реВрдк рдЕрд╕реЗ рд╡рд┐рд╡реЗрдЪрди 3,4 рдкреНрд░рдХрд░рдгрд╛рдд рдХрд░реВрди рддреЛ рд╡рд│рддреЛ рддреЛ рдирд┐рдЯрд╢реЗ рдХрдбреЗ! рдорд╛рдирд╡рд╛рдиреЗ рдЖрдкрд▓реА рдкреНрд░рдЧрддреА “рд╡рд┐рдЪрд╛рд░ рдкреВрд░реНрд╡рдХ” рдХреЗрд▓реЗрд▓реА рдирд╛рд╣реАрдпреЗ рддреНрдпрд╛рдореБрд│реЗ рддреЛ рд╕рдВрдкреЗрд▓ рдЕрд╕рдВ рдХрд╛рд╣реА рдирд┐рддрд╢реЗ рдореНрд╣рдгрд▓рд╛. рдЖрджреА рдорд╛рдирд╡ рддреЗ рдЖрддрд╛ рдкрд░реНрдпрдВрдд,рдЪреБрдХреАрдЪреЗ рдУ рдЕрд╕реЗрдирд╛,рдХрд╛рд╣реА рд░реАрддреА-рдорд╛рдиреНрдпрддрд╛-рдкрд╛рдпрдВрдбреЗ рд╕рдордЬрд▓рд╛ рдзрд░реВрди рдареЗрд╡рдд рд╣реЛрддреЗ,рд╡реМрдЬреНрдЮрд╛рдирд┐рдХ рдкреНрд░рдЧрддреА рд╡рдЧреИрд░реЗ рдореБрд│реЗ рддреЗ рдкрдЯрд╛рдкрдЯ рдкрдбрд╛рдпрд▓рд╛ рд▓рд╛рдЧрд▓реЗрдд рдЖрдгрд┐ рддреНрдпрд╛рдЬрд╛рдЧреА рдирд╡реАрди рд░рдЪрдирд╛ рдХрд░рд╛рдЪреЗ рдЖрдкрдг рд╡рд┐рд╕рд░рд▓реЛ/рдЖрддрд╛ рддреЗ рдЬрдордгрд╛рд░ рдирд╛рд╣реА рдЕрд╕реЗ рддреЗ рдореНрд╣рдгрддреЛ. рдкрдХреНрд╖реА рдорд╛рдирд╡рд╛рд▓рд╛ рдПрдХрддреНрд░ рдзрд░реВрди рдареЗрд╡рдгрд╛рд░рд╛ рджреЗрд╡,рд╣рд╛ рджреЗрд╡ рдЖрдкрдг рдорд╛рд░реВрди рдЯрд╛рдХрд▓рд╛ рдЖрд╣реЗ, god is dead, рдЖрдгрд┐ рддреНрдпрд╛рдЪ рдкреЛрдХрд│реАрдд рдЖрдкрдг рдХреЛрд╕рд│реВрди рдкрдбреВ/implode. рдЕрд╕рд╛ рд╕рдВрджрд░реНрдн manson рджреЗрддреЛ. рд╣реНрдпрд╛ рдорд╛рдВрдбрдгреАрдЪреЗ рдорд░реНрдпрд╛рджрд┐рдд рд╕реНрд╡рд░реВрдк рдЖрдгрд┐ рддреНрдпрд╛рддреВрди рдирд┐рдШрдгрд╛рд░ рдорд╛рд░реНрдЧ рд╣реНрдпрд╛рд╕рд╛рдареА рддреЛ рдХрд╛рдиреНрдЯ рдХрдбреЗ рд╡рд│рддреЛ ! рдорд╛рдирд╡рд╛рдЪреА рдЕрд░реНрде рд▓рд╛рд╡рд╛рдпрдЪреА рдХреНрд╖рдорддрд╛ рд╣реАрдЪ рддреНрдпрд╛рд▓рд╛ рдорд╛рдирд╡ рдмрдирд╡рддреЗ(рд╡рд┐рдЪрд╛рд░ рдХреНрд╖рдорддрд╛) рдЕрд╕реЗ рдХрд╛рдиреНрдЯ рдореНрд╣рдгрддреЛ. рддреНрдпрд╛рдореБрд│реЗ рдиреБрд╕рддрд╛ рдЙрдкрднреЛрдЧ рдЖрдгрд┐ рдкрд╢реНрдЪрд╛рддрд╛рдк рдЕрд╕реЗ рдорд╛рдирд╡рд╛рдЪреЗ рдЬрдЧ рдирд╛рдпрд╕рд▓рд╛ рдкрд╛рд╣рд┐рдЬреЗ.рддреНрдпрд╛рд╣реА рдкреБрдвреЗ, рдлрдХреНрдд рдирдлрд╛ -рдиреБрдХрд╕рд╛рди,рд╕реБрдЦ-рднреАрддреА рдЕрд╕реЗ рдЕрдЧрджреА рд╡реНрдпрд╡рд╣рд╛рд░реА рд╕реНрд╡рд░реВрдк,рддреНрдпрд╛ рддреНрдпрд╛ рд╡реЗрд│реА рдпреЛрдЧреНрдп рдЕрд╕реЗрд▓ рддрд░реА рдЙрддреНрдХреНрд░рд╛рдВрддреАрдЪреНрдпрд╛ рд╡рд┐рд░реБрджреНрдз рдЖрд╣реЗ рдЕрд╕реЗ manson рдореНрд╣рдгрддреЛ. рд╕рдордЬ рд╡рд┐рдХрд╕рд┐рдд рдЭрд╛рд▓реЗрд▓реНрдпрд╛ рдорд╛рдгрд╕рд╛рдиреЗ рд╡реНрдпрд╡рд╣рд╛рд░рд╛рдЪреНрдпрд╛ рдкрд▓реАрдХрдбреЗ рдЬрд╛рдКрди рдореВрд▓реНрдп рд╣реНрдпрд╛ рдЖрдзрд╛рд░рд╛рд╡рд░ рдЬрдЧрд╛рд╡реЗ рдЕрд╕реЗ рддреА рдореНрд╣рдгрддреЛ.рдЗрдереЗ рдХрд╛рдиреНрдЯ рд▓рд╛ рд╕реЛрдмрдд рдШреЗрдКрди рдорд╛рдирд╡рд╛рд▓рд╛ рдлрдХреНрдд рдорд╛рдгреБрд╕рдХреА рд╣реЗрдЪ рддрддреНрд╡ рдкрд░рдо рдЕрд╕рд▓реЗ рдкрд╛рд╣рд┐рдЬреЗ. рддреНрдпрд╛рдиреЗ рдорд╛рдгреВрд╕рдкрдг рдЬрдкрдд ,рд╣реНрдпрд╛ рдЬрд╛рдкрдгреНрдпрд╛рд▓рд╛ рдЖрдкрд▓реЗ рдзреНрдпреЗрдп (end as opposed to means) рдорд╛рдиреВрди рдЬрдЧрд╛рд╡реЗ рдЕрд╕реЗ рддреЛ рдорд╛рдВрдбрддреЛ. рд╣реЗ рдкреБрд╕реНрддрдХ рдмрд╣реБрддрд╛рдВрд╢ рдкрд╛рд╢реНрдЪрд╛рддреНрдп рд▓реЛрдХрд╕рд╛рдареА рдЕрд╕рд▓реНрдпрд╛рдиреЗ,рд▓реЗрдЦрдХ рдореНрд╣рдгреВрди рддреНрдпрд╛рд▓рд╛ рдЕрд╕реЗ рдЬрдЧрддрд╛ рдпреЗрддреЗ рдХрд╛ рдЖрдгрд┐ рдХрд╕реЗ рд╣реНрдпрд╛рдмрджреНрджрд▓ рдЕрдзрд┐рдХ рдмреЛрд▓рдгреЗ рднрд╛рдЧ рдЖрд╣реЗ.рд╕рд╛рдзрд╛рд░рдгрддрдГ рдЕрд╢реНрдпрд╛ рдкреБрд╕реНрддрдХрд╛рдд,рд╣реНрдпрд╛ рд╡рд│рдгрд╛рд╡рд░ рдмреБрджреНрдз рдЖрдгрд┐ рд╡рд┐рдкрд╢реНрдпрдирд╛ рд╡рдЧреИрд░реЗ рдЙрджреНрдзреГрдд рдХреЗрд▓реА рдЬрд╛рддреЗ.рдкрдг рдЧрдореНрдордд рдЭрд╛рд▓реА. рдорд╛рдирд╡реА рдкрдг рд╣реЗрдЪ рдореВрд▓реНрдп рдореНрд╣рдгреВрди рдЬрдЧрдд рд╡рд╛рдЧрд╛рд╡реЗ рдЖрдгрд┐ рддреЗ рдХрд╕реЗ рд╣реЗ рд╕рд╛рдВрдЧрддрд╛рдирд╛ рддреЛ рдЕрдВрддрд┐рдо рдирдлрд╛ рд▓рдХреНрд╖рд╛рдд рдШреЗрдК рдирдХрд╛ рдЖрдгрд┐ рдкреНрд░реЗрдпрд╕ рдЕрд╕реЗ рдореВрд▓реНрдп рдореНрд╣рдгреВрди рдорд╛рдирд╡реА рдЪрд╛рдВрдЧреБрд▓рдкрдгрд╛ рдЕрдВрдЧреАрдХрд╛рд░рд╛рдд рдЬрдЧрд╛ рдЕрд╕реЗ рд╕рд╛рдВрдЧрддреЛ. Being good for the sake of beging good without the calculation of the benefit,рдЕрд╕реЗ рдХрд╛рд╣реАрд╕реЗ рддреЛ рджреЛрди рддреАрди рдкрд╛рдирд╛рдд рдорд╛рдВрдбрддреЛ. рдирд┐рд╖реНрдХрд╛рдо рдХрд░реНрдордпреЛрдЧ,рдЗрддрдХрд╛ рджрдгрджрдгреАрдд рдПрдЦрд╛рджреНрдпрд╛ рд╣рд┐рдЯ рдкреБрд╕реНрддрдХрд╛рдд рдорд╛рдВрдбрд▓реЗрд▓рдВ рджрд┐рд╕рдд рдирд╛рд╣реА.

Image credits: mark manson’s website and wikipedia.

Categories
Marathi Misc

Marathi Satire:mumbai bullet train wins UN award

рдЬрдЧрд╛рддреАрд▓ рд╕рд░реНрд╡реЛрдЪ 6 рдмреБрд▓реЗрдЯ рдЯреНрд░реЗрди рдкреНрд░рдХрд▓реНрдкрд╛рдд рдореБрдВрдмрдИ-рдЖрдорджрд╛рд╡рд╛рдж рдмреБрд▓реЗрдЯ рдЪрд╛ рд╕рдорд╛рд╡реЗрд╢ ! рднрд╛рд░рддрд╛рдд рд╕рд░реНрд╡рддреНрд░ рдЬрд▓реНрд▓реЛрд╖!!
(UTI) рдЖрддреНрддрд╛рдЪ рдкреНрд░рд╛рдкреНрдд рдЭрд╛рд▓реЗрд▓рд╛ рд╡реГрддреНрддрд╛ рдиреБрд╕рд╛рд░, рдпреБрдирд╛рдпрдЯреЗрдб рдореЛрдирд┐рдЯрд╛рд░реА рдмрдБрдХреЗрдиреЗ рдЬрд╛рд╣реАрд░ рдХреЗрд▓реЗрд▓реНрдпрд╛ рдЬрдЧрд╛рддреАрд▓ 6 рд╕рд░реНрд╡реЛрддреНрддрдо рдмреБрд▓реЗрдЯ рдЯреНрд░реЗрди рдкреНрд░рдХрд▓реНрдкрд╛рдд рднрд╛рд░рддрд╛рддреАрд▓ рдореБрдВрдмрдИ рдмреБрд▓реЗрдЯ рдкреНрд░рдХрд▓реНрдкрд╛рдЪрд╛ рд╕рдорд╛рд╡реЗрд╢ рдЭрд╛рд▓реЗрд▓рд╛ рдЖрд╣реЗ.рдЬрдЧрд╛рддреАрд▓ рд╕рдЧрд│реНрдпрд╛ рдмреБрд▓реЗрдЯ рдЯреНрд░реЗрди рдкреНрд░рдХрд▓реНрдкрдЪреА рдпрд╛рджреА рдХрд░реВрди рдмрдБрдХреЗрдиреЗ рд╣реА рдпрд╛рджреА рдЬрд╛рд╣реАрд░ рдХреЗрд▓реЗрд▓реА рдЖрд╣реЗ.рд╣реНрдпрд╛рдкреНрд░рд╕рдВрдЧреА рдмрдБрдХреЗрдЪреЗ рдкреНрд░рдореБрдЦ рдЧреЛ рдЯреВ рдореВрди рдореНрд╣рдгрд╛рд▓реЗ “рдЬрд╛рдЧрддрд┐рдХ рдкрд╛рддрд│реАрд╡рд░ рд╡рд┐рд╡рд┐рдз рджреЗрд╢рд╛рддреАрд▓ рдмреБрд▓реЗрдЯ рдкреНрд░рдХрд▓реНрдкрд╛рдд рдЙрддреНрдХреГрд╖реНрдарддреЗрд╕рд╛рдареА рдмрдВрдзреБрднрд╛рд╡рд╛рдиреЗ рд╕реНрдкрд░реНрдзрд╛ рдирд┐рд░реНрдорд╛рдг рд╡реНрд╣рд╛рд╡реА рд╣реНрдпрд╛рд╕рд╛рдареА рдЖрдореНрд╣рд┐ рд╣реА рдпрд╛рджреА рддрдпрд╛рд░ рдХреЗрд▓реА рдЖрд╣реЗ”. рд╣реНрдпрд╛рдд рдЬрдЧрд╛рддреАрд▓ рдирд╛рд╡рд╛рдЬрд▓реЗрд▓реЗ рд╢рд┐рдВрдХрдирд╢реЗрдВрди,рдЬрд░реНрдорди рднрд╛рди,рд╢рдШрд╛рдИ рдорд╛рдЧрд▓реЗрд╡реНрд╣реА рдЗрддреНрдпрд╛рджреА рдкреНрд░рдХрд▓реНрдкрд╛рдд рднрд╛рд░рддрд╛рддреАрд▓ рдореБрдВрдмрдИ рдмреБрд▓реЗрдЯ рдкреНрд░рдХрд▓реНрдк рд╕рд╣рд╛рд╡реНрдпрд╛ рдХреНрд░рдорд╛рдВрдХрд╛рд╡рд░ рдЖрд▓реЗрд▓рд╛ рдЖрд╣реЗ.
рдмреБрд▓реЗрдЯ рдЯреНрд░реЗрдирдЪреА рдЧрддреА,рд╕реЛрдпреА рд╕реБрдзреАрд╡рд╛,рддрдВрддреНрд░рдХреМрд╢рд▓реНрдп,рд╡рдХреНрддрд╢реАрд░рдкрдгрд╛ рдЖрдгрд┐ рднрд╛рдбреЗ рдЗрддреНрдпрд╛рджреА рдирд┐рдХрд╖рд╛рдВрд╡рд░ рдЖрдзрд╛рд░рд┐рдд рдЧреБрдВрддрд╛рд▓рд┐рдХрд╛ рдмрдирд╡реВрди рд╣реА рдпрд╛рджреА рддрдпрд╛рд░ рдХреЗрд▓реА рдЖрд╣реЗ.рд╣реНрдпрд╛рдд рд╕рд░реНрд╡рд╕рдорд╛рд╡реЗрд╢рдХрддрд╛ рд╣реЗ рддрддреНрд╡ рд╡рд╛рдкрд░реВрди рдкрд╣рд┐рд▓реНрдпрд╛рдВрджрд╛рдЪрд╛ рдЧреНрд░реАрдирдлрд┐рд▓реНрдб рдореНрд╣рдгрдЬреЗ рд╣реЛрдК рдШрд╛рддрд▓реЗрд▓реЗ, рдЕрд╢реА рдПрдХ рдирд╡реАрди рд╢реНрд░реЗрдгреАрддреАрд▓, рдПрдХрдореЗрд╡ рдЬрд╛рдЧрд╛ рднрд╛рд░рддрд╛рддреАрд▓ рдореБрдВрдмрдИ рддреЗ рдЖрдорджрд╛рд╡рд╛рдж рд╣реНрдпрд╛ рд╡рд┐рдЪрд╛рд░ рдЕрдзреАрди рдкреНрд░рдХрд▓реНрдкрд╛рдиреЗ рдкрдЯрдХрд╛рд╡рд▓реА.
рддреНрдпрд╛рдореБрд│реЗ рднрд╛рд░рддрд╛рдд рд╕рд░реНрд╡рддреНрд░ рдЖрдирдВрджрд╛рдЪреЗ рд╡рд╛рддрд╛рд╡рд░рдг рдкрд╕рд░рд▓реЗ рдЖрд╣реЗ.рд╣реНрдпрд╛рдкреНрд░рд╕рдВрдЧреА рдореБрдмрдИ рдмреБрд▓реЗрдЯ рдЯреНрд░реЗрди рдЪреЗ рд╡реНрдпрд╡рд╕реНрдерд╛рдкрдХ рд╕рдЪрд┐рди рджреАрдХреНрд╖рд┐рдд рдореНрд╣рдгрд╛рд▓реЗ,рдЖрдордЪреНрдпрд╛ рдкреНрд░рдХрд▓реНрдкрд╛рдЪреЗ рд╕рджреНрдпрд╛рд╕ рдХреЗрд╡рд│ рдХреБрджрд│ рдлрд╛рд╡рдбрд╛ рдЭрд╛рд▓реЗ рдЕрд╕рд▓реЗ рддрд░реА рдПрдХрдВрджрд░реАрдд рднреБ-рд╕рдо-рдкрд╛рдВрджрдг, рдЖрдорджрд╛рд╡рд╛рдж рд╣реЗ рд╢реНрд░реАрдордВрдд рд╢рд╣рд░ рдзрд░рд╛рд╡реА рдЕрд╕рд▓реЗрд▓реНрдпрд╛ рд╢рд╣рд░рд╛рд╢реА рдЬреЛрдбрдгрд╛рдпрдЪреА рджреВрд░рджреГрд╖реНрдЯреА, рд╣реНрдпрд╛рдд рд╢реВрдиреНрдп рд╡реНрдпрд╛рдЬрд╛рд╡рд░ рдорд┐рд│рд╛рд▓реЗрд▓рдВ рдЬрдкрд╛рдиреА рдХрд░реНрдЬ рдЗрддреНрдпрд╛рджреА рдкреНрд░рд╕реНрддрд╛рд╡рд┐рдд рдмрд╛рдмреА рдЖрдордЪреНрдпрд╛ рдкрджрд░рд╛рдд рд╣рд╛ рд╕рдиреНрдорд╛рди рдкрдбрдгреНрдпрд╛рд╕ рдХрд╛рд░рдгреАрднреВрдд рдЭрд╛рд▓реНрдпрд╛.рд╕реЛрдмрдд рдореБрджреНрджрд╛рдо рдкрд░реНрдпрд╛рд╡рд░рдг рд╡рд┐рд╖рдпрдХ рдореНрд╣рдгреВрди рдЬреЗ рдХрд╛рд╣реА рдХрд▓реНрдкрдХ рдирд┐рдпреЛрдЬрди рдЖрдореНрд╣реА рдХрд░рдгрд╛рд░ рдЖрд╣реЛрдд рддреЗ рдирд┐рдпреЛрдЬрди рдмрдШреВрди рдмрдБрдХ рд╡рд┐рд╢реЗрд╖ рдЦреБрд╢ рдЭрд╛рд▓реА.рд╣реНрдпрд╛ рдмреБрд▓реЗрдЯ рдЯреНрд░реЗрдирдЪреНрдпрд╛ рдЪрд╛рдХрд╛рддреВрди рдирд┐рд░реНрдорд╛рдг рд╣реЛрдгрд╛рд░реА рдЙрд╖реНрдорд╛ рд╡рд╛рдкрд░реВрди рдЖрдореНрд╣реА рдорд╛рд░реНрдЧрд╛рддреАрд▓ рдЦрд╛рд░реЗ рдкрд╛рдгреА рдЙрдХрд│реВрди рддреНрдпрд╛рддреВрди рдореАрда рдЖрдгрд┐ рдорд┐рдирд░рд▓ рд╡рд╛рдЯрд░ рддрдпрд╛рд░ рдХрд░рдгрд╛рд░ рдЖрд╣реЛрдд.рд╕реЛрдмрдд рдорд╛рд░реНрдЧрд╛рддреАрд▓ рдореЕрдирдЧреНрд░реБрд╡ рдЪреНрдпрд╛ рдЦрд╛рд░рдлреБрдЯреАрдд рдЖрдореНрд╣реА рдХрд╛рдЬрд╡реНрдпрд╛рдВрдЪреА рд╡рд┐рд╢реЗрд╖ рд╢реЗрддреА рдХрд░рдгрд╛рд░ рдЖрд╣реЛрдд, рддреНрдпрд╛рдореБрд│реЗ рд╕рд╣реНрдпрд╛рджрд░реАрддреАрд▓ рдХрд╛рдЬрд╡реНрдпрд╛рдВрдЪреА рд╕рд╣рд▓ рдЖрдгрд┐ рддреНрдпрд╛рдореБрд│реЗ рд╣реЛрдгрд╛рд░реЗ рдирд┐рд╕рд░реНрдЧ рд╣реНрд░рд╛рд╕ рдХрдореА рд╣реЛрдИрд▓ рдЖрдгрд┐ рдкреБрдгреНрдпрд╛рддреАрд▓ рдирд┐рд╕рд░реНрдЧ рдкреНрд░реЗрдореА рдЦреБрд╢ рд╣реЛрддреАрд▓.рд╕реЛрдмрддрдЪ рдмреБрд▓реЗрдЯ рдЪреЗ рдЗрдВрдЯрд┐рд░рд┐рдпрд░ рдЖрдореНрд╣реА рд╡рд╛рд░рд▓реА рдкреЕрдЯрд░реНрди рд╡рд░ рдХрд░рдгрд╛рд░ рдЖрд╣реЛрдд.рдЧреЗрд▓реНрдпрд╛ 600 рд╡рд░реНрд╖рд╛рдд рдЖрджрд┐рд╡рд╛рд╕реАрдВрдирд╛ рдЕрд╕реЗ рддреНрд░рд┐рдмреВрдЯ рдХреБрдард▓реНрдпрд╛рд╣реА рдкреНрд░рдХрд▓реНрдкрдиреЗ рджрд┐рд▓реЗрд▓реЗ рдирд╛рд╣реА.рд╣реНрдпрд╛рдЪ рдореВрд│реЗ рдЖрдордЪрд╛ рдкреНрд░рдХрд▓реНрдк рд╣реНрдпрд╛ рдпрд╛рджреАрддреАрд▓ рд╕рд╛рд░реНрде рд╡рд┐рдЬреЗрддрд╛ рдард░рддреЛ.
рд╣реНрдпрд╛ рдШрдЯрдиреЗрд╡рд░ рдЖрдо рдЬрдирддреЗрдЪреА ,рдЖрдордЪреНрдпрд╛ рдкреНрд░рддрд┐рдирд┐рдзреАрдиреЗ рдЬреА рдкреНрд░рддрд┐рдХреНрд░рд┐рдпрд╛ рдШреЗрддрд▓реА рддреНрдпрд╛ рдкреНрд░рддрд┐рдХреНрд░рд┐рдпреЗ рдиреБрд╕рд╛рд░ рд▓реЛрдХрд╛рдВрдд рдЙрддреНрд╕рд╛рд╣рд╛рдЪреА рдПрдХ рдорд╕реНрдд рд▓рдХреЗрд░ рдкрд╕рд░рд▓реЗрд▓реА рдЖрд╣реЗ.рдЬрд╛рдЧреЛрдЬрд╛рдЧреА рдЦрд╛рджреАрдЪреЗ рдлреНрд▓реЗрдХреНрд╕ рдЙрднрд╛рд░рд▓реЗ рдЧреЗрд▓реЗ рдЖрд╣реЗрдд.рддреНрдпрд╛рдд рд╡рд┐рд╡рд┐рдз рд░рд╛рдЬрдХреАрдп рдкрдХреНрд╖ рдЖрдкрд▓реЗ рд╢реНрд░реЗрдп рдЕрдзреЛрд░реЗрдЦрд┐рдд рдХрд░реАрдд рдЖрд╣реЗрдд.рдПрдХ рдкрдХреНрд╖рд╛рдиреЗ рддрд░ рд╡рд╕рдИ-рд╡рд┐рд░рд╛рд░ рдЦрд╛рдбреАрдд рдЬрдЧрд╛рддреАрд▓ рд╕рд░реНрд╡рд╛рдд рдореЛрдард╛ рдЦрд╛рджреАрдЪрд╛ рдЦрд╛рдбреА рдлреНрд▓реЗрдХреНрд╕ рдмрдирд╡реВрди рддреНрдпрд╛рд╡рд░ “рдХрд░рд╛рдпрдЪреНрдпрд╛ рдЖрдзреАрдЪ рджрд╛рдЦрд╡реВрди рджрд┐рд▓реЗ” рдЕрд╕рд╛ рд╕рдВрджреЗрд╢ рджрд┐рд▓рд╛ рдЖрд╣реЗ.рд╣реНрдпрд╛ рдШрдЯрдиреЗрдЪреА рдкреНрд░рддрд┐рдХреНрд░рд┐рдпрд╛ рд╕рдорд╛рдЬ рдорд╛рдзреНрдпрдорд╛рдд рдЙрдордЯрд▓реА рдЕрд╕реВрди, “рдорд╛рдЭреНрдпрд╛ рд╕реНрд╡рдкреНрдирд╛рдВрдд рдмреБрд▓реЗрдЯ рдЯреНрд░реЗрдирдЪреА рд╕рдлрд░” рд╣реЗ рд╕рдЧрд│реНрдпрд╛рдд рдЯреНрд░реЗрдВрдбрд┐рдВрдЧ рдлреЙрд░рд╡рд░реНрдб рдард░рд▓реЗрд▓рдВ рдЖрд╣реЗ(рддреНрдпрд╛рд╕ рдкрдЯрдХрди рдпреБрдиреЛ рдЪрд╛ рдкреБрд░рд╕реНрдХрд╛рд░ рдорд┐рд│реЛ).
рдирд┐рд╕рд░реНрдЧ рдЬрдЧрддрд╛рдд рд╕реБрджреНрдзрд╛ рдЖрдирдВрджрд╛рдЪреЗ рд╡рд╛рддрд╛рд╡рд░рдг рдкрд╕рд░рд▓реЗрд▓рдВ рдЖрд╣реЗ.рддреНрдпрд╛рдореБрд│реЗ рдореБрдВрдмрдИрддреАрд▓ рдХреЛрд╕рд│рдзрд╛рд░ рдкрд╛рдЙрд╕ рдЖрддрд╛ рдЖрдкрд▓реА рд╕рд╛рдорд╛рдЬрд┐рдХ рдмрд╛рдВрдзрд┐рд▓рдХреА рд╕рдордЬреВрди рд╕реЛрд▓рд╛рдкреВрд░ рд▓рд╛ рд╢рд┐рдлреНрдЯ рдЭрд╛рд▓рд╛рдп рдЖрдгрд┐ рд╣реНрдпрд╛ рдШрдЯрдиреЗрд▓рд╛ рд╕реЙрд▓рд┐рдбрдпрд╛рд░реАрддреА рдореНрд╣рдгреВрди рднреБрд╕рд╛рд╡рд│ рдЪреНрдпрд╛ рд░реЗрд▓ рдкрдЯрд╛рд░реАрдВрдиреА рдкреБрдврдЪреНрдпрд╛ 24 рддрд╛рд╕рд╛рд╕рд╛рдареА рд░рд╛рдЧ (рдорд╛рд▓)рдд рдЦрдбрдЦрдбрд╛рдЯ рдХрд░рд╛рдпрдЪреЗ рдард░рд╡рд▓реЗ рдЖрд╣реЗ.рдПрдХрдВрджрд░реАрдд рд╣реА рдШрдЯрдирд╛ рднрд╛рд░рддрд╛рд╕рд╛рдареА рднреВрд╖рдг рдЖрд╣реЗ рдЕрд╕реЗ рдЖрдордЪреЗ рдорд╣рд╛рди рдиреЗрддреЗ рд░рдорддрд╛ рдЬреЛрдЧреА рдЖрдЬ рдЯреНрд╡рд┐рдЯрд░ рдХреЗ рд╕рд╛рде рдХрд╛рд░реНрдпрдХреНрд░рдорд╛рдд рдореНрд╣рдгрд╛рд▓реЗ.рдЗрддрдХреЗ рдЕрдЪреНрдЫреЗ рджрд┐рди рдЖрд▓реНрдпрд╛рдореБрд│реЗ рдорд╛рддреНрд░ рд╕рдЧрд│реЗ рд╡рд┐рд░реЛрдзреА рдкрдХреНрд╖ рд╣реЗ рдЦреВрдк рджреАрди рдЭрд╛рд▓реЗрдд рд╣реЗ рдорд╛рддреНрд░ рдирдХреНрдХреА.