HN user

supratims

4 karma

Ex Startup guy. Full stack developer.

Posts2
Comments15
View on HN

First and foremost majority of people need to agree that there is a problem and it needs solving. Most people living in urban cities are too busy to just survive and fulfil the basic needs, they dont have time to think of pollution, corruption, devolution etc , ironically so. A leading tv news host even said India is already a developed country and when he lands in Mumbai traveling back from London he feels as if he coming from a developing country to a developed country. If majority of educated city dwelling folks now feel there is no problem in India and never challenge the status quo then there is nothing to be improved. Many are happy to just live in the unliveable cities simply thinking its better than their neighbours at the very minimum. Where will the outrage come from.

Secondly, the government does its best to distract people from questioning about such basic issues. They seem to be busy capturing more power and delivering so called growth for the sake of it and very good at advertising every single thing they have done (and yes some progress has been seen in last 20 years). Ever since the current government is in power noone has been allowed to challenge any of their decisions or lack thereof. Also outrage or questioning the authorities is now seen as a anti-national sentiment.

For the longest of times contract (and perm) developers/project managers/agencies have taken a lot of liberties of time and money only to develop sub standard products and then charge more for change requests and bug fixes. The model was long due to be disrupted. This new way of vibe coding is not perfect yet but produces results and thats what the sponsors are looking at as a return on investment. As technologists we have to play a big role to find that right balance and educate everyone, not just the business folks about what could go wrong and where are the areas where it might be actually used.

In our org (large US bank) there has been a huge rollout of github copilot and adoption has been very successful. For me it became essential to learn how this can help me in day to day coding/testing/devops etc. Right now I am churning out a python code to parse a csv and create a report. I have never learnt python before.

None of the machine/platform is perfect. Some have more issues than others. My mac(s) have had issues occasionally, both hardware and of course software related. But I still prefer a Mac to a Thinkpad (my second choice). In my opinion Macbooks tend to last longer and have proved to be a lot more value for money over a long time.

For a small/startup company it is often easier if they can ask the new joinee to complete a few tasks beforehand, even before joining. Some places are keen on background checks, HR-onboarding etc before even an ID can be issued.

I was once asked by a founder to help setup mongodb and react on their laptop to get started with a hello-world application while we were sitting in a cafe. Little did I knew it was a job interview. Interesting way to identify if a person is self starter or not.

The problem with checking in so frequently is that it is still intrusive and causes distraction. Many engineers would feel the need to do just make up stuff just to show something has happened since the last update.

We work in smaller teams in a scrum like environment. Our tasks are small ranging from 2-7 days mostly. To make it easier for us developers to communicate estimations higher up, we do following :

* Split work as small as possible, and atomic so that aborting/undoing is possible if required. Like all teams we do throw away a lot of stuff. * If a task contains 5 bullets (best case), we would only give an estimate for the bullets that we know for sure can be done without further dependencies and complications. We refrain from providing an overall estimate in such cases. * We often proceed with starting a task, and as the task progresses and more clarity emerges, we revise the estimate. Importantly we are encouraged to raise flags as early as possible. * We have dev servers that we spin out frequently to stage things that are in progress to test. They may break but give us early feedback which is crucial. Sometimes helps to stop a task earlier rather than later.

Still not a perfect system, but works for us without causing too much friction.