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

بخشی که من در آن کار می کردم، مرکز فناوری اطلاعات دانشکده برق بود وعملا در بخش پشتیبانی فنی دانشکده مشغول بودم.

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

دلیل این مساله چند جنبه دارد:

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

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