Middle разработчики по цене Junior-а или «хочу практики»
Всем привет. Я очень хочу в IT, мне ’оно’ нравится, да и способности присутствуют. Я считаю что уже готов для работы, но есть проблема. Побывав на испытательном сроке в одной компании я понял, что они не особо хотят обучать начинающих. Хотят уже обученных, с опытом.
Остается 2 выхода, либо идти на курсы (академии) (Luxoft, SoftServe) или получать практику другим спсобом. Певый вариант не очень интрисует, так как это долгий и не очень продуктивный путь.
Поэтому ищу ментора / единомышленника / компанию(в которой готов работать бесплатно). В день могу тратить от 4 до 8 часов. Готов работать над проектами, связанными с web приложениями.
34 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівчто-то заголовок никак к сути топика не клеется
Рад, что автор нашел работу/проект быстро, но хочу таки поделиться своим опытом, может кому-то поможет.
Начнут с того, что согласен с большинством комментаторов и несогласен с автором. Кто хочет научиться, тому надо идти туда, где берут и делать то, что есть. Даже с минимально й ЗП. Альтернатива — придумать себе какую-то среднею сложности задачку и реализовать её в коде. Постепенно усложняя свой pet-project, рано или поздно придется читать книги по архитектуре ... и вырастешь до толкового мидла. Например, у меня есть свой игровой сайт. Денег приносит копейки, но с его помощью я научился программировать (vfm-elita.com). А в процессе работы над ним, приходилось решать МНОЖЕСТВО проблем (из разряда пол-дня гуглишь, пол дня кодишь.. потом опять гуглишь). Вот пример тому мой вопрос (один и большого множества) на форуме программистов: forum.sources.ru/...howtopic=223139
Надеюсь кому-то поможет.
Проект нашел, всем спасибо.
+1
Поставьте себя на место такой компании. Зачем им подобный человек? Понятно, что бесплатно Вы будете работать только до определенного времени, а потом либо потребуете оплату за работу, либо найдете другое место работы. Итого, компания будет иметь профит только на время Вашего обучения, и то профит сомнительный, т.к. Вы будете занимать время людей, которые уже работают в компании. И очень вероятно, что для компании такой процесс будет убыточный.
Как я вижу выход из ситуации (по своему опыту): первоначально необходимо устраиваться в компании, которым не требуются высококлассные спецы для рабочего процесса, но где будет возможность учиться. Например, это разного рода государственные конторы и учреждения, возможно некоторые банки (суппорт). Работая там, у Вас будет возможность учиться. Рассматривайте работу в таких компаниях как инвестицию в свое образование, т.к. оплата будет минимальной.
госконторы и банки не дадут ничего. это совсем другая область ИТ, после вылета из которой за душой не остаётся ничего нужного.
Единственный плюс — можно поднатаскаться в теории достаточно, чтобы пройти тестирование на ждуна куда-нить в не слишком требовательную контору.
Реального опыта же будет 0.
Еще один плюс: есть возможность спрыгнуть с разработки в сферу аналитики. Часто в таких компаниях процессы разработки идут на тяп-ляп, как исторически сложилось. И если подберется коллектив инициативных студентов, то есть все шансы внести свежую струю и смело писать строчку в резюме по поводу построения «правильных» процессов разработки ПО в организации (системы контроля версий, WorkFlow и т.д.). Все зависит от инициативности, самоорганизованности и желания приобретать нужные практические навыки.
Конечно, можно просто работать «от забора до обеда», не вникая ни во что дальше своего фронта работ. В этом случае, действительно, реального опыта будет 0, и думаю, лучше уже на этом этапе выбрать другую профессию.
Вот приват, вроде, более-менее серьёзно разрабатывает. Но на разработку берут не стажёров.
CVS, CI, тестирование, языки, планирование, — этого не будет. Будет доза екстремального программирования в широком смысле єтого слова, свободное время, возможно возможность поднять и полуподпольно поддерживать интранет ресурс и набор скриптов автоматизации.
Вы не правы, если считаете, что вариант, когда Вас будут по шесть часов в день на протяжении полу года учить есть «долгим и не очень продуктивным».
E синьйора, к которому вас прикрепляют вполне хватает своего напряга и поэтому он не будет с вами нянчиться целый день, но на сложные вопросы ответит.
Суть обучения: научиться работать самостоятельно, это вам скажет любой лид. Есть задача и требования — пошел гуглить, читать stack-overflow, разные хаки и прочее, я когда учился в 2011 году кодил 1 час в день, а 8 часов гуглил/читал/применял разные хаки. Тратил все свои выходные, было адски тяжело, но я справился и в свои те 35 лет стал junior-ом с з.п. 350$, потом повышали, да и технологии давались легче.
Feel the difference!
А вы хотите сразу стать миддлом после пары книжечек?
Я не могу полностью описать ситуацию, но поверьте я не ною, и с заданием я справлялся. Проблемы были в тонкостях, название переменных / не полная обработка ошибок / применение патернов. А кодить 1 час и 8 гуглить, как по мне непозволительная роскошь.
Я собственно об этом и говорю. Мне практика нужна.
Спасибо, но я думаю это все же от ситуации очень зависит.
я не помню где видел, но если считать количество строчек, выданых «на-гора» в день толковым спецом, то там получаются смешные цифры. Иные начинающие от пхп (делфи, питон, сишарп етц) делают этих спецов в разы, а поди ж ты — спецы остаются спецами, а начинающие всё ещё продолжают начинать)
Есть только одна ситуация когда кодить важнее — срочный фикс деплоя/билдов, при условии, что вы в курсе что и как делается в принципе и придерживаетесь проектных стандартов.
Во всех остальных случаях гораздо полезнее подумать полдня, нарисовать схемы, прикинуть кусочки кода, затем обсудить с девелоперами и тестерами (они добреют и заводят меньше багов) и за оставшиеся1-1,5 дня сделать.
В противном случае если тупо кодить, то будут проблемы с интеграцией в команде, т.к. чуваки будут просто не в курсе где и что вы пишете = гарантированные проблемы с merge-ом в начале (превед svn) или в конце когда подливаешь свою ветку (git), а тестеры потом тупо взбесятся, что не понимают как это работает — и отомстят — заведут баги, «тут точки нет в тексте», «подвинь кнопку на 2px» и т.д.
Выводы делайте сами.
Ну вы закрутили. Да вообще суть топика в другом.
Думать некогда, кодить надо )))1-1,5 дня, значит вы почти две недели ни хрена не делали, производительность низкая. Если бы вы начали писать с ошибками и увидели ошибки, переписали, то получилось бы не, допустим 1-1,5 дня, а 2-2,5. Что все равно быстрее двух недель. И даже если вы сверхумно всё продумаете, не верю, что то, что за 1.5 дня написано, не будет переписываться ни разу.
Вы рассуждаете как мидл, который только паттерны изучил. И сидит, ломает голову, как всё продумать, чтобы всё сразу заработало. Но если вы пару недель думаете, а на кодинг ушло
код == работа. Всё остальное от лукавого. Хотите думать, думайте в процессе. Код — это черновик ваших мыслей.
По поводу:
Названия переменных принимаете как принято в проекте. Плохо или хорошо не важно, хуже, когда по разному. Это спрашивать не надо у синьйоров, по коду видно. Ошибки не обрабатываем, пусть падает. Серьезный недостаток новичков в том, что они считают, что ошибки надо всегда и везде обрабатывать. (Я про язык с эксепшинами). Паттерны читать, критически осмысливать, применять только в крайней необходимости, когда код упрощается с ними, а не усложняется (такое бывает, когда хотят на будущее сделать так, чтобы потом что-то проще менять, а на самом деле код «на сейчас» усложняется). Меняем работу. Что за неуставные отношения )) Как это, в колективе мстители? Не на базаре ж.То же касается и этого.
Не хочу оскорблять, но то мнение мидлов, и у меня было такое мнение когда-то. То мнение людей, живущих водопадом и не умеющих еще управлять хаосом )))
«Думать» никто у вас не отбирает.
Три стадии «достижения просветления»:
1) не могу копать
2) могу копать!
3) могу не копать
Где-то соотносится с программированием.
1) Пишу быстро, куйня получается
2) Начал учиться думать перед написанием, стал код чище
3) Пишу быстро, получается сравнительно качественно и быстро.
Т.е. есть техники, как писать, как переписывать, как в конце концов моделировать предметную область. Вы же всегда даже в уме это делаете по частям, а не всё сразу. Когда научитесь сразу по частям и записывать — вы получаете сразу в процессе мышления продукт. Позже, когда научитесь, будете думать, как вы без этого раньше обходились? Продумывая и не записывая ничего, это где-то аналогично, что играть в шахматы без доски. Мазохизм. Хотя в шахматах он имеет смысл, не очень удачная аналогия, то в программировании совсем почти не имеет смысл всё держать в уме.
Это так же может зависеть от сферы разработки. Я чаще в энтерпрайз работал. Не над чем особо думать. А требования меняются чаще, чем пятницы.
Но работал и в проектах, требующих производительность, алгоритмы и всё такое. То же самое. Конечно, если не знакомы с подходами к задаче, нужно почитать. Но думать тоже особо не над чем: нужен код, нужны замеры и реальные цифры, а не решать в воображении, что производительно, а что нет.
Где-то так
Моя ценность — решать проблемы, за которые мне платят деньги. Можно их решать костылями абы-как, как делают индусы и люди, «управляющие хаосом», который сами себе и создают, а можно самому себе сделать легче, если немного подумать.
Такое ощущение, что вы не программист, а неудавшийся журналист судя по ответам.
А я не предлагаю писать костыли. Это долгая тема, как надо разрабатывать эволюционно, по ТДД и тому подобное.
По сути, это не про костыли. А про «думать», но в процессе и с хорошей самодисциплиной в этом думании. Т.е. с определенным подходом, в какой последовательности думать и обязательно в этом процессе всё записывается в код. Т.е. представьте, что вы думаете с листочком бумаги, рисуя там чертежи. Это то же самое. Плюс подхода в том, что по окончанию процесса именно думания вы уже получаете готовый продукт.
Извините, если я как-то так ответил с оскорблением. Это так привык )) (Луговский стайл)
Как раз, по-моему, программисты на втором этапе своего развития пытаются все время думать, перед тем как писать. Дело не в том, что они думают, а в том, что они продумывают слишком много, ничего не записывая. В итоге получается водопад. Когда человек планирует всё наперед и живет по плану. В эволюционном же проектировании программист тоже думает, но думает по частям, обладая самодисциплиной и не забегая наперед, не планируя далеко свои действия. Тогда, он пишет вполне достойный и хороший код. Не идеальный, но качество достаточно высокое, а производительность как программиста очень высокая.
Советую для вхождения в тему книгу
Кент Бек «Экстремальное программирование: разработка через тестирование»
То, что я пишу: практика, давно и хорошо себя зарекомендовавшая. Это гораздо глубже, чем можно себе не ознакомившись с темой представить.
Миддлы не так уж и плохи, как по мне лучше занимать адекватную должность, чем делать хорошую мину при плохой игре.
Был у нас в команде один украинский senior с высоким самомнением и снисходительным отношением к миддлам, так он умудрялся растягивать2-х дневный таск на 3-4 недели, мотивируя это большой занятостью и делая «морду кирпичом», хорошо что свалил в другую команду уже, но его код пришлось переделывать мне и ушло на это чистых 2 недели, ах да, он был не покрыт тестами, была куцая проверка входных параметров = вылеты на некоторых исходных данных, сам код — гов*нокод уровня чуть лучше индуса.
как раз в тему.Еще наш senior любил порассуждать о высоких материях на любую тему от японской живописи до Unix-а, не разбираясь ни в одной теме. Кого-то мне напоминает :-)
так, называть себя синьйорами кто угодно может. По-моему синьер должен обладать отменными знаниями в своей области, не писать или хотя бы уметь не писать говнокод и очень стараться этого не делать. И опыта минимум 8 лет. Так как в других странах. Это у нас могут себя назвать через год опыта синьйорами. А через два уже архитекторы и тимлиды.
Бывает. И чаще, чем не бывает ))
Для детей природы спец. пояснение:
а не то что вы пишете.
придумать 0,5 дня в 2 недели — лихо вы так? судите по себе?
Думать даже полдня не записывая — не полезно. У вас нет быстрой обратной связи от кода, вы не пользуетесь средствами программиста, языком программирования. Язык и должен быть инструментом вашего мышления, а код показателем, насколько правильно и естественно вы думаете на этом языке. Если же вы продумываете и не пишете, то это всё равно, что у вас язык программирования не родной, а вы не программист, а, допустим, сантехник. Вам надо нарисовать на языке труб, унитазов и раковин, что вы хотите сделать, а потом заняться переводом на язык, который понимают программисты.
Рисуя UML-диаграммы, например, может казаться, что они красивы и вы нашли красивое решение. Но когда оно ляжет на код, сразу становится видно, что он нечитаем, неочевидный, кривой и тому подобное. Поэтому лучше использовать не схемы, не воображение, а язык программирования. Придумали часть, записали, посмотрели. Не нравится — переписали. Именно «переписали», т.е. «рефакторинг» и дает то, что код остается приемлемым и без костылей.
Есть и место в графике, когда действительно необходимо не писать код, а «осмотреться». Это когда вы читаете документацию или изучаете стандартные подходы для решения таких задач, чтобы не создавать велосипеды с нуля.
А если копаете «от забора до обеда» — то придется и дальше придерживаться именно такого подход а к рабочему процессу. Думаю, это не является Вашей целью.
Ну «побывал» же на ис в одной компании. Все, мидл.
А я легітимний президент.
Я думал, по возрасту.