Для отжига в городе поребриков надо — быть иностранным бизнесменом, к которому наведалась «krysha», напиться по этому поводу в клубе с незнакомыми девицами, поймать бомбилу и поехать в Невский район снимать деньги в банкомате на темной улице. fontanka.ru
Надо больше ада — A look at C++14: Papers Part I meetingcpp.com
Радует:
(pipeline::from(input_queue) |
bind(grep, "^Error") |
bind(vgrep, "test@example.com") |
bind(sed, "'s/^Error:.*Message: //") |
output_queue).run(&threadpool);
Тут один старик разнылся о том что индустрия скатывается в гавно blog.golodnyj.ru . Я думаю он не понял сути моего прошлого словоблудия про обычных программистов #2250187 , хотя ему простительно, он же руководитель, да и живет в деревне.
В деревне Иркутск хреново с программистами, но еще хуже с работой за вменяемые деньги. Потому выживают, либо ведущие программисты умеющие работать, либо джуны быстро растущие до ведущих. Шлак сливается в Новосибирск/Москву/СПБ, или идет работать в бургеркинг/связной/СТОшку.
Хотя и ведушие не долго терпят. Вот например у меня есть несколько друзей из Иркутска, с доходом более 4000-5000$ в месяц. Одни пашут на двух-трех работах круглосуточно и рискуют потерять семью. Кто-то напаривает руководство и в рабочее время фигачит чужой "опердень"(с). Бывает что хлебные Иркутские места требуют занятия всяким говном и отсиживанием часов. Но обычно у всякого человека наступает предел и он валит из "этой страны"(с) в Австралию например, или идет по пути "обычных программистов"(с).
Я знаю одного "серого кардинала" одного российского банка. Он не программист, но он программирует взаимодействие людей в офисах по всей стране. Приезжает на несколько месяцев в командировку и программирует поведение биороботов в филиале банка. И это работает, по крайней мере его еще не уволили, да и профит растет.
Кстати, айти индустрия тоже пробует себя в создании бироботов — "обычных программистов"(с). Но это работает только как наполнитель для кошачьего туалета, то есть для выкачивания дополнительных бюджетов у впечатлительных заказчиков. Ведь многие обосновывают затраты на проект по головам, а не по мифическому ТЗ. Да и работу по большей части делают ведущие специалисты.
Но я увлекся, я ведь в исходном посте #2250187 хотел высказать несколько мыслей, например:
* Мир не меняется, старики всегда ноют что "молодежь уже не та".
* Мир меняется, а старики порой застывают в прошлом.
* Работу делает не руководитель, а исполнитель.
* Только всецело понимая процесс можно достичь хорошего результата.
* Специализация по большей части зло, ибо винтики в машине после износа выбрасываются.
* Деньги это не цель работы, ибо работа не должна впустую сжигать нашу жизнь.
* И еще много всего, что мне уже лень писать.
А закончу я пожалуй процитировав одного моего коллегу — "Да у них менеджер упоротый, вечно что то хочет сделать, у него постоянно идеи какие-то, покоя от него нет, одним словом он в яндексе работал!".
Обычный программист.
Когда я искал работу в СПБ, то очень многие работодатели грозились дать мне в подчинение обычных программистов. А я реально не понимал, кто это такие, и мучил друзей вопросами. Но буквально недавно я понял, кто такой "обычный программист" ®.
Озарение пришло пару недель назад, когда ко мне подошел один программист из команды, и сказал, что я зря дополнительно занимаюсь аналитикой по проекту и обновлением серверов. По его мнению это работа специализированных людей, а наше дело писать код как нам скажут. Не сразу, но я понял его взгляд на мир и он меня смутил.
Индустрия меняется, люди начинают привыкать быть винтиками и специализироваться на конкретных областях. Тестировщик теперь должен тыкать в программу, программист кодировать, аналитик писать умные тексты, а менеджер проекта заниматься художественный рисованием гантограмм. И все счастливы, все при деле.
Но при всем при этом начинают появляется стеклянные перегородки между областями знаний. Многие перестают понимать, как из джуниор программиста стать ведущим. Люди перестают понимать зачем и как они должны работать. Теряются принципы, ради стабилизации производства.
Вот например одна история от моего друга про минимизацию рисков и стабилизацию производства. Один программист предложил использовать технологию X для проекта. После краткого обсуждения все согласились, что она более оптимальна чем технология Y. Но менеджер проекта сказал, что обычные программисты имеют опыт с технологий Y, потому все остается как есть. Программист уволился через месяц. В итоге проект был переписан на технологию X после того как были превышены сроки и заказчик чуть не расторг контракт.
Возможно я из нового поколения динозавров, что скоро вымрут. Я думаю похожие мысли о моем поколении были у начавших программировать за 10 лет до меня. У меня компьютер появился только в 2001 году, где я для фана осваивал ассемблер и писал Фреймворк на борланд паскаль 7. Но я был и остаюсь "школотой" для зубров спектрума и мсдос.
В итоге я не хочу быть обычным программистом. Моя цель делать все от меня зависящее для запуска проекта. И если сисадмины/тестировщики/руководители/аналитики/архитекторы не могут что-то сделать нормально, то я на время отвлекусь от своей черно-няшной среды разработки, и покажу им как сделать правильно.
Не люблю дебаг, трейсы больше радуют. Но иногда лень побеждает и devopsreactions.tumblr.com
p/s Тут еще всякого добра есть devopsreactions.tumblr.com
Обдумываю два способа организации процесса разработки кода, который работает и его можно поддерживать. Первый вариант это жестокое код ревью, чтобы в итоге "код был как бы написан одним человеком". Второй вариант использование искусственных ограничений в коде, чтобы написание "говна" не влияло на всю систему.
Первый вариант с ревью конечно выглядит соблазнительно. Всех заставлять жить по единым правилам сродни религии или армии. К тому же знаю пару контор где так принято. Но вот почему то подсознательно испытываю отвращение к подобной муштре. Развратила меня свобода. Да и не хочется быть карающим мудаком.
Второй вариант с использованием ограничений мне кажется более любопытным. По крайней мере я его не осознано начал применять с 2006 года. Результаты меня поразили. Жесткие грани системы были настолько прочны и сложны для быстрого восприятия. Что джуны и "обычные программисты" успешно пили новые фичи. Хотя иногда приходилось выходить за рамки.
Также второй вариант нравится мне тем, что люди могут расти в любую сторону. То есть находить в себе интересные для себя качества, и развивать их. Это мне кажется намного лучше железного кулака обучения. Да и приятно работать с умными и всесторонне развитыми людьми. Хотя не спорю что без дисциплины тут никуда.
На одной из встреч "питерских программистов" меня спросили как быть с программистами которые выходят за рамки? То есть берет бывший джун и лезет в жесткое ядро системы, а менеджер говорит, что надо поддержать парня, помочь ему. В принципе цель менеджера и бывшего джуна получить опытного программиста. Что для одного добавочная стоимость, а для другого небольшое повышение зарплаты. Но вот что делать со скатывание проекта в говно? Но оставлю вопрос без ответа, ибо все непросто.
К слову сказать я не против армейских традиций код ревью, и возможно я бы смог эффективно в этом жить. Также наверняка там ест разумные и всесторонне развитые люди. Но пока у меня есть выбор, я выбираю — "Liberté, Égalité, Fraternité".
Код liquibase адский ад, вот например логгер у них свой есть. Во первых накуя? Во вторых как так то?
private PrintStream err = System.err;
...
err.println(logLevel+" "+DateFormat.getDateTimeInstance(DateFormat.SHORT, DateFormat.SHORT).format(new Date())+ ":"+name + ": " + message);
...
e.printStackTrace(err);
Я считаю, что результирующие переменные в методах это хорошо. Такой код удобнее читать и поддерживать. Также это очень полезно при отладке и ведении трейс-логов. Например, на одном собеседовании я написал примерно так:
public MyObject findByValue(Collection<MyObject> myObjects, int value) {
Интервьюер тогда сразу зацепился за переменную result. И вот что делать с подобными спагетти-кодерами?
MyObject result = null;
for (MyObject myObject : myObjects) {
if (value == myObject.getValue()) {
result = myObject;
break;
}
}
return result;
}
Linux Way: Максимальное время разрешения проблемы не более 10 рабочих дней. В случае невозможности разрешения проблемы в указанный срок она признается неразрешимой. altlinux.ru