Does Fastmail really get push? I have a vague recollection that the reason I’m using their app over native ios Mail is because ios Mail was notifying me about emails with a noticeable delay.
If I'm not mistaken, vibe coding is supposed to be when you don't review at all, you just let'r rip. Reviewing the AI's code is just... Like if coding was riding a bike, and you got an electric bike. Kind of. It doesn't seem like vibes to me.
the usage of vibe coding in my experience is towards those folks who run whatever the AI produced and if it does what they expect without throwing errors they ship it. If it throws errors they plug that back into the chatbot until the code stops throwing errors.
The whole point of vibe coding is its working faster than you would on your own. If you're reviewing it carefully and understand how it works, you might as well have written it by hand.
Even if it appears to do what you want, but you don't actually read and understand the code, how do you know it doesn't do something else also? Maybe something you don't want?
Irrelevant in vibe coding. If it walks like a duck and quacks like a duck, you don't go looking for extra heads, eyes, fingers, tongues, or tails. You ship it then throw repl.it under the bus when it blows up.
I don't know. Me and my colleagues call "S3" every storage service that provides an AWS S3 API. I think the official name for the product I buy from my cloud provider (Scaleway) is "Object Storage".
S3 is a generic term for a cloud storage everywhere. Idk about proper terms, I always called Google Cloud Storage or Backblaze or any other products using S3 protocol as "S3". It all works the same
Even if the final nod of agreement happens in real time the actual decision making process for critical product features should involve planning, thinking, research, etc. There should be a strong paper trail such that everyone knows what the decision is going to be prior to the "everyone gets together and declares this is how things are going to be" step.
If them missing some meetings means they're in the dark as to how those features were decided on then I can't see that as a defence of attending every meeting so much as a statement of BS meetings being so predominant in the company that all decisions are made through a BS process.
This might not be quite what the previous poster meant, but in my experience it's often not that the developer missed a meeting and now doesn't know some critical piece of information. Rather, it's often that the developer has some knowledge about the code that changes how something should be implemented. Because they weren't at the meeting, nobody else knew about this, and it's only later, when the developer sits down to write the code, that everyone finds out.
In this case, there's nothing to document from the meeting because the information wasn't shared in the first place. The information could only have been shared if the developer had been in the meeting.
(FWIW, I've rarely seen this from a developer not being in a meeting entirely, but I've seen it a few times where a developer has treated the meeting as a "read-only" event, i.e. expected that other people provide all the requirements and not used their own expertise or experience of the code to push back on decisions.)
The point in the parent comment still stands. There should be a paper trail so that the developer would have to confront the need to add such a detail. If the decision was made in the meeting alone, then it was lost in time as not all developers can be expected to be in every meeting.
How? Meeting notes can never contain all the detail of the meeting and, if they do, there would be so much content that you'd likely miss them when you read the documentation. That's to say nothing of the time investment of the person to catch up on every document produced.
In that case, you're essentially relying on the people in the meeting to know they should document that thing as important which, given the person who knows it's important isn't there, is pretty unlikely.
Even in an ideal world, we'll have developers not in the meetings they need to be in. My contention would be that we should try to get people in the right meetings and, over time, the number of issues where someone isn't in the right meeting will be lower than if we just don't have those meetings.
If decisions are being made about the code or implementation, then the person working on that code should be in that meeting, surely. Otherwise there's no point making that decision.
I realize introverts don't work that way, I know, I am one. But I've had some of the most brilliant ideas come through purely on a discussion nay sometimes an emotionally charged argument.
Important decisions are almost never 2+2=4, if they were, they wouldn't be important and yes you wouldn't need a meeting (like I admitted, there's definitely a lot of unimportant meetings).
But important decisions are almost always an exercise in coaxing, cajoling and persuasion, which is just extremely low fidelity on paper.
Most engineers will look at their team leads and say "I don't believe in this strategy on paper", and all their team leads can say is "I was at the meeting. You had to be there"
I'm an introvert, too. I have no troubles participating in, or leading, or even fighting in group activities. Does it exhaust me? Yes, it does. I literally feel physical pain if I have to stay in company for more than maybe an hour. But value is created through interaction, not some process, paper stacks, or a lone wolf hiding in the closet, so I learned a long time ago how to communicate effectively, give and take feedback, organize tight meetings, and facilitate decision making.
I'm actually a bit tired of introverts hiding behind their disposition. You can do something about it, and it's more than complaining.
EDIT: Sorry, that was more rantish than I wanted. But I'll leave it here anyway.
Most people in meetings don’t type very fast, and find it easier to talk than to write.
This means that prior to AI transcription/summary bots, there wasn’t much written documentation about the decisions and conclusions from meetings. Now hopefully that will change.
In my org we have rotating minutes takers - it effectively takes them out of the meeting, but they do pipe up if an issue affects them directly. Of course people's meeting taking skills vary widely but I still find the human-made minutes far superior and accurate to whatever Copilot cooks up.
I wasn't so much saying that there should be plenty of documentation generated during a meeting as saying that there should be plenty of documentation prior to the meeting. That the meeting is based on.
I've also read a thing (dunno if it was opinion or fact) that posited that people's reading ability is directly correlated to a preference for video, I suspect it's the same with meetings. I read / write all day (including on here lmao), meetings are draining in comparison. But the people in those meetings don't read / write nearly as much as I do.
I did once think that if the meeting were to be transcribed, people are outputting paragraphs of text in a short amount of time, just verbally. But keeping up with that is pretty draining, as you have to listen and process it, whereas with reading you can skim and re-read things easily.
I sometimes think people's basic skills - reading and typing - are underdeveloped or not assessed, and they should be assessed when applying for a job that involves reading and typing. But I don't even think people consider reading/writing skills when looking for staff since the assumption is that everyone's is good enough.
I administer reading comprehension tests and typing speed tests to all candidates I consider hiring.
It’s overlooked.
Good ones who can’t type fast, I assign them typing lessons their first few paid days on the job, and a half hour twice a week thereafter for a while.
I’m an outlier and can type 120wpm without trying very hard, but I expect 40-50wpm (touch typing, not hunt and peck) at a minimum from staff that work with computers and aren’t disabled.
> Good ones who can’t type fast, I assign them typing lessons their first few paid days on the job, and a half hour twice a week thereafter for a while.
This is very interesting to me - I’ve actually been building https://www.typequicker.com recently and was curious about potentially adding features and marketing it towards businesses who then can use it to train their workers.
Typing quickly is extremely overlooked and since I learned touch typing, it completely improved my productivity and career trajectory. (Went from 40ish to about 100-120wpm depending on what I’m typing)
What are some tools that you use when you say you assign lessons?
If I ask the question myself then there's no step where a human expert has vetted the content and put their name on it. That curation and vouching is of value.
Now your mind might have immediately went "pffff as if they're doing that" and I agree but only to the extent that it largely wasn't happening prior to AI anyway. The vast majority of internet content was already low quality and rushed out by low paid writers who lacked expertise in what they were writing about. AI doesn't change that.
Completely agree. We are used to thinking of authorship as the critical step. We're going to have to adjust to thinking of publication as the critical step. In an ideal world, publication of a piece would be seen as vouching for that piece. Putting your reputation on the line.
I wonder if we'll see a resurgence in reputation systems (probably not).
Are streaming services really measuring value in terms of minutes watched? I would have thought they’d have better methods of tracking which shows generate subscriptions and retention.
Cost-per-minute and total minutes delivered being key metrics for their production folks would have a similar effect, and is kinda the same thing (how many minutes of viewing will be experienced by someone who watches the show you made for us?) if they don't also have effective controls in place to keep the editing tight—and, from what they put out, I think they do not.
Implementation is what takes that raw R&D and uses it to solve problems real problems, which is where it derives it value. Armies of people slightly modifying slightly different saas is how those foundational ML models end up in the everymans workflow.
Your tribe were the people you worked with at Loom. When you left your tribe became only your girlfriend. What are you going to do? Have perfect harmony with 100% of your tribe forever? Of course not. Of course you fought. Because on top of lover she now fulfils all sorts of roles including rival, competitor, and nemesis.
You need to pick a group, any group, and stick with it.
Jumping around both physically and vocationally is not only not going to help you, it's going to make integrating yourself in to a group way harder.
