คิดว่าตัวเองเปลี่ยนไปรึเปล่า

เวลามีคนมาทักว่า “คุณเปลี่ยนไปนะ” คนฟังก็จะรู้สึกในแง่ร้ายๆมากกว่าแง่ดี
แล้วทำไมเราไม่คิดว่า “คุณเปลี่ยนไปนะ” มันเป็นเปลี่ยนไปในทางที่ดีนะ?

ทำให้คิดต่อว่า เราทำงานมา3ปีกว่า (นานเหมือนกันแฮะ) ผมเปลี่ยนไปหรือไม่

คงต้องถามก่อนว่า คำว่าเปลี่ยนไปในทางดีหรือร้าย

สิ่งที่เป็นก่อนจะเริ่มทำงาน

1. ค่อนข้างขี้อาย ไม่ค่อยพูด
2. รักสงบ ไม่ค่อยเข้าสังคม
3. ไม่กินเหล้า
4. ความรู้หางอึ่ง ปฎิบัติก็เหมือนกัน
5. มองโลกในแง่ร้ายพอสมควร
6. ประหยัด แน่นอนว่าเงินเดือนเราน้อยใช้จ่ายต้องระวัง
7. ไม่ชอบการเปลี่ยนแปลง
8. ติดเกมส์ออนไลน์
9. ตั้งใจทำงานเพราะความรู้น้อย อ่านหนังสือบ่อย เพราะกลัวว่าพี่ๆให้ทำอะไรแล้วจะทำไม่ได้เป็นตัวถ่วง
10. ไม่ค่อยละเอียดรอบคอบ สาเหตุส่วนหนึ่งเป็นเพราะรู้น้อย
11. ขี้บ่น ขี้น้อยใจ เอามาบ่นในblog twitter บ่อยๆ
12. ตื่นเต้นบ่อยๆเวลาหัวหน้าเรียก
13. ไม่ค่อยมีปากมีเสียงกับใคร หัวหน้าสั่งงานก็รับปากอย่างเดียว ไม่ถาม

สิ่งที่ตอนนี้เป็น(เรียกว่าพัฒนาขึ้นหรือลงไม่ทราบ)

1. พูดมากขึ้น มีปากมีเสียงมากขึ้น
2. รักสงบเหมือนเดิม เข้าสังคมมากขึ้น
3. ไม่กินเหล้าเหมือนเดิม กินเบียร์บางโอกาส แต่น้อยจนเรียกว่าไม่ได้กิน
4. ความรู้ปานกลาง (ถ้าว่าความรู้สูงก็คงไม่ได้ยังไม่ได้เรียนรู้อีกหลายเรื่อง)
5. มองตัวเองมากขึ้น ถ้าเราเข้าใจถึงเหตุที่เป็นไปของมัน เราก็จะไม่โทษใคร
6. แอบshopมือหนัก แต่ก็ยังคำนึงถึงเลขในบัญชีอยู่เสมอ
7. ยังคงไม่ชอบการเปลี่ยนแปลงอยู่ยังต้องฝึกอีกเยอะ
8. เลิกได้แล้ว อันนี้ภูมิใจมาก
9. ตั้งใจทำงานอยู่เสมอ หนังสือพยายามอ่านอยู่ เพราะเราเป็น Developer นี่
10. ประสบการณ์สอนให้เราเป็นคนละเอียดรอบคอบ แต่ก็ยังมีอยู่เล็กๆน้อยๆอยู่
11. ยังบ่นอยู่แต่ เดี๋ยวนี้คิดมากขึ้นว่าไอ้ที่บ่นเราไม่ได้ทำอะไรบกพร่อง
12. ยังใจเต้นอยู่
13. ถามมากขึ้น หัด protect ตัวเอง

อาจจะมีที่ดีหรือเสียมากกว่านี้แต่ตอนนี้ยังนึกไม่ออก

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

ปล.ช่วงนี้ไม่ได้เขียนบล็อคทางโปรแกรม เพราะอ่านไปเขียนไปมันทำให้อ่านช้าลงเยอะเลย (แต่จะอ่านอย่างเดียวจะอ่านจบรึเปล่าก็ไม่รู้เหมือนกัน = =a)

Tags: ProgrammerLife, ในงาน

Key Design Concepts

นี่เป็นส่วนหนึ่งในหัวข้อของ Software’s Primary Technical Imperative: Managing Complexity
แปลมาจาก หนังสือ Code Complete #2

Importance of Managing Complexity

ความสำคัญของการจัดการความซับซ้อน

เมื่อรายงานผลสำรวจถึงสาเหตความผิดพลาดของ software-project พวกเขาไม่ค่อยจะระบุว่า ความผิดพลาดทางเทคนิคเป็นสาเหตุของความผิดพลาดใน project
การที่ Project fail มักมีสาเหตุมาจาก

- poor requirements
- poor planning
- poor management

ถ้า project จะ fail ในต้นเหตทางเทคนิค ก็มักจะมีสาเหตุมาจาก uncontrolled complexity หรือ การไม่ควบคุมความซับซ้อนที่จะเกิด เพราะ software มีการเติบโตในทางซับซ้อนได้ตลอดเวลาในแบบที่ไม่มีใครคาดคิด เมื่อถึงจุดหนึ่งถ้าหากโปรเจ็คมีความซับซ้อนแบบที่ไม่มีใครเข้าใจมันอย่าง แท้จริง ผลกระทบที่ตามมาจากการแก้ไขโค้ดที่หนึ่งส่งผลกระทบถึงในส่วนอื่นๆตามมา progress หรือความคืบหน้าของงานจะช้าลงหรือชะงักไปในที่สุด

อาจกล่าวได้ว่า Managing Complexity เป็นหัวข้อที่สำคัญที่สุดหัวข้อหนึ่งในทาง technical ของ software development.

Dijkstra (1972) ชี้ให้เห็นว่าไม่มีกะโหลกของมนุษย์คนไหนใหญ่พอที่จะบรรจุ โปรแกรมคอมพิวเตอร์สมัยใหม่ได้:ซึ่งหมายความว่าเราในฐานะ software developers ไม่ควรพยายามที่จะอัดโปรแกรมทั้งโปรแกรมเข้าไว้ในหัวเราในคราวเดียว ; เราควรจัดระบบโปรแกรมให้อยู่ในรูปแบบที่ง่ายต่อการ “focus” เมื่อใดที่เราต้องการได้, นั่นคือการลดขนาดของโปรแกรมของเราที่ลงถึงขนาดที่เราคิดเมื่อใดก็ตาม  เราอาจลองคิดเล่นๆเหมือนเราเล่นกลเลี้ยงบอลในอากาศ ยิ่งเราเลี้ยงบอลมากโอกาสที่จะทำบอลหล่นยิ่งสูง บอลแต่ละลูกที่เราทำหล่นก็นำไปสู่การออกแบบที่ผิดพลาด หรือ coding error

ในระดับของ Software-architecture, ความซับซ้อนของปัญหาจะลดลงเนื่องจากการ แบ่งระบบออกเป็น subsystems. ลองเปรียบเทียบว่า เราใช้เวลาทำงานง่ายๆในชิ้นส่วนเล็กๆหลายๆส่วน กับ แก้ปัญหาของชิ้นส่วนชิ้นโตส่วนเดียว แบบไหนดีกว่ากัน? เป้าหมายของทุกๆการออกแบบระบบ software คือการแตกปัญหาที่ซับซ้อนออกเป็นส่วนย่อยๆเพื่อการแก้ปัญหาที่ง่ายขึ้น ยิ่ง subsystems มีอิสระต่อกันมากเท่าไหร่ มันจะปลอดภัยในการfocusส่วนนั้นๆมากขึ้น

การกำหนดช่วงเวลาให้สั้นช่วยให้ลดภาระทางด้านจิตใจ(mental workload). เขียนโปรแกรมใน term ของ problem domain มากกว่าที่จะเขียนใน term ของรายละเอียดใน low-level implementaion (พุ่งเป้าไปที่ปัญหามากกว่าจะมองลึกลงไปในรายละเอียดการimplement) และทำงานกับ “highest level of abstration” คือมองจากผลลัพธ์ภายนอกสุด จะลดภาระของสมองเราได้มาก

ผลสำเร็จของ programmer คือความสามารถที่มนุษย์คนหนึ่ง(programmer) ทำได้เพื่อให้โค้ดของเขา ง่ายต่อการเข้าใจ ต่อตัวเขาเองและคนอ่าน และทำให้มี error น้อยที่สุด

How to Attack Complexity
Project ที่มีการ take cost สูง design ไม่มีประสิทธิภาพ มักมาจาก 3 ปัจจัย
- การมี solution ที่ซับซ้อนเกินไปเพื่อแก้ปัญหาเล็กๆ
- การมี solution ที่ง่าย และไม่เหมาะสมกับปัญหาที่ซับซ้อน
- ความไม่เหมาะสม กับการมี solutionซับซ้อน ที่มีต่อปัญหาที่ซับซ้อน

Dijkstra กล่าวว่า software สมัยใหม่นั้นมีความซับซ้อนโดยตัวมันเองอยู่แล้ว และไม่ว่าเราจะพยายามเท่าไหร่ในที่สุดเราก็ต้องเจอกับความซับซ้อนในระดับใด ระดับหนึ่งกับปัญหาที่มีในโลกแห่งความเป็นจริง

คำแนะนำในการจัดการกับความซับซ้อน
-ย่อขนาดของ ความซับซ้อนให้และแตกงานที่เป็นประเภท Essential Complexity ให้เหมาะสมกับคนที่จะสามารถแก้ปัญหาได้ในช่วงเวลาที่เหมาะสม
-จำกัดงานที่เป็นประเภท Accidental Complexity ให้น้อยที่สุด

หาก เราระรึกไว้เสมอว่า การจัดการกับความซับซ้อนมีความสำคัญไม่ยิ่งหย่อนไปกว่ากระบวนการทางเทคนิค ของ software การออกแบบที่ตามมาย่อมออกมาตรงไปตรงมาไม่ซับซ้อนเกินไป

Tags: design

ขอโทษประเทศไทย

โฆษณาตัวนี้โดนแบนจากกองเซนเซอร์ครับเพราะกลัวจะโดนฟ้อง …เห้อ!..

ขอโทษประเทศไทย

Tags: youtube

ชัดเจน

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

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

แล้วเราควรทำอย่างไร?
1)สร้างความชัดเจน ด้วยการเขียนปัญหาทั้งหมดออกมาเป็นข้อๆ
2)กำหนดความสำคัญของปัญหา หาทางแก้ปัญหาที่ง่ายที่สุดก่อน เป็นการสร้างความรู้สึกว่าเราแก้ปัญหาไปบ้างแล้ว (มันทำให้เรารู้สึกดีขึ้น ใจชื้นขึ้นได้จริงๆ)
3)ทำเป็นประจำ

Tags: ใช้สมอง

MCTS:12:User and Data Security ภาค2

MCTS:12:User and Data Security

Authenticating and Authorizing Users

Using Access Control Lists

Tags: .netFramework, c#, Cert, programming