వారు చెప్పినట్లుగా, మీరు మీ పాత కోడ్ గురించి సిగ్గుపడకపోతే, మీరు ప్రోగ్రామర్‌గా ఎదగడం లేదు - మరియు నేను ఈ అభిప్రాయంతో ఏకీభవిస్తున్నాను. నేను 40 సంవత్సరాల క్రితం వినోదం కోసం ప్రోగ్రామింగ్ ప్రారంభించాను మరియు వృత్తిపరంగా 30 సంవత్సరాల క్రితం, నేను చాలా తప్పులను కలిగి ఉన్నాను. చాలా. కంప్యూటర్ సైన్స్ ప్రొఫెసర్‌గా, నేను నా విద్యార్థులకు తప్పుల నుండి నేర్చుకునేలా బోధిస్తాను-వారివి, నావి మరియు ఇతరులవి. నా నిరాడంబరతను కోల్పోకుండా నా తప్పుల గురించి మాట్లాడే సమయం వచ్చిందని నేను భావిస్తున్నాను. అవి ఎవరికైనా ఉపయోగపడతాయని ఆశిస్తున్నాను.
మూడవ స్థానం - మైక్రోసాఫ్ట్ సి కంపైలర్
నా పాఠశాల ఉపాధ్యాయుడు రోమియో మరియు జూలియట్‌లను విషాదంగా పరిగణించలేమని నమ్మాడు, ఎందుకంటే పాత్రలకు విషాద అపరాధం లేదు - వారు కేవలం యుక్తవయసులో ఉన్నంత తెలివితక్కువగా ప్రవర్తించారు. నేను అప్పుడు అతనితో ఏకీభవించలేదు, కానీ ఇప్పుడు నేను అతని అభిప్రాయంలో హేతుబద్ధతను చూస్తున్నాను, ముఖ్యంగా ప్రోగ్రామింగ్‌కు సంబంధించి.
నేను MITలో నా రెండవ సంవత్సరం పూర్తి చేసే సమయానికి, జీవితంలో మరియు ప్రోగ్రామింగ్‌లో నేను యవ్వనంగా మరియు అనుభవం లేనివాడిని. వేసవిలో, నేను మైక్రోసాఫ్ట్‌లో, సి కంపైలర్ టీమ్‌లో ఇంటర్న్ చేసాను.మొదట నేను ప్రొఫైలింగ్ సపోర్ట్ వంటి రొటీన్ పనులు చేసాను, ఆపై కంపైలర్‌లోని అత్యంత ఆహ్లాదకరమైన భాగం (నేను అనుకున్నట్లుగా) - బ్యాకెండ్ ఆప్టిమైజేషన్‌పై పని చేయడం నాకు అప్పగించబడింది. ముఖ్యంగా, నేను బ్రాంచ్ స్టేట్‌మెంట్‌ల కోసం x86 కోడ్‌ని మెరుగుపరచాల్సి వచ్చింది.
సాధ్యమయ్యే ప్రతి కేసుకు సరైన మెషీన్ కోడ్‌ను వ్రాయాలని నిర్ణయించుకున్నాను, నేను పూల్‌లో తలదాచుకున్నాను. విలువల పంపిణీ సాంద్రత ఎక్కువగా ఉంటే, నేను వాటిని నమోదు చేసాను . వారికి ఉమ్మడి డివైజర్ ఉంటే, నేను టేబుల్‌ను బిగుతుగా చేయడానికి దాన్ని ఉపయోగించాను (కానీ విభజన ఉపయోగించి మాత్రమే చేయగలిగితే మాత్రమే ) అన్ని విలువలు రెండు శక్తులుగా ఉన్నప్పుడు, నేను మరొక ఆప్టిమైజేషన్ చేసాను. విలువల సమితి నా షరతులను సంతృప్తిపరచకపోతే, నేను దానిని అనేక ఆప్టిమైజ్ చేయదగిన కేసులుగా విభజించి, ఇప్పటికే ఆప్టిమైజ్ చేసిన కోడ్‌ని ఉపయోగించాను.
ఇది ఒక పీడకల. చాలా సంవత్సరాల తర్వాత నా కోడ్‌ను వారసత్వంగా పొందిన ప్రోగ్రామర్ నన్ను అసహ్యించుకున్నాడని నాకు చెప్పబడింది.
పాఠం నేర్చుకున్న
డేవిడ్ ప్యాటర్సన్ మరియు జాన్ హెన్నెస్సీ కంప్యూటర్ ఆర్కిటెక్చర్ మరియు కంప్యూటర్ సిస్టమ్స్ డిజైన్‌లో వ్రాసినట్లుగా, ఆర్కిటెక్చర్ మరియు డిజైన్ యొక్క ప్రధాన సూత్రాలలో ఒకటి సాధారణంగా సాధ్యమైనంత త్వరగా పని చేసేలా చేయడం.
అరుదైన కేసులను ఆప్టిమైజ్ చేయడం కంటే సాధారణ కేసులను వేగవంతం చేయడం పనితీరును మరింత సమర్థవంతంగా మెరుగుపరుస్తుంది. హాస్యాస్పదంగా, సాధారణ కేసులు తరచుగా అరుదైన వాటి కంటే సరళంగా ఉంటాయి. ఈ తార్కిక సలహా మీకు ఏ కేసు సాధారణమైనదిగా పరిగణించబడుతుందో తెలుసని ఊహిస్తుంది - మరియు ఇది జాగ్రత్తగా పరీక్ష మరియు కొలత ప్రక్రియ ద్వారా మాత్రమే సాధ్యమవుతుంది.
నా రక్షణలో, నేను బ్రాంచ్ స్టేట్‌మెంట్‌లు ఆచరణలో ఎలా ఉన్నాయో గుర్తించడానికి ప్రయత్నించాను (ఎన్ని శాఖలు ఉన్నాయి మరియు స్థిరాంకాలు ఎలా పంపిణీ చేయబడ్డాయి వంటివి), కానీ 1988లో ఈ సమాచారం అందుబాటులో లేదు. అయినప్పటికీ, నేను కనుగొన్న కృత్రిమ ఉదాహరణ కోసం ప్రస్తుత కంపైలర్ సరైన కోడ్‌ను రూపొందించలేనప్పుడు నేను ప్రత్యేక సందర్భాలను జోడించకూడదు.
నేను అనుభవజ్ఞుడైన డెవలపర్‌ని పిలవాలి మరియు అతనితో కలిసి, సాధారణ కేసులు ఏమిటో ఆలోచించి, వాటితో ప్రత్యేకంగా వ్యవహరించాలి. నేను తక్కువ కోడ్ వ్రాస్తాను, కానీ అది మంచి విషయం. స్టాక్ ఓవర్‌ఫ్లో వ్యవస్థాపకుడు జెఫ్ అట్‌వుడ్ వ్రాసినట్లుగా, ప్రోగ్రామర్ యొక్క చెత్త శత్రువు ప్రోగ్రామర్ స్వయంగా:
మా అందరిలాగే మీకు కూడా మంచి ఉద్దేశాలు ఉన్నాయని నాకు తెలుసు. మేము ప్రోగ్రామ్‌లను సృష్టిస్తాము మరియు కోడ్ రాయడానికి ఇష్టపడతాము. మనం అలా తయారయ్యాము. డక్ట్ టేప్, ఇంట్లో తయారుచేసిన ఊతకర్ర మరియు చిటికెడు కోడ్‌తో ఏదైనా సమస్యను పరిష్కరించవచ్చని మేము భావిస్తున్నాము. కోడర్‌లు దానిని అంగీకరించడం ఎంతగానో బాధిస్తుంది, ఉత్తమ కోడ్ ఉనికిలో లేని కోడ్. ప్రతి కొత్త లైన్‌కు డీబగ్గింగ్ మరియు మద్దతు అవసరం, దానిని అర్థం చేసుకోవాలి. మీరు కొత్త కోడ్‌ని జోడించినప్పుడు, అన్ని ఇతర ఎంపికలు అయిపోయినందున మీరు అయిష్టంగా మరియు అసహ్యంతో అలా చేయాలి. చాలా మంది ప్రోగ్రామర్లు చాలా ఎక్కువ కోడ్‌ని వ్రాస్తారు, అది మన శత్రువుగా మారుతుంది.
నేను సాధారణ కేసులను కవర్ చేసే సరళమైన కోడ్‌ని వ్రాసి ఉంటే, అవసరమైతే నవీకరించడం చాలా సులభం అవుతుంది. ఎవరూ ఎదుర్కోవటానికి ఇష్టపడని గందరగోళాన్ని నేను విడిచిపెట్టాను.
రెండవ స్థానం: సోషల్ నెట్‌వర్క్‌లలో ప్రకటనలు
నేను సోషల్ మీడియా అడ్వర్టైజింగ్‌లో Googleలో పని చేస్తున్నప్పుడు (మైస్పేస్ గుర్తుందా?), నేను 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 ఇంజనీర్లు కొంతకాలం బిలియర్డ్స్ ఆడటం మానేసి, కొంచెం వెనక్కి తగ్గారు తప్ప. మరుసటి రోజు ఉదయం నేను క్రాష్ డంప్‌తో ఇమెయిల్‌ను అందుకున్నాను, కోడ్‌ని సరిదిద్దాను మరియు లోపాన్ని గుర్తించే యూనిట్ పరీక్షలను జోడించాను. నేను ప్రోటోకాల్‌ను అనుసరించినందున - లేకపోతే నా కోడ్ అమలు చేయడంలో విఫలమవుతుంది - ఇతర సమస్యలు లేవు.
పాఠం నేర్చుకున్న
అటువంటి పెద్ద తప్పు ఖచ్చితంగా అపరాధి తొలగింపుకు ఖర్చవుతుందని చాలా మంది ఖచ్చితంగా అనుకుంటున్నారు, కానీ ఇది అలా కాదు: మొదట, ప్రోగ్రామర్లందరూ తప్పులు చేస్తారు మరియు రెండవది, వారు చాలా అరుదుగా అదే తప్పును రెండుసార్లు చేస్తారు.
నిజానికి, నాకు ఒక ప్రోగ్రామర్ స్నేహితుడు ఉన్నాడు, అతను తెలివైన ఇంజనీర్ మరియు ఒక్క తప్పు చేసినందుకు తొలగించబడ్డాడు. ఆ తరువాత, అతను గూగుల్‌లో నియమించబడ్డాడు (మరియు త్వరలో పదోన్నతి పొందాడు) - అతను ఒక ఇంటర్వ్యూలో చేసిన తప్పు గురించి నిజాయితీగా మాట్లాడాడు మరియు అది ప్రాణాంతకంగా పరిగణించబడలేదు.
అందు కోసమే IBM యొక్క లెజెండరీ హెడ్ థామస్ వాట్సన్ గురించి:
సుమారు లక్ష డాలర్ల విలువైన ప్రభుత్వ ఉత్తర్వును ప్రకటించారు. IBM కార్పొరేషన్ - లేదా బదులుగా, థామస్ వాట్సన్ సీనియర్ వ్యక్తిగతంగా - నిజంగా దాన్ని పొందాలనుకుంటున్నారు. దురదృష్టవశాత్తూ, సేల్స్ రిప్రజెంటేటివ్ దీన్ని చేయలేకపోయారు మరియు IBM బిడ్‌ను కోల్పోయింది. మరుసటి రోజు, ఈ ఉద్యోగి మిస్టర్ వాట్సన్ కార్యాలయంలోకి వచ్చి అతని డెస్క్‌పై ఒక కవరు ఉంచాడు. మిస్టర్ వాట్సన్ దానిని చూడడానికి కూడా ఇష్టపడలేదు - అతను ఒక ఉద్యోగి కోసం ఎదురు చూస్తున్నాడు మరియు అది రాజీనామా లేఖ అని తెలుసు.
ఏం తప్పు జరిగిందని వాట్సన్ అడిగాడు.
టెండర్ పురోగతిపై సేల్స్ ప్రతినిధి వివరంగా మాట్లాడారు. అతను నివారించగలిగే తప్పులను పేర్కొన్నాడు. చివరగా, "మిస్టర్ వాట్సన్, నన్ను వివరించడానికి అనుమతించినందుకు ధన్యవాదాలు. ఈ ఆర్డర్ మాకు ఎంత అవసరమో నాకు తెలుసు. అతను ఎంత ముఖ్యమో నాకు తెలుసు” అని చెప్పి బయలుదేరడానికి సిద్ధమయ్యాడు.
వాట్సన్ తలుపు దగ్గరికి వచ్చి, అతని కళ్ళలోకి చూస్తూ, కవరును తిరిగి ఇచ్చాడు: “నేను నిన్ను ఎలా వెళ్ళనివ్వగలను? నేను మీ విద్య కోసం ఒక మిలియన్ డాలర్లు పెట్టుబడి పెట్టాను.
నా దగ్గర టీ-షర్టు ఉంది: "మీరు నిజంగా తప్పుల నుండి నేర్చుకుంటే, నేను ఇప్పటికే మాస్టర్‌ని." నిజానికి, లోపాల విషయానికి వస్తే, నేను సైన్స్ డాక్టర్.
మొదటి స్థానం: యాప్ ఇన్వెంటర్ API
నిజంగా భయంకరమైన లోపాలు భారీ సంఖ్యలో వినియోగదారులపై ప్రభావం చూపుతాయి, పబ్లిక్ జ్ఞానాన్ని పొందుతాయి, సరిదిద్దడానికి చాలా సమయం పడుతుంది మరియు వాటిని చేయలేని వారిచే తయారు చేయబడతాయి. నా అతి పెద్ద తప్పు ఈ ప్రమాణాలన్నింటికీ సరిపోతుంది.
అధ్వాన్నంగా ఉంటే మంచిది
నేను చదివాను తొంభైలలో గ్రాడ్యుయేట్ విద్యార్థిగా ఉన్న ఈ విధానం గురించి, మరియు నేను నా విద్యార్థులను అడిగాను కాబట్టి ఇది నాకు చాలా ఇష్టం. మీకు బాగా గుర్తులేకపోతే, మీ మెమరీని రిఫ్రెష్ చేయండి, అది చిన్నది. ఈ వ్యాసం సరళతతో సహా అనేక విధాలుగా "సరైనది" మరియు "అధ్వాన్నంగా ఉత్తమం" అనే విధానానికి విరుద్ధంగా ఉంటుంది.
ఇది ఎలా ఉండాలి: డిజైన్ అమలు మరియు ఇంటర్‌ఫేస్‌లో సరళంగా ఉండాలి. అమలు యొక్క సరళత కంటే ఇంటర్ఫేస్ యొక్క సరళత చాలా ముఖ్యమైనది.
అధ్వాన్నంగా, మంచిది: డిజైన్ అమలు మరియు ఇంటర్‌ఫేస్‌లో సరళంగా ఉండాలి. ఇంటర్ఫేస్ యొక్క సరళత కంటే అమలు యొక్క సరళత చాలా ముఖ్యమైనది.
ఒక్క నిమిషం ఆ సంగతి మర్చిపోదాం. దురదృష్టవశాత్తు, నేను చాలా సంవత్సరాలు దాని గురించి మరచిపోయాను.
అనువర్తన ఆవిష్కర్త
గూగుల్‌లో పనిచేస్తున్నప్పుడు, నేను జట్టులో భాగుడిని , ఔత్సాహిక Android డెవలపర్‌ల కోసం డ్రాగ్ అండ్ డ్రాప్ ఆన్‌లైన్ డెవలప్‌మెంట్ వాతావరణం. ఇది 2009, మరియు మేము ఆల్ఫా వెర్షన్‌ను సకాలంలో విడుదల చేయడానికి ఆతురుతలో ఉన్నాము, తద్వారా వేసవిలో మేము శరదృతువులో బోధించేటప్పుడు పర్యావరణాన్ని ఉపయోగించగల ఉపాధ్యాయుల కోసం మాస్టర్ క్లాస్‌లను నిర్వహించగలము. నేను TI-99/4లో గేమ్‌లను ఎలా వ్రాస్తాను అనే వ్యామోహంతో స్ప్రిట్‌లను అమలు చేయడానికి స్వచ్ఛందంగా ముందుకు వచ్చాను. తెలియని వారికి, స్ప్రైట్ అనేది రెండు డైమెన్షనల్ గ్రాఫికల్ వస్తువు, ఇది ఇతర సాఫ్ట్‌వేర్ ఎలిమెంట్‌లతో కదలగలదు మరియు పరస్పర చర్య చేయగలదు. స్ప్రిట్‌లకు ఉదాహరణలు స్పేస్‌షిప్‌లు, గ్రహశకలాలు, గోళీలు మరియు రాకెట్‌లు.
మేము జావాలో ఆబ్జెక్ట్-ఓరియెంటెడ్ యాప్ ఇన్వెంటర్‌ని అమలు చేసాము, కాబట్టి అక్కడ కొన్ని వస్తువులు మాత్రమే ఉన్నాయి. బంతులు మరియు స్ప్రిట్‌లు చాలా సారూప్యంగా ప్రవర్తిస్తాయి కాబట్టి, నేను లక్షణాలు (ఫీల్డ్‌లు) X, Y, స్పీడ్ (స్పీడ్) మరియు హెడ్డింగ్ (దిశ)తో ఒక వియుక్త స్ప్రైట్ తరగతిని సృష్టించాను. ఘర్షణలను గుర్తించడం, స్క్రీన్ అంచు నుండి బౌన్స్ అవ్వడం మొదలైన వాటి కోసం వారు అదే పద్ధతులను కలిగి ఉన్నారు.
బంతి మరియు స్ప్రైట్ మధ్య ప్రధాన వ్యత్యాసం ఖచ్చితంగా డ్రా అయినది - నిండిన వృత్తం లేదా రాస్టర్. నేను మొదట స్ప్రిట్‌లను అమలు చేసినందున, చిత్రం ఉన్న చోట ఎగువ ఎడమ మూలలో x- మరియు y-కోఆర్డినేట్‌లను పేర్కొనడం లాజికల్‌గా ఉంది.
స్ప్రిట్‌లు పనిచేసిన తర్వాత, నేను చాలా తక్కువ కోడ్‌తో బాల్ వస్తువులను అమలు చేయగలనని నిర్ణయించుకున్నాను. ఒకే సమస్య ఏమిటంటే, నేను బంతిని రూపొందించే ఆకృతి యొక్క ఎగువ ఎడమ మూలలో x- మరియు y-కోఆర్డినేట్‌లను సూచించే సరళమైన మార్గాన్ని (అమలు చేసేవారి కోణం నుండి) తీసుకున్నాను.
వాస్తవానికి, ఏదైనా గణిత పాఠ్యపుస్తకంలో మరియు సర్కిల్‌లను సూచించే ఏదైనా ఇతర మూలంలో బోధించినట్లుగా, వృత్తం మధ్యలో x- మరియు y-కోఆర్డినేట్‌లను సూచించడం అవసరం.
నా గత పొరపాట్లు కాకుండా, ఇది నా సహోద్యోగులను మాత్రమే కాకుండా మిలియన్ల కొద్దీ యాప్ ఇన్వెంటర్ వినియోగదారులను కూడా ప్రభావితం చేసింది. వారిలో చాలామంది పిల్లలు లేదా ప్రోగ్రామింగ్‌కు పూర్తిగా కొత్తవారు. బంతి ఉన్న ప్రతి అప్లికేషన్‌లో పని చేస్తున్నప్పుడు వారు చాలా అనవసరమైన దశలను చేయవలసి వచ్చింది. నా ఇతర తప్పులను నవ్వుతూ గుర్తు చేసుకుంటే, ఈ రోజు కూడా నాకు చెమటలు పట్టేలా చేస్తుంది.
నేను చివరకు ఈ బగ్‌ని పదేళ్ల తర్వాత ఇటీవలే పరిష్కరించాను. "పాచ్డ్", "ఫిక్స్డ్" కాదు, ఎందుకంటే జాషువా బ్లాచ్ చెప్పినట్లుగా, APIలు శాశ్వతమైనవి. ఇప్పటికే ఉన్న ప్రోగ్రామ్‌లను ప్రభావితం చేసే మార్పులను చేయడం సాధ్యపడలేదు, మేము OriginAtCenter ఆస్తిని పాత ప్రోగ్రామ్‌లలో తప్పు విలువతో మరియు భవిష్యత్తులోని అన్నింటిలో నిజమైన విలువతో జోడించాము. వినియోగదారులు తార్కిక ప్రశ్నను అడగవచ్చు: ప్రారంభ బిందువును మధ్యలో కాకుండా వేరే చోట ఉంచాలని ఎవరు భావించారు. ఎవరికి? పదేళ్ల క్రితం సాధారణ APIని సృష్టించడానికి చాలా సోమరిగా ఉన్న ఒక ప్రోగ్రామర్‌కు.
నేర్చుకున్న పాఠాలు
API లలో పని చేస్తున్నప్పుడు (దాదాపు ప్రతి ప్రోగ్రామర్ కొన్నిసార్లు చేయవలసి ఉంటుంది), మీరు జాషువా బ్లాచ్ యొక్క వీడియోలో పేర్కొన్న ఉత్తమ సలహాలను అనుసరించాలి ""లేదా :
- API మీకు గొప్ప ప్రయోజనం మరియు గొప్ప హాని రెండింటినీ తీసుకురాగలదు.. మంచి API రిపీట్ కస్టమర్‌లను సృష్టిస్తుంది. చెడ్డది మీ శాశ్వతమైన పీడకల అవుతుంది.
- పబ్లిక్ APIలు, వజ్రాల వంటివి శాశ్వతంగా ఉంటాయి. మీ అన్నింటినీ ఇవ్వండి: ప్రతిదీ సరిగ్గా చేయడానికి మరొక అవకాశం ఉండదు.
- API రూపురేఖలు క్లుప్తంగా ఉండాలి — తరగతి మరియు పద్ధతి సంతకాలు మరియు వివరణలతో ఒక పేజీ, ఒక లైన్ కంటే ఎక్కువ తీసుకోదు. ఇది మొదటిసారిగా పరిపూర్ణంగా మారకపోతే APIని సులభంగా పునర్నిర్మించడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది.
- వినియోగ సందర్భాలను వివరించండిAPIని అమలు చేయడానికి లేదా దాని స్పెసిఫికేషన్‌పై పని చేయడానికి ముందు. ఈ విధంగా మీరు పూర్తిగా పని చేయని APIని అమలు చేయడం మరియు పేర్కొనడం నివారించవచ్చు.
నేను కృత్రిమ స్క్రిప్ట్‌తో చిన్న సారాంశాన్ని అయినా వ్రాసి ఉంటే, చాలా మటుకు నేను లోపాన్ని గుర్తించి సరిదిద్దాను. కాకపోతే, నా సహోద్యోగులలో ఒకరు ఖచ్చితంగా దీన్ని చేస్తారు. సుదూర పరిణామాలను కలిగి ఉన్న ఏదైనా నిర్ణయం కనీసం ఒక రోజు ఆలోచించాల్సిన అవసరం ఉంది (ఇది ప్రోగ్రామింగ్‌కు మాత్రమే వర్తిస్తుంది).
రిచర్డ్ గాబ్రియేల్ యొక్క వ్యాసం యొక్క శీర్షిక, "వర్స్ ఈజ్ బెటర్" అనేది మార్కెట్‌లో మొదటిగా ఉండటం-అసంపూర్ణ ఉత్పత్తితో కూడా-ఎవరైనా పరిపూర్ణమైనదాన్ని వెంబడిస్తూ శాశ్వతత్వం గడిపే ప్రయోజనాన్ని సూచిస్తుంది. స్ప్రైట్ కోడ్‌ను ప్రతిబింబిస్తూ, దాన్ని సరిగ్గా పొందడానికి నేను ఎక్కువ కోడ్‌ని వ్రాయవలసిన అవసరం లేదని నేను గ్రహించాను. ఎవరెన్ని చెప్పినా, నేను చాలా పొరబడ్డాను.
తీర్మానం
ప్రోగ్రామర్లు ప్రతిరోజూ తప్పులు చేస్తుంటారు, అది బగ్గీ కోడ్‌ను వ్రాయడం లేదా వారి నైపుణ్యం మరియు ఉత్పాదకతను మెరుగుపరిచేదాన్ని ప్రయత్నించకూడదనుకోవడం. వాస్తవానికి, నేను చేసినంత తీవ్రమైన తప్పులు చేయకుండా మీరు ప్రోగ్రామర్ కావచ్చు. కానీ మీ తప్పులను గుర్తించకుండా మరియు వాటి నుండి నేర్చుకోకుండా మంచి ప్రోగ్రామర్‌గా మారడం అసాధ్యం.
నేను చాలా తప్పులు చేసినట్లు భావించే విద్యార్థులను నిరంతరం ఎదుర్కొంటాను మరియు అందువల్ల ప్రోగ్రామింగ్‌కు దూరంగా ఉండకూడదు. ITలో ఇంపోస్టర్ సిండ్రోమ్ ఎంత సాధారణమో నాకు తెలుసు. నేను జాబితా చేసిన పాఠాలను మీరు నేర్చుకుంటారని నేను ఆశిస్తున్నాను - కాని ప్రధానమైనది గుర్తుంచుకోండి: మనలో ప్రతి ఒక్కరూ తప్పులు చేస్తారు - ఇబ్బందికరమైనది, ఫన్నీ, భయంకరమైనది. భవిష్యత్తులో కథనాన్ని కొనసాగించడానికి నా దగ్గర తగినంత మెటీరియల్ లేకపోతే నేను ఆశ్చర్యపోతాను మరియు కలత చెందుతాను.
మూలం: www.habr.com