3 ms·
> I think I'm not alone in this. Hopefully? No, it works in a similar way for me. I can do abstractions to a certain degree in my head and plan ahead but also
by creesch 3y ago
> I think I'm not alone in this. Hopefully?
No, it works in a similar way for me. I can do abstractions to a certain degree in my head and plan ahead but also do need to work on a problem and trial things.
It's interesting that the article mentions Javascript as not having an immediate feedback cycle. Which is true enough for a lot of the modern Javascript stack. Although live reloading is also a thing depending on what aspect you are working on.
> Imagine a service that never stops, you diff the existing functions with the new functions, only updating what needs to be updated. If there is a change in the rate of errors then you automatically rollback the deployed functions.
I am pretty sure that this is already a concept in use by companies. Although the exact naming for it, I can't remember.
It also highly depends on the sort of domain you are active in. The more critical your data is, the less likely it is that you want to risk using this type of development and testing model.
Not to mention that it seems lean in the logical fallacy of "only errors indicate faults" while the most devastating bugs often are those that don't cause clear errors. For example, when dealing with data your particular system might have no increased errors but due to a data change a system down the line might.
Another potential issue is that because you are developing this in an explorative manner, it also doesn't leave much room for a review process. Or any of the myriad of other processes and methods that normally should be in place to evaluate the thing under development.
In addition to the above, the way the article does describes the envisioned process leaves very little room for proper documentation. More specifically, it feels like a process where documentation will be more of an afterthought than it already is within many teams.
Off-topic for the subject, but using monospaced fonts for blog posts sucks for readability, imho.
- MarceColl 3y agoJavascript has decent feedback cycle, but pretty bad program state persistence as you reload things, there are some attemps and sometimes Vite is able to do it, but it's a pretty sad state of affairs in general. The end remarks are more to let the imagination run a little bit free than anything particularly structured, the part about deployment doesnt really exist as it is in most companies, there is a concept of canary deployments, blue green, etc, but not on a running process ala Erlang or Elixir. Still, Im not sure if it is even a good idea since starting from a clean slate is usually good. I need to do more testing around this. There is no interest in documentation while the process of discovering is going on, because the documentation would be stale as soon as you move on in the discovery process. Its not even a fault of the system, it just doesn't make sense. Once you find a good enough design, then you transition into settling it, documenting it, writing more thorough tests. About the review process, this is mostly targeted at individuals and teams where there is a certain trust involved. But for knowledge spread that's why I also tackle doing this collaboratively, as I think it could even increase the effectiveness of this approach. The design was pretty fast done with a template. I'll see if I have time today to test other fonts and see how it improves. Thanks for taking the time to read