Перестаньте читати, щоб наповнити бібліотеку. Почніть читати, щоб вирішити проблему.

Більшість списків літератури для інженерів зосереджені на накопиченні знань. Сучасна інженерія винагороджує за усунення вузьких місць.

Нещодавно молодший інженер показав мені список «Топ-10 книг для інженерів». Він виглядав так само, як і списки десятирічної давнини. Він ґрунтувався на тому самому старому припущенні.

Припущення полягає в тому, що читання достатньої кількості книг робить вас кращим інженером. Високоефективні команди навчаються інакше.

Найкращі інженери будують плани навчання навколо обмежень.

Стандартні списки читання припускають, що всі знання мають цінність. Насправді ж інженерна цінність залежить від контексту.

• Бекенд-інженеру, який стикається з проблемами бази даних, не потрібна книга про Agile. • Команді, яка витрачає занадто багато на AI inference, не потрібна загальна книга про майстерність (craftsmanship). • Стартапу, який стикається з проблемами затримки (latency), не потрібна методологія лідерства.

Цим людям потрібні рішення для конкретного вузького місця, з яким вони стикаються. Списки читання оптимізовані під повноту. Інженерія ж винагороджує за релевантність.

Основи, такі як бази даних та мережі, все ще важливі. Але цього вже недостатньо.

Сучасні системи приносять нові обмеження. Витрати на AI inference — яскравий приклад. Традиційні списки рідко охоплюють такі проблеми.

Виклик полягає вже не лише в написанні правильного програмного забезпечення. Виклик полягає в побудові надійних систем на основі ймовірнісних компонентів.

У минулому інженери працювали з детермінованими системами. Один і той самий вхід давав один і той самий результат.

Сьогодні системи поводяться інакше. Промпт дає різні відповіді. Агент обирає різні шляхи. Оновлення моделі змінює поведінку системи, навіть якщо ви не змінювали свій код.

Нові питання такі: • Як оцінити якість? • Як керувати цими змінами?

Це не граничні випадки. Це повсякденні інженерні завдання.

Сильні інженери не читають книги від корки до корки. Вони читають заради механізмів. Вони знаходять вузьке місце, визначають механізм і вивчають лише те, що їм потрібно.

• Якщо затримка (latency) висока, вивчайте batching. • Якщо є проблеми з контекстом, вивчайте retrieval. • Якщо агенти дають збій, вивчайте evaluation.

Це безпосередньо пов'язує навчання з продакшеном. Знання стають важелем впливу.

Використовуйте цей цикл навчання:

  1. Визначте вузьке місце.
  2. Знайдіть конкретний ресурс для вирішення цієї проблеми.
  3. Застосуйте рішення.

Перестаньте намагатися прочитати весь список. Почніть намагатися покращити систему.

Перш ніж братися за наступну книгу, запитайте себе: Яке найбільше обмеження у моїй системі?

Це затримка, вартість, надійність чи спостережуваність?

Знайдіть ресурс, який допоможе подолати це вузьке місце. Інженерія — це не змагання з читання. Це професія, що полягає у вирішенні обмежень.

Саме система диктує, що вам варто вивчати далі.

Джерело: https://dev.to/neilton_rocha_dev/stop-reading-to-build-a-library-start-reading-to-solve-a-problem-55ag