Sachin Dixit's Blog

The 8 hour norm

It was in the 1920’s decade that Ford realized that for optimum productivity labour well being is important. That’s the beginning of an 8 hour work day.
Between 1920’s and 2020’s a lot has changed in terms of our expectations from life our social relationships and most importantly our ability to focus on this.It doesn’t need a social scientist to tell that in an environment full of notifications/distraction and huge amount of emotional overload caused by media and news consumption the 8 hour work day itself is a mirage.

The missing link

The second point a lot of us miss on the 8 hours workday movement is that it was optimal for assembly line setup. Software or creative work or sports are not really the kind of professionals where repetitive, mentally less taxing measures of work,output or productivity can apply.Its for these reasons many good companies offer recreational facilities, mediation, greenery and stuff like that at the workplaces.
Many studies done on actual productive work done by software professionals record 3 to 4 hours of meaningful work. That too happens in bursts of 40 minutes blocks.
The rest of the time is spent on animated,less brain consuming stuff.But this is also the beauty of the human brain.While we can do brain intensive work for hours together the slacks not only recharges the brain but it also fuels some creative, lateral reflection on the task at hand.So in reality the slack is feeding into the performance we do in the 3.5 hour productive zone.

Realities of a Gen Z workplace

However a lot of the above studies have become little outdated with GenZ entering workforces.Recent article on HBR type of publications are saying that GenZ’s need for direction,purpose and connection might have shifted the niddle from 3.5-4 hours to a lesser number.In post covid world,i belive even earlier generations might have slightly lesses numbers when it comes to median productive hours.

But,most of the software industry is still stuck at 8 Hours of continuous office activity as a measure of productivity (read again).The outsourcing shops add +1 hour to this . And worst still some old executives call for 70-80-90 hours work week as a regular feature of the Indian industry. Not only is this demand out of touch with research or productivity but it is also heavily out of touch with how emotional of an average indian family men and women operate.

ps: too lazy to locate and cite the source studies.Work Hours for GenZ workplace.

Give me something Quick and Dirty !?

That’s one of the most common statement that gets good engineers agitated .

It used to disturb me the most when I was a young Architect .But with experience now am able to understand the situation from where this statement originates .Once you see this it will also help you feel calm at workplace by not feeling Us vs They conflict or feeling that your craftsmanship has been questioned .

Here is where it originates

Clarity and certainty are the two most important things that Managers/Directors get asked about . The world will look like heaven if software engineers could given their managers certainty that the job will be done with quality and on what-time . And guess what , this almost doesn’t happen .

So the second thing that manager will seek is clarity . Are you past the roadblock ? what could he do to help you ? and so on. And finally it again comes down to : the next certain date of delivery.

The world of the software engineers

This is in stark contrast with the world the software engineer. To begin with there is lot of ambiguity in the requirements .It has always been there ! There is also lot of interdependency with everyone else’s work . And on top of that there are all the patterns , designs ideals and cross cutting concerns one need to take care of . This is one of the main reason we all could write solution to our LeetCode algorithm problems in a near predictable timeframe but we cant be sure of when our teams can finish the project .

The issue oftentimes is that we as software engineers are poor at communicating all these dependencies that we feel and know .Hell we even expect “them” to know it beforehand !

In great teams there are individuals or mechanisms that help developers verbalize and communicate it .But it is not so common .

What Quick and Dirty actually implies

This where the Quick and Dirty comes in ! The manager ,pushed to the walls of deadline is asking you.

1. Can you please do the most direct code to the requirements , the design ideals can be applied later .

2. Make working assumptions on the missing pieces .

3. Eliminate the dependencies on others to the maximum extent possible .

4. Look for something already available or even an alternative approach.

5. Brute force is allowed instead of elegance (for now).

6. Do not produce buggy or insecure code .

So the call for Quick and Dirty is really a call for software engineer to move from craftsman’s role to the role of savior ,communicator and negotiator (bargainer if there is a word like that ).

What has been your experience with the call to Quick and Dirty ?Did you avert the crisis ? Did you bargain of extra time to make everything proper later ?

ps: What happened to the work of Tech Managers you may ask ?that in next blog

#dotpe and Software Engineering Discipline

The issue with dotpe API

Since last few hours, dotpe ,an Indian startup catering to restaurant is in news for the funny hacks one could do in their API .I am sharing the archived sub stack article below for the details . It a fun read where a techie found out most ordered items at different branches of Social bar .He then goes on to hack the api by ordering an item on behalf of a table next to him . Read to know what items folks in India prefer with their drinks . Damn i did not know Social is so big (are they open to Private Equity :)).

image copyright Pea Bee

Why would a startup miss the basics

But the intention of the post is not the ridicule dotpe .It is clear that they missed enforcing basic authorization for their APIS .It is very unlikely that their engineers didn’t know about elementary practices on auth. The most likely it is case of features overpowering the discipline .Someone totally missed modelling the system boundary since “all the API was doing is to order food from menu” only to later realize that once you keep the gate open anything can walk in.Thats a generic take.

More specifically probably dotpe wanted customers to order food by scanning a QR code without any friction of singup. This resulted in a clientless API sans any id or possibility of auth. You can this of this as using postman . Its is very likely that someone did point it out internally but lost the argument in favour of frictionless experience given by a powerful designation.

This is also points at larger problem i.e lack of regard to the discipline of Software Engineering Indian startup industry .

The maturity deficit

As industry we don’t have a good supply people across experience levels who have built software from ground up and run it earn their salary .It is one thing to hire bright engineering’s with brilliant leetcode and MBA credentials .But brilliance is not a substitute for wisdom and having nerves .It is in such cases it is very likely that he QoS/concerns like auth-performance-maintainability-resilience or more such ability is missed .Or even if they are taken care by the developers they loose the argument in favor of “release it now” argument. This is the spectrum from skills to wisdom to nerves . And that is the craft of Software Engineering ( as opposed to just code and build).

Dotpe’s redemption

back to dotpe ,they should scrutinize their people dynamics as opposed to punish the engineer in charge .Better still they should turn this into a marketing opportunity by release monthly dotpe food trends .

Here is the whole story https://web.archive.org/web/20240923081639/https://peabee.substack.com/p/whats-inside-the-qr-code-menu-at

Value Transitions .

Every time you read about grooming teams or individuals you would hear that they need to have role clarity . A clear definition of what their new role is ,what is expected of them by A/B/C/D/E/F and G. Its a separate fact that at many places even this doesn’t happen .But people eventually figure it out ,to the best of their ability .

What they invariably fail to also realized that with each role the values they believe in also need to change. Say you are an expert developer ,who takes pride in producing “prefect” code .Now that you have grown up or the team has ; you get promoted to a Lead . How do you now extract “perfect” code from multiple people ? Sure there are reviews and test cases ,but how do you get code as perfect as you would have done ?

This is really the moment where your values are challenged. Left unchecked it can easily morph into micromanagement , playing favorites (to the geek developer just like you) or even pent of resentment (about them).

What has to really happen is that this tech lead has to know that his value has to change from being perfect to being watchful , from being particular to being mindful ,from being meticulous to being organized .

Because as the role transitions from individual to lead they levers you used to pull have changed so has the values that make you select these levers .

—

Just to be comprehensive you values would get challenged with every change i.e. role/team/project/economy/Time .

Just to be void confusion : habits are different hurdles to cross than values .Its easy to vocalized about habit but things that are part of your individual success process(ISP) are difficult to identify for the individual ,leave alone transitioning them .Values are the foundation of your ISP .

Peter principle is classic book on promotions . It says that every person rises to his level of incompetency .That is people in a hierarchical organizations keep getting promoted till they reach a level for which they are no fit/ready/skilled .

The principle and book by the same name is from the 70s .And it still holds true…

And before you think of one particular person in your hierarchy where this principle has manifested , the right question to ask is how can we ourselves escape this.

The fundamental problem problem is modern workplace is that promotion i.e rising up in the hierarchy is the only mainstream way to grow . However with each role change the skill demands change .There are organizations and individuals who are aware of this and take effort to skill people up.

At the same time there are a lot who miss the target . For a change , just ask yourself and your friends if you were told and trained about the shift needed in your role ,the last time you were promoted to Tech Lead ,Manager, Architect or whatever junior role you were promoted to 🙂 .

Another approach some companies take is that of internal startup that shakes up the culture of static-stable-hierarchical way of working towards competitive-renewal-delivery based reorganization .

There are few more variations of these things where companies essentially try to avoid power ladder , salary ladder and value ladder . All of which feed into peter principal .However avoiding these ladder is tough ask so Peter principle keeps manifesting at workplace .

Read the book ,its good .

Pair Programming with a Large Language Model .

Guess this wording settles the debate against the developers . The narrative has been set for use of LLM for productivity boosts with this phrasing !But are developers burdened with expectations or is there some hope of real usefulness to developers with the help of AI?lets check .

Using llm for coding task is expected to give huge productivity boost . Mckinsey already released a report on measuring developer productivity .Organizations like ChatGPT/OpenAI/Microsoft and the likes of meta/CodeLLma are coming up with code LLMs and numbers on productivity boost .There are new coding LLMs or LLMs with such capability coming up every week ,so this list is non exhaustive .

Paid to code or paid to recollect ?

However the question remains , can LLMs in its current form boost developer productivity across the board . The answer is no .Its only the developers who have a clear picture in mind of what they want ,can save some time with typing work with tools like copilot .

However the cognitive work for the developer now shifts towards reviewing the code generated by AI .Which is heavier mental work then writing code via learned skills .

This also raises a question of memory recall of such AI generated code at scale ! .Developers after all are not paid just to “code it” . They are valued for knowing their code , maintaining it and debugging it . Will the developers have a clear mental model of such AI generated code ? and what is the limit of such active recollections ? For now we we don’t know answers to these questions .We can take some guess from our experience with social media .This experience tells as we honestly don’t have first class recall of the virtual updates from our network when compared to actual moments spent in physical world. Even if someone argues that social media is not approached with the serious ness coding is ; the limits of our fatigued brains are known now. So I would conclude that the so called boost to developer productivity is overhyped .

The Future of coding with AI

There is however a good case of vendor curated assistants .Imagine an coding assistant from spring/java or vuejs or likes. These can help us with smarter code highlight ,offer deeper code review and provide standardized lookup code samples for developers to use. They can also have a real connection to the language runtime and offer are better suggestions on optimizations and debugging .

This is probably the less shiny ,less geeky middle path to developer productivity with the help of AI. Exactly in the spirit of Pair Programming with a Large Language Model .

(image via genecraft )