اولین ماه شما در یک استارتاپ، تأثیری ماندگار بر جای میگذارد. هیچ دوره آمادگی آرامی وجود ندارد و خبری از هفتهها تماشای ویدئوهای توجیهی در انتظار آمادهسازی لپتاپ توسط بخش IT نیست. از روز اول، از شما انتظار میرود چیزهایی بسازید، آنها را خراب کنید و سپس تعمیرشان کنید؛ چیزهایی که افراد واقعی واقعاً از آنها استفاده خواهند کرد. من این موضوع را پس از پیوستن به Treevah، شرکتی که ابزارهایی برای کمک به جویندگان کار جهت سازماندهی درخواستهایشان میسازد، به سرعت یاد گرفتم. سی روز فعالیت در یک محیط در مراحل اولیه، بیش از هر کلاس درس یا مسابقهای، درباره توسعه نرمافزار به من آموخت.
ریتم بیامان است
در Treevah، کار منتظر نمیماند تا شما با محیط سازگار شوید. تیم در تلاش است تا محصول را از مرحله آلفا به بتا و در نهایت به مرحله تولید (production) برساند، که این یعنی هر وظیفه وزن و اهمیت خاص خود را دارد. جایی برای کارهای گذرا یا وظایفی که فقط در صندوق ورودی یک استاد ذخیره میشوند، وجود ندارد. وقتی ویژگی (feature) جدیدی را عرضه میکنید، مستقیماً به دست کاربرانی میرسد که در حین جستجوی شغل بعدی خود، سعی در پیگیری ضربالاجلها، مصاحبهها و پیگیریها دارند.
سرعت کار خستهکننده است. هر روز با سرعت حرکت میکنید و حجم کار سریعتر از آنچه انتظار دارید انباشته میشود. ضربالاجلها انتزاعی نیستند؛ آنها با نقاط عطفی گره خوردهاند که تعیین میکنند آیا شرکت میتواند به جویندگان کار بیشتری خدمات ارائه دهد یا خیر، و یا اینکه شکافهای موجود در تجربه فعلی کاربران را برطرف کند. این سنگینی بر شما فشار میآورد، اما در عین حال وضوحی ایجاد میکند که در سازمانهای بزرگتر به سختی یافت میشود. وقتی وظیفهای را تمام میکنم، میتوانم خط مستقیمی بین آنچه ساختهام و فردی که اکنون مدیریت جستجوی کار خود را آسانتر انجام میدهد، ترسیم کنم. این حس مالکیت نادر است و باعث میشود خستگی هم ارزشش را داشته باشد.
مهارتها در محیط عملیاتی سریعتر رشد میکنند
قبل از این تابستان، بخش زیادی از انرژی من صرف سخنرانی در جمع و شرکت در هکاتونها میشد. هر دو به من یاد دادند که چگونه در لحظه فکر کنم و ایدهها را تحت فشار ارائه دهم. بهویژه هکاتونها شما را تمرین میدهند تا در عرض چند ساعت، دموهای قابل اجرایی را سرهم کنید. اما تفاوتی هست بین یک پروژه آخر هفته که داوران را تحت تأثیر قرار میدهد و کد تولیدی (production code) که باید در مواجهه با صدها کاربر واقعی دوام بیاورد.
گذراندن یک ماه تمرکز بر توسعه وب در Treevah این شکاف را پر کرد. در مدرسه، پروژهها با چارچوبهای محافظتی همراه هستند. محدوده پروژه ثابت است، نیازمندیها مرحلهبهمرحله به شما داده میشود و اگر ساختار پایگاه داده (database schema) شما از هم بپاشد، میتوانید آن را در یک اسلاید ارائه توجیه کنید. اما در یک استارتاپ، اسکیما باید پابرجا بماند، زیرا جویندگان کار واقعی در حال ذخیره دادههای واقعی درخواستهای خود در آن هستند. حلقه بازخورد فوری و بیرحمانه است. وقتی یک صفحه کند بارگذاری میشود یا یک فرم در ذخیرهسازی شکست میخورد، هیچکس به نمره شما اهمیت نمیدهد؛ آنها اهمیت میدهند که آیا همین حالا فرصتی را از دست دادهاند یا خیر.
این فشار باعث رشد میشود. شما یاد میگیرید کد تمیزتری بنویسید، نه به این دلیل که یک دستورالعمل از شما میخواهد، بلکه به این دلیل که خودتان کسی هستید که باید نیمهشب آن را عیبیابی (debug) کند. یاد میگیرید در بازبینی کد (code review) سوالات دقیقتری بپرسید، زیرا انتشار یک نسخه خراب به این معناست که کاربران واقعی با بنبست مواجه میشوند. فرصتها در اینجا بسیار پرقدرتر از پروژههای مدرسهای هستند. اشتباهات هزینه بیشتری دارند و به همین دلیل درسها ماندگار میشوند.
واقعیت فروتنانه باگها
اگر بخواهم یک باور غلط را به کلی از بین ببرم، آن باور این است که هر باگ نرمافزاری یک شکست منطقی دراماتیک است. البته برخی از آنها اینگونه هستند. اما بسیاری از باگهایی که در Treevah با آنها مواجه شدم، به طرز کلافهکنندهای کوچک بودند. آنها در مقابل چشم بودند و ساعتها از عمر من را تلف کردند.
دو الگوی خاص مدام تکرار میشدند. اولین مورد، قوانین تکراری CSS بود. وقتی چندین توسعهدهنده در طول چندین اسپرینت (sprint) به یک کامپوننت واحد دست میزنند، استایلشیتها حجیم و آشفته میشوند. یک نفر یک کلاس کاربردی margin اضافه میکند، در حالی که دیگری یک مقدار را مستقیماً در فایل کامپوننت وارد میکند (hardcode). هیچکدام از اینها به تنهایی اشتباه نیست، اما در کنار هم باعث تغییر در چیدمان (layout shifts) یا جنگهای اولویت (specificity wars) میشوند که باعث میشود یک دکمه در Chrome خوب به نظر برسد اما در Safari خراب باشد. ردیابی این موارد به معنای باز کردن ابزارهای توسعه مرورگر (browser dev tools) و بررسی خطبهخط استایلهای محاسباتی (computed styles) است، به جای اینکه صرف خواندن یک منطق الگوریتمی ظریف شود.
دومین مورد، تعریف عناصر خارج از divهای والد آنها بود. یک trigger برای modal یا یک dropdown ممکن است به گره (node) اشتباهی در DOM اضافه شود. صفحه تقریباً درست به نظر میرسد، بنابراین فرض میکنید ساختار سالم است. سپس یک تداخل z-index ظاهر میشود، یا یک رویداد کلیک (click event) به هندلر اشتباهی منتقل میشود (bubbles)، و ناگهان کاربر نمیتواند پاپآپای را که فرم درخواست او را پوشانده است، ببندد. اینها معماهای علوم کامپیوتر نیستند؛ بلکه لغزشهای مکانی و ساختاری هستند که هنگام حرکت سریع، روی هم انباشته میشوند.
پیدا کردن برخی از این باگها هفتهها طول میکشید. به کد خیره میشدم، خودم را متقاعد میکردم که منطق درست است و در بنبستهایی سرگردان میشدم که به هیچجا نمیرسیدند. کلافگی واقعاً ملموس است. احساس میکنید چیزی بدیهی را از قلم انداختهاید، و واقعاً هم همینطور است. اما لذتِ بالاخره پیدا کردن یک قانون تکراری یا یک تگ پایانی جابهجا شده، بهطور غافلگیرکنندهای...