Первые два пункта не о разработчике, последний про автоматизацию с использованием готовых инструментов. SDET в моём понимании делает инструменты для тестирования.

… вакансий больше, и прав и уважения и денег.

У каждого свои приоритеты. Если нет уважения, есть два варианта: либо не та компания, либо не успели завоевать авторитет.

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

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

Должен сказать, ручные тестировщики смотрятся сегодня чуднó.
…
Я бы вообще упразднил такую должность.

Exploratory testing в качестве основной задачи, но не для регрессии, согласен.

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

Самое печальное, у человека нет времени заниматься чем-то интересным и прокачивать навыки. Тут как в известной книге:

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

Есть такой момент. В идеале отлавливается на код-ревью.

На зарплату middle/senior разработчика.

Согласен. Есть примеры, когда компания обходится без QA. Культура разработки, тесты, CI/CD — если всё присутствует, это круто.

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

1. На инженерные вакансии в компании ± одинаковые рейты. В нашем случае предлагается зарплата middle/senior разработчика.
Трюк в том, что на эти условия всё равно не найти ковбоев, стреляющих из двух рук.

2. Большие компании могут себе позволить обучение, взращивание специалистов внутри. Мы ищем опытных и самостоятельных специалистов.
Предположим, уровень программирования у человека хромает, это наживное. Но что делать с первыми двумя пунктами? Мне не кажется сверх-требованием просить рассказать архитектуру проекта и как браузер запросы гоняет. Это базовые вещи.

один раз хватит человеку показать, как надо

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

А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.

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

По моим наблюдениям люди с 10+ годами опыта на собеседованиях отвечают хуже кандидатов 3+. Они «застывают» на каком-то этапе технической компетенции и как вы выразились, почивают на лаврах «незаменимых знатоков продукта».

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

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

Остановился на связке: RSS + триггер на IFTTT.com.
Плюсы:
— бесплатно
— легко настроить

Минусы:
— задержка смс-уведомлений (от 20 минут до часа).

Описал рецепт у себя в блоге.

Если это скриншот из Ubuntu, можно подключить PPA с пропатченными пакетами.

«Совы не те, кем они кажутся» :-)

Проверил на цепочке optipng, pngcrush, pngout:
Оригинальный размер файла 255757 байт. optipng (251012) → pngcrush (251546) → pngout -ks (238793)
Если же запустить pngout -ks для оригинального файла, получил 237902 Б. То есть, чуточку эффективнее последовательного применения.
Видимо, совместное использование требует хитрых комбинаций.

Конечно, последовательность такая же, как и в перечислении выше: optipng, pngcrush, pngout, advpng.

Я пробовал скармливать один файл поочерёдно разным приложениям. На итоговом уровне сжатия это не сказалось.

Сравнивал как-то на небольшой выборке png-файлов optipng, pngcrush, pngout, advpng. Последние две программы в среднем продемонстрировали лучшее сжатие.

Делал pdf-шпаргалку с клавиатурными сочетаниями bash. Страница на github'e.

Аналогичный сценарий использования. Можно и без .Net обойтись — code.google.com/p/transmisson-remote-gui/

Отличная замена gnome-do.

P. S. И главное, никакого Mono.

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

Gecko. Потому что в зависимостях gnome-web-photo → xulrunner.