Как да бъдем успешен софтуерен инженер

За младите, със светли очи софтуерни инженери, които започват кариерата си, ето някои от най-добрите съвети, които съм чел или получил като софтуерен инженер.

Повечето от съветите тук обслужват тълпата от софтуерното инженерство, но вярвам, че има много съвети, които са приложими, независимо от професията ви.

Най-добри кариерни и житейски съвети, които получих

Накратко, най-добрият ми съвет е:

  • Подценяване, прекаляване
  • Перфектният е враг на доброто
  • Стойте на пътека
  • Съберете обратна връзка рано
  • Потърсете, преди да поискате
  • Оптимизирайте за простота

Ако предпочитате да гледате това във видео формат, направих тук видео в Youtube:

Подценяване, свръхпостигане

Подценяването на количеството работа, необходимо за изпълнение на дадена характеристика, е изключително често срещана грешка сред новите и дори опитни инженери.

Ако погледнете броя на проектите, които са свръхбюджетни и / или доставени късно, ще бъдете много изненадани. Това е лудо число, нещо в размер на 50%.

Нека да вземем предвид това за секунда: 50% от всички проекти са или свръхбюджет, или се доставят късно.

Това означава, че на всеки 1000 проекта 500 или половина от тях се доставят късно или над прогнозния бюджет. Това просто ме смущава.

Спомням си ясно по време на първия си технологичен проект, че ми беше предоставена автономията да ръководя развитието на функцията. Това означаваше, че аз съм водещият човек, който ще напише документ за технически дизайн, в който подробно се описва колко време ще отнеме за разработването на цялата функция, колко инженери ще ни трябват и т.н.

Като нетърпелив, млад инженер, какъвто бях, подцених грубо времето, необходимо за свършване на нещата. Нещо в тон 2–3x.

Бях доста разочарован от себе си по това време и в резултат на това имах обтегнати отношения и с някои от моите колеги.

След това мениджърът ми ме настани и ми даде някои промени, които променят живота. Каза ми, винаги подценявам и прекалявам.

Това означава, че трябва да сте консервативни в своите оценки, да осигурите достатъчен буфер, за да може вашите оценки да се объркат различни неща (защото всичко, което може да се обърка, ще бъде) и се стремите да реализирате вашия проект преди време / под цената.

Ползите:

  1. Дава ви достатъчно време за разработване и рефакториране според нуждите. Развитието на функции винаги е подходящ момент да се върнете назад и да оправите част от техническия дълг, който (или екипът преди вас) е натрупал през годините.
  2. Дава време да измисли най-добрия дизайн, а не само работещ дизайн.
  3. Има много неща, които могат да се объркат по време на разработване на функции. Сътрудник отива в отпуск, вие се разболявате, срещи, детето ви се разболява, колата ви се удря и списъкът продължава. Важно е да разберете, че нещата могат да се объркат и искате да се уверите, че имате буфер в графика си.
  4. Като сте в състояние да произвеждате висококачествена работа последователно в резултат на №2 и да можете да я доставяте навреме всеки път в резултат на # 3, сега сте разпознат като високопроизводител в компанията, който знае какво говорим и може да се разчита. Печеливша!

Може да спорите, че недостатъкът на недостатъчно обещаващите е, че другите ще мислят, че сте мързеливи, като прецените 10-седмична работа за нещо, което може да се направи за 2 седмици.

За да бъда честен, и аз се борих с това известно време. Тогава обаче разбрах, че стига да общувате открито и да бъдете последователни със заинтересованите страни по време на целия процес, ще бъдете добре.

Вие сте човекът, който отговаря за осигуряването на разходите, защото другите разчитат на вашия опит. Те знаят, че вие ​​сте най-съкровената с кодовата база и ви вярват да осигурите най-доброто предположение. По време на разработването на функции могат да се случват различни неща и докато открито общувате, всичко ще е наред.

Перфектният е враг на доброто

Като софтуерен инженер сте склонни да откриете, че на проекта липсва това или има нужда от това, преди да може да излезе през вратата. Един проект може да бъде проект за кодиране или просто документ за технически дизайн, който трябва да напишете.

Това, което често се случва, е, че когато задълбавате по-задълбочено в проекта, започвате да установявате, че има още неща, които не сте взели предвид. След това запретвайте ръкави и задавате мерника, за да стигнете до дъното на нещата. Решихте да прекарате следващите няколко часа в проучване и се опитвате да разгънете всичко.

След десет часа всъщност нищо не се прави и трупате повече работа от преди.

Ако това ви звучи познато, значи не сте сами.

Това се случва на всички - и това се случва на най-добрите от нас. Вярвам, че от млада възраст сме били обусловени да произвеждаме работа, която е „перфектна“ или „пълна“. В действителност обаче няма такова нещо като перфектно решение.

Живеем в свят на ограничения и има компромис за всяко важно решение, което вземем.

Ключът тук е да признаем, че не знаем всичко. Може да не го осъзнаете, но зад повечето решения, които вземате, има безброй алтернативи.

Например, като специалност информатика, какво трябва да направите за първа работа извън колежа? Освен да работите за стартъп или голяма технологична компания, бихте могли да работите и в чужбина като фрийлансър, да стартирате Youtube канал, да преподавате компютърни науки на Udemy, да стартирате блог или да стартирате собствена компания. Списъкът с опции е неограничен и решението, което ще вземете днес, ще се основава на няколко ключови критерия.

В крайна сметка ще вземете решение, което е най-доброто за вас, а не непременно и обективно най-доброто, защото всеки е уникален и няма нито един размер за всички.

Най-доброто, което можем да направим в такава ситуация, е да съберем възможно най-много информация, да признаем рисковете в това, което не знаем, и да вземем най-доброто решение оттам.

Вероятности за неуспех

Начинът, по който мисля за това е, че определям вероятност за най-лошия сценарий и го използвам за процеса на вземане на решения. Това е нещо, което научих от книга, наречена Принципи от Рей Далио, която е страхотна книга, която горещо препоръчвам.

Ако вероятността нещо да се обърка ужасно да е статистически значимо, аз или:

  1. Потърсете по-добро решение или
  2. Намерете начини за намаляване на рисковете, така че те вече да не са статистически значими.

След като бъде взето решение, след това го изпълнявам и продължавам.

Изплакнете и повторете за всеки проблем, който срещна. Намирам радост при решаването на тези проблеми и по някакъв начин радостта на живота е в решаването на проблеми с различна величина и сложност.

Ако искате да научите повече за наемането на работа като софтуерен инженер, аз преподавам малък клас, който се фокусира върху участието в техническото интервю. Можете да научите повече за това тук или на моя уебсайт: zhiachong.com

Рамка за вземане на решения

Останете на пътя

Изпълзяването на характеристиките е това, което естествено идва на ум като противоположен пример.

Продължавате да искате да добавите още функции, защото смятате, че настоящият изглежда така, сякаш е изтеглен от световната мрежа на 90-те. Чувствате, че не е готов. Мислите, че никой никога не би искал да използва вашия продукт.

Имайте предвид обаче, че всички тези неща се случват в собствената ви глава. Нищо от това не е валидирано. Не знаеш какво искат хората, докато не им сложиш нещо в ръцете.

Това, към което трябва да се стремите, е да си поставите фиксирана цел в началото на вашия проект и да се стремите да го постигнете, независимо какво.

Ползите са двойни:

  1. Това намалява пълзенето на функции и ви принуждава да се съсредоточите. По този начин са написани обеми книги и няма да ви отегчавам с конкретните подробности. Оставането на лазерния фокус е от решаващо значение, независимо от вашата позиция.
  2. Ние, хората, обичаме моменталното удовлетворение. Ако можете да пуснете нещо за 2 седмици, тогава го направете! Планирайте предварително това, което вашият проект трябва да може да постигне за 2 седмици, и след това го поставете в ръцете на вашите потребители! Това е много удовлетворяващо чувство и дори да се провали мизерно, поне сте се придържали към целта си и сега сте събрали ценна обратна връзка, за да повторите.

Това ме отвежда до следващата ми точка.

Съберете обратна връзка рано

Аз лично смятам, че винаги трябва да се стремим да пускаме рано, да пускаме често и да събираме отзиви възможно най-скоро.

Разбира се, признавам, че това е възможно предимно за софтуерни проекти. Но ме чуйте.

Пускането често и освобождаването рано ви позволява да събирате отзиви рано. Наличието на здравословна верига за обратна връзка е много важен, ако не и най-важният аспект на вашия проект.

Примката за обратна връзка за продукта

Трябва да включите цикъл за обратна връзка в началото на разработката на вашия продукт, така че да знаете, че разработвате правилния продукт за точните хора с правилните ограничения.

Също толкова важно е да се отбележи, че пускането на пазара рано не означава освобождаване на счупен продукт. Счупен продукт никога не е полезен за никого и това е просто неуважение към вашите потребители.

Трябва да измислите и да доставите продукт с минимална жизнеспособност (MVP), което означава най-малкият начин, по който вашият продукт трябва да проработи, за да задоволи нужда.

Едно нещо трябва да се отбележи, че събирането на обратна информация не означава, че трябва да е обратна връзка от всеки един потребител.

Помислете за сегментиране на вашите потребители. Вземете малък набор от потребители, в идеалния случай от различни среди (и не само приятели и семейство). Вземете продукта си в ръце, така че ако объркате, поне другите ви потребители все още не са го осъзнали и ще имате време да го поправите.

Потърсете, преди да поискате

Много по-млади инженери са склонни да задават въпроси, без да се опитват сами да намерят отговорите. Когато се натъкнат на нещо, с което не са се срещали преди, първият им инстинкт е да попитат старши инженер как е направено и как да постигнат нещо.

Ще ви помогне много да потърсите отговора сами, преди да попитате някого. Причината е двукратна:

  1. Гмуркането в дълбочина ви позволява да изследвате области, които може би никога не сте изследвали преди. Дава ви възможност да придобиете експозиция и да сте запознати с различна база от кодове.
  2. Докато се премествате на по-висока позиция, хората разчитат на вас за насоки. С течение на времето ще станете старши в групата. Хората отиват при вас за помощ и все пак ще трябва да научите това умение по-късно.

Много разработчици се шегуват, че по-голямата част от времето им се отделя на Googling и StackOverflow. Напълно съм съгласен с това, но не по причини, които може да мислите.

Способността да се намерят отговори на двусмислен проблем е силно желано умение. Интернет се е превърнал във времето в леснодостъпна съкровищница от информация, която можете да включите по всяко време, навсякъде и на всяко устройство.

И все пак, способността да се задават правилните въпроси е много по-трудно да се придобие от възможността да се отговори на тях.

С напредването на професионалната си кариера ще започнете да осъзнавате, че измислянето на правилните въпроси ще бъде умение, което трябва да научите, и ако го овладеете, това ще ви направи чудеса.

Оптимизирайте за простота

Стремете се към простотата в работата си и в живота си.

Често пъти виждам, че младши разработчици работят по проект за кодиране и те ще използват абстракция, наследяване, интерфейси и някои много интересни рамки. Въпреки всичко, въпреки цялата тази фантазия, те пишат нов код, който добавя повече усложнения, отколкото е необходимо.

Хората, които поддържат този код, няма да са същите хора, които го пишат, през повечето време. Всеки допълнителен сложен слой, добавен върху, ще направи много по-трудно да се включат новите инженери.

Когато зреете като софтуерен инженер, осъзнавате, че писането на код не е въпрос само на оптимизиране на производителността, но и на оптимизиране за хората. Също толкова важно е да напишете код, за който другите могат лесно да разсъждават.

Това е мястото, където кода четливост и организация на кода влизат в игра.

Освен ако представянето не е истинска грижа, винаги избирайте по-простия и по-чист подход.

Вярвам, че простотата се простира и до живота извън работата. Пазете живота си от разсейвания. Намалете броя на ненужните вещи, които имате в живота си. Съсредоточете се върху важните за вас неща. Оптимизирайте живота си за преживявания, а не за притежание. Това са някои от нещата, които трябва да имате предвид, докато се движите през живота.

Книги, които съм чел, и ресурси, които ми харесаха

  • Принципи на Рей Далио - Една от най-добрите книги, които съм чел от известно време. Авторът говори за принципи, които можем да приложим както в живота, така и в работата. Включих неговата рамка за решаване на проблеми в ежедневието ми
  • DailyCodingProblem: Това е услуга, която изпраща ежедневни проблеми с кодирането на имейла ви и има някои от най-новите въпроси от най-високотехнологичните компании. Използвайте моя код на купон, zhiachong, за да получите 10 $ отстъпка!
  • Как да спечелите приятели и да повлияете на хората - Класическа книга за изграждане и управление на отношенията с хората . Тази книга ми помогна да разбера как да управлявам връзките си на работното място.
  • Старшият софтуерен инженер - Страхотна книга с артикули за това как да узреят като софтуерен инженер. Тук научих как да търся, преди да поискате.
  • Ключови разговори - Страхотна книга за това как да се справяме с хората в ситуация с високи залози. Много приложим в различни аспекти на живота. Независимо дали преговаря за по-високо заплащане или решава проблемите на комуникацията със съпруга си , тази книга има някои добри съвети за решаването на тези проблеми.
  • Lean Startup - добра книга за това как да използвате минимално жизнеспособен продукт (MVP), за да тествате идея, преди да инвестирате допълнително. Използвах това, за да тествам няколко стартиращи идеи в миналото.
  • Purple Cow - Обичах тази книга. Главно използвах това за тестване на различни стартиращи идеи, които имам предвид. Тя говори за това как да пускате на пазара вашия стартъп и какво го отличава от останалите.
  • Evernote - Най-доброто приложение за водене на бележки Аз някога съм използвал. Горещо препоръчвам!
  • Молескин тефтер - наистина ми харесва този. Качеството на него е изключително високо. Цената е малко по-висока, но тъй като я използвам ежедневно, считам за добра инвестиция. Държането на красива тетрадка в ръцете ми всеки ден ме прави по-развълнуван да пиша повече бележки.
  • Pilot G2 (черен) - лесно най-добрите химикалки, които съм използвал, и само химикалки, които ще използвам. Купувам ги на едро от Amazon и ги държа навсякъде, където отида. Имам една в раницата си, една в офиса и една в домашния си офис, така че винаги да имам химикалка наоколо. Пише чудесно, мастилото тече гладко и аз просто обичам усещането да пиша в него. В съчетание с Moleskin, понякога просто искам да вдигна G2, за да записвам случайни неща там, защото тези две са толкова перфектни заедно.

Следвайте ме в Twitter, Facebook и LinkedIn. Регистрирайте се за моя пощенски списък, където редовно изпращам съвети, трикове и познания в бранша.

Ако ви хареса тази статия, коментирайте по-долу: какъв е вашият №1 най-добрият съвет за софтуерен инженер?