I strongly believe that proactively keep documentation up to date is not worth the effort.
Here is what I recommend in my teams:
- There’s an onboarding guide that is usually only updated when new people onboard. If something is not right they raise it and their onboarding partner fixes it.
- When someone shares a technical document/RFC we add it to a central repository with a creation date on it. These are point in time and usually not updated but still useful for new hires.
- We sometimes do onboarding sessions to walk through the architecture, these are recorded and added to the central information repository.
Note that in the things I wrote above there’s a mix of up to date content and slightly outdated content, ultimately the code is the source of truth. It’s not worth spending time writing docs that no one is gonna read.
Funny, I just posted the exact opposite. And find that everyone reads my docs, and comes back to them frequently as they work in different areas of the codebase. Of course, we are a remote team who swaps people in and out often, so onboarding is not a one-time event where you have partners to hold your hand. If you really only onboard once and don't have a fast-growing team, I could see where the needs would not match up and we'd both be correct for our own situations.
And do you go back and update all documents whenever something changes? If you’re swapping people around every month I agree that you must keep everything written down, happens a lot in projects that bring consultants in. But if you have a core team of people and you get 2-3 new people per year then you should be more relaxed about it.
Yep, we do. It is part of the process just like testing. For the most part, it is not painful - most features are variations on existing patterns, and don't need updates. When we do code up a new pattern, we update docs.
And you are correct - we use consultants on the team, and hire in gig workers for small tasks on a regular basis. When I worked on a small core team without much churn, I did not do any of this.
Face to face communication is very underrated nowadays, probably because of the negative connotations associated with meetings. Talking to someone is by far the fastest way to convey information. I often prefer a quick chat than spending 30 minutes writing Slack messages back and forth. I agree that writing has other benefits and it's better in certain cases but we need to get out of the mindset that writing/async is always better.
The problem is that anyone who later needs to know what was in the meeting, even the two original participants, has no access to it. On the whole, more time is lost by people not being able to refer to what was actually said later than is saved by having it quickly and synchronously. You're making more work for yourself and everybody else in the long run.
Information overload. There’s tons of info on our Slack, but the vast majority is noise. If you saved transcripts from all Zoom meetings it would be mostly noise too. The benefit of meetings is that they be chaotic. Creating something succinct and sharable from them should be done later as a singular focused activity and stored in a wiki.
Default to async, hire people reasonable enough to request upgrading to synchronous communications when needed (cover ground faster or clear up miscommunications) but used judiciously.
The pacing part can be an issue. In particular when face to face people will want to look smarter, and let things slide even if they don't completely understand them, to preserve the flow.
It's only afterwards that it comes back to bite both sides.
> Face to face communication is very underrated nowadays, probably because of the negative connotations associated with meetings. Talking to someone is by far the fastest way to convey information.
Really depends on how the conversation is handled/going. I recently had a feedback from two people having a face to face meeting. One week later they followed up and they found out they completely misunderstood what they had said to each other.
Happens every time, that is way we write the "As per our meeting, we've decided that..." emails. Even with those, people still end with different interpetations
It is not my responsibility to make sure people can make money off of me by means of "implied contracts" and other similar bullshittery. It is those people's choice to make those videos, and it's their choice of which platform they publish them on. But then it's MY choice of how I use the internet on a device I own.
Exactly. Which is why I feel no sympathy for the entitled complainers when google says enough and blocks the ad-blockers. As somebody that makes videos and makes a decent amount of money from it, I could care less about people that are so adamantly demanding free content getting cut off by Google. These people clearly don’t care about paying the subscription Google offers if they want to avoid ads, they clearly don’t want to watch ads to even support the creator, why would I care about having these people watch my videos?
It’s especially funny to see this sentiment on hacker news. “Those stupid content creators, clearly if they want to make money, just don’t use YT!”. I’m curious, what’s the alternative? Cable? Good luck. Udemy? What if I’m trying to make entertainment videos? Oh, I guess I could just build my own low latency highly efficient video hosting site and get a paid subscriber base that manages to cover hosting costs and make a profit! Yea, because that’s completely realistic…
The alternative? A job. Don't make vlogging your entire full-time occupation. That simple.
If you do want to make videos that reliably earn you money, charge money for them! Make it explicit. Don't rely on implied contracts that other people may or may not honor at their discretion.
Doing any of those things without the algorithm showing your videos to people is hard though. They also require 3k watch hours in the past year so they expect you to grind for at least a year to "prove" you are worth monetizing.
That or go viral somehow and bootstrap yourself (which is likely why the shorts views are so high). Obvious not impossible as people still do it but the math seems suspect to me.
YouTube gets thousands of hours of video uploaded every second. I'm not sure what the ratio of monetized accounts to non-monetized accounts is, but if YouTube can run a channel "for free" for a year because they aren't monetizing it yet, it seems there's a threshold they are willing to accept to serve videos "nobody wants to see" until enough people do want to see it and they advertise on it.
So the high profile creators are costing YouTube money to serve their videos and YouTube wants help paying that cost. But they only extract it from channels they know are profitable because there are a lot of eyeballs on those videos.
Almost like they are promising X ad views to advertisers and want to keep that numbers game rolling. I feel like ad based spending is going to go through a correction in the next decade.
> They also require 3k watch hours in the past year so they expect you to grind for at least a year to "prove" you are worth monetizing.
No, if you get 3k watch hours on a video you are good to go, you don't have to wait a year. I've seen plenty of channels get monetized within weeks since they already had an audience.
I remember when Game Grumps made "The Grumps" channel and before they even uploaded a single video to it, they were already at Diamond(I believe) subscriber count. I don't remember if they were immediately monetized or not, though.
There are other places you can post to jumpstart your channel like Reddit or social media you're only reliant on the grace of YT if you allow yourself to be. There's also still plenty of niche blogs/news sites that can send plenty of audience to your new channel if you're producing good content. You're also misreading the hours metric it's just a rolling window not a wait period. If you hit those metrics in a week you can monetize basically immediately.
Reminds how US centric a lot of crypto companies are. An advantage of crypto that often comes up is “instant and cheap money transfers”. In the UK, I transfer money to my friends instantaneously and for free using just my bank account.
> In the UK, I transfer money to my friends instantaneously and for free using just my bank account.
You can do the same thing in the US. The problem is that businesses can't easily do this without collecting bank routing information from customers, which is effectively "secret" because it allows anyone to debit money directly from their bank account, so they're reluctant to provide it.
What's needed is a low- or no-fee system for requesting payments from someone without collecting any secrets from them. The technology to do this is not hard -- use public key cryptography, or just require the customer to approve merchants before they can make debits. But the customer's bank has little incentive to implement this because the customer won't choose a different bank over it and meanwhile the banks own the credit processing networks charging the high fees.
Which is why people are looking for an external solution.
Both already exist. Setting up a direct debit generally only involves filling in a form. Sending money to someone else is as simple as authorising a payment to them with their account details.
What's needed is a better system for approving who is allowed to make withdrawals from your bank account instead of just "anyone in possession of your bank routing information" which makes customers reluctant to provide it.
This would be essentially solved with a standardized system for customers to give each merchant a separate bank account number (or equivalent) which really refers to the same bank account but could be revoked individually if that number is compromised or you want to remove the merchant's access, or could be set to automatically expire for non-recurring payments. But the banks don't have the incentive to provide this when they're the ones getting the credit card fees.
I like the idea of per merchant account numbers. Even better if we used some kind of cryptographic binding between the merchant account and your account, so it would not work for anyone else.
I don't know how it works outside of Italy but here we can make instantaneous bank transfers for free or a really small (and capped fee) to anyone just knowing their bank account without leaking any secret information.
You can also do this in the US with Zelle. Of course there's app alternatives like Venmo or PayPal too -- I don't really understand the importance / benefit of 'just using a bank account.'
Funny how people keep complaining about companies that don’t allow them to work from anywhere, but then are only willing to accept a salary based on the market value of a very small number of countries.
Is it funny that people expect a salary commensurate with the country where they reside? It’s not like the world has open borders and people can just pickup and move wherever they want. Sure, some young single people can do the digital nomad things, but that’s a minority of people. Most have obligations.
Many successful artists don't paint, sculpt or build anything. It's not about the technique. Art is about sending a message, it's about what the artist is trying to say. It's about what the public feels and thinks when exposed to their work.
AI has a place as a tool to produce content in a fast and cheap way. And yes, as a result of that certain jobs will likely disappear. But art will continue to exist and great artists will still be followed and admired by the public.
Part of a critic's job is to educate people. A good critic can explain why a certain film is groundbreaking and why another film is recycling ideas that have been done thousands of times. The critic's end-goal is to push the industry to make better films not because of critics, but because the public demands it.
This doesn't seem right at all, a critic's job is to drive page views and nothing more. What you are describing is how critic's like to perceive themselves.
That’s hardly the only model. If you find a critic that has similar tastes as you then you can just follow their recommendations. That’s a relatively new thing as newspaper reviews where focused on a much wider audience, but with the internet you have a lot more choices for reviewers.
- There’s an onboarding guide that is usually only updated when new people onboard. If something is not right they raise it and their onboarding partner fixes it.
- When someone shares a technical document/RFC we add it to a central repository with a creation date on it. These are point in time and usually not updated but still useful for new hires.
- We sometimes do onboarding sessions to walk through the architecture, these are recorded and added to the central information repository.
Note that in the things I wrote above there’s a mix of up to date content and slightly outdated content, ultimately the code is the source of truth. It’s not worth spending time writing docs that no one is gonna read.