• Разрыв доходов между офисом и фрилансом?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Во-первых, в офис попадают верстальщики, прошедшие собеседования и показавшие себя лучшими среди других соискателей. А на фрилансе за заказ дерутся все, включая тех, кто не попал в офис. Во-вторых, для более-менее серьёзных программистов разрыв может быть уже не в пользу офиса.
    Ответ написан
    Комментировать
  • Порядок обучения с нуля при известном конечном результате. Соответствие ЯП к этапам реализации?

    @abbrakadabbra
    А шеф готов ждать несколько месяцев, когда вы научитесь хотя бы делать первый SELECT к БД?

    Если у вас есть время, то я рекомендую вам начать с: HTML + CSS. Научитесь построить хотя бы банальную web-страницу и оформить ее. Узнайте что такое тег <form> и как он работает.
    Посмотрите как формируются таблицы (тег <tаble>).

    После этого можно начинать осваивать какой-то язык программирования.

    Я бы посоветовал Python. Если выберете его, то наверняка в качестве фреймворка будет выбран Django. На этом стеке вы уже сможете построить ваше вэб-приложение.

    Но не всех так просто и поверхностно.

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

    Но нет времени или шеф не готов ждать, то лучше отдайте задачу профессионалам.

    А программирование изучайте сами, на это деньги не нужны (тут вы поймете действительно ли оно вам нужно).
    Ответ написан
    5 комментариев
  • Важен ли для программиста язык?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Понятно, что ЯП это всего лишь средство передачи алгоритма от человека к компьютеру.

    Это не так. Язык определяет мышление.
    5ce7f0612943f270557969.png

    Следует ли из этого, что специализироваться на одном ЯП глупо?

    Да, глупо, хоть и следует не из этого. Почитайте этот ответ.
    Ответ написан
    Комментировать
  • Важен ли для программиста язык?

    @Urukhayy
    Добро пожаловать в рубрику философских вопросов Тостера!

    Спрос рождает предложение.
    Задача рождает решение.

    Для реализации решения выбирается та технология и/или инструмент (ЯП), который наиболее эффективен в заданных условиях рынка. Всё зависит от поставленных задач.

    P.S. ЯП это как "инструмент", которым можно овладеть, читая "инструкцию по применению" (документацию).
    Ответ написан
    Комментировать
  • Важен ли для программиста язык?

    VoidVolker
    @VoidVolker
    Dark side eye. А у нас печеньки! А у вас?
    Да, все именно так. Программирование — это лишь часть процесса разработки ПО, а не вся. В больших проектах непосредственно программирование может занимать 20-25% всего объема работ. ЯП — лишь инструмент для абстрактного представления каких-либо знаний, алгоритмов, данных и прочее. Частью процесса разработки ПО также являются: написание ТЗ, проектирование архитектуры и подсистем/модулей, выбор жизненного цикла ПО, разработка пользовательских и внешних/внутренних интерфейсов, разработка тестов, интеграция с внешними системами/API, управление командой и задачами, сопровождение проекта после разработки и еще куча различных мелочей и ньюансов.
    Ответ написан
    Комментировать
  • В чём причина постоянного переделывания кода?

    titov_andrei
    @titov_andrei
    All my life I learn - and die a fool!
    Ремонт ЗАКОНЧИТЬ нельзя — его можно только ПРЕКРАТИТЬ.
    https://www.inpearls.ru/
    - © Михаил Жванецкий
    Ответ написан
    Комментировать
  • Почему стремление к упорядочиванию приводит к большей энтропии и отнимает силы?

    titov_andrei
    @titov_andrei
    All my life I learn - and die a fool!
    Если брать пример из жизни, то вы пытаетесь управлять дождём. А это трудозатратно, поэтому человек управляет потоками воды после дождя. Попробуйте и вы управлять не текущей деятельностью, а направлять планируемые последствия в то или иное русло, как водостоки с крыш или ливневые системы на дорогах. Иначе завал, заторы, лужи, грязь и разочарование.
    Ответ написан
    Комментировать
  • Должен ли фронтенд разработчик уметь верстать (css)?

    @ParaBellum577
    Как фронтэндер может обойтись без верстки?... Да я тоже сидел в какой-то момент ничего не верстал около полугода, просто педалил реакт, а потом как-то пришлось опять же пол года тупо верстать. В общем это необходимый навык, я думаю. Без этого от фронта мало толку.
    Ответ написан
    Комментировать
  • Должен ли фронтенд разработчик уметь верстать (css)?

    @abbrakadabbra
    Фронт-энд разработчик не умеющий верстать, это как сантехник, не умеющий починить кран. CSS - это наверное самое легкое, что есть во фронт-энд, так что учите его, иначе вы не можете претендовать на его звание. Тем более на full-stack.
    Ответ написан
    Комментировать
  • Inversion of Control vs Dependency Inversion?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Эти принципы просто относятся к разным вещам. IoC предлагает некий способ организации управления потоком выполнения в системе (кто кого почему и когда вызывает), в то время как DIP предлагает соблюдать определенное направление при организации зависимостей (между модулями), основываясь на уровне абстрактности оных.
    В общем оба они направлены на повышение качественных характеристик системы (и это в них, как и во всех прочих принципах ООД, действительно общее), только один "подходит к проблеме" со стороны поведенческих аспектов системы, а второй - со стороны структурных.
    Ответ написан
    2 комментария
  • Какие крупные продуктовые компании берут на работу джуниоров удаленно?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Джунов на удалёнку не берёт никто в здравом уме.
    Ответ написан
    Комментировать
  • C# или C++, что выбрать со связкой с Python'ом?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Советую C++, так как у Python с ним прекрасная двусторонняя интероперабельность, что позволит серьёзно расширить свои возможности в обоих языках.
    Ответ написан
    4 комментария
  • Какому языку, в какой среде начинать учить ребенка программированию 10 лет?

    10 лет это 3 класс

    Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится
    Ответ написан
    7 комментариев
  • С чего начать изучение веб-разработки?

    Zoominger
    @Zoominger Куратор тега Веб-разработка
    System Integrator
    С изучения зарплат джунов и стажёров веб-разработки, и не на фейковых вакансиях мойкруга, а на hh.
    Затем - изучить конкуренцию на этом рынке.
    И только после этого пойти в другую область.
    Ответ написан
    6 комментариев
  • В какой области IT применение знаний - не самое важное?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Вот идеальный рабочий день - полдня в чем-то разбираться, полдня это простым языком объяснять другим кому интересно.

    Перевожу: Хочу развлекаться за счёт работодателя.

    Работа - это не про развлечение, это продажа своего труда за деньги. И программирование - это не про развлечение. Программист 49% времени пишет скучный код, а иногда и переписывает чужой ужасный код, ещё 49% времени занудно ловит унылые баги. Остаётся радоваться оставшимся двум процентам интересного.
    5cdd8aaeef145978587602.png
    Ответ написан
    2 комментария
  • Какие стратегии повышения зарплаты существуют?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Центральный показатель для бизнеса, а следовательно и руководителей, как людей представляющих интересы этого самого бизнеса - это коэффициент возврата инвестиций (ROI). Соответственно, сотрудник должен приносить компании больше денег, чем потребляет. Естественно, что чем выше разрыв между затратами и прибылью, тем лучше, поэтому фонд оплаты труда руководитель должен держать на том минимальном уровне, который гарантирует бесперебойную работу сотрудников. Один из факторов этой бесперебойности - низкая текучка. Сотрудников терять нежелательно. И чем ценнее для компании сотрудник, чем более он профессионален и/или чем больше на него завязано, тем дороже обходится его потеря. Натурально в деньгах. Придётся затратить больше, чем обычно, денег на поддержание работы без него. Придётся затратить деньги и время (те же деньги) на поиск, найм, введение в работу, возможно, обучение нового сотрудника. При этом он может оказаться совсем неподходящих и цикл придётся повторить. Или может оказаться просто хуже прошлого и эффективность отдела снизится. Поэтому, когда сотрудник приходит просить прибавку, руководитель оценивает может ли этот сотрудник уйти или только блефует, насколько легко его будет заменить, какой урон компании будет нанесён его уходом. Потом руководитель оценивает стоимость расширения ФОТ - есть ли резервы, какой сейчас ROI, будет ли больший ROI от реинвестиции этих средств во что-то другое? Если уход сотрудника будет стоить меньше, чем увеличение ФОТа, сотруднику откажут.

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

    Из этого вывод, стратегия проста - увеличивайте собственный профессиональный уровень на столько, чтобы свободно менять компанию, как только вас что-то перестало устраивать.
    Ответ написан
    4 комментария
  • Как направить программиста на путь истинный?

    @Alexey_Kutepov
    Разработчик программного обеспечения
    d35ab284fd834ee78248059a3adf530c.jpg
    Ответ написан
    Комментировать
  • Почему чувствую себя бесполезным и ни на что не способным на первой работе по специальности?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Если ты реально умеешь программировать, т.е. успешно донести до машины мысль, да так, чтобы она ее в точности выполнила, то это очень здорово, но этого категорически недостаточно.

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

    Я очень долго писал бухсофт, при этом не имея толком знаний по бухгалтерии. Я всегда работал в плотной связке с опытными профильными специалистами, по сути, являясь скорее переводчиком с человеческого на машинный. Причем профильные специалисты хорошо выполняли своё дело, но молча, буквально как пленные партизане. Поэтому моей первейшей задачей всегда было разговорить бухгалтера, помочь осмыслить и сформулировать в мельчайших деталях процессы, которые они на автомате делают ежедневно в течении многих лет. Разумеется никаких ТЗ я никогда в жизни в глаза не видел. Вернее так, ТЗ я формировал себе сам из того, что удалось выведать у бухгалтеров и их руководства.

    Один из вариантов разговорить - это прийти и рассказать своё видение. Люди любят поправлять, вносить коррективы, добавлять деталей. :) Это называется посплетничать. :)

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

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

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

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

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

    Внезапно выясняется, что во всех этих процессах софтскиллы рулят и решают.

    В общем мой совет - качай всё, особенно софтскиллы и отставить кукситься.

    ПыСы: Большинство сотрудников в компаниях, где ты будешь обитать, будут считать тебя то ли кудесником, то ли магом, то ли телепатом, то ли всё вместе. Каждый будет искренне убежден, что ты знаешь все то же самое, что знает он и плюс еще кучу всего, чего они не знают, поэтому будут грузить всем чем угодно. Так же будут искренне верить, что ты обладаешь доступом в пятое измерение, что у тебя времени вагон (т.е. примерно 48 часов в сутках, а может и 72, кто тебя знает то...) и ты многозадачный. В общем будут проявлять все мыслимые и немыслимые формы неадеквата. Это нормально. Через это нужно пройти, научиться во всем это плавать, как рыба в воде. Это здорово прокачивает тебя как личность, если ты настроен на подобный прогресс.

    Если же хочешь просто сидеть в сторонке и кодить, то тебе нужно искать компании/команды, где все айтишные процессы уже выстроены и формализованы, где всю эту работу за тебя уже сделали аналитики, манагеры, лиды. Где ты придешь на готовую архитектуру, с детальным описанием кодстайла. Где тебе будут скидывать посильные таски, продуманные и детально прописанные. Да, такие компании тоже существуют, но их нужно искать, т.к. они пока в меньшинстве...
    Ответ написан
    Комментировать
  • Почему не могу найти работу Junior'ом C#?

    @kttotto
    пофиг на чем писать
    Это не резюме, это набор слов, ничем Вас не выделяет из общей массы и даже делает низовым в списке общей массы.

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

    2.
    Отличное знание WinForms, ASP.NET, LINQ и WPF. Паттерны: MVVM, MVP, Repository, IoC.

    Для третьекурсника звучит самонадеяно. При такой формулировке на техническом собеседовании будут проверять "отличное" знание и я почти уверен, что Вы его провалите. Лучше сказать что-то подобие: имел опыт работы с, для реализации использовал технологии, имею <начальные> навыки работы с и т.д.

    3.
    Занимался исправлением мелких багов, написанием небольших SQL-запросов и unit-тестов, решал небольшие задачи.

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

    4.
    Если вспомнить css и html

    Вот такое никогда не пишите. Лучше соврать или преувеличить, или даже написать "Отличное знание", но не так как Вы здесь сформулировали.

    5. Не нужно оставлять ссылки на каждый проект в репозитории. Либо один, самый интересный на Ваш взгялд, либо одна ссылка на сам репозиторий. Работодатель пойдет туда только, если Вы заинтересуете его, не раньше. И ему пары файлов хватит оценить ваш уровень. Он не будет делать ревью всех Ваших проектов.

    6. Опыта одного проекта мало. Где опенсерс проекты, где участия в хакатонах, где амбиции стартапов, посещение конференций? Работодатель хочет понимать как Вы заинтересованы развиваться, какие у Вас планы для дальнейшего роста. Он берет вас нулевым не из альтруистических побуждений, а с надеждой, что Вы быстро вырастите и вернете ему прибылью затраченное на Вас время. Из Вашего резюме видно только одно: я студент - дайте работу. А почему Вам, за какие такие заслуги и что с этого будет иметь работодатель - не понятно.

    7. Я посмотрел Ваш код. Я бы не хотел, чтобы так писали у меня в проекте, начиная от именований и заканчивая некоторой логикой. Вас надо очень осторожно подпускать к реальным задачам и контролить, что Вы там напишете, просто чувствуется маленький опыт и до "отличных знаний" там далеко.

    В общем, вывод. Пока у Вас за плечами нет списка реальных проектов, чтобы Вас пригласили, надо себя выпячивать, хвастаться достижениями, демонстрировать амбиции, свою уникальность. Нужно убеждать работодателя, что Вы именно тот, кто ему нужен. В резюме этого нет. Когда у Вас будет пяток законченных проектов, будет наоборот, работодатель будет за Вами бегать и убеждать, что Вам у него будет лучше всего. И на hh студентов практикантов не ищут, поэтому только Вы должны делать отклики на вакансии, обязательно с сопроводительным письмом, в котором парой фраз Вы сможете заинтересовать работодателя.
    Ответ написан
    Комментировать