8 советов начинающим программистам или ретроспектива моей карьеры / Habr
Ровно 15 лет назад, в этот самый день, своими дрожащими коленками я переступил порог офиса небольшого провинциального интернет-провайдера. Моя первая настоящая работа в качестве программиста. Знаний почти нет. Тонкий испуганный голосок откуда-то из желудка советует развернуться и убежать подальше, пока окончательно не опозорился. Глубокий вдох-выдох, и вот генеральный директор уже ведет меня в небольшую комнатку-подвальчик, показывает на полуразобранный компьютер, видавший лучшие времена: «Это твое рабочее место. Устраивайся». Так началась моя карьера.
Но перенесемся в настоящее. Сейчас я пишу эти строки, сидя в удобном офисе престижного БЦ в центре Москвы. За плечами работа с крупными международными брендами и разработка сложных fintech приложений. Сотни книг прочитано и десятки статей написано. Мания величия давно вылечена. Менеджерские позиции опробованы и отвергнуты. Душевное равновесие найдено. Любовь к профессии сохранена. Однако это не статья из серии “Какой я молодец. Делай, как я и тоже будешь молодцом”. Эта статья о том, какие ошибки я совершал и что можно было сделать лучше. Эта статья — ретроспектива моей карьеры.
Меняйте компанию, если нет развития
Время от времени я застревал в компаниях, которые явно перерос по уровню. Вроде и деньги платят хорошие, и все тут знакомо и удобно. Приходишь утром, выбираешь привычный режим на кофемашине. Обмениваешься шутками с Катей из бухгалтерии. Садишься в свое кресло, которое давно приняло очертания твоего мягкого места. Открываешь ноут и погружаешься в ежедневную рутину из типичных хорошо знакомых тебе задач. Внимание! Это ловушка!
Работа не должна становиться рутиной. Должны быть вызовы. Не каждый день, может даже не каждый месяц, но если вам слишком легко — пора уходить. Не нужно бояться трудностей. Если на собеседовании вам показалось, что тут ребята решают слишком сложные задачи, и вы точно лажанетесь в первый же день — этот оффер для вас. Ищите максимально сложные задачи, только так вы сможете совершенствоваться, а не деградировать на кухне любимой компании по 4 часа в день
Будьте программистом, а не кодером
Написать код != решить проблему. Код — это только один из инструментов для решения проблем. Ох, как же долог был путь до осознания этого простого утверждения. Как же много времени было потрачено впустую. Нас, программистов, со страшной силой притягивает код. Видя очередную задачу в Джире, мы пробегаем ее глазами по диагонали и скорее-скорее писать код! Как только код написан — мы теряем интерес к задаче и берем новую.
Помните: ваша ценность как программиста не в элегантном коде с экзотическими паттернами от “Банды четырех“. Ни одна компания еще не добивалась успеха благодаря красоте кода (во всяком случае я таких примеров не припомню). Всегда держите в уме конечный результат.
Не бойтесь экспериментировать
Каждый раз, начиная новый пет-проект, я либо начинал его на хорошо знакомых технологиях, либо переходил на них после нескольких недель. Ведь так гораздо быстрее. Какой смысл мучиться с Кафкой, если есть любимый Кролик? Зачем укладывать структуру данных в документы, если она сама легко укладывается в реляционную модель? Каждый раз мысль о том, что нужно побыстрее выйти в прод, мешала мне развиваться. В итоге большая часть моих проектов лежит мертвым грузом на гитхабе, не принеся мне не только мировой известности, но даже новых знаний. Пытаясь угнаться за сроками, которые я сам себе ставил, я просто терял время. Экспериментируйте. Спешить некуда. Развивайте кругозор. Если вы эксперт в какой-то технологии — используйте эти знания на работе, но вне работы пользуйтесь инструментами, с которыми вы не знакомы. Это сложно психологически, ведь вы будете понимать, что используя хорошо знакомый язык программирования, уже пожинали бы плоды славы от вашего проекта на Мальдивах. А приходится разбираться, почему преобразование чара в инт отдает код символа, а не цифру.
Запускайте пет-проекты
Я давно понял: чтобы быть успешным программистом, мало быть хорошим программистом. Нужно понимать разработку продукта гораздо шире своей специализации. Но как этого добиться? Я могу прочитать сотни книг по маркетингу и они будут бесполезны, если я не применяю эти знания на практике. Я могу подписаться на телеграм каналы лучших продуктологов страны, но что с того, если у меня нет продукта, на котором можно экспериментировать?
С тех пор, как я запустил свой первый пет-проект, мне стало гораздо проще находить общий язык с фронтами, qa, продактами, маркетологами и любыми другими членами команды. Ведь я стал понимать их работу намного лучше. Современное программирование — очень командное, и опыт работы над собственным проектом помогает мне находить точки соприкосновения с другими членами команды.
Учитесь декомпозировать
У меня всегда были проблемы с внимательностью. Я допускал в коде очень глупые ошибки. Не потому что я что-то не понимал или не знал как сделать. Просто я был невнимателен. Боролся с этой проблемой разными скучными способами (например, следил за минутной стрелкой), но ничего не помогало. Естественно, после каждой такой ошибки моя самооценка резко падала. О каком развитии может идти речь, если самооценка на нуле? Решение пришло в виде декомпозиции. Меньше задача = меньше кода = меньше вероятность допустить ошибку. Я часто слышу фразу «эту задачу нельзя декомпозировать», но лично я считаю, что любую задачу можно декомпозировать до бесконечности. Если у вас не получается, скорее всего, вы просто не до конца понимаете задачу.
Изучайте инструменты
Долгое время я пользовался IDE как обычным редактором кода с удобной навигацией. А еще у меня был начальник, который программировал исключительно в mcedit и часто театрально вопрошал: «Кто ты без своего IDE?». Или у меня 24/7 был открыт терминал, но я совсем не умел с ним работать. Я долго жил без статических анализаторов и стайл-фиксеров. Игнорировал горячие клавиши. И не видел в этом никакой проблемы.
Участвуйте в opensource
Opensource — это больно. Каждый ваш PR будет рассмотрен под микроскопом. Каждая переменная, каждый символ. Каждый тест будет подвергнут сомнению. И это не ваш тимлид, который: «а, ну ладно, давай так смержим». С этими людьми не договоришься, на них не пожалуешься, их не задавишь авторитетом. И они вам даже не платят. Примерно на двадцать пятом комментарии очень хочется послать все нафиг.
Терпите! Opensource — это отличная возможность прокачать свой скилл, работая с лучшими программистами мира (хотя тут зависит от проекта). Начните с малого. Выберите какой-нибудь несложный инструмент или библиотеку. Зайдите в раздел issues и посмотрите, что можно пофиксить. Надо сказать, что обычно на гитхабе полностью отсутствует токсичность. Если ваш ПР разнесут в клочья, то сделают это очень конструктивно. Во всяком случае, по моему опыту.
Верьте в себя
Время от времени у меня возникали ситуации, когда хотелось все бросить и пойти работать на стройку. Таскать кирпичи. Этой ситуацией могла быть задача, которая никак не заканчивалась. У которой ежедневно менялись требования. Или технология, которую я не хотел изучать. Или интеграция стороннего сервиса, у которого полностью отсутствовала документация. Или просто функциональность, для понимания которой требовалось образование финансиста, а все продуктологи говорят исключительно на английском. Я психовал, прокрастинировал, увольнялся и срывал злость на котейке.
Есть один прием, который сейчас сильно помогает мне с такими задачами. Просто я всегда помню, что в итоге я справлюсь. Всегда справлялся. И всегда буду. Нужно просто сесть, поизучать, подумать, разложить по полочкам, задать правильные вопросы правильным людям. Главное, верить в себя и оставаться спокойным. Вообще, пожалуй, это самый главный совет, которым я и закончу статью. Keep calm and believe in yourself. Вы справитесь.
101 совет, как стать хорошим программистом (и человеком) / Habr
1. Научитесь гуглить
Быть программистом, — значит научиться искать ответы на свои вопросы. Научившись эффективно «гуглить», вы сэкономите много времени, затрачиваемого на разработку.
2. Не обещайте много, но делайте больше, чем обещали
Лучше сообщать вашей команде, что выполнение задачи займет три недели, но выполнять её за две, чем наоборот. Следуя этому принципу, вы выстроите доверительные отношения.
Примечание от переводившего:
Большая просьба снисходительно отнестись к замеченным ошибкам в переводе, грамматике или пунктуации, и сообщить о них для исправления.
Спасибо
3. Будьте добры к дизайнерам; они ваши друзья
Дизайнеры обеспечивают решения пользовательских проблем. Учитесь у них и работайте сплоченно, чтобы создавать эффективные продукты.
4. Найдите наставника
Найдите кого-то, у кого могли бы учиться и получать авторитетное мнение (в ориг. «bounce off»). Coding Coach — отличное место, где вы можете найти технического наставника.
5. Будьте наставником
Будьте тем, у кого другие могут чему-то научиться. Мы будем рады видеть вас среди наставников на Coding Coach.
6. Пишите полезные комментарии
Пишите комментарии, объясняющие «почему», а не «что».
7. Называйте переменные и функции соответствующе
Функции и переменные должны точно описывать их назначение, поэтому «myCoolFunction» не подходит.
8. Берите отпуск
Нам всем нужно отдыхать. Отправьтесь в путешествие, о котором мечтаете. Ваш мозг и сотрудники будут благодарны.
9. Удаляйте неиспользуемый код
Не стоит накапливать технический долг.
10. Учитесь читать код
Чтение кода — недооцененный навык, но очень ценный.
11. Установите здравый баланс между работой и личной жизнью
Вам требуется время, чтобы расслабиться после долгого рабочего дня. Отключите рабочие уведомления или удалите приложения из вашего телефона.
12. Личные встречи только при необходимости
Этот вопрос может быть решен по Email или Slack? Если да, не стоит назначать встречу. Если нет, не затягивайте её продолжительность без веских причин.
13. Парное программирование
Парное программирование позволяет вам побыть и в роли учителя и в роли ученика.
14. Пишите отличные email-письма
Научитесь захватывать внимание собеседника в email-письмах, выражаясь кратко, но ясно.
15. Станьте частью сообщества
Окружайте себя единомышленниками, мотивирующими вас преодолевать трудности.
16. Убирайтесь в своих ветках
Убирайтесь в ваших ветках систем контроля версий, как вы делаете это дома перед приходом гостей. Если вы не нуждаетесь в чем-то, выбросите это; не складывайте в шкаф.
17. Не занимайтесь фейс-контролем
Не говорите другим, что они недостаточно хороши, чтобы работать в отрасли. Каждый имеет ценность.
18. Постоянно обучайтесь
Вы выбрали профессию, которая требует непрерывного обучения. Учитесь любить и это.
19. Не сдавайтесь
Это не всегда будет легко. Но ведь мы все начинали с того же. У вас получится.
20. Беритесь за задачи, которые пугают
Если они вас не пугают, значит не помогут вам расти.
21. Уточняйте требования перед тем, как начать
Вы должны понять критерии выполнения задачи перед тем, как приступить к написанию кода. Это сэкономит ваше время.
Обзаведитесь набором инструментов, которыми вы владеете вдоль и поперек. Знайте, для каких целей они служат и когда выгоднее использовать тот или иной инструмент в проекте.
23. Учитесь любить конструктивную критику
Просите доверенных коллег и друзей о конструктивной критике. Это поможет вам расти как программисту и как человеку.
24. Будьте всесторонне развиты
Технологии меняются, и меняются быстро. Не противьтесь новинкам, а изучайте и формируйте о них своё мнение.
25. Оставайтесь актуальным
Будьте в курсе последних технических новостей, следя за публикациями, блогами, подкастами и новостями.
26. Сосредоточьтесь на решении проблемы
Развитые навыки решения проблем помогут победить любую проблему. Оттачивайте то, что поможет решить проблему.
27. Оставайтесь скромным
Независимо от того, какое у вас звание или в какой компании вы работаете, оставайтесь скромным.
28. Учитесь делать отличные презентации
Учитесь, как увлекать аудиторию и делать отличные презентации
29. Изучите все решения, прежде чем остановиться на чем-то
Не хватайте первое попавшееся решение. Изучите все варианты перед тем, как приступать к написанию кода.
30. Найдите свою нишу
В технической индустрии существует много разных сфер. Найдите область, которая будет интересовать вас больше других и станьте в ней экспертом.
31. Развивайте хорошие привычки
Старайтесь вырабатывать устойчивые и полезные привычки, такие как удаление отвлекающих факторов, планирование своего времени, присутствие на собраниях и привычка начинать с наиболее важных задач. Это может потребовать определенных усилий, но оно будет стоить того в долгосрочной перспективе.
32. Изучайте отладку кода
Исследуйте инструменты браузера для отладки кода. Изучайте эти возможности в вашей IDE. Изучая наиболее эффективные методы отслеживания ошибок, вы будете способны решить даже наиболее сложные проблемы.
33. Развивайте свои текущие навыки
Просто потому, что в данный момент вы овладели каким-то навыком, не значит, что не нужно продолжать развивать его. Навыки со временем теряются, если сознательно не совершенствуются, а индустрия эволюционирует настолько стремительно, что важно продолжать практиковаться. Избавьтесь от типа мышления «Я всегда это делал таким образом» и переключитесь на «Есть ли лучший способ сделать это?».
Даже если сейчас у вас отличный пресс, глупо надеяться, что вы сможете съедать по пончику в день и не потерять его
34. Поймите, почему
Будут ситуации, когда вы должны будете высказать своё мнение, поэтому предварительно важно понять, почему. Почему решение «А» лучше решения «Б»? Предоставьте правильные аргументы и ваше мнение будет более обоснованным.
35. Знайте себе цену
Вы — товар, и должны быть надлежащим образом оплачены. Будьте осведомлены о средних зарплатах в вашей сфере в регионе, где находитесь. Если вы получаете меньше денег, пора поговорить с менеджером. Идите за тем, чего заслуживаете.
36. Не бойтесь просить о помощи
Если вы застряли на проблеме и тратите слишком много времени на поиск решения, самое время обратиться за помощью. Все мы люди. Нам всем может понадобиться помощь. Нет ничего постыдного в том, чтобы обратиться к коллеге за поддержкой.
37. Учитесь учиться
Люди обучаются по-разному. Одним лучше обучаться с помощью видеоуроков, другим — через чтение книг. Определите подходящий вам стиль обучения и старательно практикуйте его.
38. Будьте добрым
Будут ситуации, когда вас попросят дать отзыв о коллеге. Будьте добрым. Вы можете высказать мнение о недостаточной инициативности Деборы, не разрывая её на части.
39. Делайте перерывы
Практически невозможно 8 часов подряд проводить за написанием кода. Вы быстро выгорите и наделаете множетсво ошибок. Поэтому установите таймер, чтобы напомнить себе останавливаться и сделать перерыв. Сходите на прогулку. Попейте кофе с коллегами. Отвлечение от экрана положительно скажется на вашей продуктивности и качестве работы.
40. Отслеживайте свой прогресс
Обучение программированию занимает много времени и может быть невероятно изматывающим, если вы не видите прогресс. Поэтому важно отслеживать достижения и прогресс в движении к своей цели. Держите небольшой список рядом с компьютером и каждый раз, когда достигаете чего-то нового, отмечайте это, каким бы незначительным оно не было. Большие награды состоят из маленьких достижений.
41. Не полагайтесь на фреймворк или библиотеку
Изучайте нюансы языка программирования больше, чем тонкости фреймворка или библиотеки. Не обязательно изучать язык перед знакомством библиотеками, но понимание того, почему фреймворк или библиотека работают определенным образом, поможет вам писать более чистый и производительный код.
42. Учитесь любить код-ревью
Присутствие кого-то, кто читает и анализирует ваш код, может вселять ужас, зато может обеспечить бесценную обратную связь, которая сделает вас лучшим программистом, чем до этого. Вы также должны работать над способностью проводить хорошее код-ревью.
43. Интересуйтесь смежными областями
Изучите основы смежных сфер деятельности, таких как дизайн, маркетинг, фронтенд или бекенд разработка. Это поможет вам стать более разносторонним программистом.
44. Не выбирайте удобную технологию; выбирайте правильную
У каждого проекта разные потребности и поэтому мы должны выбирать правильные инструменты для работы. И хотя гораздо удобнее выбрать технологии, с которыми вы работали ранее, если они не соответствуют потребностям проекта, нужно изучить альтернативы.
45. Берите ответственность за свои ошибки
Все люди делают ошибки и вы будете допускать их на протяжении всей вашей карьеры. Поэтому очень важно признавать это и брать на себя ответственность, когда допускаете ошибку. Это поможет выстроить доверительные отношения с членами вашей команды и менеджментом.
46. Проверяйте свой собственный код
Перед созданием пул-реквеста, проверьте свой собственный код. Если это была работа коллеги, какие комментарии вы бы сделали? Очень важно сначала определить проблемы или ошибки, прежде чем запрашивать проверку кода.
47. Учитесь на своих неудачах
Неудача — это просто не достижение ожидаемого результата, и это не обязательно плохо. У всех нас случается много неудач в течение карьеры. Учитесь на своих ошибках. Что вы можете сделать по-другому в следующий раз?
48. Определите свои слабые стороны
Узнайте себя. Какие у вас слабые стороны? Может быть, постоянно забываете обновить тесты перед пушем. Или вы плохи в плане ответов на email-сообщения. Изучите свои недостатки, чтобы активно работать над ними.
49. Оставайтесь любопытным
Эта сфера постоянно эволюционирует, поэтому любопытство важно. Если вы чего-то не понимаете, будь то требования проекта или строка кода, скажите об этом. Никто не будет критиковать вас за то, что вы попросили разъяснений, и в результате вы создадите лучший код.
50. Не пытайтесь учить всё
В мире огромное количество знаний и просто невозможно освоить всё. Выберите несколько тем для освоения и отбросьте остальное. Вы конечно сможете получить косвенные знания о других областях, но не получится их все освоить.
51. Убейте своих любимцев
То, что вы пишете какой-то код, не значит, что вы должны быть эмоционально привязаны к нему. Никому не нравится, когда его работа выбрасывается, но код имеет жизненный цикл, не стоит забывать об этом.
52. Поддерживайте свою команду
В хорошей команде все поддерживают друг друга. Это создаёт благоприятную почву пробовать что-то новое без страха наказания.
53. Ищите вдохновение в сообществе
Найдите несколько человек из той же сферы, которые вас восхищают. Это будет вдохновлять вас продолжать работать над своими проектами или пробовать что-то новое.
54. Цените свою работу
Независимо от опыта или должности, ваша работа имеет ценность. Цените её по достоинству.
55. Заблокируйте отвлекающие факторы
Отключение уведомлений в мессенджерах, email и социальных сетях поможет вам сфокусироваться и провести рабочий день максимально продуктивно. Джерри не умрёт, если вы ответите ему через 30 минут.
56. Оказывайте поддержку
Поддерживайте членов вашей команды, например, посетив важную презентацию или помогая, если они застряли.
57. Хвалите тогда, когда этого заслуживают
Если кто-то проделал отличную работу, скажите об этом. Похвала — отличный способ завоевать доверие членов вашей команды.
58. Тестируйте ваш код
Тесты важны. Юнит-тесты, регрессивное, интеграционное, сквозное тестирование. Тестируйте свой код и ваш продукт будет более стабильным.
59. Распланируйте свой подход
Когда вы получаете запрос на разработку нового функционала или тикет с ошибкой, сначала разработайте план атаки. Что вам требуется, чтобы решить эту проблему или разработать функционал? выделение хотя бы нескольких минут, чтобы спланировать атаку, может сэкономить часы разочарования
60. Учитесь псевдокодировать.
Псевдокодирование — отличный навык, потому что позволяет вам решать сложные проблемы без затрат времени на написание строк кода. Опишите выбранный подход на бумаге, смоделируйте различные примеры тестирования и посмотрите, где подводные камни.
61. Отслеживайте свои достижения
Если вы получили награду на работе, запишите это. Если вы разрабатываете важную функцию, запишите это. Вы создадите беклог моментов, которые могут помочь в продвижении по службе или повысить моральный дух в трудные моменты.
62. Изучайте основы программирования
Изучите некоторые основные алгоритмы сортировки и поиска, а также структуры данных. Это поможет вам в решении задач независимо от языка.
63. Выбирайте долговечные и поддерживаемые технологии
Хотя тестировать самые новые технологии интересно, выбирайте те из них, которые будет легко поддерживать в enterprise-приложении. Команда будет благодарна вам долгие годы.
64. Изучайте шаблоны проектирования
Шаблоны проектирования — это полезные инструменты для разработки архитектуры кода. Вы можете не нуждаться в них на каждом проекте, но общее представление о них поможет при создании больших приложений.
65. Уменьшайте неоднозначность
Вместо написания сложного кода, демонстрирующего ваши умелые навыки программирования, стремитесь к удобочитаемости и простоте. Это поможет членам вашей команды легче внести свой вклад.
66. Погашайте технический долг
Технический долг может иметь серьезные последствия для производительности, поэтому если можно провести рефакторинг, вы должны это сделать.
67. Обновляйтесь чаще
Вместо того, чтобы выпускать масштабные обновления раз в месяц, делайте это чаще с меньшим списком изменений. С меньшей вероятностью вы сделаете ошибки и сломаете изменения.
68. Делайте коммиты рано и часто
Делать коммиты рано и часто — лучший способ обеспечить чистоту вашей работы, а также уменьшить стресс от случайного возврата важных изменений.
69. Поймите, когда нужно просить о помощи
Вам следует не только не бояться просить о помощи, но и понять, когда это следует делать. Вы всегда должны пытаться решить проблему перед тем, как просить о помощи. Но когда вы боретесь с проблемой больше часа, стоимость перевешивает выгоду, и вам следует обратиться к коллеге.
70. Задавайте правильные вопросы
Когда задаете вопрос, старайтесь быть настолько конкретным, насколько это возможно
71. Получайте отзыв о незаконченной работе
Вам не обязательно заканчивать работу, чтобы получить отзыв о ней. Если вы не уверены в правильности выбранного направления, попросите коллег помочь проверить это.
72. Читайте документацию
Документация — это чистейший источник правды о технологии, поэтому умение читать её может быстро помочь вам стать экспертом.
73. Пробуйте всё
Ничего не мешает вам попробовать решение проблемы. Что вам терять?
74. Разговаривайте на встречах
Ваши идеи и мнения ценны, поэтому участие в митингах поможет вам развить взаимопонимание с командой и руководством.
75. Сотрудничайте с другими командами
Если появилась возможность поработать с другой командой в вашей компании, воспользуйтесь ею.
76. Обзаведитесь личными проектами
Когда вы работаете 40 часов в неделю, важно выделять время сторонних проектов, которыми вы увлечены. Они помогают оживить вашу любовь к программированию и попробовать новые технологии, к которым у вас может не быть доступа на работе.
77. Определите свои карьерные цели
Важно иметь представление идеального карьерного пути. Если этого нет, вы пытаетесь пустить стрелу, не видя цели.
78. Участвуйте в беседах
Комментарии в блогах, участие в разговорах в Twitter. Взаимодействуйте с сообществом. Вы узнаете гораздо больше, если будете активным участником, а не овощем.
79. Распределяйте задачи по приоритетам
Обучение расставлять приоритеты к задачам поможет увеличить продуктивность. Ведите текущих ежедневных задач, а также долгосрочных задач, и упорядочивайте их по наиболее важным.
80. Не упускайте из виду детали
Детали могут иметь большое значение в проекте
81. Доверяйте своей команде
Ваших коллег по команде наняли на работу за их навыки. Используйте их и доверяйте им, чтобы выполнить работу.
82. Учитесь делегировать
Если вы занимаете руководящую должность, учитесь эффективно делегировать полномочия. Это сэкономит вам время. Вы не можете делать все сами.
83. Не сравнивайте себя с другими
Единственный, с кем вы должны себя сравнивать, — это кем вы были вчера.
84. Окружите себя союзниками
Обучение программированию будет долгим, и не всегда легким, путем. Окружите себя людьми, которые будут подталкивать вас идти вперед.
85. Не начинайте с масштабируемости
Начинать масштабируемости — это верный путь перегрузить себя. Создавайте с учетом масштабируемости, но не начинайте масштабирование, пока в нем не появится потребность. Таким образом, вы не перегружаете свою команду, но сохраняете способность к росту.
86. Взвесьте последствия для производительности
Если вы хотите использовать крутую новую технологию, прежде вы должны взвесить последствия для производительности. Не можете ли вы реализовать что-то подобное без потери производительности? Если да, может возникнуть желание пересмотреть выбранный подход.
87. Не допускайте дискриминации
Не допускайте дискриминации новых технологий или идей. Будьте открыты возможности освоить новые навыки. Также не допускайте дискриминации людей. Мы все заслуживаем уважения.
88. Беритесь за работу, для которой недостаточно квалифицированы
Вы никогда не будете соответствовать всем требованиям для работы. Поэтому используйте шанс и приступайте! Что вы потеряете?
89. Разбивайте код на модули
Вы могли бы писать весь код в одном длинном файле, но это сложно поддерживать. Благодаря модульности, мы убеждаемся, что наш код легко воспринимать и тестировать.
90. Не следует просто копипастить
Если собираетесь скопипастить решение со StackOverflow, вы должны точно понимать, что оно делает. Разбирайтесь в коде, который решили внедрить.
91. Создайте вдохновляющую среду
Вы будете намного более мотивированы работать, если удовлетворены своим рабочим местом.
92. Помните, откуда вы пришли
Мы все начинали с одного и того же. По мере развития ваших навыков и карьеры не забывайте, откуда пришли.
93. Старайтесь оставаться оптимистом
Если что-то не получается, продолжайте пытаться и будьте оптимистом. Завтра новый день. Оптимизм поможет движению вашей команды и вашему психическому здоровью.
94. Постоянно переоценивайте свой рабочий процесс
Просто потому, что что-то работает сейчас, не значит, что так будет всегда. Переоценивайте свой рабочий процесс и вносите коррективы, когда это нужно.
95. Учитесь работать из дому
Если у вас есть возможность, работать из дому, учитесь делать это эффективно. Найдите отдельный офис, лишенный отвлекающих факторов. Boneskull написал отличную статью о работе из дому, с которой вам следует ознакомиться.
96. Создавайте доступные продукты
Каждый должен иметь возможность воспользоваться вашим продуктом
97. Соблюдайте свои обязательства
Если вы сказали кому-то, что сделаете что-то к определенной дате, соблюдайте свои обязательства. И если вы не можете уложиться в оговоренный срок, сообщите об этом заранее.
98. Будьте инициативны
Если у вас есть свободное время, помогите с выполнением задач своей команды. Они будут благодарны за вашу инициативу.
99. Создайте потрясающее портфолио
Отличное портфолио выделяет вас из толпы. Используйте это как шанс показать свои навыки программиста и дизайнера.
100. Помните, почему любите программирование
Вы подались в эту профессию, потому что она вызвала интерес. Если вы выгораете, сделайте перерыв. Дайте себе возможность возродить свою страсть к программированию.
101. Делитесь своими знаниями
Если вы освоили что-то крутое, поделитесь этим. Представьте на местом митапе или конференции. Обучайте своих коллег или подопечных во время обеда. Обмен знаниями укрепляет их.
как получить первую работу / Luxoft corporate blog / Habr
Не только я в свое время, а многие мои приятели и однокурсники сейчас серьезно обеспокоены вопросом: хочу быть программистом, как начать?Целью написания статьи послужили не только сомнения в себе моих знакомых. Подозреваю, что количество людей, которые в данный момент думают на этим же вопросом, достаточно велико, дабы моя первая в жизни статья смогла помочь каким-то планом более чем паре друзей.
В чем состоит проблема? Нужно составить резюме, закинув в раздел «Professional skills» пару технологий, соответствующих искомой вакансии, разослать по вакансиям и вроде как должно все получится. Но есть подводные камни:
1) Качество технического образования. Несмотря на то, что моя специальность носит гордое название «Компьютерные науки», в 70% учебной программы знания по предметам даются устаревшие, а преподаватели либо просто пожилые люди, давно отставшие от современных технологий, либо ко всему с крепчающим маразмом. А из этого следует проблема несоответствия требованиям рынку труда студента, желающего стать разработчиком, но имеющего пробелы в понимании современных технологий. Я уверена, что не единственная, кто столкнулся с этим.
2) Неуверенность в себе и сомнения. Начинающий разработчик зачастую элементарно боится пойти на собеседование, считая себя не готовым даже для попытки. Он может неверно оценивать степень своей подготовки. И наконец, этот же человек порой знает только один способ получить работу – например, курсы в той или иной компании. Но ограниченность выбора (у тех же курсов есть временные рамки набора, требования, собеседования) только порождают лишние препятствия и сомнения. Итог — упущенное время.
3) Наличие или получение диплома не по специальности. Хороший разработчик с техническим складом ума может не обязательно быть им по образованию. Но программист-самоучка часто делает то, нравится и то как видит сам. Отсутствие какой-либо системности в полученных им знаниях и пробелы в азах могут стать причинами отказов после прохождения интервью.
Немного о себе: я студентка пятого курса, работать начала с середины третьего, сразу на full-time на позиции Automation QA. В предыдущей компании отработала почти полтора года на двух проектах. В настоящее время работаю на позиции junior java developer в Luxoft. Текущий опыт работы с javа: около 2-х лет.
В сегодняшней публикации хочу предложить вашему вниманию обзор всех известных мне путей, итогом каждого из которых может стать желаемая работа разработчиком (проверенные на практике проиллюстрирую примерами). Все истории, упоминающиеся ниже курсы компаний соответствуют Киеву, камни в огород образованию — КПИ, факультету информатики и вычислительной техники (особо большой валун для моей кафедры).
1. Курсы в той или иной компании.
Luxoft, Epam, Yandex, Global Logic — далеко не весь перечень компаний, которые приглашают к себе на курсы, в интернатуру и тренинг-центры. Много учебных классов открыты в технических университетах.
Плюсы этого варианта очевидны:
• бесплатное обучение
• работа с востребованными на рынке труда технологиями на интересных реальных задачах
• последующее трудоустройство в этой же компании
• в случае смены работы – неспоримый плюс для других работодателей.
К сожалению, минусов не меньше:
• ограничение по времени набора слушателей (зачастую или с начала учебного года или весной). Для тех, кто не успел– ждать и терять время.
• требования к претендентам. Компаниям не выгодно набирать на курсы людей, далеких от IT, поскольку на их обучение и ввод в реальные проекты понадобится больше времени, а значит – больше затрат. Поэтому они предпочитают сотрудничать с определенными факультетами технических ВУЗов, а значит — меньше шансов попасть человеку “со стороны”.
2. Профильные курсы в образовательных центрах
По данному запросу Google услужливо подскажет массу центров, школ и курсов, которые готовы сделать из любого человека Джобса(зачер.) программиста. Главное — желание и серьезный подход к занятиям.
Плюсы данного варианта:
• обучение востребованным на рынке IT специальностям и технологиям
• высокая вероятность трудоустройства по окончанию (у меня было трое коллег в команде, прошедших одни и те же курсы Java в разное время. По окончанию двоих пригласили на интервью hr, а третий сам отправил резюме). В последствии, одному из них эти курсы стали хорошим подспорьем для работы над новым проектом (в котором мне, например, зная только Сore но не ЕЕ, приходилось разбираться походу).
• набирают всех желающих и готовых учиться
Минусы:
• они не бесплатны. Зачастую недоступны для студентов, чья стипендия раза в 2 меньше стоимости месяца обучения там.
• не все курсы одинаково качественные. При выборе центра ориентируйтесь на отзывы реальных людей, а не на рекламу и сладкие обещания гарантированного трудоустройства.
3. Первая работа на позиции automation QA
Начну, пожалуй, со своего примера, ведь это была моя первая работа в ІТ. В целом, практических знаний и минимального опыта для работы разработчиком мне катастрофически не хватало, а вот тестировщиком взяли (несложные вопросы по Java Core и сетям). Я попала на проект, в котором процесс тестирования клиента заключался в написании командой Automation QA Android приложения, отправлявшего по определенным паттернам много разных запросов на разные ресурсы. Так же у нашей команды был свой фреймворк с кучей утилит для анализа логов, tcp dump’ов, поведения девайса, а я получила первый дев-опыт в написании собственной утилиты для конфигурирования ip-tables. А еще понимание модели OSI, опыт работы с клиент-серверным приложением и наконец – пройденный production-проект, факт наличия которого помог в последующем поиске работы. Именно поэтому не считаю работу automation чем-то зазорным, примитивным или плохой ступенью к работе разработчика – прежде чем сказать «нет» нужно хорошо разобраться, в чем она будет заключаться. На втором проекте в этой же компании мне дали задачу покрыть старый функционал unit-тестами, разрешили немного порефакторить. Работа конечно скучноватая, но после нескольких месяцев пошли задачи фикса несложных багов. Таким образом, получила опыт работы с Unit тестированием (Powermock, Mockito) и навык быстро разбираться в незнакомых технологиях (тот же баг в JavaScript).
Выделю плюсы данного варианта:
• при правильном выборе проекта — работа и обучение в одном флаконе (никто ведь не мешает параллельно общаться с разработчиками на своем же проекте, получать от них практические знания, самому что-то читать и писать в свободное время)
• деньги. Очень мотивируют расти профессионально в работе с понравившимися технологиями. Ну и хочется жить не только на стипендию.
• опыт работы production (используя Scrum, системы контроля версий, системы трекинга задач (та же JIRA) и т.д). Вот в университете мне почти ничего такого не рассказывали (до середины третьего курса точно), что-то там о Scrum было на 4-м, C Git познакомилась только в этом году (спасибо преподавателю — Android-разработчику). Это преимущество при поиске следующей работы и во время выполнении задач на ней (когда только устроившемуся junior’у не придется в панике под ночь пересоздавать какой-то бранч, или искать, как поменять коммит потому что сегодня конец спринта, а с тем же Git’ом или пониманием планирования задач непорядок.
• опыт работы с технологиями, который потом можно выгодно подать и продать, рассматривая позиции разработчика. (Например, после своего первого проекта мне хватит знаний претендовать на позицию на проекте с клиент-серверным взаимодействием)
Без минусов, увы, никак:
• даже в случае глубокого погружения в программирование на позиции QA, потом нужно немало попотеть в правильном составлении резюме и подаче своего опыта, дабы пригласили на собеседование на позицию разработчика. Я не говорю, что это жесткое правило, читайте «такое часто бывает» а не «это жесткое правило». А теперь немного проиллюстрирую. Первый пример – мой коллега, Automation QA: без особых усилий нашел новую работу разработчиком в небольшой конторе, где предыдущий опыт не сыграл никакой роли. Второй пример – я. Действительно данный минус открылся мне неприятным фактом при поиске работы разработчиком(не хотели приглашать на интервью), но я правильно составила CV (указав предыдущую позицию, разумеется, но кратко описав все свои responcibilities на двух проектах и общий стаж работы с Java). А еще разослала его везде куда нашла, существенно повысив шансы попасть на как можно большее к-во собеседований.
• риск остаться тестировщиком. Не слишком обременительные обязанности, зарплата не ниже чем у разработчика и простой код расслабляют. В таком случае подумайте, чего вы вообще хотите – много денег, интересные задачи, или не делать ничего.
4. Университетская подготовка, учебные проекты, работа в лабораториях.
В ВУЗах есть масса возможностей чему-то научиться, хорошо поискав. Нравится делать сайты? Напиши\перепиши\саппорти факультетский или каферальный сайт. Хочешь кодить под Андроид? Напиши свое приложение, которым сам, как студент, хотел бы пользоваться. Поищи в университете лаборатории и образовательные центры – вот и первый опыт. Словом, нужно пересмотреть все возможные варианты в непосредственно своей в среде обитания.
Плюсы:
• технический опыт (в случае наличия технически подкованного руководителя качественное дополнительное обучение)
• умение самостоятельно обучаться новому. Мой нынешний преподаватель разработки под Android сделал в качестве своей дипломной работы приложение для студентов нашего университета с расписанием, преподавателями, картой корпусов и университетским радио. Несмотря на некомпетентного в данном вопросе руководителя, он разобрался сам, и после сдачи диплома устроился Android-разработчиком без особых проблем.
Минусы:
• будьте готовы к тому, что ответственность за начатый проект ляжет на ваши плечи, а преподаватель\руководитель может оказаться не компетентным помочь вам технически, но очень дотошным как заказчик.
• забудьте об оплате своего труда (надеюсь, не нужно объяснять, почему).
5. Open source проекты
Здесь уж каждому по способностям и предпочтениям. Выбрав понравившийся проект на том или ином языке, отличное начало — дописать в него несложный функционал либо отрепродьюсить и пофиксить несложный баг. Это возможность поработать над реальным проектом с опытными разработчиками, получая от них feedback и знания. Чтение чужого кода учит не только компилировать его в голове но и сходу находить “узкие места” или некорректную реализацию.
Плюсы: перечислила выше 🙂
Минусы:
• этот способ подготовки не может быть единым, а лишь как дополнение и закрепление знаний на практике.
6. Домашняя подготовка
К ней относится чтение технической литературы, онлайн — уроки, изучение документации, наконец целенаправленная подготовка к интервью. Лучший вариант домашней подготовки — параллельное ведение собственного небольшого проекта и чтение литературы. Придумать приложение, которым пользовался бы сам, разделить на задачи и каждый день по несколько часов разбираться с ними — не сложно. Главное начать. А как писать — Google в помощь, новичку сейчас там можно найти ответ практически на любую возникшую проблему.
Достаточно много плюсов:
• чтение книг и документации дает хорошую базу не только для прохождения интервью, но и на будущей работе
• первый проект можно и нужно выкладывать в открытый доступ, критика других покажет узкие места и возможные пути изменения, доработки, улучшения
• наличие готового приложения (пусть небольшого) — аргумент для работодателя и возможность для интервьюера оценить практический опыт претендента (большой плюс)
• умение самостоятельно планировать время и решать поставленные задачи (это умеет далеко не каждый разработчик, увы)
Минусы:
• первые ошибки, которым не удастся найти решение, и отсутствие опытного куратора, могут отбить желание продолжать вообще. В таком случае, стоит задуматься — а чего ты вообще можешь добиться в этой жизни, если опустил руки от мелкой проблемы? Хм, пожалуй, это больше плюс.
• отсутствие куратора может завести требования, архитектуру или реализацию проекта в “дебри”
7. Комбинация перечисленных выше.
Никто не запрещает работая Automation QA ходить по вечерам на курсы, или учась и делая какой-то проект в университете, дома пилить задачи в Open Source проекте и читать книги. Чем больше вы прилагаете усилий, тем больше имеете шансов получить желаемую работу. Думаю, что в любой комбинации плюсами будут выступать как раз все перечисленные выше варианты. Главный минус, который хочу здесь выделить – откладывание поиска работы «на потом». Постоянно мониторьте рынок, особенно те вакансии, которые касаются интересующего вас языка или технологии. Периодически ходите на собеседования, дабы понимать свой реальный уровень и прогресс.
Я допускаю, что во многих приведенных выше правилах найдутся свои исключения. Но, как известно, они лишь подтверждают правила.
Как программисту зарабатывать еще больше / Habr
По мотивам поста «Что делать программисту, чтобы получать нормальные деньги…», хочу поделиться мыслями о том, что делать программисту, чтобы получать хорошие деньги.
Итак, вы не пошли в госконтору, избегаете маленьких студий, ориентированных на внутренний рынок и работаете в компании с неплохими перспективами. Как увеличить свой доход?
Принято считать, что доход в IT зависит от времени и лояльности:
Доход = Скилы * Время * ЛояльностьИнтуитивно кажется, что нужно хорошо работать. Не опаздывать на дейли. Разобраться в своей части проекта. Ставить долгосрочные цели. Овертаймить, если необходимо. Не конфликтовать. Стремиться стать незаменимым.
Но за 12 лет в IT я видел много примеров того, как это не работает. Как технически сильные ребята зарабатывают меньше рынка. Ждут следующего ревью, надеясь, что в этот раз их, наконец, оценят по достоинству.
Но этого не происходит. Приходится снова экономить на маффинах и черничных смузи. И план покупки Tesla Model 3 сдвигается в очередной раз.
На деле, ваш доход зависит от других параметров:
Доход = Скилы * Разговорный английский * Понимание бизнеса * Умение вести переговорыРазговорный английский
Мне сложно передать насколько это важный скилл, вне зависимости от должности в IT.
И вроде как все понимают, насколько он важен, но мало кто занимается им всерьез. Ключевое слово — разговорный. Если вы не можете поддержать диалог, считайте что английского у вас нет.
Чтобы научиться говорить по-английски, надо говорить по-английски. Стесняться, краснеть, потеть, но говорить. Зона развития расположена вне зоны комфорта.
Понимание бизнеса
Между «просто делать таски в джире» и «понимать на чем продукт зарабатывает деньги» огромная разница. Продакт менеджеры не провидцы. Добрую долю задач, которые ими ставятся, можно сделать проще, сделать позже или не делать вообще.
Когда вы понимаете бизнес, вы начинаете добавлять ценность не только в код, а и в продуктовые решения. А значит, растет и ваша ценность.
Переговоры
Ваши доходы это чьи-то расходы. Если вы не готовы к переговорам, вы их гарантированно проиграете. Литературы на эту тему масса. Из того что мне понравилось — Гэвин Кеннеди «Договориться можно обо всем».
Простой пример:
«Хочу повышение потому что… прошло два года», «… я развиваюсь», «… планирую купить машину» — слабая переговорная позиция. «У меня тут оффер на $4k» — сильная.
Достаточно проходить пару собеседований в год, чтобы быть в курсе ситуации на рынке.
In real life you never get what you deserve. You get what you negotiate.
Почему я об этом пишу
Я работал на разных руководящих позициях от PM в аутсорсинге до CTO в продуктовой компании и видел много карьерных историй от стремительных до тупиковых.
Мой Telegram: @thinkdecide
Как программисты-самоучки в реальности получают работу / Habr
Вопрос с Quora:
Как программисты-самоучки в реальности получают работу?
Мне 17 лет и я занимаюсь программированием с 14-ти. Основной упор на Java, я получил 5 баллов по предмету AP Computer Science. Я довольно хорошо разбираюсь в Java (синтаксис, основные классы, GUI/JFrame и т.д.) и неплохо знаком с HTML5 и CSS3. Кажется, мне не хватает многих знаний, чтобы реально претендовать на работу в индустрии (например, как работают СУБД и какую из них следует использовать), и мне интересно, как другие программисты изучают такие вещи. Я планирую пойти в колледж по специальности «Разработка программного обеспечения», но меня начинает расстраивать мысль, что колледж — необходимое условие, чтобы получить работу. Есть ли какие-то курсы, которые я пропустил, хотя должен был изучить их, или что-то другое, чего я не сделал?
Мой ответ:
Думаю, ты неправильно смотришь на вещи. Ты думаешь, что должен пройти курсы, чтобы кто-то другой дал ответы и научил тебя. С фундаментальной точки зрения программисты-самоучки действуют иначе.
У программиста-самоучки много общего с тем, кто самостоятельно научился игре на гитаре. Не знаю, играл ли ты когда-нибудь на гитаре, так что объясню, как происходит обучение.
Во-первых, всё начинается с того, что кто-то видит, как другой человек играет на гитаре. Большинство из тех, кто уже играет, в какой-то момент хотели быть на кого-то похожими. После этого он принимает решение: «Я тоже могу научиться!», идёт в местный магазин музыкальных инструментов и покупает бэушную гитару (потому что она дешевле, но всё равно крутая).
Далее происходит одно из двух. Или человек находит самоучитель игре на гитаре в каком-то виде, ИЛИ он идёт на YouTube и начинает пробовать играть свои любимые песни. Как правило, второй вариант эффективнее.
Теперь, когда юный гитарист замотивирован сыграть конкретную песню, он будет смотреть видео, распечатывать табы, аккорды и так далее — он будет сидеть и пытаться сам воссоздать песню, руководствуясь видеороликами и доступными табами.
После многих часов практики, подбора аккордов, соло, ритма и прочего, он сможет сыграть свою версию песни. Она будет не совсем такой же, но достаточно близка к оригиналу для рок-н-ролла.
Потом он выберет другую песню, которая ему нравится, и ещё одну. Постепенно начинающий гитарист освоит шаблоны, техники и всё остальное, даже не понимая, что это такое. Он просто находит способ сделать необходимую вещь, не изучая названия и теории.
В конце концов игра на гитаре станет «естественной», а изучение новой песни — обычным и безболезненным делом. «Язык» гитары для него станет чем-то естественным, вроде человеческой речи.
Всё это происходит в течение тысяч часов практики. Даже если практиковаться несколько часов в день, процесс занимает годы.
Так какое это имеет отношение к программистам-самоучкам?
Ну, что действительно делает из самоучки программиста — так это то, что он создаёт разные штуки. И много всяких штук. Чтобы стать отличным программистом с востребованными навыками, ты должен создавать вещи и писать код.
Посещение классов и изучение теории — это хорошо, но многие профессоры не способны написать даже простейшую программу. Они не могут сделать тебе полезное приложение, которое кто-нибудь захочет использовать.
Не то чтобы они не знают свой предмет, просто главное в преподавании — это исследовать предмет и понимать теорию, а не писать код и приносить пользу клиенту.
Чувствуешь разницу?
Самые лучшие программисты, с которыми я когда-либо работал, стали такими, потому что писали реальный код. Практически постоянно.
Например, сегодня каждый веб-разработчик (и его брат) используют WordPress. Задолго до WordPress я написал для себя 3 или 5 разных систем управления контентом на PHP и MySQL. Я делал игры. Писал мобильные приложения. Фреймворки. SAAS-приложения.
Никто не платил мне за это. Всё это я делал для удовольствия или для обучения, или из любопытства.
Много лет я не посещал никаких курсов и не думаю, что они бы значительно продвинули мою карьеру. Но если бы я сел и решил создать собственный язык программирования или операционную систему с нуля, то наверняка узнал бы много полезного по ходу дела.
Да, я мог посещать курсы по этим предметам. Но гораздо больше можно узнать, если самому создавать вещи, делать ошибки и по-настоящему «чувствовать» всё это, а не узнавать из книги или лекции.
Так что могу дать совет, с помощью которого ты получишь огромное преимущество над теми, кто такого почти не делает…
Решай проблему, которую способен решить. Создавай программы, которые делают такие классные вещи, какие ты сам или другие хотели бы увидеть в программе. Пиши код каждый божий день. По вечерам, в выходные, каждый день. Даже если только 15 минут, нормально.
В конце концов у тебя получится что-то работающее и довольно приличное.
Затем начинай снова. Сделай что-нибудь ещё. Продолжай писать и писать, и писать, и писать. Вложи в свой скилл тысячи часов, бросая себе вызов на создание новых проектов.
По мере написания кода сохраняй работу в маленькое портфолио на своём сайте. Каждый раз по окончании проекта сообщай о нём на Hacker News или Reddit, или ещё где-то. В блоге.
Тебе 17… К 20-ти годам ты легко можешь вложить более 2000 часов в разработку своего навыка, в портфолио будет 10-20 проектов и ты выучишь многие уроки, которые учащиеся на курсах никогда не выучат.
Что ещё важнее, ты сможешь ясно продемонстрировать свою способность писать код, решать проблемы и выпускать что-то рабочее в этот мир. Это большая ценность. Именно то, что ищут компании.
Как только найдёшь работу, продолжай программировать в свободное время и продвигать свои проекты. Ты будешь расти быстрее, чем сверстники, потому что они приходят домой и смотрят телевизор, не обучаются, не растут и не создают НИЧЕГО. Они получают зарплату и идут домой.
Чем больше будешь создавать, тем больше у тебя знаний. Чем больше знаний, тем выше твоя ценность. Чем выше ценность, тем легче найти работу, тем больше зарплата и так далее.
Так что вылезай из скорлупы и создай что-нибудь. Пиши код!
Десять советов начинающим программистам / Habr
Предисловие
Хорошо, когда работаешь с человеком, который отлично знает толк в своём деле. А что, если случается работать с коллегой, опыт которого не столь большой. Особенно это касается профессионально-личностных качеств. Невольно приходится подсказывать, местами помагать ему, а где-то даже откровенно учить. Все мы когда-то начинали. Все эти действия требуют немалых усилий, которые можно было бы применить по прямому назначению — в разработке проекта, но без подготовки новых специалистов будет тяжелее.
Так вот, чтобы минимизировать эти затраты, давайте «создадим» хорошего, а возможно и идеального начинающего программиста, с высоким потенциалом и светлыми горизонтами.
Предлагаемые здесь десять советов не претендуют на оригинальность и, в основном, базируются на моем небольшом пятилетнем опыте разработок. Итак, начнем.
1. Будьте самостоятельными
Если у вас есть какой-то вопрос, и вы не знаете как с ним поступить, то вначале постарайтесь исследовать его самостоятельно. Не ждите постоянной помощи от коллег — у них и без вас работы хватает. Используйте всю мощь поисковых систем, специализированных ресурсов (например, stackoverflow), профессиональных блогов, форумов разработчиков, и конечно же хабра. Большинство типичных «граблей» можно обойти различными эффективными вариантами, а для решения базовых задач есть дюжины готовых решений. Просто пойдите и возьмите.
2. Умейте спрашивать
Если самостоятельные поиски ответа на вопрос не дали результатов и вы долгое время топчетесь на месте, то не бойтесь спросить помощи у более опытных коллег.
Перед тем, как задать свой вопрос, не спешите, постарайтесь его максимально четко сформулировать. Возможно, что ответ на вопрос уже кроется в самом вопросе.
Если нужно показать какой-либо алгоритм или схему и указать на «тёмные», проблемные или слабые места, то для изображения старайтесь пользоваться специальными инструментами (например, UML), это позволит эффективно продемонстрировать предмет вопроса, а также даст вам прибавку к навыку проектирования.
3. Постоянно развивайтесь
Все мы являемся свидетелями сногсшибательных темпов развития технологий. Особенно это касается нашей сферы деятельности. Помните, что многое, что преподавали вам в ВУЗе, к сожалению может очень быстро устареть, стать не актуальным. К счастью, это пока не касается фундаментальных технических наук. Будьте готовы к тому, что вам постоянно придется постигать что-то новое, разбираться в свежих инновационных технологиях и исследовать новые тенденции всё время, которое вы будете выступать в роли разработчика программного обеспечения. К тому же подрастающее поколение не дремлет и создает конкуренцию. Важно понимать и то, что для эффективного и быстро освоения технологии, нужно постоянно тренировать сам навык обучения и не давать ему атрофироваться.
4. Не бойтесь учиться оценивать
Вспоминая себя, вначале у меня была своеобразная боязнь оценки поставленной задачи. И я с переменным успехом то промахивался, то попадал. Могу вас сразу успокоить, эта задача является настолько не простой, что для её решения существует множество комплексных методик, разрабатываемых не одним поколением специалистов, и это не только в айти. Мне кажется, что я вас изрядно напугал. Ну да ничего, поймаете пару ударов граблями, угостите пивом более опытных коллег, чтобы разузнать их ноу-хау, и у вас будет базовый навык эстимации задач. Со временем, приобретая опыт по решению различных задач, картина будет весьма ясной, например, вы без труда поймете, что на реализацию фичи «свистелка-пыхтелка на jQuery» понадобится 6 часов плюс 2 часа на риски. Так что это дело наживное.
5. Не забывайте о всей картине системы
Разрабатывая очередной класс, реализуя паттерн или же исправляя хитрый баг, не забывайте о всей картине создаваемого ПО. Иногда случается так, что в результате чрезмерно-увлечённой работы над каким-то участком кода сужается видимость проекта, что приводит к потенциальным конфликтам в коде, нелепым ошибкам и провоцирует появление узких мест в системе.
Старайтесь тренировать общее видение картины через распечатанные на бумаге диаграммы классов (либо ключевые её части), схемы алгоритмов, комплексные структуры данных и прочие важные компоненты. Это поможет в случае замешательства быстро освежить общее представление и вернутся в здравый ритм.
6. В меру используйте готовые решения
Наверное, нигде больше, чем в айти, не изобретается такое огромное количество велосипедов. В этом есть как свои плюсы, так и откровенные минусы. Важно понимать, что если есть достаточное количество времени, задача не сложная и вы хорошо представляете, что нужно делать, то можно написать свою реализацию, которая гармонично впишется в общий стиль проекта. Это как минимум даст вам понимание процессов изнутри, и конечно же практический опыт. Однако, если времени в обрез, либо задача успешно решается комплексным инструментарием, например, популярным фреймворком, задействованным на проекте либо каким-то компонентом из библиотеки, то эффективнее использовать готовое решение. Учтите, что возможны ситуации, когда в дальнейем может потребоваться оптимизация или расширение выбранного вами решения.
7. Цените свой труд
Не подходите к задаче, как одолжению, иначе от вас будет только вред. Цените то, что вы творите, ведь вы именно творите и создаете. Не пожалейте пары минут на оформление кода, согласно общепринятым стандартам в компании или команде. Вычистите свой результат, будьте педантичны, воспитайте в себе эту привычку, если её еще нет. К примеру, если у вас «съехал» элемент интерфейса на несколько пикселей вправо, то не пожалейте времени поправить его, вернув на место. Обязательно проверяйте и запускайте результат своей деятельности, не перекладывайте всё на плечи без того загруженных инженеров по контролю качества. В итоге вас обязательно заметят и оценят по достоинству, и все, потому что вы цените то, что создаете.
8. Не будьте ленивыми
Комменты на хабре, просмотр роликов на ютубе и прочие скайпы во время простоев на работе — это не плохо, но гораздо лучше заниматься чем-то полезным как для себя, так и для коллег. Прочитали об интересной технологии, которую потенциально можно применить на проекте? Попробуйте её в деле — нагрузите тестами в песочнице, сравните полученные результаты с уже используемыми сходными технологиями, или же напишите «hello world» в виде движка для блога либо другой тривиальной (но не слишком) задачи. Также хорошо в свободное время можно создать что-то своё: будь то простенький greasemonkey-скрипт для любимого веб-ресурса, или же давно не дающая покоя оригинальная мысль для стартапа. В любом случае огромным плюсом после всего этого будет поддержание рабочего тонуса и, как следствие, хорошие результаты в решении новых задач.
9. Умейте правильно излагать свои мысли
Старайтесь кратко и четко излагать свои мысли. Не зря говорят, что краткость — сестра таланта. Если вам приходится не просто и словесная «вода» льется без остановки, то тренируйтесь «на кошках»: запишите мысль на бумаге, постарайтесь вдумчиво выделить базовый тезис и, через постепенное вычеркивание «лишних» и «приукрашающих» слов и фраз, очищайте его. Отнеситесь к этому, как к игре — с азартом, энтузиазмом и интересом. В роли второй «кошки» выступает, как ни странно, твиттер, с его ограничениями на сообщения.
10. Не ограничивайтесь своей ролью
Вначале вы будете заниматься выполнением поставленных задач. И иногда вам будет казаться, что менеджер не прав, клиенты тупые, а тимлид тиран и узурпатор. Часто это всего лишь иллюзия, которая может изрядно подпортить отношения в коллективе и даже подмочить вашу репутацию. Чтобы понять движущие их мотивы, постарайтесь поставить себя на место того или иного человека, подумайте, как бы вы поступили на их месте, имея ряд ограничений и обязанностей. Чаще всего человека можно понять, в противном случае вам просто не повезло, и тогда уже приложите усилия для продуктивной коммуникации. То же самое применимо, когда вы вырастите и смените роль разработчика на ту, которая была ранее непонятна. В этом случае просто вспомните себя, и старайтесь не давить на без того замученного программиста.
Послесловие
Для кого-то это само собой разумеющееся, и, возможно, на меня повесят погоны всем известного капитана. Но, как показывает практика, к сожалению не все это понимают и, в последствии, набивают глупые шишки как себе, так и коллегам. А ведь этого можно было избежать.
В комментариях горячо приветствуются другие полезные и конструктивные советы. Уверен, что будет интересно все, как на базе своего опыта, так и советы, полученные в наставление от более опытных и мудрых коллег.
как стартовать и куда двигаться? / Habr
Бывает, что человек, совсем не связанный с IT, проникается интригующей красотой этой сферы и ставит себе задачу постепенно освоить программирование с нуля. И тут он зачастую просто теряется, не понимая, с чего начать, и нуждаясь в хорошем фундаменте и системном подходе.Я, будучи недавно в такой же ситуации, гуглила, искала мануалов на Хабре (кое-что нашла: Десять советов начинающим программистам, Начинающему программисту про стартапы и не только…), но в итоге всё же была вынуждена обратиться за советом к одному хорошему человеку, который составил для меня вот такой план. С разрешения этого человека размещаю данный план на Хабре – вдруг он пригодится и кому-то ещё. (Тем более, что перечисленные книги относятся к «золотому фонду» литературы в данной сфере и проверены временем.)
UPD: Новичкам советую обратить внимание на комментарии — там активно и аргументированно корректируется этот план.
Этап I. Основы
Нортон «Программно-аппаратная организация IBM PC»
Эта книга, несмотря на свою давность, относятся к тем, что пока отнюдь не устарели. Как новичок подтверждаю – повествование вполне понятно и для почти полного чайника в IT.
Гук «Аппаратные средства IBM PC»
А эту книгу стоит прочитать «поверх» – она расскажет о том, как дела в данной сфере обстоят сейчас.
Этап II. Hardware
Шаг 1
Морс, Алберт «Архитектура микропроцессора 80286»
Почему тут берётся за основу именно микропроцессор 80286 – станет понятно по изучении трудов первого этапа.
Шаг 2
Гук «Аппаратные интерфейсы ПК»
Гук «Интерфейсы устройств хранения»
Этап III. Операционные системы
Шаг 1
Таненбаум «Архитектура компьютера»
Шаг 2
Колисниченко, Аллен «Linux: полное руководство»
От общей теории переходим к изучению конкретной операционной системы – на примере Linux.
Немет, Снайдер, Хейн «Руководство администратора Linux»
Этап IV. Собственно программирование
Шаг 1
Керниган, Ричи «Язык программирования С»
Почему первым для освоения выбран именно язык Си? Как мне рассказали знающие товарищи, он поможет достичь правильного «программистского мышления», чего было бы сложно достичь, начиная изучение, скажем, с Паскаля. Кроме того, язык Си по-прежнему используется в наши дни и подходит как для прикладного, так и для системного программирования.
Шаг 2
Кнут «Искусство программирования»:
Том 1. Основные алгоритмы
Том 2. Получисленные алгоритмы
Том 3. Сортировка и поиск
Бентли «Жемчужины программирования»
Зачем осваивать эти труды? Как уже отмечали на Хабре – «наверное, нигде больше, чем в айти, не изобретается такое огромное количество велосипедов». Данные книги помогут этого избежать – и попутно будут прививать умение писать не просто код, а хороший код.
Ну а для затравки можно прочесть небольшой цикл лекций «Культура программирования» (автор – А. Бабий). Он помогает начинающим программистам понять, что их деятельность не будет проходить в вакууме, а неизбежно включит взаимодействие с другими программистами, с заказчиками и пользователями (а также включит необходимость копаться потом в своих собственных или в чужих программах).
Закономерный вопрос новичка: сколько времени займёт изучение всего этого? По прогнозам моего советчика, у человека, который может тратить на изучение программирования только вечера и выходные, на прочтение и осмысление литературы первых трёх этапов уйдёт полгода-год. На четвёртый этап тоже даётся год – чтение должно сопровождаться практикой по самостоятельному составлению программ. Как получится на самом деле – время покажет.
Буду крайне благодарна за ваши советы и уточнения.