Thread by Steven Hutton
- Tweet
- Jul 7, 2021
- #ComputerProgramming #Productivity
Thread
I wanna talk a bit more about @cmuratori's excellent terminal rendering demo.
www.youtube.com/watch?v=hxM8QmyZXtg&
There isn't too much too it, Muratori shows that terminal rendering can be 10-100x faster than windows terminal for outputting large files with a simple solution.
www.youtube.com/watch?v=hxM8QmyZXtg&
There isn't too much too it, Muratori shows that terminal rendering can be 10-100x faster than windows terminal for outputting large files with a simple solution.
@cmuratori Enough has been said about the approach. It's not too complicated (watch the video).
I wanna talk about the argument that the reason it's ok that windows terminal (+lots of other software) is slow is that business are focused on adding features.
I wanna talk about the argument that the reason it's ok that windows terminal (+lots of other software) is slow is that business are focused on adding features.
This has come up over and over. People are saying "Well the reason it's slow is that they're focused on dev productivity not software optimizations." Or variations thereof.
This is a CRUCIAL misunderstanding of the development process.
This is a CRUCIAL misunderstanding of the development process.
1st : Just because I can't resist being bitchy.
If these companies are so focused on development speed and delivering business value (i.e. features) quickly, why can't they do that quickly either?
2nd : Performant software isn't business value?
If these companies are so focused on development speed and delivering business value (i.e. features) quickly, why can't they do that quickly either?
2nd : Performant software isn't business value?
The fundamental misunderstanding here is that FAST software is EASIER to develop. There is no conflict between development speed and software performance. They are, in reality, mutually supportive.
There are several reasons for this:
1st. Simple code is easy to develop. It's easy to understand, change and refactor, it's easy to reuse. Simple code is also generally faster.
It certainly STAYS fast for much longer than complicated code does.
1st. Simple code is easy to develop. It's easy to understand, change and refactor, it's easy to reuse. Simple code is also generally faster.
It certainly STAYS fast for much longer than complicated code does.
This is so obvious when you think about it. It's easy to address performance issues in a simple code base because everything's easy in a simple code base.
Fixing a bug that causes a slowdown in a complicated solution is hard, CAUSING a bug in a complicated solution is easy.
Fixing a bug that causes a slowdown in a complicated solution is hard, CAUSING a bug in a complicated solution is easy.
Simpler code is generally faster code (I'm aware of the special cases - don't @ me). Simpler code is easier to develop for. If you want fast delivery of features and performance then IN BOTH CASES you want simple solutions.
2nd : FAST code is easier to develop.
It's easier to test, easier to work with, you get faster iteration times, faster feedback on your changes, you unit tests run faster so you get earlier error detection.
It's easier to test, easier to work with, you get faster iteration times, faster feedback on your changes, you unit tests run faster so you get earlier error detection.
Imagine you're a microsoft dev working on a bug with large file output in windows terminal. EVERY TIME you repro the issue, every time you make a change, every time you run the test it takes 5 minutes.
If it takes you 2 attempts to confirm the issue, 5 to locate the source of the bug, 2 runs to confirm what's happening, 10 runs to test the issue on several files and be sure it's resolved. You spent 90 MINUTES just waiting for the program to run. For one simple bug fix.
Compare to Casey's solution - 2 seconds per run. Way easier. That's just raw time, it doesn't even count the horrible effects of trying to maintain your concentration with this kind of awful feedback loop. (Trust me, it's hard).
When your code is sufficiently fast it opens so many doors for you as a developer.
If your functionality is fast you can run a complete set of tests on every local compile. If your software starts quickly enough you can update it silently on user machines without them noticing.
If your functionality is fast you can run a complete set of tests on every local compile. If your software starts quickly enough you can update it silently on user machines without them noticing.
If your software is responsive users will use features that they just won't touch if they're slow.
Fast software is just a joy to work with, we hardly even know this these days because everything is so slow.
Fast software is just a joy to work with, we hardly even know this these days because everything is so slow.
If your software is slow and laggy, it'll be annoying to use and annoying to develop. If your software is snappy and responsive it'll be a joy to use. Tools that're joyful to use are easier to develop for. When the software is good enough it hardly even feels like work.
This is a cyclical relationship. Code that's fast is easier to develop and code that is easy to develop can get and stay fast.
Performance is a feature, if you can't improve performance easily then it's likely whatever other changes you want to make will also go slowly.
Performance is a feature, if you can't improve performance easily then it's likely whatever other changes you want to make will also go slowly.
I can't understand why professional programmers are so hostile to these concepts.
Don't you want your life to be easy?
Don't you want your life to be easy?
Ok, that's it /thread.
