Kilka prognoz na 2025 rok, które nigdy się nie spełniły: • Młodsi programiści mieli być całkowicie zastąpieni • Inżynierowie promptów mieli być najwyżej opłacanym zawodem w technologii • Każda firma miała prowadzić autonomiczne agenty AI • Wszyscy mieli być w stanie tworzyć gry wideo za pomocą kodu do tej pory • Ręczne pisanie kodu miało być przestarzałe • Większość firm nie miała już zatrudniać inżynierów Nic z tego się nie wydarzyło. Niektóre z tych rzeczy mogą nigdy się nie zdarzyć.

Ostatnio zyskałem ogromny szacunek dla programistów odczuwających wibracje. Siedzimy na naszych wysokich koniach, mówiąc im, że ich kod jest do niczego i że modele nie mogą naprawić ich bałaganu, ale oni po prostu się tym nie przejmują. Wielu z tych ludzi po prostu optymalizuje pod kątem innego wyniku. Dla nich kod to tylko środek do celu. Nie obchodzi ich utrzymanie, elegancja czy poprawność, ponieważ nie planują dotykać tego kodu. Zależy im na dostarczeniu swojego pomysłu, zanim o nim zapomną. Czy wiesz, ile pomysłów miałem, których nigdy nie zrealizowałem, bo nie miałem czasu lub byłem zbyt leniwy, żeby wstać z kanapy? Mogę się nauczyć czegoś od ludzi, którzy są gotowi działać, nawet gdy tylu arystokratów mówi im, że nie powinni.

Konsultowałem dla ponad 100 firm w ciągu ostatnich 3 lat, a oto niektóre z moich osobistych ulubionych rekomendacji: (Naprawdę zdziwiłbyś się, jak wielu programistów poza internetową bańką potrzebuje pomocy.) 1. Niektóre zespoły nie używają żadnego systemu wersjonowania kodu. Wiem, że to trudne do uwierzenia, ale mam świadków. Szczerze mówiąc, to nie jest powszechne, ale widziałem to na własne oczy. 2. Kultura testowania jest rzadka. Łatwym sposobem na poprawę tego, co robi zespół, jest nauczenie ich, jak pisać zautomatyzowane testy jednostkowe i integracyjne. 3. Arkusze kalkulacyjne to najpopularniejsze rozwiązanie, jakie widziałem w terenie. Na przykład, jedną z moich najczęstszych rekomendacji jest użycie MLFlow do śledzenia eksperymentów i wersjonowania modeli. 4. Większość zespołów zawsze chce wdrożyć technicznie poprawne rozwiązanie dla problemu. Nauczyłem się bardzo dobrze identyfikować rozwiązania, które spełniają znacznie więcej ograniczeń (takich jak budżet, harmonogram, umiejętności zespołu, postrzeganie itp.). Nazywam to "ramowaniem problemu" i jest to ogromna pomoc dla firm. 5. Zawsze polecam kontenery deweloperskie tym zespołom, w których każda osoba używa innego systemu operacyjnego i ma problemy z konfiguracją i przenośnością. 6. Spróbuj skalować aplikację, nie poświęcając czasu na obserwowalność i śledzenie. Najczęściej jest to tak proste, jak rejestrowanie odpowiednich informacji. Czasami możesz poświęcić czas na skonfigurowanie odpowiednich narzędzi do bardziej zaawansowanej obserwowalności. 7. W systemach uczenia maszynowego (90% projektów, z którymi się zajmuję) monitorowanie zawsze jest myśleniem wtórnym. Nauczyłem się całkiem dobrze pomagać zespołom w integracji z Evidently AI. 8. Spędzam mnóstwo czasu, pomagając zespołom budować end-to-end, powtarzalne i automatyzowalne przepływy pracy z miejscami do wypełnienia, które mogą uzupełnić później. Na przykład, budując pipeline treningowy, który zaczyna się od przetwarzania danych i kończy na wdrożeniu modelu. Wiele różnych praktyk zawsze pojawia się w różnych zespołach: • Jak wdrożyć CI/CD • Jak wersjonować zbiory danych • Jak wiedzieć, co oznacza "zrobione" • Jak prawidłowo zarządzać sekretami • Jak zarządzać ustawieniami konfiguracyjnymi • Jak konfigurować logi • Jak testować w produkcji (testy a/b, wdrożenia w cieniu itp.) • ... Ludzie pracujący dla dużych firm technologicznych są lata świetlne przed wszystkimi innymi, ale rynek tej wiedzy poza dużymi technologiami jest ogromny.