Недоліки в дизайні та боротьба з приниженням з цього приводу [закрито]

Ви завжди були принципово правильними у запропонованих вами розробках програмного забезпечення? Коли ви видаєте якусь конструкцію, яка була принципово неправильною, ви, як правило, втрачаєте повагу членів своєї команди. Незважаючи на те, що ви робите після цього, ви в кінцевому підсумку знаходяться за все, що ви запропонували після цього інциденту. Це особливо гірше, коли ви новачок у команді, і вони не знають вашого минулого, де у вас були хороші історії успіху.

Можливо, причина, по якій ви створили поганий дизайн, була через відсутність досвіду чи знань чи те й інше в цій галузі. Як ви зіткнулися з такою ситуацією? Це як одноразова річ у вашій кар’єрі чи це відбувається увімкнення та вимкнення? Хтось поставить це позаду чи комусь у такій ситуації потрібно шукати новий напрямок роботи? Кілька чесних відгуків, будь ласка ...

Дякую.

Одного разу vp статки 500 коштував компанії в 1 мільйон доларів з поганим бізнес-рішенням. Коли він, звернувшись із відставкою генерального директора, відповів йому: "Я щойно вклав у вашу освіту один мільйон доларів, і тепер ви намагаєтесь піти? Я не приймаю".

Я втомлююсь від керівників та інших працівників, які швидко звинувачують помилку в тому, що хтось є новобранцем, або припускаючи, що вони некомпетентні. Є лише один спосіб стати хорошим дизайнером, а це - f @ $% на кілька. Мені байдуже, чи мої співробітники помиляються, мені байдуже, якщо вони роблять одне й те саме кілька разів. Питання в тому, наскільки покірний і наскільки ви навчальний? Коли хтось подає вам вашу помилку, ви спочатку захищаєтесь чи чуєте їх? Якщо ви один з рідкісних хлопців, котрий може проковтнути його гордість і навчитися на цьому, то вам варто зациклюватися. Кожен, від кого ви втрачаєте повагу за те, що помилився один раз, не є тим, хто заслуговує на вашу повагу.

Мені особисто довелося переписати перші два проекти, які я розробив хоча б двічі, але ви знаєте, що? Я навчився тон, і хоча мої роботодавці в цей час були збурені, це швидко було компенсовано ефективністю, яку я здобув з часом, готові вчитися на своїх помилках.

Що стосується принизливого аспекту та як відновитись, я маю дві поради. По-перше, люди за часом забувають. Крім того, коли хтось інший має прожектор на них, вони теж будуть гвинтовими. Тоді всі знову будуть рівні. По-друге, не будьте мудаком для інших, коли вони роблять чесні, навчання, помилки. Насправді, ви повинні заохочувати їх, якщо вони просто не потребують твердого удару в попу. Ви можете з часом допомогти змінити культуру своєї команди, пам’ятаючи, як ви себе почували, коли ви зробили чесну помилку. Ви зрештою надихнете людей бути кращими програмістами, дизайнерами та людьми.

Я цим займаюся давно (15+ років), і досі не встигаю правильно. Найкращі проекти виходять з ітеративного, спільного процесу. Коли ви деякий час працювали над дизайном, легко потрапити в пастку, думаючи, що це єдиний спосіб зробити це. Свіжа перспектива корисна для того, щоб побачити речі, які вам не вистачає.

Для того щоб це працювало, команді потрібно довіряти один одному. Ви не можете побоюватися показати людям дизайн, який може бути хибним, і потрібно мати можливість приймати критику дизайну. У свою чергу, решта команди повинні розуміти, що вади дизайну не є відображенням дизайнера. Це очікувана частина дизайну. Це також, як члени команди вчаться і стають кращими: від власних помилок та помилок інших.

Якщо ви перебуваєте в нефункціональній команді, яка не працює так, у вас є два варіанти:

1. спробуйте виправити команду
2. знайти нову команду (або внутрішньо, або у нового працівника).

Наскільки я знаю, я завжди був принципово виправданим . Це не зовсім те саме, що бути принципово правильним . Часто обставини змінюються між часом, коли ви повинні прийняти рішення "x", і часом, коли стає зрозуміло, що "x" було неправильним заднім числом .

Це ніби підготовка податків на прибуток у США. Дуже багато людей думають, що тут має бути відповідь. Немає. Ви маєте свою думку; ваш податковий бухгалтер має свою думку; IRS має свою думку.

Коли я роблю помилки, я не втрачаю нікого поваги. (Наскільки я знаю.) Я думаю, що це тому, що частково я завжди визнаю власні помилки. (Насправді, я часто виявляю власні помилки.) Крім того, майже у всіх значних дизайнерських рішеннях більше ніж одна людина підписується на них. Будь-які помилки в цих рішеннях належать групі, а не повністю одній людині.

Що стосується визнання помилок, я думаю, що це стає простішим, коли ви набуваєте компетентності та досвіду. На мій досвід, чим новіше ти будеш розробляти та розробляти, тим менше ймовірність визнати помилку.

Це трапляється позаду, і це не повинно зірвати вашу кар'єру. Ніхто не знаходить відповідальної відповідальності незмінно приймає правильні рішення. Насправді, ніхто, який несе в собі значну відповідальність, незмінно приймає оборонні рішення.

Але більшу частину часу ви повинні мати можливість приймати захисні рішення на основі неповної інформації. Як сказала б моя дочка: "Це просто люди".

Іноді всі не так трапляються. Помилки неминучі. Признавайся вільно, коли ти неправий, вчись на своїх помилках і проявляй смирення, особливо якщо ти спочатку не був переконаний, що ти насправді помилився.

"Приниження" не повинно відбуватися ніколи і ніколи. Це, швидше за все, не покращить працездатність людини.

Тут у моїй компанії ми виробили культуру поваги до тих людей, які все ще готові дотримуватись жорстких рішень, але можуть визнати, що вони помиляються, і коригувати свою поведінку, коли це потрібно.

Ви завжди були принципово правильними у запропонованих вами розробках програмного забезпечення?

Так, я нелюд! Ну, звичайно, ні.

Коли ви видаєте якусь конструкцію, яка була принципово неправильною, ви, як правило, втрачаєте повагу членів своєї команди.

Немає! Якщо це трапиться, то з командним духом щось не так.

Усі роблять помилки. Деякі рішення виявляються хорошими, деякі поганими, більшість - щось середнє. І успіхи, і невдачі слід сприймати як урок, як ви, так і решта команди.

Перші помилки можуть відчувати себе погано, але після того, як ви зробили їх сотні, це просто як частина роботи.

Це трапляється з усіма. Головне - вчитися на своїх помилках і намагатися не допускати цього повторення. Також обов’язково визнайте, що це була помилка з вашого боку. Наприклад, я одного разу допустив помилку, використовуючи нижчий рівень доступу до даних (SubSonic3). У той час, коли я приймав рішення, я просто хотів відійти від розроблених вручну запитів SQL. Тож я вибрав те, що в той час здавалося одним із найпростіших для початку. Я теж не був досвідчений з DAL. Ну, після вирішення декількох проблем мені було цікаво, чому деякі запити затягуються занадто довго, і я виявив, що SubSonic без поважних причин тягнув цілі таблиці.

Отже, я сказав своєму начальнику, пояснив, що я помилився, і дав йому свій план виправити. Мій начальник, звичайно, не був у захваті від мене, зробивши досить велику помилку, вимагаючи декількох днів чистої міграції. Але він також переконався, що я знову не помилився. Він змусив мене створити проект з підтвердженням концепції для наступного шару доступу до даних, до якого я запропонував перейти, і ми переконалися, що він буде працювати з нашими вимогами, і що він не знищує цілі таблиці. Загалом, для мене це був хороший досвід навчання, і тепер я обов'язково переконаюся, що ключова частина проекту відповідає вимогам і не матиме великих проблем.

Тому в основному те, що ти робиш, це:

1. Признайся, ти помилився
2. Складіть план, щоб це виправити
3. Переконайтеся, що ваш план справді спрацює
4. Переконайтеся ще раз.
5. Полагодь це!

Якщо ви не знаєте, як це виправити, не бійтеся залучати інших членів команди.

Останнє, розслабтесь! Усі роблять помилки. Дуже мало людей отримують це ідеально з першого разу

Це примхливі моторошні змагальні речі, і не дуже хороша ситуація, в якій бути. Ніхто не завжди має рацію, і немає чого соромитися, якщо хтось придумає кращий спосіб зробити це, або якщо вони знайдуть проблему з як ви це зробили.

Вам потрібно емоційно позбавитись від свого рішення і витратити свій час на пошук найкращого рішення, тоді ви можете бути задоволені, коли проблема вирішена, навіть якщо її вирішує хтось інший.

Ви багато чого не говорите у своєму питанні. Я не можу сказати, що таке ваше налаштування для "видачі дизайну". Це первісна дискусія з однолітком щодо запланованого підходу чи це надання, на що ви сподіваєтесь, остаточного коду?

Якщо колишній, то немає ніяких причин почуватися погано і немає причин, щоб ваші ровесники підозрювали вас у майбутньому.

Якщо ви чекаєте остаточної доставки, щоб обговорити свій дизайн з кимось іншим, то я не звинувачую їх у тому, що вони підозріли у вашій іншій роботі.

Кожен повинен обговорити свій дизайн з кимось іншим. Залежно від складності чи критичності, можливо, вам доведеться обговорювати це з кількома людьми кілька разів. Кожен може помилитися, неправильно зрозуміти вимогу або пропустити спеціальну справу.

Помилки, виявлені на початку, легше та дешевше виправити. Вони повинні бути дуже простими, якщо ви не повторюєте одні й ті самі помилки. Експертні оцінки полегшують ранні помилки на помилках.

Якщо ви намагаєтесь бути самотнім кодером в командному середовищі, ви здійснюєте (майже невиправданий) гріх, думаючи, що ви досить досконалі, що вам не потрібна чужа допомога. Той факт, що це командне середовище, доводить, що проблема досить велика, що ніхто не збирається все це зрозуміти. Люди повинні розмовляти один з одним, або якщо помилки призведуть до того, що їхні голови будуть занадто близько до звільнення (або після звільнення).

Я завжди робив різницю між, з одного боку, добрими чи поганими рішеннями; а з інших правильних і неправильних рішень. Хороше рішення - це те, що за тих самих обставин з однаковою інформацією ви б ухвалили те саме; Погане рішення - це таке, яке ви б прийняли інакше. Правильне рішення - це рішення, яке за допомогою огляду та додаткової інформації виявляється правильним; і навпаки, з неправильними рішеннями.

Часто говорили, що людина, яка не приймає неправильних рішень, ніколи нічого не приймає. Неправильні рішення - це спосіб навчання. Погані рішення часто посилюються через те, що той, хто приймає рішення, вкладає себе у рішення і намагається ретроспективно обґрунтувати рішення або довести, що воно було гарним рішенням врешті-решт (приховування завжди більше шкоди, ніж оригінальне рішення).

Більшість прийнятих мною дизайнерських рішень виявились правильними, але я навчився більшості та вдосконалював ті рішення, які були невірними. Я сподіваюсь, що дуже мало моїх рішень були поганими рішеннями, але частина проблеми поганих рішень - це визнання того, що рішення було поганим, і прийняття часто невдоволених уроків, які випливали з них.

До тих пір, поки вони не стануть " Ранковою ранковою четверкою ". Я не маю ніякої користі для того, хто сидить через усі дизайнерські дискусії, не кажучи нічого, лише стверджуючи, що знав, що це не спрацює після факту. Ви повинні вміти брати критику, навіть якщо вона не поставлена ​​в конструктивному контексті.

Напевно, одна з найкращих особливостей сайту SO - це можливість ризикувати та запропонувати та непевне рішення. Це ви дізнаєтесь. Йти по життю з купою лайно в голові, що неправильно, але ти ніколи не говорив про контракт, це справжня незнання.

Вони можуть знати щось, чого ви не знаєте, але вони все не знають. Займіться цим, займіться роботою і щось зробіть. Нехай вони витрачають час, думаючи, що вони такі прокляті розумні.

Я завжди забезпечував гарний дизайн? Немає! Я прагну це зробити, я прагну покращитись, але з кожним наступним проектом я можу завжди виглядати те, що я робив раніше, і переслідую, як я якось пропустив оцінку.

Що стосується того, хто запропонував дизайн, який не є зоряним, я б не заперечував проти цієї людини, якби ця людина продемонструвала, що бажає вчитися на помилці та була відкрита до критики. Якщо я бачу докази того, що людина так само прагне стати кращим і має здатність до цього, то погана дизайнерська пропозиція - це лише можливість навчання.

Це трапляється з усіма час від часу, тому найкраще робити, щоб зрозуміти, чому дизайн був неправильним, і навчитися цьому. Якщо це брак знань, то, невдача дизайну, сподіваємось, дасть вам нові знання, які ви зможете використати наступного разу. Не дозволяйте це відштовхувати вас, кожен переживає це в певний момент. Це найкращий спосіб набути досвіду та спійматися з новою командою / оточенням.

Це трапляється часто. Наша галузь змінюється настільки стрімко, що шанси ніколи не помилитися фактично дорівнюють нулю.

Однак ти штовхнув поганий дизайн вниз по грудях над їхніми запереченнями? Ось чому вони можуть реагувати на них.

Якщо помилка була масовою, звичайно знадобиться час, щоб відновити повагу. Якщо хтось із ваших колег сприйняв вас у поганому напрямку та створив проблеми для всієї команди, то чи не знадобиться би він, щоб найближчим часом проявити себе більше?

Все, що ви можете зробити, це визнати, що ви помилилися, надайте належне тому, хто мав рацію, і прагніть краще слухати та краще досліджувати варіанти в майбутньому.

Що ви не вважали, що дизайн помилився? (Не випадковий приклад - спроектуйте процес імпорту для використання існуючої веб-служби, яка працює за рядком (повторне використання коду та потребує зміни лише правил бізнесу в одному місці), не розуміючи, що деякий імпорт матиме мільйони записів, і це займе кілька днів до закінчити.) Навчіться цьому і розглядайте ці речі в майбутньому.

Там буде завжди бути помилки. Помилятися - це бути програмістом. Продовжуйте вчитися у інших в Інтернеті, особливо у ваших колег. Єдиний ганьба тут полягатиме в тому, щоб здатися або закопати голову в пісок, коли мова йде про такі питання, як тут.

Покладіть його за собою, опустіть голову і зробіть все можливе. Якщо ви хороший програміст, ви будете світити через свої помилки.

Якщо ви не впевнені, що ваша ідея лежить на міцній основі, вам слід обговорити її з кількома довіреними колегами, перш ніж запропонувати її всій компанії або відділу. Насправді, навіть якщо ви впевнені, вам все одно слід обговорити це з людьми, з якими ви працюєте, і які, швидше за все, знають вас найкраще. Вони допоможуть вирішити проблеми на початку.

У нас це трапляється часом. Використовуйте першу конструкцію як прототип. Дізнайтеся, що саме працювало, а що не було і чому. Тоді ви можете написати набагато кращий кінцевий продукт.

Не намагайтеся виправдати себе або захиститись. Визнайте помилку і рухайтеся далі.

Фундаментальна проблема, схоже, не пояснюється: це соціальна проблема. Таку поведінку ви можете побачити майже в кожній професії: якщо ви помилитесь, і їм подобається «класифікувати» вас у певних речах, це назавжди. Це соціальна поведінка. Навіть розумні та розумні люди схильні наслідувати всіх.

Дозвольте навести приклад, який не має нічого спільного з програмуванням: на попередній роботі я забув один раз або два рази помити посуд. Відтоді всі працівники думали, що я та людина, яка ніколи не миє посуд. А тепер, як тільки у мийці є брудна річ, це я (хто ще це міг би бути).

Це скрізь те саме: це соціальна поведінка, незалежно від того, яка це проблема.

Ти мені кажеш, що хочеш чесного відгуку? Єдине рішення - кинути роботу на іншу роботу. Якщо всі люди колективу вважають, що ти не добрий у своїй роботі, це незабаром не зміниться, шкода сказати це таким чином. Тому шукайте іншу роботу, тому що ви ніколи не зміните подібну (дурну, я мушу визнати) соціальну поведінку.

Ключовим є те, як ви заявляєте про свою справу та які зміни ви вносите. Якщо ви претендуєте на гуру програмування, який не робить нічого поганого і є приголомшливішим, ніж Джон Скіт, то цілком ймовірно, що в якийсь момент вас зберуть за це. Ключовим є те, як ви представляєте свої рішення, щоб ви могли показати, що це розумне рішення проблеми, а не ідеальне рішення, яке навіть не слід перевіряти.

Найкращим моїм прикладом може бути виявлення побічних ефектів від проведення класу staticу веб-додатку, де я працював колись. Я не знав, наскільки погано було б, щоб цей один екземпляр зберігався і ділився з усіма користувачами програми, але я навчився цьому і вчасно відновився. Іноді може статися так, що щось знайдеться, і необхідно внести основні виправлення. Я теж був у тому таборі, де мені довелося просіяти купу VBScript, щоб зменшити рядкові конкатенації, які викликали проблеми з пам’яттю, де я працював колись. Я навіть пам’ятаю, як писав код, вразливий до ін'єкцій SQL, ще в 1998 році, коли я писав пошук коду клієнта, який повинен був динамічно генерувати SQL, оскільки у цій частині програми було близько 20 необов’язкових полів.

Перфекціонізм може бути дещо острим мечем, ось як я бачу цей 3-й коментар, а також є способом, яким я є часом. Погано бачити, що є всі ці помилки, і нічого ніколи не буває правильно. Добре в тому, що, отримуючи найкраще, що можна, ти цілком можеш зустрітися, якщо не перевершити очікування інших від тебе. Постійне вдосконалення цілком може стати комп’ютерним способом побачити перфекціонізм, і якщо він тримається в помірності, я вважаю це гарною справою. Чи не зважає на всі допущені помилки ваш код? Це робить роботу? Це точки, на які слід замислитися, а також, якщо хтось завжди щось на цьому фіксує, чи добре, що ти хочеш бути чудовим так погано, що краще не робити нічого іншого, поки це не ідеально? Практика може бути корисною, щоб допомогти знайти схеми, щоб краще виконати роботу. Однак,