googamooga

If you are a painter, you don't need to know chemical formulas for the pigments you're using to have a direct touch to your creation.

For me, that material conciousness in computers was always in grasping the way system works holistically. To feel the system. To treat it as almost a living organism.

Fair. But I'd change a title a bit to Product Engineer or System Designer. Still a lot of engineering judgement is/will be required to deliver production-ready systems.

When you let compiler generate code for you, you're not a real programmer... That's what opcode coders was ranting in early 60s about FORTRAN programmers.

Product managers can't produce viable programs ready to be deployed in production (yet). But maybe the will able to do it in the future. We don't know how far or close this future is. But I don't think it's not a bad idea in general.

Yes, fully agree with you. Although, I read some stories that in early 60s a lot of people who used to program in opcodes (because there were no higher-level languages, even assemblers were quite new and "untested") were also struggling to accept new reality that was coming with Algol, Fortran, amd Cobol. But given that the absolute number of programmers in the world at that time was quite low nobody paid attention to their fears and pains.

To me, personally, this shift is really enabling and refreshing. I usually have lot's of ideas but did not neither time nor capacity to play with them. Some of them were just impossible to do as a team of one. Now everything is possible! :)

I started my coding apprenticeship back in early 80s with a senior programmer who taught me to code in LSI-11 processor codes. I memorized the whole table of octal processor opcodes and learned how to compose them with data to write programs on PDP-11. I was able to understand what each exact 16-bit word in my program is doing. It was a great skill. But then the same guy taught me FORTRAN 83, and I suddenly understood that writing in opcodes is not exciting anymore, because you can be 10x more productive and suffer less. Now, many years and programming languages later, with my coding skills in LSI-11 opcodes totaly athrophied, I do not regret about loosing that skill at all.

I see no reason to regret that our skills in coding C++/Java/* will decline or athrophy at some point in time. This will mean that we just don't need them anymore.

I'm currently a technical architect (individual contributor role, IC) at a large multinational financial firm in Switzerland. Previously CTO/CIO/Founder/CEO in multiple companies in multiple industries (enterprises and startups), most of them in Russia. My overall experience in tech (IT/Telecom/SW Eng) is more than 35 years.

Before I joined my current company, I have never been an IC and never stayed for more than four years with the same employer. I'm five and a half years already with my current employer and would really appreciate to continue with them further despite obviously like the OP says "my knowledge is not really valued and useful" there.

The thing is, using my accumulated versatile tech experience and good understanding of how any large enterprise works, and working in IC position, I can really bent my workload/agenda in a way that work becomes more or less fun! Not counting the Teams meetings, an unavoidable evil. :) But even them, I turn them into fun activity too, by generating nice useful minutes using transcripts "anchored" either in code or in Confluence pages (with a tool-enabled LLM). Being an individual contributor is important for this, otherwise if you even a level higher, in example, a line manager, you can't really bent your agenda much because you must care for other people and invest your time in helping them to achieve common goals.

That were my 50c. :)

I fully support this approach! When I first started experimenting—rather naively—with using tool-enabled LLMs to generate documents (such as reports or ADRs) from the extensive knowledge base in Confluence, I built a few tools to help the LLM search Confluence using CQL (Confluence Query Language) and store the retrieved pages in a dedicated folder. The LLM could then search within that folder with simple filesystem tools and pull entire files into its context as needed. The results were quite good, as long as the context didn’t become overloaded. However, when I later tried to switch to a 'Classic RAG' setup, the output quality dropped significantly and I refrained from switching.

There is a lot said about exploitation in the book and in the comments here on HN. I would like to start a kindergarten (a day care for toddlers and pre-school kids) in Switzerland, where such service is very scarce and expensive because the state does not subsidize preschool childcare. What HN community recommends me on the form of legal entity that I should use to start this venture? Options available are corporation, non-profit association or co-operative. What would be the most ethical and non-exploitative option which would work business-wise at the same time?

Not only the codebase, but also the domain, the stakeholders, the history of requirements, etc etc etc.

Thank you so much for recommending both authors! I'm a huge fan of Egan and would really appreciate to explore the Australian sci-fi scene more.

R.I.P. Niklaus Wirth. Your ideas, languages and designs were the inspiration for several generations of computer scientists and engineers. Your Lilith computer and Modula-2 language kindled a small group of students in Western Siberia’s Akademgorodok to create KRONOS - an original RISC processor-based computer, with it’s own OS and Modula-2 complier, and lots of tools. I was very lucky to join the KRONOS team in 1986 as a 16 yo complete beginner, and this changed my life forever as I become obsessed with programming. Thank you, Niklaus.