4 ms·

> I strongly believe that iteration time has a huge impact on programmer satisfaction, and Ninja is used exactly in the edit-compile loop where the difference o

> I strongly believe that iteration time has a huge impact on programmer satisfaction, and Ninja is used exactly in the edit-compile loop where the difference of 1 second and 4 seconds is critical. I think I am personally more latency-sensitive than the average programmer, but I also believe that programmers feel latency and it affects their mood even if they don't notice it. (Google has recently done some research in this area that kinda confirmed my belief, here's hoping they'll publish it publicly!) This is something to emphasize. I often feel that my productivity is strongly linked to the latency of actions I do. I like to play around a lot if the latency is low. Once it becomes higher, I generally don't do that, and in principle I often additionally think about how to work around stuff, maybe write another complexity layer on top, maybe even do less testing, etc (many of these things just unconsciously). So it does not only adds the latency time, but really makes the whole development cycle slower, and less optimal. Also I tend to get distracted more easily. When I know that the next action (compiling, startup time, whatever) takes 30-60 seconds, I will definitely not just wait, but do something in the meanwhile. But also you cannot really do something productive in that time. So I end up checking mails or HN or so. Also, since I started with my PhD, doing research on machine learning, I discovered a whole new scale of this problem, which I had not experienced before. Now the latency time has usually increased from a couple of seconds to a day, or a week. This drastically changes of how you work. To stay productive, you have to parallelize your work. When you are trying out things, you will try out many variations in parallel. Also you will look at the intermediate results, and maybe already draw conclusions from that. If there is a chance to refactor your current pipeline to reduce that iteration loop time, or the wait-time (which might be the startup time of some tool, or whatever), I think it's very worth to do it.

rjsw 6y ago
We have come full circle back to the days of batch processing and punched cards.
- mcny 6y ago
  Reminds me of this comment: https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 https://archive.fo/FEtN0 https://archive.fo/FEtN0 Oracle Database 12.2. It is close to 25 million lines of C code. What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap. Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does. Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating. The only reason why this product is still surviving and still works is due to literally millions of tests! Here is how the life of an Oracle Database developer is: - Start working on a new bug. - Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag. - Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug. - Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion. - Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete. - Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug. - Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours. - Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right. - Finally one fine day you would succeed with 0 tests failing. - Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix. - Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on. - After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch. The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication). The fact that this product even works is nothing short of a miracle! I don't work for Oracle anymore. Will never work for Oracle again!

rjsw 6y ago

We have come full circle back to the days of batch processing and punched cards.

mcny 6y ago
Reminds me of this comment: https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941 https://archive.fo/FEtN0 https://archive.fo/FEtN0 Oracle Database 12.2. It is close to 25 million lines of C code. What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap. Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does. Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating. The only reason why this product is still surviving and still works is due to literally millions of tests! Here is how the life of an Oracle Database developer is: - Start working on a new bug. - Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag. - Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug. - Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion. - Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete. - Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug. - Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours. - Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right. - Finally one fine day you would succeed with 0 tests failing. - Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix. - Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on. - After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch. The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication). The fact that this product even works is nothing short of a miracle! I don't work for Oracle anymore. Will never work for Oracle again!