Видеть путь и пройти его не одно и тоже
Я стал разработчиком из-за недостатка цифровых игр. Звучит довольно банально. Но когда я ещё учился в школе, то мечтал о Super Nintendo и Play Station, но мог позволить себе только китайскую версию Nintendo ES. Из-за этого я вырастил в себе желание делать то, чего не могу получить. Это, кстати, относится и к настольным играм, но об этом, возможно, напишу в другой раз. Так я пошел учиться на программиста.
И тут кроется один нюанс. Одно дело иметь желание писать свои игры, а другое дело понимать сам процесс разработки, что для этого нужно знать и в каком направлении двигаться. Важно понимать это максимально полно, стараться узнать все детали и составить четкий план достижения этой цели. У меня этого не было. Поэтому со временем цель смазалась, первоначальный план был вытеснен обучением пользования ПК, а навыки копились из того, что было необходимо в учёбе. Поэтому мой совет, будьте усерднее и не сходите с первоначального пути.
В дальнейшем ваше окружение, восприятие мира и навыки изменятся. И не вы будете управлять обстоятельствами, а они вами. Поэтому нужно очень сильно постараться, чтобы преодолеть все трудности. К этому нужно быть готовым заранее, нужно приготовить запас прочности. Не многим это удаётся, но осиливших наверняка ждёт успех. Представьте, как вы потом будете рассказывать о том, как достигли своей цели, сами. Это дорогого стоит.
А что же я? В итоге я не пишу компьютерные игры, никакие. Я занимаюсь веб разработкой. Это оказалось очень увлекательным, это меня затягивает с головой, это позволяет мне раскрыться. Хотя иногда я жалею, что так и не стал системным разработчиком. Но я не далеко ушёл от своего изначального плана, я смог научиться и занимаюсь тем, о чём мечтал ещё в школе, пусть и немного в другом направлении. Поэтому важно поставить себе четкую цель и упорно к ней двигаться. И всё получится.
Я стал разработчиком из-за недостатка цифровых игр. Звучит довольно банально. Но когда я ещё учился в школе, то мечтал о Super Nintendo и Play Station, но мог позволить себе только китайскую версию Nintendo ES. Из-за этого я вырастил в себе желание делать то, чего не могу получить. Это, кстати, относится и к настольным играм, но об этом, возможно, напишу в другой раз. Так я пошел учиться на программиста.
И тут кроется один нюанс. Одно дело иметь желание писать свои игры, а другое дело понимать сам процесс разработки, что для этого нужно знать и в каком направлении двигаться. Важно понимать это максимально полно, стараться узнать все детали и составить четкий план достижения этой цели. У меня этого не было. Поэтому со временем цель смазалась, первоначальный план был вытеснен обучением пользования ПК, а навыки копились из того, что было необходимо в учёбе. Поэтому мой совет, будьте усерднее и не сходите с первоначального пути.
В дальнейшем ваше окружение, восприятие мира и навыки изменятся. И не вы будете управлять обстоятельствами, а они вами. Поэтому нужно очень сильно постараться, чтобы преодолеть все трудности. К этому нужно быть готовым заранее, нужно приготовить запас прочности. Не многим это удаётся, но осиливших наверняка ждёт успех. Представьте, как вы потом будете рассказывать о том, как достигли своей цели, сами. Это дорогого стоит.
А что же я? В итоге я не пишу компьютерные игры, никакие. Я занимаюсь веб разработкой. Это оказалось очень увлекательным, это меня затягивает с головой, это позволяет мне раскрыться. Хотя иногда я жалею, что так и не стал системным разработчиком. Но я не далеко ушёл от своего изначального плана, я смог научиться и занимаюсь тем, о чём мечтал ещё в школе, пусть и немного в другом направлении. Поэтому важно поставить себе четкую цель и упорно к ней двигаться. И всё получится.
Публичная деятельность
Нужно ли разработчику заниматься вещами, связанными с программированием, но не связанными с основной деятельностью? Я считаю, что больше да, чем нет. Но логично, что каждый решает сам по мере своих сил. Если это приносит кому-то пользу, то тут нечего думать, нужно заниматься. Если же тут корыстная выгода, то я вам не мама, чтобы вас осуждать.
Разработчик может быть ментором для кого-то, может вести информационный блог или канал с полезными статьями, может делать образовательный контент или заниматься обучением в онлайн школе, может участвовать в разработке полезного публичного проекта, может быть организатором различных хакатонов или встреч, может быть экспертом на различных форумах или в группах по интересам, а может просто жить своей работой и не делать ничего другого, связанного с разработкой.
Если вы всё же решили заниматься чем-то, то это не должно быть копированием уже созданного контента, делайте своё. Изучите уже созданное другими, выясните чего не хватает и занимайтесь, если у вас есть к этому интерес и способности. Делать, чтобы делать, это плохая затея, которая умрёт на пол пути. Другое дело, если у вас есть желание, но недостаточно опыта, тогда стоит подождать какое-то время и набраться навыков. А то кроме мамы и сестры это никому не будет интересно.
Для опытных разработчиков публичная деятельность должна быть как следствие их большого опыта, которым можно поделиться. Или же они могут использовать свои знания для получения материальной выгоды, а может даже самоутверждения. Но главное генерируемый контент.
И маленький совет. Если вы по характеру человек общительный, то можете хорошо понимать, где есть информационный вакуум. В таком случае нужно заранее определить для себя направление и способ вещания. В наше время это не сложно. Но нужно действовать.
Нужно ли разработчику заниматься вещами, связанными с программированием, но не связанными с основной деятельностью? Я считаю, что больше да, чем нет. Но логично, что каждый решает сам по мере своих сил. Если это приносит кому-то пользу, то тут нечего думать, нужно заниматься. Если же тут корыстная выгода, то я вам не мама, чтобы вас осуждать.
Разработчик может быть ментором для кого-то, может вести информационный блог или канал с полезными статьями, может делать образовательный контент или заниматься обучением в онлайн школе, может участвовать в разработке полезного публичного проекта, может быть организатором различных хакатонов или встреч, может быть экспертом на различных форумах или в группах по интересам, а может просто жить своей работой и не делать ничего другого, связанного с разработкой.
Если вы всё же решили заниматься чем-то, то это не должно быть копированием уже созданного контента, делайте своё. Изучите уже созданное другими, выясните чего не хватает и занимайтесь, если у вас есть к этому интерес и способности. Делать, чтобы делать, это плохая затея, которая умрёт на пол пути. Другое дело, если у вас есть желание, но недостаточно опыта, тогда стоит подождать какое-то время и набраться навыков. А то кроме мамы и сестры это никому не будет интересно.
Для опытных разработчиков публичная деятельность должна быть как следствие их большого опыта, которым можно поделиться. Или же они могут использовать свои знания для получения материальной выгоды, а может даже самоутверждения. Но главное генерируемый контент.
И маленький совет. Если вы по характеру человек общительный, то можете хорошо понимать, где есть информационный вакуум. В таком случае нужно заранее определить для себя направление и способ вещания. В наше время это не сложно. Но нужно действовать.
Широкий кругозор или экспертность
Что же эффективнее и полезнее, иметь большой кругозор и обширные знания в различных областях, или быть экспертом в одном конкретном направлении? Думаю очевидно, что это зависит от ситуации и обстоятельств. Поэтому я не буду советовать развиваться в каком-то одном направлении или же расширять кругозор в разных. Просто порассуждаем о том и другом, а вы сами сделаете свой выбор.
В школе и университете нас обучали всему и по не многу. После школы хоть и пытались дать какое-то специальное образование, но в целом это были разнообразные дисциплины и направления. Поэтому мы сами должны были сделать свой выбор и двигаться в ту или иную сторону. Наверняка многих пугала эта неопределённость. Потратить своё время на изучение чего-то одного, а потом разочароваться в этом. В какой-то степени это так. Но уверяю, всё это будет не напрасно. Так вы поймёте, что это не ваше и сможете отбросить этот вариант. Да и любые полезные знания могут в дальнейшем пригодиться. И никогда не поздно научиться чему-то новому.
Если идти в сторону расширения кругозора, то вы будете намного более гибким, у вас будет более креативное мышление, и вы сможете лучше понимать суть происходящего. В работе вы сможете быстро адаптироваться и уже потом можно будет попытаться сосредоточиться на чём-то конкретном. Во многом вы сможете стать ценным и универсальным сотрудников, но всё же останетесь на среднем уровне. Поэтому расширение кругозора выгоднее в том случае, если вы часто будете менять работу и будете постоянно расширяться в разных направлениях. В дальнейшем вам будет проще выбрать, где закончить свою карьеру, но сложно будет иметь экспертное мнение. Есть шанс стать преподавателем начальных и базовых знаний, неплохим ментором для начинающих. Поэтому это неплохой вариант для экстравертов.
Если же идти в эксперты, то вы будете иметь глубокие знания в конкретной области, будете решать свою задачу быстро и качественно, в то время, когда эти задачи будут сложные и трудные для остальных, но не для вас. В работе вы сможете без особых проблем найти себе применение в своей области и покажете достойный результат, но есть шанс оказаться за бортом, если по вашей специальности не будет вакансий или же она потеряет актуальность. Обычно эксперты по долгу работают в одном месте, считаются ценными и незаменимыми сотрудниками, но рискуют быть уволенными первыми, если их амбиции и незаменимость станут проблемой для коллектива.
В итоге получается так, что хороша золотая середина. Но это совершенно безрисковый путь. А как я писал выше рисковать необходимо. Поэтому важно знать, к чему может привести тот или иной выбор и быть готовым к последствиям.
Что же эффективнее и полезнее, иметь большой кругозор и обширные знания в различных областях, или быть экспертом в одном конкретном направлении? Думаю очевидно, что это зависит от ситуации и обстоятельств. Поэтому я не буду советовать развиваться в каком-то одном направлении или же расширять кругозор в разных. Просто порассуждаем о том и другом, а вы сами сделаете свой выбор.
В школе и университете нас обучали всему и по не многу. После школы хоть и пытались дать какое-то специальное образование, но в целом это были разнообразные дисциплины и направления. Поэтому мы сами должны были сделать свой выбор и двигаться в ту или иную сторону. Наверняка многих пугала эта неопределённость. Потратить своё время на изучение чего-то одного, а потом разочароваться в этом. В какой-то степени это так. Но уверяю, всё это будет не напрасно. Так вы поймёте, что это не ваше и сможете отбросить этот вариант. Да и любые полезные знания могут в дальнейшем пригодиться. И никогда не поздно научиться чему-то новому.
Если идти в сторону расширения кругозора, то вы будете намного более гибким, у вас будет более креативное мышление, и вы сможете лучше понимать суть происходящего. В работе вы сможете быстро адаптироваться и уже потом можно будет попытаться сосредоточиться на чём-то конкретном. Во многом вы сможете стать ценным и универсальным сотрудников, но всё же останетесь на среднем уровне. Поэтому расширение кругозора выгоднее в том случае, если вы часто будете менять работу и будете постоянно расширяться в разных направлениях. В дальнейшем вам будет проще выбрать, где закончить свою карьеру, но сложно будет иметь экспертное мнение. Есть шанс стать преподавателем начальных и базовых знаний, неплохим ментором для начинающих. Поэтому это неплохой вариант для экстравертов.
Если же идти в эксперты, то вы будете иметь глубокие знания в конкретной области, будете решать свою задачу быстро и качественно, в то время, когда эти задачи будут сложные и трудные для остальных, но не для вас. В работе вы сможете без особых проблем найти себе применение в своей области и покажете достойный результат, но есть шанс оказаться за бортом, если по вашей специальности не будет вакансий или же она потеряет актуальность. Обычно эксперты по долгу работают в одном месте, считаются ценными и незаменимыми сотрудниками, но рискуют быть уволенными первыми, если их амбиции и незаменимость станут проблемой для коллектива.
В итоге получается так, что хороша золотая середина. Но это совершенно безрисковый путь. А как я писал выше рисковать необходимо. Поэтому важно знать, к чему может привести тот или иной выбор и быть готовым к последствиям.
❤1
У каждого свой путь
Когда я учился в университете, то жил в студенческом общежитии. Нас тогда было четверо в одной комнате. Четыре айтишника. Нет, мы не пытались взломать сайт Пентагона, мы просто гоняли "кваку" по сети. Но я не про это. Каждый из нас по своему шёл к своему диплому.
Один любил играть на гитаре. В итоге он не стал разработчиком, да и до диплома он не доучился. Но у него всё хорошо. Второй не особо увлекался разработкой, зато упорно совершенствовал свои навыки работы с ПК. Диплом он получил, но на этом IT для него закончилось. Третий был отъявленным разработчиком. На 3 курсе дизассемблировал приложения, писал снифферы, учился ночами, а отсыпался днём. Я же был ответственным и увлечённым IT-шником. Программа курса говорила учить это, я это учил, молча недоумевая, как же это мне поможет в дальнейшем.
Так вот этот третий уже на 3 курсе чётко понимал что, как и зачем. К концу 4-го курса он уже был своим для преподавателей своей специальности, а на 5-ом он уже работал в другом городе и приезжал только для сдачи экзаменов и курсовых. В итоге диплом на 5, работа в хорошей компании и цель достигнута.
Когда я думаю об этом, я пытаюсь поставить себя на его место. Мог ли я поступить также? Мне казалось, что он что-то знает наперёд. Хотя сейчас я понимаю, что тут ничего сложного. Главное уверенно делать то, что у тебя хорошо получается. И не поступать глупо. Просто идти напролом, старательно используя все возможности. И поверьте, преподаватели тоже могут оценить ваше рвение и старание. Главное - не останавливаться.
Когда я учился в университете, то жил в студенческом общежитии. Нас тогда было четверо в одной комнате. Четыре айтишника. Нет, мы не пытались взломать сайт Пентагона, мы просто гоняли "кваку" по сети. Но я не про это. Каждый из нас по своему шёл к своему диплому.
Один любил играть на гитаре. В итоге он не стал разработчиком, да и до диплома он не доучился. Но у него всё хорошо. Второй не особо увлекался разработкой, зато упорно совершенствовал свои навыки работы с ПК. Диплом он получил, но на этом IT для него закончилось. Третий был отъявленным разработчиком. На 3 курсе дизассемблировал приложения, писал снифферы, учился ночами, а отсыпался днём. Я же был ответственным и увлечённым IT-шником. Программа курса говорила учить это, я это учил, молча недоумевая, как же это мне поможет в дальнейшем.
Так вот этот третий уже на 3 курсе чётко понимал что, как и зачем. К концу 4-го курса он уже был своим для преподавателей своей специальности, а на 5-ом он уже работал в другом городе и приезжал только для сдачи экзаменов и курсовых. В итоге диплом на 5, работа в хорошей компании и цель достигнута.
Когда я думаю об этом, я пытаюсь поставить себя на его место. Мог ли я поступить также? Мне казалось, что он что-то знает наперёд. Хотя сейчас я понимаю, что тут ничего сложного. Главное уверенно делать то, что у тебя хорошо получается. И не поступать глупо. Просто идти напролом, старательно используя все возможности. И поверьте, преподаватели тоже могут оценить ваше рвение и старание. Главное - не останавливаться.
❤1
Градации разработчиков и зачем это нужно
Для меня разработчики делятся на 3 основных типа: джун, миддл, сеньор. Джун это тот, кому говорят, что делать и как это сделать. Миддл это тот, кому говорят, что делать, и он сделает. Сеньор это тот, кому не надо говорить. Он сам знает, что нужно сделать. Конечно, есть ещё всякие тимлиды, техлиды, СТО и т.д. Но это уже разработчики-руководители в разных пропорциях.
Конечно же это всё условности, чтобы хоть как-то определять компетенции программиста. У каждой компании могут быть свои градации (типа Мидлл++, High middle и т.д.) с определенными параметрами. Кому-то это нужно для отдела кадров, кому-то для своего чсв. Не советую привязываться к этому, но нужно знать об этом. Хотя бы просто для того, чтобы говорить на понятных терминах с другими.
Можно гнаться за этими лычками. Можно мечтать о том или ином статусе. Можно самому придумать в своей компании массу подобных делений, но это всё мелочи. Важно другое. А именно - решать задачи бизнеса. Пусть ты хоть джун с вчерашним дипломом, хоть сеньор 40+. Если задачи решаются, а проблем ты не создаёшь, то ты идеальный сотрудник.
Поэтому советую быть проще и относиться к этому спокойно. Если вас спросят на собеседовании кем ты себя считаешь, или в dev клуб будут пускать не ниже мидлл+. То смело отвечайте, что это не важно, важно чтобы заказчик был доволен. В любом случае у вас есть два пути. Или погрязнуть в пучине рангов и статусов, или быть свободным, успешным и эффективным разработчиком. Чего и вам желаю!
Для меня разработчики делятся на 3 основных типа: джун, миддл, сеньор. Джун это тот, кому говорят, что делать и как это сделать. Миддл это тот, кому говорят, что делать, и он сделает. Сеньор это тот, кому не надо говорить. Он сам знает, что нужно сделать. Конечно, есть ещё всякие тимлиды, техлиды, СТО и т.д. Но это уже разработчики-руководители в разных пропорциях.
Конечно же это всё условности, чтобы хоть как-то определять компетенции программиста. У каждой компании могут быть свои градации (типа Мидлл++, High middle и т.д.) с определенными параметрами. Кому-то это нужно для отдела кадров, кому-то для своего чсв. Не советую привязываться к этому, но нужно знать об этом. Хотя бы просто для того, чтобы говорить на понятных терминах с другими.
Можно гнаться за этими лычками. Можно мечтать о том или ином статусе. Можно самому придумать в своей компании массу подобных делений, но это всё мелочи. Важно другое. А именно - решать задачи бизнеса. Пусть ты хоть джун с вчерашним дипломом, хоть сеньор 40+. Если задачи решаются, а проблем ты не создаёшь, то ты идеальный сотрудник.
Поэтому советую быть проще и относиться к этому спокойно. Если вас спросят на собеседовании кем ты себя считаешь, или в dev клуб будут пускать не ниже мидлл+. То смело отвечайте, что это не важно, важно чтобы заказчик был доволен. В любом случае у вас есть два пути. Или погрязнуть в пучине рангов и статусов, или быть свободным, успешным и эффективным разработчиком. Чего и вам желаю!
Одноимённые разработчики
В нашей компании есть два разработчика, у которых одинаковые имена. Поэтому когда у нас происходит рабочий созвон и на нём присутствуют оба (а чаще всего так и бывает), то это вызывает проблемы - не всегда понятно к кому обращаются.
Для решения этого небольшого, но досадного недостатка, я предложил, чтобы ко мне обращались Александр (я всё же старше), а к другому Саша. Остальные согласились, но пришлось подождать какое-то время, пока все к этому привыкли. Но в целом после этого проблема ушла. По крайней мере стало намного лучше, чем было.
Но почему так происходило? Точного ответа нет. Скорее всего так всем было проще. Но есть ощущение, что одного из нас уважали меньше. Я не стал выяснять, а решил просто избавиться от проблемы. Думаю я смог.
Можно подумать, что проблема ничтожна, но она тратит время каждого, отвлекает от сути. Потому нужно решать такие мелочи. Ведь из мелкого складывается большое, а из крошечного вырастает огромное. Нам огромные проблемы не нужны.
В нашей компании есть два разработчика, у которых одинаковые имена. Поэтому когда у нас происходит рабочий созвон и на нём присутствуют оба (а чаще всего так и бывает), то это вызывает проблемы - не всегда понятно к кому обращаются.
Для решения этого небольшого, но досадного недостатка, я предложил, чтобы ко мне обращались Александр (я всё же старше), а к другому Саша. Остальные согласились, но пришлось подождать какое-то время, пока все к этому привыкли. Но в целом после этого проблема ушла. По крайней мере стало намного лучше, чем было.
Но почему так происходило? Точного ответа нет. Скорее всего так всем было проще. Но есть ощущение, что одного из нас уважали меньше. Я не стал выяснять, а решил просто избавиться от проблемы. Думаю я смог.
Можно подумать, что проблема ничтожна, но она тратит время каждого, отвлекает от сути. Потому нужно решать такие мелочи. Ведь из мелкого складывается большое, а из крошечного вырастает огромное. Нам огромные проблемы не нужны.
👍1
Если заболел на удалёнке
Тема, которая уже не так актуальна, но всё ещё имеет место быть. Казалось бы. Как поступить, если ты работаешь удалённо, но заболел? Ответ не очевиден из-за того, что существует масса факторов. Поэтому для простоты предположим, что вы работаете по ТК, у вас есть медицинский полис и нет расширенного ДМС.
Если бы у вас была оплата по часам, то естественно выгодно работать даже больным. Хотя выгодно ли? Болезнь это стресс для организма, он работает в необычном режиме и любые перегрузки чреваты. Поэтому отдыхать необходимо.
Кто-то может подумать, что простуда, грипп, ОРВИ это временно и не сильно помешает работе, просто надо выпить таблетку. Но нет. Даже в таком случае надо отдыхать и лечиться. Не нужно бояться заявить об этом. У вас есть право восстановиться и отложить работу на потом.
Кто-то скажет, что это же нужно ехать к врачу, чтобы получить справку. Нужно. Иначе никак. Здоровье дороже. Хотя признаюсь, я сам не настолько сознательный в этом плане, каким надо было бы быть. И я иногда работал, будучи больным на удалёнке. Но поверьте, это того не стоит. Научитесь заботиться о себе, тогда ваша жизнь будет более полноценной.
Тема, которая уже не так актуальна, но всё ещё имеет место быть. Казалось бы. Как поступить, если ты работаешь удалённо, но заболел? Ответ не очевиден из-за того, что существует масса факторов. Поэтому для простоты предположим, что вы работаете по ТК, у вас есть медицинский полис и нет расширенного ДМС.
Если бы у вас была оплата по часам, то естественно выгодно работать даже больным. Хотя выгодно ли? Болезнь это стресс для организма, он работает в необычном режиме и любые перегрузки чреваты. Поэтому отдыхать необходимо.
Кто-то может подумать, что простуда, грипп, ОРВИ это временно и не сильно помешает работе, просто надо выпить таблетку. Но нет. Даже в таком случае надо отдыхать и лечиться. Не нужно бояться заявить об этом. У вас есть право восстановиться и отложить работу на потом.
Кто-то скажет, что это же нужно ехать к врачу, чтобы получить справку. Нужно. Иначе никак. Здоровье дороже. Хотя признаюсь, я сам не настолько сознательный в этом плане, каким надо было бы быть. И я иногда работал, будучи больным на удалёнке. Но поверьте, это того не стоит. Научитесь заботиться о себе, тогда ваша жизнь будет более полноценной.
Рекомендации для собеседований
Большинству из нас приходится проходить собеседования. Долгие, трудные, разные. Сначала с нами работает hr, затем мы общаемся с тимлидом, потом может прийти СТО, иногда самые одарённые получают тестовое задание, а кому-то в итоге приходит оффер. Это примерная схема. Я проходил десятки собеседований и хочу поделиться своим опытом.
Для начала hr. Все мы должны понимать, что hr не программист и редко имеет техническое образование. Его задача подготовить краткое резюме о нас по заранее заданным критериям. Поэтому иногда они могут задавать странные вопросы или называть что-то не так, как мы привыкли это слышать. Не надо шутить над этим. Такая у них работа. Лучше проявить понимание и тогда вы покажетесь более привлекательными и увеличите свои шансы. Плюс hr не всегда имеет полные данные о том месте, куда он вас пытается нанять. Поэтому лучше подготовиться заранее, прочитать вакансию или составить список вопросов, на которые потом вам ответят.
После этого чаще всего с вами общается тимлид. И это чуть ли не сама важная часть собеседования. Именно тимлид делает заключение и принимает решение о том, подходите вы или нет (только если после этого не предвидится встреча с СТО). Чаще всего вам придётся сделать так, чтобы тимлид увидел в вас себя. Вы можете всё знать. А можете не знать ничего, но с лёгкостью находить нужное. Вы можете иметь сотни крутых проектов в портфолио. Вы можете иметь багаж софт скилов. Хардскилов. Несколько дипломов. Но если вы не подходите под его требования, то вам не повезло. Научитесь понимать таких людей сразу. Ну и не забывайте, что и кодить тоже надо уметь. Если пришлось встретиться с СТО, то вам нужно доказать ему, что вы можете заменить его в ближайшем будущем. В общем человеческий фактор играет важную роль.
Теперь немного про тестовое задание. Его можно выполнять, если вам ну вообще нечего показать. Потому что обычно это или впустую потраченное время, т.к. вас могут использовать для написания кода. Или просто пытаются тянуть время. Лучше сделать пэт проект и показывать его в качестве примера.
Кажется уже вот вот и вам вышлют оффер. Но не нужно торопиться. Всегда задавайте максимальное количество вопросов. О том, чем вам придётся заниматься. Какой в команде воркфлоу. Насколько хорошо команда относится к разработке и как сильно болеет за качество кода. Как часто происходят встречи или созвоны. Не забудьте уточнить про бонусы или корпоративные плюшки. И конечно же спросите про то, какие у вас перспективы. Как минимум покажете свою заинтересованность. А как максимум будете знать, чего вас ждёт в команде и какие условия работы вам предстоят.
Конечно же все собеседования уникальны, но в целом в них есть костяк, о котором я написал. Поэтому вы уже примерно знаете, чего вам ожидать. Да и всегда можно спросить у hr, как проходит отбор. И последний совет. Иногда проходите собеседования без цели найти работу, а просто для того, чтобы держать себя в тонусе. И успехов.
Большинству из нас приходится проходить собеседования. Долгие, трудные, разные. Сначала с нами работает hr, затем мы общаемся с тимлидом, потом может прийти СТО, иногда самые одарённые получают тестовое задание, а кому-то в итоге приходит оффер. Это примерная схема. Я проходил десятки собеседований и хочу поделиться своим опытом.
Для начала hr. Все мы должны понимать, что hr не программист и редко имеет техническое образование. Его задача подготовить краткое резюме о нас по заранее заданным критериям. Поэтому иногда они могут задавать странные вопросы или называть что-то не так, как мы привыкли это слышать. Не надо шутить над этим. Такая у них работа. Лучше проявить понимание и тогда вы покажетесь более привлекательными и увеличите свои шансы. Плюс hr не всегда имеет полные данные о том месте, куда он вас пытается нанять. Поэтому лучше подготовиться заранее, прочитать вакансию или составить список вопросов, на которые потом вам ответят.
После этого чаще всего с вами общается тимлид. И это чуть ли не сама важная часть собеседования. Именно тимлид делает заключение и принимает решение о том, подходите вы или нет (только если после этого не предвидится встреча с СТО). Чаще всего вам придётся сделать так, чтобы тимлид увидел в вас себя. Вы можете всё знать. А можете не знать ничего, но с лёгкостью находить нужное. Вы можете иметь сотни крутых проектов в портфолио. Вы можете иметь багаж софт скилов. Хардскилов. Несколько дипломов. Но если вы не подходите под его требования, то вам не повезло. Научитесь понимать таких людей сразу. Ну и не забывайте, что и кодить тоже надо уметь. Если пришлось встретиться с СТО, то вам нужно доказать ему, что вы можете заменить его в ближайшем будущем. В общем человеческий фактор играет важную роль.
Теперь немного про тестовое задание. Его можно выполнять, если вам ну вообще нечего показать. Потому что обычно это или впустую потраченное время, т.к. вас могут использовать для написания кода. Или просто пытаются тянуть время. Лучше сделать пэт проект и показывать его в качестве примера.
Кажется уже вот вот и вам вышлют оффер. Но не нужно торопиться. Всегда задавайте максимальное количество вопросов. О том, чем вам придётся заниматься. Какой в команде воркфлоу. Насколько хорошо команда относится к разработке и как сильно болеет за качество кода. Как часто происходят встречи или созвоны. Не забудьте уточнить про бонусы или корпоративные плюшки. И конечно же спросите про то, какие у вас перспективы. Как минимум покажете свою заинтересованность. А как максимум будете знать, чего вас ждёт в команде и какие условия работы вам предстоят.
Конечно же все собеседования уникальны, но в целом в них есть костяк, о котором я написал. Поэтому вы уже примерно знаете, чего вам ожидать. Да и всегда можно спросить у hr, как проходит отбор. И последний совет. Иногда проходите собеседования без цели найти работу, а просто для того, чтобы держать себя в тонусе. И успехов.
👍1
Первый опыт совместного проектирования
Расскажу свой первый опыт совместного обсуждения решения задачи с проектированием и пошаговой реализацией. Нам требовалось реализовать функционал, который бы запускал любой валидный загруженный файл с кодом. По сути это были кастомные расширения. Нас тогда было трое. Руководитель проекта, старший разработчик и я.
Моя задача была написать само расширение. Старшему разработчику нужно было сделать запуск этих расширений. А руководитель просто управлял процессом. Задача выглядит не сложной, но не для начинающего разработчика.
Мне было сложно. Я просто не имел подобного опыта и старался участвовать в диалоге по мере сил. Иногда я ловил себя на мысли, что ничем не могу помочь. Но я не сдавался и либо поддерживал предложения старшего, либо молчал. Иногда меня просили прокомментировать что-то, и я что-то говорил. Это был очень полезный опыт, хотя и тяжёлый для меня. В итоге мы всё смогли сделать как надо.
Что я хотел этим сказать? А то, что в начале часто бывает тяжело. И опускать руки самое последнее дело. Старшие сотрудники тоже были молодыми и понимают джунов, а поэтому всегда поддержат. Так что всегда нужно стараться и нужно двигаться до конца. Пусть это трудно, но это бесценный опыт.
Расскажу свой первый опыт совместного обсуждения решения задачи с проектированием и пошаговой реализацией. Нам требовалось реализовать функционал, который бы запускал любой валидный загруженный файл с кодом. По сути это были кастомные расширения. Нас тогда было трое. Руководитель проекта, старший разработчик и я.
Моя задача была написать само расширение. Старшему разработчику нужно было сделать запуск этих расширений. А руководитель просто управлял процессом. Задача выглядит не сложной, но не для начинающего разработчика.
Мне было сложно. Я просто не имел подобного опыта и старался участвовать в диалоге по мере сил. Иногда я ловил себя на мысли, что ничем не могу помочь. Но я не сдавался и либо поддерживал предложения старшего, либо молчал. Иногда меня просили прокомментировать что-то, и я что-то говорил. Это был очень полезный опыт, хотя и тяжёлый для меня. В итоге мы всё смогли сделать как надо.
Что я хотел этим сказать? А то, что в начале часто бывает тяжело. И опускать руки самое последнее дело. Старшие сотрудники тоже были молодыми и понимают джунов, а поэтому всегда поддержат. Так что всегда нужно стараться и нужно двигаться до конца. Пусть это трудно, но это бесценный опыт.
❤1
Если надо вырастить разработчика
Когда кто-то нанимает джуна, то вероятнее всего не потому что он хорош и готов решать задачи, а потому что у него есть навык обучения, он показал хорошие перспективы и команда готова вырастить из него единомышленника и достойного участника команды. Поэтому на испытательном сроке джун должен проникнуться духом коллектива, а сама команда должна задать ему хороший вектор развития. Так какие же навыки должен освоить новичок, чтобы его оставили?
Понимание. Есть вещи, которые нужно понимать без объяснений. Код должен быть по общим шаблонам и правилам, но соответствовать текущим решениям. Инициатива наказуема. Если сомневаешься - спроси. Если задача не решается, то проси помощи. И т.д. Т.е. человек должен понимать основы работы в команде.
Скорость. Задачи не могу решаться вечно. Выше я написал, что разработчик должен понимать, когда его задача зашла в тупик. Плюс если работа удалённая, то важно отвечать без задержек и по делу.
Безконфликтность. Когда ты молод, то хочешь поменять мир. Но на данном этапе задача джуна выполнять просьбы других и ни в коем случае не иди против решения старших. Можно предложить свой вариант, но никогда не нужно его оспаривать.
Не тупить. Есть люди, которые считают, что можно жить по интуиции. Можно, но когда ты сеньор. Джуны должны взять за правило проверять и перепроверять свои решения, иначе они будут выглядеть глупо.
Стремление. Новичок должен показать всем, что он готов делать больше, чем от него требуется, но уметь держать свои "горячие" идеи при себе. Он должен научиться здравому рвению.
Смысл проекта. Это часть стремления. Нужно или самому понять в чем смысл проекта и чего хочет бизнес, или спросить об этом старших.
Приоритеты команды. У каждой команды есть свои наработанные паттерны общения и поведения. Нужно понять их и научиться применять. Это короткий путь стать частью команды.
Культура общения. Важная часть взаимодействия. Если вы любите матерные слова, то на испытательном сроке забудьте все. Даже если подобным образом общаются старшие. И вспомните уроки русского языка. Порой даже пропущенная запятая может стать проблемой и затянуть решение задачи.
Аккуратность. Новички должны содержать код в чистоте. Никаких лишних комментариев, пустых строк, забытых включений.
Это основные вещи, которые для меня важны у новичка. Считаю без подобных навыков джун не станет полноценной частью команды и будет только мешать работе. Возможно это банальные вещи, но они очень важны. Учитывайте их.
Когда кто-то нанимает джуна, то вероятнее всего не потому что он хорош и готов решать задачи, а потому что у него есть навык обучения, он показал хорошие перспективы и команда готова вырастить из него единомышленника и достойного участника команды. Поэтому на испытательном сроке джун должен проникнуться духом коллектива, а сама команда должна задать ему хороший вектор развития. Так какие же навыки должен освоить новичок, чтобы его оставили?
Понимание. Есть вещи, которые нужно понимать без объяснений. Код должен быть по общим шаблонам и правилам, но соответствовать текущим решениям. Инициатива наказуема. Если сомневаешься - спроси. Если задача не решается, то проси помощи. И т.д. Т.е. человек должен понимать основы работы в команде.
Скорость. Задачи не могу решаться вечно. Выше я написал, что разработчик должен понимать, когда его задача зашла в тупик. Плюс если работа удалённая, то важно отвечать без задержек и по делу.
Безконфликтность. Когда ты молод, то хочешь поменять мир. Но на данном этапе задача джуна выполнять просьбы других и ни в коем случае не иди против решения старших. Можно предложить свой вариант, но никогда не нужно его оспаривать.
Не тупить. Есть люди, которые считают, что можно жить по интуиции. Можно, но когда ты сеньор. Джуны должны взять за правило проверять и перепроверять свои решения, иначе они будут выглядеть глупо.
Стремление. Новичок должен показать всем, что он готов делать больше, чем от него требуется, но уметь держать свои "горячие" идеи при себе. Он должен научиться здравому рвению.
Смысл проекта. Это часть стремления. Нужно или самому понять в чем смысл проекта и чего хочет бизнес, или спросить об этом старших.
Приоритеты команды. У каждой команды есть свои наработанные паттерны общения и поведения. Нужно понять их и научиться применять. Это короткий путь стать частью команды.
Культура общения. Важная часть взаимодействия. Если вы любите матерные слова, то на испытательном сроке забудьте все. Даже если подобным образом общаются старшие. И вспомните уроки русского языка. Порой даже пропущенная запятая может стать проблемой и затянуть решение задачи.
Аккуратность. Новички должны содержать код в чистоте. Никаких лишних комментариев, пустых строк, забытых включений.
Это основные вещи, которые для меня важны у новичка. Считаю без подобных навыков джун не станет полноценной частью команды и будет только мешать работе. Возможно это банальные вещи, но они очень важны. Учитывайте их.
👍1
Постановка задачи важна
Постановка задачи решает половину задачи. И это не для красного словца. Я много раз ловил себя на мысли, что трачу много времени на понимание задачи, если она плохо описана. И это не значит, что в задаче должен быть описан ход решения, это значит, что постановка задачи должна полностью отвечать на проблему и иметь полную информацию.
Основная проблема тут в том, что постановка задачи, или её описание, обычно написаны очень кратко. И разработчику приходится многое додумывать, на многое искать ответы самому или отвлекать кого-то вопросами. Это очень мешает и сбивает с толку. Описание должно быть ёмким и понятным.
С другой стороны в описании может быть много лишнего. Вступление, длинные описания, базовые термины и т.д. Это тоже очень мешает. В постановке должно быть всё по делу и ничего не должно отвлекать от задачи. В данном случае золотая середина - лучший вариант.
Ещё один бич постановки задачи - это ошибки в тексте или неграмотная организация предложений. Для меня это очень важная тема. Любая ошибка в слове, неверный знак препинания, слово не на нужном месте сильно сбивают с толку. Приходится решать микро задачу, чтобы понять написанное. Люди уже и автоматическую проверку правописания придумали, а все равно ошибок уйма. Как можно так не уважать себя и того, кто будет это читать?
В итоге я очень прошу заранее задуматься над тем, чтобы научиться правильно делать описание задачи и как не допускать ошибок в предложениях. За это вам обязательно скажут спасибо!
Постановка задачи решает половину задачи. И это не для красного словца. Я много раз ловил себя на мысли, что трачу много времени на понимание задачи, если она плохо описана. И это не значит, что в задаче должен быть описан ход решения, это значит, что постановка задачи должна полностью отвечать на проблему и иметь полную информацию.
Основная проблема тут в том, что постановка задачи, или её описание, обычно написаны очень кратко. И разработчику приходится многое додумывать, на многое искать ответы самому или отвлекать кого-то вопросами. Это очень мешает и сбивает с толку. Описание должно быть ёмким и понятным.
С другой стороны в описании может быть много лишнего. Вступление, длинные описания, базовые термины и т.д. Это тоже очень мешает. В постановке должно быть всё по делу и ничего не должно отвлекать от задачи. В данном случае золотая середина - лучший вариант.
Ещё один бич постановки задачи - это ошибки в тексте или неграмотная организация предложений. Для меня это очень важная тема. Любая ошибка в слове, неверный знак препинания, слово не на нужном месте сильно сбивают с толку. Приходится решать микро задачу, чтобы понять написанное. Люди уже и автоматическую проверку правописания придумали, а все равно ошибок уйма. Как можно так не уважать себя и того, кто будет это читать?
В итоге я очень прошу заранее задуматься над тем, чтобы научиться правильно делать описание задачи и как не допускать ошибок в предложениях. За это вам обязательно скажут спасибо!
Отношения в команде
Поговорим о том, какие могут быть последствия от тех или иных отношений в команде. Но т.к. тема широкая, то я затрону момент с прогрессом и обменом опыта на примере разных команд, с которыми я так или иначе работал.
Многим нравится, когда в команде дружелюбные отношения и нет явного лидера, т.е. когда все примерно понимают свою роль. В такой команде спокойно и легко, но нет никакого прогресса. Никто вас не гонит, никто с вас ничего особенного не требует, но и роста нет. Это и хорошо и плохо.
Если же в команде есть лидер, то он ведёт всех за собой и может стать примером, за которым нужно всем успевать. Иначе останешься в хвосте. Не думаю, что отстающие нужны в такой команде. Поэтому нужно либо стараться расти, либо уходить. Такая команда прогрессивная, но авторитарная. Это и хорошо и плохо.
Если в команде много специалистов, которые часто показывают креативные вещи и могут этим поделиться с другими, то такая команда будет расти на примерах, но может стать заложницей идей других и подавить индивидуальность в угоду "командного пути". Это и хорошо и плохо.
Если в команде много специалистов ниже среднего, то прогресс команды от такого состава будет не велик, но есть большая возможность слепить из команды что-то уникальное. Это позволяет легче управлять командой, но приходится тратить много времени на команду. Это и хорошо и плохо.
С пониманием таких отношений можно заранее составить план действий в команде и выбрать себе более подходящие условия взаимодействия и конечную цель, к которой можно прийти.
Поговорим о том, какие могут быть последствия от тех или иных отношений в команде. Но т.к. тема широкая, то я затрону момент с прогрессом и обменом опыта на примере разных команд, с которыми я так или иначе работал.
Многим нравится, когда в команде дружелюбные отношения и нет явного лидера, т.е. когда все примерно понимают свою роль. В такой команде спокойно и легко, но нет никакого прогресса. Никто вас не гонит, никто с вас ничего особенного не требует, но и роста нет. Это и хорошо и плохо.
Если же в команде есть лидер, то он ведёт всех за собой и может стать примером, за которым нужно всем успевать. Иначе останешься в хвосте. Не думаю, что отстающие нужны в такой команде. Поэтому нужно либо стараться расти, либо уходить. Такая команда прогрессивная, но авторитарная. Это и хорошо и плохо.
Если в команде много специалистов, которые часто показывают креативные вещи и могут этим поделиться с другими, то такая команда будет расти на примерах, но может стать заложницей идей других и подавить индивидуальность в угоду "командного пути". Это и хорошо и плохо.
Если в команде много специалистов ниже среднего, то прогресс команды от такого состава будет не велик, но есть большая возможность слепить из команды что-то уникальное. Это позволяет легче управлять командой, но приходится тратить много времени на команду. Это и хорошо и плохо.
С пониманием таких отношений можно заранее составить план действий в команде и выбрать себе более подходящие условия взаимодействия и конечную цель, к которой можно прийти.
Режим работы и отдыха
Казалось бы, банальная вещь, поддерживать режим работы и отдыха, но на деле обычно выходит иначе. Люди или перерабатывают, потому что за переработки им больше платят, либо работают на двух работах, что тоже должно приносить больше дохода. А есть просто те, кому больше нечем заняться.
Но в итоге получается, что люди играют в игру - пока я молод и здоров я могу горы свернуть и мне всё нипочём, а эти горы принесут мне горы материальных благ. Но когда люди смотрят в прошлое, то многие сожалеют о потраченном времени и готовы сделать всё что угодно чтобы его вернуть.
Работа как и всё остальное требует разумного подхода, чёткого плана, и поддержание режима работы, совмещённого с качественным отдыхом. Без хорошего отдыха не будет хорошей работы. Поэтому каждый раз когда вы уходите в работу с головой, очень важно вовремя отдохнуть и набраться сил. Когда пройдёт время, когда вы станете взрослыми, вы поймёте, что сил уже недостаточно, что не хватает времени на восстановление как это было раньше. А всё потому, что раньше вы не обращали внимание на ваше тело, на ваш организм, на то как он реагирует на работу, когда ему нужен отдых и какой ему нужен отдых.
Запомните, нужно и важно уметь отдыхать и поддерживать режим работы и отдыха. Научитесь делать это с самого начала, поставьте это одной из целей своих трудовых будней. Ведь только правильное и чёткое совмещение работы с отдыхом принесёт вам максимальную эффективность и продлит вашу способность к качественной и успешной работе. Заботьтесь о себе.
Казалось бы, банальная вещь, поддерживать режим работы и отдыха, но на деле обычно выходит иначе. Люди или перерабатывают, потому что за переработки им больше платят, либо работают на двух работах, что тоже должно приносить больше дохода. А есть просто те, кому больше нечем заняться.
Но в итоге получается, что люди играют в игру - пока я молод и здоров я могу горы свернуть и мне всё нипочём, а эти горы принесут мне горы материальных благ. Но когда люди смотрят в прошлое, то многие сожалеют о потраченном времени и готовы сделать всё что угодно чтобы его вернуть.
Работа как и всё остальное требует разумного подхода, чёткого плана, и поддержание режима работы, совмещённого с качественным отдыхом. Без хорошего отдыха не будет хорошей работы. Поэтому каждый раз когда вы уходите в работу с головой, очень важно вовремя отдохнуть и набраться сил. Когда пройдёт время, когда вы станете взрослыми, вы поймёте, что сил уже недостаточно, что не хватает времени на восстановление как это было раньше. А всё потому, что раньше вы не обращали внимание на ваше тело, на ваш организм, на то как он реагирует на работу, когда ему нужен отдых и какой ему нужен отдых.
Запомните, нужно и важно уметь отдыхать и поддерживать режим работы и отдыха. Научитесь делать это с самого начала, поставьте это одной из целей своих трудовых будней. Ведь только правильное и чёткое совмещение работы с отдыхом принесёт вам максимальную эффективность и продлит вашу способность к качественной и успешной работе. Заботьтесь о себе.
Собеседование как экзамен
Все мы помним контрольные работы или экзамены в период обучения. Уверен каждый из нас хоть как-то готовился к этим решающим этапам процесса образования. На пути карьеры эти этапы тоже присутствуют. Будь это большой проект, важное мероприятие или встреча. Но я хочу поговорить о другом. О собеседовании с точки зрения возможности для выбора пути или решающего этапа в карьере.
К собеседованию можно подходить с двух сторон. Либо это единственный и последний шанс, либо это переходный этап. Т.е. либо нужно и важно получить ту должность, на которую будет происходить собеседование. Либо использовать собеседование как этап подготовки к другому, более важному собеседованию. Второй вариант нет смысла рассматривать, к такому собеседованию каждый готовится как ему хочется. А вот первый вариант стоит обговорить подробнее.
Мои первые собеседования были простые и я не особо к ним готовился. Конечно, если бы это было что-то из FAANG, то наверняка я бы постарался. Но старания были потом. А по началу я не считал это явной целью, хотя если бы понимал всё более чётко, то и ставил бы перед собой другие задачи. Поэтому первое и весомое правило - это понимать важность подготовки и осознавать тот факт, что собеседование нужно пройти максимально эффективно.
Последующие собеседования были сложнее. Но учитывая мой недостаточный опыт подготовки некоторые хорошие вакансии проходили мимо меня. Поэтому постепенно я начал готовиться через эти самые собеседования. Т.е. я начинал лучше понимать, что спрашивают чаще и на что делается упор. На самом деле это путь в никуда. Такие вещи нужно узнавать до беседы с работодателем. Поэтому второе важное правило - готовьтесь к собеседованию как к последнему экзамену.
Ну и в конце хочу вспомнить случай, когда я спустя множество собеседований расслабился, стал в какой-то степени самоуверен от того, что знаю ответы на все вопросы и в итоге не смог пройти отбор в хорошую компанию, из-за чего сожалею до сих пор. А всё потому, что не смог подготовиться в достаточной степени. Поэтому третье и самое важное правило - не считай себя самым умным, потому что каждый видит мир по своему и важно найти общий язык до того, как в тебе разочаруются.
P.S. На самом деле невозможно подготовиться на 100% и знать всё. Можно вообще ничего не знать, но подходить под требования. А можно знать всё, но не найти общий язык. Я навсегда останусь при своём мнении: если ты способен показать, что можешь решать задачи, для которых тебя хотят нанять, то тебя наймут, даже если ты "без рода и племени". Но готовиться всё равно надо.
Все мы помним контрольные работы или экзамены в период обучения. Уверен каждый из нас хоть как-то готовился к этим решающим этапам процесса образования. На пути карьеры эти этапы тоже присутствуют. Будь это большой проект, важное мероприятие или встреча. Но я хочу поговорить о другом. О собеседовании с точки зрения возможности для выбора пути или решающего этапа в карьере.
К собеседованию можно подходить с двух сторон. Либо это единственный и последний шанс, либо это переходный этап. Т.е. либо нужно и важно получить ту должность, на которую будет происходить собеседование. Либо использовать собеседование как этап подготовки к другому, более важному собеседованию. Второй вариант нет смысла рассматривать, к такому собеседованию каждый готовится как ему хочется. А вот первый вариант стоит обговорить подробнее.
Мои первые собеседования были простые и я не особо к ним готовился. Конечно, если бы это было что-то из FAANG, то наверняка я бы постарался. Но старания были потом. А по началу я не считал это явной целью, хотя если бы понимал всё более чётко, то и ставил бы перед собой другие задачи. Поэтому первое и весомое правило - это понимать важность подготовки и осознавать тот факт, что собеседование нужно пройти максимально эффективно.
Последующие собеседования были сложнее. Но учитывая мой недостаточный опыт подготовки некоторые хорошие вакансии проходили мимо меня. Поэтому постепенно я начал готовиться через эти самые собеседования. Т.е. я начинал лучше понимать, что спрашивают чаще и на что делается упор. На самом деле это путь в никуда. Такие вещи нужно узнавать до беседы с работодателем. Поэтому второе важное правило - готовьтесь к собеседованию как к последнему экзамену.
Ну и в конце хочу вспомнить случай, когда я спустя множество собеседований расслабился, стал в какой-то степени самоуверен от того, что знаю ответы на все вопросы и в итоге не смог пройти отбор в хорошую компанию, из-за чего сожалею до сих пор. А всё потому, что не смог подготовиться в достаточной степени. Поэтому третье и самое важное правило - не считай себя самым умным, потому что каждый видит мир по своему и важно найти общий язык до того, как в тебе разочаруются.
P.S. На самом деле невозможно подготовиться на 100% и знать всё. Можно вообще ничего не знать, но подходить под требования. А можно знать всё, но не найти общий язык. Я навсегда останусь при своём мнении: если ты способен показать, что можешь решать задачи, для которых тебя хотят нанять, то тебя наймут, даже если ты "без рода и племени". Но готовиться всё равно надо.
Все должны делать ревью
Логично предположить, что оценку какого-то продукта должен делать эксперт, будь это готовый продукт или прототип. Ведь только человек с опытом сможет наиболее точно определить недостатки продукта и дать подходящие комментарии. Но так ли это на самом деле? Считаю, что нет.
Во первых, эксперт не всегда может быть объективен, т.к. часто его навыки узко-специализированы. Во вторых, в команде должно быть общее восприятие продукта и оценку должны проводить все. И пусть специалисты без опыта не смогут выдать релевантное мнение, но что более важно, они смогут лучше прочувствовать разрабатываемый продукт и смогут набраться ценного опыта.
К тому же недостаточно опытные разработчики могут иметь свежий взгляд или уметь посмотреть на проблему с другой стороны. Хоть это и незначительное преимущество, но иногда оно очень полезно в команде, которая начинает "костенеть" или "закисать". Мир не стоит на месте, поэтому важно не отставать от него.
Однако самое важно в том, чтобы младшие разработчики делали ревью, это получение опыта на основе анализа готового кода, написанного старшими разработчиками. И это, безусловно, самое ценное. Только на чужом примере можно научиться писать хороший код.
И что так же не менее важно, так это то, что необходимо именно заставлять делать ревью кода. И заставлять нужно менее опытных программистов, чтобы они смотрели код более опытных членов команды. Пусть они и не найдут багов или архитектурных проблем, но зато многому научатся. Потраченное в начале на это время хорошо окупится потом.
Логично предположить, что оценку какого-то продукта должен делать эксперт, будь это готовый продукт или прототип. Ведь только человек с опытом сможет наиболее точно определить недостатки продукта и дать подходящие комментарии. Но так ли это на самом деле? Считаю, что нет.
Во первых, эксперт не всегда может быть объективен, т.к. часто его навыки узко-специализированы. Во вторых, в команде должно быть общее восприятие продукта и оценку должны проводить все. И пусть специалисты без опыта не смогут выдать релевантное мнение, но что более важно, они смогут лучше прочувствовать разрабатываемый продукт и смогут набраться ценного опыта.
К тому же недостаточно опытные разработчики могут иметь свежий взгляд или уметь посмотреть на проблему с другой стороны. Хоть это и незначительное преимущество, но иногда оно очень полезно в команде, которая начинает "костенеть" или "закисать". Мир не стоит на месте, поэтому важно не отставать от него.
Однако самое важно в том, чтобы младшие разработчики делали ревью, это получение опыта на основе анализа готового кода, написанного старшими разработчиками. И это, безусловно, самое ценное. Только на чужом примере можно научиться писать хороший код.
И что так же не менее важно, так это то, что необходимо именно заставлять делать ревью кода. И заставлять нужно менее опытных программистов, чтобы они смотрели код более опытных членов команды. Пусть они и не найдут багов или архитектурных проблем, но зато многому научатся. Потраченное в начале на это время хорошо окупится потом.
Отпустить проблему, чтобы решить её быстрее
Уверен у вас были ситуации, когда некоторая задача долго не решалась из-за постоянно возникающих трудностей. И казалось бы простая проблема требует больше времени, чем планировалось изначально.
А также, я уверен, у вас были случаи, когда подобные затянутые задачи неожиданно находили свое решение, как только вы обратились за помощью. Причем решение вы находили сами.
Я не знаю почему так происходит, но знаю, что нужно научиться определять момент, когда простая задача затягивается. Как только появляется такое чувство, значит нужно немедленно отложить задачу. Хотя бы на часок, отвлекитесь или переключитесь на другую проблему. А после возвращения вы намного быстрее сможете найти решение. Проверено.
Уверен у вас были ситуации, когда некоторая задача долго не решалась из-за постоянно возникающих трудностей. И казалось бы простая проблема требует больше времени, чем планировалось изначально.
А также, я уверен, у вас были случаи, когда подобные затянутые задачи неожиданно находили свое решение, как только вы обратились за помощью. Причем решение вы находили сами.
Я не знаю почему так происходит, но знаю, что нужно научиться определять момент, когда простая задача затягивается. Как только появляется такое чувство, значит нужно немедленно отложить задачу. Хотя бы на часок, отвлекитесь или переключитесь на другую проблему. А после возвращения вы намного быстрее сможете найти решение. Проверено.
👍1
Незаменимых не бывает
Моя первая официальная работа продолжалась немногим более 3 месяцев. Это было в гос организации сразу же после университета. Тогда я чувствовал себя независимым и ещё плохо понимал, куда мне двигаться дальше. А ушёл то я по причине того, что меня забрали в армию. Только вот теперь я уже был с опытом.
Вторая работа была лучше первой. Меня взяли, потому что у меня был уже нужный опыт. И огромное желание развиваться и расти. Год за годом я рос и в итоге перерос свою должность. Дошло до того, что я мог совмещать две работы. Со временем вторая работа требовала всё больше занятости, и я решил работать на первой работе пол дня, а остальное время на второй. Ведь я же могу. Я же ценный специалист.
Как оказалось потом, реальность совсем не такая, как кажется. Меня уволили стразу же, когда я пришел просить перейти работать на пол дня. Так начальство поняло, что мне мало одной работы. В тот день мне сказали, что ты или полностью с нами, или уходишь. Я ушел в тот же момент. С небольшим скандалом. Но я ни разу не жалею.
Эта история научила меня тому, что незаменимых не бывает. Чем ценнее ты как сотрудник, тем больше проблем ты создаёшь своим авторитетом. И тем сложнее бывает доказать свою нужность через свою ценность. Остаётся либо ухватиться за важную должность, либо тихо и мирно делать своё дело и не создавать лишних проблем.
Моя первая официальная работа продолжалась немногим более 3 месяцев. Это было в гос организации сразу же после университета. Тогда я чувствовал себя независимым и ещё плохо понимал, куда мне двигаться дальше. А ушёл то я по причине того, что меня забрали в армию. Только вот теперь я уже был с опытом.
Вторая работа была лучше первой. Меня взяли, потому что у меня был уже нужный опыт. И огромное желание развиваться и расти. Год за годом я рос и в итоге перерос свою должность. Дошло до того, что я мог совмещать две работы. Со временем вторая работа требовала всё больше занятости, и я решил работать на первой работе пол дня, а остальное время на второй. Ведь я же могу. Я же ценный специалист.
Как оказалось потом, реальность совсем не такая, как кажется. Меня уволили стразу же, когда я пришел просить перейти работать на пол дня. Так начальство поняло, что мне мало одной работы. В тот день мне сказали, что ты или полностью с нами, или уходишь. Я ушел в тот же момент. С небольшим скандалом. Но я ни разу не жалею.
Эта история научила меня тому, что незаменимых не бывает. Чем ценнее ты как сотрудник, тем больше проблем ты создаёшь своим авторитетом. И тем сложнее бывает доказать свою нужность через свою ценность. Остаётся либо ухватиться за важную должность, либо тихо и мирно делать своё дело и не создавать лишних проблем.
❤1
Книги нужно читать
Сейчас я напишу довольно банальные вещи, но это важные вещи. Порой именно разговор о таких вещах даёт возможность обратить на них внимание и вспомнить их важность.
И это чтение книг. Любых книг. Технических, классических, художественных и научных, познавательных и образовательных. Любое чтение очень хорошо повышает ваш кругозор, а значит даёт вам рост и преимущества.
Я уверен, что в каждой книге найдётся что-то полезное. Важно уметь обращать на это внимание. А этот навык тренируется усердным чтением книг. И хорошо было бы, если бы художественные и технические книги чередовались.
За последние несколько лет я прочитал больше книг, чем за всю жизнь до этого. И уверяю вас я получил массу пользы. И я продолжаю их читать. Чего и вам желаю.
Сейчас я напишу довольно банальные вещи, но это важные вещи. Порой именно разговор о таких вещах даёт возможность обратить на них внимание и вспомнить их важность.
И это чтение книг. Любых книг. Технических, классических, художественных и научных, познавательных и образовательных. Любое чтение очень хорошо повышает ваш кругозор, а значит даёт вам рост и преимущества.
Я уверен, что в каждой книге найдётся что-то полезное. Важно уметь обращать на это внимание. А этот навык тренируется усердным чтением книг. И хорошо было бы, если бы художественные и технические книги чередовались.
За последние несколько лет я прочитал больше книг, чем за всю жизнь до этого. И уверяю вас я получил массу пользы. И я продолжаю их читать. Чего и вам желаю.
Не переделывай всё под себя
"Со своим уставом в чужой монастырь не ходят"
На своём опыте могу сказать, что после накопления некоторого набора навыков, формируется определённое видение качества кода. И когда открываешь чужой проект, то невольно появляется желание изменить код так, как привык его видеть. Но это неправильно. И вот почему.
Во первых, это выглядит очень странно. Новичок, о котором пока мало что знают, начинает менять код, который менять не требуется. Это сразу же показывает его с непрофессиональной стороны. Примерно как если бы его позвали в гости, а он начал бы переставлять мебель, когда все садятся за стол. Сначала нужно заработать хоть немого авторитета, а потом уже можно пытаться менять что-то.
Во вторых, после ненужных изменений очень сложно делать ревью. Представляете сколько будет отличий, если изменятся отступы или код станет "красивее"? Очень много. И за этим всем не так то просто увидеть реальные изменения. Конечно, можно сделать это отдельным коммитом, но давайте потом, когда это действительно потребуется.
В третьих, это просто лишняя работа. Сомневаюсь, что в компании есть столько свободного времени, чтобы новички сразу же делали такие изменения. Поэтому не надо раздражать начальство, а лучше сосредоточиться на самом важном и показать всем, что вы пришли сюда не ерундой заниматься. Плюс к этому важно знать, что инициатива наказуема. В этом случае могут дать больше подобной рутинной работы, или наказать за эту.
В четвёртых, это просто неуважение к другим. Представьте, что другие разработчики работали с этим кодом годами, он отлажен и он исправно работает. И тут вдруг приходит кто-то новенький и начинает менять это. Они воспримут этот как нечто неприемлемое. Как я уже писал выше, сначала докажите своё право на это. Да и вообще, если что-то работает, то не надо это трогать!
В итоге мой совет: не надо в первое время работы над новым проектом (в любой компании) переделывать его под себя. Даже один файлик. Это не ваша обязанность. Просто делайте, что требуется.
"Со своим уставом в чужой монастырь не ходят"
На своём опыте могу сказать, что после накопления некоторого набора навыков, формируется определённое видение качества кода. И когда открываешь чужой проект, то невольно появляется желание изменить код так, как привык его видеть. Но это неправильно. И вот почему.
Во первых, это выглядит очень странно. Новичок, о котором пока мало что знают, начинает менять код, который менять не требуется. Это сразу же показывает его с непрофессиональной стороны. Примерно как если бы его позвали в гости, а он начал бы переставлять мебель, когда все садятся за стол. Сначала нужно заработать хоть немого авторитета, а потом уже можно пытаться менять что-то.
Во вторых, после ненужных изменений очень сложно делать ревью. Представляете сколько будет отличий, если изменятся отступы или код станет "красивее"? Очень много. И за этим всем не так то просто увидеть реальные изменения. Конечно, можно сделать это отдельным коммитом, но давайте потом, когда это действительно потребуется.
В третьих, это просто лишняя работа. Сомневаюсь, что в компании есть столько свободного времени, чтобы новички сразу же делали такие изменения. Поэтому не надо раздражать начальство, а лучше сосредоточиться на самом важном и показать всем, что вы пришли сюда не ерундой заниматься. Плюс к этому важно знать, что инициатива наказуема. В этом случае могут дать больше подобной рутинной работы, или наказать за эту.
В четвёртых, это просто неуважение к другим. Представьте, что другие разработчики работали с этим кодом годами, он отлажен и он исправно работает. И тут вдруг приходит кто-то новенький и начинает менять это. Они воспримут этот как нечто неприемлемое. Как я уже писал выше, сначала докажите своё право на это. Да и вообще, если что-то работает, то не надо это трогать!
В итоге мой совет: не надо в первое время работы над новым проектом (в любой компании) переделывать его под себя. Даже один файлик. Это не ваша обязанность. Просто делайте, что требуется.