Some of my best purchases were outdoor clothing I bought some 7 years ago on a whim. I constantly regret not getting some 10 of them, and sadly they don't make these anymore.
- Thermal inner pants from Berghaus
- Knitted thermal jacket from Salewa
1. I like the way sources are listed on the right panel, that makes them easily visible as i scroll through the answer.
2. The rendering of the answers using rich visual components is nice to look at. I personally hate information dense reports that ChatGPT spews, which isn't easy to consume quickly.
What I miss though is iterations on the answer, as in, how do I specifically zoom into one aspect of the answer, and then easily zoom out and continue.
Thank you! We actually support "zooming into" different parts of an answer. The chat conversation is now stored as a tree, so you can ask a followup, then revise the followup, and switch between the revisions below the answer when doing a third followup.
I could imagine that the cash cow part of a product gets all the attention in the beginning. Does that stay the same through the life cycle? Or do you see that it takes a back seat while feature development on top of that takes the center stage at alter stages of the product?
[edited to add this] I also see that it's sometimes easier to build something new, than to go on maintaining something.
Just curious to know if you see the following trend:
As a codebase matures, the amount of time spent of code maintenance increases and with bug fixes, it gets harder to spot them and the amount of code that is required to solve them is little.
Yes. We have at least one team dedicated to identifying bugs and maintaining technical quality. For example they statistically analyze our CI runs to identify regressions. They find some subtle bugs that would be difficult to identify through one's own experience.
This is a team that no one interested in their career progression should ever be on. This is usually a dead end and almost impossible to spin in behavioral interviews.
Well, not my experience at all and combining that with the link I posted, I suspect you are mistaking what I am referring to. What are you basing your statement on?
Let’s say I am interviewing two people with the same technical skills.
One says that they have spent the last couple of years fixing bugs and analyzing the CI builds. The other talks about leading major new initiatives or being responsible for a major new feature and I dig into it. Guess which one I’m going to hire?
In the terms of promo docs, which shows more “impact”, “scope” and “dealing with ambiguity”?
It sounds like you would hire the one building CRUD apps. Perhaps I was unclear in my original post, technical quality teams don’t analyze CI and fix bugs. The team in my org builds sophisticated tools to analyze CI runs and teams self service the bug fixes. When you are operating at large scale and delivering products, there is no limit to impact or scope; ambiguity is inherent.
> But I was equally surprised by how little this was being discussed, or (as far as I could tell) practiced in the real world. While there seemed to be endless threads on Twitter about server-side React (to get the UI generation closer to the data), no-one was talking about the opposite: moving the data to be closer to the UI, and onto the client!
This, I've wondered for a while. There is plenty of talk about server side rendering, which I don't think is useful for many apps out there. SSR is quite wasteful of the resources on the client side that can be made useful. And, I've seen many apps being developed with "use cliënt" littered all over, and that begs to wonder why do you even want SSR in your app.
Wasn't the reason for SSR to have more control over security and offload work from the client to the server? Let's not forget that the majority of the worlds population is using slow ass tech. We cant simply put huge workloads to the client.
I think the main drive for the modern version SSR was SEO. The workload part? the whole point of SPAs was to move compute - especially fancy UI compute down to the client so the server only had to move data... so we're just completing the circle again.
It is exactly what I am talking about. Rendering the component on the server, takes up resources, as opposed to just sending that data to the client, and the client rendering it.
In Nextjs, "use client" is used to force the rendering to take place in the client, because many components cannot me rendered in the server. For example maps. In this case, it's unnecessary to use an SSR framework.
There aren't many smart watches out there. I've loved what Garmin has done. I had always hoped something which would open up an ecosystem to build on. This looks promising on that front.
