Бореться як програміст. Потрібна порада [закрито]

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

Але є різниця між "виконанням роботи" та "виконанням роботи належним чином". Давайте скористаємося прикладом.

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

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

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

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

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

Я планую влаштуватися на роботу після нового року. Мені потрібна безпека роботи. Саме тому я задаю це питання.

Які поради ви можете дати в питаннях саморозвитку та самовдосконалення? Чи варто менше турбуватися? Або, можливо, шукати роботу в якості розробника PHP, коли я не буду безпосередньо обробляти SQL запити?

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

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

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

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

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

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

Бути професіоналом у цій галузі - це постійно побивати себе проти власної неадекватності. Зробіть це 8–5 по понеділок по п’ятницю, можливо більше, якщо настає термін, приємні вихідні, і повертайтеся ще для понеділка. Оце робота.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недосвідчений програміст часто потрапляє в пастку перепланування:

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

З цією логікою є ряд помилок.

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

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

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

Такий підхід дозволить вам навчитися достроково .

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

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

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

Але є різниця між "виконанням роботи" та "виконанням роботи належним чином".

Ні, немає, і я думаю, що це корінь вашої проблеми. Мені здається, ви занадто зациклювались на тому, щоб турбуватися про те, щоб робити справи "правильно", оскільки як індивідуальний розробник ви не бачите, як працюють інші. Але правильно відповідно до кого? Хто ця чарівна людина, яка вирішує, що те, що ви робите, є «правильним»? Візьміть 100 кращих програмістів у світі, і я гарантую, що жодне з двох не погодиться на 100% на кожну тему програмування.

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

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

А тепер піди щось * * *