It can also be helpful to make sure interviewers can clearly say yes or no about a candidate. If you're not there, ask whatever you need to get there. If you never get to yes then it's a no.
Being the most popular comes with big benefits. There are far more articles about how to support issues that you run into, and many more libraries available for your use. While other libraries maybe "better"in some cases, giving up the support of the large community is a big cost.
Pay. Simple. The enshitification is a direct result of the free business model, where the users of the service are actually the product, and the advertisers are the real customers. Even if kagi feels too expensive, you are still voting with your wallet by choosing a service that you pay for and showing companies that they can focus on building good products for the people who use them and are willing to pay for them. FWIW, the same is true of social networks, but they suffer from the additional complexity of needing enough people to use a service to make it worthwhile.
Why not just get written feedback from interviewers rather than adding so much drama? Yes, social dynamics can play a significant role if you pull everyone into a room to hear their initial opinions. And worse if you have more than their peers in that discussion. Instead, if you get written feedback from each interviewer first, then you can skip the entire discussion sometimes and discuss on the candidates that had support via a normal discussion. If the hiring manager has the final say, they should run those discussions (not the hiring manager's boss, as implied). Also, any company that "was trying to hire around 30 developers at top speed" has bigger problems with management than how to hire.
Learning a new syntax takes a day or two, a week or two at the most. Having a site or product that helps you with that doesn't seem important, at least to me. The hard part about learning a new language is learning how to use it, not its syntax. Learning how to use it requires working with it, and for a long time, somewhere in the 3 to 10 year range to really become an expert. You can't learn experience quickly using any product or YouTube video.
I understand the frustration, but this article is just conspiracy theory based anecdotal data l. The claim that the engineers don't understand the Google search algorithm is not backed up by anything aside from a casual conversation with one person. These are just random thoughts by somebody who doesn't actually understand how Google works, who their customers are, and they're just frustrated because they are not generating revenue using whatever system they had before. And it is feeding off a story that has very little basis in fact.
This has all happened before. This will all happen again. Everyone felt the same way about TypeScript. Types feel annoying at first, if you lived without them. Using untyped libraries is annoying until they all have types, which happens over time. Types prove their worth every time.
The backup mitigates the problem because, if you are banned, which only happens to fools and fakes, you can take the backup and set it up on another service. Sure, you lose a couple of days of time migrating, but that's not a reason to avoid choosing a better solution.
Just make the Designer the Product Manager, or get rid of the PM title entirely. After all, the process of navigating features and fixes to move the product forward is really a design job, not a management function. Also, the more the technical and design people understand the business side, including Marketing and Sales, the better. Ideally, technical and business sides work together, with design as the cartilage that holds them together.
At a startup you can run your company on the communication tools provided in Google workspace. There's much more to this than calendar and email. Tagged comments for coordinating actions, using gdocs with meetings and transcription and summarization by Gemini, communal editing and sharing, the gdocs history, sheets and slides, backup and logging tools, domain management and more. If you use proton, you get Google workspace from 15 years ago, at best.
Or, you can look at the positive contribution that AI is adding for developers. This is true even for curmudgeons like me that tried it early on and had bad experiences. Using AI to look up documentation, and asking the AI to summarize alternatives takes many fewer clicks than searching Google. I also find it generates good code if you ask the right questions. That is, as an experienced programmer, I'm able to generate much better, iterative prompts than a nontechnical person or a junior programmer. With tools and the AI evolving, making iterative changes across your app using an AI is clearly part of the future of programming. Heck, it even chooses good variable names, and that's been the bane of programmers since the dawn of programming.
This looks cool and +1 for the 37Signals and Basecamp folks. I need to verify that I'll be able to spin up GPU enabled containers, but I can't imagine why that wouldn't work...
Great to hear you've improved serverless debugging. What if my endpoint wants to run ffmpeg and extract frames from video. How does that work on serverless?
I love that the only alternative is a "pile of shell scripts". Nobody has posted a legitimate alternative to the complexity of K8S or the simplicity of doctor compose. Certainly feels like there's a gap in the market for an opinionated deployment solution that works locally and on the cloud, with less functionality than K8S and a bit more complexity than docker compose.
It would be wonderful if the world could accept blunt feedback. It is certainly easier to give and more in-line with what most technical people would prefer. However, we work with humans, and we have learned an awful lot about how humans respond to language, especially criticism. The advice here applies to giving feedback to any human, not just superiors. As you spend time working with humans, you learn, perhaps slowly that what you might consider "fluff" is really about helping make your point. Being direct doesn't always, or even usually, work as well.
Sounds to me like you need to do more testing. You should have automatic integration tests that run with your CI/CD pipeline to make sure you don't break seemingly unrelated bits, and most importantly you need to actually test the application like a real user - like QA will test it - before you merge. Writing code that works is only half the battle. You need to test it and get it ready for production before you merge. Most importantly you need a robust test suite with >90% coverage, to avoid breaking things by accident. Focus on making sure your code is stable, rather than trying to get each task done as quickly as possible.
And how does that help the company? So you can fire them and have to train up a new replacement to make new mistakes? Or, instead, promote the manager who made a bad decision? Besides, blaming the LLM is probably even easier! I definitely agree that you need to do post-mortems on mistakes, of course.
If the items in this meeting were put into a shared document, not only would you stay on the same page, but you would have a searchable history, which becomes valuable as time moves forward. What really triggers my red flag here, though, is that "standing meetings" are one of the worst offenders as far as useless meetings go. Instead of forcing everyone to sync at a specific time, if you put these updates in documents or emails, you allow for more asynchronous consumption, and you don't affect the flow of individuals, especially if you have multiple time zones.
Use Google docs. Ideally, everything or as much as possible should be public and accessible to anyone on the team. Especially planning and scheduling documents. Each meeting should have an agenda attached to the meeting on the Calendar. Each meeting should be transcribed and then summarized using Gemini.
Minimize the unsearchable communication tools, like Slack and Discord, though these tools are fantastic for casual conversations. Everything possible should be done to minimize notifications from Slack/Discord. In fact, minimize interruptions as much as possible to maximize the asynchronous benefits of working remotely.
On the development side, everything should be code reviewed before merging to main, as this helps spread knowledge and increase the signal:noise in written communications.
On the business side, all customer meetings (many of which should use GMeet), should be transcribed and summarized so the developers and other folks can be as close to the customer as possible.
Meet in person as a whole company AT LEAST once per year, perhaps 2-3 times. This can get expensive. As the team learns each other, the frequency can reduce. During periods of employee growth, increase the frequency.
Read "Remote" and other books by the Basecamp team.
It's funny how folks see their jobs as safe, but nearby jobs that they don't understand as at risk. In this case, actors are safe, but VFX better be worried. Ben knows actors are artists and it's going to be hard for an AI to mimic all the experience and subtleties he's gained over his life. The same is true in VFX, it's just that Ben doesn't understand the art or the process of visual effects.
All the creatives are worried that Gen AI will steal their jobs. Seems to me that the most likely candidate for replacement is the manager. Their primary job is summary and communication, an ideal fit for an LLM. If you already coordinate your company around Google docs, the AI has access to all the information about company's status, even all the emails.