જેમ તેઓ કહે છે, જો તમને તમારા જૂના કોડથી શરમ નથી, તો પછી તમે પ્રોગ્રામર તરીકે વધતા નથી - અને હું આ અભિપ્રાય સાથે સંમત છું. મેં 40 વર્ષ પહેલાં અને વ્યવસાયિક રીતે 30 વર્ષ પહેલાં મનોરંજન માટે પ્રોગ્રામિંગ શરૂ કર્યું હતું, તેથી મારી પાસે ઘણી ભૂલો છે. ખૂબ જ. કોમ્પ્યુટર સાયન્સના પ્રોફેસર તરીકે, હું મારા વિદ્યાર્થીઓને ભૂલોમાંથી શીખવાનું શીખવું છું - તેમની, મારી અને અન્યની. મને લાગે છે કે મારી ભૂલો વિશે વાત કરવાનો આ સમય છે જેથી મારી નમ્રતા ન ગુમાવો. હું આશા રાખું છું કે તેઓ કોઈને ઉપયોગી થશે.

ત્રીજું સ્થાન - માઇક્રોસોફ્ટ સી કમ્પાઇલર

મારી શાળાના શિક્ષક માનતા હતા કે રોમિયો અને જુલિયટને દુર્ઘટના તરીકે ગણી શકાય નહીં કારણ કે પાત્રોમાં કોઈ દુ:ખદ અપરાધ નથી - તેઓ ફક્ત મૂર્ખતાપૂર્વક વર્તે છે, જેમ કે કિશોરોએ જોઈએ. ત્યારે હું તેની સાથે સહમત ન હતો, પરંતુ હવે હું તેના અભિપ્રાયમાં, ખાસ કરીને પ્રોગ્રામિંગ સાથેના સંબંધમાં તર્કસંગતતાનો એક દાણો જોઉં છું.

મેં MIT માં મારું બીજું વર્ષ પૂરું કર્યું ત્યાં સુધીમાં, હું યુવાન અને બિનઅનુભવી હતો, જીવન અને પ્રોગ્રામિંગ બંનેમાં. ઉનાળામાં, મેં માઇક્રોસોફ્ટમાં, C કમ્પાઇલર ટીમમાં ઇન્ટર્ન કર્યું. શરૂઆતમાં મેં પ્રોફાઇલિંગ સપોર્ટ જેવી નિયમિત બાબતો કરી, અને પછી મને કમ્પાઇલરના સૌથી મનોરંજક ભાગ (જેમ મેં વિચાર્યું) - બેકએન્ડ ઑપ્ટિમાઇઝેશન પર કામ કરવાનું સોંપવામાં આવ્યું. ખાસ કરીને, મારે બ્રાન્ચ સ્ટેટમેન્ટ માટે x86 કોડ સુધારવાનો હતો.

દરેક સંભવિત કેસ માટે શ્રેષ્ઠ મશીન કોડ લખવાનું નક્કી કરીને, મેં મારી જાતને પૂલમાં ધકેલી દીધી. જો મૂલ્યોની વિતરણ ઘનતા વધારે હતી, તો મેં તેમાં પ્રવેશ કર્યો સંક્રમણ કોષ્ટક. જો તેમની પાસે સામાન્ય વિભાજક હોય, તો મેં તેનો ઉપયોગ ટેબલને કડક બનાવવા માટે કર્યો હતો (પરંતુ માત્ર જો વિભાજનનો ઉપયોગ કરીને કરી શકાય. બીટ શિફ્ટ). જ્યારે તમામ મૂલ્યો બે શક્તિઓ હતા, ત્યારે મેં બીજું ઑપ્ટિમાઇઝેશન કર્યું. જો મૂલ્યોનો સમૂહ મારી શરતોને સંતોષતો નથી, તો મેં તેને ઘણા ઑપ્ટિમાઇઝ કરી શકાય તેવા કેસોમાં વિભાજિત કર્યું અને પહેલેથી જ ઑપ્ટિમાઇઝ કરેલ કોડનો ઉપયોગ કર્યો.

તે એક દુઃસ્વપ્ન હતું. ઘણા વર્ષો પછી મને કહેવામાં આવ્યું કે મારો કોડ વારસામાં મેળવનાર પ્રોગ્રામર મને ધિક્કારે છે.

પાઠ શીખ્યા

ડેવિડ પેટરસન અને જ્હોન હેનેસી કમ્પ્યુટર આર્કિટેક્ચર અને કોમ્પ્યુટર સિસ્ટમ્સ ડિઝાઇનમાં લખે છે તેમ, આર્કિટેક્ચર અને ડિઝાઇનના મુખ્ય સિદ્ધાંતોમાંનો એક એ છે કે સામાન્ય રીતે વસ્તુઓ શક્ય તેટલી ઝડપથી કાર્ય કરે.

સામાન્ય કેસોને ઝડપી બનાવવાથી દુર્લભ કેસોને ઑપ્ટિમાઇઝ કરવા કરતાં વધુ અસરકારક રીતે કામગીરીમાં સુધારો થશે. વ્યંગાત્મક રીતે, સામાન્ય કિસ્સાઓ ઘણીવાર દુર્લભ કેસ કરતા સરળ હોય છે. આ તાર્કિક સલાહ ધારે છે કે તમે જાણો છો કે કયો કેસ સામાન્ય માનવામાં આવે છે - અને આ ફક્ત સાવચેતીપૂર્વક પરીક્ષણ અને માપનની પ્રક્રિયા દ્વારા જ શક્ય છે.

મારા બચાવમાં, મેં વ્યવહારમાં શાખા નિવેદનો કેવા દેખાય છે તે શોધવાનો પ્રયાસ કર્યો (જેમ કે ત્યાં કેટલી શાખાઓ હતી અને કેટલા સ્થિરાંકો વિતરિત કરવામાં આવ્યા હતા), પરંતુ 1988 માં આ માહિતી ઉપલબ્ધ ન હતી. જો કે, જ્યારે પણ વર્તમાન કમ્પાઈલર હું જે કૃત્રિમ ઉદાહરણ સાથે આવ્યો છું તેના માટે શ્રેષ્ઠ કોડ જનરેટ કરી શકતો નથી ત્યારે મારે ખાસ કિસ્સા ઉમેરવા જોઈએ નહીં.

મારે અનુભવી વિકાસકર્તાને કૉલ કરવાની જરૂર છે અને તેની સાથે મળીને, સામાન્ય કેસો શું હતા તે વિશે વિચારવું અને ખાસ કરીને તેમની સાથે વ્યવહાર કરવો. હું ઓછા કોડ લખીશ, પરંતુ તે સારી બાબત છે. સ્ટેક ઓવરફ્લોના સ્થાપક જેફ એટવુડે લખ્યું તેમ, પ્રોગ્રામરનો સૌથી ખરાબ દુશ્મન પોતે પ્રોગ્રામર છે:

હું જાણું છું કે આપણે બધાની જેમ તમારો ઇરાદો શ્રેષ્ઠ છે. અમે પ્રોગ્રામ બનાવીએ છીએ અને કોડ લખવાનું પસંદ કરીએ છીએ. આ રીતે આપણે બનેલા છીએ. અમને લાગે છે કે કોઈપણ સમસ્યા ડક્ટ ટેપ, હોમમેઇડ ક્રચ અને કોડની એક ચપટી વડે ઉકેલી શકાય છે. તે સ્વીકારવા માટે કોડર્સને જેટલું દુઃખ થાય છે, તેટલું શ્રેષ્ઠ કોડ એ કોડ છે જે અસ્તિત્વમાં નથી. દરેક નવી લાઇનને ડીબગીંગ અને સપોર્ટની જરૂર છે, તેને સમજવાની જરૂર છે. જ્યારે તમે નવો કોડ ઉમેરો છો, ત્યારે તમારે અનિચ્છા અને અણગમો સાથે આમ કરવું જોઈએ કારણ કે અન્ય તમામ વિકલ્પો ખતમ થઈ ગયા છે. ઘણા પ્રોગ્રામરો વધુ પડતા કોડ લખે છે, જે તેને આપણો દુશ્મન બનાવે છે.

જો મેં સામાન્ય કેસોને આવરી લેતા સરળ કોડ લખ્યા હોત, તો જો જરૂરી હોય તો તેને અપડેટ કરવાનું વધુ સરળ બન્યું હોત. મેં એક વાસણ છોડી દીધું જેની સાથે કોઈ વ્યવહાર કરવા માંગતું ન હતું.

બીજું સ્થાન: સામાજિક નેટવર્ક્સ પર જાહેરાત

જ્યારે હું 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 એન્જિનિયરોએ થોડા સમય માટે બિલિયર્ડ રમવાનું બંધ કર્યું અને થોડું રોલબેક કર્યું. બીજા દિવસે સવારે મને ક્રેશ ડમ્પ સાથેનો ઈમેલ મળ્યો, કોડ સુધાર્યો અને એકમ પરીક્ષણો ઉમેર્યા જે ભૂલને પકડશે. કારણ કે મેં પ્રોટોકોલનું પાલન કર્યું છે - અન્યથા મારો કોડ ફક્ત ચલાવવામાં નિષ્ફળ જશે - ત્યાં કોઈ અન્ય સમસ્યાઓ નહોતી.

પાઠ શીખ્યા

ઘણાને ખાતરી છે કે આવી મોટી ભૂલ ચોક્કસપણે ગુનેગારને બરતરફ કરવા માટે ખર્ચ કરશે, પરંતુ આવું નથી: પ્રથમ, બધા પ્રોગ્રામરો ભૂલો કરે છે, અને બીજું, તેઓ ભાગ્યે જ બે વાર સમાન ભૂલ કરે છે.

વાસ્તવમાં, મારો એક પ્રોગ્રામર મિત્ર છે જે એક તેજસ્વી એન્જિનિયર હતો અને તેને એક જ ભૂલ કરવા બદલ કાઢી મૂકવામાં આવ્યો હતો. તે પછી, તેને Google પર રાખવામાં આવ્યો હતો (અને ટૂંક સમયમાં પ્રમોટ કરવામાં આવ્યો હતો) - તેણે એક ઇન્ટરવ્યુમાં કરેલી ભૂલ વિશે પ્રામાણિકપણે વાત કરી હતી, અને તેને જીવલેણ માનવામાં આવતું ન હતું.

તે શું છે જણાવો IBM ના સુપ્રસિદ્ધ વડા થોમસ વોટસન વિશે:

લગભગ એક મિલિયન ડોલરના સરકારી ઓર્ડરની જાહેરાત કરવામાં આવી હતી. IBM કોર્પોરેશન - અથવા તેના બદલે, થોમસ વોટસન સિનિયર વ્યક્તિગત રીતે - ખરેખર તે મેળવવા માંગે છે. કમનસીબે, વેચાણ પ્રતિનિધિ આ કરવામાં અસમર્થ હતો અને IBM બિડ હારી ગયો. બીજા દિવસે, આ કર્મચારી શ્રી વોટસનની ઓફિસમાં આવ્યો અને તેના ડેસ્ક પર એક પરબિડીયું મૂક્યું. શ્રી વોટસને તેની તરફ જોવાની પણ તસ્દી લીધી ન હતી - તેઓ એક કર્મચારીની રાહ જોઈ રહ્યા હતા અને જાણતા હતા કે તે રાજીનામું પત્ર છે.

વોટસને પૂછ્યું કે શું ખોટું થયું.

વેચાણ પ્રતિનિધિએ ટેન્ડરની પ્રગતિ વિશે વિગતવાર વાત કરી. તેણે એવી ભૂલોને નામ આપ્યું જે ટાળી શકાયું હોત. અંતે, તેણે કહ્યું, “મિસ્ટર વોટસન, મને સમજાવવા બદલ આભાર. મને ખબર છે કે અમને આ ઓર્ડરની કેટલી જરૂર છે. હું જાણું છું કે તે કેટલો મહત્વપૂર્ણ હતો," અને જવા માટે તૈયાર થયો.

વોટસન દરવાજા પાસે તેની પાસે ગયો, તેની આંખોમાં જોયું અને શબ્દો સાથે પરબિડીયું પાછું આપ્યું: “હું તમને કેવી રીતે જવા દઉં? મેં હમણાં જ તમારા શિક્ષણમાં એક મિલિયન ડોલરનું રોકાણ કર્યું છે.

મારી પાસે એક ટી-શર્ટ છે જે કહે છે: "જો તમે ખરેખર ભૂલોમાંથી શીખો છો, તો હું પહેલેથી જ માસ્ટર છું." હકીકતમાં, જ્યારે ભૂલોની વાત આવે છે, ત્યારે હું વિજ્ઞાનનો ડૉક્ટર છું.

પ્રથમ સ્થાન: એપ્લિકેશન શોધક API

ખરેખર ભયંકર ભૂલો મોટી સંખ્યામાં વપરાશકર્તાઓને અસર કરે છે, જાહેર જ્ઞાન બની જાય છે, સુધારવામાં લાંબો સમય લે છે, અને તે લોકો દ્વારા કરવામાં આવે છે જેઓ તેમને બનાવી શક્યા ન હોય. મારી સૌથી મોટી ભૂલ આ તમામ માપદંડોને બંધબેસે છે.

ખરાબ તેટલું સારું

મેં વાંચ્યું રિચાર્ડ ગેબ્રિયલ દ્વારા નિબંધ સ્નાતક વિદ્યાર્થી તરીકે નેવુંના દાયકામાં આ અભિગમ વિશે, અને મને તે એટલું ગમ્યું કે હું મારા વિદ્યાર્થીઓને પૂછું છું. જો તમને તે સારી રીતે યાદ નથી, તો તમારી યાદશક્તિને તાજી કરો, તે નાની છે. આ નિબંધ સરળતા સહિત ઘણી રીતે "તેને યોગ્ય બનાવવા" અને "ખરાબ તે વધુ સારું" અભિગમની ઇચ્છાથી વિરોધાભાસી છે.

તે કેવી રીતે હોવું જોઈએ: ડિઝાઇન અમલીકરણ અને ઇન્ટરફેસમાં સરળ હોવી જોઈએ. અમલીકરણની સરળતા કરતાં ઇન્ટરફેસની સરળતા વધુ મહત્વપૂર્ણ છે.

ખરાબ, વધુ સારું: ડિઝાઇન અમલીકરણ અને ઇન્ટરફેસમાં સરળ હોવી જોઈએ. અમલીકરણની સરળતા ઇન્ટરફેસની સરળતા કરતાં વધુ મહત્વપૂર્ણ છે.

ચાલો તે વિશે એક મિનિટ માટે ભૂલી જઈએ. કમનસીબે, હું ઘણા વર્ષોથી તેના વિશે ભૂલી ગયો.

એપ્લિકેશન શોધક

Google માં કામ કરતી વખતે, હું ટીમનો ભાગ હતો એપ્લિકેશન શોધક, મહત્વાકાંક્ષી Android વિકાસકર્તાઓ માટે ડ્રેગ-એન્ડ-ડ્રોપ ઑનલાઇન વિકાસ વાતાવરણ. તે 2009 હતું, અને અમે સમયસર આલ્ફા સંસ્કરણ પ્રકાશિત કરવાની ઉતાવળમાં હતા જેથી ઉનાળામાં અમે શિક્ષકો માટે માસ્ટર ક્લાસ યોજી શકીએ જેઓ પાનખરમાં ભણાવતી વખતે પર્યાવરણનો ઉપયોગ કરી શકે. TI-99/4 પર હું કેવી રીતે રમતો લખતો હતો તે માટે હું નોસ્ટાલ્જિક, સ્પ્રાઉટ્સનો અમલ કરવા માટે સ્વૈચ્છિક હતો. જેઓ જાણતા નથી તેમના માટે, સ્પ્રાઈટ એ દ્વિ-પરિમાણીય ગ્રાફિકલ ઑબ્જેક્ટ છે જે અન્ય સૉફ્ટવેર ઘટકો સાથે ખસેડી અને ક્રિયાપ્રતિક્રિયા કરી શકે છે. સ્પ્રાઉટ્સના ઉદાહરણોમાં સ્પેસશીપ્સ, એસ્ટરોઇડ્સ, માર્બલ્સ અને રેકેટ્સનો સમાવેશ થાય છે.

અમે Javaમાં ઑબ્જેક્ટ-ઓરિએન્ટેડ ઍપ ઇન્વેન્ટરને લાગુ કર્યું છે, તેથી ત્યાં ઑબ્જેક્ટનો સમૂહ છે. દડા અને સ્પ્રાઈટ્સ ખૂબ જ સમાન રીતે વર્તે છે, તેથી મેં ગુણધર્મો (ક્ષેત્રો) X, Y, ઝડપ (ગતિ) અને મથાળું (દિશા) સાથે એક અમૂર્ત સ્પ્રાઈટ વર્ગ બનાવ્યો છે. તેમની પાસે અથડામણો શોધવા, સ્ક્રીનની કિનારી પરથી ઉછળવા વગેરે માટે સમાન પદ્ધતિઓ હતી.

બોલ અને સ્પ્રાઈટ વચ્ચેનો મુખ્ય તફાવત એ છે કે બરાબર શું દોરવામાં આવે છે - ભરેલું વર્તુળ અથવા રાસ્ટર. મેં પહેલા સ્પ્રાઈટ્સનો અમલ કર્યો હોવાથી, જ્યાં ઈમેજ સ્થિત હતી તેના ઉપરના ડાબા ખૂણાના x- અને y- કોઓર્ડિનેટ્સનો ઉલ્લેખ કરવો તાર્કિક હતું.

એકવાર સ્પ્રાઉટ્સ કામ કરી રહ્યા હતા, મેં નક્કી કર્યું કે હું બહુ ઓછા કોડ સાથે બોલ ઑબ્જેક્ટ્સને અમલમાં મૂકી શકું છું. એકમાત્ર સમસ્યા એ હતી કે મેં સૌથી સરળ માર્ગ (અમલકર્તાના દૃષ્ટિકોણથી) લીધો, જે બોલને ફ્રેમ બનાવતા કોન્ટૂરના ઉપરના ડાબા ખૂણાના x- અને y- કોઓર્ડિનેટ્સ સૂચવે છે.

વાસ્તવમાં, વર્તુળના કેન્દ્રના x- અને y- કોઓર્ડિનેટ્સ સૂચવવા જરૂરી હતા, જેમ કે કોઈપણ ગણિતના પાઠ્યપુસ્તકમાં અને વર્તુળોનો ઉલ્લેખ કરતા અન્ય કોઈપણ સ્ત્રોતમાં શીખવવામાં આવે છે.

મારી ભૂતકાળની ભૂલોથી વિપરીત, આની માત્ર મારા સાથીદારોને જ નહીં, પણ લાખો એપ્લિકેશન શોધક વપરાશકર્તાઓને પણ અસર થઈ છે. તેમાંના ઘણા બાળકો હતા અથવા પ્રોગ્રામિંગ માટે સંપૂર્ણપણે નવા હતા. દરેક એપ્લીકેશન જેમાં બોલ હાજર હતો તેના પર કામ કરતી વખતે તેઓએ ઘણાં બિનજરૂરી પગલાં ભરવા પડ્યા. હાસ્ય સાથે મારી બીજી ભૂલો યાદ કરું તો આજે પણ આ ભૂલ મને પરસેવો પાડી દે છે.

મેં છેલ્લે દસ વર્ષ પછી તાજેતરમાં જ આ બગને પેચ કર્યો. "પેચ કરેલ", "નિશ્ચિત" નથી, કારણ કે જોશુઆ બ્લોચ કહે છે તેમ, API શાશ્વત છે. હાલના પ્રોગ્રામ્સને અસર કરે તેવા ફેરફારો કરવામાં અસમર્થ, અમે OriginAtCenter પ્રોપર્ટીને જૂના પ્રોગ્રામ્સમાં વેલ્યુ ફોલ્સ અને ભવિષ્યના તમામ પ્રોગ્રામ્સમાં ટ્રુ સાથે ઉમેરી છે. વપરાશકર્તાઓ એક તાર્કિક પ્રશ્ન પૂછી શકે છે: જેમણે પણ કેન્દ્ર સિવાય બીજે ક્યાંક પ્રારંભ બિંદુ મૂકવાનું વિચાર્યું હતું. કોને? એક પ્રોગ્રામરને જે દસ વર્ષ પહેલાં સામાન્ય API બનાવવા માટે ખૂબ આળસુ હતો.

પાઠ શીખ્યા

APIs પર કામ કરતી વખતે (જે લગભગ દરેક પ્રોગ્રામરે ક્યારેક કરવું પડે છે), તમારે જોશુઆ બ્લોચના વિડિયોમાં દર્શાવેલ શ્રેષ્ઠ સલાહને અનુસરવી જોઈએ "સારી API કેવી રીતે બનાવવી અને તે શા માટે એટલું મહત્વનું છે"અથવા આ ટૂંકી યાદીમાં:

• API તમને મોટો ફાયદો અને મોટું નુકસાન બંને લાવી શકે છે.. એક સારો API પુનરાવર્તિત ગ્રાહકો બનાવે છે. ખરાબ તમારા શાશ્વત દુઃસ્વપ્ન બની જાય છે.
• સાર્વજનિક API, હીરાની જેમ, કાયમ રહે છે. તેને તમારું બધું આપો: બધું બરાબર કરવાની બીજી તક ક્યારેય નહીં મળે.
• API રૂપરેખા સંક્ષિપ્ત હોવી જોઈએ — વર્ગ અને પદ્ધતિના હસ્તાક્ષરો અને વર્ણનો સાથેનું એક પૃષ્ઠ, એક લીટી કરતાં વધુ ન લેતું. આ તમને API ને સરળતાથી પુનઃરચના કરવાની મંજૂરી આપશે જો તે પ્રથમ વખત સંપૂર્ણ ન બને.
• ઉપયોગના કિસ્સાઓનું વર્ણન કરોAPI ને અમલમાં મૂકતા પહેલા અથવા તેના સ્પષ્ટીકરણ પર કામ કરતા પહેલા. આ રીતે તમે સંપૂર્ણપણે બિન-કાર્યકારી API ને અમલમાં મૂકવાનું અને સ્પષ્ટ કરવાનું ટાળશો.

જો મેં કૃત્રિમ સ્ક્રિપ્ટ સાથે ટૂંકો સારાંશ પણ લખ્યો હોત, તો સંભવતઃ મેં ભૂલને ઓળખી અને તેને સુધારી લીધી હોત. જો નહીં, તો મારા સાથીદારોમાંથી એક ચોક્કસપણે તે કરશે. કોઈપણ નિર્ણય કે જેના દૂરગામી પરિણામો હોય છે તેના વિશે ઓછામાં ઓછા એક દિવસ માટે વિચારવું જરૂરી છે (આ માત્ર પ્રોગ્રામિંગને જ લાગુ પડતું નથી).

રિચાર્ડ ગેબ્રિયલના નિબંધનું શીર્ષક, "વૉર્સ ઇઝ બેટર," એ લાભનો ઉલ્લેખ કરે છે જે બજારમાં પ્રથમ બનવા માટે જાય છે - અપૂર્ણ ઉત્પાદન સાથે પણ - જ્યારે કોઈ અન્ય વ્યક્તિ સંપૂર્ણ નિબંધનો પીછો કરવા માટે અનંતકાળ વિતાવે છે. સ્પ્રાઈટ કોડ પર પ્રતિબિંબિત કરતા, મને ખ્યાલ આવે છે કે તેને યોગ્ય કરવા માટે મારે વધુ કોડ લખવાની પણ જરૂર નથી. ગમે તે કહે, હું ઘોર ભૂલમાં હતો.

નિષ્કર્ષ

પ્રોગ્રામરો દરરોજ ભૂલો કરે છે, પછી ભલે તે બગડેલ કોડ લખવાનો હોય અથવા કંઈક અજમાવવા માંગતા ન હોય જે તેમની કુશળતા અને ઉત્પાદકતામાં સુધારો કરે. અલબત્ત, તમે મારા જેવી ગંભીર ભૂલો કર્યા વિના પ્રોગ્રામર બની શકો છો. પરંતુ તમારી ભૂલોને ઓળખ્યા વિના અને તેમાંથી શીખ્યા વિના સારા પ્રોગ્રામર બનવું અશક્ય છે.

હું સતત એવા વિદ્યાર્થીઓનો સામનો કરું છું જેઓ એવું અનુભવે છે કે તેઓ ઘણી બધી ભૂલો કરે છે અને તેથી પ્રોગ્રામિંગ માટે તેમને કાપવામાં આવતા નથી. હું જાણું છું કે આઇટીમાં ઇમ્પોસ્ટર સિન્ડ્રોમ કેટલું સામાન્ય છે. હું આશા રાખું છું કે તમે મેં સૂચિબદ્ધ કરેલા પાઠ શીખી શકશો - પરંતુ મુખ્ય યાદ રાખો: આપણામાંના દરેક ભૂલો કરે છે - શરમજનક, રમુજી, ભયંકર. જો ભવિષ્યમાં મારી પાસે લેખ ચાલુ રાખવા માટે પૂરતી સામગ્રી ન હોય તો મને આશ્ચર્ય થશે અને અસ્વસ્થ થશે.

સોર્સ: www.habr.com