Google is immensely rich from their ad business.
As long as that keeps printing money they don't really care about employees, products, development, customers or rivals.
1,196 karma · joined October 10, 2022
Senior Software Architect @ Austrian railways ÖBB
Blog: https://www.fabianzeindl.com/
The key to happiness is to accept the mixture, also accept that you sometimes rename and reorganize stuff, that that sometimes makes it better and sometimes makes it worse, and that sometimes thinking about all of this is just procrastination, but sometimes it's not!
I do think that this comes from the code base not being very good. The base layout and view classes have hundreds of thousand lines of codes, the layout algorithm is quadratic to the number of views. It was originally designed for digital cameras, not for phones. The base classes use many bit fields as well instead of enums, they don't look like Java.
Plus the strange back button concept which comes from the camera.
All this means developers waste a lot of time wrestling the framework.
While aggressively optimizing we replaced malloc in the end with a function we called "cooloc", that traded portability and security for speed. The debug tool here would have been useful.
ME: Write all your answers as concise as possible, military telegram style. GPT: Acknowledged. Will respond in concise military telegram style.
ME: Explain quantum gravity. GPT: Quantum gravity: Theory unifying general relativity and quantum mechanics. Describes gravity at smallest scales. Merges quantum field theory and gravitational force. Seeks to reconcile Einstein's relativity with quantum physics. Graviton exchange particles considered. Still under active research.
ME: Can you shorten that even more. GPT: Quantum gravity: Unifies general relativity, quantum mechanics. Explains gravity, small scales. Merges fields, reconciles relativity, quantum physics. Graviton exchange. Active research.
Or timing:
ME: What would happen if you as a AI model had timing information about how long you need to answer a question. What could you do with this meta-information?
GPT: If I, as an AI model, had access to timing information about how long I need to answer a question, it could impact my model in several ways:
[...]
Dynamic response generation: With timing information, I could dynamically adjust the response generation process based on the available time. This might involve employing strategies like progressive disclosure, where I provide an initial brief answer within a short time frame and then gradually expand on the topic if more time is available. This adaptive approach would allow me to provide relevant information within the given time constraints.Usually the individuals doing the work do understand that, but it is really hard to properly divide work and describe requirements. Why people try do divide it in even smaller tasks which increases this kind of complicated creative-writing work is beyond me.
> We realised that waterfalls that start with months of requirements capture followed by months of BDUF aren’t a great idea.
What we should have realized by now is that we never did waterfall right because it's inventor Winston Royce required it to be done TWICE for each project. Two iterations.
What this world needs is Atlassian hiring a number of work psychologists and theorists and have them streamline JIRA based on their learnings. Not in a UX "I want to create a story"-story sort of way. But in a "How do I deal with 50 tickets that are vastly different in quality?" sort of way.
They should answer questions like: "How can we make it so that the user always immediately knows whether to put this text in JIRA or confluence"?
Then Microsoft needs to hire the same people and improve text creation in outlook.
Java does, but apart from JDBC for databases, and the servlet-API, I haven't seen many cases where that really improved the world of programming. Java-EE relied heavily on such abstractions, but nowadays those would be replaced by simpler, less abstract constructs with less redirections.
> This is huge for things like database drivers which might become outdated or not support certain features. In Go switching database drivers in as simple as importing the new library. You don't have to change your code.
Database drivers are an abstraction that tends to leak it's underlying technology very fast.
The idea of just being to swap your database out under the hood is neat, but generally holds only for simple projects.
Also the abstraction that helps you here is SQL really, not the driver.
I wouldn't say dumber than humans. Actually prompt injections remind me a lot of how you can trick little children into giving up secrets. They are too easily distracted, their thought-structures are free floating and not as fortified as adults.
LLMs show childlike intelligence in this regard while being more adult in others.
Always use postgresql. It's more logical, more extensible, saner, supports many extensions and is more predictable.
MySQL is inconsistent crap, that trades away consistency, correctness and stability for a little bit of performance in standard use cases.
Do yourself a favor and always use postgreSQL. I switched 15 years ago and never looked back. Have done 15-50 projects since in psql.
Then I had it switch to various temperatures while heating and also had a geofence for my phone implemented that turned on the heating when I entered a 500m radius. Even had a calibration script for the servo motor.
He was right and still is. Not that it's impossible to implement a good PWA, all you have to do is manage your state and interface in a way that no interaction takes longer than 50ms to compute. But most developers are not able to deliver than, most don't even think about UIs in this sort of way.
And V8 GC behaviour is still terrible and an unbelievable battery hog.
Probably multiple brain-areals that work differently and in conjunction. "Left-brain" like language functions working with serial information, "right-brain" function that tend to work on images (= parallel information), combined with symbolic-logical reasoning, an extremely strong programmable aversion system (the emotion of disgust) and the tendency to be lazy = optimizing in- and output.
And using PostgREST [0] you can serve your postgreSQL database as REST-API. And if you throw foreign data wrappers / multicorn in the mix, you can map any other datasource into your postgreSQL-db as table.
> This code is in JS because it has to run in the browser, so it is not super fast.
Try profiling heap allocations in Chrome Debugger. In my experience especially array-allocation can slow down JS-code a lot.
Yes. I mentioned this is in the last section. When test-performance is alright, typically you don't need to optimize code anymore.
For me, optimizations in the "code performance" category are for example trading off a generalist API for a more complicated tweaked version that reaches into details and enables caching. The kinds of optimizations game developers do where they make the code less general and pretty, but more performant.
> OTOH, I have got a few test suites that run for 30 minutes or more, just because the search space is so big. But that's code that only needs to be tested once.
What are these suites testing?
But there's a good sentence for dealing with it, if you are envious of somebody else having something you can tell yourself: "I have something he doesn't have. I have _enough_."