> ChatGPT was outright lying to people. And making us look bad in the process, setting false expectations about our service.
I find it interesting that any user would attribute this issue to Soundslice. As a user, I would be annoyed that GPT is lying and wouldn't think twice about Soundslice looking bad in the process
> Every kid with a laptop thinks they're the next Zuckerberg, but most can't debug their way out of a paper bag
I feel like I've seen this quote many times over the years.
Also, how do they calculate employment rate? If you get a job at McDonald's while having a civil engineering degree or nutrition science, that counts as employed as well, no?
Would be good to see how many are actually employed in their field of study
Nationalism is not the thing stopping most people.
It's your friends, family and the feeling of belonging. This is culture, not nationalism. I lived in Canada for 10 years before moving back home. I had a great life in Canada, fulfilled things I quite literally never dreamed possible, but I didn't belong.
I lived my life between vacations, just waiting for the time that I can go back home and spend time with family. I realized this is no way to live life.
I second this! I was recently looking into a way to build something like this for my grandfather, but wasn't even sure where to start from the hardware side.
I wanted to have hardware plug into TV receiver, generate subtitles for live TV program and then play it back on TV. Delay would likely be less than a minute but even a few minutes is not a problem really.
Many people with a hearing problem would benefit from this and with AI getting so good at Speech-to-text, this can be done for quite a large population.
If anyone has a recommendation on where to start with this, I'd appreciate it! Was thinking of using Whisper for subtitle generation, but not sure about hardware that can take in, and output HDMI and run this software
I think it's worth a read because it does contain nuance and food for thought that would get lost in a summary. It's not that long, and I'm a slow reader.
But, to try and summarize:
- Issues with Gemini were not (in author's opinion) an initial instruction set fluke, but top to bottom design of the system.
- Rather than presenting the information you asked for it's presenting what its makers think the world and information you asked for should look like (i.e their ideology)
- If you can't know how the product is trained and set up, you can't trust anything it gives you because you'll never know if you're getting the information as is, or are getting the world view of the company who's product you're using.
- "...ask yourself what would Search look like if the staff who brought you Gemini was tasked to interpret them & rebuild it accordingly? Would you trust that product? Would you use it? Well, with Google's promise to include Gemini everywhere, that's what we'll be getting.."
I think you might be reading into it a bit too much.
The author is saying that this code
> reads exactly like how a person might talk about what they want to test
A person WOULDN'T talk about testing a Ticket like what you're describing with implementation details
"Ticket is a class, which will have a method of _this_ and I will call that method, which will then do _that_, and I will take the return of that method and call put it in a variable, that will be a constant..."
A person WOULD talk about testing a Ticket high level like this
"Let's describe a Ticket. When the ticket is closed, it emails the requestor with a confirmation."
Now listen, obviously not being familiar with the syntax makes reading code harder, but a programming language isn't designed so that people can just look at the code and learn the syntax from looking at the code. That wouldn't make sense.
With that said, I struggle to see some of your points listed as non-intuitive. All of your comments are related to not understanding the implementation details of this code. And that's just not what's being talked about here.
I often see complaints about this when people are uncomfortable accepting _syntax_ that clearly tells them _what_ will happen, but if they don't understand HOW that happens, they don't like it.
Here's another Rails example, for validating a model
```
class Person < ApplicationRecord
validates :name, presence: true, uniqueness: true
end
```
Can you seriously say that you don't understand that the name of the Person will be validated if it is present, and if it is unique? I doubt that very much.
Can you say that you have no idea how it's implemented? Yes. You don't know how something might be implemented in a language you don't know. But, does that really matter when talking about expresiveness?
I found this article helpful. Most comments on here seem to suggest that hourly is best done when clients don't know what they want, and I think that actually misses the point of the article, in my understanding.
Working with a few customers as a freelancer, I agree, a lot of time they can't express what they actually want. They know it when they see it, but they can't express it correctly so you end up building a product, and having a thousand change requests - basically the customer uses you as a prototyping machine until you build what they want.
Obviously this can't work with fixed pricing, BUT this is where the point of the article comes in. If the only thing you can offer to your customer is writing code based on a requirement - you're racing to the bottom because thousands can write code based on a requirement.
BUT, if you focus on outcome - I will build you what you want, AND I'll help you figure out what that is!! That service will include asking the right questions, helping the client figure out what they want, and you can put all of that in your fixed price offer. At this point you aren't just writing code for them, you are their business partner, you want them to succeed, and you will use your experience to offer advice. If you become good at this, you are much more than just a programmer, or what the article calls "technician".
So, thanks for the article, I found it interesting and have some food for thought.
Interesting reading the comments how everyone has their own best way of joining a new team.
For me, the best way to join a codebase without a doubt is to actually just use the product first. What good is looking at the code if you have no idea what the product is even supposed to do?
This doesn't have to be in-depth knowledge, but just go through the setup of your product, do a few happy path use cases, feel what it's like to actually use the thing you're about to develop.
I have a morse code app which consistently crashed when certain users would try to translate letter "i", and it took me a long time to figure out that only the turkish users would complain about it, and when one of them sent me a screenshot I only noticed a "wrongly" rendered capital letter i (I used toUpper) and after digging around a bunch, I learned about this while turkish letter i.
This is not as good as it sounds just because it works for you.
People don't love moving, and they usually move for better work opportunities, not to accomodate a pay cut at their current job. Moving to a lower cost of living area also means moving to an area with less opportunities, and not to mention moving away from your social circles and the life you have established somewhere.
The only way I can see this working if uber started hiring bew remote engineers in the US, but asking their current ones to move from SF so they can take a pay cut?
I don't know if it was a good idea showing the link in the comments, since OP clearly didn't want their business mentioned.
I understand anyone could've done what you did, but that means that they would have to care enough to actually go looking through OP's profile and them finding out the name would be deliberate and not just plainly advertised for anyone.
I find it interesting that any user would attribute this issue to Soundslice. As a user, I would be annoyed that GPT is lying and wouldn't think twice about Soundslice looking bad in the process