Je strašně vidět, že pracujete tendenčně projektově místo produktově, i když máte třeba osobní zodpovědnost za provoz. Nemáte prostě jeden produkt, který řešíte ze všech různých úhlů pohledu. (Tedy aspoň to tak působí a je to úplně v pořádku, ale ovlivňuje to Váš pohled.)
Díky různým zkušenostem od dobrovolné práce ve studentské síti, práce ve velmi tradiční firmě, různé další pozice až nakonec po velmi netradiční startup (OrgPad jsem teď) je to všude diametrálně odlišné. U projektu samozřejmě může být střídání gard poměrně rychlé, může být pomalé. Kód může být dobrý natolik, že se základní myšlenka především rozšiřuje a nebo se pořád znovu dokola přepisuje pomocí jiných přístupů. To samé samozřejmě může být u produktu, ale obyčejně je tam kontinuita větší, co tak vnímám.
Startup je zajímavý tím, že exponenciální růst přináší různé výzvy v rychlé řadě za sebou. Věci se ze začátku udělají nějak, aby se neztrácela data, aby to nějak chodilo apod. potom se kontinuálně věci zlepšují. Přidává se postupně dle potřeby schopnost běžet např. s více aplikačními servery, přidává se HA, více se řeší monitoring a metriky atd. Kdyby se ale všechno dělalo od začátku "správně", tak by se nikdy nezačalo/ došly by finance před vstupem na trh. Ano, taky jsem si musel na tento přístup nejdřív zvyknout, to je rozdíl v tom, že už nejsem zaměstnanec v etablované tradiční firmě, ale vlastně spíš jakoby v roli zakladatele/ investora v něčem úplně novém. Rozdíl je taky v tom, že se vhodné řešení vlastně pořád hledá, zatímco jinde je často nasnadě. To je velká výhoda (a současně nevýhoda) tradiční firmy, kdy je problematika do určité míry již prozkoumaná - není moc prostor na nový pohled.
Nakonec bych řekl, že bychom se měli vyvarovat tomu označovat něco, na čem pracujeme zrovna my za to nejdůležitější na daném projektu/ produktu. Důležitý je celek. Každopádně uživateli je databáze fakt jedno, když mu neztrácí/ nerozbíjí data a nečeká zbytečně na výsledky - zajímá ho ale rozhraní ať už je to GUI nebo nějaké API, se kterým komunikuje, třeba ten našeptávač a celkový dojem ze sčítání.
Mimochodem k tomu výkonu a důležitosti je jednoznačně z těch tvrdých kompetencí u OrgPadu důraz na frontendu. Přenos dat/ čekání na data je minimum stráveného času. Spíš se čeká na DOM v prohlížeči s čímž lze udělat poměrně málo, pokud nechceme dělat rendering úplně ve vlastní režii. Mimochodem na výkonu backendu se pracovalo třeba 2 týdny za rok a půl fungování, z toho většinu času ale šlo o zásadní změnu infrastruktury pro migraci z Heroku na vlastní infrastrukturu, což mělo za vedlejší efekt lepší výkon, fokus měly ale spíš jiné provozní vlastnosti. Explicitně na výkonu frontendu čistě z hlediska kódu se pracovalo minimálně měsíc, spíš déle.
I z hlediska kódu je backend zlomek frontendu a to i kdybych srovnal jen části s logikou (tedy bez GUI na frontendu). Uživatelé OrgPadu používají produkt jen a pouze kvůli tomu, jak se ovládá a jak funguje. To, že běží a že neztrácí data se tiše předpokládá. Nikdo tohle zmiňovat nebude, podobně jako nezmiňujeme u auta, že je fajn, že ve většině případů jede.
Je zajímavé si ale počíst o tom, jak jdete od databáze k aplikaci, jak různé věci řešíte. Váš poslední odstavec to dobře shrnuje.