Баланс між «правильним інструментом для роботи» та знайомством [закрито]

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

Нічого собі, це ДУЖЕ важке питання, коли його виводять із світу теорії та у світ виробництва.

В теорії

Простий. Завжди використовуйте найкращий інструмент для роботи і просто вивчіть, що вам потрібно.

На практиці

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

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

Поза теорією є серйозні наслідки для вашого вибору технології.

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

Якщо це особистий проект - завжди використовуйте «правильний» інструмент - тож, зіткнувшись з цим рішенням у бізнес-контексті, ви можете здійснити більш обізнаний дзвінок.

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

http://headrush.typepad.com/creating_passionate_users/2006/08/when_the_best_t.html

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

Мій загальний підхід:

1. Якщо це невелика або короткочасна річ, завжди записуйте її у знайомі інструменти.
2. Якщо це велика, довгострокова річ, погляньте на користь витрат і вигод від вивчення нового інструменту.
3. Якщо ви не впевнені, ставитесь до цього як до короткотермінової речі, поки у вас не з’явиться доказ того, що це довгострокова річ. Потім зайдіть і знову подивіться на рішення.

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

Чудове запитання! Як сказав у своїй відповіді whatsisname, "знайомству не вистачає кредиту". Інший інструмент, інша рамка, інша мова може бути набагато кращим, ніж те, що ви звикли користуватися, і ви все одно будете набагато менш продуктивні з ним уперше, коли вивчили мотузки.

Я працюю кілька років як розробник ASP.NET в цифрових агентствах, де ми поєднуємо великі проекти, невеликі проекти, жорсткі проекти, добре набиті проекти тощо. Що ми намагаємось зробити, щоб розширити свої навички, це шукати "м'які цілі", більш дрібні проекти, які не мають болісно жорстких та жорстких термінів, і використовувати їх як можливість використовувати нові технології, які можуть бути вищими. .NET 2.0, 3.5, 4.0, ASP.NET MVC, Linq to SQL, Entity Framework - усі вони я вперше використав у такому проекті.

Якщо ви зможете скористатися вашими можливостями таким чином, то, сподіваємось, ви будете готові з більшим набором варіантів вибрати правильний інструмент, не відчуваючи дефіциту знайомства. Так само, як у прикладі Хуліо: вони знайшли ціль, куди вони могли б додати Ruby до свого репертуару, а тепер ідучи вперед, вони можуть вибирати між Java та Ruby.

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

Це залежить від кількох речей:

1. Наскільки ви добрі у вивченні нових мов чи інструментів.

Якщо ви швидко навчаєтесь, бар'єр у вивченні нових мов чи інструментів нижчий. Це дає можливість додати ще один інструмент до панелі інструментів.

2. Наскільки незалежно від мови / інструменту, ви робите своє робоче середовище.

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

Хтось із vim або emacs не має цієї проблеми. Все, що їм потрібно зробити - це вивчити нову мову.

3. Ділова реальність

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

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

Якщо вам цікава нова мова, і ви (і бізнес) можете собі це дозволити, то чому б не дати собі пару тижнів на місяць вивчити її?

Ось як я навчився рубіну. Мій партнер з кодером мав 7 років досвіду роботи з Java. Я мав 11 років досвіду Java. Ніхто з нас нічого не знав про рубін, тільки що ми хотіли його спробувати.

Я переконав його та решту компанії спробувати рубін протягом місяця (це був проект на 6-8 місяців). Найгірший випадок, ми почали б за цей час використовувати Java.

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

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

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

Моя власна версія - "використовувати потрібний мені інструмент" для роботи. Бути "доступним" означає, що я вмію ним користуватися, а не лише те, що я можу купити / отримати компілятор та // або час виконання.

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

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

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