Fast
catherinejue.com
Fast
1–10 of 450 posts
Re: Fast
#2I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 minutes to do what would have taken a day", but then I thought, "maybe it was 20 minutes for 4 hours worth of work". The next day I looked at it and found the logic was convoluted, it tried to write good error handling but didn't succeed. I went back and forth and ultimately wound up recoding a lot of stuff manually. In 5 hours I had it done for real, certainly with a better test suite than I would have written on my own and probably better error handling.
See https://www.reddit.com/r/programming/comments/1lxh8ip/study_...
Re: Fast
#3> But software that's fast changes behavior.
I wonder if the author stopped to consider why these opposing points make sense, instead of ignoring one to justify the other.
My opinion is that "fast" only becomes a boon when features are robust and reliable. If you prioritize going twice as "fast" over rooting out the problems, you get problems at twice the rate too.
Re: Fast
#4> Rarely in software does anyone ask for “fast.” > But software that's fast changes behavior. I wonder if the author stopped to consider why these opposing points make sense, instead of ignoring one to justify the other. My opinion is that "fast" only becomes a boon when features are robust and reliable. If you prioritize going twice as "fast" over rooting out the problems, you get problems at twice the rate too.
Re: Fast
#5I have been asking about Latency-Free Computing for a very long time. Every Computing now is slow.
Re: Fast
#6Speed of all kinds is incredibly important. Give me all of it.
- Fast developers
- Fast test suites
- Fast feedback loops
- Fast experimentation
Someone (Napoleon?) is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own".
As long as there is some rigor and you aren't shipping complete slop, consistently moving very quickly fixes almost every other deficiency.
- It makes engineering mistakes cheaper (just fix them fast)
- It make product experimentation easy (we can test this fast and revert if needed)
- It makes developers ramp up quickly (shipping code increases confidence and knowledge)
- It actually makes rigor more feasible as the most effective rigorous processes are light weight and built-in.
Every line of code is a liability, the system that enables it to change rapidly is the asset.
Side note: every time I encounter JVM test startup lag I think someday I am going to die and will have spent time doing _this_.
Re: Fast
#7Are you kidding me? My product owner and management ask me all the time to implement features "fast".
Re: Fast
#8Re: Fast
#9Speed is what made Google, which was a consumer product at the time. (I say this because it matters more in consumer products.)
Re: Fast
#10Highly Agree. Speed of all kinds is incredibly important. Give me all of it. - Fast developers - Fast test suites - Fast feedback loops - Fast experimentation Someone (Napoleon?) is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own". As long as there is some rigor and you aren't shipping complete slop, consistently moving very quickly fixes almost every o…