Я плохой разработчик, я не люблю программировать, не читаю про новые фреймворки за завтраком, не разрабатываю пет проекты и не контрибьючу в опенсорс. Уже пять лет я притворяюсь Python разработчиком. Чтобы придать моим словам немного веса, я опишу свой карьерный путь. Я закончил бакалавриат в провинциальном университете по направлению Информационные Системы и Технологии, год работал айти специалистом в местном рекламном агентстве, полтора года младшим python разработчиком в финтех компании, год экспериментировал с фрилансом, два года работал в отделе автоматизации в компании по разработке мобильных игр. Прошел курс яндекс практикума Middle Python Developer. Сейчас я EngD trainee в техническом университете в Нидерландах. Ниже описаны несколько принципов, которым я следовал и которым я бы хотел, чтобы следовали мои коллеги с которыми я работал за это время.
Выучи английский
Английский язык дает тебе огромные преимущества на пути развития разработчика. Знание языка открывает тебе доступ к документации, туториалам, обучающим видео, курсам и даже вопросам на stack overflow. С английским b2 и выше можно подаваться на более интересные вакансии внутри СНГ, работать с иностранными заказчиками на фрилансе и подаваться на вакансии за рубежом.
Подготовься к собеседованию
Перед тем как стать разработчиком, нужно успешно пройти собеседование и получить работу. Если собеседующий - гордый разработчик, который горит своей профессией, то ожидания у него будут завышенные не только в технической части, но и в части твоего отношения к программированию. Чтобы чувствовать себя более уверенным во время собеседования, погугли самые популярные вопросы и ответы, пройдись по основным терминам, конструкциям и синтаксису языка. Обрати внимание на соответствующие технологии. Таким образом, пока ты готовишься, возможно ты правда что-то узнаешь и притворяться разработчиком будет легче.
Гугли, перед тем как спрашивать
Говорят, что нет глупых вопросов, но это не так. Глупый вопрос - это вопрос на который можно найти ответ в гугле быстрее, чем задавая тот же самый вопрос своим коллегам. К тому же гугление развивает очень полезный навык - формулирование вопросов и мыслей в целом. Ведь вместо того, чтобы вывалить бессвязный поток мыслей, тебе действительно нужно подумать как задать вопрос так, чтобы гугл его понял и нашел то, что тебе нужно. Как и при подготовке к собеседованию, пока ты гуглишь ты правда можешь узнать что-то полезное, а самостоятельное решение проблем повысит твою уверенность в себе. В дальнейшем, ты будешь меньше переживать, что не сможешь самостоятельно справиться с какой-то из задач. А вишенка на торте этого совета в том, что ты будешь задавать коллегам более сложные вопросы и будешь казаться немного умнее, чем ты есть.
Настрой свою среду разработки
Разработчики любят все автоматизировать. Это касается и их рабочих инструментов. Автоформатирование кода, оптимизация импортов, статический анализ кода, автоматизированные тесты. Все это уже готово и сделает твою жизнь проще. Настрой свою среду, выучи сочетания клавиш, чтобы выполнять все автоматизированные проверки, которые можешь. Таким образом код, которым ты делишься будет выглядеть более профессионально, а твои коллеги найдут меньше ошибок на код ревью.
Следуй инструкциям и гайдлайнам своей команды
Скорее всего твой тимлид уже побеспокоился о том, чтобы командная работа была простой и отлаженной и написал гайдлайны для работы над проектом. Следуй им. Проверяй и перепроверяй, что все выполнено так, как просили. Таким образом работа, которой ты делишься будет соответствовать требованиям, а тимлид почувствует, что не зря писал все эти гайдлайны. Одна из самых раздражающих вещей в пятый раз кидать ссылку на документ с гайдлайнами и сообщением: “Прочитай”.
Если следовать этим советам, то будет казаться что ты самостоятельный и опытный разработчик, который знает, что делает даже если это пока не так. Но самый сок в том, что эти принципы позволяют постепенно развиваться. В итоге притворяться разработчиком будет все легче и легче.
Комментарии (107)
Luciphur
21.08.2022 22:03+28Хороший здравый список советов, хотя заголовок конечно может немного сбить с толку ) Очень нравится совет про английский язык, многие джуны и кандидаты в стажеры у меня эту часть недооценивают, и ИМХО очень зря.
jshapen
22.08.2022 07:32-4На фрилансе, кстати, можно и без знания языка кодить :)
morijndael
22.08.2022 15:27+9Потом при виде кода от таких фрилансеров хватаешься за голову и начинаешь нервно смеяться, со словами "господичтоза******[ужас]". Трустори
Английский нужен как минимум, чтобы читать документацию
jshapen
22.08.2022 16:39-1Хорошо, что 8 лет назад когда я начинал фрилансить мне такого не говорили. Иначе я бы не узнал, что клиенты платят не за чтение документации и не за знание языка, а за решение их проблем.
morijndael
22.08.2022 18:07+7Конечно, можно не думать обо всем вот этом, и очень быстро фигачить костыли в колеса велосипеда. Но рано или поздно ехать на этой конструкции станет крайне проблематично
А документация часто самый простой и прямой способ понять, как решить проблему. А если не повезло, и официальной документации кот наплакал, то неофициальных статей будет больше на английском, просто из-за того что он основной
Не, конечно можно и без английского. Просто с ним проще, и рано или поздно навык чтения наработается на тех кейсах, где решение по русски не гуглится
Aazamandius
22.08.2022 18:55+18Возле моего дома часто ходят люди и спрашивают "Есть работа?". Однажды мне надо было сделать небольшое отверсти под верхним кольцом для слива, небольшое, что бы труба прошла. Правильного инструмента у меня не было а долбить цемент сверлом - я бы весь день убил.
Ладно. Есть говорю. Надо вот тут сделать дырку. Он сказал "Вообще без проблем". Нашел где то такое же сверло, мотолок - сверлил, сверлил - потом ему тоже надоело. Нашел где то лом. В итоге он мне отломал знатный кусок этого кольца снизу, примерно треть. Стоит, смотрит и говорит - готово.
И вы знаете - он прав. Но лучше б я сам это сделал.
Решить проблему для клиента можно по разному. Можно сделать хорошо, а можно сделать так что потом уже никто и ничего за вменяемый прайс не сделает. Поэтому правильные фрилансеры (разработчики, я не имею права говорить за другие профессии) читают документацию и учат архитектуру.
d2d8
22.08.2022 23:13+2Проблема вашего исполнителя в том, что у него весьма ограничен круг потенциальных заказчиков и фиаско на вас закрывает его возможности заработка у несколько ваших соседей, а смена локации для него весьма сложна. У прогера-фринлансера же в заказчиках весь мир, куча бирж и любителей рискнуть качеством ради денег. Поэтому сверлить дыры ломом они могут весьма успешно.
igorsmi
22.08.2022 23:49По моему вы смешиваете понятия знания английского языка и знание языка программирования, архитектуры и т.п. Далеко не факт, что программист знающий английский язык будет превосходить такого же программиста, не обладающим таким знанием, с таким же временным опытом в программировании. Можно работать на российском рынке, изучать литературу и документацию на русском языке, которой кстати тоже не мало, и обладать высоким профессиональным уровнем. Конечно, знание английского языка никогда лишним не будет, и это будет только плюсом. Но каждый человек сам для себя выставляет приоритеты. Возможно пока вы тратите время на изучение английского языка, другой человек решает, что он прочитает несколько десятков переведённых книг, и когда упрётся в потолок возможно появится желание изучить английский язык, для дальнейшего собственного развития, а возможно поймёт, что ему и это не нужно.
arheops
24.08.2022 14:44Позвольте усомнится в том, что если изучать документацию 10 лет на русском и 10лет на русском И английском — на выходе будет одинаковый опыт. Нет, если первый был гений а второй — идиот — то да. А так, 50%+ возникающих проблем не имеют описания даже на русском, не то что решения.
tommyangelo27
23.08.2022 09:36+1Надо вот тут сделать дырку.
Ну вот он дырку и сделал, а надо было просить сделать отверстие ????
milkground
23.08.2022 10:16Решить проблему для клиента можно по разному. Можно сделать хорошо, а можно сделать так что потом уже никто и ничего за вменяемый прайс не сделает. Поэтому правильные фрилансеры (разработчики, я не имею права говорить за другие профессии) читают документацию и учат архитектуру.
К сожалению, это рассуждения про идеального фрилансера с точки зрения заказчика. В реальной жизни большинство фрилансеров (не только в ИТ и не только онлайн) хотят просто заработать деньги. Именно поэтому вам отломали кусок крыльца, а не изучали перед этим архитектуру крылец и отверстий + best practices. А как потом заказчик будет искать кого-то на доработки - это исключительно головная боль заказчика, лежащая в плоскости подбора и контроля исполнителей.
Ruwisk
24.08.2022 19:41Честно - мне английский и в предыдущей работе инженером на стройке пригождался.
1- Ушел в иностранную контору = баф на гринд золота =)
2- Документация, переговоры с людьми. Конечно, да к индусикам надо привыкнуть.
kpmy
21.08.2022 22:39+19Если судить по известной демо-игре о теории игр, Имитатор это одна из эффективных стратегий.
nulovkin
22.08.2022 01:39+2Чтобы поступить, как хороший игрок, нужно играть не менее хорошо. Если вы с успехом притворяетесь Каспаровым в шахматах, значит, вы действительно не хуже.
ReadOnlySadUser
22.08.2022 02:00+3Если ты победил Каспарова, то да. А если проиграл - уже начинаются нюансы) Ведь в отличии от Шахмат, обычная жизнь не подчиняется чётким правилам и практически любой неуспех можно списать на обстоятельства, при вкачанной хитрожопости.
SadOcean
22.08.2022 11:31+8Но и побеждать нужно не Каспарова
И вообще, чтобы убежать от медведя, нужно просто бежать не медленнее всех.
RalphMirebs
23.08.2022 09:15+5А потом голос за кадром «Мишка сделал даблкил… Мишка сделал пентакил!»
SadOcean
24.08.2022 17:57Правило будет работать универсально, пока ты не останешься один.
Если медведь догонит последнего - то тебе нужно просто продолжать не быть последним.
mSnus
22.08.2022 12:08+11В обычной жизни роляет маркетинг. Строчка в резюме "я играл в шахматы с Карповым" резко выделяет вас из ряда обычных, а уж проиграл или выиграл - это второй вопрос, а внимание уже привлечено.
Daddy_Cool
22.08.2022 15:53+1Да-да! Я так люблю рассказывать как боролся с чемпионом мира и чемпионом России. А что я проиграл все пять схваток (и чуть не потерял сознание в итоге) это уже малозначимые детали. )))))
tandzan
22.08.2022 19:51+1Как говорил один мошенник из "Истории подделок" - хорошая имитация гораздо более трудная задача, чем создать оригинал.
kpmy
22.08.2022 22:01Выдвигаем "гипотезу огурца": попав в айти-компанию притворщик всё равно станет таким-то айтишником, как свежий огурец попав к солёным, всё равно просолится.
Ведь по сути, принципы в статье неплохие, даже некоторые "настоящие" им не следуют.
RomanistHere
21.08.2022 23:25+11Забыли один важный совет (возможно не знаете), часто менять работу. Так и денег больше каждый раз можно просить и свою непродуктивность можно свалить не "не успел ещё со всем разобраться".
Глядишь, рано или поздно после общения с кучей людей что-то и проснётсяInnokentyDM Автор
21.08.2022 23:39+12Совет действительно дельный, как-то про него не подумал. Но должен сказать, что в силу своего характера я им пользовался только отчасти. Задерживался на некоторых позициях дольше чем это было необходимо. Мои более активные знакомые, преуспели больше как раз благодаря этому
fishHook
22.08.2022 11:30+11А в чем именно преуспели то? С зарплаты 2к перешли на 2.5к, это история успеха? Понятно, что если работодатель оказался гавно или какие-то другие есть препятствия для продолжения работы - ну вот не нравится и все, что поделать - то надо работу менять. А так чтобы менять ради того чтобы поменять... Ну так себе совет. Ты же не научишься ничему. Чтобы влиться в большой сложный проект мне надо полгода минимум, чтобы более-менее понять архитектуру решения, предметную область, стек технологий, узнать команду. Что-нибудь дельное предложить для развития у меня получается через год примерно. Вырасти как специалист можно только если ты берешь на себя ответственность, принимаешь решения, планируешь, видишь последствия своих решений через время. А так как вы предлагаете лучше и не начинать, лучше сразу в ПМы
InnokentyDM Автор
22.08.2022 11:50+4Работодатель не обязательно плохой, просто может быть в своей нише из которой люди вырастают, например компания по разработке сайтов где-то в провинции. Но под давлением таких вещей как "мы команда", "нам жаль тебя терять", "у меня тут кореша все работают", "кто меня еще возьмет" люди задерживаются, а иногда даже остаются на работе, которую было бы выгоднее и с точки зрения развития и с точки зрения зарплаты поменять.
А преуспели в том, что начинали как раз в провинциальных компаниях и постепенно переходили до более интересных позиций и да, зарплата тоже росла.
Поэтому, если ты не стартуешь на джуниорской позиции в условном яндексе, сразу после Универа и стажировки, то вероятно придется поменять работу пару раз в ближайшие несколько лет.
Ну и да, зп вроде как растет быстрее при смене работ, чем если ты на том же месте ждешь повышения, но это уже другая история
saboteur_kiev
22.08.2022 15:48+1Если ты имитатор, а не специалист, то рост зп все равно упрется в предел некомпетентности как твой так и интервьюверов.
А если ты внутри проекта не сидишь, а растешь, то наоборот как специалист ты вырастешь гораздо больше.
Основная проблема заключается в том, что на большинстве проектов - человек осваивает свой небольшой круг обязанностей и не пытается из него вырасти. Сидит, ДОБАВЛЯЯ к ним что-нибудь еще ради двух копеек.
Но есть много компаний, где вертикальный и горизонтальный рост вполне себе организован и требует лишь некоторой доли проактивности.
diogen4212
22.08.2022 09:50+3насколько часто, чтобы это не вызвало подозрений вида «его отовсюду гонят, значит он нам не нужен, только время на него потратим»?
Ivan22
22.08.2022 16:20раз в 2 года оптимум имхо,
Anuarooo
23.08.2022 09:48-1Неа, по опыту, чтобы зарплата вырастала в два - раз в год нужно менять. За два года покроешься плесенью и технологии с которыми ты работаешь могут стать неактуальными на рынке
ookami_kb
23.08.2022 13:41+7А потом появляются такие "сеньоры", которые ни одного проекта дольше года не вели, и не представляют, что такое поддерживаемая архитектура, и у которых актуальность технологий измеряется месяцами.
Anuarooo
23.08.2022 14:08ну у меня проект примерно год ведётся, я не уволился с текущей работы, но нашёл новую и как-то балансирую между двумя проектами, оказываю услуги.
Я не говорю что это хорошо в плане навыков, но чтобы зарплата росла нужно чаще менять компании. Можно и за год получить достаточный опыт, да и в какой-то момент вы всё равно остановитесь и будете держаться за компанию.
Лучше это сделать на уровне 2.5-3к баксов чем на уровне 0.5-1.5
Да и если ваш продукт работает год, то это как бы достаточно для любого продукта...
Cerberuser
23.08.2022 18:12если ваш продукт работает год, то это как бы достаточно для любого продукта
Мне два года назад передали на поддержку и развитие продукт, который до меня разрабатывали несколько лет в другой фирме и три года - в нашей. Полёт условно-нормальный, планируем продолжать, основная проблема - постоянное желание взять и переписать всё нафиг.
arheops
24.08.2022 14:48Одно из отличий мидла от сеньйора — сеньйор желание переписать сдерживает. И переписывает только куски, которые уж точно надо.
Вас же не просят переписывать? Значит, не актуально.
Ares_ekb
24.08.2022 05:30+4Да и если ваш продукт работает год, то это как бы достаточно для любого продукта...
Теперь понятно почему на меня иногда смотрят как на поехавшего, у меня многие проекты планировались на десятилетия. Чтобы за это время могла появиться и устареть куча фреймвоков, чтобы сменилось несколько форматов представления данных XML -> JSON -> YAML -> и дальше какая-то неведомая фигня, которая будет на хайпе через пару лет, десять лет, двадцать лет, ... Чтобы бизнес-требования могли постоянно меняться. Чтобы могло умереть и родиться несколько поколений разработчиков. И чтобы при всём этом не требовалось существенное изменение архитектуры и переделка всего.
Anuarooo
24.08.2022 07:27Тут смысл в том, что если ваш продукт проработал год и не упал, то скорее всего и дальше он так же будет работать, технологии могут обновляться, но проект будет дальше работать на старых, а вам нужно расти... Я это говорю потому, что я python разраб и каждый год выходят новые релизы ... и приложения с django/flask переписывают потихоньку на асинхронные фреймворки типа fastapi/aiohttp.
Ares_ekb
24.08.2022 08:22+3Зависит от того что считать ростом :) Если рост - это изучение новых фреймвоков, то, да, нужно менять работу как можно чаще. Если рост - это разработка масштабных проектов, в создании которых участвуют сотни разработчиков, то какой там используется фреймвок в целом пофиг. Особенно в долгосрочной перспективе, что бы там не использовалось всё равно успеет несколько раз устареть.
RomanistHere
23.08.2022 22:30-1зависит от софт скиллов и умения разговаривать с людьми. Но если меньше года пять проектов подряд, то, очевидно многие рекрутёры пройдут мимо. Хотя опять же, если ты офигеть какой уникальный спец, то это и визиткой может быть. Есть люди, которым скучно работать больше пару месяцев над одним проектом и они вполне круты - хоть это и не укладывается в топик оригинального поста
alaudo
22.08.2022 00:14+1Интересно было бы посмотреть на пример гайдлайнов, написанных тимлидом...
hellamps
22.08.2022 00:25+6а это часто гугленный копипаст из серии "а у эирбнб..."
cxFaust
22.08.2022 11:09+3Оно то да. Но это помогает команде писать все в одном стиле. А то приходят джуны со своми code style в idea. И большая часть changes это смещение строки влево на пробел...
Ivan22
22.08.2022 16:21ну вот в гайд-лайне и написано - "перед комитом, применяем автоматический форматировщик кода такой-то"
Ares_ekb
22.08.2022 06:37+10Специально для вас скопипастил кусочек внутреннего гайдлайна по реализации слоя хранения данных :) Я добавил конечно немного комментариев. В целом в гайдлайне описаны рекомендации по нормализации данных, именованию всего, первичным ключам (в том числе реализация equals и hashCode), иерархии классов, скалярным полям (типы данных, ограничения), связям между сущностями (особенно всякий трэш про двунаправленные связи, который практически всегда реализуются неправильно, особенно с помощью Lombok), по индексам, по каскадным операциям, по структуре проекта (это как-раз скопипащенный кусок), по версионированию схемы данных, по тестированию, по реализации API.
Обычно это описание лучших практик в сжатом и структурированном виде. Если эти темы гуглить, то часто находятся или просто корявые примеры реализации, которые нельзя использовать, или несколько длиннющих статей, описывающих совершенно разные варианты реализации, и непонятно какой из них выбрать. Плюс многие темы холиварные. Например, первичные ключи должны быть числовыми или uuid? Вы найдете кучу статей, доказывающих, что один вариант лучше другого. У нас четко зафиксирован один из вариантов и всё. Или нужно ли реализовывать equals() и hashCode(), и если нужно, то как? Тут тоже много вариантов, из которых мы выбрали один. Эталонной реализации двунаправленных связей вообще нигде нет, каждый делает как-то по-своему.
Совсем отличный вариант, если эти рекомендации ещё и реализованы на ArchUnit.
vassabi
22.08.2022 14:13+1(особенно всякий трэш про двунаправленные связи, который практически всегда реализуются неправильно, особенно с помощью Lombok
я наверно неверно понимаю "двунаправленные связи", но мне казалось, что обычно такого не должно быть в нормализованных представлениях....
можете рассказать подробнее - что вы имели в в виду под "двунаправленными связями" ?
Ares_ekb
22.08.2022 16:29+2Например, есть две сущности: пользователь и роль. Между ними связь многие ко многим, реализованная на уровне СУБД как промежуточная таблица. А на уровне JPA у пользователей может быть такая коллекция:
@ManyToMany private Set<Role> roles = HashSet<>();И у ролей может быть такая коллекция:
@ManyToMany(mappedBy = "roles") private Set<User> users = HashSet<>();Т.е. не только пользователи ссылаются на роли, но и роли ссылаются на пользователей. Связь двунаправленная. Двунаправленными могут быть также ManyToOne/OneToMany или две связи OneToOne.
В подавляющем большинстве случаев так делать не нужно, связи должны быть направлены в одну сторону: от более специфической сущности к более абстрактной или от агрегирующей сущности к её составным частям.
Тут могут быть чисто технические проблемы. Например, комментарии на хабре могут ссылаться на пользователей (авторов), но обратную ссылку лучше не делать. Hibernate не очень работает с большими коллекциями, загрузить из базы автора для комментария это норм или для пользователя загрузить список его ролей норм. А если, наоборот, при загрузке пользователя загружать ещё и все его комментарии или загружать вместе с ролью и десятки тысяч пользователей, то это не норм. Последнее лучше делать отдельным запросом с пагинацией. Даже ленивая загрузка тут не особо поможет.
Но основная проблема скорее в том, что с двунаправленными связями сущности начинают зависеть друг от друга и очень сложно разбить такую схему данных на относительно независимые части. Например, может быть ядро схемы данных, в котором определены пользователи, роли, ... И могут быть более специфические части: 1) статьи и комментарии, 2) вакансии и резюме, ... Если пользователи будут ссылаться на статьи, резюме и т.д., то это будет большая монолитная схема данных, где всё от всего зависит.
Есть ещё одна техническая проблема, на которую практически всегда забивают, особенно любители Lombok ) Нафига вручную писать геттеры, сеттеры, добавим пару аннотаций и Lombok сам нам всё сгенерит: getRoles(), setRoles(). Но если между пользователями и ролями связь двунаправленная, то при добавлении роли пользователю нужно обновить и обратный конец связи, т.е. для роли в её коллекцию users добавить этого пользователя. Есть много разных статей на эту тему: раз, два, три. Обычно делают такие методы: getRoles(), который возвращает немодифицируемую коллекцию, addRole() и removeRole(), которые обновляют другой конец ассоциации.
Но опять-таки в большинстве случае лучше вообще избегать таких двунаправленных связей.
Cerberuser
22.08.2022 16:45+3getRoles(), который возвращает немодифицируемую коллекцию
Причём я в своё время заморочился даже с тем, чтобы сделать её немодифицируемой на уровне API (т.е. возвращать не List/Set/etc., а ListView/SetView/etc., с отдельной иерархией классов и без мутирующих методов вообще - как в Kotlin, в каком-то смысле). Иначе становилось трудно проследить, в каком месте эта коллекция меняется - чаще всего это происходило через
getFoos().add(foo), и, соответственно, эти операции терялись среди обычных операций получения коллекции.
vassabi
22.08.2022 17:13+2понятно, спасибо.
PS: не надо ругать lombok :) дело не в нем, а в людях. Если явно написать свою реализацию getRoles(), то он её уже не трогает.
zuek
23.08.2022 10:42Мне на вскидку приходят перечни конструкционных материалов и нормальных крепёжных изделий - когда гайка одного типоразмера может быть изготовлена из латуни, нержавейки, оцинковки... ну, или модели обуви/одежды и стандартные размеры/полнота/рост... в общем, в реальной жизни это очень нередкий кейс (например, подбор крепежа, исходя из материала, или фильтр обуви по доступным размерам).
kellas
22.08.2022 00:39+45Если что-то выглядит как разработчик, кодит как разработчик и говорит как разработчик, вероятно это и есть разработчик )
Притворяйтесь сколько угодно.
Dmi3yD
22.08.2022 10:57Это видимо определенный ответ статье Исповедь ничтожества, прочитав которую я понял в очередной раз: "Я знаю, что я ничего не знаю!"
InnokentyDM Автор
22.08.2022 11:20+2В Исповедь ничтожества - это скорее следующий виток развития, когда ты осознал, что просто притворяясь дальше уже не уедешь
Kuch
22.08.2022 01:08+1Заголовок: 5 советов как притворяться...
Пункты:
Учись
Готовься
Ищи и изучай
Поработай на будущее
-
Следуй документации
Кажется, что статья все таки ближе к "работай", а не притворяйся. Могу накидать свои пункты как притворяться, но в большинстве своем они все равно требуют знаний, навыков и понимая, что ты делаешь
alvltab
22.08.2022 05:09+23Fake IT till you make IT.
yellow-elephant
22.08.2022 14:12То же самое хотел написать, но увидел ваш комментарий прям в ту же секунду, когда об этом подумал. Эх, у меня так не получается, даже наоборот — синдром самозванца во все поля.
dromaniak
22.08.2022 10:13+3В любой непонятной ситуации говори, что был интернет плохой, комп сломался (не мое)
Nialpe
22.08.2022 10:59+3Возможно я пропустил самый главный совет, но надо ли разрабатывать (писать код), чтобы притворяться разработчиком? Или это уже переходит в стадию быть разработчиком, а не притворяться. Не соображу никак. Запутался уже где ирония, а где нет.
Nedder
22.08.2022 11:38+2Найти индуса, который будет кодит за тебя. ;)
Ну, или в качестве варианта, учиться на видео с ютуб. Лет 10 назад все было намного хуже, сейчас, если человек ну не полный бездарь, выучиться до junior+ имхо может на таких видео почти каждый.
anarchomeritocrat
22.08.2022 12:45+11Жесть
Вот по этому любая статистика в IT бессильна.
Одни притворяются, другие не тянут, третьи прокрастинируют и ленятся, четвёртые выгорели, пятые депрессуют, шестые на стакан подсели, а то и на что то позабористей и тд и тп, а горизонт всё ярче озаряется пожарами полыхающих дедлайнов, долина смерти всё больше заполняется трупами несостоявшихся стартапов с казалось бы действительно гениальными идеями, фриланс биржи... я перестал заказывать работу на фриланс биржах вообще.
А статистика всё меряет зарплаты и популярность стеков, не в состоянии проникнуть в такие области, как отношение тех на ком всё держится к тем кто вообще не нужен и тем, кто откровенно вреден.
Я не притворяюсь, я разработчик до мозга костей и контраст с советами разительный, так, например, я вообще ни когда, серьёзно - ни разу в жизни не готовился к собеседованиям и проходил их блестяще (за исключением пары отказов по overqualified, но это другое), а почему? потому что мне просто жуть как интересно вообще всё в IT, потому что я самоучка, который любит своё дело, потому что я поставил крест на алкоголе и наркотиках и больше не калечу свой мозг, потому что веду активный образ жизни и интересуюсь всем на свете, причем и гуманитарными и техническими направлениями, потому что это реально моё призвание.
Если Вам приходится притворяться программистом, а не быть им, может это всё таки не Ваше?
InnokentyDM Автор
22.08.2022 12:54+3Как много людей могут с уверенностью назвать что-то их призванием? Хорошо, что Вы можете.
Советы как раз для тех, кто не разработчик для мозга костей, а может только наполовину или вообще пришел в профессию чисто ради бабок, тоже на мой взгляд валидная причина. Особенно сейчас, когда количество рекламы онлайн курсов зашкаливает и всем обещают интересные задачи, креативную работу и горы золота.
Интересно было бы почитать советы с Вашей стороны, что Вами движет?fishHook
22.08.2022 15:27+3Я искренне, глубочайше уверен, что если тебя не прёт от программирования как такового, то в разработке ПО тебе делать нечего. Наполовину не получится. Ради бабок не получится. Много чего в жизни можно делать ради бабок (таксистом работать например), но не писать код. Почему, я не знаю, это практическое наблюдение.
Finch182
22.08.2022 15:47+2Уже 7 лет в разработке. Сижу ради денег. Уже добрался до FAANG. Программирование терпеть не могу. Но буду терпеть, где я еще такие деньги заработаю
Daddy_Cool
22.08.2022 16:08+2Вот он, настоящий героизм! /irony
А как/когда/чем/зачем вы ЖИВЁТЕ? /серьезноFinch182
22.08.2022 16:13+6Любовь к деньгам компенсирует нелюбовь к программированию) поэтому в результате я счастливый человек)
fishHook
22.08.2022 16:41Поздравляю, у вас хорошие нервы и низкий порог ответсвенности. Но, семь лет - это немного. Еще парочку и наступит оно - выгорание. А там только в таксисты или менеджеры, что в прочем одно и то же.
Finch182
22.08.2022 16:48+2Если таксистом или менеджером будут платить такие деньги то я только за. А в целом я пока каждые 3 года полностью меняю специальность с повышением зарплаты, так что в принципе выгореть не успеваю. Щас еще пару тройку лет в европе поработаю, потом в штаты на удвоенную зарплату, так до пенсии надеюсь и протяну без выгорания.
F0iL
22.08.2022 16:47+2Почему? Таких людей - у кого нету страсти к программированию и кто не "горит" разработкой, а занимается этим исключительно потому что за это хорошо платят - в отрасли очень и очень много. Да, они не запилят новый фреймворк, не изобретут новые концепции, не запустят популярнейший опенсорс-проект, не напишут крутых статей на Медиум или Хабр - но от них это и не требуется, не каждый должен быть вторым Торвальдсом или Белларом. Но они нередко дорастают до крепких миддлов или даже синьоров, они хорошие исполнители и их навыков более чем хватает для успешного решения задач бизнеса типа написания CRUD'ов, запросов к апишкам и шлепанья форм. В итоге хорошо всем - бизнес получает достаточно разработчиков для своих нужд, "настоящие программисты" имеют возможность спихнуть скучную рутину на других и заниматься тем что интереснее, а "ненастоящие программисты" просто имеют работу, за которую очень хорошо платят. И все довольны.
tommyangelo27
22.08.2022 18:20+4нередко дорастают до крепких миддлов или даже синьоров, они хорошие исполнители и их навыков более чем хватает для успешного решения задач бизнеса
У меня есть друг с таким подходом в программирование пришёл, исключительно ради денег. Уже 11 лет в профессии, от формошлёпа дорос до Engineering Manager в крупной международной компании.
Глядя на него — наоборот завидую, что он к разработке практически без эмоций подходит, у него не подгорает, когда что-то откровенно плохо сделано. В трудных ситуациях он всегда с холодной головой.
anarchomeritocrat
22.08.2022 16:39+2Я сейчас работаю над своими исследованиями и немного контрибьючу в опенсорс. Пока вообще ничего за это не получаю - живу только за счет ранее созданных пассивных источников, что много ниже, чем мог бы работая на зп, но мне интересно задумку в жизнь воплотить и выложить её на гитхаб под MIT, без всяких коммерческих притязаний и путей монетизации. Движет мной любопытство и интерес. Вот у Вас была в детстве любимая игрушка в которой надо было как то креативить? Лего, какой то другой конструктор, пластилин там и тд? Такая, от которой за уши не оттащишь, залипательная-залипательная? Вот то же самое что с этим занятием Вами двигало, мной движет во всём, что касается IT. Я когда начинал программить (конец 80-х, 90-е), сказать девушке, что ты компьютерщик - это поставить крест на всей романтике, потому что гики и ботаны были не то, что не в моде, а даже в минусе - крутыми были маскулинность и сила. Примерно вот такой был средний образ. По статусу были сравнимы с дежурным электриком - младший придаток бухгалтерии и не было космических зарплат, клише про интеллектуальную элиту и всенародного хайпа "войти в айти". Вот просто спросите себя - в те времена вы бы пошли в программисты, или нет?
Что посоветовать? Ну, раз уж взялись за это дело, то попробуйте разжечь пламя интереса в себе, эксперементируйте, придумывайте, разбирайтесь, самообучайтесь постоянно. В Японии есть такое понятие "Шокунин", по сути "мастер своего дела", так вот я посоветую любому, кто выбрал свою дорогу в какой то области, осознать, что это не рррраз и ты синьор ассемблера - это долгий путь проб и ошибок, усердной работы над саморазвитием. Поставьте себе цель не бабла заработать как можно больше, а стать реально гуру, экспертом, профессионалом - по настоящему разобраться в теме от и до. Может тогда вдруг тоже обнаружите, что это Ваше призвание, а деньги - это плохая мотивация в любой сложной области, настоящий специалист рождается из увлечения самой специальностью, а не размером её оплаты.
Такой вот парадокс - что бы в бабловой профессии бабла поднять, надо перестать думать о бабле и начать думать о профессии ) как то так )
hellamps
23.08.2022 05:14+1я вот не согласен. о бабле надо постоянно думать, а надеятся на талант и гениальность - порой опрометчиво.
yellow-elephant
22.08.2022 14:35+4Искренне рад за вас (без шуток, если что, всегда приятно читать о том, что человек нашёл себя и радуется жизни)!
Но скажите, пожалуйста, где бизнесу взять достаточно таких, как вы? Или что делать людям, которым нравится деятельность, доходов с которой хватит только на прикрытие наготы? Зато они могут двигать таски в джире, чтобы оплачивать счета, а в свободное время занимаются интересными им вещами. Win-win же.
Zara6502
22.08.2022 13:59+1Выучи английский
Мне кажется если вы в ИТ, то он учится сам по себе без прикладывания усилий, другой вопрос сможете ли вы на нём разговаривать, это совсем другая история.
Подготовься к собеседованию
На мой взгляд бессмысленное занятие, это как сдать ЕГЭ на 100 баллов, а потом не уметь посчитать дискриминант.
Гугли, перед тем как спрашивать
Это верно и нужно для жизни, а не только для ИТ, но
тебе действительно нужно подумать как задать вопрос так, чтобы гугл его понял и нашел то, что тебе нужно
сегодня это заметно проще, я уже лет 10 как не пишу и не формулирую вопросы как доктор наук, кстати многое гуглили до нас и ответы на вопросы "прога для игр" дают куда более точные ответы, так как мы же помним, что дилетантов в мире куда больше, а значит гугл учится на их вопросах.
ты будешь задавать коллегам более сложные вопросы и будешь казаться немного умнее, чем ты есть.
как человек со стажем в ИТ в 24 года скажу - всем плевать что я там и как я там кому кажусь, а обратная сторона этой вишенки будет в том, что тебе навалят работы которую ты не тянешь, но ведь ты сам только что показался всем умным, значит должен уметь. А кому оно надо это превозмогание? я наоборот стал вести себя как глупый и моя жизнь стала проще, на зарплату никак не повлияло.
Настрой свою среду разработки
Сегодня питон, завтра c#, послезавтра java - под всё не нанастраиваешься. Я наоборот все интерфейсы всегда использую "по умолчанию", что всегда и везде совместимо, я могу сесть за любой ПК и сразу им пользоваться.
Следуй инструкциям и гайдлайнам своей команды
Как только встречу адекватного руководителя, то обязательно так сделаю. Пока, к несчастью, такие на горизонте не появлялись.
Имхо, у вас ошибка выжившего.
InnokentyDM Автор
22.08.2022 14:50+1Интересный взгляд, вполне может быть и ошибка выжившего, но эти советы отчасти появились от моего небольшого опыта тимлидерства и работы с младшими коллегами, когда они явно игнорировали все то, что написано выше.
И элементарно загуглить, и просто соблюдать нейминг, и запускать тесты. И в итоге описанное то, что я делал и хотел бы чтобы делали коллеги с которыми я работаю)
Есть один вопрос только, как часто приходится садиться за любой пк и начинать работать? Звучит немного странно, сразу в голову приходят хакеры из голливудских фильмов, которые с рандомного пк взламывают Пентагон) я
vassabi
22.08.2022 15:05Есть один вопрос только, как часто приходится садиться за любой пк и начинать работать?
тоже стало интересно - как такое сделать?
пока что единственный вариант когда настраиваешь универсальный RDP и тогда с любого другого компа логинишься на свой рабочий ...
inkelyad
22.08.2022 19:50Если любой ПК - не совсем любой, а внутри организации, то при логине монтируется /home, а при загрузке самого ПК - еще и /usr/ со всем софтом, что организация пользуется.
Собственно, когда-то давно оно так и работало, но потом как-то кончилось.
Zara6502
23.08.2022 05:15то при логине монтируется /home
Сетевые профили не есть гуд, за удобством скрываются другие проблемы. Но, у меня на работе три домена, три профиля, а еще два локальных профиля, настраивать каждый не вижу смысла, это абсолютно никак не повлияет на качество работы, а через год я могу работать уже в другом месте, где вообще нельзя настраивать профиль. Поэтому не вижу смысла.
PS: слабо представляю переносимость софта через сетевую папку, у нас софт разный для разных рабочих мест, объем общий около 150 Гб, запуск многих пакетов не с локального SSD будет очень печальным.
d-stream
23.08.2022 03:00+1Иногда бывает и другое: от смены до смены компьютера банально забывается "где и что подкручивал". Поэтому со временем и приходишь к неким обобщенным дефолтам.
В какой-то мере это перекликается и с теми же паттернами программирования - в общем-то это просто рецепты, возможно даже не самые идеальные в конкретном месте, но вот они привычны, понятны, узнаваемы и в итоге с первых строк чужого кода понятно что "убийца садовник", что не в детективе только на пользу.
Zara6502
23.08.2022 05:06небольшого опыта
это и есть то, почему ваше мнение о проблеме слишком нерепрезентативно. Я каждый день вижу людей, разного возраста, которые не умеют нормально пользоваться ПК, но это не значит что если написать статью с советами как пользоваться ПК это будет охватывать большую аудиторию. Как правило в любой профессиональной сфере есть люди которые удивляют своей тупостью, причем на разных должностях и всегда задумываешься как этот человек вообще работает. Но вот так.
как часто приходится садиться за любой пк и начинать работать? Звучит немного странно
Вообще каждый день, у меня 650 ПК на обслуживании.
А если про разработку, то у меня условно 4 рабочих места, жмякаю Visual Studio Installer и в путь, то есть от начала разработки на конкретном ПК меня отделяет только время на установку VS.
InnokentyDM Автор
23.08.2022 09:43Имхо, в таком случае это у вас ошибка выжившего. Всё-таки обычно у разработчиков одно рабочее место, может ещё одно дома. Необходимость регулярно переключаться с одного места - это какой-то очень специфичный кейс. А чем вы занимаетесь, если не секрет?
Zara6502
23.08.2022 13:13Слова "обычно" как раз и говорят об ошибке выжившего, то есть когда вы опираетесь на какой-то универсальный стандарт, на единую модель поведения, вы же согласитесь что это невозможно в принципе?
Ну я за всех разработчиков не скажу, каждый страдает как хочет, у меня дома 4 ПК, ноутбук, на работе 4 ПК. Причем профили такие что настраивать их нет смысла. Что-то конечно настраивается, но по минимуму.
Я не столько за то, чтобы у всех разрабов было много рабочих мест, а за то, чтобы человек без особых телодвижений быстро мог сразу начать работать. Я не поверю что в компании у вас 100%-я свобода кастомизации рабочего места, дома - соглашусь, но не на работе.
Родственник работает в геймдеве, у него несколько ПК с разным железом, несколько тестовых серверов, отдельные машины для PlayStation и XBOX с разным железом. С дома ко всем может подключаться удаленно, какой-то особой кастомизации у него нет.
Я просто реально не могу представить зачем кастомизировать всё настолько что кастомизация превращается во что-то ради самой кастомизации. Ну или банально вам нужно к соседу подсесть и на его ПК на его рабочем месте что-то показать и вдруг у него раскладка ДВОРАК, левая мышка, все шорткаты другие и т.д. - и что дальше? Таких примеров из жизни могу сотню рассказать и любители Punto Switcher всякие, и любители настраивать браузер так что он сам превращается в отдельный компьютер, а без аддонов вообще не знают как пользоваться браузером.
Не секрет чем я занимаюсь, но не вижу смысла говорить, так как вы будете это использовать как аргумент в разговоре, а это к теме не относится. Скажу лишь что сейчас я не разработчик в том смысле как подаёт автор статьи (вы). У вас это собирательный образ современной молодой команды в какой-то строго определенной компании работающей по какому-то шаблону. Возможно в Москве или Европе таких много, я такие не видел ни разу, общался какое-то время с российскими разрабами HP, Toshiba, Сбер - у них всё совсем иначе и не совпадает с тем что пишете вы.
PS: единственная кастомизация с моей стороны это темная тема в VS и браузере.
PPS: Надеюсь вы понимаете что я не наезжаю и у меня нет зла к вам, просто вижу что информация затрагивает какой-то узкий сегмент людей.
InnokentyDM Автор
23.08.2022 13:29+1Вероятно я не достаточно ясно про настройку среды выразился. В моем понимании - это использовать средств автоматизации, которые помогают соблюдать стандарты языка + выучить стандартные горячие клавиши для их применения и быстрого использования IDE, без фанатизма.
Согласен, что я говорю про достаточно определенный тип разработчиков. Аля бэк/фронт, может отчасти мобильщики. Понимаю, что есть ембеддед, геймдев, сетевые разработчики и еще куча разных со своей спецификой, которая сильно влияет на работу. Но я все же придерживаюсь совета, что свою среду в любом случае знать нужно, независимо от того, какая она. Вероятно вместо "настроить" в заголовке этого совета можно было бы использовать что-то вроде "Знай свои инструменты", но звучало бы слишком обще тогда)
Ни в коем случае не чувствую, что вы наезжаете. Наоборот интересна и полезна другая точка зрения. Спасибо за ответы)Zara6502
23.08.2022 13:44Хм, я понял вас. Да, возможно какие-то обобщение есть в словах это и зацепило. Про инструменты, в таком понимании как вы написали сейчас, абсолютно поддерживаю вашу точку зрения - знание инструмента это тоже немалый скилл, а для разработчика и знание дебаггера, это вообще что-то из области талантов, мне например даётся всегда тяжело.
MegaMANGO
22.08.2022 15:08+1Советы полезные, только не понимаю при чём тут притворство.) Вполне нормальный список навыков, которые помогут стать Джуном +, а то и мидлом
Gradiens
22.08.2022 15:09+1А в чем тут притворство-то?
В том, что вам не нравится программировать? Сочувствую. Большинство людей на этой планете не любит свою работу. Но с точки зрения бизнеса это совершенно не важно.
Важно лишь то, как успешно вы решаете поставленные задачи.
Если вы нормально работаете как программист, то, по "утиной типизации" вы и есть программист.
А чувствуете ли вы себя хорошим программистом, плохим, собачкой или котиком - бизнесу без разницы. На зарплату это не влияет. Влияет немного на головняк вашего тимлида, но на то он и тимлид, чтобы с этим разбираться.
Nedder
23.08.2022 08:43+3Вы что! Нельзя работать программистом и не любить свою работу! Это просто невозможно. (сарказм)
Так таксисты работают в такси только потому, что им нравиться водить машину и общаться с новыми людьми. А проститутки просто очень любят секс. А водители ассенизаторской машины ... тоже что-то любят. :)
Diamon33
23.08.2022 19:36+2в такси только потому, что им нравиться водить машину
А вот и нет, они водят машину для души, а так у них бизнес.
Нельзя работать программистом и не любить свою работу
Выше в ветке по комментам неиронично говорят, что нельзя. Я не могу сказать, что люблю программирование, у меня получается делать то, что требуется по работе, я стараюсь ответственно подходить к любой задаче и разбираться до мелочей в том, что делаю. Но я не иду делать свой фреймворк, у меня даже желания не хватает или времени нет сделать нормальный пет проект.
Программирование позволило мне заработать на первую машину, затем переехать в США, в США накопить/вложить средств на случай, если я соберусь в менеджеры или таксисты, а также позволить себе посещать психолога, кататься на лыжах в горах, ходить в походы, в целом путешествовать по странам, заниматься музыкой (в частности - пианино) с преподавателем, вкусно есть в разных заведениях и играть в любые игры на любых платформах.
С точки зрения Д'Артаньянов разработки я, как простой мушкетер - не должен существовать, видимо.
Dropsen
22.08.2022 17:09+2Я бы ещё добавил "Будь смелым". Можно очень многое узнать, если всё-же не боишься задать неправильный вопрос, отписаться на вакансию, которая, по твоему мнению, слишком крута для тебя, не боишься общаться с собеседующим и т.д.
Полезный навык)
Mayari
22.08.2022 17:28-1У самурая нет цели, есть только путь. И этот путь ведёт к успеху. Homo ludens как он есть: игра в развитие, развитие через игру. Браво автору!
artsiom-rusau
22.08.2022 19:22+1Отличные советы. Многие забывают про изучение английского языка и его активного применения на рабочем месте, избегая компании, где его используют.
Хотя в современных реалиях без него никуда, если ты думаешь о своем развитии и хочешь быть человеком мира.
HarryFox
22.08.2022 20:15+2Не знаю, откуда эта фраза у меня в голове, мне приятно думать, что это я ее изобрёл (что вряд ли):
Казаться - уже наполовину быть.Однако позже встретил англоязычный вариант:
Fake it till you make it
saipr
Не убавить, не добавить.
Всё так.