HN user

byebyetech

479 karma
Posts14
Comments104
View on HN

I don't know how they are measuring productivity. For me it is insane productivity boost.

Here is how I use it:

1. Investigate issue in the codebase

2. Write unit tests.

3. Quick experiments.

4. Help with terminal commands and one off scripts.

5. Boilerplate code.

6. Work at higher level than language syntax.

7. Avoid wasting time looking for solution on the internet.

You need to take a trip to your home country and see conditions of poor people there. You are basically mocking them when you say you are a slave who makes $500k/year. Most people in your home country can't even imagine to make that much in their 10 lifetimes. Have some perspective dude.

Supply of doctors is definitely an important issue. But prices are high not because they can't find doctors. It is high because they have no real competition. When someone is suffering from a heart attack what options do they have than to go to the nearest hospital? Even in non-emergency situations people chose to go to the healthcare provider nearest to them. Also even if we assume people magically able to chose any healthcare provider in the country by teleporting themselves. On what basis they are going to make decision? Prices of healthcare services are opaque and almost secret until they surprise you with 6 figure bill.

That is why i laugh at republicans (Ben Shapiro et al) argument that healthcare competition is what making it the "best" in the world. Don't compare it with restaurant business.

The most important thing product people need to understand is to not treat engineers as mindless robotic resource that you can deploy on any problem and get the output of Code. Engineers are human beings so it makes sense to create environment in which they can do their best. There are human universals like feeling of belonging, job satisfaction, flow, low stress, less chaos, appreciation that can improve team productivity. Wish there was a way to track it in a quantifiable way.

I think technical debt should be called "management debt" because management is the primary source of such debts. Technical debt implies it something engineers forgot to do or were just lazy to do it. While it maybe the case in some places , mostly its Agile/Project planning that lacks any appropriate place for fixing technical debt and refactoring.