เมื่อใดที่คน ๆ หนึ่งจะถูกพิจารณาว่าเป็นโปรแกรมเมอร์ที่ไม่ดี? [ปิด]

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

ถ้าเป็นไปได้ ... เขา / เธอควรปรับปรุงอย่างไร?

เมื่อพวกเขาล้มเหลวที่จะเรียนรู้จากความผิดพลาดของพวกเขาและจากความคิดเห็นของเพื่อน

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

โปรแกรมเมอร์ที่ไม่รู้ว่าเขาไม่รู้อะไรและไม่สนใจที่จะรู้

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

จากบทความ:

โปรแกรมเมอร์ที่เข้าใจว่าโค้ดทำอะไร แต่ไม่เป็นเช่นนั้น

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

ข้อสรุปคือเมื่อพวกเขาถามคำถามการเขียนโปรแกรมเดียวกันหลายครั้งระบุว่าพวกเขาไม่ได้ใช้ข้อมูลภายใน

เมื่อพวกเขาใช้เวลานานในการแก้ปัญหา FizzBuzz

โปรแกรมเมอร์ที่ปฏิเสธที่จะเรียนรู้เทคโนโลยี / ภาษาใหม่ ๆ และยืนยันที่จะยึดติดกับสิ่งที่พวกเขารู้อยู่แล้ว

ภาคผนวก: (เพิ่มสิ่งที่ขีดพูดด้านล่างในความคิดเห็น)

ส่วนขยายของสิ่งนี้คือคนที่รู้จักชุดย่อยของการทำงานของเทคโนโลยีบางอย่าง แต่ไม่ต้องการที่จะเรียนรู้อะไรเพิ่มเติมเกี่ยวกับมัน ภาษาโปรแกรมแก้ไขเครื่องมืออื่น ๆ ...

เมื่อสมาชิกในทีมเป็นนักพัฒนาผลิตเชิงลบ

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

ความหมายที่เหลือของทีมของคุณต้องทำงานมากขึ้นเพราะนักพัฒนาที่ไม่ดี NNPP

เมื่อพวกเขาผลิตสิ่งต่าง ๆ ที่เกี่ยวข้องกับThe Daily WTFเป็นประจำ

เมื่อพวกเขารู้ว่ามีวิธีที่ดีกว่าในการทำสิ่งต่าง ๆ แต่ก็ยังปฏิเสธที่จะทำสิ่งเหล่านั้นแม้ในเวลาที่อนุญาต

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

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

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

1. ในอดีตที่ผ่านมา
   ไม่สามารถฝึกอบรมได้หรือ Ossified เมื่อ 'โปรแกรมเมอร์' ดูเหมือนจะไม่สามารถดูดซับระบบใหม่เครื่องมือใหม่หรืออะไรก็ตามที่ถูกปรับใช้ไม่ว่าการฝึกอบรม / การศึกษาจะเสร็จสิ้น มีการกล่าวซ้ำการฝึกอบรมเป็นประจำ
   เมื่อ 'โปรแกรมเมอร์' เท่านั้นที่รู้เทคโนโลยีหรือการเข้ารหัสกระบวนทัศน์ที่พวกเขาใช้เมื่อ 10 หรือ 15 ปีก่อน มันดีพอแล้วทำไมพวกเขาถึงต้องเปลี่ยนล่ะ
2. โค๊
   ดโคดเดอร์คาวบอยรหัสคนแรกโดยไม่มีแผน 'โปรแกรมเมอร์' ที่ทำการเปลี่ยนแปลงที่ยังไม่ทดลองกับรหัสการผลิตและ / หรือข้อมูล "เพราะเราต้องแก้ไขให้ถูกต้องแล้ว" และจากนั้นจะประหลาดใจเมื่อ "แก้ไข" ล้มเหลว
   คาวบอยก็ไม่ใช่ผู้เล่นทีมแน่นอนที่สุด ไม่ต้องการทีมไม่มีกลิ่นเหม็น
3. สภาพอากาศใบพัด
   นี้ 'โปรแกรมเมอร์' เป็นติดใจกับ "เทคโนโลยีหวือหวา " และเห็นทุกกรอบการทำงานใหม่ภาษาวิธีการหรือสิ่งที่ใหม่และร้อนเป็น
4. "สมองใหญ่"
   โปรแกรมเมอร์คนนี้มั่นใจในความสามารถและความสามารถของเขาว่าสิ่งต่าง ๆ ได้ทำไปแล้วซึ่งไม่ได้ทำให้รู้สึกเป็นโครงการมากนัก เช่นการเขียนซ้ำไลบรารีมาตรฐาน "เพราะมันไม่มีประสิทธิภาพสำหรับระบบของเรา" หรือแนะนำเครื่องมือและเทคนิคที่ไม่เหมาะกับปัญหาที่เกิดขึ้น เช่นแนะนำ Lisp หรือ Forth ในสภาพแวดล้อมเมนเฟรม
5. LOC ^a. Sandbagger
   'โปรแกรมเมอร์' นี้ใช้ obfuscation และทิศทางที่ผิดเพื่อเพิ่ม ^a LOC: เส้นของรหัสที่ได้รับเงิน ฉันได้เห็นรหัสในสถานการณ์นี้ซึ่งเป็นหน้าหลังหน้าจอหน้าจอหลังโครงสร้างที่ซ้ำกันและตรรกะโดยมีเพียงย่อหน้าหรือชื่อตัวแปรควบคุมเปลี่ยนเป็นปั๊มขึ้นนับบรรทัด
6. ผู้เชี่ยวชาญที่ขาดไม่ได้
   'โปรแกรมเมอร์' ที่มีความรู้ด้านโดเมนในการแก้ปัญหาในมือ แต่เนื่องจากพวกเขา "รู้" ทุกอย่างเกี่ยวกับมัน ตามความเป็นจริงถ้าพวกเขาถูกรถบัสชนองค์กรทั้งหมดจะพังทลาย {การสังเกต:คนที่คิดว่าพวกเขาขาดไม่ได้มักจะเป็น (ทุกคนมีแหล่งที่มาของคำพังเพยนี้หรือไม่?)}
7. The Pasta Chef
   'โปรแกรมเมอร์' นี้มีความเชี่ยวชาญในการทำสปาเก็ตตี้โดยมีตัวระบุที่ยากเกินกว่าจะทำตามได้โดยไม่ต้องใช้ IDE เช่น IndexI1O0, Index1I0O เป็นต้น
8. Summer Intern - ภัยพิบัติการเดินประเภทย่อยโดยเฉพาะ
   ร้านค้าเก่าของฉันเคยเช่าโรงเรียนมัธยมปลายหรือฝึกงานช่วงอายุจำนวนมาก มีอยู่ครั้งหนึ่งที่แผนกต้องการฐานข้อมูลขนาดเล็กเพื่อติดตามการใช้งานอุปกรณ์บางอย่าง (ตอนนี้นี่เป็นการรอกลับมาแล้วและใช้ dBase III) ผู้ชายเขียนรหัสตลอดฤดูร้อน แต่ไม่ได้ทำเมื่อวิทยาลัยเริ่มในฤดูใบไม้ร่วง เขาได้รับการขยายหนึ่งสัปดาห์จากนั้นสัปดาห์ที่สอง ในตอนท้ายของสัปดาห์ที่สองฉันถูกส่งออกไปรับโครงการของเขาและนำมันกลับไปที่การพัฒนาระบบให้เสร็จ เขาแสดงให้ฉันดูสิ่งที่เขาทำไปแล้วส่วนที่ยังไม่เสร็จ สิ่งที่ใช้ได้ผลดีกับอาหารตาดี แต่แอปพลิเคชันนั้นไม่สมบูรณ์ เมื่อฉันเปิดกล่องฟล็อปปี้ที่ฟอร์แมตใหม่เพื่อรับสำเนาเขาพูดว่า "แค่วินาทีเดียวให้ฉันลบไฟล์ทดสอบของฉัน ... " และก่อนที่ฉันจะพูดอะไรก็ได้เขาจะลบไฟล์จำนวนมาก
   การเรียงลำดับที่น่าสงสัยและพบว่าแอปพลิเคชันของเขาแทบจะไม่มีอะไรเลยนอกจากขนมตาเมื่อฉันกลับไปที่ร้านของฉันฉันกลับไปที่แผนกและดึง Norton ออกและยกเลิกการลบไฟล์ที่เขาต้องการลบพยายามหาตรรกะเพิ่มเติม แม้ว่าจะไม่สมบูรณ์
   ฉันพบไม่ใช่ตรรกะที่ไม่ดี แต่มีพฤติกรรมที่ไม่ดี เครื่องพิมพ์ที่ต่ออยู่กับพีซีที่เขาใช้คือเครื่องพิมพ์ล้อเดซี่ ชุดอักขระที่ติดตั้งตามปกติคือตัวแปรสวิส ผลลัพธ์ของโปรแกรมที่ถูกลบจะระบุชื่อที่อยู่ DOB รหัสตัวอักษรบางตัวและหมายเลขประจำตัวบางประเภท รูปแบบและเลย์เอาต์รบกวนฉัน วันเดือนปีเกิดสำหรับคนหลาย ๆ คนนั้นแทบจะไม่ได้ดื่มอย่างถูกกฎหมาย ที่อยู่ส่วนใหญ่ไม่ได้อยู่ที่นั่นเมื่อฉันค้นหาในไดเรกทอรีกากบาดของเรา เมื่อฉันแสดงเอกสารให้กับหัวหน้างานของเขาเขามองมาที่ฉันและพูดว่า "ใบขับขี่คุณไม่คิดเหรอ?" ฉันบอกว่าฉันทำเช่นนั้น เขาบอกว่านั่นเป็นสาเหตุที่เขาพบว่าหุ้นที่โปร่งใสถูกตัดทิ้งในถังขยะถัดจาก Xerox เด็กชายที่ไม่ดีของเราได้ทำการซ้อนทับเพื่อปรับอายุของเขาและเพื่อนของเขาในใบขับขี่ เรารายงานให้เจ้าหน้าที่ทราบไม่จ่ายสำหรับสองสัปดาห์สุดท้ายของเขา

นี่เป็นเพียงตัวละครที่ไม่ดีที่ฉันต้องร่วมงานด้วย ....

/ s / BezantSoft

ไม่สามารถปรับตัวเองให้เข้ากับเทคโนโลยีที่กำลังจะมาถึง

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

เมื่อไม่มีใครสามารถอ่านรหัสของเขาได้ ไม่ว่าคุณจะสดใสแค่ไหน โปรแกรมเมอร์ไม่เป็นเกาะ

คนที่ไม่ใส่ใจกับรายละเอียดและมักจะอยู่ใน "มันใช้งานได้ดังนั้นฉันจะปล่อยให้มันอยู่คนเดียวข้อยกเว้นทั้งหมดที่อยู่ในบันทึกไม่สำคัญ"

มีสองประเภทสำหรับโปรแกรมเมอร์สำหรับฉัน - เดี่ยวและทีม

โปรแกรมเมอร์เดี่ยวที่ไม่ดีคือ

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

โปรแกรมเมอร์ในทีมที่ไม่ดีคือผู้ที่อยู่ในหมวดหมู่โปรแกรมเมอร์เดี่ยวที่ไม่ดี ได้แก่

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

ไม่เต็มใจที่จะยอมรับว่าพวกเขาไม่รู้คำตอบและ / หรือไม่เต็มใจที่จะค้นหา

ถ้าคุณไม่รู้ก็อย่ายอมแพ้ - คิดออกแล้วทำมันให้สำเร็จ

สัญญาณเตือนครั้งใหญ่ในประสบการณ์ของฉันคือเมื่อพวกเขาไม่แสดงความคิดเห็นแฮ็กของพวกเขา ....

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

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

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

การแสดง repreategly ขวาวิธีที่จะทำมันซ้ำแล้วซ้ำอีกเพียงแค่ทำมันเป็นวิธีที่ง่าย

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

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

ไบนารีใช้งานได้ดีในคอมพิวเตอร์: มันคือ '1' หรือ '0', "เปิด" หรือ "ปิด" เราสามารถสรุปและเข้ารหัสข้อมูลจำนวนมากโดยใช้สองสถานะที่มีชื่อเสียงเหล่านั้น แต่ก็ไม่ได้มีแนวโน้มที่จะทำงานได้ดีสำหรับเรื่องของมนุษย์: "ดี" หรือ "ไม่ดี" "มีสติ" หรือ "บ้า" "ดี" หรือ "ชั่ว" "ฉลาด" หรือ "โง่" "อ้วน" หรือ "ผอม" "มีชีวิต" หรือ "ตายแล้ว" การประเมินค่าโพลาไรซ์แบบนี้ทำให้มนุษย์ที่ห่วงใยเป็นส่วนหนึ่งของฉันที่ไม่พอใจอย่างมาก ด้วยวิธีการวัดใดที่ฉันเลือกที่จะใช้ฉันมักจะพบว่าคำตอบของความแตกต่างอย่างสิ้นเชิงจริง ๆ แล้วนอนอยู่ที่ไหนสักแห่งตามความต่อเนื่องระหว่างขั้วหนึ่งกับอีกขั้วหนึ่งไม่ใช่ที่ปลายทั้งสอง

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

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

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

ดังนั้นฉันขอแนะนำให้คุณลองใช้คำเล็ก ๆ ของฉันสามคำว่า "ถึงระดับใด" และดูว่าพวกเขาสามารถพาคุณไปได้ไกลแค่ไหน!

คนที่พูดว่า "ไม่สามารถทำได้"

ในความคิดของฉันมันคือทั้งหมดที่เกี่ยวกับการแก้ปัญหาเครื่องมือควรมีความเกี่ยวข้องน้อยกว่าการทำงานจริง ถ้าฉันต้องแก้โดยใช้ MS-Access หรือภาษาแอสเซมบลีมันเป็นเรื่องของเวลาและเงินไม่ใช่เรื่องของ "มันไม่สามารถทำได้"

สัญญาณเตือนคือการมุ่งเน้นไปที่วิธีการทางวิชาการและ "เหมาะสม" มากเกินไปและไม่เน้นการทำงานให้เสร็จ

ถ้าเขารู้ไวยากรณ์ของภาษา แต่ไม่ทราบแนวคิดพื้นฐานของอัลกอริทึม

เมื่อพวกเขาทำสิ่งที่น่าสังเวชมากมาย แต่ผลิตน้อยมาก

! (ฉลาดและทำสิ่งต่าง ๆ ได้สำเร็จ)

ผู้ที่ไม่ทราบหลักการเช่น SOLID, DRY, OOP และอื่น ๆ สิ่งสำคัญคือต้องมีความเข้าใจที่ดีเกี่ยวกับหลักการและพื้นฐานการเขียนโปรแกรมมากกว่าการรู้เทคโนโลยีเฉพาะ ผู้ที่มีพื้นฐานที่มั่นคงจะสามารถเรียนรู้หัวข้อใหม่ได้อย่างง่ายดายและจะสร้างรหัสที่ดีกว่า

โปรแกรมเมอร์ฝังตัวที่ไม่เข้าใจการขัดจังหวะเป็นอย่างดีหรือมัลติทาสก์ นอกจากนี้โปรแกรมเมอร์ที่ต้องทำงานกับบิตฟิลด์ แต่ไม่เข้าใจการดำเนินการทางตรรกะกับมัน

สัญญาณการรู้จำทันทีคือมีคนพูดว่า: "ฉันไม่เข้าใจว่าทำไมมันไม่ทำงานฉันทำทุกอย่างถูกต้อง"

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

ฉันเคยสืบทอดระบบที่นักพัฒนาคนก่อนนำมาใช้ใหม่ (ใน Java) ชุดใหญ่ของ Ashton Tate DBase III + api อยู่ด้านบนของไลบรารีการเข้าถึง dbf ที่กำหนดเอง ไม่มีการใช้เฟรมเวิร์กคอลเลกชัน Java

นี่คือเพื่อให้เขาสามารถเขียนแอพ Java / swing ที่ดูและทำตัวเหมือนแอพ DBase III + (หรืออาจเป็น clipper)

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

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

แต่เขาเป็นโปรแกรมเมอร์ที่น่ากลัวเพราะโค้ดของเขาใช้คุณสมบัติของระบบที่เขาใช้งานไปในทางที่ผิด เขายินดีที่จะใช้เวลา 3 เดือนในการปรับแต่งผลประโยชน์ที่น่าสงสัยมากกว่าเรียนรู้ Java / Swing / SQL