Mit kodowania głosem
Gdy programiści słyszą "kodowanie głosem," większość wyobraża sobie kogoś dyktującego składnię Python: "def spacja calculate podkreślenie total otwórz nawias items zamknij nawias dwukropek..." To nie jest kodowanie głosem. To tortury.
Prawdziwe kodowanie głosem to nie o zamienianiu wejścia klawiatury na składnię. To o wykorzystywaniu twojego głosu dla dużej części rozwoju oprogramowania, która jest naturalnym językiem: dokumentacja, komentarze, wiadomości commit, opisy PR, podziały zadań, aktualizacje Slack i przeglądy kodu.
Stosunek naturalnego języka do składni w większości pracy rozwojowej jest wyższy niż większość programistów zdaje sobie sprawę. Dokładny programista może spędzić:
- 20% pisząc kod
- 30% pisząc dokumentację i komentarze
- 15% pisząc opisy problemów i zawartość PR
- 20% w Slack, e-mailu i spotkaniach
- 15% na przeglądzie kodu i planowaniu
To 80% pracy gdzie wprowadzanie głosu jest albo szybsze niż pisanie albo równie efektywne. 20%, które jest rzeczywistą składnią, pozostaje na klawiaturze.
Co dyktować jako programista
Komentarze kodu
Komentarze to czysty naturalny język. Napisanie jasnego komentarza wyjaśniającego dlaczego funkcja istnieje, jakie przypadki brzegowe obsługuje, lub co osoba dzwoniąca powinna wiedzieć, jest łatwiej mówić niż wpisywać.
Przepływ pracy: Nawiguj do lokalizacji komentarza w edytorze, naciśnij hotkey, mów wyjaśnienie, zwolnij. Tryb Clean usuwa wypełniacze i tworzy czysty tekst.
Przykład: Naciśnij hotkey, mów "ta funkcja obsługuje przypadek brzegowy gdzie token użytkownika wygasł, ale token odświeżający nadal jest ważny, próbuje jeden refresh, a następnie wymusza logout jeśli ten też nie powiedzie się, osoba dzwoniąca powinna obsługiwać AuthenticationError," zwolnij. Komentarz pojawia się sformatowany i czysty.
Dokumentacja i README
Pliki README, dokumentacja API i liniowe komentarze JSDoc/docstring to dokładnie gdzie wprowadzanie głosu doskonale się sprawdza. Piszesz dla czytającego człowieka w naturalnej prozie — tę samą rzecz, którą byś powiedział, jeśli ktoś zapytałby cię o wyjaśnienie kodu.
Mówienie dokumentacji funkcji patrząc na kod tworzy lepszą dokumentację niż pisanie jej. Naturalnie opisujesz to, co widzisz, bez tarcia translacji myśli na uderzenia klawisza.
Komunikaty commit
Dobre komunikaty commit to krótka proza: co się zmieniło i dlaczego. Mówienie komunikatu commit jest szybsze niż wpisanie, a tryb Clean zapewnia, że czyta się dobrze.
Opisy Pull Request
Opisy PR — problem, rozwiązanie, plan testu, notatki recenzenta — to dokładnie rodzaj strukturalnej zawartości, którą Telvr obsługuje dobrze. Tryb Dev Task tworzy tę strukturę natywnie.
Przykład: Naciśnij hotkey, przełącz się na tryb Dev Task, mów "naprawiłem warunek wyścigu w przepływie przetwarzania płatności, problem był dwa jednoczesne żądania mogą oba sprawdzić saldo zanim którykolwiek je odliczył, dodałem blokadę wiersza na poziomie bazy danych wokół transakcji, dodałem test, który spawa dwa jednoczesne próby płatności," zwolnij. Wynikiem jest strukturalny opis PR z problemem, rozwiązaniem i uwagami testowania.
Opisy problemów i biletów
Napisanie szczegółowego raportu o błędzie lub specyfikacji funkcji przez pisanie jest nudne. Mówienie jej naturalnie patrząc na problem jest szybsze i często tworzy bardziej dokładne opisy, ponieważ nie walczysz z mechanicznym obciążeniem pisania.
Aktualizacje Slack i zespołu
Aktualizacje postępu, zablokowania, podsumowania standup — te są rozmowne z natury. "Wczoraj skończyłem refaktor auth, dziś pracuję nad integracją płatności, zablokowany na otrzymywaniu poświadczeń test dla środowiska sandbox, zapytam Sarah." To kompletny standup w 15 sekundach mowy.
Konfiguracja dla przepływów pracy programisty
Konfiguracja hotkey
Domyślny hotkey Telvr (Option + Space na Mac) działa dobrze dla programistów, ponieważ nie konfliktuje z większością skrótów IDE. Jeśli wolisz coś innego, hotkey można konfigurować.
Rekomendowana konfiguracja dla programistów:
- Trzymaj ręce na home row
- Użyj kombinacji dwóch klawiszy, aby zapobiec przypadkowemu aktywowaniu w terminalu
- Unikaj hotkeyi, które konfliktują z twoim IDE (sprawdź VS Code lub JetBrains keymaps)
Wybór trybu
Dla przepływów pracy programisty:
- Tryb Clean: Ogólne komentarze, dokumentacja w prozie, wiadomości Slack
- Tryb Dev Task: Opisy PR, specyfikacje problemów, streszczenia wymagań technicznych
- Tryb Meeting Notes: Notatki retro po sprincie, podsumowania dyskusji designu
- Tryb Email: Komunikacja techniczna obok klienta, aktualizacje statusu dla nie-technicznych stakeholderów
Integracja IDE
Telvr używa ogólnosystemowego wstawiania tekstu, co oznacza, że działa w każdym polu tekstowym w każdej aplikacji. To obejmuje:
- VS Code (edytor kodu, zintegrowany terminal, wyszukiwanie, komentarze)
- JetBrains IDE (IntelliJ, WebStorm, PyCharm)
- Zed, Neovim (będąc w trybie insert)
- Linear, Jira, GitHub (w przeglądarce)
- Terminal (gdy wpisując nie-polecenie tekst takie jak wiadomości git commit)
Nie ma pluginu do instalacji. Każde edytowalne pole tekstowe jest dozwolone.
Rzeczywisty przepływ pracy programisty
Oto jak sesja tworzenia z wprowadzaniem głosu wygląda w praktyce:
Poranny standup w Slack: Naciśnij hotkey, mów wczorajszy postęp + dzisiejszych plan + blokady, zwolnij. Gotowe w 20 sekund.
Pisanie kodu: Klawiatura. Normalny przepływ pracy tworzenia.
Dodawanie komentarza do złożonej funkcji: Nawiguj do właściwej linii, naciśnij hotkey, mów wyjaśnienie naturalnie, zwolnij.
Tworzenie GitHub issue dla błędu: Otwórz nowy issue, naciśnij hotkey z trybem Dev Task, opisz błąd i kroki reprodukcji, zwolnij. Zatytułuj issue, prześlij.
Pisanie komunikatu commit:
git commit w terminalu, naciśnij hotkey w edytorze, który się otwiera (lub pipe do pliku), mów opis commit, zwolnij.
Pisanie opisu PR: Otwórz formularz PR, naciśnij hotkey z trybem Dev Task, wyjaśnij co robi PR i dlaczego, zwolnij. Dodaj notatki recenzenta jeśli potrzeba.
Odpowiadanie na techniczne pytanie w Slack: Naciśnij hotkey, wyjaśnij techniczną decyzję lub koncepcję na głos, zwolnij. Tryb Clean tworzy czytelne wyjaśnienie bez konieczności pisania ostrożnie.
Rzeczywistość produktywności
Największe zyski z wprowadzania głosu w tworzeniu pochodzą nie z surowej szybkości, ale ze zmniejszenia tarcia. Dokumentacja jest często odkładana lub całkowicie pomijana, ponieważ pisanie jej wydaje się obciążeniem ponad rzeczywistą pracę pisania kodu. Gdy napisanie komentarza lub docstring trwa 15 sekund mowy zamiast 2 minut dokładnego pisania, próg dodania go znacznie się zmniejsza.
Lepiej udokumentowany kod, bardziej kompletne opisy PR i dokładniejsze raporty problemów są często praktycznym wynikiem wprowadzania głosu programisty — nie tylko szybszym wykonaniem tych samych nawyków.
Jeden tydzień do nowego nawyku
Wprowadzanie wprowadzania głosu do twojego przepływu pracy tworzenia:
Dzień 1: Używaj głosu tylko dla wiadomości Slack. Nic innego.
Dzień 3: Dodaj komunikaty commit. Mów opis w edytorze terminala.
Dzień 5: Dodaj komentarze liniowe. Zacznij narrację złożonych funkcji kiedy je kończysz.
Dzień 7: Dodaj opisy PR z trybem Dev Task. Zauważ, że piszesz bardziej kompletne opisy niż wcześniej, ponieważ mówienie jest szybsze niż pisanie.
Po dwóch tygodniach, nawyki są ustalone i wprowadzanie głosu wydaje się naturalne zamiast wysiłkowe.