Jag har varit i din situation flera gånger än jag bryr mig om att komma ihåg. Jag fick mitt första IT-relaterade jobb 1984 och jag har gått sedan dess. I många jobb jag har haft har jag arbetat med människor som var mer intresserade av att "få det gjort" utan att tänka på framtida påverkan eller övergripande design. Jag har arbetat med människor som helt enkelt nöjde sig med att göra så lite som möjligt och gillade att få betalt på en nivå som speglade marknaden snarare än deras bidrag. Jag har också arbetat med människor som brinner för det arbete de gör och som vill tillhandahålla service och produkter av hög kvalitet. Jag har arbetat med människor som kan ha varit socialt utmanade, men deras glans återspeglas i deras arbetsetik och känsla av äganderätt till sina uppgifter och uppdrag.

I alla de situationer jag har nämnt är den röda tråden är att jag kunde lära mig något av dem alla, oavsett hur till synes obetydligt eller filosofiskt förändrande det var vid den tiden. Dina kollegor kommer att drivas av olika mål. Vissa behöver helt enkelt förse sig själva och / eller sin familj med säkerhet. Vissa behöver de pengar som IT-proffs har för att mata sina materiella behov och önskan om status. Vissa skulle göra jobbet för hälften av vad de får, bara för den personliga tillfredsställelsen att göra ett bra jobb. I vilket fall som helst kan ditt bästa tillvägagångssätt när du arbetar med dina kollegor vara att helt enkelt acceptera att människorna runt kanske inte styrs av samma enheter som du. Det gör dem inte mindre värda din respekt och stöd, för de är dina lagkamrater.

Med detta sagt, precis som du borde acceptera dem för vad du uppfattar som deras brister, bör de också acceptera dig för vad de tror att är dina brister. Du måste vara trogen mot dig själv och vad som driver dig. Om du vill att saker och ting ska vara på ett visst sätt i dina projekt bör du kunna göra vad du tror är bäst. Du kan inte förvänta dig att de använder ditt tillvägagångssätt, men du kan komma med förslag. Om de väljer att inte genomföra dina idéer, så var det. Känn dig inte avvisad eller försvagad, för så länge du följer det tillvägagångssätt som passar dig kommer ditt arbete att göras. Med tiden kan du förvärva några konverterare och du kan se några implementeringsstrategier de använder som du vill anta. Alla kan lära av varandra. Utmaningen är att ta bort antagandet att eftersom den här personen inte gör det som jag gör det gör han / hon det på fel sätt.

Jag tror att det finns flera saker du kan göra för att hålla dig motiverad.

1. Först bör du inse att du inte är ensam. Titta runt i det här forumet. Det finns faktiskt många frågor som liknar din, även om de flesta är mindre direkta. Jag har faktiskt haft erfarenhet av att bli anställd eftersom jag visste bästa praxis men inte fick implementera bästa praxis alls alls.
   Jag tror att det är lätt att skapa en världsbild där du föreställer dig din uppfattning om excellens är viktigt för alla. När allt kommer omkring lär du dig vissa saker som bästa praxis och de bloggare du ser upp för att ta dessa idéer som lästa. Men den världen är osynlig för många "genomsnittliga" utvecklare, och även de som känner till den kanske inte känner att den är lika viktig som du. Att bara veta att du inte är galen, att andra människor stöter på tegelväggar när de vill implementera alla dessa bra saker hjälper dig att behålla ditt förnuft.
   Detta är inte att säga att du ska förlora din enhet: don 't. Min helt färdiga uppskattning är att kanske 25% av utvecklarna verkligen har det. Så småningom hittar du en plats i livet där enheten fungerar för dig snarare än att frustrera dig, och när du gör det kommer det att vara givande på ett sätt som 75% av utvecklarna kanske inte kommer att uppleva (detta kan eller kanske inte är ekonomiska fördelar).

2. Håll dig positiv . Det faktum att du skickade frågan indikerar att du vet att det finns en risk att bli fast i negativa tankar när din frustration äter bort dig. Om du tycker att detta händer, hitta sätt att vända dina tankar till positiva saker. Gå en promenad eller lyssna på glad musik medan du arbetar. Gräva dig verkligen vad du gör och blockera de saker som andra gör som frustrerar dig.
   En sak som hjälper dig att hålla dig positiv är att undvika att tillskriva andra motiv. Allt du vet är att dina frustrerande medarbetare inte vill ha det du vill ha dem. Låt dem oroa sig för varför. Sluta tänka även om de är omotiverade. De kan vara väldigt motiverade, men på sätt som du inte bryr dig om.

3. Tänk på frågan från andra perspektiv . En sak som min chef ofta berättar för mig är att han inte ens bryr sig om det är snabbare att göra saker på ett eller annat sätt. Vad han verkligen vill är att ha en riktigt bra uppfattning om exakt hur lång tid något tar. Om du alltid gör något på samma sätt uppfyller det det målet för de flesta.
   Att titta på den andra sidan av sakerna, försöka med ett helt annat tillvägagångssätt, även om det är bättre praxis, medför en betydande risk att du kanske inte hålla tidplan. Ur det perspektivet är det faktiskt lite oetiskt att pröva andra metoder än de beprövade - du gör något för din egen psykiska hälsa som kanske inte är bra för företagets hälsa.
   Många utvecklare och chefer gör det inte inse att bra kod faktiskt gör det möjligt att göra mer tillförlitliga uppskattningar. Eftersom du bara är två år ute i skolan, överväga möjligheten att du ännu inte är redo att skriva den typen av kod och låta dig spendera tiden på att lära dig att det kan få företaget att missa några viktiga deadlines, även om det är bra åt dig.

4. Arbeta för förändring . Lägg lite hud i spelet och ta lite av din personliga tid att sätta ihop en demo av de tekniker som du tycker ska placeras på plats. När du gör din tonhöjd, var försiktig så att du inte säger något som låter som en kritik av någon person, och försök att undvika att säga "den här tekniken är dålig." Säg istället "Jag tror att om vi gjorde X skulle det spara 30% eller mer av den tid vi tar för att göra uppgift Y jämfört med vad vi gör nu." Håll dig till den här icke-kritiska, icke-anklagande strategin även om du får ledande frågor som "Men jag trodde att vi redan använde bästa praxis. Varför gör vi inte det här?" Jag följde den här strategin och slutade med att få grönt ljus för att skriva om hela vår kodbas.
   Genom att göra detta kan du kanske lägga tillräckligt med en prototyp där ute för att visa det, bara för att du inte är den mest erfaren medlem av laget, betyder inte att du inte kan skriva solid kod. Och du kan lära dig tillräckligt av detta att även om du blir sagt "nej" kan du bättre skriva den typen av kod i framtiden (på det här jobbet eller ett annat).
   Du kanske får veta "nej, "men folk kommer ihåg att du tog ställning. Det kan röra nålen lite, eftersom du sa att inte alla är omotiverade. Om du verkligen tror att detta är det bästa sättet att göra saker, låt det inte gå, men var klok i hur du trycker på frågan. När jag till exempel kom tillbaka från semestern och jag blev ombedd att göra en ändring som jag inte kunde göra eftersom webbplatsen hade ändrats på ett sätt som jag inte hade något sätt att veta om, påpekade jag min chef att om webbplatsen hade varit under versionskontroll kunde jag ha tittat i loggen och bara sett vad som hände. Men jag skulle inte ha gjort den kommentaren framför andra anställda. Dessa typer av kommentarer kan verka snarky, så använd dem sparsamt och bara i en-mot-en-konversation. Oddsen någon tror att de är snarkiga ökar exponentiellt baserat på publikens storlek.

5. Bygg support . Odla medvetet dina "erfarna och riktigt smarta" kollegor. Gå till lunch tillsammans och diskutera vad som stör dig (på ett positivt sätt som "Jag hade den här idén ..."). Om de vet vad du tycker och du vet vad de tycker är det mycket troligt att de naturligtvis kommer att ansluta sig till din röst eller vice versa när du är i möten. I själva verket bör du söka efter möjligheter att stödja alla som gör något som att erbjuda en idé om bästa praxis, oavsett om du tidigare visste att personen var intresserad av bästa praxis eller inte.
   När du har byggt en bra bas bland de likasinnade utvecklarna , se om du kan odla de du inte ser som motiverade. För det första kan de överraska dig. För en annan är de mindre benägna att blockera dig om du har en personlig vänskap.

6. Inse att det här jobbet inte är ditt liv, och kanske inte vara din framtid. Du är inte fast i det här jobbet, men medan du håller på med det, mjölk det för allt du kan när det gäller vad du kan lära dig. Kanske kommer de aldrig att uppskatta den eld du tar till jobbet. Det är ok - att lära sig att leva i ett jobb som inte "får" dig är en värdefull färdighet. Men när du väl känner att du är redo att sprida dina vingar, om du ser en bättre möjlighet, gå till den. Att tänka på jobbet som bara vad som händer "just nu" snarare än "hur det kommer att vara för evigt" kan förändra din attityd mycket.

7. Ge det tid . Jag hade en gång en chef (som var på väg att gå i pension) som sa till mig "Amy, du behöver inte bli så arg. Gör bara vad du gör och så småningom kommer människor att inse att du är rätt mycket. " Det tar tid att bygga upp cred, och team förändras inte över natten bara för att du påpekar att de borde. Ge dina idéer tid att sjunka in och fortsätta att plugga, och kanske med tiden kommer du att titta upp och inse att saker har förändrats mycket, till det bättre, på kortare tid än du var rädd för. Detta hände mig :).

När de fick ett problem skulle de välja det första tillgängliga alternativet eller så skulle de bara titta på en befintlig lösning och kopiera och klistra in densamma. Och sådana kollegor är faktiskt i högre positioner för mig.

........

Jag känner mig dålig (och också ledsen) när något görs på ett sätt när jag vet att det finns ett bättre sätt att göra detsamma

Dina kollegor kan vara i en högre position för dig eftersom de kan få saker gjorda snabbt och effektivt.

När du säger att det finns ett "bättre sätt", säger du att sättet det gjordes inte var elegant, inte "vackert" och att du hade ett slicker sätt att åstadkomma detsamma? Eller säger du att dina kollegor lägger ut farlig, osäker kod eller kod som kommer att vara väldigt svår att underhålla och skala?

Om det första är fallet, välkommen då till den verkliga världen. Företag vill att saker ska göras snabbt, eftersom tid är pengar .

Om du har att göra med den andra, låter det som om du befinner dig i ett hemskt företag med dålig ledning. Sug upp det, lär dig så mycket du kan och fortsätt sedan till en bättre möjlighet när du har chansen.

Jag har ingen aning om hur CS-grader fungerar var du kommer från, men enligt vad jag har sett har de väldigt lite att göra med en programvaruutvecklare. Academia är berömt skyddad från den verkliga världen.

Den svåra delen är att hitta en balans mellan ett ofattbart ideal och "det fungerar bara" -lösningen. Endera av ytterligheterna fungerar faktiskt - i vissa miljöer. Om du gör kontrakts slutanvändar grejer utan utsikter till underhåll är "bara att få det gjort" en giltig filosofi. När du skriver Shuttle-programvara har du mycket mer tid att polera.

När du försöker ändra inställningen hos människorna omkring dig, se till att du faktiskt är säker om fördelarna. Bygg upp proffsen och nackdelarna, uppskatta kostnaderna för "dåliga lösningar" och kostnaderna för "rätt kod" - varken är gratis. Om du har tur förstår människorna runt dig möjlighetskostnader - det gör det mycket lättare att gå mot bättre arkitektur, bättre kod. Om koden tar dubbelt så lång tid att skriva men är hälften så mycket arbete att underhålla och förlänga, vill du visa att den kostnaden faktiskt betalar tillbaka någon gång med rimlig säkerhet.

Kundnöjdhet är också en oerhört viktig faktor. Om valet är mellan bättre kod och bättre användarupplevelse vinner UX alltid, och det borde det. Återigen är den största tippfaktorn när bättre kod leder till bättre UX i framtiden - kommer effekterna av bättre kod att räcka för att göra det billigare i slutändan? Bra kod är ofta en investering, inte något värdefullt; sällan hittar du en möjlighet när bra kod ger bättre effektivitet på originaluppgiften (notera att jag pratar om "dålig" kod som produceras av bra programmerare - om dina programmerare helt enkelt är dåliga och slarviga, har lite tur); återbetalningen kommer vanligtvis längre ner på vägen, om alls.

Människor har problem med att tänka på investeringar. Få några siffror. Det kan vara till stor hjälp om du faktiskt kan samla in data från det förflutna - när du föreslår ändring av arkitektonisk eller kodkvalitet, skriv ner den. När tiden kommer och ditt förslag skulle spara tid eller förbättra kundnöjdheten - skriv ner det. När du har tillräckligt, gå till dina chefer, seniorer, vem som helst - det är lättare att diskutera när du har "hårda" data i dina händer.

Det motsatta gäller också. anta inte att "bättre" kod är automatiskt bättre. Jag har sett många fall där programmerarna förlorade alldeles för mycket tid på att utarbeta saker som inte spelade någon roll - på en testapplikation som bara fanns i ett scenario och kastades bort, och på annat håll skapade en arkitektur som var alltför komplicerad och i slut hämmas vidare utveckling.

Perfekt är sällan bra. Om din eftersläpning inte är full av (mindre) buggar och funktionsförfrågningar som du helt enkelt inte har tid och resurser att fixa, gör du förmodligen något fel och din konkurrens vinner på dig.

Jag tänker vanligtvis i termer av tid eller pengar. Att översätta saker till pengar hjälper mycket i kostnads-nytta-beräkningar. Detta tog mig lite mer arbete, och jag fick lite erfarenhet av det. Hur mycket skulle jag betala för den kunskapen, var det värt det? Det sparar lite tid på vägen - räcker det? Vad blir kostnaden om jag inte gör det på det sättet och det visar sig vara ett dåligt beslut på vägen? Det är viktigt att veta hur mycket tid som spenderades på att fixa buggar på den ursprungliga uppgiften, annars blir uppfattningen extremt skev. Om något tog mig 4 timmar, precis som uppskattat, men då tillbringade jag 20 timmar på att fixa buggarna, måste det vara synligt att min uppskattning var långt borta.

Det tar mycket att driva om du är "den enda". Men det kan göras, du kan gå till bättre praxis, bättre kod, bättre programvara. Se bara till att det till slut är faktiskt bättre på något mätbart sätt.