คำถามติดแท็ก productivity

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

48 productivity 

ในNo Silver Bullet Fred Brooks สร้างการคาดการณ์ที่หลากหลายเกี่ยวกับอนาคตของวิศวกรรมซอฟต์แวร์โดยสรุปได้ดีที่สุดจาก: ไม่มีการพัฒนาอย่างใดอย่างหนึ่งไม่ว่าจะเป็นเทคโนโลยีหรือในเทคนิคการจัดการที่ตัวเองสัญญาว่าจะปรับปรุงประสิทธิภาพการผลิตตามลำดับความน่าเชื่อถือและความเรียบง่ายเพียงอย่างเดียว เหตุผลของเขาน่าเชื่อถือมาก Brooks เขียนในปี 1986: เขาพูดถูกมั้ย นักพัฒนาซอฟต์แวร์ในปี 2014 ผลิตซอฟต์แวร์ในอัตราที่น้อยกว่า 10 เท่าเร็วกว่าในปี 1986 หรือไม่? โดยการวัดที่เหมาะสม - การเพิ่มผลผลิตมีขนาดใหญ่แค่ไหน?

45 productivity 

ฉันกำลังคิดถึงการนำเสนอสั้น ๆ ที่ทำงานเกี่ยวกับการใช้ Stack Overflow เป็นทรัพยากรสำหรับงานประจำวันของคุณ ประสบการณ์ของคุณกำลังทำอะไรอยู่? คุณคิดว่าเป็นทรัพยากรที่ถูกต้องหรือไม่ที่จะบอกเพื่อนร่วมงานของคุณเกี่ยวกับมันหรือคล้ายกับบอกพวกเขาเกี่ยวกับ Google ว่าเป็นทรัพยากรหรือไม่ มีวิธีที่ดีกว่าในการทำมัน? ฉันเอนตัวไปถามด้านข้างของ Stack Overflow แทนที่จะตอบคำถามเหล่านี้เพื่อหลีกเลี่ยงการโต้แย้งที่คุณไม่ควรทำ เพียงแค่ติดตามผล เดิมทีฉันไม่ต้องการตั้งคำถามเฉพาะเจาะจงกับกรณีของตัวเองมากเกินไป งานนำเสนอของฉันจะเป็นการพูดคุยอย่างรวดเร็วสี่นาทีเท่านั้นซึ่งฉันจะพูดซ้ำหลายชั่วโมงไปยังกลุ่มต่าง ๆ ฉันอาจถามคำถามก่อนที่จะพูดคุยกับ Stack Overflow และอ้างถึงในระหว่างการนำเสนอ หวังว่าฉันจะได้รับกิจกรรมระหว่างชั่วโมง ฉันจะพูดคุยสั้น ๆ เกี่ยวกับเว็บไซต์ Stack Exchange อื่น ๆ ที่เหมาะสมกับผู้ชมเนื่องจากไม่ใช่นักพัฒนาทั้งหมด ฉันคิดว่า Super User, Server Fault และโปรแกรมเมอร์ควรทำงานได้ดี ฉันจะไม่ทำการนำเสนออีกสองสามเดือนเนื่องจากมีการจัดกำหนดการใหม่ แต่ฉันจะอัปเดตว่าฉันจะไปได้อย่างไร

45 productivity  communication 

ฉันสังเกตเห็นพฤติกรรมในตัวเองว่าฉันเรียกว่า "stopping point syndrome" ... หมายความว่าฉันไม่สามารถหยุดทำงานได้จนกว่าจะถึง "stopping point" (หรือฉันหมดแรง) กล่าวอีกนัยหนึ่งถ้าฉันอยู่ในโซนที่ทำงานเกี่ยวกับการทำให้คุณสมบัติเสร็จสมบูรณ์ฉันจะไม่หยุดจนกว่าจะเสร็จสิ้น หากเป็นข้อผิดพลาดที่ฉันกำลังทำอยู่เอฟเฟกต์นี้จะเด่นชัดยิ่งขึ้น ... ฉันจะไม่หยุดจนกว่าจะได้รับการแก้ไขหรืออย่างน้อยก็เข้าใจ แม้ว่าฉันจะทำงานจากแล็ปท็อปและมี VPN และสามารถกลับบ้านได้อย่างง่ายดายและรับงานในภายหลังในเย็นวันนั้นความจริงนั้นไม่ได้ช่วยให้ฉันออกจากงาน ... มันเหมือนว่าฉันกลัวว่าฉันจะตายก่อนที่ฉันจะพบจุดบกพร่อง . ฉันมีเวลายากมากที่จะอธิบายเรื่องนี้กับสมาชิกในครอบครัวที่ไม่สามารถเข้าใจได้ว่าทำไมฉันถึงไม่กลับบ้านจากการทำงานในเวลาเดียวกันและบางครั้งก็กลับบ้านเวลา 23.00 น. แม้แต่ผู้จัดการก็ยังงงกับสิ่งนี้และฉันสังเกตว่าเพื่อนร่วมงานส่วนใหญ่ของฉันไม่มีปัญหาในการทำงานในเวลาเดียวกันทุกวัน ไม่มีใครมีปัญหานี้หรือไม่? ฉันควรจะกังวลเกี่ยวกับเรื่องนี้และ / หรือพยายามที่จะเปลี่ยน? ถ้าเป็นเช่นนั้นได้อย่างไร

44 development-process  productivity  time-management 

ดังนั้นจึงเป็นที่ยอมรับกันโดยทั่วไปว่าโปรแกรมเมอร์ระดับสูงสามารถสร้างลำดับความสำคัญได้มากกว่า / ดีกว่ารหัสโดยเฉลี่ย เป็นที่ยอมรับกันโดยทั่วไปว่าอัตราข้อผิดพลาดที่เกิดขึ้นในโค้ดนั้นค่อนข้างคงที่สำหรับโปรแกรมเมอร์ แต่มีแนวโน้มที่จะได้รับผลกระทบจากกระบวนการที่ใช้เมื่อเขียนรหัสและหลังจากเขียนรหัสแล้ว (ตามที่ฉันเข้าใจ) มนุษย์มักจะทำผิดพลาดในอัตราที่ค่อนข้างคงที่ - โปรแกรมเมอร์ที่ดีกว่าเพียงสังเกตเห็นพวกเขามากขึ้น โปรดทราบว่าการยืนยันทั้งสองข้างต้นมาจากCode Completeโดย Steve McConnell ดังนั้นจึงไม่ใช่เรื่องของมุมมองที่แตกต่าง ดังนั้นฉันจึงเริ่มเห็นสิ่งนี้ในรหัสของฉัน ฉันสามารถใช้จำนวนโค้ดประมาณ 4-5 เท่ากับเพื่อนร่วมงานของฉัน (วัดจากคะแนนเรื่องราวที่ประเมินโดยทีม) ด้วยคุณภาพที่สูงขึ้น (ขึ้นอยู่กับตัวชี้วัดประสิทธิภาพและจำนวนการเปลี่ยนแปลงที่เกิดขึ้นหลังจากเช็คอิน) แต่ฉันก็ยังทำผิดอยู่ ระหว่างการทดสอบหน่วยที่ดีขึ้นความเข้าใจที่ดีขึ้นเกี่ยวกับสิ่งที่รหัสกำลังทำอยู่และการมองปัญหาที่ดีขึ้นเมื่อทำการตรวจสอบโค้ดฉันไม่ได้ผลิตข้อผิดพลาด 4-5 เท่า แต่ฉันยังคงผลิตประมาณสองครั้งเป็นโรคจิตหลายพบได้โดยการควบคุมคุณภาพเป็นนักพัฒนาอื่น ๆ ในทีมของฉัน อย่างที่คุณอาจจินตนาการสิ่งนี้ทำให้เกิดปัญหาบางอย่างกับผู้ที่ไม่ใช้เทคนิคทำการวัดแบบเมตริก ฉันพยายามที่จะชี้ให้เห็นว่าฉันผลิตข้อบกพร่องในอัตราครึ่งหนึ่งของเพื่อนของฉัน (และแก้ไขสองเท่าเป็นจำนวนมาก) แต่มันเป็นเรื่องยากที่จะขายเมื่อมีกราฟบอกว่าฉันผลิตข้อผิดพลาดเป็นสองเท่า ดังนั้นวิธีจัดการกับความจริงที่ว่าผลผลิตที่เพิ่มขึ้นจะนำไปสู่การเพิ่มจำนวนข้อบกพร่อง?

43 productivity  code-quality  bug 

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

41 productivity  configuration  development-environment  virtualization 

ฉันทำงานให้กับ บริษัท ใหญ่ (พนักงานมากกว่า 8,000 คน) เป็นเวลาเกือบ 2 ปีแล้วและได้รับการจ้างงานหลังจากเรียนจบหลักสูตร ทุกคนที่นี่ต้องจัดการรหัสประจำวันซึ่งมักจะออกแบบมาไม่ดีและเต็มไปด้วยแฮ็ก ในตอนแรกฉันเก็บข้อมูลไม่ดีพยายามอย่าวิพากษ์วิจารณ์สิ่งต่างๆ แต่สถานการณ์ตามที่ได้กลายเป็นเรื่องยากมากที่จะอยู่กับและดูเหมือนว่าไม่มีใครเต็มใจที่จะปรับปรุง / แทนที่เครื่องมือที่เราใช้ เพื่อให้ชัดเจนยิ่งขึ้นเรามี: เครื่องมือควบคุมแหล่งที่ล้าสมัย (Visual SourceSafe) makefiles เก่าธรรมดาที่รองรับเฉพาะการสร้างใหม่อย่างเต็มรูปแบบ .def ไฟล์ที่ต้องดูแลรักษาด้วยตนเองและแยกกันสำหรับสถาปัตยกรรมที่มีอยู่ทั้งหมด ส่วนหัวของเสาหินไฟล์และโครงการที่มีไฟล์ต่างกันน้อยมาก (แต่แต่ละไฟล์มีโค้ดประมาณ 3000 บรรทัดซึ่งบางครั้งก็ดูแลงานที่แตกต่างกันมาก) ไม่มีการใช้สิ่งอำนวยความสะดวกด้านภาษา "ใหม่" ( std::stringก็ไม่ใช่เรื่องใหม่ แต่ไม่มีใครยกเว้นฉันใช้) ฉันตัดสินใจไม่กี่เดือนที่ผ่านมาเพื่อทำอะไรกับมันโดยการออกแบบสภาพแวดล้อมการรวบรวมใหม่ ฉันสามารถสร้างบิวด์เพิ่มเติมเพื่อทำงานได้อย่างน่าเชื่อถือใช้เวลาในการคอมไพล์เร็วขึ้นสร้างโครงงานที่ดีกว่า.defสร้างไฟล์อัตโนมัติ ฉันยังสร้างบริดจ์จาก / ถึง Git ถึง / จาก Visual SourceSafe ฉันแสดงความสำเร็จของฉันต่อเพื่อนร่วมงานหลายคนและเจ้านายของเรา แต่ก็เหมือนไม่มีใครสนใจ พวกเขาทุกคนต่างก็พูดว่า "อืม ... ผู้คนเคยทำแบบนั้นแล้วทำไมเราจะเปลี่ยนสิ่งต่าง ๆ ? …

40 architecture  productivity  changes 

ที่ทำงานฉันได้รับเครื่องที่สมเหตุสมผล (ดูอัลควอดจ์ 2GHz, 4GB RAM, ไดรฟ์ 160GB 7200RPM, Win7) แต่ก็ขาดไปไม่กี่แห่ง (HDD / RAM) พนักงานไอทีก็โอเคกับฉันที่จะเปลี่ยนฮาร์ดแวร์ด้วยตัวเองดังนั้นตอนนี้ฉันจึงเล่นกีฬา SSD และ RAM 8GB เพิ่มเติม (ดังนั้นฉันจึงสามารถเรียกใช้ Visual Studios และเครื่องเสมือนหลายเครื่องได้) ฉันรู้ว่ามันเป็นการตัดสินใจทางธุรกิจของ บริษัท ที่จะเลือกเครื่องที่พวกเขาทำ แต่ในเวลาเดียวกันฮาร์ดแวร์ที่เร็วขึ้นทำให้ฉันมีความสุขและมีประสิทธิผลในการทำงานมากขึ้น ฉันเดาว่าคำถามของฉันคือฉันเป็นคนเดียว (ไม่ใช้ตัวเองสู้ :) ผู้ที่ยินดีที่จะใช้จ่ายเงินส่วนตัวบนฮาร์ดแวร์งานของพวกเขาเพื่อคุณภาพชีวิตที่ดีขึ้นและฉันควรเข้าใกล้ด้วยวิธีอื่นหรือไม่? เป็นไปได้ไหมที่จะพูดย้อนหลัง "ฉันคิดว่าคุณควรจ่ายคืนให้ฉันสำหรับฮาร์ดแวร์มูลค่า $ 500 เพราะ [blah]"

40 performance  productivity  hardware 

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

40 productivity  experience 

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

39 productivity  time-management 

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

39 productivity  coding 

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

38 productivity 

ผมเคยได้ยินเกี่ยวกับการเขียนโปรแกรมการเขียนโปรแกรมเป็นเวลาสองวันโดยไม่ต้องนอนและดื่มกาแฟและกระทิงแดง นอกจากนี้ในภาพยนตร์อย่างThe Social Networkในฉากที่พวกเขาแสดงให้เห็นว่าMark Zuckerbergได้เขียนโปรแกรมมา 36 ชั่วโมงแล้ว ฉันยังอ่านที่ไหนสักแห่งที่ใน บริษัท เช่น Facebook, Google, foursquareฯลฯ พวกเขาสามารถเขียนโค้ดได้นานกว่า 24 ชั่วโมงโดยไม่ต้องนอนหลับ นี่เป็นเรื่องจริงหรือ คุณสามารถสร้างรหัสคุณภาพสูงได้จริงหรือไม่หากคุณไม่ได้นอนหลับ สิ่งต่าง ๆ เช่น Red Bull ประกอบขึ้นเพื่อการนอนหลับได้หรือไม่?

37 productivity 

ฉันเป็น CTO ของ บริษัท ซอฟต์แวร์ที่มี codebase ขนาดใหญ่ (ทั้งหมด C #) และทีมวิศวกรขนาดใหญ่ ฉันสามารถดูได้ว่าส่วนต่าง ๆ ของรหัสจะง่ายกว่าในการเขียนใน F # ทำให้เกิดเวลาในการพัฒนาที่เร็วขึ้นข้อผิดพลาดที่น้อยลงการใช้งานแบบขนานที่ง่ายขึ้น ฯลฯ โดยทั่วไปแล้วการเพิ่มผลิตผลโดยรวมสำหรับทีมของฉัน อย่างไรก็ตามฉันยังสามารถเห็นข้อผิดพลาดในการทำงานหลายประการของการแนะนำ F # ได้แก่ : 1) ทุกคนต้องเรียนรู้ F # และมันไม่สำคัญเหมือนการเปลี่ยนจากพูด Java เป็น C # สมาชิกในทีมที่ไม่ได้เรียนรู้ F # จะไม่สามารถทำงานในส่วน F # ของ codebase 2) กลุ่มของโปรแกรมเมอร์ F # ที่จ้างได้ ณ ขณะนี้ (ธ.ค. 2010) …

37 functional-programming  productivity  maintenance  f# 

เมื่อแนวคิดของการเขียนโปรแกรมเชิงวัตถุได้รับการแนะนำให้รู้จักกับโปรแกรมเมอร์เมื่อหลายปีก่อนมันดูน่าสนใจและการเขียนโปรแกรมก็สะอาดขึ้น OOP เป็นเช่นนี้ Stock stock = new Stock(); stock.addItem(item); stock.removeItem(item); นั่นง่ายกว่าที่จะเข้าใจด้วยชื่อที่อธิบายตนเอง แต่ตอนนี้ OOP ที่มีรูปแบบเช่น Data Transfer Objects, Value Objects, Repository, Dependency Injection เป็นต้นนั้นมีความซับซ้อนมากขึ้น เพื่อให้บรรลุถึงข้างต้นคุณอาจต้องสร้างหลายคลาส (เช่น abstract, factory, DAO เป็นต้น) และใช้อินเทอร์เฟซหลายตัว หมายเหตุ: ฉันไม่ขัดกับแนวปฏิบัติที่ดีที่สุดที่ทำให้การทำงานร่วมกันการทดสอบและการรวมระบบง่ายขึ้น

36 design-patterns  productivity  programming-practices  object-oriented-design