เดือนแรกของคุณในสตาร์ทอัพจะสร้างความเปลี่ยนแปลงที่ชัดเจน มันไม่มีการค่อยเป็นค่อยไป ไม่มีการนั่งดูวิดีโอปฐมนิเทศเป็นสัปดาห์เพื่อรอฝ่าย IT จัดเตรียมแล็ปท็อปให้ ในวันแรก คุณถูกคาดหวังให้สร้าง ทำพัง และแก้ไขสิ่งต่างๆ ที่ผู้คนใช้งานจริง ผมเรียนรู้เรื่องนี้ได้อย่างรวดเร็วหลังจากเข้าร่วมงานกับ Treevah บริษัทที่สร้างเครื่องมือเพื่อช่วยให้ผู้หางานจัดการใบสมัครของพวกเขาได้ง่ายขึ้น สามสิบวันในสภาพแวดล้อมของบริษัทระยะเริ่มต้นสอนผมเรื่องการพัฒนาซอฟต์แวร์ได้มากกว่าในห้องเรียนหรือการแข่งขันใดๆ ที่เคยเจอมา
จังหวะการทำงานที่รวดเร็วและไม่หยุดหย่อน
ที่ Treevah งานไม่รอให้คุณปรับตัวได้เสียก่อน ทีมกำลังเร่งผลักดันผลิตภัณฑ์จาก alpha ไปสู่ beta และเข้าสู่ production ในที่สุด ซึ่งหมายความว่าทุกงานล้วนมีความสำคัญ ไม่มีที่ว่างสำหรับงานที่ทำไว้แค่พอเป็นพิธี หรือการสั่งงานที่ถูกเก็บทิ้งไว้ในกล่องจดหมายของอาจารย์ เมื่อคุณปล่อยฟีเจอร์หนึ่งออกมา มันจะถูกส่งตรงไปยังผู้ใช้งานที่กำลังพยายามติดตามกำหนดการ สัมภาษณ์ และการติดตามผลในขณะที่กำลังมองหางานใหม่
จังหวะการทำงานนั้นน่าเหนื่อยล้า คุณต้องเคลื่อนที่อย่างรวดเร็วในทุกๆ วัน และปริมาณงานก็พอกพูนเร็วกว่าที่คุณคาดคิด เดดไลน์ไม่ใช่เรื่องนามธรรม แต่มันผูกติดกับหมุดหมายสำคัญ (milestones) ที่เป็นตัวกำหนดว่าบริษัทจะสามารถให้บริการผู้หางานได้มากขึ้น หรือจะสามารถแก้ไขช่องโหว่ในประสบการณ์การใช้งานปัจจุบันได้หรือไม่ ความกดดันนั้นทำให้คุณล้า แต่ในขณะเดียวกันมันก็สร้างความชัดเจนที่หาได้ยากในองค์กรขนาดใหญ่ เมื่อผมทำงานเสร็จ ผมสามารถลากเส้นตรงเชื่อมโยงระหว่างสิ่งที่ผมสร้าง กับคนที่สามารถจัดการการหางานของเขาได้ง่ายขึ้น ความรู้สึกของการเป็นเจ้าของงาน (ownership) นั้นหาได้ยาก และมันทำให้ความเหนื่อยล้านั้นดูคุ้มค่า
ทักษะพัฒนาแบบก้าวกระโดดเมื่อได้ทำงานจริง
ก่อนหน้านี้ในช่วงฤดูร้อน พลังงานส่วนใหญ่ของผมหมดไปกับการพูดในที่สาธารณะและการแข่งขัน hackathon ทั้งสองอย่างสอนให้ผมรู้จักการคิดแก้ปัญหาเฉพาะหน้าและนำเสนอไอเดียภายใต้ความกดดัน โดยเฉพาะ hackathon ที่ฝึกให้คุณประกอบร่างเดโมให้ใช้งานได้ภายในไม่กี่ชั่วโมง แต่มีความแตกต่างระหว่างโปรเจกต์ช่วงสุดสัปดาห์ที่ทำเพื่อสร้างความประทับใจให้กรรมการ กับ production code ที่ต้องอยู่รอดจากการใช้งานจริงของผู้ใช้หลายร้อยคน
การใช้เวลาหนึ่งเดือนมุ่งเน้นไปที่การพัฒนาเว็บที่ Treevah ช่วยปิดช่องว่างนั้น ในโรงเรียน โปรเจกต์ต่างๆ จะมีขอบเขตที่กำหนดไว้ชัดเจน ขอบเขตงานถูกกำหนดมาให้แล้ว ข้อกำหนดต่างๆ ถูกป้อนให้ถึงที่ และถ้า database schema ของคุณพัง คุณก็แค่สามารถอธิบายเหตุผลในสไลด์นำเสนอได้ แต่ภายในสตาร์ทอัพ schema ของคุณต้องแข็งแกร่ง เพราะผู้หางานจริงๆ กำลังเก็บข้อมูลการสมัครงานจริงๆ ไว้ในนั้น วงจรการตอบกลับ (feedback loop) นั้นรวดเร็วและไม่ปรานี เมื่อหน้าเว็บโหลดช้าหรือฟอร์มบันทึกข้อมูลไม่สำเร็จ จะไม่มีใครสนใจเกรดของคุณ พวกเขาสนใจแค่ว่าพวกเขาเพิ่งพลาดโอกาสสำคัญไปหรือไม่
ความกดดันนั้นบีบให้เกิดการเติบโต คุณเรียนรู้ที่จะเขียนโค้ดให้สะอาดขึ้น ไม่ใช่เพราะเกณฑ์การให้คะแนนสั่ง แต่เพราะคุณจะเป็นคนที่ต้องมานั่งไล่แก้บั๊ก (debugging) ตอนเที่ยงคืน คุณเรียนรู้ที่จะตั้งคำถามที่เฉียบคมขึ้นในระหว่างการทำ code review เพราะการ deploy build ที่พังหมายถึงผู้ใช้งานจริงต้องเจอกับอุปสรรค โอกาสในที่แห่งนี้ส่งผลกระทบต่อคุณแรงกว่าโปรเจกต์ในโรงเรียน ความผิดพลาดมีราคาที่ต้องจ่ายสูงกว่า ดังนั้นบทเรียนจึงฝังลึกกว่า
ความจริงที่น่าตื่นตะลึงของบั๊ก
หากมีมายาคติอย่างหนึ่งที่ผมอยากจะทำลายทิ้ง นั่นคือความคิดที่ว่าบั๊กของซอฟต์แวร์ทุกตัวต้องเป็นความล้มเหลวทางตรรกะที่ยิ่งใหญ่ แน่นอนว่าบางตัวก็เป็นเช่นนั้น แต่บั๊กหลายตัวที่ผมเจอที่ Treevah กลับเป็นเรื่องเล็กน้อยจนน่าหงุดหงิด พวกมันซ่อนตัวอยู่ในที่ที่เห็นได้ชัดและทำให้ผมเสียเวลาไปหลายชั่วโมง
มีรูปแบบสองอย่างที่ปรากฏขึ้นซ้ำๆ อย่างแรกคือ กฎ CSS ที่ซ้ำซ้อน เมื่อนักพัฒนาหลายคนแตะต้องคอมโพเนนต์เดียวกันในช่วงหลาย sprints ไฟล์ stylesheet จะเริ่มบวมขึ้น คนหนึ่งอาจเพิ่ม margin utility class ในขณะที่อีกคนกำหนดค่าแบบ hardcode ลงในไฟล์คอมโพเนนต์ ซึ่งทั้งคู่ไม่ได้ผิดหากมองแยกกัน แต่เมื่อรวมกันพวกมันกลับสร้าง layout shifts หรือสงครามความสำคัญของ CSS (specificity wars) ที่ทำให้ปุ่มดูดีบน Chrome แต่พังบน Safari การตามหาต้นตอหมายถึงการต้องเปิด browser dev tools และไล่ดู computed styles ทีละบรรทัด แทนที่จะได้อ่านตรรกะอัลกอริทึมที่สวยงาม
อย่างที่สองคือการกำหนดตำแหน่ง element ไว้นอก parent divs ของมัน ตัว modal trigger หรือ dropdown อาจถูก append เข้าไปใน node ที่ผิดใน DOM หน้าจออาจจะดูเกือบถูกต้องจนคุณคิดว่าโครงสร้างนั้นสมบูรณ์แล้ว แต่แล้วความขัดแย้งของ z-index ก็ปรากฏขึ้น หรือ click event อาจจะ bubble ไปยัง handler ที่ผิด และทันใดนั้นผู้ใช้งานก็ไม่สามารถปิด popup ที่บังฟอร์มใบสมัครของพวกเขาได้ สิ่งเหล่านี้ไม่ใช่ปริศนาทางวิทยาการคอมพิวเตอร์ แต่มันคือความผิดพลาดทางโครงสร้างและตำแหน่งที่เกิดขึ้นได้ง่ายเมื่อคุณต้องทำงานด้วยความรวดเร็ว
บั๊กบางตัวต้องใช้เวลาหลายสัปดาห์กว่าจะหาเจอ ผมมักจะจ้องมองโค้ด พยายามโน้มน้าวตัวเองว่าตรรกะมันถูกต้องแล้ว และหลงทางไปในเส้นทางที่ตันซึ่งไม่ได้นำไปสู่สิ่งใดเลย ความรู้สึกหงุดหงิดนั้นเป็นเรื่องจริง คุณจะรู้สึกเหมือนว่าคุณกำลังมองข้ามอะไรบางอย่างที่มันชัดเจนมาก และคุณก็มองข้ามมันจริงๆ แต่ความพึงพอใจเมื่อในที่สุดก็ตรวจพบกฎที่ซ้ำซ้อนหรือแท็กปิดที่วางผิดที่นั้นก็น่าประหลาดใจ