8 ระดับของโปรแกรมเมอร์

คุณเคยได้รับคำถามสัมภาษณ์อันคลาสสิคไหม, “คุณจะเห็นตัวคุณอยู่ที่ไหนในอีก 5 ปี?” เมื่อถูกถาม ผมจะนึกย้อนกลับไปที่ วิดีโอ Twisted Sister ตอนหนึ่งในปี 1984 เสมอ


ผมอยากจะให้คุณบอกกับผม -ไม่, ดีกว่านั้น, บอกกับทุกคนในชั้นเรียน

คุณอยากจะทำอะไรกับชีวิตของคุณ?

คุณอยากจะร็อค, แน่นอน! หรืออย่างน้อยก็คือเป็น ร็อคสตาร์โปรแกรมเมอร์ (เป็นบทความที่ดีบทความหนึ่งครับ – ผู้แปล) มันไม่ใช่คำถามที่โดยทั่วไปจะได้รับคำตอบที่จริงจังเท่าไหร่ – เช่นเดียวกับคำถามเก่าๆในการสัมภาษณ์, “อะไรคือจุดอ่อนที่ใหญ่ที่สุดของคุณ?” มันคือคุณที่บางครั้งร็อคมากไป, ใช่ไหม? ผู้บริสุทธิ์ที่พบเจออาจได้รับความเจ็บปวดได้

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

คำถาม “คุณจะเห็นตัวคุณอยู่ที่ไหนในอีก 5 ปี” เป็นประเภทรวดเร็ว และผู้คนส่วนมากจะตอบกลับไปที่ผู้สัมภาษณ์อย่างรวดเร็วในแบบที่เตรียมตัวมา ก่อนแล้ว แต่มันแสดงให้เห็นความกังวลที่ลึกซึ้งยิ่งกว่า: อะไรคือเส้นทางอาชีพที่มีศักยภาพสำหรับผู้พัฒนาซอฟต์แวร์? แน่นอน, เราทำสิ่งพวกนี้ เพราะเรารักมัน, และเราก็ โชคดีมากในความคิดนั้น แต่คุณจะยังคงนั่งลงเขียนโปรแกรมในตอนที่คุณอายุ 50? ในตอนที่คุณอายุ 60? อะไรคือผลลัพธ์ของอาชีพที่ดีที่สุดที่เป็นไปได้สำหรับโปรแกรมเมอร์ที่มีความ ต้องการจะเป็น..อืม, โปรแกรมเมอร์?

จะเกิดอะไรขึ้นถ้าผมบอกคุณ, โดยไม่จริงจังเท่าไหร่, ว่ามันมี 8 ระดับของโปรแกรมเมอร์?
โปรแกรมเมอร์ระดับตำนาน (Dead Programmer)
นี่เป็นระดับที่สูงสุด โค้ดของคุณยังคงอยู่ข้ามผ่านความตายของคุณ คุณเป็นส่วนหนึ่งของประวัติศาสตร์ที่ได้รับการบันทึกของวงการคอมพิวเตอร์ โปรแกรมเมอร์คนอื่นๆ ศึกษางานและงานเขียนของคุณ คุณอาจชนะรางวัล Turing, หรือได้เขียนงานที่มีอิทธิพล หรือสร้างหนึ่งหรือสองสิ่งที่เป็นรากฐานของเทคโนโลยีที่ส่งผลต่อการเขียน โปรแกรมที่เรารู้จักกัน คุณไม่ได้มีแค่บทความ wikipedia ของตัวคุณเองเท่านั้น – มันมีเว็บไซต์ที่อุทิศแก่การศึกษาชีวิตและงานของคุณด้วย
โปรแกรมเมอร์น้อยคนที่ได้ไปถึงระดับนี้ในช่วงชีวิตของเขา
ตัวอย่าง: Dijkstra, Knuth, Kay
โปรแกรมเมอร์ที่ประสบความสำเร็จ (Successful Programmer)
โปรแกรมเมอร์ที่เป็นทั้งคนที่เป็นที่รู้จักกันดี และได้สร้างธุรกิจทั้งหมด หรืออาจขนาดทั้งอุตสาหกรรม – ด้วยโค้ดของพวกเขาเอง โปรแกรมเมอร์เหล่านี้ได้ให้ อิสระที่แท้จริง แก่ตัวพวกเขาเอง: อิสระที่พวกเขาจะตัดสินใจเลือกงานที่พวกเขาอยากทำเอง และการแบ่งปันอิสระนั้นแก่เพื่อนร่วมอาชีพ
นี่เป็นระดับที่โปรแกรมส่วนใหญ่ทุกคนควรอยากที่จะเป็น การที่จะได้ระดับนี้ขึ้นอยู่กับทักษะทางธุรกิจมากกว่าการเขียนโปรแกรม
ตัวอย่าง: Gates, Carmack, DHH
โปรแกรมเมอร์ที่มีชื่อเสียง (Famous Programmer)
นี่ก็เป็นอีกที่หนึ่งที่ควรอยู่, แต่ต้องยกเว้นว่าคุณต้องมีงานประจำ
คุณเป็นโปรแกรมเมอร์ที่มีชื่อเสียงในหมู่คนเขียนโปรแกรม แต่การมีชื่อเสียงไม่ได้ช่วยให้คุณสามารถสร้างรายได้หรือสนับสนุนตัวคุณเอง การมีชื่อเสียงเป็นเรื่องที่ดี แต่การประสบความสำเร็จเป็นเรื่อง ที่ดีกว่า คุณอาจจะได้ทำงานกับบริษัทเทคโนโลยีใหญ่ที่มีชื่อเสียง, บริษัทเล็กๆที่มีอิทธิพล, หรือเป็นส่วนหนึ่งของทีมสตาร์ตอัพที่ไม่ใหญ่โตนัก ไม่ว่าจะทางไหน โปรแกรมเมอร์คนอื่นๆ ได้ยินชื่อของคุณ และคุณได้ผลกระทบที่ดีในที่นั้นแล้ว
โปรแกรมเมอร์ที่ทำงานได้ (Working Programmer)
คุณได้มีอาชีพที่ประสบความสำเร็จสำหรับผู้พัฒนาซอฟต์แวร์ ทักษะของคุณอยู่ในความต้องการ และคุณไม่เคยที่จะต้องใช้เวลานานและยากลำบากสำหรับการหางานที่ดี เพื่อนร่วมงานนับถือคุณ ทุกบริษัทที่คุณทำงานด้วยได้ถูกพัฒนาและรุ่งเรื่องยิ่งขึ้นในสักทางจากการมี อยู่ของคุณ
แต่คุณจะไปที่ไหนจากตรงนั้น?
โปรแกรมเมอร์ระดับกลาง (Average Programmer)
ที่ระดับนี้คุณเป็นโปรแกรมเมอร์ที่ดีพอที่จะตระหนักได้ว่าคุณไม่ใช่โปรแกรมเมอร์ที่ยิ่งใหญ่ และคุณอาจเป็นไม่ได้
พรสวรรค์มักจะมีส่วนน้อยต่อความสำเร็จ คุณสามารถประสบความสำเร็จได้ถ้าคุณมีทักษะด้านธุรกิจและผู้คน ถ้าคุณเป็นโปรแกรมเมอร์ระดับกลาง ที่สามารถใช้ชีวิตอยู่ตรงนั้นได้แสดงว่าคุณได้รับพรสวรรค์, แค่ไม่จำเป็นว่าจะต้องเป็นที่การเขียนโปรแกรม
อย่าดูถูกคุณค่าของการรู้ตัวเอง มันเป็นสิ่งที่มีค่ามากกว่าที่คุณตระหนัก มันไม่มีอะไรผิดกับการที่ไม่มีพรสวรรค์ จงกล้าหาญ มองให้ออกว่าอะไรที่คุณทำได้ดี และไล่ตามมัน อย่างหนักหน่วง
โปรแกรมเมอร์สมัครเล่น (Amateur Programmer)
โปรแกรมเมอร์สมัครเล่นที่รักที่จะเขียนโปรแกรม, และมันแสดงให้เห็นว่าเป็นแบบนั้น: พวกเขาอาจจะเป็นนักศึกษาอนาคตไกล หรือเด็กฝึกงาน, หรืออาจจะมีส่วนร่วมในการโครงการ open source, หรือสร้างสรรค์โปรแกรมหรือเว็บไซต์ที่น่าสนใจในเวลาว่าง “เพียงเพื่อความสนุก” โค้ดและความคิดของพวกเขาแสดงถึงสัญญาณแห่งความสำเร็จและความกระตือรือร้น
การเป็นโปรแกรมเมอร์สมัครเล่นเป็นสิ่งที่ดี จากระดับตรงนี้ คนๆหนึ่งสามารถไปสู่การเป็นโปรแกรมเมอร์ที่ทำงานได้อย่างรวดเร็ว
โปรแกรมเมอร์ที่ไม่เป็นที่รู้จัก (Unknown Programmer)
โปรแกรมเมอร์ทั่วๆไป เก่ง แต่ไม่ถึงกับโดดเด่น อาจจะทำงานให้กับบริษัทขนาดใหญ่, บริษัทนิรนาม MegaCorp มันเป็นแค่งาน ไม่ใช่ทั้งชีวิตของพวกเขา ไม่มีอะไรผิดเกี่ยวกับสิ่งนั้น, เช่นกัน
โปรแกรมเมอร์ที่แย่ (Bad Programmer)
ผู้คนที่บางครั้งหล่นไปอยู่ในตำแหน่งโปรแกรมโดยที่ไม่มีทักษะหรือความสามารถแม้แต่นิด ทุกๆสิ่งที่พวกเขาแตะ กลายเป็นความเจ็บปวดและทรมาณ สำหรับเพื่อนโปรแกรมเมอร์รอบข้าง – ที่เป็นไปได้ว่าจะเป็นโปรแกรมเมอร์ที่แย่คนอื่นๆ, ที่ขาดทักษะพื้นฐานที่จะบอกได้ว่าพวกเขากำลังทำงานกับโปรแกรมเมอร์ที่แย่
ซึ่ง, บางที, อาจจะเป็นเครื่องหมายสำหรับโปรแกรมเมอร์ที่แย่ทุกคน คนเหล่านี้ไม่มีธุระกับการเขียนโค้ดในทุกๆ รูปแบบ – แต่พวกเขาก็ทำ, อย่างไรก็ตาม

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

ในประโยคสั้นๆ, คุณอยากจะทำอะไรกับชีวิตของคุณ?



ที่มา http://xenon.kmi.tl/?p=24

ต้นฉบับ: http://www.codinghorror.com/blog/2009/04/the-eight-levels-of-programmers.html

โดย Jeff Atwood @ Coding Horror

50 ข้อคิดสำหรับนักพัฒนาโปรแกรมที่ควรรู้ไว้

1.โปรแกรมแบบพอเพียง(ทำอะไรให้เล็กที่สุดเท่าที่เป็นไปได้)
2.ทำสิ่งธรรมดาให้ง่าย ทำสิ่งยากให้เป็นไปได้
3.จงโปรแกรมโดยนึกว่าจะมีคนมาทำต่ออย่างแน่นอน
4.ระเบียบ กฏข้อบังคับ เชื่อมั่นไม่ได้แล้ว ถ้ามีเพียงหนึ่งโมดูลไม่ปฏิบัติตาม
5.ตัดสินใจให้ดีระหว่างความชัดเจน(clearance) กับ การขยายได้(extensibility)
6.อย่าเชื่อมั่น output จากโมดูลอื่น ถึงแม้เราจะเป็นคนเขียนเอง
7.ถ้าคนเขียนยังเข้าใจได้ยาก แล้วคนอ่านจะเข้าใจได้ยากกว่าแค่ไหน
8.ค้นหาข้อมูลสามวันแล้วทำหนึ่งวัน หรือจะทำสามวันแล้วแก้บั๊กตลอดไป
9.จงสร้างเครื่องมือ ก่อนทำงาน
10.อย่าโทษโมดูลอื่นก่อน โดยเฉพาะถ้าโมดูลอื่นเป็น OS และ Compiler
11.พยายามทำตามกฏ แต่ถ้ามีข้อยกเว้น ต้องมีอย่างหลีกเลี่ยงไม่ได้ แล้วประกาศและตะโกนให้ดังที่สุด
12.High cohesion Loose coupling. (ยึดเกาะให้สูงสุดในโมดูล และ เกาะเกี่ยวกับโมดูลอื่นให้น้อยที่สุด)
13.ให้สิ่งที่เกี่ยวข้องกันยิ่งมากอยู่ไกล้กันมากที่ สุด
14.อย่าเชื่อโดยไม่พิสูจน์
15.อย่าลองทำแล้วคอมไพล์ดู ถ้าเราไม่ได้คาดหวังผลลัพธ์อะไรไว้ (อย่างเช่นปัญหา index off by one)
16.จงกระจายความรู้เพราะนั่นคือการทำ Unit Test ระดับล่างสุด(ระดับความคิด)
17.อย่าเอาทุกอย่างใส่ใน UI เพราะ UI คือส่วนที่ Unit Test ได้ยาก
18.ทั้งโปรเจ็คต์ควรไปในทางเดียวกันมากที่สุด( Consistency )
19.ถ้ามีสิ่งที่ดีอยู่แล้วจงใช้มัน อย่าเขียนเอง ถ้าจำเป็นต้องเขียนเอง ให้ศึกษาจากข้อผิดพลาดในอดีตก่อน
20.อย่ามั่นใจเอาโค้ดไปใช้จนกว่าจะ test อย่างเพียงพอ
21.เอาโค้ดที่ test ไว้ที่เดียวกันกับโค้ดที่ถูก test เสมอ
22.ทุกครั้งที่แก้ไขโค้ดให้ run unit test ทุกครั้ง
23.จงใช้ Unit Test แต่อย่าเชื่อมั่นทุกอย่างใน Unit Test เพราะ Unit Test ก็ผิดได้
24.ถ้าต้องทำอะไรที่ซ้ำกันมากกว่าหนึ่งครั้ง ก็เพียงพอแล้วที่จะแยกโค้ดส่วนนั้นออก
25.ทำให้ใช้งานได้ก่อน แล้วค่อย optimize และถ้าไม่จำเป็น อย่าoptimize
26.ยิ่งประสิทธิภาพเพิ่ม ความเข้าใจง่ายจะลดลง
27.ใช้ Design Pattern ที่เป็นที่รู้จักจะได้คุยกับใครได้รู้เรื่อง
28.อย่าเก็บไว้ทำทีหลัง ถ้ายังไงก็ต้องทำ
29.MutiThreading ไม่ใช่แค่การเพิ่มประสิทธิภาพ แต่มันมาพร้อมกับ Concerency, Deadlock, IsolationLevel, Hard to debug, Undeterministic Errors.
30.จงทำอย่างโจ่งแจ้ง
31.อย่าเพิ่ม technology โดยไม่จำเป็น เพราะนั่นทำให้โปรแกรมเมอร์ต้องวุ่นวายมากขึ้น
32.จงทำโปรเจ็คต์ โดยคิดว่าความเปลี่ยนแปลงเกิดขึ้นได้เสมอ
33.อย่าย่อชื่อตัวแปรถ้าไม่จำเป็น เดี๋ยวนี้ IDE มันช่วยขึ้นเยอะแล้วไม่ต้องพิมพ์เองแค่ dot มันก็ขึ้นมาให้เลือก
34.อย่าใช้ i, j , k , result, index , name, param เป็นชื่อตัวแปร
35.ทำโค้ดที่ต้องสื่อสารผ่านเครือข่ายให้คุยกันน้อยท ี่สุด
36.แบ่งแยกดีดี ระหว่าง Exception message ในแต่ละเลเยอร์ ว่าต้องการบอกผู้ใช้ หรือ บอกโปรแกรมเมอร์
37.ที่ระดับ UI ต้องมี catch all exception เสมอเพื่อกรอง Exception ที่ลืมดักจับ
38.ระวัง คอลัมภ์ allow null ใน database ดีดี ค่า มัน convert ไม่ได้
39. อย่าลืมว่า Database เป็น global variable ประเภทหนึ่ง แต่ละโปรแกรมที่ติดต่อเปรียบเหมือน MultiThreading ดังนั้นกฏของ Multithreading ต้องกระทำเมื่อทำงานกับ Database
40.ระวังอย่าให้ logic if then else ซ้อนกันมากมาก เพราะสมองคนไม่ใช่ CPU จินตนาการไม่ออกหรอกว่ามันอยู่ตรงไหนเวลา Debug (ถ้ามากกว่าสามชั้นก็ลองคิดใหม่ดูว่าเขียนแบบอื่นได้ มั้ย)
41.ระวังอย่าให้ลูปซ้อนกันมากมาก ไม่ใช่แค่เรื่องความเร็วอย่างเดียว เวลา Debug เราคิดตามมันไม่ได้ (ถ้าเกินสามชั้นก็ไม่ไหวแล้ว)
42. อย่าใช้ Magic Number ใน Code เช่น if( controlingValue == 4 ) เปลี่ยนไปใช้ Enum ดีกว่า เป็น if( controlingValue == ControllingState.NORMAL ) เข้าใจง่ายกว่ามั้ย
43.ถ้าจะเปรียบเทียบ string Trim ซ้ายขวาก่อนเสมอ
44.คิดหลายๆ ครั้งก่อนใช้ Trigger
45.โปรแกรมเมอร์คือห่วงโซ่สุดท้ายของมลพิษทางความซับ ซ้อน ดังนั้นหา project leader ดีดีแล้วกัน
46. มนุษย์ฉลาดกว่าคอมพิวเตอร์ การเขียนโปรแกรมก็คือการสอนให้คอมพิวเตอร์ฉลาดได้เหมือนเรา (มนุษย์ฉลาดกว่าคอมพิวเตอร์จริงๆนะ) Reply With Quote
47. จงควบคุมคอม มิใช่ให้คอมควบคุมเรา เราต้องสั่งให้คอมทำงาน ไม่ใช่ให้เราทำงานตามคอมสั่ง
48. อย่าปล่อยให้ข้อจำกัดของคอม มาจำกัดความคิดของเรา [คอมไม่ดีเปลี่ยนเครื่องเลย 55+]
49. ยอมรับความคิดของผู้อื่น แต่อย่าออกจากกรอบของตนเอง
50. หมั่น Save โปรแกรมไว้อย่าสม่ำเสมอ ก่อนที่จะไม่มีโอกาส Save [จะให้ดี Save เป็นแต่ละ Version เลย]


ที่มา http://www.ict.buu.ac.th/Blog/Lists/Posts/Post.aspx?ID=1470