โปรแกรมเมอร์ควรสวมหมวกอะไร [ปิด]

จากประสบการณ์ของฉันผู้พัฒนาซอฟต์แวร์มักสวมหมวกหลายใบและเติมหลายบทบาทด้วยความรับผิดชอบที่แตกต่างกัน จากการเข้ารหัสไม่เพียง แต่บางครั้งก็เขียน SQL ออกแบบส่วนติดต่อผู้ใช้ออกแบบฐานข้อมูลจัดการกราฟิกจนถึงการทดสอบ QA

หากบทบาทหลักคือการเขียนซอฟต์แวร์ / รหัสผู้พัฒนาไม่ควรทำหน้าที่อะไร? ยังมี .... บ้าง?

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

ดูแลระบบ การพัฒนาซอฟต์แวร์และการจัดการโครงสร้างพื้นฐานด้านไอทีเป็นชุดทักษะที่แตกต่างกันสองชุดซึ่งมีลักษณะคล้ายกับบุคคลภายนอก (มันแค่ต่อสู้กับคอมพิวเตอร์ใช่ไหม) สำหรับ บริษัท เล็ก ๆ การทดลองจะแข็งแกร่งมากที่จะทำให้ The Computer Guy รับผิดชอบต่อเครื่องทั้งหมดในสำนักงาน

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

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

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

การแก้ปัญหาไม่เคยมีสไตล์

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

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

Tester!

กรุณาส่งผู้ทดสอบตรงๆออกจากโรงเรียนทดสอบถ้าต้องการ!

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

ฉันไม่ได้บอกว่าการทานอาหารสุนัขไม่ใช่ความคิดที่ดี ฉันแค่คิดว่าผู้ทดสอบมีความสำคัญมากในขณะนี้ว่าฉันเป็นโปรแกรมเมอร์

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

โปรแกรมเมอร์ไม่ควรจะเป็นเพียงการทดสอบสำหรับรหัสของตัวเอง

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

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

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

สองฉันนึกถึงค้างคาวทันที

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

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

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

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

นอกจากนี้นักพัฒนาไม่ควรทำการทดสอบ QA - นั่นคืองานของแผนก QA (บริษัท ที่ฉันทำงานที่ทำอุปกรณ์การแพทย์แบบฝังตัวดังนั้นนี่เป็นข้อกำหนดที่การทดสอบจะต้องทำโดยแผนกแยกต่างหาก)

ในทางกลับกันฉันไม่เห็นเหตุผลว่าทำไมนักพัฒนาไม่สามารถออกแบบฐานข้อมูลและเขียน SQL ได้หากพวกเขามีพื้นหลังให้ทำ - ฉันทำมาหลายครั้งแล้ว

ฝ่ายสนับสนุนด้านเทคนิค

วันเวลาของฉันเสียไปมากด้วยการโทรหาฝ่ายสนับสนุนด้านเทคนิค ...

บางคนที่เป็นที่นิยมคือ:

• "บัญชีของฉันถูกล็อค" หรือ "ฉันลืมรหัสผ่าน"
• "ฉัน [โทรศัพท์ | แป้นพิมพ์ | เมาส์ | คอมพิวเตอร์] ไม่ทำงาน"
• "คอมพิวเตอร์ของฉันช้าคุณสามารถตรวจสอบสิ่งผิดปกติได้หรือไม่?"
• "ทำไม X จึงเกิดขึ้นเมื่อฉันคลิกปุ่มนี้มันควรจะทำ Y"
• "ฉันได้รับป๊อปอัปเหล่านี้ .... " หรือ "ฉันคิดว่าฉันมีไวรัส"
• "บุคคลนี้ไม่อยู่ที่นี่แล้วคุณสามารถปิดใช้งานเนื้อหาทั้งหมดได้หรือไม่"
• "เรามีพนักงานใหม่คุณสามารถตั้งค่าพวกเขาด้วยล็อกอินการ์ดรักษาความปลอดภัยหมายเลขโทรศัพท์อีเมล ฯลฯ "

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

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

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

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

ขาย

คนเสพเวจมูกที่ยากจนบางคนต้องทำ แต่ก็ไม่ควรเป็นนักพัฒนา

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

ศิลปินและUser Interface ที่ออกแบบ

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

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

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

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

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

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

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

นอกเหนือจากนั้นไม่มี "หมวก" ที่นักพัฒนาซอฟต์แวร์ไม่ควรสวมใส่หากพวกเขามีทักษะที่จะทำให้เก่งในบทบาทนั้น

ฉันมักจะทำงานใด ๆ ที่ถูกขว้างมาที่ฉันถ้าหากว่า:

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

วิธีนี้ฉันได้รับการประกันกับเจ้านายของฉันเป็นส่วนใหญ่และถ้ามีคนผิดพลาดก็สามารถแก้ไขได้อย่างน้อยที่สุด

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

ดังนั้นผู้พัฒนาไม่ควรสวมหมวกที่ไม่ได้มีส่วนร่วมทำให้เกิดการเติบโตส่วนบุคคลและนำไปสู่ประสิทธิภาพสูงสุด - และขโมยเวลาจาก "หมวก" ที่ทำสิ่งเหล่านี้ให้พวกเขา

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

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

หมวกที่มีกระป๋องเบียร์อยู่ด้านข้างด้วยฟาง ความคิดที่ไม่ดีถ้าคุณถูกจับ

แก้ไข:

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

หมวกตำหนิ