justbees

I think this is the strongest quote in the article

> The main issue was that businesses invented solutions in search of problems that people never had, rather than finding ways to improve customers’ experiences.

There's always room for finding solutions to problems people didn't _know_ that they had. This is just inventing or misinterpreting problems to try and get rid of employees.

I include a rule in the initial PR prep that it runs. So there's a hard limit to the length of the comments and what type of comments it can write and they get flagged in the review. It also reads the comments and checks for consistency with the following code so they don't drift. And the reviewer is a completely different agent/different model.

So all of that happens before the manual review and usually catches a lot of the 3-5 line comments it inevitably adds.

That's so interesting to me! I actually have a terrible memory for events and names so my answer is almost always - sort of. So I can visualize an apple, but if you say - remember that time we went apple picking with Greg? I might only vaguely remember that, and not know who Greg is. But, if you showed me a picture of Greg I would probably say - oh that's that guy we went apple picking with. Why did we do that?

My mom has aphantasia and we were both shocked to discover it even exists.

She saw something about it online and then started asking everyone in the family if they could picture an apple in their mind. We all said - yes of course, what are you talking about?

And she said, "When you say the word apple, I think of the concept of an apple. It's juicy. It's crisp. It's red, etc, but I don't SEE an apple. I just know what it is."

She had no concept that other people literally saw the apple and I had no concept that people couldn't see the apple.

I asked her what she thought the phrase "in your minds eye" meant for her entire life and she said she thought it just meant exactly what she was describing and not literally seeing anything...

I lived in an apt in Brooklyn for 5 years, a brownstone built in 1931, and I never saw a single roach (they also never raised the rent).

1. we kept it very clean 2. the owners/landlords lived in the building with their children

Thank you "Monika landlord"! (that's how she signed the Christmas cards she would give us - yes, I know how lucky we got)

I've been doing the same thing lately and I definitely feel like stubbing out the high level architecture at the beginning makes a difference. The codebase I'm in now has very particular ways of doing things and claude doesn't always pick that up.

Style can be as important as substance.

I still do a lot of back and forth about the plan - have it written to a file. Read through the file, make changes by hand and have claude read my changes and on and on. But starting with the basic architecture there's less ambiguity.

There's a DVD box set that has almost all of the original music!

Evidently it's from a true story. Luckily not actually thrown from a helicopter!

https://classictvhistory.wordpress.com/2012/11/21/turkeys-aw...

CLARKE BROWN: The turkey drop was actually a real incident. ... Although the turkeys were thrown off the back of a truck, as opposed to how it was depicted on the [show].

like wet sacks of cement...

I actually ended up with pdf because I could brand it and my parents (who are in their 70s) understood it better than seeing a CSV. That was REALLY throwing them off. We went through rounds and rounds with the sharing. So instead they just get a little image that they can import and then all the data is embedded in the pdf along with tiny images, but it just looks like a little thumbnail file.

Oh man! I made an app for my family too. They have an antiques/book selling business on eBay so I made an app for them to actually keep track of things as they buy them.

That was where their process was breaking down - When did we buy this? How much was it? The sort of things that are semi-difficult to keep track of when you're going to A LOT of estate sales and then basically need to enter all the stuff into a spreadsheet when you get home.

So the concept was - take pics and enter simple data as you're out and about and then export the data when you get home.

I ended up going way down some deep rabbit holes because I didn't want to host any data (my goal was to actual release the app and hosting people's shopping trips wasn't something I wanted to take on).

So it's all local storage and for sharing between family members I ended up embedding the data in a pdf that you can send in a text and then import - so if x people are at the same sale they can all add to the same "trip" at the same time and then combine the trip when they're all finished shopping.

So image and data optimization were big concerns since it's all on your phone until you export it/delete the trip.

I was a fun process until it wasn't :P

I did end up getting to 1.0 and shipping to the app store, which was really my goal -> make an app and go all the way through the process. So in that way it was a success.

Yeah my parents thought it was funny and I was like... yeah not actually. You need to get that fixed.

My dad likes to joke around and his doctor uses some kind of transcription service. Time for fun!

His doctor asked him about using drugs and he made a joke that was something like "I only use coke" - meaning coca-cola. Of course his doctor knew he was kidding about drinking too much soda because he eats/drinks too much sugar. So they had a little laugh and moved on.

BUT now it's in his medical transcripts. My mom said it "transcribed" it as something like "the patient responded he has used cocaine recently".

I guess his doctor doesn't go in and actually fix things or even read over what the transcription says...

Also both of my parents have accents and have reported really weird transcriptions that don't match what they actually said.

So now my mom has told my dad he can't make jokes with the doctor anymore because even if the doctor knows he's joking it's going to get noted down as a "fact".

Don't worry I'm crying enough for both of us.

If the two are indistinguishable from an outsider's perspective how would you know which one to trust?

I totally agree - the example they give doesn't really need react OR backbone. You could just as easily show vanilla js as the 3rd example and wonder why you would ever even need a framework.

One off it seems fine, but a huge backbone app gets really complicated for me. Show me a huge react app vs a huge backbone app and I will understand the react much more quickly.

"It's verbose, sure, but there's no mystery. A junior developer can trace exactly what happens and when. The mental model is straightforward: "when this happens, do this."

I don't think that's true. A large backbone app has a lot of code that you'll have to trace through multiple files in different directories - the template are here, the functions are there but the endpoints are over there and... maybe it's just the backbone app I have to update but it's much more confusing and abstracted than the react app I also have to update. And don't even get me started with adding a new component. I can drop a new component into the react app and import it anywhere and it's super fast and easy... backbone not so much.

"LLMs are very effective at locating and explaining things in complex code bases." YES. I do nothing BUT write code and tracking everything down in the code base is greatly simplified by using an LLM.

This is just a new tool. I think the farming example mentioned in another post is actually a great example. I love coding. I code in my free time. It's just fun. I've been doing it for ~20 years and I don't plan on stopping anytime soon!

But at work I'm really focused on results more than the fun I can have writing code. If a tractor makes the work easier/faster why would I not use a tractor? Breaking my back plowing isn't really my end goal at work. Having a plowed field is my end goal. If I can ride around in a tractor while doing it great! If I can monitor a fleet of tractors that are plowing multiple fields at once even better!

When I go home I can plant anything I want in any way I want and take all the time I want. Of course that's probably why in my free time I end up working on games I never finish...

I'm getting really great results in a VERY old (very large) codebase by having discussion with the LLM (I'm using Claude code) and making detailed roadmaps for new features or converting old features to new more useable/modern code. This means FE and BE changes usually at the same time.

I think a lot of the points you make are exactly what I'm trying to do.

- start with a detailed roadmap (created by the ai from a prompt and written to a file)

- discuss/adjust the roadmap and give more details where needed

- analyze existing features for coding style/patterns, reusable code, existing endpoints etc. (write this to a file as well)

- adjust that as needed for the new feature/converted feature - did it miss something? Is there some specific way this needs to be done it couldn't have known?

- step through the roadmap and give feedback at each step (I may need to step in and make changes - I may realize we missed a step, or that there's some funky thing we need to do specifically for this codebase that I forgot about - let the LLM know what the changes are and make sure it understands why those changes were made so it won't repeat bad patterns. i.e. write the change to the .md files to document the update)

- write tests to make sure everything was covered... etc etc

Basically all the things you would normally WANT do but often aren't given enough time to do. Or the things you would need to do to get a new dev up to speed on a project and then give feedback on their code.

I know I've been accomplishing a lot more than I could do on my own. It really is like managing another dev or maybe like pair programming? Walk through the problem, decide on a solution, iterate over that solution until you're happy with the decided path - but all of that can take ~20 minutes as opposed to hours of meetings. And the end result is factors of time less than if I was doing it on my own.

I recently did a task that was allotted 40 hours in less than 2 working days - so probably close to 10-12 hours after adjusting for meetings and other workday blah blah blah. And the 40 hour allotment wasn't padded. It was a big task, but doing the roadmap > detailed structure including directory structure - what should be in each file etc etc cut the time down dramatically.

I would NOT be able to do this if I the human didn't understand the code extremely well and didn't make a detailed plan. We'd just end up with more bad code or bad & non-working code.

You might like this book then The Secret Lives of Colours, https://www.penguinrandomhouse.com/books/552503/the-secret-l... It's really beautiful if you're into colors!

That reminds me of the Ricky Jay article in the New Yorker. What an amazing guy! https://www.newyorker.com/magazine/1993/04/05/ricky-jay-magi... It so worth the read and there's no paywall.

What about having a contribute button? I know this must be a lot of work and it's such a cool idea! If you had a way to contribute on the join page I would chip in for sure :) My husband is a writer and he uses newspapers.com to research a lot of vintage newspapers for historical context. I can imagine this being a great resource for him.

When Claude says “Let’s try a different approach” I immediately hit escape and give it more detailed instructions or try and steer it to the approach I want. It still has the previous context and then can use that with the more specific instructions. It really is like guiding a very smart intern or temp. You can't just let them run wild in the codebase. They need explicit parameters.

Same here. Recently the camera has started shaking really badly so I'm thinking of finally getting a replacement. I have other cameras though, so the phone camera is just for convenience. It's hard to bite the bullet on a new phone when the one I have is (aside from the camera) in great shape.

If you wanted to read more on the same/expanded topic, I thought this book was pretty good.

Ghost Hunters: William James and the Search for Scientific Proof of Life After Death, by Deborah Blum.

https://www.penguinrandomhouse.com/books/292812/ghost-hunter...

It was frontend. I did ok with some heavy studying, but I'm definitely more UI focused on a day to day basis. The problems I had to figure out during the interview were nothing at all like what I do daily.

I walked away feeling like if I really wanted to I could knuckle down and study for longer and get a job there, but I decided it wasn't really my thing and went in other directions. Like I said, I took the studying and the subject matter as a challenge and I feel pretty pleased with how far I got considering I have a painting degree.

Ok, completely different take!

I also interviewed there last spring, but I thought it was super positive, even though I didn't get the job. I had to push myself really hard to get the onsite and I think that was beneficial to me. I have no computer science background at all and it forced me to prep intensively between interviews. So, I kind of went into it figuring I probably wouldn't get it but who knows and that it would just be good to have the experience of this super tough interview.

I learned some things! I started thinking about my job a bit differently, which is cool. Also, at the very least, the process made me better at interviews. Ha! There's always something you can take from a difficult experience (and it was for sure difficult.)

I don't think you should feel discouraged or feel bad about your abilities. It sounds like it was just a poor fit and you should be happy it didn't work out! Plus, now you've been through it once. You know what it's like. You can do it again somewhere else and it'll work out.

Good luck with Amazon!

Same! I worked in a setting like that and it was by far the most productive environment I've been in as far as pure work volume and concentration. Basically people were in tiny open offices sorted by teams (i.e. frontend, backend, copywriters). Our group kept the room pretty dark and no one talked, we just messaged each other. I realize that description can sound a little creepy, but it was blissful.

Open office-wise the best was getting a desk that was in a corner around a pony wall. So I had a wall (conference room) at my back, a pony wall at my left and a desk facing towards me, which is almost like a wall in front. Also the people I was sitting near could control the lights on our side of the wall. We kept only half on and it was super helpful. I think bright fluorescent lighting is a little distracting. Maybe not distracting, but not awesome.

Someone just mentioned this in another thread (https://news.ycombinator.com/item?id=18397380) and I didn't know there was a name for it. Now I do :D