การออกแบบที่เสนอของฉันมักจะแย่กว่าของเพื่อนร่วมงานของฉัน - ฉันจะดีขึ้นได้อย่างไร [ปิด]

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

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

2. งานของฉันเกี่ยวข้องกับการเขียนโปรแกรมใน Python ฉันพยายามอ่านซอร์สโค้ด แต่คุณคิดว่าฉันจะพัฒนาทักษะการออกแบบได้อย่างไร มีหนังสือหรือซอฟต์แวร์ดีๆสักเล่มที่ฉันควรศึกษาหรือไม่?

โปรดให้ความกระจ่างแก่ฉัน ฉันจะขอขอบคุณสำหรับความช่วยเหลือของคุณ

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

คุณมีจุดแข็งสองจุดที่ยอดเยี่ยมมาก

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

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

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

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

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

ในอุดมคติแล้วโปรแกรมเมอร์ทุกคนควรรู้ภาษาจากแต่ละชั้นเรียน คุณเรียนรู้อะไรได้บ้าง:

1. ภาษาหลัก OOP แบบคงที่พิมพ์: Java, C # (ส่วนใหญ่ใช้ในซอฟต์แวร์องค์กร) และ C ++ (การเขียนโปรแกรมระบบและแอปพลิเคชันเดสก์ท็อปที่ซับซ้อน)
2. ภาษา OOP ที่ใช้ต้นแบบ: Javascript (การเขียนโปรแกรมเว็บฝั่งไคลเอ็นต์)
3. ภาษาขั้นตอน: C (ซอฟต์แวร์แบบฝังตัวและการเขียนโปรแกรมระบบ)
4. ภาษาที่ใช้งานได้: Haskell, ML หรือ Lisp (ภาษาที่ใช้งานได้ดีสำหรับซอฟต์แวร์ที่มีความขนานสูง)

ภาษาการเขียนโปรแกรมเชิงตรรกะ (Prolog) อาจไม่เป็นประโยชน์ในอุตสาหกรรมส่วนใหญ่จะใช้ในการวิจัยใน AI

สิ่งนี้จะช่วยขยายความคิดที่หลากหลายที่นึกถึงเมื่อพยายามออกแบบวิธีแก้ปัญหา

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

วิธีที่ดีที่สุดในการปรับปรุงในการออกแบบซอฟแวร์คือการออกแบบซอฟแวร์* วิธีหนึ่งที่จะทำได้คือการดูการแข่งขันการออกแบบ: TopCoder มีการออกแบบส่วนประกอบมากกว่า 100 รายการพร้อมด้วยเอกสารประกอบการออกแบบ UML และการนำไปใช้งานใน Java และ / หรือ C # รับส่วนประกอบสำเร็จรูปที่คุณชอบอ่านข้อกำหนดคุณสมบัติและลองออกแบบด้วยตัวเองเพื่อให้เป็นไปตามข้อกำหนด ใช้เวลาหนึ่งหรือสองชั่วโมงคิดเกี่ยวกับปัญหาและร่างแผนภาพคลาสจากนั้นเปิดการออกแบบที่ชนะและอ่านสิ่งที่ผู้เขียนทำ เปรียบเทียบการออกแบบของเขากับคุณมองเห็นความแตกต่างและดูว่าการออกแบบของคุณดีกว่าหรือไม่ ตรวจสอบบัตรคะแนนการแข่งขันเพื่อดูว่าผู้ตัดสินให้คะแนนการออกแบบอย่างไร สิ่งนี้จะให้ความคิดเห็นที่คุณต้องการในการตัดสินใจว่าจะพัฒนาทักษะการออกแบบของคุณอย่างไร

อย่าออกจากงานของคุณ การทำงานกับคนที่มีทักษะดีกว่าคุณจะดีกว่าเพื่อที่คุณจะได้เรียนรู้จากเขาหรือเธอ

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

ในการพัฒนาทักษะการออกแบบสิ่งที่ดีที่สุดที่จะทำคือการสร้างการออกแบบจากนั้นจะโหดร้ายกับตัวเองในการประเมินพวกเขาและกำหนดวิธีการที่พวกเขาสามารถปรับปรุง ถามคำถามกับตัวเองเช่น: มันจะทำงานได้หรือไม่และเป็นไปตามข้อกำหนดในทุกด้านหรือไม่มันสามารถบำรุงรักษาได้หรือไม่ฉันจะสามารถทดสอบสิ่งนี้ได้หรือไม่มันจะทำให้เกิดปัญหาด้านประสิทธิภาพหรือไม่ สามารถจัดการกับการเปลี่ยนแปลง อ่านเกี่ยวกับรูปแบบการออกแบบและลองนำไปใช้กับการออกแบบของคุณ Refactor อย่างไร้ความปราณีหลังจากมาด้วยการออกแบบที่เป็นธรรมชาติ หากคุณกำลังออกแบบฐานข้อมูลพร้อมกับแอปพลิเคชันอ่านอย่างละเอียดเกี่ยวกับการทำให้เป็นมาตรฐานและการปรับฐานข้อมูลคุณจะได้เรียนรู้มากมายเกี่ยวกับการออกแบบฐานข้อมูลถ้าคุณเรียนรู้วิธีทำให้ฐานข้อมูลทำงานได้อย่างมีประสิทธิภาพและมีประสิทธิภาพมากที่สุด สำหรับการใช้งานคิดเกี่ยวกับหลักการของ DRY และ SOLID ในการออกแบบของคุณ อ่านเกี่ยวกับ antipatterns เพื่อรู้ว่าควรหลีกเลี่ยงสิ่งใด

การตระหนักถึงการออกแบบที่ดีกว่าคือความสามารถที่สำคัญ คุณควรส่งเสริมสิ่งนี้ตามที่คุณทำตามคำแนะนำก่อนหน้านี้บางส่วนเกี่ยวกับการดูการออกแบบ

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

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

คุณจะได้รับแนวคิดเกี่ยวกับหลักการต่าง ๆ สำหรับการออกแบบจากแหล่งข้อมูลต่อไปนี้: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf การออกแบบซอฟต์แวร์บนวิกิพีเดีย Google "หลักการออกแบบซอฟต์แวร์"

• ทำความเข้าใจกับแบบจำลองต่างๆสำหรับการออกแบบซอฟต์แวร์เช่นการออกแบบเชิงวัตถุหรือการออกแบบฟังก์ชั่นหรือการออกแบบการวิเคราะห์เชิงโครงสร้าง สิ่งเหล่านี้อาจแตกต่างกันอย่างสิ้นเชิงจากความคิดที่จะเข้าใกล้งานออกแบบและพวกเขาแต่ละคนมีพื้นที่ที่พวกเขาเก่ง เรียนรู้สิ่งเหล่านี้เป็นเครื่องมือสำหรับกล่องเครื่องมือของคุณ http://userpages.umbc.edu/~khoo/survey2.html

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

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

ขอให้สนุก - อย่าทำถ้าคุณไม่สนุกอย่างน้อย!

คุณมาถึงขั้นตอนแรกแล้ว คุณยอมรับว่าคุณมีสิ่งที่ต้องเรียนรู้ว่างานของเพื่อนร่วมงานดีกว่าของคุณและคุณต้องการเรียนรู้และปรับปรุง

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

เมื่อคุณเข้าใจแล้วให้ดึงหลักการที่อยู่เบื้องหลัง ถามคำถามเช่นนี้

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

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

ฉันต้องการเพิ่ม (นอกเหนือจากคำตอบที่ยอดเยี่ยม) ที่มีให้มากกว่า "เขาสามารถสร้างการออกแบบที่ดีกว่าฉัน" คำตอบอื่น ๆ ให้ความสำคัญกับวิธีที่คุณจะได้รับการออกแบบที่ดีขึ้นซึ่งทั้งหมดและดี ... แต่ ...

ฉันเดิมพันเงินที่คุณสามารถทำได้ดีกว่าเพื่อนร่วมงานของคุณ ที่จะไม่สร้างการแข่งขันที่ฉี่หรืออะไรก็ได้ (คุณทำได้ดีกว่า Y สกรูคุณฉันทำได้ดีกว่า X!) แต่เพื่อชี้ให้เห็นความจริงที่ทุกคนมีจุดแข็งและจุดอ่อน

ที่งานของฉันมีนักพัฒนา 4 คน มีหลายครั้งที่ "โปรแกรมเมอร์" หลักสองคนสามารถสร้างสิ่งต่าง ๆ ที่ทำให้ฉันตกอยู่ในผงฝุ่น ทำให้หัวฉันพยายามหมุนหัวของฉันไปรอบ ๆ การสร้างสรรค์ของพวกเขา

แต่ฉันดีกว่าใน SQL และสคริปต์บรรทัดคำสั่งมากกว่าพวกเขาและสามารถทำให้สิ่งต่าง ๆ ที่ทำให้พวกเขาตกอยู่ในฝุ่นได้โดยอัตโนมัติ

พวกเขาดีกว่าฉันเหรอ ในบางพื้นที่แน่นอน นรกในหลาย ๆ พื้นที่พวกเขา - ฉันเป็นนักพัฒนารุ่นน้องที่ร้านค้าของฉันและพวกเขามีประสบการณ์กับฉันมานานหลายปี แม้จะมีประสบการณ์มาหลายปี แต่ฉันก็ยังดีกว่าในบางพื้นที่

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

มุ่งเน้นทั้ง - จุดแข็งและจุดอ่อน - ของคุณและเพื่อนร่วมงานของคุณ

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

คุณต้องเรียนรู้จากทุกคน

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

อย่าให้มืออาชีพหึงหวงระหว่างคุณกับโอกาสในการเรียนรู้

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

2. ทักษะการออกแบบส่วนใหญ่มาพร้อมกับประสบการณ์และหลังจากที่คุณอ่านหนังสือสำคัญสองสามเล่ม ฉันอยากจะแนะนำคุณดังต่อไปนี้:

   • Robert C. Marting - หลักการรูปแบบและการปฏิบัติที่คล่องตัว (มี 2 เวอร์ชั่นหนึ่งฉบับใน Java และอีกหนึ่งใน C # ไม่สำคัญว่าคุณจะเลือกแบบใดแนวคิดและหลักการสามารถนำไปใช้กับวัตถุใด ๆ ที่มุ่งเน้น - และไม่เพียง - รหัสแหล่งที่มา)
   • กว่า Robert C. Marting มีหนังสือที่น่าสนใจอีก 2 เล่ม: Clean Code และ The Coder ที่สะอาด
   • แม้ว่ามาร์ตินจะครอบคลุมรูปแบบการออกแบบที่ทันสมัยทั้งหมดในหนังสือเล่มแรกของเขาคุณต้องการค้นหาหนังสือรูปแบบการออกแบบดั้งเดิมโดย Gang of Four
   • ในที่สุดก็มีหนังสือเล่มอื่น ๆ ที่ให้ผลตอบแทนสูงในวันนี้: ซอฟต์แวร์การเติบโตเชิงวัตถุที่แนะนำโดยการทดสอบหรือการปรับโครงสร้างโดย M. Feathers (ฉันคิดว่า) หรือเขียนกรณีการใช้ที่มีประสิทธิภาพโดย A. Cockburn และอีกไม่กี่คุณจะค้นพบ

ไม่มีหนังสือเหล่านี้เป็นกระสุนวิเศษ แต่การอ่านคำแนะนำ 2 ข้อแรกอาจจะเปลี่ยนมุมมองและการรับรู้ของคุณเกี่ยวกับการเขียนโปรแกรมตลอดไป

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

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

กล่าวโดยย่อว่า "ประสบการณ์หลายปี" อาจไม่เทียบเท่ากันเสมอไป ไปทำให้ปีของคุณมีค่า

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