3 ms·

I have to say, this is definitely not how I code. Maybe I’m in the minority, but I don’t think so

bayindirh 3y ago
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.
liampulles 3y ago
For me it took some practice, but I got there in the end. https://liampulles.com/jira-tickets.html https://liampulles.com/jira-tickets.html
- swah 3y ago
  I like your post a lot - but I wouldn't do a side project like this - seems to take a bit of the fun from coding, I guess.
  - liampulles 3y ago
    Totally fair
kkfx 3y ago
It's essentially the classic Smalltalk workstation model. End user programming, where the user live in a live easy to bend environment and just have to write few bits, some listings, to bend the desktop to it's wish. You are in a MUA composition windows and want to solve an equation? You have some bits that do so in your system, no need to switch "application", just feed the input to the relevant function and get locally the result. You just want to change something? Easy to do, it's just few bits of code. This is the most effective and powerful use of a computer we have ever invented. It was dropped because no one who works in sw business want power users and easy to bend code, it's nature is collaborative, not commercial. It's nature allow people to understand and those who became "alphabets" do not like Alphabet's or Oracle's o Meta-information business and they can perfectly goes on without them.
MarceColl 3y ago
That's fine, I was just explaining how I code and the problems with the current tools. How do you approach new problems?

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.

liampulles 3y ago

For me it took some practice, but I got there in the end. https://liampulles.com/jira-tickets.html https://liampulles.com/jira-tickets.html

swah 3y ago
I like your post a lot - but I wouldn't do a side project like this - seems to take a bit of the fun from coding, I guess.
- liampulles 3y ago
  Totally fair

kkfx 3y ago

It's essentially the classic Smalltalk workstation model. End user programming, where the user live in a live easy to bend environment and just have to write few bits, some listings, to bend the desktop to it's wish. You are in a MUA composition windows and want to solve an equation? You have some bits that do so in your system, no need to switch "application", just feed the input to the relevant function and get locally the result. You just want to change something? Easy to do, it's just few bits of code. This is the most effective and powerful use of a computer we have ever invented. It was dropped because no one who works in sw business want power users and easy to bend code, it's nature is collaborative, not commercial. It's nature allow people to understand and those who became "alphabets" do not like Alphabet's or Oracle's o Meta-information business and they can perfectly goes on without them.

MarceColl 3y ago

That's fine, I was just explaining how I code and the problems with the current tools. How do you approach new problems?