Table of Contents
গুগলে যোগ দেওয়ার সময় আমার ধারণা ছিল, চাকরিটা কেবল ভালো কোড লেখারই নামান্তর। আমি অবশ্য আংশিক ঠিক ছিলাম। কিন্তু যত দিন গড়িয়েছে, ততই বুঝেছি—যে ইঞ্জিনিয়াররা সফল হন, তারা যে সবসময় সেরা প্রোগ্রামার, তা নয়। বরং তারা কোডিংয়ের বাইরের জগতটা বুঝতে পেরেছেন: মানুষ, অফিস পলিটিক্স, দলবদ্ধ হয়ে কাজ করা এবং অনিশ্চয়তা।
এই শিক্ষাগুলো ক্যারিয়ারের শুরুতে জানা থাকলে আমার জন্য খুব ভালো হতো। কিছু বিষয় জানা থাকলে হয়তো মাসের পর মাস হতাশা এড়ানো যেত। আবার কিছু বিষয় বুঝতে আমার বছর পার হয়ে গেছে। এর কোনোটিই নির্দিষ্ট প্রযুক্তি নিয়ে নয়—প্রযুক্তি খুব দ্রুত বদলে যায়, তাই সেসব দীর্ঘমেয়াদে খুব একটা গুরুত্বপূর্ণ নয়। এগুলো হলো সেই ধরণের প্যাটার্ন বা ধাঁচ, যা প্রতিটি প্রকল্পে এবং প্রতিটি দলে বারবার ফিরে আসে।
আমি এগুলো শেয়ার করছি, কারণ যে ইঞ্জিনিয়াররা আমার জন্য একই কাজ করেছিলেন, তাদের কাছে আমি ঋণী। এটি আমার সেই ঋণ শোধ করারই একটি ক্ষুদ্র প্রচেষ্টা।
১. সেরা ইঞ্জিনিয়াররা ব্যবহারকারীর সমস্যা সমাধানেই সবচেয়ে বেশি মনোযোগী
কোনো প্রযুক্তির প্রেমে পড়ে সেটি কোথায় ব্যবহার করা যায়, তা খোঁজা বেশ আকর্ষণীয় ব্যাপার। আমিও এমনটা করেছি, সবাই করে। কিন্তু যারা সবচেয়ে বেশি ভ্যালু বা মূল্য তৈরি করেন, তারা হাঁটেন বিপরীত পথে। তারা ব্যবহারকারীর সমস্যা গভীরভাবে বোঝার চেষ্টায় মগ্ন থাকেন এবং সেই বোঝাপড়া থেকেই সমাধান বের করে আনেন।
ব্যবহারকারীর প্রতি এই মনোযোগের মানে হলো—সাপোর্ট টিকিটের পেছনে সময় দেওয়া, ব্যবহারকারীর সাথে কথা বলা, তাদের ভোগান্তিগুলো দেখা এবং সমস্যার মূলে না পৌঁছানো পর্যন্ত “কেন” জিজ্ঞেস করে যাওয়া। যে ইঞ্জিনিয়ার সত্যিকার অর্থে সমস্যাটা বোঝেন, তিনি প্রায়ই দেখেন যে সবচেয়ে জাঁকজমকপূর্ণ সমাধানের চেয়ে সহজ সমাধানটিই বেশি কার্যকর।
অন্যদিকে, যে ইঞ্জিনিয়ার সমাধান দিয়ে কাজ শুরু করেন, তিনি নিজের আইডিয়ার সপক্ষে যুক্তি খুঁজতে গিয়ে অহেতুক জটিলতা তৈরি করেন।
২. নিজে সঠিক হওয়ার চেয়ে সবাইকে নিয়ে সঠিক পথে থাকাই আসল
প্রতিটি কারিগরি তর্কে জিতেও আপনি দিনশেষে প্রকল্পটি হারাতে পারেন। আমি দেখেছি, মেধাবী ইঞ্জিনিয়াররা সবসময় ঘরের সবচেয়ে বুদ্ধিমান ব্যক্তি হয়েও মনে মনে ক্ষোভ জমা করেন। এর মাশুল পরে দিতে হয় “রহস্যময় ইমপ্লিমেন্টেশন সমস্যা” এবং কলিগদের “অদ্ভুত প্রতিরোধ” হিসেবে।
আসল দক্ষতা তর্কে জেতা নয়, বরং আলোচনার মাধ্যমে একমত হওয়া, অন্যদের মতামতের জন্য জায়গা তৈরি করা এবং নিজের সিদ্ধান্তের প্রতিও কিছুটা সন্দেহ পোষণ করা।
“সুদৃঢ় মতামত, তবে নমনীয় অবস্থান” (Strong opinions, weakly held)—এর মানে এই নয় যে আপনার আত্মবিশ্বাসের অভাব আছে। বরং অনিশ্চয়তার মধ্যে নেওয়া সিদ্ধান্তগুলোকে নিজের ইগোর সঙ্গে জড়িয়ে ফেলা উচিত নয়।
৩. কাজের ওপর জোর দিন, শিপ করুন। বাজে পেজ এডিট করা যায়, শূন্য পেজ নয়
নিখুঁত হওয়ার চেষ্টা অনেক সময় আমাদের স্থবির করে দেয়। আমি দেখেছি ইঞ্জিনিয়াররা সপ্তাহের পর সপ্তাহ এমন সব আর্কিটেকচার নিয়ে আলোচনা করছেন, যা তারা কখনো বানাননি। নিখুঁত সমাধান কখনো শুধু চিন্তা থেকে আসে না—এটি বাস্তবতার সংস্পর্শে এসেই জন্ম নেয়। এক্ষেত্রে কৃত্রিম বুদ্ধিমত্তা (AI) অনেকভাবে সাহায্য করতে পারে।
প্রথমে কাজটা দাঁড় করান, তারপর সঠিকভাবে করুন, এরপর আরও ভালো করুন। ব্যবহারকারীর সামনে কাঁচা প্রোটোটাইপটি তুলে ধরুন। ডিজাইন ডকের অগোছালো প্রথম খসড়াটি লিখুন। আপনাকে সামান্য লজ্জিত করবে—এমন MVP (Minimum Viable Product) শিপ করুন। এক সপ্তাহের বাস্তব ফিডব্যাক থেকে আপনি যা শিখবেন, এক মাসের তাত্ত্বিক বিতর্ক থেকেও তা শেখা সম্ভব নয়।
গতিশীলতাই স্বচ্ছতা তৈরি করে। অতিরিক্ত বিশ্লেষণে সময় নষ্ট করলে কোনো লাভ হয় না।
৪. স্পষ্টতাই পরিপক্বতা, চালাকি বা জটিলতা কেবল ঝামেলাই বাড়ায়
চতুর বা ট্রিকি কোড লেখার প্রবণতা ইঞ্জিনিয়ারদের মধ্যে প্রায় সার্বজনীন। এটি নিজের যোগ্যতার প্রমাণ বলে মনে হয়।
কিন্তু সফটওয়্যার ইঞ্জিনিয়ারিং হলো তা-ই, যা ঘটে যখন আপনি এর সঙ্গে সময় এবং অন্য প্রোগ্রামারদের যুক্ত করেন। সেই পরিবেশে, কোডের স্পষ্টতা কোনো পছন্দ-অপছন্দের বিষয় নয়—এটি অপারেশনাল ঝুঁকি কমানোর উপায়।
আপনার কোড হলো একটি কৌশলগত নোট, যা অচেনা কেউ হয়তো রাত ২টার সময় সার্ভার ডাউনের বা আউটেজের সময় ঠিক করার চেষ্টা করবে। তাদের বোঝার সুবিধার্থে কোড লিখুন, নিজের কোডিং সৌন্দর্য দেখানোর জন্য নয়। যে সিনিয়র ইঞ্জিনিয়ারদের আমি সবচেয়ে বেশি সম্মান করি, তারা প্রতিবারই চতুরতার বদলে স্পষ্টতাকে বেছে নিতে শিখেছেন।
৫. অভিনবত্ব এক ধরণের ঋণ, যা আউটেজ ও নিয়োগের ঝামেলার মাধ্যমে শোধ করতে হয়
আপনার প্রযুক্তি নির্বাচনকে একটি সীমিত বাজেটের “ইনোভেশন টোকেন” বা উদ্ভাবনী সুযোগ হিসেবে বিবেচনা করুন। প্রতিবার যখন আপনি পরীক্ষিত নয় এমন কিছু গ্রহণ করবেন, তখন আপনার একটি টোকেন খরচ হবে। আপনার হাতে কিন্তু খুব বেশি টোকেন নেই।
এর মানে এই নয় যে “কখনোই উদ্ভাবন করবেন না।” বরং এর মানে হলো, “শুধু সেখানেই উদ্ভাবন করুন যেখানে আপনাকে বিশেষ কিছু করার জন্য অর্থ দেওয়া হচ্ছে।” বাকি সবকিছুর জন্য সাধারণ বা ‘বিরক্তিকর’ (boring) প্রযুক্তি ব্যবহার করাই শ্রেয়, কারণ এই প্রযুক্তিগুলোর ব্যর্থতার ধরণগুলো আমাদের জানা।
“কাজের জন্য সেরা টুল” প্রায়শই “অনেক কাজের জন্য সবচেয়ে কম খারাপ টুল”—কারণ ভিন্ন ভিন্ন টুলের এক বিশাল চিড়িয়াখানা সামলানো বাস্তবে বেশ কঠিন।
৬. আপনার কোড আপনার হয়ে কথা বলে না, মানুষ বলে
ক্যারিয়ারের শুরুতে আমি বিশ্বাস করতাম, দুর্দান্ত কাজ নিজেই নিজের পরিচয় দেবে। আমি ভুল ছিলাম। কোড নীরবে রিপোজিটরিতে বসে থাকে। আপনার ম্যানেজার মিটিংয়ে আপনার নাম উল্লেখ করবেন কি না, অথবা কোনো সহকর্মী আপনাকে কোনো প্রকল্পের জন্য সুপারিশ করবেন কি না—সেটা সম্পূর্ণ ভিন্ন বিষয়।
বড় সংস্থায়, সিদ্ধান্তগুলো এমন মিটিংয়ে নেওয়া হয় যেখানে আপনাকে আমন্ত্রণ জানানো হয়নি, এমন সব সারসংক্ষেপ বা সামারি পড়ে যা আপনি লেখেননি এবং সিদ্ধান্ত নেন এমন সব লোক যাদের হাতে সময় কম কিন্তু অগ্রাধিকার অনেক। যদি আপনার অনুপস্থিতিতে কেউ আপনার কাজের প্রভাব ব্যাখ্যা করতে না পারেন, তাহলে আপনার প্রভাব থেকেও কোনো লাভ নেই।
এটি কেবল আত্ম-প্রচার নয়। এটি আপনার কাজের মূল্য সবার কাছে—এমনকি আপনার নিজের কাছেও—স্পষ্ট করে তোলার প্রক্রিয়া।
৭. সেরা কোড হলো সেটাই, যা আপনাকে লিখতে হয়নি
ইঞ্জিনিয়ারিং সংস্কৃতিতে আমরা নতুন কিছু সৃষ্টিকে উদযাপন করি। কাউকে কোড মুছে ফেলার জন্য পদোন্নতি দেওয়া হয় না, যদিও মুছে ফেলা প্রায়ই নতুন কিছু যোগ করার চেয়ে বেশি কার্যকর। আপনি যে প্রতিটি লাইন কোড লিখবেন না, সেটি এমন এক লাইন কোড যা আপনাকে কখনো ডিবাগ, মেইনটেইন বা ব্যাখ্যা করতে হবে না।
কোড লেখার আগে এই প্রশ্নটি করুন: “যদি আমরা এই ফিচারটি না বানাই, তাহলে কী হবে?” কখনো কখনো উত্তর হয় “খারাপ কিছু হবে না,” এবং সেটিই আপনার সমাধান।
সমস্যাটা এই নয় যে ইঞ্জিনিয়াররা কোড লিখতে পারেন না বা AI দিয়ে তা করতে পারেন না। সমস্যা হলো, আমরা এত ভালো কোড লিখতে পারি যে, আমাদের আদৌ সেটা লেখা উচিত কি না—তা জিজ্ঞেস করতে ভুলে যাই।
৮. বড় স্কেলে, আপনার বাগেও (Bug) ব্যবহারকারী তৈরি হয়
যথেষ্ট ব্যবহারকারী থাকলে, আপনার সিস্টেমের প্রতিটি আচরণ—তা আপনি প্রতিশ্রুতি দিন বা না দিন—মানুষের অভ্যাসে পরিণত হয়। কেউ হয়তো আপনার API স্ক্র্যাপ করছে, আপনার সিস্টেমের অদ্ভুত আচরণগুলো অটোমেট করছে, কিংবা আপনার বাগগুলোর ওপর ভিত্তি করে কাজ করছে।
এটি ক্যারিয়ারের জন্য একটি বড় শিক্ষা: আপনি সামঞ্জস্য বজায় রাখার কাজকে “রক্ষণাবেক্ষণ” এবং নতুন ফিচারকে “আসল কাজ” হিসেবে আলাদা করতে পারেন না। সামঞ্জস্য বজায় রাখাটাই তখন প্রোডাক্টের অংশ।
আপনার ডিপ্রেকেশন বা পুরনো ফিচার বাদ দেওয়ার প্রক্রিয়াকে মাইগ্রেশন হিসেবে ডিজাইন করুন—যাতে সময়, টুলিং এবং সহানুভূতির ছাপ থাকে। বেশিরভাগ “API ডিজাইন” আসলে ভবিষ্যতে সেই “API অবসরে পাঠানো”র প্রস্তুতি।
৯. বেশিরভাগ “ধীরগতির” দল আসলে সমন্বয়হীন দল
যখন কোনো প্রকল্প দীর্ঘায়িত হয়, তখন সাধারণত ইমপ্লিমেন্টেশন বা বাস্তবায়নকে দোষ দেওয়া হয়: লোকেরা যথেষ্ট পরিশ্রম করছে না, প্রযুক্তি ভুল, অথবা যথেষ্ট ইঞ্জিনিয়ার নেই। সাধারণত এর কোনোটিই আসল সমস্যা নয়।
বড় কোম্পানিপগুলোতে, বিভিন্ন দলগুলো হলো আপনার কনকারেন্সি (concurrency) ইউনিট, কিন্তু দল বাড়লে সমন্বয়ের খরচ জ্যামিতিক হারে বাড়ে। বেশিরভাগ ধীরগতি আসলে অ্যালাইনমেন্ট বা সমন্বয়ের ব্যর্থতা—লোকেরা ভুল জিনিস বানাচ্ছে, অথবা সঠিক জিনিসটাই অসামঞ্জস্যভাবে বানাচ্ছে।
সিনিয়র ইঞ্জিনিয়াররা “দ্রুত কোড লেখা”র চেয়ে দিকনির্দেশনা, ইন্টারফেস এবং অগ্রাধিকার স্পষ্ট করতে বেশি সময় দেন, কারণ আসল বাধার সৃষ্টি হয় সেখানেই।
১০. যা নিয়ন্ত্রণ করতে পারেন সেদিকে মনোযোগ দিন, যা পারেন না তা উপেক্ষা করুন
বড় কোম্পানিতে অসংখ্য বিষয় আপনার নিয়ন্ত্রণের বাইরে থাকে—সাংগঠনিক পরিবর্তন, ম্যানেজমেন্টের সিদ্ধান্ত, বাজারের পরিবর্তন, বা প্রোডাক্টের মোড় ঘুরে যাওয়া। এগুলো নিয়ে ভাবলে উদ্বেগ বাড়ে, কিন্তু কাজের ক্ষমতা বাড়ে না।
যে ইঞ্জিনিয়াররা সুস্থ এবং কার্যকর থাকেন, তারা তাদের প্রভাবের জায়গাটিতেই মনোযোগ দেন। অফিস রি-অর্গানাইজেশন হবে কি না তা আপনি নিয়ন্ত্রণ করতে পারেন না। কিন্তু আপনার কাজের মান, আপনি কীভাবে প্রতিক্রিয়া জানাবেন এবং কী শিখবেন—সেটি আপনি নিয়ন্ত্রণ করতে পারেন। অনিশ্চয়তার মুখোমুখি হলে, সমস্যাগুলো ছোট ছোট টুকরো করুন এবং আপনার পক্ষে করা সম্ভব এমন কাজগুলো চিহ্নিত করুন।
এটি হাল ছেড়ে দেওয়া নয়, বরং কৌশলগত ফোকাস। যা পরিবর্তন করতে পারেন না, সেখানে শক্তি ব্যয় করা মানে—যা পরিবর্তন করতে পারতেন সেখান থেকে শক্তি চুরি করা।
১১. অ্যাবস্ট্রাকশন জটিলতা কমায় না, এটি অন-কলের দিনে ঝামেলা সরায়
প্রতিটি অ্যাবস্ট্রাকশন বা বিমূর্তায়ন হলো একটি বাজি, যেখানে আপনি ধরে নেন যে এর নিচে কী আছে তা আপনার বোঝার দরকার হবে না। কখনো কখনো আপনি এই বাজিতে জিতেন। কিন্তু কিছু না কিছু লিক (leak) হয়ই, এবং যখন হয়, তখন আপনাকে জানতে হবে আপনি কিসের ওপর দাঁড়িয়ে আছেন।
সিনিয়র ইঞ্জিনিয়াররা প্রযুক্তির স্তর বা স্ট্যাক যত উঁচুতেই কাজ করুন না কেন, “লো-লেভেল” বা ভিত্তিগত বিষয়গুলো শিখতে থাকেন। এটি নস্টালজিয়ার জন্য নয়, বরং অ্যাবস্ট্রাকশন ব্যর্থ হওয়ার মুহূর্ত এবং রাত ৩টায় যখন আপনি সিস্টেমের সাথে একা থাকবেন—সেই সময়ের প্রস্তুতির জন্য। আপনার স্ট্যাক ব্যবহার করুন, কিন্তু এর ভেতরের ব্যর্থতার ধরণগুলো সম্পর্কে একটি পরিষ্কার ধারণা রাখুন।
১২. লিখলে চিন্তাভাবনা স্বচ্ছ হয়; শেখার সেরা উপায় হলো তা শেখানো
লেখালেখি আপনাকে স্পষ্ট হতে বাধ্য করে। যখন আমি অন্যদের কাছে কোনো ধারণা ব্যাখ্যা করি—কোনো ডক ফাইলে, আলোচনায়, কোড রিভিউ কমেন্টে, এমনকি AI-এর সাথে চ্যাট করার সময়—তখন আমি আমার নিজের বোঝার ফাঁকগুলো আবিষ্কার করি। অন্যকে কোনো কিছু বোঝানোর চেষ্টা করলে বিষয়টি আমার নিজের কাছেই আরও পরিষ্কার হয়ে ওঠে।
এর মানে এই নয় যে আপনি সার্জারি শেখানোর মাধ্যমে সার্জন হতে পারবেন, কিন্তু সফটওয়্যার ইঞ্জিনিয়ারিংয়ে এই ধারণাটি অনেকাংশেই সত্যি।
এটি কেবল জ্ঞান বিতরণের মহানুভবতা নয়, এটি একটি স্বার্থপর শেখার কৌশলও। যদি আপনি মনে করেন আপনি কিছু বোঝেন, তাহলে সেটি সহজভাবে ব্যাখ্যা করার চেষ্টা করুন। যেখানে আপনি আটকে যাবেন, বুঝবেন সেখানেই আপনার বোঝাপড়া অগভীর। শেখানো হলো নিজের মানসিক মডেল ডিবাগ করার উপায়।
১৩. যে কাজ অন্য কাজকে সম্ভব করে, তা অমূল্য—কিন্তু অদৃশ্য
সংযোগকারী কাজ বা ‘গ্লু ওয়ার্ক’ (Glue work)—যেমন ডকুমেন্টেশন, অনবোর্ডিং, আন্তঃদলীয় সমন্বয়, প্রক্রিয়া উন্নয়ন—অত্যন্ত গুরুত্বপূর্ণ। কিন্তু আপনি যদি এটি নিজের অজান্তে করতে থাকেন, তাহলে এটি আপনার কারিগরি প্রবৃদ্ধি থামিয়ে দিতে পারে এবং আপনাকে হতাশ করে ফেলতে পারে। ফাঁদটি হলো, এটি দৃশ্যমান কোনো প্রভাব হিসেবে না দেখিয়ে কেবল “সাহায্য করা” হিসেবে চালিয়ে যাওয়া।
এজন্য সময় নির্দিষ্ট করুন। রোটেট বা পালাবদল করুন। কাজগুলোকে দৃশ্যমান কিছুতে পরিণত করুন: ডকস, টেমপ্লেট বা অটোমেশন। এবং এটিকে আপনার প্রভাব হিসেবে তুলে ধরুন, নিছক ব্যক্তিগত ভালোমানুষি হিসেবে নয়।
“অমূল্য কিন্তু অদৃশ্য”—ক্যারিয়ারের জন্য এটি একটি বিপজ্জনক সংমিশ্রণ।
১৪. প্রতিটি বিতর্কে জিতলে সম্ভবত আপনি নীরব প্রতিরোধ জমা করছেন
আমি নিজের সবজান্তা ভাবের প্রতি সন্দেহপ্রবণ হয়ে উঠেছি। যখন আমি খুব সহজে তর্কে “জিতি”, তখন সাধারণত কিছু একটা ভুল থাকে। লোকেরা আপনার বিরুদ্ধে তর্ক করা বন্ধ করে দেয় মানে এই নয় যে আপনি তাদের বোঝাতে পেরেছেন; বরং তারা চেষ্টা করা ছেড়ে দিয়েছে—এবং তারা সেই অসম্মতিটি প্রকাশ করবে কাজে কিংবা মিটিংয়ে।
আসল সম্মতি বা অ্যালাইনমেন্ট তৈরি হতে সময় লাগে। আপনাকে অন্যদের দৃষ্টিভঙ্গি বুঝতে হবে, ফিডব্যাক নিতে হবে এবং কখনো কখনো সবার মঙ্গলের জন্য নিজের মত পরিবর্তন করতে হবে।
তর্কে জিতে নিজেকে সঠিক প্রমাণ করার ক্ষণস্থায়ী অনুভূতির চেয়ে, সহযোগীদের নিয়ে দীর্ঘমেয়াদে কিছু তৈরি করা অনেক বেশি মূল্যবান।
১৫. যখন কোনো পরিমাপ বা মেট্রিক লক্ষ্য হয়ে দাঁড়ায়, তখন তা আর কার্যকর থাকে না
ম্যানেজমেন্টের কাছে আপনি যে মেট্রিকই তুলে ধরবেন, একসময় না একসময় সেটা ম্যানিপু্লেট বা ‘গেম’ করা হবে। এটা কেউ খারাপ উদ্দেশ্য নিয়ে করে না, বরং মানুষ যা পরিমাপ করা হয় তার জন্যই নিজেকে প্রস্তুত করে।
আপনি যদি কোডের লাইন ট্র্যাক করেন, আপনি আরও বেশি লাইন পাবেন। যদি কাজের গতি (velocity) ট্র্যাক করেন, আপনি ফুলিয়ে-ফাঁপানো এস্টিমেট পাবেন।
সিনিয়রদের কাজ হলো: প্রতিটি মেট্রিক অনুরোধের জবাবে এক জোড়া মেট্রিক দেওয়া। একটি গতির জন্য হলে, অন্যটি গুণমান বা ঝুঁকির জন্য। এরপর নির্দিষ্ট সংখ্যার পূজা না করে, ট্রেন্ড বা গতিপ্রকৃতি ব্যাখ্যার ওপর জোর দিন। লক্ষ্য হওয়া উচিত অন্তর্দৃষ্টি বা ইনসাইট পাওয়া, নজরদারি করা নয়।
১৬. “আমি জানি না” বলাটা দুর্বলতা নয়, বরং নিরাপত্তা তৈরি করে
যে সিনিয়র ইঞ্জিনিয়াররা বলেন “আমি জানি না”, তারা দুর্বলতা দেখাচ্ছেন না—তারা অন্যদের জন্য সুযোগ তৈরি করছেন। যখন একজন নেতা অনিশ্চয়তা স্বীকার করেন, তখন এটি সংকেত দেয় যে ঘরে অন্যদের জন্যও একই কাজ করা নিরাপদ। এর বিকল্প হলো এমন একটা সংস্কৃতি, যেখানে সবাই ভান করে যে তারা সব বুঝছে এবং সমস্যাগুলো লুকিয়ে রাখে—যতক্ষণ না তা বিস্ফোরিত হয়।
আমি এমন দল দেখেছি যেখানে সবচেয়ে সিনিয়র ব্যক্তি কখনো নিজের বিভ্রান্তি স্বীকার করেননি, ফলে সেখানে বড় ক্ষতি হয়েছে। কেউ প্রশ্ন করে না। ধারণাগুলো চ্যালেঞ্জ করা হয় না। জুনিয়র ইঞ্জিনিয়াররা চুপ থাকেন কারণ তারা ধরে নেন বাকি সবাই সব বুঝতে পারছে।
আপনি যখন কৌতূহল দেখান, তখন আপনি এমন একটি দল পান যারা আসলেই শিখতে চায়।
১৭. আপনার নেটওয়ার্ক যেকোনো চাকরির চেয়ে বেশি দিন টিকে থাকে
ক্যারিয়ারের শুরুতে আমি কাজের ওপর মনোযোগ দিয়ে নেটওয়ার্কিংকে উপেক্ষা করেছি। পরে বুঝেছি, এটি ছিল ভুল। যে সহকর্মীরা সম্পর্কের পেছনে বিনিয়োগ করেছেন—কোম্পানির ভেতরে এবং বাইরে—তারা দশকের পর দশক সুবিধা পেয়েছেন।
তারা সবার আগে সুযোগের খবর পেয়েছেন, দ্রুত সম্পর্ক তৈরি করতে পেরেছেন, ভালো পদের জন্য সুপারিশ পেয়েছেন এবং বছরের পর বছর ধরে বিশ্বাসভাজন লোকদের সাথে যৌথ উদ্যোগ শুরু করেছেন।
আপনার চাকরি চিরস্থায়ী নয়, কিন্তু আপনার নেটওয়ার্ক আপনার সাথেই থাকে। কৌতূহল এবং উদারতার সাথে নেটওয়ার্কিং করুন, নিছক স্বার্থ উদ্ধারের ধান্দায় নয়। যখন চাকরি ছাড়ার সময় আসে, তখন প্রায়শই এই সম্পর্কগুলোই নতুন দরজা খুলে দেয়।
১৮. পারফরম্যান্স বাড়ে অপ্রয়োজনীয় কাজ বাদ দিলে, চতুরতা যোগ করলে নয়
যখন সিস্টেম ধীরগতির হয়, তখন আমাদের প্রবণতা থাকে নতুন কিছু যোগ করা: ক্যাশিং লেয়ার, প্যারালাল প্রসেসিং বা চতুর অ্যালগরিদম। কখনো কখনো এটি ঠিক। কিন্তু আমি পারফরম্যান্সের বড় বড় উন্নতি দেখেছি কেবল এই প্রশ্নটি করার মাধ্যমে—“আমরা এমন কী প্রসেস করছি যার আসলে দরকার নেই?”
প্রয়োজনীয় কাজ দ্রুত করার চেয়ে অপ্রয়োজনীয় কাজ মুছে ফেলা প্রায় সবসময় বেশি প্রভাবশালী। সবচেয়ে দ্রুতগতির কোড হলো সেটাই, যা কখনো রান করার প্রয়োজনই হয় না।
অপ্টিমাইজ করার আগে প্রশ্ন করুন, কাজটি কি আদৌ থাকা উচিত?
১৯. প্রসেস বা প্রক্রিয়া অস্পষ্টতা কমানোর জন্য, পেপার ট্রেইল তৈরির জন্য নয়
সেরা প্রসেস কাজের সমন্বয় সহজ করে এবং ব্যর্থতার ঝুঁকি কমায়। আর সবচেয়ে খারাপ প্রসেস হলো “আমলাতান্ত্রিক নাটক”—যা কোনো সাহায্য করে না, বরং যখন কোনো ভুল হয় তখন একে অন্যকে দোষারোপ করার কাজে লাগে।
আপনি যদি ব্যাখ্যা করতে না পারেন যে কীভাবে একটি প্রসেস ঝুঁকি কমায় বা স্বচ্ছতা বাড়ায়, তাহলে এটি সম্ভবত শুধুই বাড়তি বোঝা (overhead)। আর যদি লোকেরা কাজ করার চেয়ে তাদের কাজের ডকুমেন্ট করতেই বেশি সময় ব্যয় করে, তবে বুঝবেন কোথাও বড় ধরনের ভুল হচ্ছে।
২০. শেষমেশ, টাকাপয়সার চেয়ে সময়ের মূল্য বেশি হয়ে দাঁড়ায়
ক্যারিয়ারের শুরুতে আপনি সময়ের বিনিময়ে অর্থ উপার্জন করেন—এবং এটি ঠিক আছে। কিন্তু একটা পর্যায়ে হিসাবটা উল্টে যায়। আপনি বুঝতে শুরু করেন যে সময় হলো এমন এক সম্পদ যা আর ফিরে পাওয়া যায় না।
আমি দেখেছি সিনিয়র ইঞ্জিনিয়াররা পরবর্তী প্রমোশনের পেছনে ছুটতে গিয়ে নিজেকে শেষ করে ফেলছেন, বেতনের সামান্য কয়েক শতাংশ বৃদ্ধির জন্য জীবনপাত করছেন। তাদের কেউ কেউ তা পেয়েছেনও। কিন্তু বেশিরভাগই পরে ভেবেছেন, তারা যা দিয়েছেন তার বিনিময়ে এটি কি আদৌ মূল্যবান ছিল?
এর মানে এই নয় যে “কঠোর পরিশ্রম করবেন না।” বরং এর মানে হলো, “আপনি কিসের বিনিময়ে কী দিচ্ছেন তা জানুন এবং ভেবেচিন্তে সিদ্ধান্ত নিন।“
২১. কোনো শর্টকাট নেই, কিন্তু চক্রবৃদ্ধি মুনাফা (Compounding) আছে
দক্ষতা আসে ইচ্ছাকৃত অনুশীলন থেকে—আপনার বর্তমান সক্ষমতার চেয়ে একটু বেশি চাপ নেওয়া, প্রতিফলন এবং পুনরাবৃত্তি। বছরের পর বছর ধরে। এর কোনো সংক্ষিপ্ত পথ নেই।
কিন্তু আশার কথা হলো: শেখার বিষয়টি চক্রবৃদ্ধি হারে বাড়ে, যখন এটি নতুন তথ্য জানার বদলে নতুন নতুন সুযোগ তৈরি করে। লিখুন—লাইক বা কমেন্টের জন্য নয়, নিজের স্বচ্ছতার জন্য। বারবার ব্যবহার করা যায় এমন বেসিক বা প্রিমিটিভ তৈরি করুন। ছোটখাটো অভিজ্ঞতাগুলোকে নিজের প্লে-বুকে রূপান্তর করুন।
যে ইঞ্জিনিয়ার তার ক্যারিয়ারকে লটারি টিকিট হিসেবে না দেখে চক্রবৃদ্ধি মুনাফা বা কম্পাউন্ডিং ইন্টারেস্ট হিসেবে দেখেন, তিনি সাধারণত দিনশেষে অনেক এগিয়ে থাকেন।
শেষ কথা
একুশটি শিক্ষা শুনতে অনেক বেশি মনে হতে পারে, কিন্তু এগুলো আসলে কয়েকটি মূল কথায় ফিরে আসে: কৌতূহলী থাকুন, বিনয়ী থাকুন এবং মনে রাখুন যে কাজ সবসময় মানুষের জন্যই—যে ব্যবহারকারীদের জন্য আপনি বানাচ্ছেন এবং যে সহকর্মীদের সাথে আপনি কাজ করছেন।
ইঞ্জিনিয়ারিং ক্যারিয়ার যথেষ্ট দীর্ঘ, তাই প্রচুর ভুল করেও সামনে এগিয়ে যাওয়া যায়। যে ইঞ্জিনিয়ারদের আমি সবচেয়ে বেশি সম্মান করি, তারা সবকিছু সঠিক করেননি—তারা নিজেদের ভুল থেকে শিখেছেন, যা আবিষ্কার করেছেন তা শেয়ার করেছেন এবং এগিয়ে গেছেন।
যদি আপনি আপনার যাত্রার শুরুতে থাকেন, জেনে রাখুন যে সময়ের সাথে সাথে এটি আরও সমৃদ্ধ হয়। আর যদি আপনি অভিজ্ঞ হন, আশা করি এগুলোর কিছু বিষয় আপনাকে অনুপ্রাণিত করবে।