Laser etching QR codes onto thin sheets of non-corroding metal or ceramics may be a lot easier to preserve and read back. Also etching the ISO/IEC 18004 standard as text/ images may be doable also. Reimplementing the needed software can be done with today's AI in a matter of a day or two. (I have actually done that over a longer period of time though.)
Look at how much the components cost 6 months ago and now. That may explain why some calculations shifted considerably. It may be an act of keeping up with the market and having some reserve.
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.
Totally, but then you probably don’t want SREs. If you’re okay with 99% availability (~7 hours of downtime a month assuming 24x7 goal), you can get by with much cheaper staffing and won’t have to deal with the turnover from SREs who get bored.
reply