ru.m.wikipedia.org/...Роговичи_(дворянский_род

А вообще да, шансов маловато, но ведь еще меньше, что закинут в прошлое... Вопрос поставлен так, что есть выбор, в если он есть, то почему бы не фантазировать в этом контексте

много кто тут философствует на тему сложной жизни в те времена — но сам вопрос так поставлен, что есть возможность выбирать, соответственно «умер в детстве», «рабам слово не давали» и прочее можно смело откидывать и просто фантазировать — как Л.Толстой сено косил, не потому что надо было, а потому что хотел ;)

я бы наверно строителем был... математика, физический труд, работа на свежем воздухе — самое оно :)

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

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

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

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

я не гнушаюсь пользоваться стандартными фреймфорками типа бутстрапа, и понятно, что я юзаю всякие btn btn-primary — но, как «джун» правильно подметил, если есть 4×4, то ездить всегда принципиально только на передней — глупо... для каждого способа есть своя область применения

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

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

ну если scss используете, то какие могут быть проблемы? все, что реально реюзабл, кидаете в миксины, и включаете в свой # селектор... комбинируете, параметризируете как вам нужно...

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

у вас там платят построчно и по этому менеджменту ставятся задачи уменьшение строк кода?

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

для того, чтобы использовать какие-то наработки более одного раза, советую смотреть в сторону sass/less — опять таки, если не сильно напрягает пару байт лишнего цсс-а на выходе...

использовать классы там, где пишешь стили конкретно для одного элемента — вот это фу...

когда люди стилизируют чем-то на подобие class="my-top-margin-10px my-bottom-padding-2px my-left-border-solid" вместо того, чтобы все эти селекторы вписать под один айди — мне хочется плакать...

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

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

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

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

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

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

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

у меня встречное предложение — снимать эти 100 баксов с рекрутеров, которые привели такого «несерьезного» прогера в компанию ;) тогда возможно они между собой объединятся, и не будут переманивать, дабы вместе не нести финансовые потери... и к этому я действительно готов привыкнуть...

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

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

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