41–50 of 128 posts
Here's a priority list that you should typically follow for making anything. 1. Make it work. 2. Make it not break. 3. Make it fast. That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.
1. Make it work.
2. Make it right.
3. Make it fast.
> When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the be…
I have a simple mantra that helps me remember this. "Its clay, not stone".
Earlier quoted context omitted.
Depends on your industry and where you work obviously. But I have a strict "that will do" policy. If it looks like it might work, that will do. It won't' be well engineered, it will be buggy. But the project will be completed and released. If it makes some sales and looks like it has some traction, then I go back and visit the many (many) //todo - clean this up and refactor everything out. Usually after a while of ad…
I agree with this philosophy as well. If is a project or program that will be worked on more as time progresses, typically it refactors itself after the programmer has a better grasp of the big picture. Often the bigger picture can only be grasped after there is some momentum with the project. I'd say this works 90% of the time, where the other 10% needs more upfront design and research done before any real work is s…
If the prototype is quickly made, it could even count as part of that upfront design process.
Earlier quoted context omitted.
I've been just like this - without the context of a problem to solve, theoretical things just don't click for me. Regex was a mystery and impossible to memorize until I had to write a matcher for a class, and I haven't forgotten since. Similarly, I never get stuck at work, because everything I learn has a problem behind it, but as soon as I go home and try to teach myself something for fun I derp out immediately.
Why not integrate new things to learn with a fun side project?
> When I try to build something new, I find myself instantly criticizing my technique, to the point of paralysis. This function is hard to test; this object's dependencies need to be injected rather than initialized internally; that module needs an integration test; and so on and so forth. Even when writing spike or proof of concept code, I find myself revisiting the same lines over and over again, looking for the be…
Well-stated -- and (at the risk of over-complimenting), very close to the absolute zen of self-driven learning.
"He who rests while other people work with their heads, hands, and hearts is a capitalist".
Here's a priority list that you should typically follow for making anything. 1. Make it work. 2. Make it not break. 3. Make it fast. That's it really. Until the performance of something is blocking what you need to do somewhere else leave it the hell alone.
The world doesn't need more crummy unusable software.
Earlier quoted context omitted.
I agree with this philosophy as well. If is a project or program that will be worked on more as time progresses, typically it refactors itself after the programmer has a better grasp of the big picture. Often the bigger picture can only be grasped after there is some momentum with the project. I'd say this works 90% of the time, where the other 10% needs more upfront design and research done before any real work is s…
It's rapid prototyping. It might just happen that the prototype is good enough to sell, but once you have a basis, comparisons can begin. If the prototype doesn't have to act as the real product, just a skeleton, it's not so hard to change the "bones" if something isn't working properly. If the prototype is quickly made, it could even count as part of that upfront design process.