I would like to strike a better balance between charging by the hour and complete fix price, especially where the work is hardly predictable up front. The problem here is a mix of trust, respect and discipline. If both parties share these values and an hour really represents useful AND needed output than the actual time spent would always be larger than the billed amount. We do have such understanding with some clients and consultants/ contractors. This works well if the work is on-off, shorter projects with people that have a long-term professional relationship. Of course, such an approach will never go down with people who have a stubborn accounting mindset.
Within the tech industry, we rely on people to think things through well. Because like with other engineered systems actually changing things later has a real cost, even though it's all an artificial, massless construct and even though we do have AI to do some of the grunt work. The problem is, we are building understanding, predictability and bigger changes tend to make some assumptions obsolete. Sometimes you don't even know which exactly, unless you have precisely engineered the change - costing thinking time that is mostly invisible, e.g. people only write down the result of the thinking or the gist of the straightened path to that result if you are lucky. Almost nobody writes down the paths not taken and the reasoning for those decisions along the way. All of this is the proof of work that's missing or that's hard to verify, if it was created honestly and not inflated artificially.
So yes, measuring work, efficiency of spending time doing work and agreeing on compensation are the hard parts, especially if we cut trust out of the equation.
By some measures, the software industry is in a state where steel production was maybe in 1880-1900. By the end of the 19. century we were quite able to produce largish steel constructions but the Siemens-Martin furnace aka Open Hearth Furnace was new https://en.wikipedia.org/wiki/Open-hearth_furnace and allowed us to produce large quantities of quality steel. At the same time the industrial processes were still quite imprecise and manual, people got hurt regularly during work. The LLMs we use today are an improvement in the process, just like the Open Hearth Furnace, but there are much quicker, more precise technologies that we don't yet know about/ don't use in the mainstream. (The electric arc furnace, electro-slag remelting, vacuum arc remelting, oxygen converter process would be equivalent advancements to the OHF for example.)
So where is the meaning in all this?
We can look at the steel making revolution and try to learn from it. Software is in most places, so is steel. In my experience a steel mill employee generally gets paid. There is the dignity in struggle, because the work tends to be demanding. Perhaps we will have machines working on the standardized components for us to put together after QA/ conformance testing to form a larger system. Maybe software engineering will really be more like work planning or a machine engineering studio. What I am confident about is that we will get more standardization and everything will get a lot more complex, yet we will have tools to cope with that.
In effect if the operating system knew about the DRAM layout, it could for instance double critical data structures and race the processing. Maybe this would be helpful in the networking areas.
On the other hand this can maybe get fixed in hardware by just copying the page that's being refreshed to the side somewhere, eliminating the whole waiting problem. Last but not least, AFAIK writes to a row already recharge the capacitors so there shouldn't be a need to refresh it. What am I missing?
To me and many other people the syntax looks like Lego but that's a taste thing and arguing about taste isn't very productive. What is more objective is that there are less syntactic patterns to care about to do at least 90% of pretty complex systems including concurrency. The rest can usually be limited to a few namespaces that are rarely touched later because they just work. Compare that with Python...
If you want to calcify something and add robustness, use clojure.spec or Malli. Clojure encourages writing testable code and also in general, there is less code to test. Smaller problem, easier to tackle well.
The JVM is a beast for serious things because of its performance and tooling. If you need something small/ with a quick start, you can use GraalVM or some of the dialects like ClojureScript or Babashka to do what needs to be done. There is ongoing work on ClojureCLR, Jank, Janet, Basilisp, Hy and other dialects or inspired languages. Usually, these are pretty close to Clojure or try to follow the behavior of Clojure so that stuff written using Clojure.core just works the same. Clojure is turning out to be the actual lingua franca.
For me, programming in Clojure is the nearest thing to fun that I ever had doing programming. To me there seems to be less ceremony about things especially on bigger projects. For the little things Babashka tends to be even more straight forward.
And yes, there are things about Clojure that can make the life harder. Usually it has to do with laziness e.g. when you just try to get a data structure written to a file. When you want to have restartable, stateful components such as database connections, web servers, etc. and want to start them in a certain order. There are some functions that are unexpectedly slow and stuff like this that could be somewhat more predictable. All this would be more approachable if there were real documents for beginners with a little more explanations than the terse descriptions that senior developers with 20+ years of experience find sufficient.
Many people assume that companies need or want global enterprise level of management of infrastructure or 24/7 support. That's simply not the case. Many small and mid-sized companies just need their applications to run. There is no CTO on the board and nobody else really cares where the stuff runs if it fits a certain budget, is available enough to not cause major disruptions and is responsive enough to not cause complaints. Some companies may care about a certain level of compliance/ security and whether their admins/ DevOps people seem to be in agony most of the time but of those there aren't many. That's also a reason why the EU introduced directives such as NIS2, DORA, CRA, CER, even the now 10 year old GDPR and more.
Most companies I have seen have never updated the BIOS of their servers, nor the firmware on their switches. Some of those have production applications on Windows XP or older and you can see VMware ESXi < 6.5 still in the wild. The same for all kinds of other systems including Oracle Linux 5.5 with some ancient Oracle DB like 10g or something, that was the case like 5 years ago but I don't think the company has migrated away completely to this day.
Any sufficiently old company will accrete systems and approaches of various vintages over time only very slowly ripping out some of those systems. Usually what happens is that parts of old systems or old workarounds will live on for decades after they have been supposedly decommissioned. I had a colleague who was using CRT monitors in 2020 with computers of similar vintage, probably with Pentium III or early Pentium IV, because he had everything set up there and it just worked for what he was doing. I don't admire it, yet that stuff works and I do respect that people don't want to replace expensive systems just because they are out of support, when they do actually work and they have people taking care of them.
I hope they expand it in such a way that anybody could uncover the ships of the Russian "shadow fleet" and put more pressure on politicians and officials. Suspicious draught or erratic position changes or incorrect data upon leaving/ entering a port would be key to detecting possible circumvention of sanctions.
If you brush for 2 minutes I can guarantee you have not cleaned your teeth properly if you have 28-32 of them, use interdental brushes (TePe, Curaprox)/ superfloss and a regular tooth brush.
If you are worried about brushing off your enamel, you should get correct tooth brushes, not use abrasive tooth pastes, not brush immediately after drinking acids as another commenter has written. Some people have soft enamel but effect of some medication/ sickness/ malnutrition during childhood but that is relatively rare. If in doubt, consult dental hygiene specialist or a dentist.
Source: My wife is an established dental hygienist keeping up with the newest approaches, going to advanced courses/ master classes, visiting conferences.
Many are just not that diligent with proper dental hygiene. Interdental brushes/ superfloss are used only occasionally if at all and not every day. There are people that brush for 2 minutes and call it a day, because they heard it's enough in some advert or because the electric toothbrush stops. Well, it turns out you need a lot longer than that and a reasonable technique if you want to keep your teeth clean and healthy.
The acidic, sugary drinks and food don't help at all. Drinking mineral water (no sugar, no extra acids) or to wash the mouth with regular water or a low concentration sodium bicarbonate / baking soda solution to balance pH after eating/ drinking something else would probably help. Of course, if not dissolved completely, the baking soda could act as an abrasive which wouldn't be that great for tooth health so probably just use regular water.
You don't need to invest much money to keep good oral health, it certainly is much cheaper to fix the problems that will arise if you don't, if they can be fixed at all. It however does cost effort/ time.
Consult a passionate dental hygienist or get a second opinion from a different dentist. Either you are doing yourself no favors by biting to push over the top and should probably get some kind of a retainer like boxers have to prevent overloading your teeth.
Or you are one of many people that have been told how great their teeth are yet which have periodontitis/ gum inlfamation. (Source: My wife is an established dental hygienist keeping up with the newest approaches, going to advanced courses, visiting conferences.) If your gums are redish instead of light pink that's a good indication. If you are bleeding on regular use of interdental brushes/ flossing that's another hint something might be off.
I would assume for certain problems LLMs have a solution readily available for JavaScript/ TypeScript or similarly popular languages but not for Clojure/Script. Therefore my thinking was that the process of getting to a workable solution would be longer and more expensive in terms of tokens. I however don't have any relevant data on this so I may just be wrong.
I have a pretty non-standard setup but with very standard tools. I didn't follow any specific guide. I have ZFS as the filesystem, for each VM a ZVOL or dataset + raw image and libvirt/ KVM on top. This can be done using e.g. Debian GNU/ Linux in a somewhat straight forward way. You can probably do something like it in WSL2 on Windows although that doesn't really sandbox stuff much or with Docker/ Podman or with VirtualBox.
If you want a dedicated virtual host, Proxmox seems to be pretty easy to install even for relative newcomers and it has a GUI that's decent for new people and seasoned admins as well.
For the remote connection I just use SSH and tmux, so I can comfortably detach and reattach without killing the tool that's running inside the terminal on the remote machine.
I hope this helps even though I didn't provide a step-by step guide.
Many people seem to be running OpenCode and similar tools on their laptop with basically no privilege separation, sandboxing, fine-grained permissions settings in the tool itself. This tendency is reflected also by how many plugins are designed, where the default assumption is the tool is running unrestricted on the computer next to some kind of IDE as many authentication callbacks go to some port on localhost and the fallback is to parse out the right parameter from the callback URL. Also for some reasons these tools tend to be relative resource hogs even when waiting for a reply from a remote provider. I mean, I am glad they exist, but it seems very rough around the edges compared to how much attention these tools get nowadays.
Please run at least a dev-container or a VM for the tools. You can use RDP/ VNC/ Spice or even just the terminal with tmux to work within the confines of the container/ machine. You can mirror some stuff into the container/ machine with SSHFS, Samba/ NFS, 9p. You can use all the traditional tools, filesystems and such for reliable snapshots. Push the results separately or don't give direct unrestricted git access to the agent.
It's not that hard. If you are super lazy, you can also pay for a VPS $5/month or something like that and run the workload there.
You would be surprised. I have unclogged processes inside and between companies before where people would tell me it's not possible or that success is unlikely.
And yes, if you are working with professionals most expenditures can be planned well in advance so you definitely can take months or even more than a year in the process. If there is a major issue affecting the business of the company you would be surprised what is possible. I've got things approved in weeks in an enterprise of 2000+ employees before and I was 5 levels down from the CEO then. I have improved my negotiation skills greatly since then (it helps when you co-found a consulting company).
You can get servers elsewhere as well and they can be more agile than Dell/ HPE/ SuperMicro/ Lenovo. Asus, Asrock, Gigabyte and some other brands can ship servers rather quickly. Perhaps not the next day but the prices are much lower out of the door especially if you are a smaller customer. Most companies know well in advance how much compute/ storage they will need. So if something takes a month or two it isn't a big issue.
For small SMBs using Proxmox is reasonably ok-ish. Running in production for 2+ years already our customers are quite happy. We also sent some patches to Proxmox for other much larger clients...
Anyone who is really committed to their infrastructure will not build it on top of highly proprietary stuff where you have 0 visibility into what's actually happening so you can only hope that somebody fixes it sustainably, in a reasonable time frame and permanently.
With open source, if you have the right people, you can find/ bisect down to the commit and function where the problem is exactly, which speeds up the remedy immensely. We have done such a thing with backup restores from the Proxmox Backup Server. The patches are now in Proxmox VE 9.0 because the low hanging fruit problem was actually with the client code not the Proxmox Backup Server.
Within the tech industry, we rely on people to think things through well. Because like with other engineered systems actually changing things later has a real cost, even though it's all an artificial, massless construct and even though we do have AI to do some of the grunt work. The problem is, we are building understanding, predictability and bigger changes tend to make some assumptions obsolete. Sometimes you don't even know which exactly, unless you have precisely engineered the change - costing thinking time that is mostly invisible, e.g. people only write down the result of the thinking or the gist of the straightened path to that result if you are lucky. Almost nobody writes down the paths not taken and the reasoning for those decisions along the way. All of this is the proof of work that's missing or that's hard to verify, if it was created honestly and not inflated artificially.
So yes, measuring work, efficiency of spending time doing work and agreeing on compensation are the hard parts, especially if we cut trust out of the equation.