Попал на стажировку к говно-кодерам. Нужен совет

Здравствуйте!

Ситуация следующая:
Прошел курсы по верстке и основам JS и по знакомству попал на бесплатную стажировку в небольшую конторку занимающуюся разработкой сайтов и web-приложений. Я надеялся подтянуть свои знания и набраться опыта, но сейчас понимаю, что скорее всего моим надеждам сбыться не суждено. Мои новые коллеги выдают такие перлы, что Петросян и рядом не лежал.

Вот некоторые из них:
1. Мы не используем Git — это (внезапно!) не удобно.
2. Sass — это постпроцессор и вообще говно.
3. Зачем писать аккуратный и код? Все равно эти сайты кроме нас никто поддерживать не будет!
4. В именах классов мы используем транслитерацию так-как не все знают английский.

В общем ребята вообще печальные. Никто ничего не знает, дальше простого html / css никто не учил. Руками здесь сложнее простых квадратных кнопок никто ничего не делает. При любом удобном случае ищут куски готового кода. Все сайты делают на Wordpress. В CSS через каждую строчку используют !important и стилизацией через атрибут style тоже не брезгуют. Псевдоэлементы? — нет, не слышали. В понятии местного дизайнера модульная сетка — эта та что появляется если в Photoshop нажать CTRL + ’. Пытался что-то изменить, но мои советы никто не слушает.

Да, тяжело поверить, но это правда. И я теперь не знаю что делать. И уходить некуда, и оставаться не хочется.

Что посоветуете?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Лучшие комментарии пропустить

Хороших кодеров нет. Но вы держись там, здоровья вам и хорошего настроения.

Дык ведь это и есть опыт коммерческой разработки!

Один раз меня наняли дописывать проект с индусами, и я думал что все очень плохо. Но пару месяцев спустя меня наняли другие индусы фиксить их проект — все было в разы хуже (понял, что первые были не так уж и плохи). Казалось, что это дно, но нет — пару недель назад увидел проект, который был настолько ужасен, что я отказался от него через два дня (а вообще убедил заказчика его переписать и на днях буду релизить). К чему я это... жизненно короче, и не факт что в другом месте не будет хуже.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Думаю, что это норма для небольших конторок и микрокомандочек самоучек, колбасящих сайты.
Как ведь получается следование хорошим практикам?
Это или комьюнити, или строгое следование корпоративным или проектным стандартам, или же собственный горький опыт, вынудивший искать нечто другое, чем решения в лоб...

Всему этому реально негде взяться в таких конторках, ведь люди с индустриальным опытом туда попадают редко.

Да, тяжело поверить, но это правда. И я теперь не знаю что делать. И уходить некуда, и оставаться не хочется.

Ничего тяжелого :-) Не везде сплошной Эпам.
Пока набивать руку и тянуть на себя одеяло. Если не получится, валить. Если получится, тоже валить («если ты в комнате лучший, значит, ты не в той комнате»). Хорошо, что есть осознание того, что они делают неправильно...

Способен ли быдлокодер осознать свою сущность или это незлечимо?

В проектную команду около месяца назад начальство взяло человека который взялся писать бекенд используя самопальный набор костылей и велосипедов aka собственную cms, естественно на php. Человек понятия не имеет даже о подходе работы с гитом, поскольку весь свой г****код складывает прямо в ветку мастер. и не может даже настроить апач с mysql пользуясь исключительно openserver. при этом считает себя какадемоном 80-ого уровня в программировании и всех остальных неучами.
лечится ли данный тип заболевания или после определенного числа нулей в зарплате это навсегда прожигается в мозгу?

А що таке трапилось і навіщо потрібне стало стажування? Якщо в 2008 вже 2 роки досвіду було. Загубився досвід? Чи то інший анонімус?

dou.ua/...rticles/code-documenting
25 квітня 2008
«Года 2 назад на одном проекте мы искали виноватого,»

Что посоветуете?
тут вже нічого не врятує здається. Ї це я не про компанію.
Чи то інший анонімус?
Это другой, скорее всего — все удаленные юзеры становятся вот таким анонимусом.

Ага, похоже тимлид дал ответ за него. :)

Якщо ти розумієш всі ці речі, то для чого пост створювати? Відповідь очевидна навіть тобі

1. Мы не используем Git — это (внезапно!) не удобно.
Отчасти правда.. скажем, gui клиентов хороших так и нет.
2. Sass — это постпроцессор и вообще говно.
Ну, промахнулись с постпроцессором, но «говно» — это субъективное мнение... человека нельзя судить по тому, что он что-то считает говном.
3. Зачем писать аккуратный и код?
Так вы пишете только аккуратный или только код ?
4. В именах классов мы используем транслитерацию так-как не все знают английский.
У нас принято считать транслитерацию плохой, просто потому что так принято. Но ведь объективно нет ничего в ней плохого. Вот смотрю сейчас в класс SharePluginReceptacle и пытаюсь понять, что это, и чем мне помогает то, что он на языке Байрона и Шекспира ? А если люди на самом деле не знают английского ? вы же пишете слово «так-как» неграмотно, но никто не встает в театральные позы.
Отчасти правда.. скажем, gui клиентов хороших так и нет.
sourcetree

Минуточку, так это шо — в люксофте такое твориться?

Знаю множество примеров, когда ПО разрабатывается БЕЗ системы контроля версий. Если клиент доволен — то почему бы и нет? Я не говорю, что это правильно. Неправильно, и в принципе очень неудобно. Но Клиенту-то что с этого?
если гит не осилилили, то почему бы не юзать старый добрый SVN ? куча удобств же.

читал похожий топик месяц назад, только был заголовок «быдлокодеры»))

4. В именах классов мы используем транслитерацию так-как не все знают английский.
Занавес

Они правы.

1. Мы не используем Git — это (внезапно!) не удобно.
2. Sass — это постпроцессор и вообще говно.
3. Зачем писать аккуратный и код? Все равно эти сайты кроме нас никто поддерживать не будет!
4. В именах классов мы используем транслитерацию так-как не все знают английский.

В большинстве случаев очень много сайтов поддерживает веб-студия, потому что они даже не посещаемые. Это сделать, деньги получить, залить на шаред. Все. И смотреть чтобы шаред не уплыл.

Если не подписан контракт тогда нужно уходить. И даже не сомневайся. Если ты в себе уверен — работу найти не проблема.

Это в тему про бесплатные стажировки.

Хотите на стажировку к нам? )

Работайте, пытайтесь потихоньку что-то улучшить (а вдруг!), и ходите на собеседования, чем больше, чем лучше )))

пользуясь случаем, хочу напомнить о прекрасной заметке Джоэла: www.joelonsoftware.com/...ticles/fog0000000043.html
Joel Test — это действительно прикольная штука. И надо стараться максимизировать этот показатель. У моей конторы там бал низкий, но для ориентира всё равно имеет смысл использовать.

Это проверка такая ))

Это проверка такая :)

Поддерживаю многих здесь ребят! УХОДИ! Это-ж не «старый чемодан»... не подходит — можешь сменить!
А вообще — лучше всего реши четко, что уходишь, если деньги есть на что жить вообще. Потом — иди к руководству и по хорошему попытайся поговорить, что мол тебя такая ситуация не устраивает... и расскажи свои ожидания!
1. Если скажут: «Иди на***!». Не останавливайся, разворачивайся с радостным лицом, и ищи следующую контору.
2. Ну а может и не скажут. Может предложат что-то веселее (что мало-вероятно). =)

Не думаю что есть такие компании которые скажут

«Иди на***!».
А если так и скажут тогда можно и имя компании сказать)

Совет один — вали из конторки. Работы много, рано или поздно что то найдешь, где лучше культура разработки. Пересиливать себя нет никакого смысла, кроме денег — если хорошо платят, то можно потерпеть. Но и это недолго.

совета тут только два. 1) либо приспосабливаться к говнокодерам, 2) либо попробовать найти что-то другое. имхо, лучше второе, но реально говнокодеров хватает в очень многих конторах, минимум 80%, это должно очень сильно повезти — попасть в оставшиеся 20%... :)

Здравствуйте!

Прошел курсы по верстке и основам JS и по знакомству попал на бесплатную стажировку в небольшую конторку занимающуюся разработкой сайтов и web-приложений
Вы прошли курсы, и имеете теоретические знания. Сотрудники конторы имеют практические знания и определенное количество существующих/новых клиентов, которых все устраивает.
Главная задача ИТ-компании — это получать прибыль от продажи ПО. Качественный код, до определенной степени, это делать помогает. Но только до определенной степени.

Попробуйте взглянуть на вещи с позиции клиента — заказчика ПО.

Мы не используем Git — это (внезапно!) не удобно.
Знаю множество примеров, когда ПО разрабатывается БЕЗ системы контроля версий. Если клиент доволен — то почему бы и нет? Я не говорю, что это правильно. Неправильно, и в принципе очень неудобно. Но Клиенту-то что с этого?
Зачем писать аккуратный и код? Все равно эти сайты кроме нас никто поддерживать не будет!
Клиент: — мне нужно склепать сайт за 5-10-20 дней, очень срочно! Какие Ваши оценки?
Контора: — если делать быстро, то 5 дней, если аккуратно, то 20.
Клиент: — делайте быстро, но с приемлемым качеством.
Контора: — ок.
4. В именах классов мы используем транслитерацию так-как не все знают английский.
В чужой монастырь со своим уставом не ходят. В каждой компании есть свои правила оформления кода. В этой компании — именно такие. Хотите изменить — обоснуйте, что Ваш подход будет более удобным, и принесет какие-то преимущества. Не можете обосновать — значит, Ваш подход не лучше существующего, по крайней мере значительно не лучше.
Руками здесь сложнее простых квадратных кнопок никто ничего не делает. При любом удобном случае ищут куски готового кода.
Копипаст, конечно, зло, но как говорят классики, «все уже разработано до нас». К сожалению, изобретение велосипедов вместо готового и давно обкатанного функционала — одна из основных проблем новичков в сфере ИТ. Впечатление, что ты можешь сделать лучше, больше, изящнее — чаще всего обманчиво.
И я теперь не знаю что делать. И уходить некуда, и оставаться не хочется.
Что делать — учиться. Welcome to the Real World, как говорится. По моему скромному ИМХО, профессионала от новичка отличает умение работать и подстраиваться под любую ситуацию, и учиться, учиться, учиться... Это не значит, что нужно писать говнокод, но как мне кажется, сугубо из написанного Вами, на Вашем уровне очень сложно отличить мух от котлет, т.к. практики у Вас маловато. На Вашем месте, я бы попытался понять логику и преимущества используемых подходов. Не бойтесь спрашивать у старших товарищей. Для этого очень помогает установка, что каждый разработчик старается писать код наилучшим образом, исходя из существующих реалий, окружения и знаний. Взгляд через призму этой установки на процессы компании может многое прояснить.

«Знаю множество примеров, когда ПО разрабатывается БЕЗ системы контроля версий. Если клиент доволен — то почему бы и нет?»

А если клиент попросит вас писать в древней IDE работая через FTP с чужим взломанным сайтом? Или даже не попросит, а будет доволен результатом, который внешне работает, но уязвим по нескольким пунктам безопасности, да ещё и трудно вносить изменения.
С таким подходом вы поступите непрофессионально. Нельзя позволять клиенту влиять на ваш профессионнализм. Нельзя приносить в жертву профессионализм в угоду клиента. Если вы считаете иначе, то у меня для вас плохие новости.

А если клиент попросит вас писать в древней IDE работая через FTP с чужим взломанным сайтом?
... то я попытаюсь обосновать Клиенту ошибочность этого подхода, а также и то, что Клиент не должен углубляться в технические тонкости реализации. Если же Клиент настаивает, то до него будут донесены проблемы с уязвимостью, подробно разжеваны возможные последствия, а также предложена альтернатива выбранному подходу (почему-то этот момент очень часто упускают, только критикуя подход Клиента). Если Клиент упорствует, то далее все зависит от политики компании: либо заключается договор с оговорками и подробным описанием «мы же вас предупреждали» и функционал реализовывается, либо компания отказывается от дальнейшего сотрудничества с Клиентом. Исходя из моей практики, Клиент обычно внемлет разумным доводам и соглашается на компромиссы.

Компании для разработки ПО существуют для того, чтобы получать прибыль от этого процесса. Качество ПО влияет на размер прибыли весьма опосредованно. Довольно часто приходится крутиться в треугольнике Сроки-Цена-Качество, и не всегда Качество занимает 1 место. Селяви.

Вы прошли курсы, и имеете теоретические знания. Сотрудники конторы имеют практические знания и определенное количество существующих/новых клиентов, которых все устраивает.Главная задача ИТ-компании — это получать прибыль от продажи ПО. Качественный код, до определенной степени, это делать помогает. Но только до определенной степени.
Попробуйте взглянуть на вещи с позиции клиента — заказчика ПО.
Как бы вам сказать... Тут ситуация, когда человеку привили хорошие практики, а он «пришел на завод», где тонкую электронику чинят кувалдой да паяльником, которым разве что вёдра лудить.
Знаю множество примеров, когда ПО разрабатывается БЕЗ системы контроля версий. Если клиент доволен — то почему бы и нет? Я не говорю, что это правильно. Неправильно, и в принципе очень неудобно. Но Клиенту-то что с этого?
Я за последние пол года видел троих таких клиентов. Все трое после разбора полетов рвали волосы сначала себе, потом исполнителю.
Клиент: — мне нужно склепать сайт за 5-10-20 дней, очень срочно! Какие Ваши оценки?
Контора: — если делать быстро, то 5 дней, если аккуратно, то 20.
Клиент: — делайте быстро, но с приемлемым качеством.
Контора: — ок.
Предложу сделать заглушку за 5, а потом месяц доводить до ума.
Если заказчик не согласен — это не наш заказчик.
И да, я объяснял начальству, что я тупо не буду делать «абы шо за 5 дней» — потом это аукнется и мне и конторе, не раз.
Копипаст, конечно, зло, но как говорят классики, «все уже разработано до нас». К сожалению, изобретение велосипедов вместо готового и давно обкатанного функционала — одна из основных проблем новичков в сфере ИТ. Впечатление, что ты можешь сделать лучше, больше, изящнее — чаще всего обманчиво.
Копипаст — зло, а вот найти готовый кусок кода, понять как он работает и на его основании сделать своё — это правильно. При условии что это что-то небольшое, если это что-то большое — лучше поискать либу.
Что делать — учиться. Welcome to the Real World, как говорится. По моему скромному ИМХО, профессионала от новичка отличает умение работать и подстраиваться под любую ситуацию, и учиться, учиться, учиться...
Добро пожаловать. В реальный мир.
Человек угробит существующие навыки и знания.
Поймите, есть разница между подстраиваться при необходимости и постоянно работать против своих принципов. Вот завтра вам придут и скажут «MySQL это стильно, модно, молодёжно! Теперь ты работаешь с ним!», что вы сделаете?
Это не значит, что нужно писать говнокод, но как мне кажется, сугубо из написанного Вами, на Вашем уровне очень сложно отличить мух от котлет, т.к. практики у Вас маловато. На Вашем месте, я бы попытался понять логику и преимущества используемых подходов. Не бойтесь спрашивать у старших товарищей. Для этого очень помогает установка, что каждый разработчик старается писать код наилучшим образом, исходя из существующих реалий, окружения и знаний. Взгляд через призму этой установки на процессы компании может многое прояснить.
Если некогда и некуда посмотреть — рано или поздно человек начнет писать «на отцепись» и это будет черти-что. Чтобы писать качественный код и рости нужна обстановка, которая к этому располагает.
Я знаю несколько компаний.
Одна занимается разработкой сайтов, у них постоянно вал работы, нет денег и нет притока свежих кадров. За то время что мы с ними работаем, нам удалось их заставить использовать git и переехать на bitbucket, заставить использовать composer и описывать требования к окружению, еще что-то они изучают сами. Это была масса работы, но это получилось сделать. Есть одно «но»: уровень программистов там не изменился. Как писали говно, так и пишут.
Есть другая контора. Тут пришлось ребятам объяснять что с базой нужно работать иначе. Помогло не сильно, но помогло. Новых кадров тоже нет, но те программисты что были — растут понемногу.
Есть третья контора. Текучка у них неслабая, но с приходом новых людей состояние проектов визуально улучшается. Плюс они всё же слушают наши рекомендации и делают соответствующие оптимизации. Есть у них пара закидонов в плане работы основной их системы, но это уже идет от начальства.
Есть четвертая контора. Легаси, их сайты уже могут ходить в пятый класс. За полтора года сотрудничества уволился один человек, пришло трое. Они потихоньку заканчивают переписывать свои сервисы с использованием открытого фреймворка. Переходят на utf8. Работы много, но в процессе переносов-переписываний и рефакторинга они устраивают обсуждения спорных моментов и в итоге получают стабильные и довольно шустрые системы. Тут и программисты растут и начальство, в целом, довольно продуктами.

Контора топикстартера аналогична первой. Максимум на что он может там рассчитывать — чуть набъет руку и не растеряет знания.
Если есть возможность — я бы валил оттуда.

Тут ситуация, когда человеку привили хорошие практики, а он «пришел на завод»

Как я вижу, ситуация у ТС слегка другая: человеку на курсах объяснили, как необходимо работать в идеальных, тепличных условиях. Правильно, академически, с учетом Best Practices от гуру отрасли. И он попадает в реальную компанию, которая не запускает космические корабли, а клепает сайты. И для качественного выполнения их работы вполне хватает кувалды и паяльника. И вместо того, чтобы перенять те хорошие практики, которые есть в компании, ТС с усердием, достойным лучшего применения, пытается менять устоявшиеся процессы. Это похвально, это в большинстве случаев необходимо, но у меня сложилось мнение, что ТС, не понимая специфики работы конкретно этой компании, начал думать и действовать в ключе «все это говнокод и нужно работать правильно, переписать с нуля и т.д.». Такой подход, скорее всего, не увенчается успехом, т.к. недостаточно обоснован с точки зрения бизнеса.

Предложу сделать заглушку за 5, а потом месяц доводить до ума.Если заказчик не согласен — это не наш заказчик.
Ну, если при этом Вы согласитесь, что Клиент платит за 5 дней + срочность работы, а не за 30 дней, то думаю, все будет ОК. Иначе ОЧЕНЬ СЛОЖНО будет объяснить Клиенту, за что он должен платить остальные 25 дней. И более того, я уверен, что после такого Вашего требования это уже будет не Ваш Клиент, тут Вы абсолютно правы...
а вот найти готовый кусок кода, понять как он работает и на его основании сделать своё — это правильно.
Согласен с Вами в том, что полезно понимать внутренности работы готовых кусков кода. Не согласен только с тезисом, что на основании их делать свое — это правильно. Вернее, даже не так: после глубокого анализа кода и бизнес-требований обычно отпадает необходимость делать что-то свое. Не всегда, но очень часто...
Человек угробит существующие навыки и знания.
Так нет еще никаких навыков и знаний. Выданные обрывки информации с курсов за таковые не рассматриваем ввиду их частой неприменимости в реальных проектах.
есть разница между подстраиваться при необходимости и постоянно работать против своих принципов. Вот завтра вам придут и скажут «MySQL это стильно, модно, молодёжно! Теперь ты работаешь с ним!», что вы сделаете?
А Вы что сделаете? Тут ответ очевиден. Причем очевидна также адекватность лиц в компании, которые уполномочены принимать такие решения.
Если есть возможность — я бы валил оттуда.
Я бы вначале получил максимально возможный опыт, а потом бы прислушался к Вашему совету. Жизнь коротка, а работа должна приносить удовольствие. Благо, выбор большой...
Правильно, академически, с учетом Best Practices от гуру отрасли. И он попадает в реальную компанию, которая не запускает космические корабли, а клепает сайты. И для качественного выполнения их работы вполне хватает кувалды и паяльника. И вместо того, чтобы перенять те хорошие практики, которые есть в компании, ТС с усердием, достойным лучшего применения, пытается менять устоявшиеся процессы.
я даже не знаю о каких хороших практиках может идти речь, если git — это не удобно, sass — пост-процессор... у них можно, наверное, только научиться крыть матом друг друга за то что, кто-то затер изменения, или похерил кусок кода на продакшене и сайтег клиента внезапно лег... В общем, можно, конечно, использовать и кувалду с паяльником, но это ж не значит что не надо стремиться использовать нормальные инструменты... Да и судя по всему с начальством и всякими тимлидами у них беда — если всех устраивает каменный век и все у них ненужное говно, кроме копипаста и !important
Я за последние пол года видел троих таких клиентов. Все трое после разбора полетов рвали волосы сначала себе, потом исполнителю.

Нельзя ли рассказать поподробнее об этих клиентах и о «полётах» (настолько, насколько это возможно, конечно). Правильно ли я понял ситуацию, что на проекте, который был получен от этих клиентов, не использовалась система контроля версии, и что на предложение использовать, клиент ответил отказом? Потом, когда клиент попросил вернуть что-то из предыдущей версии проекта, сделать это оказалось достаточно затруднительным?

на одной из моих первых работ, когда я был еще джуниор-РНР, ребята использовали в качестве IDE, внезапно, FAR — с сотней навешанных плагинов! Это было лет 5-6 назад. К счастью, мне не запрещали поставить Netbeans, насколько я помню.

судя по тому что ты написал ты умнее их но не в этом суть. Какой смысл тогда ходить туда и бесплатно стажироваться если ты считаешь что тупо протираешь штаны! Терять время зря очень плохая практика.

Пытался что-то изменить, но мои советы никто не слушает.
Ахахахахахахахаха!
ну насмешил.

Если стоит задача получить опыт, то советую альтернативу «попилить свой pet-project».

Не обязательно создавать что-то инновационное, главное попытаться решить небольшую, но реальную проблему, причем важно реализовать это решение «от и до» — отобрать требования (прикинуть, что стоит делать в первую о чередь, а что отложить на потом), спроектировать (только здесь важно не заниматься преждевременным обобщением и пытаться предусмотреть всё, а просто иметь примерный план что, после чего и примерно как будет сделано), реализовать и запустить — выкатить на хостинг, понаблюдать, поподдерживать, чтобы оно проработало хотя-бы пару месяцев.

Здесь есть риск в том, что тут понадобится определенные навыки самоорганизации (на стажировке кто-то будет принуждать, поэтому даже через «не хочу», но что-то делается), когда сам себе определяешь сроки и в любой момент можешь отложить, то реализация может растянутся. По моим наблюдениями (знакомые «начинающие» и кандидаты, которых собеседовал на позицию «trainee»), даже если кто-то и начинает, то не доходит этот путь до конца. Поэтому важно отнестись к этому с полной серьезностю. Можно ограничить себя по времени (в идеале — это иметь четкие дедлайны, например: к первому августа хоть какая-то версия сайта должна уже крутится на хостинге, пускай глючная, зато доступная из «внешнего» мира).

Но если таки получится осилить такой путь до конца, то черзе месяц-два получится очень, очень жирный плюс в резюме junior-а. Что буде выгодно выделять на фоне конкурентов, у большинства из которых нет ни примеров собсвтенного кода, ни, тем-более, каких-то законченных «поделок».

У реальной стажировки есть еще один плюс — всегда можно спросить совета у более опытного товарища. Но при работе над собсвенным проектом можно спрашивать совета на форумах, а в идеале — найти ментора, более опытного разработчика и периодически (раз в 3-7 дней) делать видео-созвон, где проводить ревью кода, отвечать на вопросы и обсуждать дальнейшие планы. Если нет таких знакомых, то можно даже мне написать :)

У реальной стажировки есть еще один плюс — всегда можно спросить совета у более опытного товарища.
Я именно не это и надеялся когда мне предложили стажировку и пытался спрашивать. Но поверьте, лучше бы я эти ответы не слышал.
Если нет таких знакомых, то можно даже мне написать :)
Спасибо за предложение! У меня есть одна идея. Напишу как только соберу все мысли в кучу.

Это тебе еще повезло, что у меня есть такие связи и стажировка, после курсов. Я вот наверное месяц в поисках уже)
Так что набивай лапу, если есть возможность

вот они используют ворпдресс и могут рассказать о роутах в нем... А ты можешь?
А ты SOLID, GRASP, KISS, DRY соблюдаешь? Нет? Ты говнокодер как и все — поздравляю
Ну будут они гит использовать и в одну ветку комитить, а деплоится через фтп, потому что на хостинге ssh нет.
Гит реально неудобный оказывается для таких задач
У команды задача — сделать проект неподдерживаемым для других, так что так и пишут
Я думаю тебе есть много чему поучиться

Посмотрите на все это со стороны. Вот Вы такой весь умный после курсов (!) и без дня опыта работы приходите в студию с налажеными бизнес-процессами (плохими или нет, вопрос второй) на бесплатную стажировку и пытаетесь им рассказывать, какие они лохи и неучи... Смешно выглядит.

А с чего вы взяли что я кого-то там учил как нужно делать? Я имею представление о субординации и знаю что сейчас мое место в этой команде самое последнее. Просто некоторые люди не хотят понимать что их подход к работе давно устарел и небольшие изменения будут только плюсом, даже когда им на пальцах это показываешь.

Вот Вы такой весь умный после курсов (!)
А вы случайно не из тех, кто думает что все курсы это говно, нужно все учить только самому, и что любое решение можно найти в Google? Я пошел на курсы уже с некоторыми знаниями, хоть и совсем малыми. На этих курсах меня научили этими знаниями пользоваться — не просто делать что-то, а понимать почему это именно так нужно делать. Поверьте, это был далеко не какой-нибудь ШАГ.

И что, по веб-разработке — не любое решение можно найти в Гугле?

1. Конечно, я так не думаю.
2. Вы опять становитесть в позу. А я всего лишь предложил Вам посмотреть на себя со стороны...

все немного не так. Курсы — говно. Надо учиться по профессии 5 лет.

Это нормально для 90% веб студий, остававшееся 10% это либо крупные компании где без git и прочего все развалится, или разработчики нестандартных решений.

Советую не спорить, будет только хуже, или валите оттуда или забудьте, в любом случае от клейма «странного новичка» не избавится, вы рано показали что умнее их.

любого кто кодит можно назвать говнокодером, всегда есть к чему придраться, если следовать всем умным красивым практикам и теориям, то на работу не останется времени или оно будет ооочень долго делаться. Поработали бы пару месяцев там можно уже было судить про говнокодинг и думать, что дальше делать. Никакие курсы не заменят практического опыта. Ну если курсы такие крутые и там всему научили надо было сразу в Adobe устраиваться, но и там поверьте вы бы нашли говнокодеров. Открою страшную тайну молодым дарованиям, если вы думаете, что вас сразу посадят за стол с двумя большими apple мониторами и вы там будете полдня реализовать метод красивым кодом, потом еще треть дня писать тест и еще полдня заливать, а вокруг все мегаумные и опытные супернинидзи которые обязательно будут прислушиваться к вашим советам — то такого не будет. Это как с ремонтами, приходит один ремонтник и говорит «ооо, кто же это вам такое говно сделал, надо переделывать», он переделает, придет другой и скажет тоже самое. И самое веселое, что так везде не только в ремонте или IT.

А теперь самая большая тайна коммерческой разработки: клиенту вообще пофиг, что там внутри, ему главное, что бы у него появилась рабочая версия с минимум багов и как можно быстрее. То, что сегодня является трендовым дизайном и решением, через пару лет будет устаревшим хламом.

Вообще надо слушать две стороны, любую херню можно оправдать и вообще могут говорить одно, а делать другое.

1. Мы не используем Git — если у них по одному, челу на проекте то и нафиг не надо, может они льют изменения в SVN раз в неделю, месяц, год
2. Sass — ну так может они юзают LESS/Compass, а с определением просто оговорились
3. Зачем писать аккуратный и код? Все равно эти сайты кроме нас никто поддерживать не будет! — ну если пацаны правду сказали, че им париться? )))
4. В именах классов мы используем транслитерацию так-как не все знают английский. — в каждой команде обычно свое naming convention и вам как новому, члену команды надо юзать принятые до вас соглашения

Может у них такой дизайн, что псевдоэлементы просто не нужны

Wordpress скажу я вам мощная херня которая до сих пор активно развивается ( поработаете с вордпрессом, всегда можно в черные времена подшабашить на скорую руку), и если клиент получает решение которое сделанное за 1 один день на вордпрессе, и его это устроит это -перемога. Если клиенту получает решение на symfony/grails/flask через месяц которое еще надо дебажить полгода это — зрада.

Не забывайте, всегда можно открыть свою дев компанию, где код будет кристально чистым, все друг другу братья и никаких !important!

Согласен. Возможно у меня просто такой крик души был. Просто когда ты стараешся, учишь технологии которые пишут в вакансиях на позичию Junior, а потом тебе говорят что все это никому не нужно, то впадаешь в ступор.

А ещё бывает, что ты ниньзя в Wordpress, 10 опыта работы с ней за спиной, тебя садят на проект под Wordpress, переделывать чужую говнотему под новый PSD. А ты не верстак. А через неделю приходит ПМ и говорит: «чо за херня со скоростью, ведь ты ниньзя Wordpress?»

1. Мы не используем Git — если у них по одному, челу на проекте то и нафиг не надо, может они льют изменения в SVN раз в неделю, месяц, год
Зато как больно становиться, когда диск с двухнедельной работой помирает.
3. Зачем писать аккуратный и код? Все равно эти сайты кроме нас никто поддерживать не будет! — ну если пацаны правду сказали, че им париться? )))
4. В именах классов мы используем транслитерацию так-как не все знают английский. — в каждой команде обычно свое naming convention и вам как новому, члену команды надо юзать принятые до вас соглашения
Вырабатывается привычка, которую будет ой как сложно изменить.
Зато как больно становиться, когда диск с двухнедельной работой помирает.
так кто вам мешает поднять свой SVN на облаке или Git-репо приватный за 50 или сколько там баксов. А в общий будете комитить по желанию. Я когда диплом писал — комитил в SVN и не упадет и можно удобно history посмотреть.

Ага. Только лучше сменить работодателя на более разумного и не иметь дела с извращенцами.
Если работодателю плевать на потерю 2-х недельной работы, то вероятнее всего ему плевать и на многое другое.
А так голь на выдумки хитра, может и свой монитор, комп, стул и офис принести и работу разумно организовать. Ой, это уже удаленка получилась.

BitBucket — для команды до пяти юзеров — бесплатный план с неограниченным числом приватных репозиториев.

Все таки транслит в названиях классов это перебор.

Кстати насчет транслита классов. В нашем ремесле без знания английского, хотя бы на уровне чтения-писания тех документаций вообще никуда, за исключением 1С програмеров.

Так что это хороший показатель того что программисты там не очень

Действительно, зачем писать на транслите, если можно прямо на русском языке. Или ещё лучше украинскою мовой, индусы потом точно не разберутся.

Ви так пишете, ніби українська мова — це щось погане.

Для индусов — да. А когда они в отместку начнут писать на хинди — будет весело.

несогласен, потому что 1с бывает разный. и когда с базой работает под 400 человек здесь уже все поинтересней. кстати у меня все знакомые матерые 1с, кроме нее как минимум могут еще скрипт написать на шарме, питоне и т.д. и sql запрос который многим и не снился.

Я не говорю что они хуже, а что они единственные кто реально может обойтись без инглиша

не совсем так, на данном этапе 1с очень часто работает в связке с другими системами для которых нужен инглиш. например sql сервера, BI системы типа Qlikview, slack, rabbitMQ и т.д.

пожалуй вы правы, я далек от 1С разработки

sql запрос который многим и не снился.
Зачем нужны sql-запросы, которые многим и не снятся? Надо значит базу и код спроектировать так, чтоб были только простые и быстрые запросы, и причём немного и редко.

ну сложные не значит медленные, и бывает так что база уже работает года 2, а потом заказчик говорит что ему надо так и так доработать, и проектировать все с нуля нет не времени не денег

> А теперь самая большая тайна коммерческой разработки: клиенту вообще пофиг, что там внутри, ему главное, что бы у него появилась рабочая версия с минимум багов и как можно быстрее. То, что сегодня является трендовым дизайном и решением, через пару лет будет устаревшим хламом.

Еще одна большая тайна: клиенту пофиг, как вы будете управлять изменениями без потери скорости. И чем больше говнокода, тем существеннее будет падать скорость внесения изменений.

У тебя есть два варианта: попытаться что то улучшить или свалить на лучшую работу. Кстати часть из того что ты сказал не так уж и печальна, как например все сайты на Wordpress — может у них специализация такая. В общем оно и понятно почему там говнокод c Wordpress далеко не уедешь и свои скилы не подкачаешь. Я в 2005 году стажировку проходил так там была самописная система с ООП и блэкджеком!

Учитываю твою специфику я бы посоветовал бы тебе постажироваться в каком нибудь новомодном стартапе, который использует JS во всю: Angular | React | Polymer | Backbone. ИМХО сайты уже не актуальны.

Если хочешь что-то улучшить, то для начала тебе нужно найти единомышленников, к примеру 1-2, выработать стратегию, пойти поговорить с руководством/лидом и применять ее на практике. Еще одна тактика это смоделировать/спровоцировать ситуации при которых не применять инновации станет невыгодном.

Насчет того что уходить не куда то здесь ты не прав, всегда есть куда. Для этого достаточно отправить сотню имэйлов в разные компании и предложить свою кандидатуру. Уверен что найдется 5 отличных предложений и ты еще выбирать какое лучше будешь :D

Еще одна тактика это смоделировать/спровоцировать ситуации при которых не применять инновации станет невыгодном.

Внести непоправимые изменения в код а потом сказать «ну надо было использовать несколько веток и проблемы бы не было» и со спокойной душой обновлять дома резюме :D

Это еще норм. Всегда (всегда!!!) задаю вопрос «sql-запросы в кукисах храните?». Если ответ отрицательный, то жить можно.

Такого полно, не даром ведь миллион статей об этом написано

В аналитическом сайте одной американской корпорации хранили пару логин+пароль в кукисах. Зачем — я не помню, кажется это был костыль, которым они подпирали какую-то проблему с серверными сессиями.

хранить открытый пароль даже в базе — это еб****во, а не костыль

Такой многообещающий был заголовок.... Не в этой теме срача много не разведешь... проходим мимо

Каждый суслик в поле агроном. ©

www.youtube.com/watch?v=sLP8aqbuHsw

Если бы не стажеры — не выжили бы.

Дык ведь это и есть опыт коммерческой разработки!

Был парень на собеседовании из такой конторы, вроде толковый, но в итоге не взяли потому что переучивать сложно. Не трать свое время, лучше дома «не коммерческий» проект напедаль и ссылкой на гитхаб по собеседованиям в нормальные конторы.

в нормальные конторы
Как их узнать до того как вот в чём цимес.

Так может также бесплатно дома верстать разной сложности макеты и пополнять портфолио? Это же тоже опыт, еще и какой. Я так делаю, я тоже начинающая в верстке web страниц. Давайте дружить. :) По топику согласна, стремно научиться не тому, чему надо, особенно когда знаешь как правильно.

я когда увидел пост в рассылке почему-то был уверен что он анонимный. ну и тогда посоветовал поработать месяца 3 просто чтоб поучиться на чужих ошибках
но если пост от себя то советую срочно рассылать резюме и паковать вещи пока они не оказались за дверью.

Дело в том, что это виденье одной стороны и никто не знает насколько оно адекватно, даже те товарищи, котрые дают совет быстрее бежать.

Хороших кодеров нет. Но вы держись там, здоровья вам и хорошего настроения.

Ну, разве что ради строчки в резюме. А так понятно, что оттуда надо валить побыстрее.

Я думаю, у каждого была такая контора, после которой хочетс крепко забухать и забыть как страшный сон. Или над кем можно шутить еще месяца 2-3 за пивом :) Успокойся, ищи что-то новое, а когда найдешь уходи со спокойной душой.

Вспомнил анекдот:
— Как тяжело наверное быть веб-разработчиком. Уже на собеседовании заставляют писать красивый код, как на продакшн... С комментами и тестами. Страшно представить, что же будет после трудоустройства...
— А потом на настоящей работе приходится говнокодить в древнем IDE без комментариев и тестов.
— Прикольно. Получается, что собеседование — это как мальчишник перед свадьбой. Последняя возможность почувствовать себя человеком.

че тут думать? ищи новую работу

Run, Forrest, run!

по знакомству попал на бесплатную стажировку в небольшую конторку занимающуюся ....
По мойму тут все суть раскрыта конторки и чела.
Кто-то привел малолетнее дарование, которое взяло и публично его-же обосрало :D

Это реальная жизнь, пройти это и не сойти с ума и есть стажировка. Вот и проверишь свои знания могут ли они быть эффективнее говнокодерства. Про git правда не понятно, много кто не использует git, сталкивался когда никакую систему контроля версий не используют, это был трындец, тогда заводил себе локальный репозиторий.

При любом удобном случае ищут куски готового кода.
Что, в общем-то, не так уж и плохо, если хорошо понимаешь, что этот код делает и рейтинг на SO у него 100+ и куча комментов пользователей. Это, как минимум, даёт определенную гарантию, что конкретно в этом куске кода нет совсем уж банальных ошибок.

Это автор еще просто коммерческого опыта не набрался, еще пока романтика, все руками т.д.:)

Бывает, а у нас так всегда было , есть и будет. Логика шарашкиных контор

«11. Неожиданно, но джуниоры могут знать технологию лучше синьоров»
...
«— Я тут уже всё изучил и вот чувствую, что ничему новому не учусь. Подумываю менять работу. Куда податься, не знаю. Что там сейчас в тренде?»

«Стоит ли брать на работу джуниоров» dou.ua/...articles/why-need-junior

Один раз меня наняли дописывать проект с индусами, и я думал что все очень плохо. Но пару месяцев спустя меня наняли другие индусы фиксить их проект — все было в разы хуже (понял, что первые были не так уж и плохи). Казалось, что это дно, но нет — пару недель назад увидел проект, который был настолько ужасен, что я отказался от него через два дня (а вообще убедил заказчика его переписать и на днях буду релизить). К чему я это... жизненно короче, и не факт что в другом месте не будет хуже.

1. Мы не используем Git — это (внезапно!) не удобно.
А что такого? Командлайновым интерфейсом гита можно пугать маленьких детей. Переходите на mercurial пока не поздно!

Так Git сейчас в каждой вакансии есть. И что такого страшного в командлайновом интерфейсе? Очень даже удобен.

Command line сам по себе — это ок. Не ок — это его имплементация в git. Несмотря на то, что я с git работаю каждый день, не могу не поддержать Andrii Batyiev. Mercurial — просто песня по сравнению с git.

Пробовал я ваш меркуриал. Да, проще, но эта простота нафиг не нужна

Что за люди? Им сделали проще, лучше, удобнее, а они «ненужно!!!1» и продолжают пользоваться экскрементами.

Правильнее сказать ограниченнее, и когда на эту ограниченность натыкаешься, бесит.
Да и гуевые оболочки в помощь, кто с командной строкой не дружит

Вспомнилось: Создайте систему, которой сможет пользоваться любой дурак и не один дурак не захочет ей пользоваться ))

SourceTree, GitEye и прочие GUI клиенты к гиту отменили? :)

к тому же у самого гита тоже гуй есть :)
$ git gui

что то не зарабоатло:
➜ ~ git gui
git: ’gui’ is not a git command. See ’git —help’.

наверное у Вас гит без гуя установлен просто)
хотя — с другой стороны изначально гит действительно без гуя, просто есть гуй на tk, который идет в сборке git-scm.com/download/win для винды (которую я юзаю). Да и для юниксов его (гуй на tk) можно установить и тогда этот гуй будет вызываться через git gui

просто доставь пакет и все

Gitup для маков ... но вообще cli лучше .... или Fugitive плагин для вима

плагин для вима
вот я еще подумал — интересно, вдруг в той конторе, о которой говорит топикстартер, о виме вообще не слышали, а юзают исключительно что-то вроде notepad++))

А в чем особый цимес использовать vim на Винде?

примерно в том же, в чем использование емакса на винде)

иначе зачем делают виндовые сборки вима и емакса? :)

Потому, что могут? :) Ну я серьезно не видел, чтобы в реале кто-то этим на винде пользовался, хотя лично из интереса когда-то запускал и то, и другое.

Потому, что могут? :)
думаю скорее потому, что эти редакторы считаются самыми крутыими для программеров) Поэтому и делают для того, чтобы и те программеры, что кодят из-под винды, тоже могли приобщиться к прекрасному (в смысле к виму с емаксом).
Ну я серьезно не видел, чтобы в реале кто-то этим на винде пользовался
ну вообще да, думаю, что вим и емакс в основном юзают линуксоиды/юниксоиды, ибо оба эти редактора родимлись в среде юникса + привыкшим к работе преимущественно мышкой виндузятникам будет тяжело перейти на вим/емакс с любиммого нотпад++. :)

а так я пользуюсь... немножко. :) (может потому, что со временем думаю пересесть на линукс онли).
+
программеры-виндузятники наверное очень редко приходят к тому, чтобы юзать вим/емакс как основной виндовый редактор (ибо если чел кодит например под дотнет, то ему вполне хватит вижуал студии, особенно если комп мощный).

привыкшим к работе преимущественно мышкой виндузятникам будет тяжело перейти на вим/емакс с любиммого нотпад++

Дело даже не сколько в мышке, сколько в том, что в вим и емакс даже клавиатурное управление для пользователя Windows кажется «марсианским». Плюс, отдельные режимы вставки и редактирования, чего не было даже в текстовых редакторах времён MS-DOS — за исключением, разве что, edlin, которым практически никто не пользовался.

программеры-виндузятники наверное очень редко приходят к тому, чтобы юзать вим/емакс как основной виндовый редактор (ибо если чел кодит например под дотнет, то ему вполне хватит вижуал студии, особенно если комп мощный)

Давайте определимся, как редактор или, все же, среду разработки? В качестве просто редактора, действительно, хватает notepad++ или даже встроенного в FAR. А от среды разработки ожидается гораздо бОльший функционал, и началось это не с Visual Studio, а еще со времён Turbo Pascal / Turbo C++.

и началось это не с Visual Studio, а еще со времён Turbo Pascal / Turbo C++
ну вижуал студию я так — для примера инструмента разработки под винду.
Если брать пример именно редактора под винду для дот.нета, то можно взять Visual Studio Code (он правда кросплатформенный), который из коробки поддерживает С# и ASP.NET насколько помню.
а так да еще до вижуал студии были среды разработки под винду.
Дело даже не сколько в мышке, сколько в том, что в вим и емакс даже клавиатурное управление для пользователя Windows кажется «марсианским».
ну само собой это тоже играет большую роль. Просто я пляшу от обычного пользователя винды, который решил стать программером. Он больше привык выбирать пункты меню мышкой, нежели использовать хоткеи, поэтотому он скорее выберет какой-нить редактор с гуем, нежели консольный)
я имел ввиду в первую очередь это, а не сложность хоткееев или команд. ;) Ибо, имхо, когда это опытный пользователь — он будет больше обращать внимание на то, что с помощью хоткеев и комманд быстрее и удобнее производить нужные операции, нежели мышкой. и через какое-то время возможно решит посмотреть на вим с емаксом.
-
з.ы. и да — для вима и емакса есть плагины/конфиги, адаптрованные под привыкших к винде: для вима это Cream cream.sourceforge.net (на основе gvim’a. Делает из вима практически привычный виндовый текстовый редактор), для емакса — ergoemacs ( ergoemacs.github.io ) . возможно даже еще какие-то есть.
для вима и емакса есть плагины/конфиги, адаптрованные под привыкших к винде: для вима это Cream cream.sourceforge.net (на основе gvim’a. Делает из вима практически привычный виндовый текстовый редактор), для емакса — ergoemacs ( ergoemacs.github.io ) . возможно даже еще какие-то есть.
це для збоченців.
ну реально, який лінупсоід сяде під мастай!?

так их, как мне кажется, для мастдаевцев и придумали)

Ой ну хватит вам демонизировать винду )) В 1998м году это было актуально, но не сейчас. Тем более, совсем скоро в Винде полная поддержка консольного Linux появится из коробки.

В 1998м году это было актуально, но не сейчас.

И сейчас не меньше. Потому что проблема не в линуксоедах, а в привиредах против изиотов.
Читать тут: раз, два, три.
Разница только в том, что появились линуксы для изиотов (ChromeOS, Ubuntu с дефолтной Unity-мордой и т.д.)

Бачив таких не мало.

для вима это Cream cream.sourceforge.net (на основе gvim’a. Делает из вима практически привычный виндовый текстовый редактор

Не троллинга ради — так а какие преимущества vim тогда сохраняются? Как я понимал, весь цимес vim именно в том, что он удобен привыкшим к хардкорному консольному интерфейсу?

ЦА не зрозуміла.
Хто звик хоткеями користуватися навряд чи буде дрочити мишку, і навпаки.

так а какие преимущества vim тогда сохраняются?
хз... я не вимер как бы)

Могу разве что предположить, что многие плагины вима должны работать (по крайней мере плагины подсветки синтаксиса и такие, у которых мимнимум зависмостей от др. вимовских плагинов).

Как я понимал, весь цимес vim именно в том, что он удобен привыкшим к хардкорному консольному интерфейсу?
я думал, что цимес вима в том, что он чуть ли на каждом удаленом линуксовом серваке стоит. И хош не хош, а текстовые файлы удаленно прийдется частенько открывать именно в терминальном виме со стандартным конфигом.

так что ИМХО если сел за вим — по любасу надо научиться работать в терминальном виме со стандартной конфигурацией. И в этом плане любые сборки вима с нестандартными конфигами естественно бесполезны.

Хм, ну даже в таком ключе не vim’ом единым... Помню, в таких случаях гораздо чаще пользовал nano, он и то почеловечнее будет :)

согласен)
а вот мне из консольных редакторов (которые смотрел) больше всего понравился Joe’s Own Editor, который, хоть и несколько сложнее нано, но более фукциональный вроде (и проще вима), ну и у joe есть несколько цветовых схем (по крайней мере в виндовой сборке).

Вы исходите из того что «всю дорогу пользовался Windows, с ее обычными инструментами, с чего бы меня мог заинтересовать vim/emacs с их прямо скажем нетипичным подходом». А история обратная: «всю дорогу пользовался vim/emacs, а тут сейчас приходится писать под Windows». Для нас эта ситуация все еще несколько необычна: средний джун на собеседовании про никсы может вспомнить две команды, и то из серии «когда-то в универе рассказывали», да и не-джун вполне возможно знает только как выйти из vim, а никсы у него «только на серверах». Для буржуев несколько менее необычно: у них и более старших разработчиков много, да и в образовании никсы встречаются почаще чем «один раз на третьем курсе шото такое было».

Поэтому вопрос «как использовать vim/emacs вместо IDE» стоит только когда от IDE все-равно толку мало: все эти JS/Perl/PHP/Python/Ruby/etc. А если толк от IDE таки есть, вопрос стоит «как использовать vim/emacs вместе с IDE», и там великое море вариантов. Для вашей же Visual Studio, например: vim.wikia.com/...e_gvim_with_Visual_Studio или visualstudiogallery.msdn.microsoft.com/...47-413a-9176-742be7463f92. Потому как плюшки среды разработки — это конечно хорошо, но привычный редактор при этом — еще лучше.

Для буржуев несколько менее необычно:
це в яких таких буржуїв?
мій досвід показує, що мастай там головного моску

Зависит от. Мне как-то даже ПМ попадался с убунтой на ноуте и какими-то скриптами в vim’e. Когда-то видел статью про то что emacs достаточно популярен в недрах самого великого и ужасного Microsoft’а. Мол берут народ из MIT, a в MIT их подсаживают на emacs.

Поэтому вопрос «как использовать vim/emacs вместо IDE» стоит только когда от IDE все-равно толку мало: все эти JS/Perl/PHP/Python/Ruby/etc.

Про perl и Ruby ничего не скажу, что касается тех же JS / Python / PHP, то очень многие используют IDE в полный рост, на *nix системах в том числе.

Поэтому, удивляет позиция

А история обратная: «всю дорогу пользовался vim/emacs, а тут сейчас приходится писать под Windows»

в том плане, что и под *nix системы наверняка существуют редакторы более удобные, чем vim / emacs?

Ну не верится мне, что за все годы существования Linux под него не сделали чего-то хотя бы уровня MultiEdit?

Про perl и Ruby ничего не скажу, что касается тех же JS / Python / PHP, то очень многие используют IDE в полный рост, на *nix системах в том числе.

Ок, если взять за базу тот же vim(да и любой текстовый редактор, привычный или непривычный) и *nix-окружение, как «универсальную среду разработки». Где «все есть текст». Что получаем:
1) дебаг: в основном принтами (ну не дело это текстового редактора)
2) «рефакторинг» — текстовый поиск и замена
3) «suggestions» — по-сути тоже регекспами находим что можно подставить ими же определяем текущий контекст в котором что-то можно порекомендовать.
4) подсветка синтаксиса — тут есс-но регекспами.
5) показ ошибок — в основном за счет того что #4 зафейлился и с подсветкой случился мрак :)

Для статически типизированных языков огромная плюшка IDE: возможность повычислять типы, соответственно № 2-5 будет уже базироваться не просто на абстрактном анализе текста, соответственно можно показать/сделать больше и лучше, исходя из «понимания» контекста.

Для динамических языков такой же финт ушами провернуть сильно сложнее, и полностью все-равно невозможно. Да, пытаются, да у JetBrains неплохо получается местами, но все же пропасть между IDE и текстовым редактором для условного Ruby или JavaScript не такая большая, как для Java или C#.

Но, на самом деле — это не вопрос «IDE vs. убогий-vim-кому-он-вообще надо». Я, например, использую vim для Perl, и RubyMine/IDEA для Ruby/Java. Но для RubyMine/IDEA есть чудесная эмуляция vim, в редакторе, соответственно имея все плюшки среды разработки, можно получить и часть плюшек vim(в моем случае «все плюшки vim, к которым я привык, но у меня нет особо эзотерических привычек).

в том плане, что и под *nix системы наверняка существуют редакторы более удобные, чем vim / emacs?

существуют. Собственно все эти сублаймы, атомы, визуал студио код. Но: это не вопрос про «более удобный», это вопрос про «более привычный». Или возможно даже «более понятный и предсказуемый при первом запуске». Потому что про удобство можно говорить на длинной дистанции, соответственно прошагав некоторое расстояние по learning curve, обросши привычками и автоматизмом. Тут уже все не так однозначно.

Причем забавно в этой неоднозначности вот что: если углубляться в «священные войны», то мы начнем замерять штуки типа «насколько быстро я могу сделать Х», считая что я знаю как это делать. Но, если тот же vim до некоторой степени форсит приобретение, по крайней мере некоторых привычек для эффективной работы, потому что привычного способа сделать нет, узнаешь вимовский, а если делаешь часто — входит в привычку, то для редакторов в которых все сразу просто и понятно, пользователи так и остаются в рамках простого и понятного. Я видел пользователей Far Manager’а, которые очень ловко обращались с тамошним редактором, но на одного такого приходится десяток знающих только три шортката в своей IDE: скопировать/вставить/запустить.

ацтой ваші віми з емаксами, тре пам"ятати всі комбінації кнопок

видать именно поэтому и придумали GVim и гуй к емаксу, чтобы «любители работать мышкой через меню» и те, кто не владеет слепым набором не чувствовали себя обделенными. :)

gvim с меню такого не требует. emacs аналогично.
Но когда их таки выучили — получается удобно.

А мне интересно, что заставляет людей пользоваться командной строкой если есть отличные клиенты? Тот же Git Extension — пользуюсь уже около двух лет и никакой попаболи. В командную строку макс захожу раз в неделю.

Потому, что командная строка — проще, быстрее, нативнее. Да, обучение дольше чем гуям, но потом и скорость работы выше.

По моему мнению — это вкусовщина.

Вы в корне не правы. CLI интерфейс намного более предсказуем и прозрачен, чем GUI. Простые программы можно объединять с помощью конвееров в крайне замысловатые и производительные комбаины. Также очень удобно управлять этими программами с помощью скриптов. Единственный минус — более высокий порог вхождения, но познакомившись с полноценным CLI уже гуями пользоваться не будете (со сходным функционалом).

ты просто не знаешь хороших гуи тулзов. например сравнение двух файло с возможностью правки обоих или перекачка по фтп файлов с одного сервера на другой, в гуи это все намного проще чем в кли.

Я знаю хорошие консольные утилиты. Да, согласен. Гит хистори и дифф лучше в гуях. Но абсолютное большинство инструментов лучше в консоли, просто мы с вами из разных вселенных)

я не против консоли, но гуи бывает еффективнее

Розкажи як ти пишеш та тестуєш гуй, послідовність кліків. Чи нехай користувачі тесутють?

вообще GUI тестируют как и все с помощью тестов... Там даже тема есть выше

О чём вообще спор? Многие проги с графическим интерфейсом обрабатывают также параметры командной строки. То есть их можно запускать из консоли с параметрами.

Я знаю одну контору, в которой git никогда не использовали, недавно опять взяла контракт на 4 миллиона евро (или около того). Еще знаю контору которая Sass вообще не использовала, и как-то крутилась, и сайты уже лет пять-семь висят и денежку приносят владельцам.

А я прекрасно знаю контору без git и sass, которая всего-лишь чуть больше 1 миллиона евро распилила. Неудачники видимо.

Не знаю. Препроцессоры отличная вещь. Значительно ускоряют верстку, даже если использовать только несколько их возможностей.

Я знаю одну контору, в которой git никогда не использовали, недавно опять взяла контракт на 4 миллиона евро
Это, что называется, не благодаря, а вопреки.

Перечитал пост еще раз, более внимательно.

Прошел курсы по верстке и основам JS
Итак, ты прошел курсы для начинающих. Это, случаем, не те курсы, где по пять-десять дней каждый, с занятостью по два-три часа в день? Если так, то тебе, если честно, икона улыбнулась. После таких курсов (да и вообще любых курсов для новичков), даже такая работенка — уже халява, причем неплохая.
В общем ребята вообще печальные. Никто ничего не знает
Эти печальные ребята — такие же, как ты. После тех же курсов, 100%. Ничего страшного, не парься из-за этого.
Sass — это постпроцессор и вообще говно.
Бутстрап тоже не используют? В этом есть плюс даже. Научишься верстать «руками» — это полезно.
уже халява, причем неплохая.
Я правильно понимаю, что халявой вы называете возможность бесплатно пахать на кого-то даже без шансов научиться чему-то полезному? Это действительно халява, но только никак не для автора треда.

Ну так поясните, чтобы было понятно. Где халява?

А-а-ай... Хорошо. Судя по всему (а может просто и мое видение), он прошел «кампутирные курсы» для новичков, имея нулевой опыт, проживая в районном центре, где все улицы имеют название по типу «улица ХХ Партсъезда». 2016 год — «вайти-вайти» все сложнее, особенно для таких людей, как ТС. Говноконтора в качестве первой работы — это норма, реальность и жизнь, если не для вас, то для многих людей, которые ходят вокруг и что-то там делают-думают. Многие вообще эникейщиками начинают. Пахать полгода бесплатно в его случае, чисто для строчки в резюме, для облегчения последующего трудоустройства, даже недоджуном — не такое уж и отклонение от нормы. Шансы научиться чему-то полезному там — малы, но все зависит от него; и ключевым здесь является предыдущее предложение, а не вырванное из контекста слово «халява».
Да, можно в опенсорс, можно в самообучение, можно найти другую контору, можно так, а можно эдак — кому так, а кому сяк. Дальше двери лифта закрываются и меня уже не слышно, всё.

Не, ну реально, а зачем им писать аккуратный код? Всё равно всем пофиг, как ваш сайт написан, аккуратно там банеры с рекламой крутятся, или с косяками под оперу, главное чтобы выполнялись поставленные задачи. А как там всё внутри — всем до лампочки, пусть хоть золотом-алмазами весь код выложен — это никто не оценит. К тому же продержится средний сайт года 3, ну лет 8 максимум. Git им не удобен, и у вас это вызывает непреодолимый внутренний диссонанс с вашими принципами? Постарайтесь пережить этот факт. Может они svn юзают, или hg, или архивирование через RAR, или вообще ничего. То что имена классов на транслите — это только плюс, как раз фактор, препятствующий передаче проекта на доработку индусам.

Возвращайтесь обратно продавать кабачки.

Скажи мне ваш адрес, это как раз то что мне нужно!

Друг, не стоит. Мне сегодня еще сказали, что следующим моим заданием будет сделать макет. У них вертальщики еще и макеты сами должны делать.

В деяких місцях взагалі вимагають бути фулстек девелопером. Жах.

фулстек девелопером

в айти так называют разнорабочих.

Нагадує мені одну контору де якщо ти як програміст робиш UI не по макету то ти мудак, якшо по макету но твоєму начальніку макет непонравився то ти опять мудак ібо маєш шарить UI/UX дізайн краще штатного дізайнера. Мене там вистачило від сили на 2 місяці.

Слушай, а в школе разве не то ж самое было? А в ВУЗе? Спокойно попробуй выйти на минимальные издержки. Если тебе эта стажировка что-то по карьере даст — имитируй понимание и НЕ ВМЕШИВАЙСЯ в процесс. Если нет — уходи, так и объясни что твой уровень выше их, тебе не интересно. И либо они дают тебе РАБОТАТЬ, а не стажироваться, либо ты просто уходишь туда где дадут.

Для оытного человека такое портфолио будет как Филькина грамота. Разве что вне рабочее время сидеть и верстать свои шаблоны.

Грубо говоря, твоя задача сейчас — высидеть полгода в этой конторке, выполняя работу, желательно пытаясь доучиваться в свободное время. Пока что не заморачивайся на том, что твое портфолио будет состоять из убогих сайтов на вордпрессе. Важнейшее, что тебе нужно для последующего трудоустройства джуном — это факт опыта работы. Там ты не станешь «опытным человеком», и на собесе на позицию джуна с тебя вряд ли будут спрашивать как с «опытного человека». Т.ч. если бежать некуда — лучше уж отпахай на текущем месте чисто для галочки.

Попробую, но сомнений с каждым днем все больше.

Совет дельный, без опыта работы в айти, половина ейчаров твое резюме будет удалять не читая. Сам когда искал работу заметил что отклик на резюме с курсами и резюме с 2 месяца работы фронтендщиком — 1:10 и 1:2-1:3 соответственно. И это на джуниорские вакансии.

Тут дело в том, что могут попросить примеры работ. И ладно, HR визуально все понравится и кинут они техспециалисту. А он будет оценивать код.

Хотя обычно если есть ОР, они в ответ кинут тебе ТЗ и если все окей, зовут на собеседование.

ох уж эти джуны, скажи что проекты НДА и иди собеседоваться на миддла в другую контору

Соглашусь с Артемом Фроловым.
Самое главное не спиться, сорваться и не настучать им по говнокодерским щщам нахвататься вредных привычек от коллег, а так — в резюме будет строчечка, на собеседовании плюсик в уверенность и ораторское мастерство.

Поработайте некоторое время, сделайте себе портфолио, впишите стажировку там как ваш коммерческий опыт работы (это не будет ложью, т.к. фактически вы делаете тоже самое, что трейни за зарплате в крупной конторе) и подавайтесь джуниором с опытом (свыше полгода — с руками оторвут) в нормальные компании. Все-таки, это что-то вроде первой работы и снова найти первую работу без опыта абсолютного и без портфолио гораздо труднее, чем с минимальным опытом и портфолио.

Такого не было даже в тех курятниках, где я нарабатывал первый опыт.

Подписаться на комментарии