ඔවුන් පවසන පරිදි, ඔබේ පැරණි කේතය ගැන ඔබ ලැජ්ජා නොවන්නේ නම්, ඔබ ක්‍රමලේඛකයෙකු ලෙස වර්ධනය නොවේ - මම මෙම මතයට එකඟ වෙමි. මම විනෝදය සඳහා වැඩසටහන් ආරම්භ කළේ මීට වසර 40 කට පෙර සහ වෘත්තීය වශයෙන් වසර 30 කට පෙර, එබැවින් මට බොහෝ වැරදි තිබේ. ගොඩක්. පරිගණක විද්‍යා මහාචාර්යවරයෙකු ලෙස, මම මගේ සිසුන්ට ඔවුන්ගේ, මගේ සහ වෙනත් වැරදි වලින් ඉගෙන ගැනීමට උගන්වමි. මම හිතන්නේ මගේ නිහතමානීකම නැති නොවීමට මගේ වැරදි ගැන කතා කිරීමට කාලයයි. ඒවා යමෙකුට ප්‍රයෝජනවත් වේ යැයි මම බලාපොරොත්තු වෙමි.

තෙවන ස්ථානය - Microsoft C compiler

මගේ පාසල් ගුරුවරයා විශ්වාස කළේ රෝමියෝ සහ ජුලියට් ඛේදවාචකයක් ලෙස සැලකිය නොහැකි බවයි, මන්ද චරිතවලට ඛේදජනක වරදක් නොතිබුණි - ඔවුන් හුදෙක් නව යොවුන් වියේ විය යුතු පරිදි මෝඩ ලෙස හැසිරුණි. මම එදා ඔහු සමඟ එකඟ නොවෙමි, නමුත් දැන් මම ඔහුගේ මතය තුළ තාර්කිකත්වයේ ධාන්යයක් දකිමි, විශේෂයෙන් වැඩසටහන්කරණය සම්බන්ධයෙන්.

මම MIT හි මගේ දෙවන වසර අවසන් කරන විට, මම ජීවිතයේ සහ වැඩසටහන්කරණයේ දී තරුණ හා අද්දැකීම් අඩුයි. ගිම්හානයේදී, මම මයික්‍රොසොෆ්ට් හි, සී සම්පාදක කණ්ඩායමට ඇතුළත් විය, මුලදී මම පැතිකඩ සහාය වැනි සාමාන්‍ය දේවල් කළෙමි, පසුව මට සම්පාදකයේ වඩාත්ම විනෝදජනක කොටස (මා සිතූ පරිදි) - බැකන්ඩ් ප්‍රශස්තිකරණය මත වැඩ කිරීමට මට භාර විය. විශේෂයෙන්ම, ශාඛා ප්රකාශයන් සඳහා x86 කේතය වැඩිදියුණු කිරීමට මට සිදු විය.

හැකි සෑම අවස්ථාවක් සඳහාම ප්‍රශස්ත යන්ත්‍ර කේතය ලිවීමට අධිෂ්ඨාන කර ගත් මම තටාකයට මා විසි කළෙමි. අගයන්හි ව්‍යාප්තිය ඝනත්වය වැඩි නම්, මම ඒවාට ඇතුල් කළෙමි සංක්රාන්ති වගුව. ඔවුන්ට පොදු භාජකයක් තිබේ නම්, මම එය මේසය තද කිරීමට එය භාවිතා කළෙමි (නමුත් බෙදීම භාවිතා කළ හැකි නම් පමණි. ටිකක් මාරුව) සියලුම අගයන් දෙකක බලයන් වූ විට, මම තවත් ප්‍රශස්තිකරණයක් කළෙමි. අගයන් සමූහයක් මගේ කොන්දේසි තෘප්තිමත් නොකළේ නම්, මම එය ප්‍රශස්ත අවස්ථා කිහිපයකට බෙදා දැනටමත් ප්‍රශස්ත කර ඇති කේතය භාවිතා කළෙමි.

එය නපුරු සිහිනයක් විය. අවුරුදු ගාණකට පස්සේ මට කිව්වා මගේ කේතය උරුම කරගත් ක්‍රමලේඛකයා මට වෛර කළා කියලා.

පාඩම ඉගෙන ගත්තා

ඩේවිඩ් පැටර්සන් සහ ජෝන් හෙනසි පරිගණක ගෘහ නිර්මාණ ශිල්පය සහ පරිගණක පද්ධති නිර්මාණය පිළිබඳ ලියන පරිදි, ගෘහ නිර්මාණ ශිල්පයේ සහ සැලසුම් කිරීමේ ප්‍රධාන මූලධර්මවලින් එකක් වන්නේ සාමාන්‍යයෙන් දේවල් හැකි ඉක්මනින් ක්‍රියාත්මක කිරීමයි.

දුර්ලභ අවස්ථා ප්‍රශස්ත කිරීමට වඩා සාමාන්‍ය අවස්ථා වේගවත් කිරීම කාර්ය සාධනය වඩාත් ඵලදායී ලෙස වැඩිදියුණු කරනු ඇත. උත්ප්‍රාසාත්මක ලෙස, සාමාන්‍ය අවස්ථා බොහෝ විට දුර්ලභ ඒවාට වඩා සරල ය. මෙම තාර්කික උපදේශය උපකල්පනය කරන්නේ කුමන සිද්ධිය පොදු යැයි සලකන්නේද යන්න ඔබ දන්නා බවයි - මෙය කළ හැක්කේ ප්‍රවේශමෙන් පරීක්ෂා කර මැනීමේ ක්‍රියාවලියකින් පමණි.

මගේ ආරක්‍ෂාවේදී, ශාඛා ප්‍රකාශයන් ප්‍රායෝගිකව කෙබඳු දැයි සොයා ගැනීමට මම උත්සාහ කළෙමි (ශාඛා කීයක් තිබේද සහ නියතයන් බෙදා හරින ලද ආකාරය වැනි), නමුත් 1988 දී මෙම තොරතුරු නොතිබුණි. කෙසේ වෙතත්, මා විසින් ඉදිරිපත් කරන ලද කෘත්‍රිම උදාහරණය සඳහා වත්මන් සම්පාදකයට ප්‍රශස්ත කේතයක් උත්පාදනය කිරීමට නොහැකි වූ සෑම අවස්ථාවකම මම විශේෂ අවස්ථා එකතු නොකළ යුතුය.

මට පළපුරුදු සංවර්ධකයෙකු ඇමතීමට අවශ්‍ය වූ අතර, ඔහු සමඟ එක්ව, පොදු අවස්ථා මොනවාදැයි සිතා ඒවා සමඟ විශේෂයෙන් කටයුතු කිරීමට අවශ්‍ය විය. මම අඩු කේතයක් ලියන්නෙමි, නමුත් එය හොඳ දෙයක්. Stack Overflow නිර්මාතෘ ජෙෆ් ඇට්වුඩ් ලියා ඇති පරිදි, ක්‍රමලේඛකයෙකුගේ නරකම සතුරා වන්නේ ක්‍රමලේඛකයාම ය:

අපි හැමෝම වගේ ඔයාටත් හොඳම චේතනා තියෙනවා කියලා මම දන්නවා. අපි වැඩසටහන් නිර්මාණය කරන අතර කේතය ලිවීමට කැමතියි. එහෙම තමයි අපිව හදලා තියෙන්නේ. අපි හිතන්නේ ඕනෑම ප්‍රශ්නයක් ඩක් ටේප් එකකින්, ගෙදර හැදූ අත්වාරුවකින් සහ කෝඩ් පොකුරකින් විසඳිය හැකි බවයි. කේත කරන්නන්ට එය පිළිගැනීමට වේදනාවක් වන තරමට, හොඳම කේතය නොපවතින කේතයයි. සෑම නව රේඛාවකටම නිදොස්කරණය සහ සහාය අවශ්‍ය වේ, එය තේරුම් ගත යුතුය. ඔබ නව කේතයක් එකතු කරන විට, ඔබ එය කළ යුත්තේ අකමැත්තෙන් සහ පිළිකුලෙන් වන අතර අනෙක් සියලුම විකල්ප අවසන් වී ඇත. බොහෝ ක්‍රමලේඛකයින් ඕනෑවට වඩා කේත ලියන අතර එය අපගේ සතුරා බවට පත් කරයි.

මම සාමාන්‍ය අවස්ථා ආවරණය කරන සරල කේතයක් ලිව්වා නම්, අවශ්‍ය නම් යාවත්කාලීන කිරීම වඩාත් පහසු වනු ඇත. කිසිවකුට මුහුණ දීමට අවශ්‍ය නැති අවුල් ජාලයක් මම අත්හැරියෙමි.

දෙවන ස්ථානය: සමාජ ජාල වල වෙළඳ දැන්වීම්

මම Google හි සමාජ මාධ්‍ය ප්‍රචාරණයේ වැඩ කරන විට (Myspace මතකද?), මම C++ හි මෙවැනි දෙයක් ලිව්වෙමි:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

ක්‍රමලේඛකයින් වහාම දෝෂය දැකිය හැක: අවසාන තර්කය j විය යුතුය, i නොවේ. ඒකක පරීක්ෂාව දෝෂය හෙළි නොකළ අතර මගේ සමාලෝචකයාද හෙළි කළේ නැත. දියත් කිරීම සිදු කරන ලද අතර, එක් රාත්‍රියක මගේ කේතය සේවාදායකයට ගොස් දත්ත මධ්‍යස්ථානයේ සියලුම පරිගණක බිඳ වැටුණි.

නරක කිසිවක් සිදු නොවීය. කිසිවෙකුට කිසිවක් කැඩී නැත, මන්ද ගෝලීය දියත් කිරීමට පෙර කේතය එක් දත්ත මධ්‍යස්ථානයක් තුළ පරීක්ෂා කරන ලදී. SRE ඉන්ජිනේරුවෝ ටික කාලෙකට බිලියඩ් ගහන එක නවත්තලා පොඩි රෝල්බැක් කළා මිසක්. පසුදා උදෑසන මට ක්‍රෂ් ඩම්ප් එකක් සහිත විද්‍යුත් තැපෑලක් ලැබී, කේතය නිවැරදි කර දෝෂය හසුවන ඒකක පරීක්ෂණ එක් කළේය. මම ප්‍රොටෝකෝලය අනුගමනය කළ බැවින් - එසේ නොමැති නම් මගේ කේතය ක්‍රියාත්මක වීමට අසමත් වනු ඇත - වෙනත් ගැටළු නොමැත.

පාඩම ඉගෙන ගත්තා

එවැනි ප්‍රධාන වැරැද්දක් අනිවාර්යයෙන්ම වැරදිකරු සේවයෙන් පහ කිරීමට වැය වන බව බොහෝ දෙනෙකුට විශ්වාසයි, නමුත් මෙය එසේ නොවේ: පළමුව, සියලුම ක්‍රමලේඛකයින් වැරදි කරන අතර, දෙවනුව, ඔවුන් එකම වැරැද්ද දෙවරක් කරන්නේ කලාතුරකිනි.

ඇත්තම කිව්වොත් මගේ දක්ෂ ඉංජිනේරුවෙක්, එක වැරද්දක් කරලා අයින් කරපු programmer යාළුවෙක් ඉන්නවා. ඊට පසු, ඔහු ගූගල් හි කුලියට ගන්නා ලදී (සහ ඉක්මනින් උසස් කරන ලදී) - සම්මුඛ පරීක්ෂණයකදී ඔහු කළ වැරැද්ද ගැන ඔහු අවංකව කතා කළ අතර එය මාරාන්තික යැයි නොසැලකේ.

ඒක තමයි කියන්න IBM හි ජනප්‍රිය ප්‍රධානියා වන තෝමස් වොට්සන් ගැන:

ඩොලර් මිලියනයක් පමණ වටිනා රජයේ නියෝගයක් ප්‍රකාශයට පත් කරන ලදී. IBM Corporation - හෝ ඒ වෙනුවට, තෝමස් වොට්සන් ජ්‍යෙෂ්ඨ පුද්ගලිකව - ඇත්තෙන්ම එය ලබා ගැනීමට අවශ්‍ය විය. අවාසනාවකට, විකුණුම් නියෝජිතයාට මෙය කිරීමට නොහැකි වූ අතර IBM ට ලංසුව අහිමි විය. පසුදින මෙම සේවකයා වොට්සන් මහතාගේ කාර්යාලයට පැමිණ ලියුම් කවරයක් ඔහුගේ මේසය මත තැබීය. වොට්සන් මහතා ඒ දෙස බලන්නටවත් වෙහෙසුනේ නැත - සේවකයෙකු එනතුරු බලා සිටි ඔහු එය ඉල්ලා අස්වීමේ ලිපියක් බව දැන සිටියේය.

වොට්සන් ඇහුවා මොකක්ද වැරදුනේ කියලා.

අලෙවි නියෝජිතයා ටෙන්ඩරයේ ප්‍රගතිය ගැන විස්තරාත්මකව කතා කළේය. වැළැක්විය හැකිව තිබූ වැරදි නම් කළේය. අවසාන වශයෙන්, ඔහු පැවසුවේ, “වොට්සන් මහත්මයා, මට පැහැදිලි කිරීමට ඉඩ දීම ගැන ස්තූතියි. මම දන්නවා අපිට මේ ඇණවුම කොච්චර අවශ්‍යද කියලා. මම දන්නවා එයා කොච්චර වැදගත්ද කියලා” කියා පිටත් වීමට සූදානම් විය.

වොට්සන් ඔහු දොර ළඟට පැමිණ, ඔහුගේ දෑස් දෙස බලා ලියුම් කවරය ආපසු දුන්නේ ය: “මම ඔබට යන්න දෙන්නේ කෙසේද? මම ඔබේ අධ්‍යාපනයට ඩොලර් මිලියනයක් ආයෝජනය කළා.

මා සතුව ටී-ෂර්ට් එකක් තිබේ: "ඔබ ඇත්තටම වැරදි වලින් ඉගෙන ගන්නේ නම්, මම දැනටමත් දක්ෂයෙකි." ඇත්ත වශයෙන්ම, දෝෂ සම්බන්ධයෙන්, මම විද්‍යාව පිළිබඳ වෛද්‍යවරයෙකි.

පළමු ස්ථානය: App Inventor API

සැබවින්ම බිහිසුණු දෝෂ විශාල පරිශීලකයින් සංඛ්‍යාවකට බලපායි, පොදු දැනුමක් බවට පත්වේ, නිවැරදි කිරීමට බොහෝ කාලයක් ගත වන අතර ඒවා සිදු කළ නොහැකි අය විසින් සිදු කරනු ලැබේ. මගේ ලොකුම වැරැද්ද මේ නිර්ණායක සියල්ලටම ගැලපේ.

නරක අතට වඩා හොඳයි

මම කියෙව්වා රචනය Richard Gabriel විසිනි උපාධි ශිෂ්‍යයෙකු ලෙස අනූව දශකයේ මෙම ප්‍රවේශය ගැන, මම එය මගේ සිසුන්ගෙන් අසන තරමට එයට කැමතියි. ඔබට එය හොඳින් මතක නැතිනම්, ඔබේ මතකය අලුත් කරන්න, එය කුඩා වේ. මෙම රචනය “එය නිවැරදිව ලබා ගැනීමට” ඇති ආශාව සහ “වඩා නරකයි වඩා හොඳ” ප්‍රවේශය සරල බව ඇතුළු බොහෝ ආකාරවලින් වෙනස් කරයි.

එය කෙසේ විය යුතුද: සැලසුම ක්රියාත්මක කිරීමේදී සහ අතුරු මුහුණතේ සරල විය යුතුය. අතුරු මුහුණතේ සරල බව ක්රියාත්මක කිරීමේ සරල බව වඩා වැදගත් වේ.

වඩාත් නරක, වඩා හොඳ: නිර්මාණය ක්රියාත්මක කිරීම සහ අතුරු මුහුණත සරල විය යුතුය. ක්රියාත්මක කිරීමේ සරල බව අතුරු මුහුණතේ සරල බව වඩා වැදගත් වේ.

අපි ඒක විනාඩියකට අමතක කරමු. අවාසනාවකට, මට එය වසර ගණනාවක් තිස්සේ අමතක විය.

යෙදුම් නව නිපැයුම්කරු

ගූගල් එකේ වැඩ කරද්දි මම ටීම් එකේ කෙනෙක් යෙදුම් නව නිපැයුම්කරු, අපේක්ෂා කරන Android සංවර්ධකයින් සඳහා ඇදගෙන යාමේ සබැඳි සංවර්ධන පරිසරයක්. එය 2009 වන අතර, ගිම්හානයේදී අපට සරත් සෘතුවේ ඉගැන්වීමේදී පරිසරය භාවිතා කළ හැකි ගුරුවරුන් සඳහා මාස්ටර් පන්ති පැවැත්වීමට හැකි වන පරිදි නියමිත වේලාවට ඇල්ෆා අනුවාදය නිකුත් කිරීමට අපි කඩිමුඩියේ සිටියෙමු. මම TI-99/4 මත ක්‍රීඩා ලිවීමට පුරුදු වී සිටි ආකාරය පිළිබඳ විකාර සහගත ස්ප්‍රයිට් ක්‍රියාත්මක කිරීමට මම ස්වේච්ඡාවෙන් ඉදිරිපත් වුණෙමි. නොදන්නා අය සඳහා, ස්ප්‍රයිට් යනු ද්විමාන චිත්‍රක වස්තුවක් වන අතර එය වෙනත් මෘදුකාංග මූලද්‍රව්‍ය සමඟ චලනය හා අන්තර් ක්‍රියා කළ හැකිය. ස්ප්‍රයිට් සඳහා උදාහරණ ලෙස අභ්‍යවකාශ නැව්, ග්‍රහක, කිරිගරුඬ සහ ජාවාරම් ඇතුළත් වේ.

අපි ජාවා හි වස්තු-නැඹුරු යෙදුම් නව නිපැයුම්කරු ක්‍රියාත්මක කළෙමු, එබැවින් එහි ඇත්තේ වස්තු සමූහයක් පමණි. බෝල සහ ස්ප්‍රයිට් ඉතා සමාන ලෙස හැසිරෙන බැවින්, මම ගුණාංග (ක්ෂේත්‍ර) X, Y, වේගය (වේගය) සහ ශීර්ෂය (දිශාව) සහිත වියුක්ත ස්ප්‍රයිට් පන්තියක් නිර්මාණය කළෙමි. ඝට්ටන හඳුනාගැනීම, තිරයේ මායිමෙන් ඉවතට පැනීම යනාදිය සඳහා ඔවුන්ට එකම ක්‍රම තිබුණි.

බෝලයක් සහ ස්ප්‍රයිට් එකක් අතර ඇති ප්‍රධාන වෙනස වන්නේ හරියටම ඇද ගන්නා දෙයයි - පිරවූ කවයක් හෝ රාස්ටර්. මම මුලින්ම ස්ප්‍රයිට් ක්‍රියාත්මක කළ බැවින්, රූපය පිහිටා ඇති ස්ථානයේ ඉහළ වම් කෙළවරේ x- සහ y-ඛණ්ඩාංක නියම කිරීම තාර්කික විය.

ස්ප්‍රයිට් ක්‍රියා කළ පසු, මම ඉතා කුඩා කේතයකින් බෝල වස්තූන් ක්‍රියාත්මක කළ හැකි බව තීරණය කළෙමි. එකම ගැටළුව වූයේ, මම පන්දුව රාමු කරන සමෝච්ඡයේ ඉහළ වම් කෙළවරේ x- සහ y-ඛණ්ඩාංක සඳහන් කරමින් (ක්‍රියාත්මක කරන්නාගේ දෘෂ්ටි කෝණයෙන්) සරලම මාර්ගය ගත් බවයි.

ඇත්ත වශයෙන්ම, ඕනෑම ගණිතමය පෙළපොතක සහ කව සඳහන් කරන වෙනත් ඕනෑම මූලාශ්‍රයක උගන්වන පරිදි, රවුමේ කේන්ද්‍රයේ x- සහ y-ඛණ්ඩාංක දැක්වීමට අවශ්‍ය විය.

මගේ අතීත වැරදි මෙන් නොව, මෙය මගේ සගයන්ට පමණක් නොව, මිලියන ගණනක App Inventor පරිශීලකයින්ටද බලපෑවේය. ඔවුන්ගෙන් බොහෝ දෙනෙක් ළමයින් හෝ වැඩසටහන්කරණයට සම්පූර්ණයෙන්ම අලුත් විය. පන්දුව පවතින සෑම යෙදුමකම වැඩ කිරීමේදී ඔවුන්ට අනවශ්‍ය පියවර රාශියක් සිදු කිරීමට සිදු විය. මගේ අනිත් වැරදි මතක් උනොත් හිනාවෙලා, අදටත් මේකි මට දාඩිය දානවා.

මම අවසානයේ මෙම දෝෂය පැච් කළේ වසර දහයකට පසුව මෑතකදීය. Joshua Bloch පවසන පරිදි API සදාකාලික වන නිසා "Patched", "fixed" නොවේ. පවතින වැඩසටහන් වලට බලපාන වෙනස්කම් සිදු කිරීමට නොහැකි වූ අතර, අපි පැරණි වැඩසටහන් වල වැරදි අගය සහ අනාගත සියලුම වැඩසටහන් වල සත්‍ය අගය සමඟ OriginAtCenter දේපල එක් කළෙමු. පරිශීලකයින්ට තාර්කික ප්‍රශ්නයක් ඇසිය හැකිය: ආරම්භක ලක්ෂ්‍යය මධ්‍යස්ථානය හැර වෙනත් තැනක තැබීමට පවා සිතුවේ කවුද? කාට ද? වසර දහයකට පෙර සාමාන්‍ය API එකක් සෑදීමට කම්මැලි වූ එක් ක්‍රමලේඛකයෙකුට.

උගත් පාඩම්

API මත වැඩ කරන විට (සෑම ක්‍රමලේඛකයෙකුටම පාහේ සමහර විට කළ යුතු), ඔබ Joshua Bloch ගේ වීඩියෝවේ දක්වා ඇති හොඳම උපදෙස් අනුගමනය කළ යුතුය.හොඳ API එකක් සාදා ගන්නේ කෙසේද සහ එය එතරම් වැදගත් වන්නේ ඇයි"නැතහොත් මෙම කෙටි ලැයිස්තුවේ:

• API මඟින් ඔබට විශාල ප්‍රතිලාභයක් මෙන්ම විශාල හානියක් ගෙන දිය හැක.. හොඳ API එකක් නැවත නැවතත් පාරිභෝගිකයන් බිහි කරයි. නරක එක ඔබේ සදාකාලික බියකරු සිහිනය බවට පත්වේ.
• දියමන්ති වැනි පොදු API සදහටම පවතී. ඔබේ සියල්ල දෙන්න: සෑම දෙයක්ම නිවැරදිව කිරීමට තවත් අවස්ථාවක් නොලැබෙනු ඇත.
• API දළ සටහන් කෙටි විය යුතුය - පන්තියේ සහ ක්‍රම අත්සන සහ විස්තර සහිත එක් පිටුවක්, පේළියකට වඩා වැඩි නොවේ. මෙය ඔබට API ප්‍රථම වරට පරිපූර්ණ නොවන්නේ නම් එය පහසුවෙන් ප්‍රතිව්‍යුහගත කිරීමට ඉඩ සලසයි.
• භාවිත අවස්ථා විස්තර කරන්නAPI ක්‍රියාත්මක කිරීමට හෝ එහි පිරිවිතර මත වැඩ කිරීමට පෙර. මේ ආකාරයෙන් ඔබ සම්පූර්ණයෙන්ම ක්‍රියාකාරී නොවන API ක්‍රියාත්මක කිරීම සහ නියම කිරීම වැළකෙනු ඇත.

මම කෘත්‍රිම පිටපතකින් කෙටි සාරාංශයක්වත් ලියා ඇත්නම්, බොහෝ විට මම දෝෂය හඳුනාගෙන එය නිවැරදි කරමි. එසේ නොවේ නම්, මගේ සගයෙකු අනිවාර්යයෙන්ම එය කරනු ඇත. දුරදිග යන ප්‍රතිවිපාක ඇති කරන ඕනෑම තීරණයක් අවම වශයෙන් දිනකට සිතා බැලිය යුතුය (මෙය ක්‍රමලේඛනයට පමණක් අදාළ නොවේ).

රිචඩ් ගේබ්‍රියෙල්ගේ රචනයේ මාතෘකාව, "වඩා නරකයි වඩා හොඳ" යන්නෙන් අදහස් කරන්නේ, අන්‍යයෙක් පරිපූර්ණ එකක් පසුපස හඹා යාමට සදාකාලික කාලයක් ගත කරන අතර, අසම්පූර්ණ නිෂ්පාදනයක් සමඟ පවා වෙළඳපොළට ප්‍රථමයා වීමේ වාසියයි. ස්ප්‍රයිට් කේතය ආවර්ජනය කරන විට, එය නිවැරදිව ලබා ගැනීමට මට තවත් කේතයක් ලිවීමට අවශ්‍ය නොවූ බව මට වැටහුණි. කවුරු මොනවා කිව්වත් මට ලොකු වැරදීමක් වුණා.

නිගමනය

ක්‍රමලේඛකයින් සෑම දිනකම වැරදි සිදු කරයි, එය දෝෂ සහිත කේතයක් ලිවීම හෝ ඔවුන්ගේ කුසලතා සහ ඵලදායිතාව වැඩිදියුණු කරන දෙයක් උත්සාහ කිරීමට අවශ්‍ය නැත. ඇත්ත වශයෙන්ම, මම කළා වගේ බරපතල වැරදි නොකර ඔබට වැඩසටහන්කරුවෙකු විය හැකිය. නමුත් ඔබේ වැරදි හඳුනාගෙන ඒවායින් ඉගෙන නොගෙන හොඳ ක්‍රමලේඛකයෙකු විය නොහැක.

බොහෝ වැරදි කරන බව හැඟෙන සිසුන් මට නිරන්තරයෙන් මුණගැසෙන අතර එබැවින් ක්‍රමලේඛනය සඳහා ඉවත් නොවේ. මම දන්නවා IT වල තියෙන impostor syndrome කොච්චර පොදුද කියලා. මා ලැයිස්තුගත කර ඇති පාඩම් ඔබ ඉගෙන ගනු ඇතැයි මම බලාපොරොත්තු වෙමි - නමුත් ප්‍රධාන එක මතක තබා ගන්න: අප සෑම කෙනෙකුම වැරදි කරයි - ලැජ්ජා සහගත, විහිලු, භයානක. අනාගතයේදී ලිපිය දිගටම කරගෙන යාමට ප්‍රමාණවත් ද්‍රව්‍ය මා සතුව නොමැති නම් මම පුදුමයට හා කලබලයට පත්වෙමි.

මූලාශ්රය: www.habr.com