หลีกเลี่ยงการเป็นโปรแกรมเมอร์“ นักทฤษฎี”

ฉันได้พบนี้บทความในโพสต์หลายที่ดังนั้น ฉันพบว่าตัวเองตกอยู่ในแม่แบบที่ 6; "นักทฤษฎี"

มันกำหนด "นักทฤษฎี" เป็น:

นักทฤษฎีรู้ทุกอย่างเกี่ยวกับการเขียนโปรแกรม เขาหรือเธอสามารถใช้เวลาสี่ชั่วโมงในการบรรยายเกี่ยวกับประวัติของภาษาการเขียนโปรแกรมที่คลุมเครือหรือแสดงหลักฐานว่ารหัสที่คุณเขียนนั้นมีค่าน้อยที่สุดอย่างสมบูรณ์แบบและอาจใช้เวลาอีกสามนาโนวินาทีในการเรียกใช้ ปัญหาคือ Theoretician ไม่ทราบเกี่ยวกับการพัฒนาซอฟต์แวร์ เมื่อ Theoretician เขียนโค้ดมันเป็น“ ความงดงาม” ที่มนุษย์ปุถุชนไม่สามารถเข้าใจได้ เทคนิคที่ชื่นชอบของเขาหรือเธอคือการเรียกซ้ำและบล็อคของโค้ดทุกอันมีการปรับแต่งให้มากที่สุด

นักทฤษฎียังเบี่ยงเบนความสนใจได้ง่าย งานง่าย ๆ ที่ควรใช้เวลาหนึ่งชั่วโมงใช้เวลานักทฤษฎีสามเดือนเนื่องจากพวกเขาตัดสินใจว่าเครื่องมือที่มีอยู่ไม่เพียงพอและพวกเขาต้องสร้างเครื่องมือใหม่เพื่อสร้างห้องสมุดใหม่เพื่อสร้างระบบใหม่ทั้งหมดที่ตรงตามมาตรฐานระดับสูงของพวกเขา นักทฤษฎีสามารถกลายเป็นหนึ่งในผู้เล่นที่ดีที่สุดของคุณหากคุณสามารถทำให้เขาหรือเธอเล่นในขอบเขตของโครงการและหยุดใช้เวลาในการทำงานกับอัลกอริทึมการเรียงลำดับขั้นสูงสุด

แม้ในขณะที่ทำงานในสิ่งที่ควรเป็นโครงการที่เรียบง่ายฉันก็มักจะจมอยู่ในความพยายามที่จะควบคุมทุกสิ่งตั้งแต่เริ่มต้น (นี่อาจอธิบายได้ว่าทำไมฉันถึงเสียเวลาประมาณ 2 ปีที่พยายามสร้างระบบปฏิบัติการจากศูนย์ ในที่สุดก็ไม่มีจุดหมาย)

อะไรจะช่วยฉันหลีกเลี่ยงการทำสิ่งนี้? และยึดมั่นในหลักการ KISS?

ขอบคุณ

การเป็นนักทฤษฎีตามธรรมชาติฉันสามารถบอกคุณได้ว่าการทำงานในร้านค้าเปรียวจะช่วยรักษาแนวโน้มดังกล่าวได้อย่างรวดเร็วและเด็ดขาด โดยเฉพาะอย่างยิ่งการดำเนินการเขียนโปรแกรม eXtreme พร้อมการเขียนโปรแกรมคู่ (การหมุนบ่อยๆ) การพัฒนาโดยใช้การทดสอบการชกมวยเวลาและการวิ่งแบบ จำกัด ขอบเขตวางงานของคุณทันทีเพื่อให้เพื่อนร่วมงานของคุณเห็น ทุกนาที นี่คือการเปลี่ยนแปลงครั้งใหญ่จากงานที่แยกจากกันในสภาพแวดล้อมสำนักงานแยกซึ่งงานสไตล์ Theoretician เติบโตขึ้น มันต้องการความซื่อสัตย์และความซื่อสัตย์โดยรวมเนื่องจากทุกคนขึ้นอยู่กับคนอื่นอย่างต่อเนื่อง

ฉันยังคงมองสมบัติสะดือของฉัน แต่ฉันต้องทำตามใจตัวเองที่บ้านหรือในโอกาสที่หายากเหล่านั้นเมื่อฉันสามารถทำงานในโครงการด้านที่ไม่ได้เป็นส่วนหนึ่งของการพัฒนาสายหลัก

1. มีเป้าหมายสำหรับสิ่งที่คุณควรจะพัฒนา

2. จำกัด เป้าหมายเหล่านั้นให้เป็นสิ่งที่สามารถส่งมอบได้ในอนาคต

3. จากนั้นมุ่งเน้นไปที่เป้าหมายเหล่านั้นกำจัดข้อพิจารณาอื่น ๆ ไม่มีพื้นหลัง ไม่มีประวัติ ไม่มีส่วนขยาย ไม่มีอะไรทั่วไปหรือนามธรรม

4. จากนั้นให้แคบลงให้เหลือน้อยที่สุดเท่าที่คุณจะทำได้ ไม่ดี. ไม่ยืดหยุ่น ไม่สามารถบำรุงรักษาได้ ยอมรับได้เพียง

5. จากนั้นจัดลำดับความสำคัญเป็นค่าต่ำสุดสัมบูรณ์ที่จำเป็นเพื่อให้ได้อย่างน้อยที่สุดที่คุณสามารถทำได้ จุดคือการเลือกวันที่ในประมาณหนึ่งสัปดาห์และสร้างต่อวันที่ หากคุณไม่สามารถส่งมอบอะไรได้ภายในหนึ่งสัปดาห์ แคบ. โฟกัส การตัดแต่ง ลด.

6. จากนั้นกำจัดขนปุย คุณมีเพียงหนึ่งสัปดาห์ ตัดต่อไป

7. จากนั้นมุ่งเน้นไปที่การใช้งานที่ลดลงซึ่งจะทำเร็วที่สุด เป็นการดีที่น้อยกว่าหนึ่งสัปดาห์คุณจึงมีเวลาในการเขียนเอกสาร

ฉันทำงานกับนักทฤษฎี ฉันพิจารณาข้ออ้าง "พิเศษ" เพื่อหลีกเลี่ยงการทำสิ่งที่อาจติดป้ายว่าล้มเหลว

ทำ - และล้มเหลว - ยาก การพูดเกี่ยวกับการทำอะไรง่ายกว่าทำอะไรบางอย่าง การวิจัยและการคิดจำนวนมากเป็นวิธีหนึ่งที่จะหลีกเลี่ยงการทำสิ่งที่ผิดและจากนั้นกลับมาทำงานซ้ำหลังจากเรียนรู้ว่าผู้ใช้โกหก

เพียงแค่ใส่รหัสไว้ข้างหน้าพวกเขา พวกเขาจะเรียกรหัสล้มเหลว มันเกิดขึ้น. แต่ในกระบวนการของความล้มเหลวคุณจะได้เรียนรู้ว่าข้อกำหนดที่แท้จริงคืออะไร และคุณจะได้เรียนรู้ว่าพวกเขาโกหก

ฉันไม่แน่ใจว่านี่เป็นสิ่งที่เลวร้ายมาก เห็นได้ชัดว่าคุณต้องมีประสิทธิผลหรือคุณจะไม่ทำงาน แต่มีความสนใจในสาขาการเป็นนักเรียนศิลปะดังนั้นการพูดไม่ได้เลวร้าย

ฉันจะเล่นกับจุดแข็งของคุณมองหาโอกาสที่สไตล์และความชอบของคุณเป็นข้อได้เปรียบ

เพื่อให้มั่นใจว่าคุณจะยังคงทำงานได้อย่างมีประสิทธิภาพในขณะที่เขียนกรอบ MVC ใน Erlang (หรืออะไรก็ตามที่คุณสนใจ) คุณควรใช้เวลาในการทำงานที่มีความละเอียดมากกว่านี้พูดชั่วโมงต่อวัน ในช่วงเวลาที่เหลือของวันเพียงแค่มุ่งเน้นไปที่งานเสี้ยงฮึดฮัดแสดงความไม่พอใจและทำให้งานสำเร็จลุล่วง เมื่อคุณเห็นสิ่งที่น่าสนใจที่จะเบี่ยงเบนความสนใจคุณคั่นหน้ามันหรือจดบันทึก แต่ทำต่อไปจากนั้นกลับมาที่มันในช่วงเวลาที่กำหนด

โดยส่วนตัวฉันมีรีม URL ที่ดูน่าสนใจและมีหนังสือห้องสมุดมากมาย ฉันอาจได้รับประมาณ 10% ของ URL เหล่านั้นในตอนท้ายและอาจอ่านหนังสือ 50% ในตอนท้าย แต่ฉันก็ยังได้งานประจำวันเช่นกัน

ฉันมีปัญหานี้ด้วยตัวเอง เทคนิคสองอย่างช่วย:

1. ใช้เทคนิค Pomodoro หรือเทคนิคการจัดการเวลาอื่น ๆ ที่คุณกำหนดลำดับของเป้าหมายระยะสั้นมาก เมื่อคุณต้องคิดออกว่าคุณจะทำอะไรให้สำเร็จในอีก 25 นาทีมันจะทำให้คุณจดจ่อกับงานที่มีประโยชน์
2. การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ หากคุณต้องเขียนแบบทดสอบที่เป็นรูปธรรมก่อนที่คุณจะเขียนโค้ดใด ๆ มันจะช่วยลดการฝันกลางวัน (ไม่มีวิธีเขียนแบบทดสอบสำหรับ "สง่างาม") หลังจากที่คุณทำงานบางอย่างคุณอาจใช้เวลามากกว่าที่คุณควรจะทำการทดสอบใหม่ แต่อย่างน้อยคุณจะต้องทำงานกับโค้ดจริงมากกว่าอุดมคติในจินตนาการ

อย่าเอาชนะตัวเองมากเกินไป มันง่ายกว่าที่จะให้นักทฤษฎีมุ่งเน้นและทำงานที่มีประโยชน์มากกว่าเพื่อให้คนที่ไม่สนใจขยายขอบเขตของพวกเขา

หลีกเลี่ยงการstackoverflow.com ไม่ได้รับฉันผิด - ฉันเป็นแฟนใหญ่ - แต่ SO และฟอรั่มการเขียนโปรแกรมเชิงอื่น ๆ ทำให้สมบูรณ์แบบศัตรูของดี หลังจากผ่านไประยะหนึ่งคุณอาจเริ่มรู้สึกว่ามีคนฉลาดนับพันมองข้ามไหล่ของคุณและไม่มีอะไรที่คุณเขียนได้ดีพอ เพิ่งได้รับสิ่งที่ทำงานและพยายามทำให้เข้าใจ คุณสามารถเยี่ยมชมได้อีกครั้งหากต้องการการปรับปรุง

นอกจากนี้หลีกเลี่ยงบทความเช่นเดียวกับที่คุณเชื่อมโยง คุณเชื่อหรือไม่ว่ามีโปรแกรมเมอร์สิบประเภท หรือว่าทุกคนที่คุณรู้จักนั้นเป็นหมวดหมู่หนึ่งหมวดหมู่ที่อธิบายไว้ทั้งหมด? บทความเช่นนี้มีบางสิ่งที่น่าสนใจเพราะมันมีความจริงอยู่เล็กน้อยคุณสามารถเห็นตัวเองและ / หรือเพื่อนร่วมงานของคุณในแบบแผนบางอย่าง แต่หมวดหมู่ถือเกี่ยวกับน้ำมากที่สุดเท่าที่สัญญาณโหราศาสตร์ ลองครั้งนี้ในครั้งต่อไปที่คุณอยู่ที่มิกเซอร์หลังการประชุม: "สวัสดีฉันเป็นรหัสโคบาล!

นั่นไม่ใช่การบอกว่าคำถามของคุณไม่ถูกต้อง - หากคุณคิดมากกว่าจะดีเรียนรู้วิธีหลีกเลี่ยงแนวโน้มนั้น แต่อย่าปล่อยให้นักปราชญ์คนนี้พูดคุยกับคุณในการหานกพิราบตัวเอง

มีแนวทางง่าย ๆ อย่างหนึ่งซึ่งอธิบายเมื่อเต็มกล่องอย่างเต็มที่ในการหลีกเลี่ยงสถานการณ์นี้

ทำสิ่งที่ง่ายที่สุดที่อาจเป็นไปได้

- เคนท์เบ็ค

ฉันคิดว่าวิธีหนึ่งที่จะป้องกันไม่ให้คุณออกไปจากเมฆคือการบังคับให้คุณเขียนแอปพลิเคชันจริงตั้งแต่ต้นจนจบนอกเหนือจากการเขียน APIs หรือกรอบทฤษฎีของคุณ ลองใส่กล่องเวลาไปรอบ ๆ และลอง "เสร็จสิ้น" ภายในเวลานั้น เฟรมเวิร์กการเขียนต้องการความเข้าใจที่ดีเกี่ยวกับรูปแบบการออกแบบและสถาปัตยกรรม แต่ฉันพบว่าการเขียนแอปพลิเคชันที่สมบูรณ์ภายในระยะเวลาที่กำหนดต้องใช้ทักษะที่แตกต่างกว่าการเขียนกรอบการออกแบบที่ยอดเยี่ยม

หากคุณต้องการใช้งานแอปพลิเคชันให้เสร็จสมบูรณ์ในบางจุดคุณต้องพาตัวเองลงสู่พื้นดินและทำมันให้สำเร็จ สิ่งนี้อาจต้องเสียสละในการออกแบบหรือถูกบังคับให้ใช้คุณลักษณะในแบบที่คุณไม่พอใจเนื่องจากข้อ จำกัด บางประเภท ฉันชอบคุณ - มีแนวโน้มที่จะเขียนและเขียนสิ่งต่าง ๆ เป็นล้านครั้ง แต่ถ้าฉันต้องเผชิญกับงานที่ต้องทำภายในระยะเวลาที่กำหนดฉันพบว่าฉันเลือกการต่อสู้ของฉัน สิ่งที่สำคัญที่สุด

ง่าย ๆ :

1. มีการปฏิบัติ

ฝั่งตรงข้ามของ Theorician (ที่มีข้อได้เปรียบในด้านข้อมูล / ความรู้ของโดเมนการเขียนโปรแกรม) คือ Pragmatic

หากต้องการใช้ KISS, DRY, SOC และวิธีคิดอื่น ๆตามที่อธิบายไว้ในคำตอบนี้หมายถึงการใช้วิธีปฏิบัติแบบผึ้ง

นอกจากนี้คุณยังสามารถเรียนรู้ที่จะเน้นการปฏิบัติโดยการอ่านหนังสือเล่มนี้:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

อย่าลืมว่าทฤษฏีและการฝึกฝนทำงานด้วยกันไม่ใช่คนเดียว หากปราศจากการฝึกฝนคุณก็รู้ไม่มีอะไร หากปราศจากความรู้มากมายคุณจะไม่สามารถปรับปรุงการฝึกฝนได้อย่างรวดเร็ว

ดังนั้นฝึกมาก และเรียนรู้มากมาย แต่อย่าปล่อยให้คนอื่นข้าม

ในโครงการของคุณกำหนดเวลา ติดมัน จากนั้นคิดอย่างจริงจังเกี่ยวกับวิธีที่จะทำให้โครงการเสร็จก่อนกำหนด (อ่านหนังสือจริง ๆ ) จากนั้นเริ่มเขียนโค้ดเริ่มอ่านสิ่งที่คุณจำเป็นต้องรู้เปลี่ยนจากการอ่านเป็นการเข้ารหัสและ จำกัด หรือเวลาการอ่านของคุณ

อืม ... บางทีคุณอาจลองรับงานในธุรกิจที่ต้องให้คุณเขียนแอปพลิเคชันภายใต้ไทม์ไลน์ ฉันจะบอกกับตัวเองว่าฉันอาจจะห่างไกลจากการเป็นนักทฤษฎีเท่าที่คุณสามารถอย่างน้อยก็ในที่ทำงาน การทำงานประเภทนั้นมีสถานที่และเวลาและมีความสำคัญต่อการพัฒนาตนเอง อย่างไรก็ตามในขณะที่ฉันชื่นชมความสามารถแบบนั้นมันไม่มีที่ในโลกธุรกิจโดยเฉพาะอย่างยิ่งที่ฉันทำงาน สภาพแวดล้อมการพัฒนาที่รวดเร็วซึ่งคุณกำลังเขียนแอปพลิเคชันในบางสัปดาห์และลูกค้าต้องการเมื่อวานนี้! ฉันได้รับพรจากนักพัฒนาที่น่าทึ่งและใช้เวลาในการทำให้ทุกคนทำงานเป็นทีม

ฉันมีผู้ชายคนหนึ่งที่ยอดเยี่ยมที่สุดเท่าที่จะเป็นไปได้ แต่เช่นเดียวกับคุณต้องบีบรหัสสุดท้ายของเขาออกมาเล็กน้อยแม้ในขณะที่มันใช้งานได้ดีแม้กระทั่งจุดที่เขาเริ่มเขียนตัวควบคุมแบบกำหนดเอง เช่นเดียวกับที่ได้รับจากสภาพแวดล้อม มันเจ๋งมาก แต่ก็เป็นการเสียเวลาเมื่อเราต้องออกไปตรงเวลา บ่อยครั้งที่โครงการด้านนี้สนับสนุนทีมและในที่สุดเขาก็เริ่มรู้สึกถึงแรงกดดันจากคนอื่นและเขาก็มีรูปร่าง ฉันขอแนะนำให้เริ่มทำงานในสภาพแวดล้อมแบบทีมกับนักพัฒนาที่ดีคนอื่น ๆ ที่ต้องผลักดันผลิตภัณฑ์ออกไป มีเวลาอีกครั้งในการสร้างและทำซ้ำสิ่งต่าง ๆ หรือเขียน MergeSort ที่มีเตะมากที่สุดเท่าที่เคยมีมา แต่บางครั้งคุณต้องนำผลิตภัณฑ์ไปยังจุดที่มันใช้งานได้และนำมันออกไปให้ลูกค้า

ไม่มีอะไรผิดปกติกับการเป็น 'นักทฤษฎี' ในความหมายปกติของคำ การมีความรู้พื้นฐานและความสามารถในการเข้าใจงานวิจัยล่าสุดของ CS นั้นเป็นความสามารถที่ยอดเยี่ยมเนื่องจากเป็นแหล่งความคิดที่ดีและเป็นต้นฉบับ

'คำถามจริง' ที่นี่มีความชัดเจนมากขึ้นในช่วงครึ่งหลังของโพสต์ รู้เป้าหมายของโครงการที่เฉพาะเจาะจงและทำงานไปยังจุดสิ้นสุดนั้นไม่ใช่เป้าหมายอื่น ๆ มันเป็นเรื่องของการมีวินัยในตนเองในกรณีนี้ ดูคำตอบของ S. Lott สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้ :)

เน้นความคิดของคุณจากการเขียนโปรแกรมและแม้กระทั่งทำสิ่งต่าง ๆ ให้เป็นซอฟต์แวร์ที่ใช้งานได้ มันตั้งค่าความสำคัญของคุณ

วิธีการบรรลุเป้าหมายนี้เป็นอีกเรื่องหนึ่ง วิธีที่ดีที่สุดคือการคิดโครงการและทำตามทุกขั้นตอนเพื่อเริ่มการผลิต หลังจากนั้นคุณจะมีความคิดที่แตกต่างกว่าเดิม

ขอบคุณสำหรับโพสต์นี้ มันทำให้งานของฉันคุ้มค่ายิ่งขึ้นในขณะที่ ฉันรู้สึกเหมือนกันว่าได้รับการศึกษาด้านสถาปัตยกรรมข้อมูลที่ทำงานในฐานะนักพัฒนาซอฟต์แวร์ บ่อยครั้งที่ฉันพบว่าตัวเองกำลังดิ้นรนกับ "สถานที่ที่จะเปลี่ยนสิ่งต่าง ๆ " มากกว่า "สิ่งที่จะเปลี่ยนแปลง" มีความสัมพันธ์มากเกินไปสิ่งที่ฉลาดและสามัญมากเกินไปที่ใช้เวลานานเกินไปในการค้นหาว่ามันทำงานอย่างไร

ดังนั้นฉันจึงเริ่มถามคำถามและคำถามอื่น ๆ อีกมากมายจนกระทั่งฉันได้รู้จักวิธีการและสิ่งที่สร้างขึ้นจริง ๆ และให้ฉันบอกคุณ - มันใช้งานได้ ยิ่งมีคำถามมากขึ้นไฟก็จะยิ่งสำคัญน้อยลงในการรักษาสถาปัตยกรรมดั้งเดิมและสุดท้ายก็กลับไปสู่พื้นฐาน

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

ขอให้เจ้านายของคุณหาที่ปรึกษาจากนั้นทำตามที่ผู้ให้คำปรึกษาบอก

ส่วนที่ยากคือการมุ่งเน้นและรับรู้ว่า "เฮ้ลองเขียนระบบปฏิบัติการใหม่" จะไม่ได้รับประโยชน์อย่างมากต่อการทำงานที่คุณได้รับ (ซึ่งเป็นเหตุผลที่ผู้จัดการโครงการจะไม่ทำ)

ให้พี่เลี้ยงทบทวนการออกแบบทั้งหมดก่อนการเข้ารหัสและรหัสจริงหลังจากการเข้ารหัส สิ่งนี้จะช่วยให้คุณจดจ่อกับสิ่งที่ต้องทำ

ฉันมีสิ่งล่อใจแบบเดียวกันกับสิ่งที่มีวิศวกรมากเกินไปและต้องใช้ความมีวินัยในตนเองและการจัดระเบียบเพื่อให้ผ่านพ้นไป เมื่อเขียนโค้ดให้คนอื่นต่อไปนี้เป็นวิธีที่ฉันทำ:

1. เมื่อเริ่มงานที่ไม่ต่อเนื่องใช้เวลาคิดสักครู่เกี่ยวกับสิ่งที่ต้องการจริงๆเท่าที่ฟังก์ชั่นคุณภาพวันที่ส่งมอบ ฯลฯ
2. ใช้เวลามากขึ้นในการวางแผนวิธีการทำแบ่งงานย่อยงานย่อย ฯลฯ เพื่อรักษาเป้าหมายของลูกค้าในรหัส
3. ประเมินเวลาสำหรับแต่ละรายการเพิ่มขึ้นถึง 50% สำหรับสิ่งที่ไม่รู้จัก หากรายการใดรายการหนึ่งใช้เวลานานกว่าสี่ชั่วโมง (ถ้าฉันทำโครงการวิทยาลัยฉันจะใช้สเปรดชีต แต่ในฐานะที่ปรึกษากับลูกค้าหลายรายฉันใช้ระบบติดตามปัญหาที่เรียกว่า Redmine)
4. สิ่งสำคัญที่สุด: ทำสิ่งที่ฉันคิดขึ้นมาเท่านั้น

แน่นอนสิ่งที่เกิดขึ้น บางครั้งฉันก็พบว่าฉันต้องทำหลายอย่างมากขึ้นดังนั้นฉันจึงเริ่มใหม่ที่ # 1 บางครั้งฉันก็พบว่างานจะใช้เวลานานกว่าที่ฉันคิดไว้ - เริ่มใหม่ที่ # 1 บางครั้งฉันรู้ล่วงหน้าว่าการออกแบบของฉันจะต้องมีรายละเอียดเพิ่มเติมในภายหลัง - ดังนั้นฉันจึงวางแผนการประมาณย่อยใหม่ที่ฉันจะเริ่มใหม่ที่ # 1

ยิ่งฉันทำสิ่งนี้มากเท่าไหร่ ความมีวินัยในตนเองเป็นกล้ามเนื้อทางจิตใจที่เสริมสร้างความแข็งแกร่งด้วยการออกกำลังกายและฉันยังปรับปรุงการประเมินว่าจะใช้เวลานานแค่ไหนในการแลกเปลี่ยนเทคนิค และฉันคิดว่ามันมีประโยชน์ที่จะจำคำพูดของนายพลแพตตัน: "แผนการที่ดีที่ดำเนินการอย่างรุนแรงตอนนี้ดีกว่าแผนที่สมบูรณ์แบบที่ดำเนินการในสัปดาห์หน้า"

ในฐานะนักพัฒนาคนเดียวเวิร์กโฟลว์ของฉันรวมสิ่งนี้เข้ากับแง่มุมของ Agile รวมถึงบอร์ด Kanban บางครั้งฉันก็ออกไปเที่ยวแทนกัน แต่ฉันพยายาม จำกัด การเบี่ยงเบนไปสองสามชั่วโมงต่อสัปดาห์และมันก็ใช้ได้ดี

หากคุณวางแผนที่จะทำงานในอุตสาหกรรมส่วนตัวสิ่งสำคัญคือการควบคุมแรงกระตุ้น "นักทฤษฎี" โปรแกรมเมอร์ที่ยอดเยี่ยมที่สุดที่ฉันรู้จักอาศัยอยู่ใน Silicon Valley แต่ไม่เคยมีงานทำมานานหลายปีเพราะเขามีชื่อเสียงในด้านการส่งรหัสที่สมบูรณ์แบบจนสายเกินไป