Comments 110
Не убавить, не добавить.
Всё так.
Хороший здравый список советов, хотя заголовок конечно может немного сбить с толку ) Очень нравится совет про английский язык, многие джуны и кандидаты в стажеры у меня эту часть недооценивают, и ИМХО очень зря.
Потом при виде кода от таких фрилансеров хватаешься за голову и начинаешь нервно смеяться, со словами "господичтоза******[ужас]". Трустори
Английский нужен как минимум, чтобы читать документацию
Конечно, можно не думать обо всем вот этом, и очень быстро фигачить костыли в колеса велосипеда. Но рано или поздно ехать на этой конструкции станет крайне проблематично
А документация часто самый простой и прямой способ понять, как решить проблему. А если не повезло, и официальной документации кот наплакал, то неофициальных статей будет больше на английском, просто из-за того что он основной
Не, конечно можно и без английского. Просто с ним проще, и рано или поздно навык чтения наработается на тех кейсах, где решение по русски не гуглится
Возле моего дома часто ходят люди и спрашивают "Есть работа?". Однажды мне надо было сделать небольшое отверсти под верхним кольцом для слива, небольшое, что бы труба прошла. Правильного инструмента у меня не было а долбить цемент сверлом - я бы весь день убил.
Ладно. Есть говорю. Надо вот тут сделать дырку. Он сказал "Вообще без проблем". Нашел где то такое же сверло, мотолок - сверлил, сверлил - потом ему тоже надоело. Нашел где то лом. В итоге он мне отломал знатный кусок этого кольца снизу, примерно треть. Стоит, смотрит и говорит - готово.
И вы знаете - он прав. Но лучше б я сам это сделал.
Решить проблему для клиента можно по разному. Можно сделать хорошо, а можно сделать так что потом уже никто и ничего за вменяемый прайс не сделает. Поэтому правильные фрилансеры (разработчики, я не имею права говорить за другие профессии) читают документацию и учат архитектуру.
Проблема вашего исполнителя в том, что у него весьма ограничен круг потенциальных заказчиков и фиаско на вас закрывает его возможности заработка у несколько ваших соседей, а смена локации для него весьма сложна. У прогера-фринлансера же в заказчиках весь мир, куча бирж и любителей рискнуть качеством ради денег. Поэтому сверлить дыры ломом они могут весьма успешно.
По моему вы смешиваете понятия знания английского языка и знание языка программирования, архитектуры и т.п. Далеко не факт, что программист знающий английский язык будет превосходить такого же программиста, не обладающим таким знанием, с таким же временным опытом в программировании. Можно работать на российском рынке, изучать литературу и документацию на русском языке, которой кстати тоже не мало, и обладать высоким профессиональным уровнем. Конечно, знание английского языка никогда лишним не будет, и это будет только плюсом. Но каждый человек сам для себя выставляет приоритеты. Возможно пока вы тратите время на изучение английского языка, другой человек решает, что он прочитает несколько десятков переведённых книг, и когда упрётся в потолок возможно появится желание изучить английский язык, для дальнейшего собственного развития, а возможно поймёт, что ему и это не нужно.
То, что 50%+ возникающих проблем не имеют описания даже на русском, это факт. Но в современно мире отсутствие знания языка не мешает находить ответы на возникающие проблемы на языке которого не знаешь.
Я всегда гуглю свои рабочие вопросы на английском, хотя не знаю его (спасибо переводчикам). Уже даже английские видео на ютубе можно смотреть на русском языке (спасибо яндексу).
И не нужно обязательно быть гением, что бы кого то превзойти. Достаточно глубокие знания в языке программировании, и в архитектуре можно получить изучая русскую литературу. Что бы познать какие то совсем новые технологии конечно тут уже наверно без английского никак.
Хотя так же на моём примере, я изучил Angular на документации с официального сайта которая не имеет перевода, мне это не помешало.
в коде всегда всё можно исправить
Надо вот тут сделать дырку.
Ну вот он дырку и сделал, а надо было просить сделать отверстие ?
Решить проблему для клиента можно по разному. Можно сделать хорошо, а можно сделать так что потом уже никто и ничего за вменяемый прайс не сделает. Поэтому правильные фрилансеры (разработчики, я не имею права говорить за другие профессии) читают документацию и учат архитектуру.
К сожалению, это рассуждения про идеального фрилансера с точки зрения заказчика. В реальной жизни большинство фрилансеров (не только в ИТ и не только онлайн) хотят просто заработать деньги. Именно поэтому вам отломали кусок крыльца, а не изучали перед этим архитектуру крылец и отверстий + best practices. А как потом заказчик будет искать кого-то на доработки - это исключительно головная боль заказчика, лежащая в плоскости подбора и контроля исполнителей.
Честно - мне английский и в предыдущей работе инженером на стройке пригождался.
1- Ушел в иностранную контору = баф на гринд золота =)
2- Документация, переговоры с людьми. Конечно, да к индусикам надо привыкнуть.
Если судить по известной демо-игре о теории игр, Имитатор это одна из эффективных стратегий.
Чтобы поступить, как хороший игрок, нужно играть не менее хорошо. Если вы с успехом притворяетесь Каспаровым в шахматах, значит, вы действительно не хуже.
Если ты победил Каспарова, то да. А если проиграл - уже начинаются нюансы) Ведь в отличии от Шахмат, обычная жизнь не подчиняется чётким правилам и практически любой неуспех можно списать на обстоятельства, при вкачанной хитрожопости.
Как говорил один мошенник из "Истории подделок" - хорошая имитация гораздо более трудная задача, чем создать оригинал.
Забыли один важный совет (возможно не знаете), часто менять работу. Так и денег больше каждый раз можно просить и свою непродуктивность можно свалить не "не успел ещё со всем разобраться".
Глядишь, рано или поздно после общения с кучей людей что-то и проснётся
Совет действительно дельный, как-то про него не подумал. Но должен сказать, что в силу своего характера я им пользовался только отчасти. Задерживался на некоторых позициях дольше чем это было необходимо. Мои более активные знакомые, преуспели больше как раз благодаря этому
А в чем именно преуспели то? С зарплаты 2к перешли на 2.5к, это история успеха? Понятно, что если работодатель оказался гавно или какие-то другие есть препятствия для продолжения работы - ну вот не нравится и все, что поделать - то надо работу менять. А так чтобы менять ради того чтобы поменять... Ну так себе совет. Ты же не научишься ничему. Чтобы влиться в большой сложный проект мне надо полгода минимум, чтобы более-менее понять архитектуру решения, предметную область, стек технологий, узнать команду. Что-нибудь дельное предложить для развития у меня получается через год примерно. Вырасти как специалист можно только если ты берешь на себя ответственность, принимаешь решения, планируешь, видишь последствия своих решений через время. А так как вы предлагаете лучше и не начинать, лучше сразу в ПМы
Работодатель не обязательно плохой, просто может быть в своей нише из которой люди вырастают, например компания по разработке сайтов где-то в провинции. Но под давлением таких вещей как "мы команда", "нам жаль тебя терять", "у меня тут кореша все работают", "кто меня еще возьмет" люди задерживаются, а иногда даже остаются на работе, которую было бы выгоднее и с точки зрения развития и с точки зрения зарплаты поменять.
А преуспели в том, что начинали как раз в провинциальных компаниях и постепенно переходили до более интересных позиций и да, зарплата тоже росла.
Поэтому, если ты не стартуешь на джуниорской позиции в условном яндексе, сразу после Универа и стажировки, то вероятно придется поменять работу пару раз в ближайшие несколько лет.
Ну и да, зп вроде как растет быстрее при смене работ, чем если ты на том же месте ждешь повышения, но это уже другая история
Если ты имитатор, а не специалист, то рост зп все равно упрется в предел некомпетентности как твой так и интервьюверов.
А если ты внутри проекта не сидишь, а растешь, то наоборот как специалист ты вырастешь гораздо больше.
Основная проблема заключается в том, что на большинстве проектов - человек осваивает свой небольшой круг обязанностей и не пытается из него вырасти. Сидит, ДОБАВЛЯЯ к ним что-нибудь еще ради двух копеек.
Но есть много компаний, где вертикальный и горизонтальный рост вполне себе организован и требует лишь некоторой доли проактивности.
раз в 2 года оптимум имхо,
Неа, по опыту, чтобы зарплата вырастала в два - раз в год нужно менять. За два года покроешься плесенью и технологии с которыми ты работаешь могут стать неактуальными на рынке
А потом появляются такие "сеньоры", которые ни одного проекта дольше года не вели, и не представляют, что такое поддерживаемая архитектура, и у которых актуальность технологий измеряется месяцами.
ну у меня проект примерно год ведётся, я не уволился с текущей работы, но нашёл новую и как-то балансирую между двумя проектами, оказываю услуги.
Я не говорю что это хорошо в плане навыков, но чтобы зарплата росла нужно чаще менять компании. Можно и за год получить достаточный опыт, да и в какой-то момент вы всё равно остановитесь и будете держаться за компанию.
Лучше это сделать на уровне 2.5-3к баксов чем на уровне 0.5-1.5
Да и если ваш продукт работает год, то это как бы достаточно для любого продукта...
если ваш продукт работает год, то это как бы достаточно для любого продукта
Мне два года назад передали на поддержку и развитие продукт, который до меня разрабатывали несколько лет в другой фирме и три года - в нашей. Полёт условно-нормальный, планируем продолжать, основная проблема - постоянное желание взять и переписать всё нафиг.
Да и если ваш продукт работает год, то это как бы достаточно для любого продукта...
Теперь понятно почему на меня иногда смотрят как на поехавшего, у меня многие проекты планировались на десятилетия. Чтобы за это время могла появиться и устареть куча фреймвоков, чтобы сменилось несколько форматов представления данных XML -> JSON -> YAML -> и дальше какая-то неведомая фигня, которая будет на хайпе через пару лет, десять лет, двадцать лет, ... Чтобы бизнес-требования могли постоянно меняться. Чтобы могло умереть и родиться несколько поколений разработчиков. И чтобы при всём этом не требовалось существенное изменение архитектуры и переделка всего.
Тут смысл в том, что если ваш продукт проработал год и не упал, то скорее всего и дальше он так же будет работать, технологии могут обновляться, но проект будет дальше работать на старых, а вам нужно расти... Я это говорю потому, что я python разраб и каждый год выходят новые релизы ... и приложения с django/flask переписывают потихоньку на асинхронные фреймворки типа fastapi/aiohttp.
Зависит от того что считать ростом :) Если рост - это изучение новых фреймвоков, то, да, нужно менять работу как можно чаще. Если рост - это разработка масштабных проектов, в создании которых участвуют сотни разработчиков, то какой там используется фреймвок в целом пофиг. Особенно в долгосрочной перспективе, что бы там не использовалось всё равно успеет несколько раз устареть.
зависит от софт скиллов и умения разговаривать с людьми. Но если меньше года пять проектов подряд, то, очевидно многие рекрутёры пройдут мимо. Хотя опять же, если ты офигеть какой уникальный спец, то это и визиткой может быть. Есть люди, которым скучно работать больше пару месяцев над одним проектом и они вполне круты - хоть это и не укладывается в топик оригинального поста
Интересно было бы посмотреть на пример гайдлайнов, написанных тимлидом...
а это часто гугленный копипаст из серии "а у эирбнб..."
Специально для вас скопипастил кусочек внутреннего гайдлайна по реализации слоя хранения данных :) Я добавил конечно немного комментариев. В целом в гайдлайне описаны рекомендации по нормализации данных, именованию всего, первичным ключам (в том числе реализация equals и hashCode), иерархии классов, скалярным полям (типы данных, ограничения), связям между сущностями (особенно всякий трэш про двунаправленные связи, который практически всегда реализуются неправильно, особенно с помощью Lombok), по индексам, по каскадным операциям, по структуре проекта (это как-раз скопипащенный кусок), по версионированию схемы данных, по тестированию, по реализации API.
Обычно это описание лучших практик в сжатом и структурированном виде. Если эти темы гуглить, то часто находятся или просто корявые примеры реализации, которые нельзя использовать, или несколько длиннющих статей, описывающих совершенно разные варианты реализации, и непонятно какой из них выбрать. Плюс многие темы холиварные. Например, первичные ключи должны быть числовыми или uuid? Вы найдете кучу статей, доказывающих, что один вариант лучше другого. У нас четко зафиксирован один из вариантов и всё. Или нужно ли реализовывать equals() и hashCode(), и если нужно, то как? Тут тоже много вариантов, из которых мы выбрали один. Эталонной реализации двунаправленных связей вообще нигде нет, каждый делает как-то по-своему.
Совсем отличный вариант, если эти рекомендации ещё и реализованы на ArchUnit.
(особенно всякий трэш про двунаправленные связи, который практически всегда реализуются неправильно, особенно с помощью Lombok
я наверно неверно понимаю "двунаправленные связи", но мне казалось, что обычно такого не должно быть в нормализованных представлениях....
можете рассказать подробнее - что вы имели в в виду под "двунаправленными связями" ?
небось многие-ко-многим
Например, есть две сущности: пользователь и роль. Между ними связь многие ко многим, реализованная на уровне СУБД как промежуточная таблица. А на уровне 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(), которые обновляют другой конец ассоциации.
Но опять-таки в большинстве случае лучше вообще избегать таких двунаправленных связей.
getRoles(), который возвращает немодифицируемую коллекцию
Причём я в своё время заморочился даже с тем, чтобы сделать её немодифицируемой на уровне API (т.е. возвращать не List/Set/etc., а ListView/SetView/etc., с отдельной иерархией классов и без мутирующих методов вообще - как в Kotlin, в каком-то смысле). Иначе становилось трудно проследить, в каком месте эта коллекция меняется - чаще всего это происходило через getFoos().add(foo), и, соответственно, эти операции терялись среди обычных операций получения коллекции.
понятно, спасибо.
PS: не надо ругать lombok :) дело не в нем, а в людях. Если явно написать свою реализацию getRoles(), то он её уже не трогает.
Мне на вскидку приходят перечни конструкционных материалов и нормальных крепёжных изделий - когда гайка одного типоразмера может быть изготовлена из латуни, нержавейки, оцинковки... ну, или модели обуви/одежды и стандартные размеры/полнота/рост... в общем, в реальной жизни это очень нередкий кейс (например, подбор крепежа, исходя из материала, или фильтр обуви по доступным размерам).
Привет друг). Спасибо).
Если что-то выглядит как разработчик, кодит как разработчик и говорит как разработчик, вероятно это и есть разработчик )
Притворяйтесь сколько угодно.
Это видимо определенный ответ статье Исповедь ничтожества, прочитав которую я понял в очередной раз: "Я знаю, что я ничего не знаю!"
Точно не утка.)
Заголовок: 5 советов как притворяться...
Пункты:
Учись
Готовься
Ищи и изучай
Поработай на будущее
Следуй документации
Кажется, что статья все таки ближе к "работай", а не притворяйся. Могу накидать свои пункты как притворяться, но в большинстве своем они все равно требуют знаний, навыков и понимая, что ты делаешь
Fake IT till you make IT.
В любой непонятной ситуации говори, что был интернет плохой, комп сломался (не мое)
Возможно я пропустил самый главный совет, но надо ли разрабатывать (писать код), чтобы притворяться разработчиком? Или это уже переходит в стадию быть разработчиком, а не притворяться. Не соображу никак. Запутался уже где ирония, а где нет.
Найти индуса, который будет кодит за тебя. ;)
Ну, или в качестве варианта, учиться на видео с ютуб. Лет 10 назад все было намного хуже, сейчас, если человек ну не полный бездарь, выучиться до junior+ имхо может на таких видео почти каждый.
Монстр Франкенштейна из кусков со стековерфлоу сгодится * шутка *
Жесть
Вот по этому любая статистика в IT бессильна.
Одни притворяются, другие не тянут, третьи прокрастинируют и ленятся, четвёртые выгорели, пятые депрессуют, шестые на стакан подсели, а то и на что то позабористей и тд и тп, а горизонт всё ярче озаряется пожарами полыхающих дедлайнов, долина смерти всё больше заполняется трупами несостоявшихся стартапов с казалось бы действительно гениальными идеями, фриланс биржи... я перестал заказывать работу на фриланс биржах вообще.
А статистика всё меряет зарплаты и популярность стеков, не в состоянии проникнуть в такие области, как отношение тех на ком всё держится к тем кто вообще не нужен и тем, кто откровенно вреден.
Я не притворяюсь, я разработчик до мозга костей и контраст с советами разительный, так, например, я вообще ни когда, серьёзно - ни разу в жизни не готовился к собеседованиям и проходил их блестяще (за исключением пары отказов по overqualified, но это другое), а почему? потому что мне просто жуть как интересно вообще всё в IT, потому что я самоучка, который любит своё дело, потому что я поставил крест на алкоголе и наркотиках и больше не калечу свой мозг, потому что веду активный образ жизни и интересуюсь всем на свете, причем и гуманитарными и техническими направлениями, потому что это реально моё призвание.
Если Вам приходится притворяться программистом, а не быть им, может это всё таки не Ваше?
Как много людей могут с уверенностью назвать что-то их призванием? Хорошо, что Вы можете.
Советы как раз для тех, кто не разработчик для мозга костей, а может только наполовину или вообще пришел в профессию чисто ради бабок, тоже на мой взгляд валидная причина. Особенно сейчас, когда количество рекламы онлайн курсов зашкаливает и всем обещают интересные задачи, креативную работу и горы золота.
Интересно было бы почитать советы с Вашей стороны, что Вами движет?
Я искренне, глубочайше уверен, что если тебя не прёт от программирования как такового, то в разработке ПО тебе делать нечего. Наполовину не получится. Ради бабок не получится. Много чего в жизни можно делать ради бабок (таксистом работать например), но не писать код. Почему, я не знаю, это практическое наблюдение.
Уже 7 лет в разработке. Сижу ради денег. Уже добрался до FAANG. Программирование терпеть не могу. Но буду терпеть, где я еще такие деньги заработаю
Вот он, настоящий героизм! /irony
А как/когда/чем/зачем вы ЖИВЁТЕ? /серьезно
Поздравляю, у вас хорошие нервы и низкий порог ответсвенности. Но, семь лет - это немного. Еще парочку и наступит оно - выгорание. А там только в таксисты или менеджеры, что в прочем одно и то же.
Если таксистом или менеджером будут платить такие деньги то я только за. А в целом я пока каждые 3 года полностью меняю специальность с повышением зарплаты, так что в принципе выгореть не успеваю. Щас еще пару тройку лет в европе поработаю, потом в штаты на удвоенную зарплату, так до пенсии надеюсь и протяну без выгорания.
Здесь 11 лет, ему тоже "еще парочка" осталась, думаю.
Главный момент - лучше пойти в таксисты или менеджеры после того, как поработаешь за хорошие деньги или до?
нередко дорастают до крепких миддлов или даже синьоров, они хорошие исполнители и их навыков более чем хватает для успешного решения задач бизнеса
У меня есть друг с таким подходом в программирование пришёл, исключительно ради денег. Уже 11 лет в профессии, от формошлёпа дорос до Engineering Manager в крупной международной компании.
Глядя на него — наоборот завидую, что он к разработке практически без эмоций подходит, у него не подгорает, когда что-то откровенно плохо сделано. В трудных ситуациях он всегда с холодной головой.
Я сейчас работаю над своими исследованиями и немного контрибьючу в опенсорс. Пока вообще ничего за это не получаю - живу только за счет ранее созданных пассивных источников, что много ниже, чем мог бы работая на зп, но мне интересно задумку в жизнь воплотить и выложить её на гитхаб под MIT, без всяких коммерческих притязаний и путей монетизации. Движет мной любопытство и интерес. Вот у Вас была в детстве любимая игрушка в которой надо было как то креативить? Лего, какой то другой конструктор, пластилин там и тд? Такая, от которой за уши не оттащишь, залипательная-залипательная? Вот то же самое что с этим занятием Вами двигало, мной движет во всём, что касается IT. Я когда начинал программить (конец 80-х, 90-е), сказать девушке, что ты компьютерщик - это поставить крест на всей романтике, потому что гики и ботаны были не то, что не в моде, а даже в минусе - крутыми были маскулинность и сила. Примерно вот такой был средний образ. По статусу были сравнимы с дежурным электриком - младший придаток бухгалтерии и не было космических зарплат, клише про интеллектуальную элиту и всенародного хайпа "войти в айти". Вот просто спросите себя - в те времена вы бы пошли в программисты, или нет?
Что посоветовать? Ну, раз уж взялись за это дело, то попробуйте разжечь пламя интереса в себе, эксперементируйте, придумывайте, разбирайтесь, самообучайтесь постоянно. В Японии есть такое понятие "Шокунин", по сути "мастер своего дела", так вот я посоветую любому, кто выбрал свою дорогу в какой то области, осознать, что это не рррраз и ты синьор ассемблера - это долгий путь проб и ошибок, усердной работы над саморазвитием. Поставьте себе цель не бабла заработать как можно больше, а стать реально гуру, экспертом, профессионалом - по настоящему разобраться в теме от и до. Может тогда вдруг тоже обнаружите, что это Ваше призвание, а деньги - это плохая мотивация в любой сложной области, настоящий специалист рождается из увлечения самой специальностью, а не размером её оплаты.
Такой вот парадокс - что бы в бабловой профессии бабла поднять, надо перестать думать о бабле и начать думать о профессии ) как то так )
Искренне рад за вас (без шуток, если что, всегда приятно читать о том, что человек нашёл себя и радуется жизни)!
Но скажите, пожалуйста, где бизнесу взять достаточно таких, как вы? Или что делать людям, которым нравится деятельность, доходов с которой хватит только на прикрытие наготы? Зато они могут двигать таски в джире, чтобы оплачивать счета, а в свободное время занимаются интересными им вещами. Win-win же.
Спасибо
Выучи английский
Мне кажется если вы в ИТ, то он учится сам по себе без прикладывания усилий, другой вопрос сможете ли вы на нём разговаривать, это совсем другая история.
Подготовься к собеседованию
На мой взгляд бессмысленное занятие, это как сдать ЕГЭ на 100 баллов, а потом не уметь посчитать дискриминант.
Гугли, перед тем как спрашивать
Это верно и нужно для жизни, а не только для ИТ, но
тебе действительно нужно подумать как задать вопрос так, чтобы гугл его понял и нашел то, что тебе нужно
сегодня это заметно проще, я уже лет 10 как не пишу и не формулирую вопросы как доктор наук, кстати многое гуглили до нас и ответы на вопросы "прога для игр" дают куда более точные ответы, так как мы же помним, что дилетантов в мире куда больше, а значит гугл учится на их вопросах.
ты будешь задавать коллегам более сложные вопросы и будешь казаться немного умнее, чем ты есть.
как человек со стажем в ИТ в 24 года скажу - всем плевать что я там и как я там кому кажусь, а обратная сторона этой вишенки будет в том, что тебе навалят работы которую ты не тянешь, но ведь ты сам только что показался всем умным, значит должен уметь. А кому оно надо это превозмогание? я наоборот стал вести себя как глупый и моя жизнь стала проще, на зарплату никак не повлияло.
Настрой свою среду разработки
Сегодня питон, завтра c#, послезавтра java - под всё не нанастраиваешься. Я наоборот все интерфейсы всегда использую "по умолчанию", что всегда и везде совместимо, я могу сесть за любой ПК и сразу им пользоваться.
Следуй инструкциям и гайдлайнам своей команды
Как только встречу адекватного руководителя, то обязательно так сделаю. Пока, к несчастью, такие на горизонте не появлялись.
Имхо, у вас ошибка выжившего.
Интересный взгляд, вполне может быть и ошибка выжившего, но эти советы отчасти появились от моего небольшого опыта тимлидерства и работы с младшими коллегами, когда они явно игнорировали все то, что написано выше.
И элементарно загуглить, и просто соблюдать нейминг, и запускать тесты. И в итоге описанное то, что я делал и хотел бы чтобы делали коллеги с которыми я работаю)
Есть один вопрос только, как часто приходится садиться за любой пк и начинать работать? Звучит немного странно, сразу в голову приходят хакеры из голливудских фильмов, которые с рандомного пк взламывают Пентагон) я
Есть один вопрос только, как часто приходится садиться за любой пк и начинать работать?
тоже стало интересно - как такое сделать?
пока что единственный вариант когда настраиваешь универсальный RDP и тогда с любого другого компа логинишься на свой рабочий ...
Если любой ПК - не совсем любой, а внутри организации, то при логине монтируется /home, а при загрузке самого ПК - еще и /usr/ со всем софтом, что организация пользуется.
Собственно, когда-то давно оно так и работало, но потом как-то кончилось.
то при логине монтируется /home
Сетевые профили не есть гуд, за удобством скрываются другие проблемы. Но, у меня на работе три домена, три профиля, а еще два локальных профиля, настраивать каждый не вижу смысла, это абсолютно никак не повлияет на качество работы, а через год я могу работать уже в другом месте, где вообще нельзя настраивать профиль. Поэтому не вижу смысла.
PS: слабо представляю переносимость софта через сетевую папку, у нас софт разный для разных рабочих мест, объем общий около 150 Гб, запуск многих пакетов не с локального SSD будет очень печальным.
Иногда бывает и другое: от смены до смены компьютера банально забывается "где и что подкручивал". Поэтому со временем и приходишь к неким обобщенным дефолтам.
В какой-то мере это перекликается и с теми же паттернами программирования - в общем-то это просто рецепты, возможно даже не самые идеальные в конкретном месте, но вот они привычны, понятны, узнаваемы и в итоге с первых строк чужого кода понятно что "убийца садовник", что не в детективе только на пользу.
небольшого опыта
это и есть то, почему ваше мнение о проблеме слишком нерепрезентативно. Я каждый день вижу людей, разного возраста, которые не умеют нормально пользоваться ПК, но это не значит что если написать статью с советами как пользоваться ПК это будет охватывать большую аудиторию. Как правило в любой профессиональной сфере есть люди которые удивляют своей тупостью, причем на разных должностях и всегда задумываешься как этот человек вообще работает. Но вот так.
как часто приходится садиться за любой пк и начинать работать? Звучит немного странно
Вообще каждый день, у меня 650 ПК на обслуживании.
А если про разработку, то у меня условно 4 рабочих места, жмякаю Visual Studio Installer и в путь, то есть от начала разработки на конкретном ПК меня отделяет только время на установку VS.
Имхо, в таком случае это у вас ошибка выжившего. Всё-таки обычно у разработчиков одно рабочее место, может ещё одно дома. Необходимость регулярно переключаться с одного места - это какой-то очень специфичный кейс. А чем вы занимаетесь, если не секрет?
Слова "обычно" как раз и говорят об ошибке выжившего, то есть когда вы опираетесь на какой-то универсальный стандарт, на единую модель поведения, вы же согласитесь что это невозможно в принципе?
Ну я за всех разработчиков не скажу, каждый страдает как хочет, у меня дома 4 ПК, ноутбук, на работе 4 ПК. Причем профили такие что настраивать их нет смысла. Что-то конечно настраивается, но по минимуму.
Я не столько за то, чтобы у всех разрабов было много рабочих мест, а за то, чтобы человек без особых телодвижений быстро мог сразу начать работать. Я не поверю что в компании у вас 100%-я свобода кастомизации рабочего места, дома - соглашусь, но не на работе.
Родственник работает в геймдеве, у него несколько ПК с разным железом, несколько тестовых серверов, отдельные машины для PlayStation и XBOX с разным железом. С дома ко всем может подключаться удаленно, какой-то особой кастомизации у него нет.
Я просто реально не могу представить зачем кастомизировать всё настолько что кастомизация превращается во что-то ради самой кастомизации. Ну или банально вам нужно к соседу подсесть и на его ПК на его рабочем месте что-то показать и вдруг у него раскладка ДВОРАК, левая мышка, все шорткаты другие и т.д. - и что дальше? Таких примеров из жизни могу сотню рассказать и любители Punto Switcher всякие, и любители настраивать браузер так что он сам превращается в отдельный компьютер, а без аддонов вообще не знают как пользоваться браузером.
Не секрет чем я занимаюсь, но не вижу смысла говорить, так как вы будете это использовать как аргумент в разговоре, а это к теме не относится. Скажу лишь что сейчас я не разработчик в том смысле как подаёт автор статьи (вы). У вас это собирательный образ современной молодой команды в какой-то строго определенной компании работающей по какому-то шаблону. Возможно в Москве или Европе таких много, я такие не видел ни разу, общался какое-то время с российскими разрабами HP, Toshiba, Сбер - у них всё совсем иначе и не совпадает с тем что пишете вы.
PS: единственная кастомизация с моей стороны это темная тема в VS и браузере.
PPS: Надеюсь вы понимаете что я не наезжаю и у меня нет зла к вам, просто вижу что информация затрагивает какой-то узкий сегмент людей.
Вероятно я не достаточно ясно про настройку среды выразился. В моем понимании - это использовать средств автоматизации, которые помогают соблюдать стандарты языка + выучить стандартные горячие клавиши для их применения и быстрого использования IDE, без фанатизма.
Согласен, что я говорю про достаточно определенный тип разработчиков. Аля бэк/фронт, может отчасти мобильщики. Понимаю, что есть ембеддед, геймдев, сетевые разработчики и еще куча разных со своей спецификой, которая сильно влияет на работу. Но я все же придерживаюсь совета, что свою среду в любом случае знать нужно, независимо от того, какая она. Вероятно вместо "настроить" в заголовке этого совета можно было бы использовать что-то вроде "Знай свои инструменты", но звучало бы слишком обще тогда)
Ни в коем случае не чувствую, что вы наезжаете. Наоборот интересна и полезна другая точка зрения. Спасибо за ответы)
Хм, я понял вас. Да, возможно какие-то обобщение есть в словах это и зацепило. Про инструменты, в таком понимании как вы написали сейчас, абсолютно поддерживаю вашу точку зрения - знание инструмента это тоже немалый скилл, а для разработчика и знание дебаггера, это вообще что-то из области талантов, мне например даётся всегда тяжело.
Советы полезные, только не понимаю при чём тут притворство.) Вполне нормальный список навыков, которые помогут стать Джуном +, а то и мидлом
А в чем тут притворство-то?
В том, что вам не нравится программировать? Сочувствую. Большинство людей на этой планете не любит свою работу. Но с точки зрения бизнеса это совершенно не важно.
Важно лишь то, как успешно вы решаете поставленные задачи.
Если вы нормально работаете как программист, то, по "утиной типизации" вы и есть программист.
А чувствуете ли вы себя хорошим программистом, плохим, собачкой или котиком - бизнесу без разницы. На зарплату это не влияет. Влияет немного на головняк вашего тимлида, но на то он и тимлид, чтобы с этим разбираться.
Вы что! Нельзя работать программистом и не любить свою работу! Это просто невозможно. (сарказм)
Так таксисты работают в такси только потому, что им нравиться водить машину и общаться с новыми людьми. А проститутки просто очень любят секс. А водители ассенизаторской машины ... тоже что-то любят. :)
в такси только потому, что им нравиться водить машину
А вот и нет, они водят машину для души, а так у них бизнес.
Нельзя работать программистом и не любить свою работу
Выше в ветке по комментам неиронично говорят, что нельзя. Я не могу сказать, что люблю программирование, у меня получается делать то, что требуется по работе, я стараюсь ответственно подходить к любой задаче и разбираться до мелочей в том, что делаю. Но я не иду делать свой фреймворк, у меня даже желания не хватает или времени нет сделать нормальный пет проект.
Программирование позволило мне заработать на первую машину, затем переехать в США, в США накопить/вложить средств на случай, если я соберусь в менеджеры или таксисты, а также позволить себе посещать психолога, кататься на лыжах в горах, ходить в походы, в целом путешествовать по странам, заниматься музыкой (в частности - пианино) с преподавателем, вкусно есть в разных заведениях и играть в любые игры на любых платформах.
С точки зрения Д'Артаньянов разработки я, как простой мушкетер - не должен существовать, видимо.
совет - "выучи Английский" рядом с советом "настрой IDE" .. это что одного уровня сложности задачи??
Я бы ещё добавил "Будь смелым". Можно очень многое узнать, если всё-же не боишься задать неправильный вопрос, отписаться на вакансию, которая, по твоему мнению, слишком крута для тебя, не боишься общаться с собеседующим и т.д.
Полезный навык)
У самурая нет цели, есть только путь. И этот путь ведёт к успеху. Homo ludens как он есть: игра в развитие, развитие через игру. Браво автору!
Спасибо, учту пункт про английский.
Отличные советы. Многие забывают про изучение английского языка и его активного применения на рабочем месте, избегая компании, где его используют.
Хотя в современных реалиях без него никуда, если ты думаешь о своем развитии и хочешь быть человеком мира.
Не знаю, откуда эта фраза у меня в голове, мне приятно думать, что это я ее изобрёл (что вряд ли):
Казаться - уже наполовину быть.
Однако позже встретил англоязычный вариант:
Fake it till you make it
Axax, либо это обучающий стеб, либо автор, на самом деле, отличный разработчик c синдромом самозванца) а так да - fake it till you make it))
5 советов, чтобы успешно притворяться разработчиком