تصویری از اعماق فضا

عکس بالا را به طور اتفاقی در ویکی پدیا دیدم.

فضاپیمای Voyager 2 این تصویر را در سال ۱۹۷۹ ثبت کرده است. نزدیک به ۳۷ سال پیش. چند لحظه به تصویر خیره ماندم. مشتری ۶۲۸,۷۳۰,۰۰۰ کیلومتر با زمین فاصله دارد. این تصویر را فضاپیمای Voyager 2 از قمر مشتری به نام IO ثبت کرده. تصور این که ساخته دست بشر تصویری از ۶۰۰ میلیون کیلومتر آن طرف تر ارسال کرده است هنوز نفسم را در سینه حبس می کند. مانند آن زمانی که تمام فکر و ذکرم سیارات منظومه شمسی بود!

سعی کنید تخیل خود را به کار وا دارید. خود را جای Voyager بگذارید. اگر آنجا بودید و با چشم خود شاهد این صحنه بودید، چه دنیایی را نظاره می کردید؟

لحظه ای به این فکر کردم که در کودکی و نوجوانی چقدر به فضا علاقه داشتم. دفترچه ای که خصوصیات تمام سیارات منظومه شمسی را در آن لیست کرده بودم را هنوز دارم!!

مهارت های غیر فنی یک برنامه نویس

به عنوان برنامه نویس همه ما به دنبال بهتر شدن در زمینه فنی هستیم. همه ما تصور می کنیم دانش فنی بالاتر مساوی است با درآمد بیشتر.

تا به حال افرادی را دیده اید که علارغم دانش فنی پایین تر از شما، موقعیت و پست بالاتری دارند؟ البته ممکن است خیلی از این افراد ارتباط هایی داشته باشند که شما ندارید! ولی در اصل قضیه به این اندازه سیاه نیست.

در حالت کلی موقعیت و درآمد بیشتر در برنامه نویسی الزاما از دانش فنی ناشی نمی شود. تقریبا در همه رشته های مهندسی علاوه بر دانش فنی که لازمه کار است، نیاز است فرد مهارت هایی داشته باشد. نمونه ای از این مهارت ها به صورت زیر می باشند:

۱) شرکت در جلسات و مدیریت آنها

شرکت در جلسات در اکثر مشاغل اجتناب ناپذیر است. اگر در خود مهارت موثر بودن در جلسا ت و صحبت کردن و به نتیجه رسیدن را نمی بینید حتما روی این موضوع کار کنید. چون به ناچار نیاز خواهد بود برای پیشرفت، در جلسات متعددی حضور پیدا کنید. مدیریت جلسه به این معنا است که در زمان معین به نتیجه ای هر چند کوچک برسید. تصمیمی اتخاذ کنید. موارد را بررسی کنید و …

۲) برقراری ارتباط

به دلیل زندگی در یک جامعه انسانی، هر فردی نیاز دارد که ارتباطات موثری با افراد پیرامون خود برقرار کند. در شغل برنامه نویسی از آن جایی که هدف اصلی معمولا رفع مشکل یک فرد یا سازمان است. و اصولا کار تیمی بالای را میطلبد، نیاز به برقراری ارتباطات موثر بیشتر احساس می شود. درست است که geek بودن در برنامه نویس ها صفت خوبی به نظر می رسد. ولی geek منزوی در دنیای امروز راه به جایی نخواهد برد!

۳) قابلیت تحلیل انتظار مشتریان

این که شما خودتان را به جای کاربران نهایی یک سیستم بگذارید مهارتی است که به راحتی در افراد یافت نمی شود. به طور مثال کاربران یک وبسایت فروش لباس چه انتظاراتی می توانند داشته باشند. یا کاربران یک نرم افزار مالی چه انتظاراتی می توانند داشته باشند. البته لازم نیست معجزه کنید. قاعدتا باید از اطلاعات دنیای پیرامون خود مانند تحلیل گران سیستم، جلسات مشتری، مشاهده میدانی و … کمک بگیرید تا به نتایجی دست یابید.

۴) کار تیمی فوق العاده

برنامه نویسی و تولید نرم افزار به شدت کار تیمی ای است. شما نمی توانید به صورت انفرادی پیشرفت کنید. پیشرفت شما در گرو مهارت شما در انجام تیمی کارهاست.

۵) آموزش

به عنوان برنامه نویس شاید به ذهنتان خطور کرده باشد که با یادگیری تخصص یا مهارت شما توسط دیگران موقعیت شغلی خود را از دست خواهید داد. یا این که باید همیشه فوت کوزه گری را نزد خود نگه دارید. ولی تجربه به طور کلی موضوعی بر عکس این را نشان داده است. یکی از فاکتورهای اصلی در پیشرفت کسب اعتماد کارفرمایان است. شاید قراردادها اجرای بخشی از قوانین حاکم بر بازار کار را تضمین کنند. ولی کلید اصلی در پیشرفت، اعتماد است. اعتماد از راه های متفاوتی ایجاد می شود. و یکی از این راهها آموزش است. آموزش به همکاران در چهارچوب های مختلف بسیار در این زمینه کمک کننده خواهد بود. آموزش همچنین باعث خواهد شد مقبولیت بیشتری در بین همکاران داشته باشید. این مقبولیت در آینده به عنوان مدیر نقش مهمی در موفقیت شما ایفا خواهد کرد.

موارد فوق چند مورد از مهارت هایی بود که می توان برای یک برنامه نویس در نظر گرفت. موارد پیشنهادی دیگری را در نظر دارید؟

سلام docs.com

تا به حال به این موضوع فکر کرده اید که جایی در وب داشته باشید برای به اشتراک گذاشتن فایل ها  و اسنادی که مورد نیاز همکاران یا دیگر افراد باشد؟

چند روز پیش با docs.com آشنا شدم. وبسایتی از طرف مایکروسافت که در مجموعه office online وجود دارد. دقیقا برای همین کار!

برای اشتراک گذاری فایل ها معمولا اولین انتخاب افراد وبلاگ یا وبسایت هست. ولی اکثر افراد به امکانات نوشتاری یک وبسایت نیازی ندارند و بیشتر در جهت اشتراک گذاری فایل ها اقدام به این کار میکنند.

در این سرویس امکان embed کردن اسناد افیس و فایل های sway*  در دیگر وبسایت ها نیز وجود دارد. همچنین این قابلیت در سرویس وجود دارد که در کنار آپلود فایل ها از دستگاه شخصی از فایلهای موجود در onedrive مایکروسافت جهت اشتراک استفاده کنید. در کنار تمام امکاناتی که این سرویس در اختیار کاربران می گذارد امکان ایجاد صفحه اختصاصی شخصی نیز خیلی جذاب است.

هنگام اشتراک یک فایل می توانید سطوح دسترسی متفاوتی را برای آن در نظر بگیرید. همچنین امکان انتخاب یک License  نیز وجود دارد.

*Sway سرویس وب ایجاد نوع خاصی از presentation از طرف مایکروسافت است.

 

چرا برنامه نویس ها چند شغله هستند؟

این موضوع را که بیشتر برنامه نویس ها چند شغله هستند نمی توان انکار کرد. در واقع این موضوع که اکثر ایرانی ها چند شغله هستند را نمی شود انکار کرد. حتی اگر کسی بتواند با شگردهای خلاقانه این موضوع را پنهان کند.

شاید بعضی مواردی که در این مطلب مطالعه خواهید کرد در مورد مشاغل غیر از برنامه نویسی نیز صحت داشته باشد.

چرا برنامه نویس ها چند شغله می شوند؟

۱) عدم امنیت شغلی

این مطلب را بارها و بارها از کارفرمایان مختلف شنیده ام که نیاز به نیرویی دارند که شش دانگ حواسش به کار شرکت باشد. درگیر کارهای حاشیه ای نشود. به طور خلاصه کاملا در اختیار مجموعه باشد. ولی در اکثر این کارفرمایان تعهدی که مورد نیاز این امر است را ندیده ام. تعهد کارمند و کارفرما امری دو جانبه است. شما نمی توانید انتظار داشته باشید کسی بدون امنیت شغلی مناسب تماما در اختیار شما باشد. به طور مثال اگر تزلزل پروژه ای را که در آن فعالیت می کند مشاهده کرد و به این نتیجه رسید که عدم موفقیت پروژه منجر به قطع همکاری خواهد شد قطعا به دنبال گزینه های جایگزین خواهد گشت.

۲) پرداختی نامناسب

همه ما می دانیم که زندگی مخارج فراوانی دارد. اعم از پیشبینی شده و پیشبینی نشده. هر انسانی به مقدار مشخصی خواهد توانست قناعت پیشه کند و زندگی خود را متناسب با درامد خود مدیریت کند. ولی بین مخارج و درامد فاصله زیادی ایجاد می شود به ناچار از هر طریقی که شده فرد باید این فاصله را کم کند. (نا گفته نماند که پرداختی نا مناسب الزاما پرداختی کم نیست، پرداخت حقوق نا مرتب نیز می تواند مصداقی از پرداختی نامناسب باشد) هر فردی راه حل خاص خودش را خواهد داشت و یکی از راه حل های برنامه نویس ها مشارکت در کارهای پروژه ای و پاره وقت است.

۳) یادگیری

برنامه نویسی شغل پویایی است. نیاز به یادگیری مستمر یکی از نیازهای اصلی هر برنامه نویسی است. وقتی در شرکت یا مجموعه ای این نیاز به نحوی برطرف نشود برنامه نویس ها معمولا مشغول پروژه های جانبی خواهند شد تا این نقص را جبران کنند.

۴) کسب تجربه

وقتی شما با مشکل فنی یا غیر فنی ای بارها و بارها بر می خورید طبیعتا مهارت حل مسائل مرتبط در شما ایجاد خواهد شد. این موضوع با دانش فنی فرق اساسی دارد.

۵) پیشرفت

به طور مثال شما قادر به انجام معماری نرم افزار هستید. بین شما و کسی که کار معماری نرم افزار انجام داده تفاوت وجود دارد. خیلی وقتها امکان این که کسی کاری بالاتر از جایگاه فعلی خود را انجام دهد در سازمان فعلی او وجود ندارد. به این دلیل اقدام به شرکت در پروژه ها یا انجام کارهای پاره وقت می کند.

مواردی ذکر شده برگرفته از تجربه شخصی بنده و مشاهده دوستان و همکاران خودم در طی چند سال اخیر است. قطعا موارد بالا همه دلایلی نیستند که ممکن است فرد را به چند شغلی هدایت کند.

موارد ذکر شده از نظر اهمیت مرتب شده بودند. به طوری که موارد بالاتر از نظر بنده اهمیت بیشتری داشته اند.

پرکاری و بدهی فنی

blog.castsoftware.com
technical-debt

چه برنامه نویسی یک برنامه نویس مفید است؟ ممکن است برنامه نویس های پرکاری را دیده باشید، که همیشه در حال جنب و جوش اند. همیشه در حال فعالیت. اما چه مقدار از این فعالیت مفید است؟ یکی از فاکتورهای مهم مفید بودن یک فعالیت برنامه نویسی مقدار بدهی فنی ای است که به جای می گذارد. در واقع هر چه مقدار بدهی فنی برنامه نویس بیشتر باشد، کار او کمتر مفید واقع خواهد شد.

بدهی فنی نمونه ها و مصادیق فراوانی دارد. در زیر چند مورد از انها را مشاهده می کنید.

  • کلاسهای (class) بسیار بزرگ با مسئولیت های فراوان. (بیشتر سیستم توسط چند کلاس بزرگ مدیریت می شوند)
  • یک stored procedure برای بسیاری از کارها.
  • Copy paste کردن کد! (فاجعه)
  • عدم استفاده مجدد مناسب از کلاسها
  • عدم refactor کردن کدها جهدت استفاده مجدد و نوشتن تکه کدهای جدید برای حل مسائل جدید
  • عدم بروزرسانی سیستم های مشتریان و نیاز به نگهداری سیستم های قدیمی در مشتریان خاص

وقتی بدهی فنی در فرایند انجام کاری بوجود می آید چه اتفاقی می افتد؟ به احتمال زیاد بدهی های فنی جمع شده از فعالیت های قبل روی هم انباشته شده و به زودی حتی فرصتی برای ارائه امکانات جدید باقی نخواهد ماند. با تنگ شدن زمان، فعالیت ها و امکانات در حال توسعه نیز با بی سلیقگی انجام شده و بدهی های بیشتری را بر جای خواهند گذاشت. این دور باطلی است که در نهایت منجر به شکست پروژه نرم افزاری خواهد شد.

آخرین نفر مسئول است

مسئله مهمتر و خطرناکتر در مورد بدهی فنی این است که پرداخت بدهی ها الزما به عهده کسی نخواهد بود که آنها را به بار آورده است. ممکن است نفرات قبلی تیم خرابکاری هایی کرده باشند که شما به عنوان آخرین کسی که روی پروژه کار کرده اید مجبور به پاسخگویی در قبال آنها باشید. هیچ چیز دردناکتر از این نخواهد بود که جوابگوی اشتباهاتی باشید که در ایجاد آنها نقشی نداشته اید!

پرکار هستید؟ پس دقت کنید

اگر برنامه نویس پرکاری هستید حتما به این مورد توجه کنید که تنگی وقت و پرکاری منجر به ایجاد بدهی های فراوان برای تیم شما نشوند. به طور خاص وقتی در حال ارائه تخمین زمانی برای کارهای سفارش داده شده هستید موضوع رفع بدهی های فنی را در نظر بگیرید. نیازی نیست که مدیریت پروژه یا مدیریت محصول در جریان ریز کارهای انجام شده در فعالیت های مختلف باشند.

مطالب مرتبط:

آیا سابقه کاری در درآمد برنامه نویسی نقش مهمی دارد؟

هفت تله فکری در راه اندازی یک استارتاپ

استارتاپ

همه در حال جنب و جوش اند. رشد روز افزون استارتاپ ها غیر قابل انکار است. جوی که در جامعه ایجاد شده بسیار هیجان انگیز است. احتمالا شما هم دوست دارید استارتاپی داشته باشید.

در هنگان بررسی و تحقیق اولیه در مورد کسب و کار جدید ممکن است در تله هایی گرفتار شویم.  در ادامه به بررسی چند نمونه از این مشکلات خواهم پرداخت. در ابتدا بهتر است تعریفی از مفهوم استارتاپ ارائه دهم.

یکی از دقیق ترین تعاریف یک استارتاپ این است:

استارتاپ یک سازمان موقت است که با هدف یافتن یک مدل کسب و کار تکرارپذیر و مقیاس پذیر بوجود آمده است. (از خوشفکری)

البته ناگفته نماند بعضی از موارد پیش رو با توجه کردن به مفهوم و تعریف اصلی یک استارتاپ به خودی خود حل شوند.

۱) پولدار می شوم

با توجه به تعریف بالا به این نتیجه می توان رسید که احتمالا به این زودی ها پولدار نخواهید شد. ایجاد یک استارتاپ تنها اول راه است. ممکن است سالها وقت صرف کنید که به نقطه بازدهی برسید. حتی ممکن است در این بازه زمانی سرمایه اولیه شخصی خود را نیز هزینه کنید. اگر در این بازه تحت حمایت سازمان یا فردی قرار بگیرید یکی از خوشبخت ها خواهید بود.

۲) رئیس خواهم شد

ممکن است بعضی از افرادی که تصمیم به ایجاد یک استارتاپ می کنند، با سودای مدیر شدن و رئیس بودن و به اصطلاح صاحب کار بودن این تصمیم را گرفته باشند. توجه داشته باشید که مدیریت هدف نیست. با این که این نوع تفکر را خیلی کم دیده ام ولی در فرهنگ ما شاید همچین دیدگاهی نسبت به ایجاد کسب و کار جدید وجود داشته باشد. افرادی که با این هدف قدم به این مسیر می گذارند باید در نظر داشته باشند که ممکن است تا مدت ها پس از اجرایی شدن استارتاپ مورد نظرشان هم کسی در سازمان وجود نداشته باشد که نیاز به ریاست وجود داشته باشد! اساسا ذات استارتاپ رهبری را می طلبد تا ریاست. رهبری خصلت کلیدی است که اکثر کارآفرینان آن را دارا می باشند.

۳) با استفاده از ارتباطات فعلی خودم موفق خواهم شد

متاسفانه دو مفهوم رانت خواری و استارتاپ در نظر خیلی از افراد یکسان تلقی می شوند. البته مفهوم رانت خواری بسیار وسیع است و زمینه های زیادی را پوشش می دهد. اگر تعریف یک استارتاپ را در مدل بالا مورد توجه قرار دهید احتمالا به تفاوت های دو مفهوم خواهید رسید. فردی که با استفاده از وسایل مختلف به طور مثال به صورت نسبتا انحصاری در بازار نرم افزار فعالیت می کند قاعدتا استارتاپ راه اندازی نکرده است. یا فردی که با توجه به روابط خاص توانایی انعقاد قرارداد یا اجرای مواردی را دارد نیز همین گونه خواهد بود. حتی در نظر من این گونه افراد کار آفرین نیز نیستند. مدل توسعه یک استارتاپ با مدل توسعه سازمان هایی از این دست بسیار متفاوت است.  اگر پا به صنعتی می گذارید که رقبای فعال در آن از روش های نا سالم در حال فعالیت هستند با روش های مدیریت استارت اپی احتمال شکست شما بسیار زیاد است!

ادامه خواندن هفت تله فکری در راه اندازی یک استارتاپ

درسی از یک نرم افزار ۱۵ دقیقه ای

یکی از دوستانم (که برنامه نویس نیز نبود) آرشیو موسیقی مفصلی داشت. یک روز این موضوع برایش پیش آمد که بتواند فایل های صوتی تکراری موجود در هارد دیسکش را یافته و تصمیمی راجع به آنها بگیرد. شروع کرده بود به این که لیست فایل ها را بررسی کند و به صورت دستی فایل های تکراری را پاک کند. بعد از مدت کوتاهی از من پرسید: فرید امکان این وجود دارد برنامه ای بنویسی که فایل های تکراری را پیدا کرده و لیستی از انها به من نمایش دهد؟ چون تعداد فایلهای موجود در آرشیو من خیلی زیاد است.

نرم افزار 15 دقیقه ای

به او گفتم کار سختی نیست. امتحان میکنم. بعد از آن در حدود ۱۵ دقیقه (زمان کار را با toggl.com ثبت کردم) توانستم برنامه ساده ای بنویسم که در درایو خاصی فایل های صوتی تکراری را پیدا کرده و در یک فایل متنی گزارشی به کاربر ارائه دهد.

دوستم از نرم افزار استفاده کرد و با توجه به این که تعداد فایها صوتی موجود در آرشیو او بسیار زیاد بود، این برنامه کمک زیادی در یافتن فایل های تکراری بر اساس نام، به او کرد.

بعد از دیدن عکس العمل دوستم در مورد نرم افزار خیلی ساده ای که تهیه شده بود به این نکته بیشتر فکر کردم که موفقیت یک پروژه نرم افزاری (چه کوچک چه بزرگ) به این که چه مقدار کار فنی عجیب و غریبی برای آن انجام شده است وابسته نیست. یا به این که چه فناوری هایی در آن استفاده شده است.

عامل اصلی در موفقیت یک پروژه نرم افزاری استفاده درست از فناوری های موجود جهت رفع نیازهای اصلی کاربر هدف است.

در صورتی که نیاز اصلی کاربر رفع نشده باشد. واقعا مهم نیست که چه فناوری هایی و چه معماری های مرتبط و منظمی در نرم افزار استفاده شده است.

این درسی بود که من گرفتم از نیاز ساده یک دوست.

نرم افزارهای موبایل hybrid سازمانی (Enterprise)

Apache_Cordova1

اگر با اکوسیستم نرم افزارهای سازمانی (Enterprise) آشنا باشید، حتما این موضوع را متوجه شده اید که روند نیاز به نرم افزارهای موبایل در زمینه های سازمانی نسبت به چند سال گذشته رشد زیادی داشته است. اکثر نرم افزارهای سازمانی محصولی (off the shelf) یا اختصاصی دارای یک یا چند نرم افزار موبایل جهت سهولت در استفاده از نرم افزار اصلی و پایه هستند.

با توجه به این رشد روز افزون بدیهی است که تمرکز زیادی از سوی دنیای فناوری روی این زمینه جلب شود. همان طور که مدت هاست تولید نرم افزارهای cross platform آرزوی تولید کنندگان نرم افزار است، با ظهور دستگاههای موبایل در این صنعت این گونه به نظر می رسد که همین نیاز به cross platform بودن در نرم افزارهای موبایل نیز روز به روز افزایش یابد.

software-home

به طور کلی روش های نوشتن نرم افزارهای موبایل به سه روش تقسیم بندی می شوند.

  • نرم افزارهای native
  • نرم افزارهای cross platform با استفاده از فناوری های xamarin و …
  • نرم افزارهای موبایل با استفاده از webview در یک برنامه native یا همان نرم افزارهای hybrid

احتمالا به اندازه کافی با تولید نرم افزارهای موبایل با استفاده از فناوری های native آشنا هستید. به طور مثال نرم افزارهای موبایل اندرویدی با استفاده از زبان جاوا تولید می شوند و نرم افزارهای iOS ای نیز با استفاده از swift یا objective c.

نوع دیگری از برنامه نویسی موبایل روش hybrid است که فناوری های مورد استفاده در این روش html و جاواسکریپت هستند. در این روش معمولا برنامه شامل یک webview خواهد بود که با طول و عرض صد در صد در برنامه بارگزاری شده است. و هر کدی که برنامه نویس تولید کند در آن webview اجرا خواهد شد.

ادامه خواندن نرم افزارهای موبایل hybrid سازمانی (Enterprise)

Greenfield development VS Brownfield development

code

به دنبال ترجمه فارسی این دو اصطلاح نیستم. مدتی پیش مقاله ای در مجله MSDN مطالعه می کردم که به اصطلاح Brownfield development مواجه شدم. به طور ساده تعریف این دو عبارت به صورت زیر هستند

Greenfield development: زمانی فعالیت های برنامه نویسی شما در این دسته قرار می گیرند که شما پروژه ای را از صفر شروع کرده باشید. پروژه ای که هیچ کدی از قبل در آن وجود نداشته باشد. یا پروژه ای که به صورت دوباره نویسی کامل انجام خواهد شد.

Brownfield development: زمانی که شما روی یک پروژه موجود کار می کنید و با تغییراتی که در آن ایجاد می کنید نسخه نرم افزار را هم افزایش می دهید، فعالیت های شما در این دسته قرار می گیرند.

با مطالعه و بررسی دسته بندی های بالا  متوجه خواهید شد که واقعا تمام فعالیت های برنامه نویسی هر برنامه نویس در یکی از دسته های بالا قرار می گیرد.

خصوصیات این دو نوع برنامه نویسی چیست؟ چه تخصص هایی برای انجام هر چه بهتر هر یکی از این انواع نیاز است؟

رفع ابهام

اولین موردی که خیلی مهم است در این جا مطرح کنم این موضوع است که هیچ یکی از این نوع کارهای نشان دهنده بلوغ یا پیشرفت یک برنامه نویس نیست. شاید این موضوع در ذهن بیاید که به طور مثال وقتی برنامه نویسی از یک حدی پیشرفت کرد دیگر روی پروژه های جدید کار خواهد کرد و کار بر روی پروژه های فعلی وظیفه برنامه نویسان کم تجربه و کم سواد است.

Brownfield development

با این که در بخش رفع ابهام این مورد را مطرح کردم که کار کردن روی هر یک از این انواع پروژه ها نشان دهنده پیشرفت یا عدم پیشرفت یک برنامه نویس نیست. ولی در صورتی که برنامه نویس کم تجربه ای هستید پیشنهاد اکید می کنم برای انجام چنین پروژه های داوطلب شوید. به چند دلیل

  • خواندن کد های نوشته شده توسط دیگران دانش و تجربه شما را افزایش خواهد داد. (همان طور که در اینجا مطرح کرده ام)
  • برنامه نویسی روی کارهای دیگران نیازمند این است که شما قوه یادگیری و انطباق سریعی داشته باشید و این خصوصیت شما تقویت خواهد شد

البته ناگفته نماند که کار روی کدهای موجود از نظر یادگیری وقتی بیشترین بازده را دارد که برنامه نویس های قبل از شما از نظر سواد و تجربه در سطح بالاتری از شما باشند.

نکته مهم دیگری که نیاز است به آن توجه کنید این است که وقتی پروژه ای که از قبل وجود داشته را توسعه می دهید، خیلی انتظار کار روی پروژه ای با تکنولوژی روز دنیا را نداشته باشید.

Greenfield development

این که به شما بگویند قرار است روی پروژه ای که در حال تولید است، کار کنید. و قرار است خالق مجموعه نرم افزارهایی باشید. احتمالا از هیجان دست از پا نخواهید شناخت. چون هر برنامه نویسی عشق ساختن نرم افزار جدیدی را در ذهن دارد. ولی آن روی سکه را هم ببینید. نرخ شکست پروژه های نرم افزاری در کشور ما بالاست، وقتی هیجان ساختن نرم افزار جدیدی وجودتان را فرا می گیرد به این موضوع هم فکر کنید!

برای نوشتن نرم افزارهایی که از صفر شروع شده اند به نظر من باید مدت های زیادی روی پروژه های دیگر کار کرده باشید. کدهای بسیار زیادی دیده باشید. در تیم های متعدد کار کرده باشید. خلاصه این که به نظر من باید تجربه قابل قبولی در برنامه نویسی و معماری داشته باشید. منظورم فقط سواد نیست. الگوهای طراحی را ممکن است خیلی از برنامه نویس ها از نظر تئوری آموخته باشند. ولی هنر استفاده درست و به جا از هریک از آنها نیازمند تجربه کار در پروژه های موفق و کاربردی است.

برنامه نویسی در پروژه ای که از ابتدا شروع شده است لذت های خاص خود را دارد ولی می تواند معایبی نیز داشته باشد.

  • عدم یادگیری مدیریت زمان: به این معنی که شما همیشه درگیر ایجاد امکانات جدیدی هستید و همیشه حق خود می دانید که زمان در نظر گرفته شده برای کارهایتان بیشتر از حد انتظار شود. چون بالاخره کار جدید است و قبلا انجام نشده است.
  • سندروم ایجاد همه چیز از نو: اگر شما به این سندروم مبتلا باشید اصلا علاقه ای به استفاده مجدد کدهای قبلی نخواهید داشت. به طور مثال اگر یک سیستم مدیریت دسترسی قبلا در سیستم های شرکت کار می کرده، شما تصمیم می گیرید از آن استفاده نکنید و معادل جدیدتر و به روزتر آن را ایجاد کنید. البته بعضی زمان ها امکان استفاده از کد های قدیمی وجود ندارد چون صورت مسئله دوباره نویسی همان ابزارها است.
  • تبدیل شدن به دانشمند برنامه نویسی: این مورد با مورد یک و دو بسیار هم راستا است. زمانی که شما علاقه خیلی زیاد به یادگیری الگوهای معماری و طراحی دارید و نوشتن نرم افزار بهانه ای می شود برای تمرین کردن آن الگوها، نه رفع نیازهای کاربران (که حقوق شما را تامین می کنند!)

هدف اصلی این نوشتار آشنایی با دو اصطلاح ذکر شده بود. در صورتی که مواردی خارج از موارد ذکر شده به نظر خواننده می رسد، خوشحال خواهم شد که آنها را مطالعه کنم.

آیا سابقه کاری در درآمد برنامه نویسی نقش مهمی دارد؟

title

در واقع بهتر است سوال را این گونه مطرح کنم. آیا با افزایش سال های سابقه کاری الزاما درآمد برنامه نویس افزایش خواهد یافت؟

جواب ساده به این سوال خیر است.

در طول دوران کاری برنامه نویس هایی را دیده ام که با تعداد سال های سابقه کاری بالا درآمد هایی به مراتب پایین به نسبت آن سابقه داشته اند.

دلیل این امر چیست؟ چرا در شغل برنامه نویسی، همانند خیلی از مشاغل دیگر با افزایش تجربه یا سابقه کاری الزاما درآمد فرد افزایش نمی یابد؟

یکی از دلایلی که به نظر من می رسد این است که در برنامه نویسی میزان درآمد فرد رابطه مستقیم با خروجی فرد دارد. هر چقدر فعالیت های فرد برای سازمان ارزشمند تر باشد درآمد او نیز به تناسب آن می تواند بالاتر باشد.

پس یک برنامه نویس می تواند سابقه کاری زیادی داشته باشد. ولی در تمام این مدت کار مهم و با ارزشی انجام نداده باشد.

مفید بودن فعالیت های برنامه نویس را تنها حجم کارهایی که تحویل می دهد مشخص نمی کند. این که چه مقدار از کد های نوشته شده توسط برنامه نویس خطا زا هستند، یا چه مقدار کد ها و کامپوننت های تولیدی او قابلیت استفاده مجدد دارند و به طور کلی چه مقدار بدهی فنی کمتر داشته باشد، نقش مهمی در ارزش گذاری کارها و فعالیت های یک برنامه نویس ایفا می کند.

متاسفانه اکثر شرکت هایی که دیده ام به موضوع بدهی فنی اصلا توجهی ندارند. مثلا در تمام سیستم های نرم افزاری خود یک بار سیستم مدیریت دسترسی را از ابتدا طراحی و پیاده سازی کرده اند. با این روش شاید در نگاه اول خروجی برنامه نویس ها بالا به نظر بیاید. ولی با مقداری توجه و دقت به فعالیت های روزانه آن ها می توان متوجه شد که افراد در حال انجام کارهای تکراری و پشت سر هم هستند.

چگونه می توان بدهی فنی را در کارها کاهش داد؟ اینجاست که تفاوت شغل برنامه نویسی با مشاغل دیگر مشخص می شود. برای کاهش بدهی فنی در کارها یک راه بیشتر در پیش رو نیست. مطالعه. هر روز باید مقداری به دانش برنامه نویسی یک فرد افزوده شود. اگر این فرایند متوقف شود در واقع مرگ یک برنامه نویس خوب اتفاق افتاده است.

البته نکته مهم که دوست دارم در این جا ذکر کنم این است که منظور از دانش، دانش برنامه نویسی است نه یادگیری کتابخانه های مختلف. دانش کد نویسی خوب، معماری نرم افزار، شی گرایی، اطلاعات پایه زبان های برنامه نویسی و …

با افزایش دانش برنامه نویسی فعال در برنامه نویس ها، می توان امیدوار بود که بدهی فنی موجود در کارهای آنها هر روز کاهش یابد.

ولی همین تعداد سال های زیاد فعالیت در حوزه برنامه نویسی در چه مواردی به کمک یک برنامه نویس خواهد آمد؟

معمولا وقتی پای مشاغل مدیریتی و مشاوره مدیریتی به میان می آید، این که برنامه نویس چند سال در حوزه تولید نرم افزار فعالیت داشته مهم می شود. ولی باز هم دقت داشته باشید که شاید این مورد برای گرفتن شغل مدیریتی لازم باشد ولی کافی نیست. در نهایت اندوخته های یک برنامه نویس است که میزان درامد و پیشرفت او را تضمین می کند.


بروزرسانی ۱۳۹۴/۱۰/۱:

یک مورد مهم در کسب تجربه این است: زمانی که کارهای زیادی انجام می دهید. بدیهی خواهد بود که با مشکلات و مسائل گوناگونی روبرو خواهید شد. این سبب می شود که به نسبت همکارانی که کم کارتر هستند در حل مسائل تکراری کارایی بالاتری داشته باشید. و باز بدیهی خواهد بود که این موضوع در درآمد شما نیز تاثیر بگذارد. ولی باز نمی توان گفت کسی که سالها سابقه کاری دارد الزاما پرکار بوده. و کارهای مفیدی انجام داده است.