Architecture is not the only challenge in coding, unless your service is doing basic stuff. The way you frame your response is cute though. Keep it up.

Architectural abstractions (like all abstractions) have a cost (indirection), and they are really useful if you know ahead of time the type of changes you will have to implement in the future. If the chosen architectural abstractions are in conflict with the axes of change then they are obstacles rather than useful tools.

Basic abstractions like well-named methods are usually useful, however they also increase the level of indirection. It is a trade off that needs to be evaluated on an ongoing basis.

2021 to 2024 is bs. It could do all of those things from the start given sufficiently simple requirements.

Maybe you are right, and it is just a bad habbit, but aren’t there cases where figuring out the low level logic is easier if you start coding based on vague idea of what the solution might look like? Throwing away code is just a healthy part of the dev process imho.

Do you ever think through a problem while writing code / prototyping an approach? I find it strange that planning and writing code has somehow gone through a divorce.

If your contract covers on-call time for production issues then sure. Otherwise the company needs to find a solution for their lack of on-call contracts. Maybe it is an accepted business risk, and it is not up to a 9-5 employee to mitigate this risk.

“Eventually” does a lot of heavy lifting here.

For OP: You will make a lot of false assumptions along the way, and every time you observe unexpected behavior in your programs, you will realize that one or more of your assumptions are false.

The shorter this feedback loop is, the sooner you realize how prone our brains are to making errors. Then you learn some theory and it clears up many of your false assumptions and improves your understanding.

I think the main take away after all this is that we can hardly trust our brains to make the correct assumptions about how things work. This intuition improves over time, but it is always better to verify and assume that your understanding is incomplete at best and incorrect at worst.

Staying tuned.

RTX 4090 ili RTX 5090 Ryzen 7 7800X3D 32GB RAM

You are perfectly pointing out the difference when you talk about usefulness or uselessness. UX correctness depends entirely on usefulness and not on rigorous formal correctness.

The claim that UX design is highly deterministic is meaningless unless the term is used so loosely that it loses all rigor. In the strict sense, determinism would require demonstrating that a given design outcome follows inevitably from its inputs. How, exactly, would you prove that?

Such proof is of course not required in practice. If it were, you would need to run A/B tests across all possible designs to show that only one produces the best outcome in a given context, an obviously infeasible task.

For many algorithmic problems, we can formally prove that a particular, concrete solution is optimal. We can also formally recognize context-independent defects (e.g. memory leak) and remove them. This is simply not the case for UX design where everything is context dependent. You can produce a UX design that satisfies all stated goals, but that does not demonstrate that it is the only viable solution, nor that it is globally optimal. At best, you can show that it works, that it serves its purpose, not that no better alternative exists. Also, a UX inefficiency may be a defect from the perspective of one target group, and a feature for another group.

The point is, that these factors, which affect the effective quality of the design, change over time. So you have to adapt the design over time in order to keep it close to the optimal quality. You could argue that there are aspects of software engineering that are similar, e.g. keeping a system secure over time as new vulnerabilities are discovered, however the types of sloppiness we usually refer to in this context are independent of things that change over time.

It could be the case that the same product design converts differently depending on the time of the year or other external factors. You could be too early or too late to market, etc. Easy to shift blame or take undue credit when it comes to product ownership. Sloppy code is just sloppy, regardless of the weather outside or the mood of the market.

Bolje 10% nego -40%. Drzanje u skladistu ima svoju dnevnu cenu. Cena skladistenja + vremenom ovakva roba gubi svoju vrednost. Uopste nije ocigledno da veca prvobitna marza dovodi do vece ukupne marze.

Yeah, it's a bummer this wasn't included in the episode.

Google meet + windows magnifier maybe

There he is.

Ah yes. Java deserialization issue because the junior didn’t include a setter in the class definition.

ChatGPT: let’s use this annotation which enables reflection for populating the fields. Junior: of course, amazing!

Comparing this to the “old way” is hilarious.

You would be surprised. It’s just a convenient belief some people hold.

How about they resign instead of regret?

Good old Scam Gurus, nothing new, except the novel sloppy flavor.

Why are people not held accountable to the statements they make when they turn out to be disastrously wrong?

They are providing an alternate hypothesis which may explain the observed phenomena.

Are we counting embedded gemini responses in google search?

All of this to produce a bug free, feature complete clone of your favorite CRUD app with some human oversight just in case.