Hogyan lehet sikeres szoftvermérnök?

Azoknak a fiatal, világos szemű szoftvermérnököknek, akik pályafutása kezdődik, az alábbiakban bemutatjuk a legjobb tippeket, amelyeket szoftvermérnökként elolvastam vagy kaptam.

Az itt található tanácsok többsége a szoftverfejlesztő tömeg számára szól, de azt hiszem, hogy sok olyan tanács van, amelyek alkalmazandók, függetlenül a foglalkozásuktól.

A legjobb karrier- és életviteli tanácsot kaptam

Röviden: a legjobb tanácsom:

  • Alulprofit, túlteljesítő
  • A tökéletes a jó ellensége
  • Maradjon egy úton
  • Korán gyűjtsön visszajelzést
  • Keressen, mielőtt feltenné
  • Optimalizálja az egyszerűség kedvéért

Ha inkább ezt videofájl formátumban szeretné megnézni, itt készítettem egy Youtube-videót:

Alulprofit, túlteljesítő

A szolgáltatás megvalósításához szükséges munka alulbecsülése rendkívül gyakori hiba az új, sőt a tapasztalt mérnökök körében.

Ha megvizsgálja a túlzott költségvetéssel és / vagy későn teljesített projektek számát, nagyon meg fog lepődni. Ez egy őrült szám, valami az 50% -ának.

Tekintsük egy pillanatra: az összes projekt 50% -a túl költségvetésben van, vagy későn szállítják be.

Ez azt jelenti, hogy minden 1000 projekt közül 500-at, vagy a feleket későn vagy a becsült költségvetés meghaladásával teljesítenek. Csak zavar engem.

Kifejezetten emlékszem rá, hogy első tech-projektem során autonómiát kaptam a szolgáltatás fejlesztésének vezetésére. Ez azt jelentette, hogy én vagyok az a fickó, aki elkészíti a műszaki tervdokumentumot, amelyben részletezi, mennyi időbe telik a teljes szolgáltatás fejlesztése, hány mérnökre lenne szükségünk, és így tovább.

Lelkes, fiatal mérnök voltam, és nagyon súlyosan alábecsültem a dolgok elkészítéséhez szükséges időt. Valami 2–3x hangzásra.

Abban az időben nagyon csalódott voltam magamban, és ennek eredményeként feszült kapcsolatok voltak néhány munkatársammal is.

A menedzserom ezután leült, és néhány életet megváltoztató tanácsot adott nekem. Azt mondta nekem, mindig alacsony áron és túlteljesítve.

Ez azt jelenti, hogy konzervatívnak kell lennie a becsléseivel, elegendő puffert kell adnia a becsléseihez, hogy különféle dolgok rosszul forduljanak el (mert bármi, ami rosszul fordulhat, megteheti), és arra törekednie kell, hogy a projektet időben előre meghozza / költség alatt.

Az előnyök:

  1. Bőséges időt ad a fejlesztéshez és a szükségleteknek megfelelő reflexióhoz. A szolgáltatásfejlesztés mindig megfelelő alkalom, hogy visszatérjen és javítson néhány technikai adósságot, amelyet Ön (vagy az előtte lévő csapat) felhalmozott az évek során.
  2. Lehetővé teszi az időt, hogy kitaláljuk a legjobb dizájnt, és nem csak a működő dizájnt.
  3. Sok olyan dolog fordulhat elő, amely a szolgáltatás fejlesztése során rosszul fordulhat. Egy munkatárs nyaralni megy, beteg lesz, találkozók, beteg lesz a gyerek, autóba sújt, és a lista folytatódik. Fontos felismerni, hogy a dolgok rosszul fordulhatnak elő, és ellenőrizni kell, hogy van-e puffer a menetrendben.
  4. Annak eredményeként, hogy a 2. számú eredmény következetesen kiváló minőségű munkát képes előállítani, és a 3. számú eredmény eredményeként minden időben képes-e időben kézbesíteni, ma már a vállalaton belül elismerten kiváló előadóművész vagy, aki ismeri beszél, és számíthat rá. Win-win!

Azt állíthatja, hogy az alul ígéretek hátránya, hogy mások azt gondolják, hogy lusta vagy, ha 10 hetes munkáját becsül egy olyan munkára, amelyet 2 hét alatt el lehetne végezni.

Hogy őszinte legyek, ezzel egy ideje küzdöttem is. Utána azonban rájöttem, hogy mindaddig, amíg nyíltan kommunikálsz, és folyamatosan összhangban maradsz az érdekeltekkel a folyamat során, rendben leszel.

Te vagy a felelős a költségek biztosításáért, mert mások az Ön szakértelmére támaszkodnak. Tudják, hogy te vagy a legkisebb a kódbázissal, és bíznak benne, hogy a legjobb kitalálást nyújtják. Különféle dolgok történhetnek a szolgáltatás fejlesztése során, és mindaddig, amíg nyíltan kommunikálsz, minden rendben lesz.

A tökéletes a jó ellensége

Mint szoftvermérnök, általában úgy találja, hogy egy projektnek hiányzik erre vagy szüksége van rá, mielőtt kimenne az ajtón. A projekt lehet kódolási projekt vagy csak technikai tervezési dokumentum, amelyet meg kell írnia.

Gyakran előfordul, hogy amikor mélyebben belemerül a projektbe, akkor észreveszi, hogy vannak olyan dolgok, amelyekről még nem számoltak el. Ezután tekerje fel az ujját, és beállítsa a látnivalót, hogy a dolgok végére kerüljön. Úgy döntött, hogy a következő néhány órát kutatással tölti, és mindent megpróbál becsomagolni.

Tíz óra alatt semmi sem történik meg, és több munkát halmoz fel, mint korábban.

Ha ez ismerősnek tűnik, akkor nem vagy egyedül.

Ez mindenkivel megtörténik - és a legjobbaknak is. Úgy gondolom, hogy fiatal kortól feltételeztük, hogy "tökéletes" vagy "teljes" munkát készítsünk. Valójában azonban nincs olyan tökéletes megoldás.

A kényszervilágban élünk, és minden fontos döntésünknek kompromisszummal kell számolnunk.

A kulcs itt annak felismerése, hogy nem tudunk mindent. Lehet, hogy nem veszi észre ezt, de a legtöbb döntése mögött rejtett alternatívák találhatók.

Például, mint számítástechnikai szakmérnök, mit kell tennie egy első munka után, amelyet a főiskolán kívül tölt be? Az induló vállalkozásoknál vagy a nagyvállalatoknál kívül külföldön is szabadúszóként dolgozhat, indíthat egy Youtube csatornát, taníthat számítástechnikát az Udemy-n, létrehozhat egy blogot vagy saját vállalkozást. Az opciók felsorolása korlátlan, és a ma meghozott döntése számos kulcsfontosságú kritérium alapján fog állni.

Végül olyan döntést hoz, amely a legmegfelelőbb, és nem feltétlenül objektíven a legjobb, mert mindenki egyedi, és nincs egy mindenki számára megfelelő.

A legjobb, amit egy ilyen helyzetben megtehetünk, az, hogy a lehető legtöbb információt gyűjtsük, elismerjük a kockázatokat abban, amit nem tudunk, és innen hozzuk a legjobb döntést.

A kudarc valószínűsége

Úgy gondolom, hogy a legrosszabb forgatókönyvhöz valószínűséget rendelök, és ezt használom a döntéshozatali folyamatom során. Ez valami, amit Ray Dalio elveknek nevezett könyvből tanultam, amely egy nagyszerű könyv, amelyet nagyon ajánlom.

Ha annak valószínűsége, hogy valami borzasztóan rosszul történik, statisztikailag szignifikáns, akkor vagy:

  1. Keressen jobb megoldást, vagy
  2. Keresse meg a kockázatok enyhítésének módjait úgy, hogy azok már statisztikailag nem szignifikánsak.

Miután döntés született, azt végrehajtom, és folytatom.

Öblítsük le, és ismételjük meg minden probléma esetén, amelyet felmerülök. Örülök annak, hogy ezeket a problémákat megoldom, és bizonyos értelemben az élet öröme a különféle nagyságrendű és összetettségű problémák megoldása.

Ha többet szeretne megtudni arról, hogyan lehet szoftvermérnökként betölteni egy állást, egy kis osztályt tanítok, amely a tech interjú megismerésére összpontosít. Többet megtudhat itt vagy a webhelyemről: zhiachong.com

Döntéshozatali keret

Maradjon az úton

A funkciók kúszása az, amely természetesen szembekerül ellentétes példaként.

Továbbra is szeretne további funkciókat hozzáadni, mert úgy érzi, hogy a jelenlegi úgy néz ki, mintha a 90-es évek internetes oldaláról töltötték le. Úgy érzi, hogy még nem kész. Úgy gondolja, hogy soha senki sem akarná használni az Ön termékét.

Vegye figyelembe azonban, hogy ezek a dolgok a fejedben zajlanak. Ennek egyike sem érvényesül. Nem tudod, mit akarnak az emberek, amíg valamit a kezükbe nem tettek.

Arra kell törekedned, hogy rögzítsen egy rögzített célt a projekt elején, és törekedjen arra, hogy bármit is elérjen.

Az előnyök kettős:

  1. Ez csökkenti a funkció kúszását és arra készteti a figyelmet. Erről sok könyvet írtunk, és a részleteket nem fogom megfizetni. A lézer-fókusz tartása kritikus, pozíciójától függetlenül.
  2. Mi, emberek, szeretjük az azonnali kielégítést. Ha 2 héten belül elenged valamit, akkor csináld! Tervezze meg előre, hogy mit érhet el a projekt két héten belül, majd helyezze el a felhasználók kezébe! Nagyon kielégítő érzés, és még ha szerencsétlenül is kudarcot vall, akkor legalább ragaszkodtál a céljához, és értékes visszajelzéseket gyűjtöttél, hogy folytathassa.

Ez a következő ponthoz vezet.

Korán gyűjtsön visszajelzést

Személy szerint úgy gondolom, hogy mindig törekednünk kell a korai felszabadításra, a felszabadításra, és a lehető leghamarabb visszajelzésre.

Természetesen felismerem, hogy ez elsősorban a szoftverprojektek esetében lehetséges. De hallgasd meg.

A gyakran kiadott és a korai elengedés lehetővé teszi a visszajelzés korai összegyűjtését. Az egészséges visszacsatolás biztosítása a projekt nagyon fontos, ha nem a legfontosabb szempontja.

A termék visszacsatolási ciklusa

A termékfejlesztés elején be kell építenie egy visszajelzési ciklust, hogy tudd, hogy a megfelelő terméket fejleszti ki a megfelelő emberek számára, a megfelelő korlátozásokkal.

Ugyanilyen fontos megjegyezni, hogy a korai kiadás nem azt jelenti, hogy egy törött terméket szabadon engednek. A meghibásodott termék soha senkinek nem hasznos, és ez csak tiszteletlenség a felhasználók számára.

Ki kell dolgoznia és ki kell szállítania egy minimálisan életképes terméket (MVP), ami azt jelenti, hogy a terméknek minimális módon kell megjelennie, hogy kielégítse egy igényt.

Egy dolog, amit meg kell jegyeznünk, hogy a visszajelzés gyűjtése nem azt jelenti, hogy minden felhasználótól visszajelzésnek kell lennie.

Fontolja meg a felhasználók szegmentálását. Szerezzen egy kis felhasználói csoportot, ideális esetben különböző háttérrel (és nem csak a barátokkal és a családdal). Vedd a kezedbe a terméket, hogy ha összezavarod, legalább a többi felhasználó még nem fogja rájött rá, és ideje lesz javítani.

Keressen, mielőtt feltenné

Sok fiatalabb mérnök hajlamos kérdéseket feltenni anélkül, hogy megpróbálta volna megkeresni a választ. Amikor belemerülnek olyan dolgokba, amelyekkel még soha nem találkoztak, az első ösztönük az, hogy megkérdezzék egy vezető mérnököt, hogy mi történt és hogyan lehet valamit végrehajtani.

Nagyon jó lesz, ha magadnak keresi a választ, mielőtt bárkit feltenne. Ennek oka kettős:

  1. A mély merülés lehetővé teszi, hogy felfedezze azokat a területeket, amelyeket még soha nem fedez fel. Ez lehetőséget ad arra, hogy expozíciót szerezzen, és megismerje egy másik kódbázist.
  2. Ahogy magasabb rangú pozícióra költözik, az emberek támaszkodnak rád útmutatásként. Idővel a csoport vezetője leszel. Az emberek segítségért fordulnak hozzád, és ezt a készséget később is meg kell tanulnia.

Sok fejlesztő viccelődik, hogy idejük nagy részét a Google-ra és a StackOverflow-ra fordítják. Teljes szívvel egyetértek ezzel, de nem okokból, amelyekre gondolhat.

Az a képesség, hogy egyértelmű problémákra válaszokat találjanak, nagyon áhított készség. Az Internet az idő múlásával könnyen hozzáférhető információgyűjtővé vált, amelyet bármikor, bárhonnan, bármilyen eszközre csatlakoztathat.

Ennek ellenére a helyes kérdések feltevésének képessége sokkal nehezebb megszerezni, mint a válaszadási képesség.

A szakmai pályafutása mentén rájössz, hogy a helyes kérdések kitalálása olyan készség, amelyet meg kell tanulnod, és ha ezt megtanulod, csodákat fogsz csinálni.

Optimalizálja az egyszerűség kedvéért

Törekedjen az egyszerűségre a munkájában és az életében.

Gyakran látom, hogy a junior fejlesztők egy kódolási projekten dolgoznak, és absztrakciót, öröklést, interfészeket és nagyon érdekes kereteket használnak. Mindezen fantázia ellenére új kódot írnak, amely a bonyolultabb, mint amennyire szükség van.

Az emberek, akik ezt a kódot fenntartják, általában nem ugyanazok lesznek, akik ezt írják. Bármilyen további bonyolultsági szint sokkal nehezebbé teszi az új mérnökök beépítését.

Amikor szoftvermérnökként érettél, rájössz, hogy a kódírás nemcsak a teljesítmény optimalizálása, hanem az emberek optimalizálása is. Ugyanolyan fontos, hogy olyan kódot írjon, amelyet mások könnyen megmagyarázhatnak.

A kódolvashatóság és a kódszervezés itt játszik szerepet.

Hacsak a teljesítmény nem jelent valódi aggodalmat, mindig válassza az egyszerűbb és tisztább megközelítést.

Úgy gondolom, hogy az egyszerűség kiterjed a munkán kívüli életre is. Óvja az életét a figyelmektől. Csökkentse az életedben lévő felesleges tárgyak számát. Összpontosítson az Ön számára fontos dolgokra. Optimalizálja az életét tapasztalatok, és nem vagyonai számára. Ez néhány szempont, amelyet szem előtt kell tartani, amikor az élet során mozog.

Az általam olvasott könyvek és az általam élvezett források

  • Ray Dalio alapelvei - Az egyik legjobb könyv, amit egy ideje elolvastam. A szerző olyan alapelvekről beszél, amelyeket alkalmazhatunk mind az életben, mind a munkában. Beépítettem a problémák megoldására szolgáló keretet a mindennapi életbe
  • DailyCodingProblem: Ez egy szolgáltatás, amely napi kódolási problémákat küld az Ön e-mailjére, és felteszi a legmagasabb szintű tech-társaságok kérdéseit. Használja a kuponkódomat, a zhiachong-ot, hogy 10 dollárt kapjon!
  • Hogyan nyerjünk barátokat és hogyan befolyásoljuk az embereket - Klasszikus könyv az emberekkel való kapcsolatok kiépítéséről és kezeléséről . Ez a könyv segített megérteni, hogyan kell kezelni a kapcsolataimat a munkahelyen.
  • Senior szoftvermérnök - Nagyszerű könyv cselekvési cikkekkel arról, hogyan érkezhet meg szoftvermérnökként. Itt tanultak meg, hogyan kell keresni, mielőtt megkérdezi.
  • Fontos beszélgetések - Kiváló könyv arról, hogyan kell kezelni az embereket magas tétben. Nagyon alkalmazható az élet különböző területein. Függetlenül attól, hogy magasabb fizetésért tárgyal, vagy kommunikál a házastárssal kapcsolatos kommunikációs kérdésekről , ez a könyv tartalmaz néhány jó tippet e problémák megoldására.
  • Lean Startup - Jó könyv arról, hogyan lehet egy minimálisan életképes terméket (MVP) felhasználni egy ötlet kipróbálására a további befektetés előtt. Ezt már a múltban számos indítási ötlet kipróbálására használtam.
  • Lila tehén - szerette ezt a könyvet. Elsősorban ezt a különböző indítási ötletek tesztelésére használtam, amelyekre gondolok. Arról szól, hogy miként lehet piacra dobni az indulást, és mi teszi különlegessé a többi elemet.
  • Evernote - A legjobb jegyzetelő alkalmazás ever Soha használtam. Nagyon ajánlom!
  • Moleskin notebook - ezt nagyon élvezem. Minősége rendkívül magas. Az ár kissé magasabb, de mivel naponta használom, jó befektetésnek tartom. Ha minden nap egy szép notebookot tart a kezemben, izgatottabb lesz, hogy további jegyzeteket írjak.
  • Pilot G2 (fekete) - Könnyen a legjobb tollak, melyeket valaha használtam, és csak azok a tollak, amelyeket használok. Ömlesztve vásárolom őket az Amazon-tól, és bárhol is tartom őket. Van egy a hátizsákban, egy irodában és egy otthoni irodámban, így mindig van egy toll körül. Nagyon jól ír, a tinta simán folyik, és én csak imádom a benne lévő írás érzését. A Moleskin-kel együtt néha csak azt akarom, hogy felvegye a G2-et, hogy véletlenszerű dolgokat készítsen rajta, mert ezek a kettő annyira tökéletes.

Kövessen engem a Twitteren, a Facebookon és a LinkedIn-en. Iratkozzon fel a levelezőlistámra, ahol rendszeresen tippeket, trükköket és ipari ismereteket küldök.

Ha élvezte ezt a cikket, kommentálja az alábbiakat: mi a legjobb tanácsadója a szoftvermérnöknek?