5 ms·

Personally I question the assumption that prototyping with bad code is faster than writing decent code. You don’t need full test coverage or deploy pipeline b

Personally I question the assumption that prototyping with bad code is faster than writing decent code. You don’t need full test coverage or deploy pipeline but I doubt that introducing constants, meaningful names, functions and other basic stuff slows down prototyping.

sdenton4 7y ago
Yeah, lots of these things are just about cultivating good habits... Once it's a habit, there's no cognitive overhead. I also tend to wonder how often research results are tainted by subtle implementation bugs that may have been more obvious with better coding habits.
Scene_Cast2 7y ago
If your prototype only has a couple of buttons (or images you can select, or whatever) - it's faster to hardcore the names and handle those cases explicitly. A good abstraction requires knowing how you'll be expanding the code (e.g. will there be more images in the future? Hundreds or billions? Or will that feature Y need to be built out?). Building that abstraction right away can definitely slow you down, as you'll be fighting it a lot of the time.
- nicoburns 7y ago
  Lack of abstraction for a one off (or two off) feature is rarely a problem. And if you need to do something 3 or more times, rhen you can probably build the abstraction pretty quickly...
seanmcdirmid 7y ago
Sure, but that isn’t nearly enough to make production worthy code. Also, naming conventions are both personal and organizational. If you are writing a prototype, you can use personally consistent standards, if you are writing production code, then you need to up that to an org standard (which you get from code review and such until it is just ingrained in your soul anyways).
- Ididntdothis 7y ago
  " but that isn’t nearly enough to make production worthy code." That's not the goal. You want code that can be refactored with reasonable effort. For example if the number 3 signifies some factor that's used several times over the the code, make it a constant with a descriptive name. This makes even the prototyping easier and whoever takes over the code has a much easier life. Or don't copy the same 5 lines all over the code with some minor changes but make it a function. This is really not hard and has huge payoff if you don't overthink it.
  - seanmcdirmid 7y ago
    Someone will surely overthink it, and everyone will always question you about where the line should be. And no, the goal isn’t always (or even often) to produce code that can be easily refactored, quite the opposite in practice. This is why having prototypes done in a separate org can be really useful (since they are writing code to serve designer needs rather than production developer needs).

sdenton4 7y ago

Yeah, lots of these things are just about cultivating good habits... Once it's a habit, there's no cognitive overhead. I also tend to wonder how often research results are tainted by subtle implementation bugs that may have been more obvious with better coding habits.

Scene_Cast2 7y ago

If your prototype only has a couple of buttons (or images you can select, or whatever) - it's faster to hardcore the names and handle those cases explicitly. A good abstraction requires knowing how you'll be expanding the code (e.g. will there be more images in the future? Hundreds or billions? Or will that feature Y need to be built out?). Building that abstraction right away can definitely slow you down, as you'll be fighting it a lot of the time.

nicoburns 7y ago
Lack of abstraction for a one off (or two off) feature is rarely a problem. And if you need to do something 3 or more times, rhen you can probably build the abstraction pretty quickly...

seanmcdirmid 7y ago

Sure, but that isn’t nearly enough to make production worthy code. Also, naming conventions are both personal and organizational. If you are writing a prototype, you can use personally consistent standards, if you are writing production code, then you need to up that to an org standard (which you get from code review and such until it is just ingrained in your soul anyways).

Ididntdothis 7y ago
" but that isn’t nearly enough to make production worthy code." That's not the goal. You want code that can be refactored with reasonable effort. For example if the number 3 signifies some factor that's used several times over the the code, make it a constant with a descriptive name. This makes even the prototyping easier and whoever takes over the code has a much easier life. Or don't copy the same 5 lines all over the code with some minor changes but make it a function. This is really not hard and has huge payoff if you don't overthink it.
- seanmcdirmid 7y ago
  Someone will surely overthink it, and everyone will always question you about where the line should be. And no, the goal isn’t always (or even often) to produce code that can be easily refactored, quite the opposite in practice. This is why having prototypes done in a separate org can be really useful (since they are writing code to serve designer needs rather than production developer needs).