The reason it is easier for programmers to transform into software engineers is the same reason we are having this conversation. For the most part, I think this is because software is so cheap and accessible. Anyone can become a software artisan with just a laptop and time. For traditional engineering, you need resources.
Here's a quote from the second post:
"When it comes to things like making circuit boards, it’s pretty common for things not to work the first time. You have to do it again, and you have to send it out to the factory and do it again. You know it costs you another however many £1000 and another two weeks on the schedule. -Mike (electrical)"
If building software was expensive like engineering in the physical world, we wouldn't have to have this argument. It's too bad that physical engineering is so expensive, because we'd probably have a lot more people trying it out.
I thought I was over this argument because it always hits a dead end, but Hillel took a really entertaining approach with this series.
Looking back, I'm almost always having this argument with other software people, but never traditional engineers. I hadn't thought much about how our stereotypes are wrong.
A great example from the second post in the series is how software people don't have experience with the unpredictability of traditional engineering projects: "Part of this misconception comes from us seeing the results of the engineering process, not the process itself. We don’t see the friction, the overruns, the delays that happen because someone built the wall one inch to the left, or when a critical supplier goes out of business. To assume that software is uniquely unpredictable is a special kind of arrogance."
This has me wondering why the software world is so unpredictable in the first place and why we aren't working on that? Or at least getting better at dealing with it. Also, why are we so inclined to think the physical world is so predictable? Probably because we spend so much time on our computers...
> This has me wondering why the software world is so unpredictable in the first place… Also, why are we so inclined to think the physical world is so predictable?
Ignoring time spent designing, software's manufacturing time is essentially zero. Compare that with days/weeks for devices and years for vessels/structures. So because we're used to the latter timescale, the pace of software feels like watching a video at 100x speed.
If engineers could instantly and cheaply print each new version of the airplane or bridge they're tasked with building, they'd start looking a lot more like the software industry. When software doesn't have its rapid/free iteration superpower (as in the early days or in must-never-fail situations), it starts looking like traditional engineering.
There seem to be a lot of components like this that need to be developed.
For example, there are plenty of tools to create ML model endpoints (send data, receive prediction) but many times, those models are not customer/user facing. They will be hit by some other program/system (often on a regularly timed schedule).
One solution is to embed the model in the application that needs the predictions, but this can get hairy when it comes to updates/maintanence/etc.
Over the next few years, we will see some generalized "model invocation" components that integrate with common data sources for these use cases.
Have you shared the code or any more details for that custom search engine anywhere? I'd love to see how you did that. I'm considering doing the same thing soon
my biggest problem with this idea is that many people are already hesitant to write/post online. limiting the number of posts they are allowed to make might make their post anxiety even worse.
I'd love a high latency app as well, but there is undeniable magic in instant communication. My best writing is often when I'm "hot" on a topic and can quickly go back and forth with others on the idea. Steam could quickly run out for that type of thing without instant communication.
Say, the way some messaging platforms have threads which can branch off of the main channel. Maybe this platform has something like that, too; instantaneous and temporary, where messages disappear N minutes after they're sent. So you can post publicly on the time-delayed cadence, or chat semi-privately in realtime.
I'm not sure if that undermines the desirable properties of the time delay.
I wonder how much sense it would make for there to be some (simple) function you can tweak a number on to set a balance between the latency and lifetime of your message?
For example the lifetime of your message (counting from when it shows up) could be 2 times the latency of it, e.g. a message with a latency of 1 day would exist for 2 days.
I'm not familiar with the python ray package. If you are familiar with actors as they exist in erlang and elixir, there's a comparison of those to Pony that might help your understanding.
Turns out an easy google search answered my question as well... this post https://medium.com/distributed-computing-with-ray/ray-for-th... does say that ray uses the actor model, and ray is listed on The Actor Model wikipedia page as an Actor Model library.
