پیش گفتار:
تراویس الفنت (Travis Oliphant) یکی از تاثیرگذارترین برنامه‌نویسان و دانشمندان داده است. او خالق NumPy و هم‌بنیان‌گذار SciPy و Anaconda و NumFOCUS است. این نوشته برگرفته از مصاحبه‌ای است که لکس فریدمن (Lex Fridman) با وی انجام داده است.
گفتار:
لکس فریدمن: می‌خواستم ازت چیزی بپرسم چون تو یکی از تاثیرگذارترین برنامه‌نویسان تاریخی و رهبر (مدیر) برنامه‌نویسان زیادی بودی و هنوز هم هستی. از دیدگاه یه برنامه‌نویس، چه عواملی باعث می‌شه یه برنامه‌نویس، برنامه‌نویس خوبی بشه و یا چی باعث می‌شه یه برنامه نویس، برنامه‌نویسی بشه با کارایی بالا.
تراویس الفنت: سوال‌ات سوال خیلی خوبی‌یه. فکر می‌کنم در دوره‌هایی از زندگی‌ام می‌تونستم جواب بهتری به این سوال بدم، چون من بارها به این موضوع فکر کردم. الان بیشتر وقت‌ام صرف استخدام همکاران بخش فروش می‌شه و ذهنم درگیر اونه.
ولی با مرور تجربیات گذشته‌ام و هم‌چنین کار کردن با برنامه‌نویس‌های واقعن فوق‌العاده‌ای که تیم‌هاشون رو رهبری می‌کنند و کار من الهام‌بخشی و اگه بشه کمک و حمایت اون‌ها و تیم‌هاشونه، می‌تونم به چند نکته‌ی کلیدی رو اشاره کنم.
اولی کنجکاوی‌یه(curiosity)! برنامه‌نویسی که کنجکاو نباشه، یه برنامه‌نویس معمولی می‌شه. خیلی زود هم انگیزه‌‌اش رو از دست می‌ده. همه‌ی تلاش‌اش رو هم نمی‌کنه. کنجکاوی اساسن یه ویژگی شخصی‌یه – یعنی اینکه شما تا چه حد درباره‌ی موضوعات کنجکاو هستید.
دومی اینه که نباید تلاش کنید همه چیز رو با هم و یه‌باره انجام بدهد. باید بپذیرید که ما به عنوان انسان محدودیت‌هایی داریم. هر کدام از ما هم محدودیت‌های خاص خودمون رو داریم و هر کدوم هم نقاط قوت و مهارت‌های خاص خودمون رو داریم. بنابراین، باید هنر برنامه‌نویسی رو با مهارت‌های خودتون تطبیق دهید.
یکی از چیزهایی که همیشه جواب می‌ده اینه که مساله‌ای که می‌خواهید حل کنید رو کوچک و محدود کنید. اگر عضو تیمی هستید احتمالن یکی دیگه معماری پروژه را آماده می‌کنه و یه بخشی از کار رو به شما می‌ده. اگه جوونید یا عضو تیمی نیستید، برای این که کار رو پیش ببرید خیلی مهمه که مساله رو به بخش‌های کوچک‌تر بشکنید. اگه یه پروژه بزرگ رو بردارید و بخواهید همه چیز را یکجا و یکباره انجام بدید، دور از انتظار نیست که توی اون گم بشید و کار رو به شکل بدی انجام بدید.
بنابراین، باید خیلی دقیق درباره‌ی کاری که می‌خواهید انجام بدید فکر کنید. مشخص کردن ورودی‌ها و خروجی‌ها، و تعریف دقیق کاری که باید انجام بشه حتی با روش ساده‌ای مثل نوشتن قبل از شروع کدنویسی خیلی مفیده. این که بدونید چه کار می‌خواهید بکنید و اون رو دقیق بیان بکنید واقعن مفیده.
از کارهای دیگران هم استفاده بکنید. فکر نکنید که باید همه چیز رو خودتون انجام بدید. هیچ‌کس این کار رو نمی‌کنه. روی شانه‌های غول‌ها بایستید (کنایه از اینکه از کارهای بقیه استفاده کنید). اما این جوری نباشه که فقط کپی-پیست بکنید. این موضوع به‌ویژه در دوره‌ی کنونی که کدکس (Codex – ابزار هوش مصنوعی OpenAI برای تولید کد) و کدهای خودکار تولیدشده اهمیت بیشتری داره. …. نکته اینجاست که کپی-پیست کنید ولی نه کپی-پیست کورکورانه. خودم بارها و بارها کپی-پیست کرده‌ام تا بفهمم و بعد متوجه شدم که این کد چه معنایی داره و چه کاری انجام می‌ده. تا جایی که می‌تونید باید کد رو بفهمید و درک کنید. توی این شرایط، کنجکاوی خیلی مهمه. اگر فقط کورکورانه کپی-پیست کنید، چیزی یاد نمی‌گیرید.
نکته‌ی بعدی اینه که حواس‌تون به چرخه‌های هیجان (hype cycle) باشه [توضیح پایین رو بخونید]. هر چند وقت یک‌بار، چیزی می‌آد که همه می‌گند «این جواب همه‌ی مشکلات‌مونه!». مثلن توسعه‌ی آزمون‌محور، برنامه‌نویسی شی‌گرا یا چابکی (Agile). مراقب باشید که توی دام این جور چرخه‌های هیجانی نیفتید. حتمن چیزهای ارزشمندی توی اون‌ها وجود داره که می‌تونید از اون‌ها یاد بگیرید، اما تقریبن مطمئن باشید که این جور چیزها پاسخ همه‌ی مشکلات نیستند.
توضیح:
چرخه‌ی هیجان (هایپ سایکل) که توسط گارتنر ابداع شده، الگویی است که نشان می‌دهد چگونه فناوری‌ها یا ایده‌های جدید از مراحل هیجان اولیه، انتظارات غیرواقعی، ناامیدی، و سپس پذیرش عملی می‌گذرند. مثلن وقتی «برنامه‌نویسی شی‌گرا» معرفی شد، خیلی‌ها فکر می‌کردند این روش پاسخ همه مشکلات برنامه‌نویسی است (اوج هیجان). اما بعد، متوجه شدند که برای هر پروژه‌ای مناسب نیست (ناامیدی). با گذشت زمان، برنامه‌نویسان یاد گرفتند از آن در جاهایی که واقعاً مفید است استفاده کنند (پذیرش عملی). این یک چرخه‌ی هیجان است که باید با احتیاط به آن نگاه کرد.
گزیده:
ندارد.
دیدگاهتان را بنویسید