Asynchronous slow life is when a concept of "time" is replaced with "creativity", "exploration", "schedule", "energy" and "debt" in context of human activities.
Читать полностью…
Centralization/decentralization cycles can also be viewed as hermeneutics, imho
Читать полностью…
Only coupling / cohesion really counts as hermeneutics, imo
Читать полностью…
https://blog.ttulka.com/how-cohesion-and-coupling-correlate/
Читать полностью…
https://koenvangilst.nl/blog/code-colocation-is-king
Читать полностью…
Probably that's strongly related to Goodhart's law
Читать полностью…
Transparent open-source culture and technical education is not about hype en masse. It only helps to pass non-intellectual barriers to modern technologies and education. It does not promise that human without engineering potential, will learn how to craft new, non-trivial programs. As this process involves not only memorizing and simple application of typical patterns.
Читать полностью…
Promotion to management (even in modern IT sector) does not depend solely on IQ. Most smart engineers stay as "tech wizards", while most managers and sales people have an average+ IQ. Maintaining power over people is not about IQ (we already see it on looming recession, degradation of products and markets, cancelling "overqualified" candidates btw). IQ is about a maximal level of abstraction that human can handle in their brain (this is correlated to spatial thinking at 80%).
Читать полностью…
rather: "people without love for the craft join the profession en masse while the best programmers get promoted out of coding"
Читать полностью…
A process of degradation of software industry:
1. IQ of average white collar man: 110. IQ of average software engineer: 120.
2. Do "reverse Flynn effect".
3. IQ of average white collar man drops to 95. IQ of average software engineer: 120.
4. Average white collar man is angry as software engineers become more autonomous than them. As engineers are smarter than them. Average manager "should be higher than them gruuuug".
5. Throw out "overqualified" engineers, force micromanagement, simplify development to only a bunch of hype frameworks and libs, simplify design and features which are suitable for monkeys with short focus and memory.
6. Average white collar man is satisfied with their power image.
When architecture of project is built on cargo cult programming patterns and temporal hacks.
Читать полностью…
I tested my audio stories generator on the Nous Hermes 10.7B model which runs locally on my CPU. And on llama.cpp server. And here are results!
The stories generator is here:
https://gitlab.com/jbyte777/storybox-generator/-/tree/with-nous-hermes-10.7b
The example of generated audio is here:
https://jumpshare.com/s/AVuVHo6DjCYBBjlDXMxZ
The Nous Hermes 10.7B model can be downloaded here:
https://huggingface.co/TheBloke/Nous-Hermes-2-SOLAR-10.7B-GGUF
The llama.cpp server can be installed from here:
https://github.com/ggerganov/llama.cpp/tree/master/examples/server
#PromptQL #texttospeech #llm #promptengineering #prompts #messageprotocol #agents
#golang #go #programming #opensource #library #indietech #programming #ai #generativeai
#blog
I think, the latter evolution is a particular case of the "cohesion"/"coupling" switch in architectural styles
Читать полностью…
https://en.wikipedia.org/wiki/Hermeneutic_circle
"mainframes" -> "personal computers" -> "cloud" -> "local-first apps" -> ... (?)
"(low coupling -> low cohesion) -> (high coupling -> high cohesion) -> (low coupling -> low cohesion) -> ..." (?)
"bunch of HTML/CSS/JS/server-side code" -> "layered monolithic web apps" -> "front-end/back-end" ->
1) "template/style/logic layers" -> "components" -> "persistent data/temporal data/use-case/view layers" -> ...
2) "monolithic layered REST APIs" -> "microservices" -> ...
https://javadevguy.wordpress.com/2019/01/06/reevaluating-the-layered-architecture/
Читать полностью…
Goodhart's law is a more fundamental relationship, probably strongly connected to overfitting from ML
Читать полностью…
https://www.warp.dev/blog/what-happens-when-you-open-a-terminal-and-enter-ls
Читать полностью…
I think, this decline can be mitigated either with (sub)ownership of software product by engineers, or with restoration of Flynn effect.
Читать полностью…
Request for development of commercial software always arises from business and sales. So it dictates in which direction it should go. If this business and sales declines in depth of their vision (which is about reverse Flynn effect), then quality of software and engineering culture degrades, and culture takes a form of hype en masse. This is how primate hierarchy works. Probably for this reason evolution of human structures and technologies is not always about continuous progress, it hits non-human resources constraints at some point.
Читать полностью…
> Managers have higher than avg iq as well
Some of them - yes. I met them. They are not like managers who I mentioned in the post.
> people without love for the craft join the profession
This is a secondary, not primary factor which is driven by the reverse Flynn effect. I think, this wouldn't be possible without restriction of development to a bunch of reinforced patterns (i.e. "cargo cult programming"). This restriction comes more from marketing and business needs with low trust to engineers. People en masse hit a plateau sticking on them, they don't accept algorithms, data structures, architectural entities etc. which fall out of their semiconscious frames. And they reinforce these patterns, sacrificing simplicity and efficiency of solution (ex. forcing RxJS single-point epic instead of simpler class for handling multiple parallel requests).
> while the best programmers get promoted out of coding
Yes. Actually best managers I met, came from programming or math background. But not vice versa. And these best managers don't rely on micromanagement technique (with exception if market around software is based on short-living cycles, and in this case software products are simpler than avg business soft), they handle asynchronous processes well. I wrote the post about the "vice versa" situation which is more common. If this "vice versa" situation happens, we have a kinda "cool guy developer" which forces coding patterns just because "sometime another cool guy read about them and they worked before (until hitting a limit when implementing new patch takes same effort as "refactoring")".
1. Work should be ecologic for humans as creative and explorative beings which live as long as they essentially can.
2. So the best code which solves a given (real or imaginary/perspective) problem, is no written code. If this solution for given problem exists.
3. Periodicity of multiple patterns/modes is a mitigation of negative effects of the Goodhart's law. "Work hard" and "follow easy path" are also patterns with limits.
4. So write less boilerplate "monkey" code, write more business-related and engineering code which provides you a recovery in future pauses.
Sometimes I also need to tweak requirements because if they were implemented naively, they would worsen a quality of feature in matured scope. For example, an additional notification for each asynchronous mutation (i.e. it's not applied immediately to affected data). However, some actions are sliced into different requests. And if you trigger "async" notification on each request, it will bloat screen with many repetitive notifications and thus worsen UX. Therefore, the best solution to balance UX, requirements, and simplicity was to include a message into some existing notifications instead of triggering a separate notification which was a default option. Though it kinda "violated" initial requirements. However, after some negotiation my balanced solution was accepted.
Without this negotiation a non-big but tricky problem would either take too many effort to resolve, or go into bloated mess of hacks which further prevents development from leveling up. Forget the "overqualified" meme, have a lead or senior engineer who has a deep understanding of project's internals
