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?
Mark manson ह्याचे पाहिले पुस्तक जबर हिट झाले. Subtle art of not giving a fuck, मध्ये हा मानवी मन आणि बुद्धी असे रूढ अर्थाने आपण जर द्वंद्व मानतो त्याबद्दल बोलतो. पुस्तक रंजक आहे,प्रत्येक प्रकरणात तो ताजे संशोधन वापरून ताण कमी-आनंद अधिक वगैरे कसे साधायचे ते सांगतो. ह्या मार्क चे वैशिष्ट्य म्हणजे तो आजच्या पिढीला समजून आहे,त्यामुळे निव्वळ मूल्य आधारित गाप्पा मारण्या ऐवजी तो आजच्या लोकांच्या समस्यांचे मूळ,जसे, entitlement/हक्कभाव वगैरे गुंता सोडवतो.आणि त्यात मग तो स्वतःला,भावना ना -नेमके म्हणजे, मला वाटते ह्याला फार भाव देऊ नये असे सांगतो,म्हणून सटल आर्ट.
1. Introduce a near native runtime : This is the applet era where the code would travel from server to client browser and a JRE plugin will serve as additional runtime .The addon runtime provided the ability to give native OS like rendering and more programmatic control over data handling .As a philosophy this continued over rewritten JFX and to some extent Flash also .The key part being browser side stepping as runtime engine .
