Як кодувати швидше (без жертвоприношення якості) [закрито]

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

То як мені стати швидшим кодером, не приносячи шкоди якості? Задля цього питання я збираюся обмежити сферу застосування C #, оскільки це в першу чергу те, що я кодую (для розваги) - або Java, яка досить схожа в багатьох питаннях, що мають значення.

Те, що я вже роблю:

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

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

Окрім цього, я постійно отримував цю компенсацію від своїх менеджерів - будь то розробка Flash у масштабному масштабі чи корпоративна Java / C ++.

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

Я працював у невеликих та середніх командах (5-50 осіб) у різних компаніях над різними проектами та різними технологіями (Flash, ASP.NET, Java, C ++). Спостереження моїх менеджерів (про що вони мені прямо сказали) - це те, що я "повільний".

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

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

Чому? Що я пропускаю? Як я можу поправитись у цьому?

Моя кінцева мета проста: якщо я можу сьогодні виготовити продукт X за 40 годин, і я можу якось вдосконалити себе так, щоб завтра я міг створити той самий продукт о 20, 30 чи навіть 38 годин - це те, що я хочу знати - як мені туди дістатися? Який процес можна використовувати для постійного вдосконалення? Я думав, що мова йде про повторне використання коду, але цього недостатньо, здається.

Мені подобається підхід Джефа Етвуда до цього, який можна знайти тут http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

В основному, у статті він посилається на уривок із книги «Art & Fear» Девіда Бейлса і Теда Орланда. Уривок йде:

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

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

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

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

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

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

• Робота над побічними проектами.
• Робота над проектами з відкритим кодом.
• Працюйте з розробниками, які кращі за вас. Пара програми!
• Ознайомтеся з новими інструментами та прийомами. Тримайте те, що працює.
• Робіть вправи з програмування, призначені для навчання апарату прийняття рішень *.
• Контролюйте своє вдосконалення на основі об’єктивних показників, таких як швидкість та швидкість дефектів, та суб'єктивні показники, такі як якість та придатність коду.

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

* http://codekata.pragprog.com/

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

У деяких середовищах розробки ¹ просто не варто витрачати додатковий час на виготовлення чогось відшліфованого, коли "достатньо добре".

^{1 - Я думаю саме про "внутрішніх інструментарів", але, мабуть, є й інші.}

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

Тому я маю кілька пропозицій для вас:

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

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

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

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

З роками / місяцями, коли ви потрапляєте у рух за кермом і автострадами, ви дізнаєтесь кілька хитрощів на шляху, що робить ваше водіння веселим. Це те, що ми називаємо досвідом. Ті "хитрощі" (які я називаю рисами) - це те, що допомагає.

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

Підсумовуючи:

• Досвід створює риси, які підвищують довіру та покращують програмне забезпечення.

PS: Досвід також випливає з навчання інших. Наприклад, допомога від SO, парне програмування, експертні огляди тощо. Ви не можете мати досвіду, якщо не можете озирнутися назад і навчитися на помилках (або якщо хтось ніколи не кидає виклик вашим зусиллям).

Питання в тому, якщо ви дешевше дивитесь на довгострокову загальну вартість.

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

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

Якщо ні, то ви рішуче повинні врахувати, чому це так:

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

Подумайте і відредагуйте своє запитання своїми висновками.

Усі люди, які допитувались про те, чи справді ти повільний, чи ні, - це безглуздо. Стати швидшим програмістом без шкоди для якості - це завжди хороша мета, незалежно від того, наскільки ти повільний або швидкий. Це моя мета № 1 як програміста, і я ніколи цього не досягну. Я завжди намагаюся зробити швидше, не жертвуючи якістю, я одержимий цим. Ось що для мене працювало досі в порядку корисності, а також кілька експериментальних ідей наприкінці:

1) Ніколи не припиняйте вчитися: Дізнайтеся все, що можна про програмування та використання комп'ютерів взагалі. Знайдіть слабкі області та вивчіть їх. Навіть якщо це здається абсолютно не пов'язаним з вашою роботою та C #, я гарантую, що якщо ви шукаєте її, ви часто знайдете способи застосувати її до того, що ви робите. Навчання також стосується досвіду, тому не просто читайте речі, а спробуйте і розширіть свої навички. Якщо ви звикли користуватися Windows, спробуйте Unix або навпаки. Якщо вам зазвичай подобається використовувати інструменти командного рядка спробуйте командний рядок і текстові редактори або навпаки. Якщо ви чуєте про інструмент або технологію, про які ви раніше не чули або про неї не знаєте багато, не піддавайтеся спокусі рухатися далі. Подивіться! Не бійтеся мислити поза межами та вивчайте нові експериментальні технології, які, на думку інших, є непрактичними;

2) Розбийте проекти: Спробуйте розбити проекти на міні-проекти. Спробуйте робити новий випуск щодня або максимум раз на кілька днів. Запитайте себе "Який мінімальний обсяг функціональності я можу випустити та все-таки випустити щось корисне для користувача". Це навичка, яку ви навчитеся, виконуючи її. Можливо, вам доведеться переконати своїх менеджерів дозволити вам це зробити, але вони, як правило, будуть задоволені результатами досить швидко. Роблячи це, ви почнете помічати, що речі, які, на вашу думку, були важливими для вашої функції, - це фактично додаткові функції, які можна буде розробити пізніше. Це дозволяє вам та вашим менеджерам надавати пріоритет лише найважливішим характеристикам замість усіх функцій, пов’язаних із тією, над якою ви працюєте. Це дозволяє швидше мислити, зберігаючи розум чітким та зосередженим. Ви в свою чергу законно програмуєте швидше. Ваші менеджери або принаймні менеджери менеджера також можуть сприймати, що ви зараз програмуєте навіть швидше, ніж ви є насправді, тому що ви отримуєте більше релізів. Ще одна величезна перевага цього полягає в тому, що ви будете набагато краще оцінювати тривалість випусків до завершення, і ваші менеджери будуть любити вас за це. Оскільки ви вже робите безліч автоматизованих тестувань, у вас не повинно виникнути проблем із стабільними часто випусками. Вам може знадобитися покращити автоматизовану систему збирання. Я настійно рекомендую прочитати книгу Безперервна доставка з серії Мартіна Фаулера. Це важко читати і тому, що воно надзвичайно повторюється, але все ще дуже корисно. Менеджери s також можуть сприймати, що ви зараз програмуєте навіть швидше, ніж ви є насправді, тому що ви отримуєте більше релізів. Ще одна величезна перевага цього полягає в тому, що ви будете набагато краще оцінювати тривалість випусків до завершення, і ваші менеджери будуть любити вас за це. Оскільки ви вже робите безліч автоматизованих тестувань, у вас не повинно виникнути проблем із стабільними часто випусками. Вам може знадобитися покращити автоматизовану систему збирання. Я настійно рекомендую прочитати книгу Безперервна доставка з серії Мартіна Фаулера. Це важко читати і тому, що воно надзвичайно повторюється, але все ще дуже корисно. Менеджери s також можуть сприймати, що ви зараз програмуєте навіть швидше, ніж ви є насправді, тому що ви отримуєте більше релізів. Ще одна величезна перевага цього полягає в тому, що ви будете набагато краще оцінювати тривалість випусків до завершення, і ваші менеджери будуть любити вас за це. Оскільки ви вже робите безліч автоматизованих тестувань, у вас не повинно виникнути проблем із стабільними часто випусками. Вам може знадобитися покращити автоматизовану систему збирання. Я настійно рекомендую прочитати книгу Безперервна доставка з серії Мартіна Фаулера. Це важко читати і тому, що воно надзвичайно повторюється, але все ще дуже корисно. і ваші менеджери будуть любити вас за це. Оскільки ви вже робите безліч автоматизованих тестувань, у вас не повинно виникнути проблем із стабільними часто випусками. Вам може знадобитися покращити автоматизовану систему збирання. Я настійно рекомендую прочитати книгу Безперервна доставка з серії Мартіна Фаулера. Це важко читати і тому, що воно надзвичайно повторюється, але все ще дуже корисно. і ваші менеджери будуть любити вас за це. Оскільки ви вже робите безліч автоматизованих тестувань, у вас не повинно виникнути проблем із стабільними часто випусками. Вам може знадобитися покращити автоматизовану систему збирання. Я настійно рекомендую прочитати книгу Безперервна доставка з серії Мартіна Фаулера. Це важко читати і тому, що воно надзвичайно повторюється, але все ще дуже корисно.

3) Використовуйте техніку pomodoro і адаптуйте / зміните те, що не працює для вас. Якщо поєднувати це з номером 2 у цьому списку, ви отримаєте ВЕЛИЧЕЗНЕ підвищення продуктивності.

4) Дізнайтеся Vim. Навіть якщо ви закінчите використовувати ці команди в Visual Studio через ViEmu, або в межах Eclipse через плагін, або зсередини Emacs, ви отримаєте продуктивність. Найкращий спосіб навчитися Vim - почати користуватися ним і змусити себе ніколи не (відключати його / повертатися до своїх старих інструментів), поки ви не освоїли його. Спочатку боляче, але ти ніколи не захочеш повертатися назад, і навіть тиснеш, коли доведеться працювати без цього. Деякі кажуть, що це не значно збільшить вашу швидкість. Але швидше швидше, особливо, коли читати та змінювати код - ЩО МИ РОБИТИ, і я виявив, що заощаджую багато часу з цим при нагоді.

5) Цей останній не обов'язково рекомендується, оскільки я не впевнений, що це гарна ідея, і це може насправді знизити вашу продуктивність, але я все-таки пророблю його там. Ви можете спробувати зробити більше приймальних тестів і менше одиничних тестів, або, принаймні, переконайтеся, що ви зробили тестування прийняття. Я мав успіх у SpecFlow, але підозрюю, що там щось краще. Навіть написання специфікацій може бути досить технічним, тому ви, можливо, хочете, щоб ваш менеджер / клієнт спочатку написав грубу версію чернетки, яку ви змінили істотно, або ви можете написати всю річ самостійно і просто прочитати їх, і все це добре. У цьому вам допоможе номер 2 із цього списку. Також приймальні тести можуть бути більш практичними і вимагати менше коду, ніж одиничні тести. Це не означає, що вони замінюють їх різними інструментами для різних речей.

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

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

Крім того, читайте «Мистецтво програмування Unix» (безкоштовно в Інтернеті, книга варта ціни)

Нарешті, ви можете бути не в потрібному місці. Круглий кілочок у квадратній роботі тощо.

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

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

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

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

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

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

Парне програмування може скоротити час QA, і якщо ви вважаєте, що один програміст виробляє лише кілька рядків на день, якщо два можуть кодувати з такою ж швидкістю, як одна, але з меншими помилками, то ви ШЛЕШЕ вперед.

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

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

Чи розглядали ви, як працюєте, детальний аудит себе? Будь-яке ручне та паперове відстеження того, як ви проводите свій час, або використовуйте щось на зразок Rescue Time, щоб відстежувати себе.

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

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

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

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

Якщо нічого іншого, це дає вам деякі орієнтири, проти яких можна працювати.

Зі свого списку у тебе все добре.

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

Не пишіть код, який більше CRAP, ніж вам потрібно. ;)

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

1. Ваша компанія продає бібліотеки
2. Ви відновили повторюваний код у бібліотеці

Ти читаєш і робиш, і це чудово. Але ви, можливо, застрягли, думаючи про procuedural або OO-коді?

Щоб відточити техніку програмування OO, ви грали з Smalltalk / Squeak?

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

Я буду цитувати дядька Боба :

Єдиний спосіб пройти швидко - це йти добре.

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

- "Vehement Mediocrity", Роберт К. Мартін

Наскільки я знаю, це:

1. добре
2. швидко
3. дешево

Як менеджер ви можете вибрати будь-які 2.

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

Основні речі, про які я можу придумати, - це наступне

• Збільште швидкість набору тексту.
• Використовуйте інструменти, які забезпечують підвищення продуктивності. Наприклад ReSharper.
• Швидші машини чи інструменти. Як і більше оперативної пам'яті або твердотільний накопичувач.

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

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

Що з генераторами коду? Іноді код повторюється. Рефакторинг може видалити частину цього, але навіть тоді у вас можуть виникати повторювані дзвінки до тієї ж функції, що ремонтується. Залежно від даних та коду, з якими ви працюєте, генератори коду (написані в Excel, Perl, Java, що б там не було ...) можуть заощадити багато часу. А використання інструментів для створення коду для розробки інтерфейсу зазвичай не вимагає.

І нарешті, може, метрика помилкова. Чи вважали ви, що кодуєте з можливою швидкою швидкістю, враховуючи все інше, і що терміни занадто короткі, тому ви здаєтесь повільним кодером?

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

Або ... отримайте більше досвіду та практики в певній області, щоб ви так добре знали кодову базу та API, що могли кодувати рішення уві сні. Це можна зробити, але потрібно більше часу. Якщо інші розробники, які швидше за вас, стають старшими та досвідченішими, то робити лише одне - ви повинні стати старшими та досвідченими!

У мене є заперечення проти перегляду "жертвованої якості для швидкості" ОП.

Професійні кодери (програмісти) повинні задовольняти 3 об'єкти:
1) Код повинен працювати за призначенням
2) Доставка має бути вчасно
3) мати гарну якість, документацію тощо
4) інше тощо

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

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

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

Я виявив, що листи їдять набагато більше, ніж я думав, просто через перерву. Зараз я відповідаю лише на листи двічі на день і за кілька днів отримую майже 1 годину продуктивності. Спробуйте такі методи, як помодоро , я використовував це як засіб вимірювання. Через рівні проміжки часу (15 хвилин) я зазначав, що я робив у той час. Це дозволило мені побачити, як структуровані мої дні та що я можу зробити, щоб досягти максимальної ефективності.

Перевага Squeak у швидкому кодуванні виходить далеко за рамки лише «відточення навичок OOP». Є причина, чому на Smalltalk були винайдені сучасні графічні інтерфейси, а також IDE, не кажучи вже про те, що JUNIT був портом SUNIT до Java, термін "OOP" був винайдений для опису Smalltalk тощо.

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