tomyedwab

Judgement is also free, apparently. Kids these days, amirite?

YouTube is an amazing place to learn new skills and if you want to learn how professionals deploy code, a peek behind the AWS curtain can be very helpful even if it is too expensive for your toy website.

The title is misleading: the chip isn't useless, it is basically NFC and can be read just fine. The number on it can be looked up in a registry to notify the owner of a lost pet. I believe there is nothing preventing you from registering the same number with multiple registries. Hope that helps.

I find this complaint totally asinine. You can hand-craft software if you like, but cheap is what customers want and that's what they're going to get. Do you spend 10x as much for hand crafted solid wood furniture, or do you buy MDF flat pack? Most people are happy buying cheap stuff from China, and if it doesn't last as long they're happy to replace it.

Well written article full of humility and vulnerability? I love it. My reaction: you don't need to feel ashamed of not knowing something, there is far too much to know and I'm still learning new techniques and concepts 37 years in, so I would never judge you for it.

I would also not judge you for having your own preferences and opinions. I too prefer working in an office to remote work, but when I say this out loud other developers take it as advocating RTO or saying remote work is worse when it just doesn't suit my personality. I get that it's a touchy subject but there is no need to get up in my face about it.

You mention bullying and brigading and that seems to be an unfortunate reality of this industry. I suspect there is a lot of insecurity and imposter syndrome that causes people to write hyper-confident blog posts about why they are better without AI and how their tests have 100% coverage and how (unfashionable language which half the world uses) is garbage etc. Maybe if we all follow your example and be candid everyone could chill out a bit.

I'll go next: despite trying several times, I have never successfully written anything more complicated than Fibonnacci in Lisp or Haskell. I know it's clean and pure and all that, but my brain just won't work that way.

My app that I published 12 years ago is on there, hah.

Honestly, good for you. I am almost two years into my spreadsheet and I try to get in 10 minutes a day of intense exercise and half an hour or more of walking to counter sitting all day at the computer. Many people try to "get healthy" and change their entire daily routine at once and that is impossible to do while also living a normal life. It sounds like you layered in one activity at a time and each success motivated the next ambitious goal. This is a smart strategy and one I would recommend to others.

The comments on this thread are a perfect mixture of Group A, explaining how there is no value in AI tools, and if there was, where is the evidence? And Group B, who are getting value from the tools and have evidence of using them to deliver real software, but are being blasted by Group A as idiots who can't recognize bad code. Why so angry?

I've been writing code for 36 years, so I don't take any of the criticism to heart. If you know what you are doing, you can ship production quality code written by an LLM. I'm not going to label it "made by an AI!" because the consumer doesn't care so long as it works and who needs the "never AI!" backlash anyway?

But to the OP: your standards are too high. AI is like working with a bright intern, they are not going to do everything exactly the way that you prefer, but they are enthusiastic and can take direction. Choose your battles and focus on making the code maintainable in the long term, not perfect in the short term.

I do think that is a real risk, yes. I don't want to use LLMs as a crutch to guard against having to ever learn anything new, or having to implement something myself. There is such a thing as productive struggle which is a core part of learning.

That said, I think everyone can relate to wasting an awful lot of time on things that are not "interesting" from the perspective of the project you are working on. For example, I can't count the number of hours I've spent trying to get something specific to work in webpack, and there is no payoff because today the fashionable tool is vite and tomorrow it'll be something else. I still want to know my code inside and out, but writing a deploy script for it should not be something I need to spend time on. If I had a junior dev working for me for pennies a day, I would absolutely delegate that stuff to them.

That sounds more complicated than what is actually happening here. The way wave functions evolve over time, their velocity of movement is proportional to the frequency of oscillation. That is why measuring the frequency component of the wave function gives you the momentum function.

You have to keep in mind that the wave function represents the many places the particle can be with some probability, as well as the many frequencies it could have, so what uncertainty means in this case is that if you constrain the function to a small area in space (with zero probability outside it) you necessarily end up with a momentum function that spreads across many different velocities.

Re: the first point. I agree that large changes should always be broken down into individually testable pieces, however I don't agree that they can always be broken down into individually shippable pieces. This is definitely true of large refactor projects, where a simple change (like upgrading a third party library) will unavoidably trigger thousands of changes throughout the codebase. I find it easier as a reviewer to look through a bunch of TODO comments that outline what needs to be done, and then each subsequent review addresses a manageable amount of the TODOs. I really see no other way since we can't ship two copies of, say, jQuery to customers.

I totally agree with you that the architectural changes should be agreed upon in advance, with direct conversations happening and whiteboards if necessary. I tried to make it clear in the post that architecture design should happen before any coding begins, but the gap I noticed was that even with full agreement on a schema or even down to the function level, there are still important details to work out before writing logic and UI on top of it, and that requires special attention from reviewers.

Just to play devil's advocate though, if you avoid face-to-face design sessions and do everything through code reviews, you will be forced to explain your thinking in text, and the whole conversation will remain as a record for future developers getting familiar with the code who may be confused about why things were done a particular way. The code review paper trail is immensely helpful to understanding a large codebase - reading through sparse meeting notes is never as good.