It may well be. Books have tons of useful expository material that you may not find in docs. A library has related books sitting in close proximity to one another. I don't know how many times I've gone to a library looking for one thing but ended up finding something much more interesting. Or to just go to the library with no end goal in mind...
Speaking as a junior, I’m happy to do this on my own (and do!).
Conversations like this are always well intentioned and friction truly is super useful to learning. But the ‘…’ in these conversations seems to always be implicating that we should inject friction.
There’s no need. I have peers who aren’t interested in learning at all. Adding friction to their process doesn’t force them to learn. Meanwhile adding friction to the process of my buddies who are avidly researching just sucks.
If your junior isn’t learning it likely has more to do with them just not being interested (which, hey, I get it) than some flaw in your process.
Start asking prospective hires what their favorite books are. It’s the easiest way to find folks who care.
I’ll also make the observation that the extra time spent is very valuable if your objective solely is learning, but often the Business™ needs require something working ASAP
It's not that friction is always good for learning either though. If you ever prepared course materials, you know that it's important to reduce friction in the irrelevant parts, so that students don't get distracted and demotivated and time and energy is spent on what they need to learn.
So in principle Gen AI could accelerate learning with deliberate use, but it's hard for the instructor to guide that, especially for less motivated students
I admire your attitude and the clarity of your thought.
It’s not as if today’s juniors won’t have their own hairy situations to struggle through, and I bet those struggles will be where they learn too. The problem space will present struggles enough: where’s the virtue in imposing them artificially?
Disagree, actually. Having spent a lot of time publishing papers in those very journals, I can tell you that just browsing a journal is much less conducive to discovering a new area to dive into than going to a library and reading a book. IME, books tend to synthesize and collect important results and present them in an understandable (pedagogical?!) way that most journals do not, especially considering that many papers (nowadays) are written primarily to build people's tenure packets and secure grant funding. Older papers aren't quite so bad this way (say, pre-2000).
I've done professional ghostreading for published nonfiction authors. Many such titles are literally a synthesis of x-number of published papers and books. It is all an industry of sorts.
> It may well be. Books have tons of useful expository material that you may not find in docs
Books often have the "scam trap" where highly-regarded/praised books are often only useful if you are already familiar with the topic.
For example: i fell for the scam of buying "Advanced Programming in the unix environment" and a lot of concept are only shown but not explained. Wasted money, really. It's one of those book i regret not pirating before buying, really.
At the end of the day, watching some youtube video and then referencing the OS-specific manpage is worth much more than reading that book.
I suspect the case to be the same for other "highly-praised" books as well.
When I first opened QBasic, <N> years ago, when I was a wee lad, the online QBasic help didn't replace my trusty qbasic book (it supplemented it, maybe), nor did it write the programs for me. It was just there, doing nothing, waiting for me to press F1.
I couldn't make head nor tails of the QBasic help back in the day. I wanted to. I remember reading the sections about integers and booleans and trying to make sense out of them. I think I did manage to figure out how to use subroutines eventually, but it took quite a lot of time and frustration. I wish I'd had a book... or a deeper programming class. The one I had never went further than loops. No arrays, etc.
You posted this in jest but it's literally true. You need to read the whole book to get the context. You SHOULD be reading the manuals and the docs. They weren't written because they're fun.
I'm not sure what you are trying to say here, or if you are trying to somehow diminish my statement by somehow claiming that online documentation is causing the same magnitude of harm compared to using a book?
Two things:
1 - I agree with you. A good printed resource is incredibly valuable and should be perfectly valid in this day and age.
2 - many resources are not in print, e.g. API docs, so I'm not sure how books are supposed to help here.
It’s an interesting question isn’t it? There are obvious qualities about being able to find information quickly and precisely. However, the search becomes much narrower, and what must inevitably result is a homogeneity of outcomes.
Eventually we will have to somehow convince AI of new and better ways of doing things. It’ll be propaganda campaigns waged by humans to convince God to deploy new instructions to her children.
And this outcome will be obvious very quickly for most observers won't it? So, the magic will occur by pushing AI beyond another limit or just have people go back to specialize on what eventually will becoming boring and procedural until AI catches up
BuildBetter | Senior Engineer (Backend, Full-stack) | Full-Time | Remote (US) | 170-200k base + equity | Visa Sponsorship not provided
BuildBetter is the product operations platform for customer-led teams. We've built an AI-first product that lets our customers, like Rappi, n8n, Posthog, and Brex automate the operations work that lets them provide their customers with world-class product experiences.
We're looking for two senior engineers to join the team; our headcount has remained small while growing revenue, and we're now bottlenecked by development speed in a way that will make you invaluable. You'll have real ownership over your code from product ideation to customer support, and we'll be making substantive product updates weekly. We're looking for team players who are as fun to work with as they are productive, and are willing to compensate these two rolls commensurately - our aim is to be in the 95th percentile of equity compensation, and we expect that in exchange we'll have value-aligned employees who will help us grow the business.
Joining us will mean solving hard problems at the frontier of AI adoption, including:
- maintaining performance at scale
- building and maintaining rich frontend user experiences that maintain the standards of usability and delight that our customers know us for.
- building agent and workflow systems that automate real work for customers
- playing around with the latest models to figure out new experiences that we can offer our customers as cutting-edge models get released monthly
- building automation that's grounded in supporting product teams rather than automating them - our bet is that this is the likelier outcome out of the current generation of AI systems
- flexible hours: we measure productivity in terms of outcomes, not time, so as long as you're able to stay aligned, productive, and in regular communication, we don't really care what hours you work
- health insurance
Please reach out to: nikhil (at) buildbetter (dot) app
Most QA, most analyst positions, a good chunk of the kludge in intellectually challenging jobs, like medical diagnostics or software engineering, most administrative work, including in education and in healthcare, about 80% of customer success, about 80% of sales, are all within striking distance of automation with current-generation LLMs. And taht's entirely ignoring the 2nd-order effects in robotics and manufacturing.
You don't need LLM to replace QA. Just fire them, push some testing to developers and the rest to the users. Shareholders will be pleased by budget efficiency!
Just a moment to reflect on how much freaking leverage computers give us today - a single permission change took down half the internet. Truly crazy times.
BuildBetter | Senior Engineer (Backend, Full-stack) | Full-Time | Remote (US) | 170-200k base + equity | Visa Sponsorship not provided
BuildBetter is the product operations platform for customer-led teams. We've built an AI-first product that lets our customers, like Rappi, n8n, and Posthog, automate the operations work that lets them provide their customers with world-class product experiences.
We're looking for two senior engineers to join the team; our headcount has remained small while growing revenue, and we're now bottlenecked by development speed in a way that will make you invaluable. You'll have real ownership over your code from product ideation to customer support, and we'll be making substantive product updates weekly. We're looking for team players who are as fun to work with as they are productive, and are willing to compensate these two rolls commensurately - our aim is to be in the 95th percentile of equity compensation, and we expect that in exchange we'll have value-aligned employees who will help us grow the business.
Joining us will mean solving hard problems at the frontier of AI adoption, including:
- maintaining performance at scale
- building and maintaining rich frontend user experiences that maintain the standards of usability and delight that our customers know us for.
- building agent and workflow systems that automate real work for customers
- playing around with the latest models to figure out new experiences that we can offer our customers as cutting-edge models get released monthly
- building automation that's grounded in supporting product teams rather than automating them - our bet is that this is the likelier outcome out of the current generation of AI systems
- flexible hours: we measure productivity in terms of outcomes, not time, so as long as you're able to stay aligned, productive, and in regular communication, we don't really care what hours you work
- health insurance
ALSO LOOKING FOR:
Senior Product Designer | $105k - $180k USD | Design + code in HTML & CSS (Tailwind)
For engineering roles, please reach out at: nikhil (at) buildbetter (dot) app
For the designer role, please reach out at: adam (at) buildbetter (dot) app
Yes exactly, my theory is that the novelty of a new generation of LLMs’ performances tends to cause an inflation in peoples’ perceptions of the model, with a reversion to a better calibrated expectation over time. If the developer reported numerical evaluations that drifted over time, I’d be more convinced of model change.
Customer here, you're tripping. Recall provides transcription as an auxiliary service, not their core value prop.
Recall is, at its core, an API for bot recording. As someone building an application that relies heavily on conversational data, recording meetings is really important. Recall makes that process as easy as an API call, standardized across various meeting platforms. It's a huge PITA to set up infrastructure to get bots to join meetings that handle each platforms' proclivities, encoding and storing video data, etc.
The transcription service is just something they do to make transcribing recordings - one of the most common first post-processing steps for any conversational data - easier and lower friction.
knowledge cards at the top of Google results have been around for at least 12 years, I'd interpret the LLM-based responses as an iteration of a feature that's been around for a while rather than mimicking a competitor.
I would argue a machine that short-circuits the process of getting stuck in obtuse books is actually harmful long term...