3 ms·

Same here. I can visualize what I'm trying to make pretty easily, and see the end result I want to have before even touching the keyboard in most cases. The on

Same here. I can visualize what I'm trying to make pretty easily, and see the end result I want to have before even touching the keyboard in most cases. The only time I poke and play with the code is when I'm poking hardware to understand what it's doing, IOW when I'm playing with a relatively black box.

Calavar 3y ago
My personal experience is that it depends on the context. Writing new functionality is usually easy if it's self contained. If I know what inputs I will have and what outputs I want, then I generally have a pretty solid idea of how to derive one from the other before the first keystroke. But if I find that the new functionality is turning into an internal API that will be consumed in multiple places for multiple use cases, things aren't so obvious anymore. You have a combinatorial explosion of design parameters: not just inputs, outputs, and algorithm, but also issues like ownership of data, ownership of the stack, which inputs are supplied at which point in the process, when is it legal to consume outputs and in what ways, push vs. pull interface, two functions for similar functionality vs. one with a flag. When the design parameter space gets this large, it's hard to reason about it ahead of time, and sometimes the most straightforward API doesn't reveal itself until you write code that uses it and realize that there's needless boilerplate or inconsistency that opens up room for logic errors. Then you go back and refactor to eliminate that. Casey Muratori calls this iterative process semantic compression [1]. I don't agree with all his software development takes, but I think he hits this one pretty squarely on the head. The key insight is that an experienced programmer can write good code on the first pass, but it usually takes a second pass to write great code. [1] https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015
MarceColl 3y ago
This is not for your typical glue code, or standard algorithms, this is for discovery work, novel programs, library api design, and exploring new systems and ideas. If you are able to take novel greenfield work, map it all out in your head and get to writing, good for you. But I somehow doubt it
- bayindirh 3y ago
  I do not write glue code 99% of the time, but write libraries, small tools, etc. The last time I did this, it was a completely novel framework for material simulations using boundary element method which happened to be my Ph.D. thesis. It did not completely turned out the way I wanted, but I was able to get the theoretical performance I targeted for (i.e. literally drowning the system in computation), nailed the data formats workflow we wanted to have, and it turned out to be pretty good. It can scale from laptops to high end servers, and on a typical laptop, it's 30x faster than a well tuned MATLAB implementation, while being at least as accurate. The formulae and algorithms we used for calculations were novel. It was mostly designed on paper, with some whiteboard work, and implemented with zero memory leaks along the way, plus we hit the performance numbers we were hoping in second beta IIRC. I'll shortly start on its second iteration, borrowing the high performance architecture, data types, but not the overall workflow. We'll try to make it even more user friendly. So yeah, I do this during implementing APIs, libraries and novel programs.
  - MarceColl 3y ago
    As I said, if you can do this, good for you. I'm just explaining how I need to do it. However, your whiteboard and paper is my exploratory programming. I don't see it as it being that different.
    - bayindirh 3y ago
      Honestly, you said "I doubt you do", so this is why I wrote this long answer. I just visualize the problem on paper. You have this, you want this, and to go from A to B, we need to do this, etc. Exploratory programming is nothing bad, or what I do is nothing good or exceptional. Humans' brains are wired differently, and as long as we arrive to the point we want, it's all good in my eyes. There's no superiority in any of the methods. We're just cooking the same food differently. That's all.
      - MarceColl 3y ago
        Yeah, sorry if it sounded harsh, what I meant is that I doubt someone hears of problem, gets coding immediately, and a very good result comes out. We need a way of reasoning and investigating the problem for some people is sit and think about the problem, for some people it is writing things down, and for some people is get going with exploratory programming.

Calavar 3y ago

My personal experience is that it depends on the context. Writing new functionality is usually easy if it's self contained. If I know what inputs I will have and what outputs I want, then I generally have a pretty solid idea of how to derive one from the other before the first keystroke. But if I find that the new functionality is turning into an internal API that will be consumed in multiple places for multiple use cases, things aren't so obvious anymore. You have a combinatorial explosion of design parameters: not just inputs, outputs, and algorithm, but also issues like ownership of data, ownership of the stack, which inputs are supplied at which point in the process, when is it legal to consume outputs and in what ways, push vs. pull interface, two functions for similar functionality vs. one with a flag. When the design parameter space gets this large, it's hard to reason about it ahead of time, and sometimes the most straightforward API doesn't reveal itself until you write code that uses it and realize that there's needless boilerplate or inconsistency that opens up room for logic errors. Then you go back and refactor to eliminate that. Casey Muratori calls this iterative process semantic compression [1]. I don't agree with all his software development takes, but I think he hits this one pretty squarely on the head. The key insight is that an experienced programmer can write good code on the first pass, but it usually takes a second pass to write great code. [1] https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015

MarceColl 3y ago

This is not for your typical glue code, or standard algorithms, this is for discovery work, novel programs, library api design, and exploring new systems and ideas. If you are able to take novel greenfield work, map it all out in your head and get to writing, good for you. But I somehow doubt it

bayindirh 3y ago
I do not write glue code 99% of the time, but write libraries, small tools, etc. The last time I did this, it was a completely novel framework for material simulations using boundary element method which happened to be my Ph.D. thesis. It did not completely turned out the way I wanted, but I was able to get the theoretical performance I targeted for (i.e. literally drowning the system in computation), nailed the data formats workflow we wanted to have, and it turned out to be pretty good. It can scale from laptops to high end servers, and on a typical laptop, it's 30x faster than a well tuned MATLAB implementation, while being at least as accurate. The formulae and algorithms we used for calculations were novel. It was mostly designed on paper, with some whiteboard work, and implemented with zero memory leaks along the way, plus we hit the performance numbers we were hoping in second beta IIRC. I'll shortly start on its second iteration, borrowing the high performance architecture, data types, but not the overall workflow. We'll try to make it even more user friendly. So yeah, I do this during implementing APIs, libraries and novel programs.
- MarceColl 3y ago
  As I said, if you can do this, good for you. I'm just explaining how I need to do it. However, your whiteboard and paper is my exploratory programming. I don't see it as it being that different.
  - bayindirh 3y ago
    Honestly, you said "I doubt you do", so this is why I wrote this long answer. I just visualize the problem on paper. You have this, you want this, and to go from A to B, we need to do this, etc. Exploratory programming is nothing bad, or what I do is nothing good or exceptional. Humans' brains are wired differently, and as long as we arrive to the point we want, it's all good in my eyes. There's no superiority in any of the methods. We're just cooking the same food differently. That's all.
    - MarceColl 3y ago
      Yeah, sorry if it sounded harsh, what I meant is that I doubt someone hears of problem, gets coding immediately, and a very good result comes out. We need a way of reasoning and investigating the problem for some people is sit and think about the problem, for some people it is writing things down, and for some people is get going with exploratory programming.