Re[11]: Что такое "знание Linux" для бэкэнд программиста?
От: a7d3  
Дата: 23.11.20 22:19
Оценка:
Здравствуйте, SergeyIT, Вы писали:

SIT>Здравствуйте, a7d3, Вы писали:


A>>Тинейджера сперва в школе прессуют, потом в ВУЗик поступать приходится — знакомство с более-менее самостоятельной жизнью и долбанутые на голову преподы. Постоянно, что-то новое, постоянно взгляды и суждения пересматривать приходится.


SIT>Последнее время перестал студентов брать... жалко время тратить, ничего нового не хотят самостоятельно изучать. А ведь им 20+


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

Если брать вчерашних студентов-линуксойдов, которые с Gentoo/ArchLinux/Slackware сами возились, то
хоть разработчиками на С++ и Golang,
хоть тестировщиками на автоматизацию через Go, Python с виртуализацией/контейнеризацией,
хоть на Software Developer in Test.

Когда надо то и с Qt разберутся и C# .Net Core трогают и вопросы DBA применимо к PostgreSQL, MariaDB (MySQL который) или же NoSQL'ы с родимым MapReduce и нюансами распределённых систем, типа eventual consistency. Не только, что CAP-теорема во многом некорректно воспринимается, но и что lock-free на x86 отличается от RISC-ов (ARM'ы) и те же принципы релятивизма в распределённых системах всплывают.

А подход в том, что приходится играть с нормами общения — как на уровне воронки при найме, так и потом в командах проектных. Выходцы из пост-СССР, 1970-х годов рождения и старше, очень плохо следят за своим поведением. Наивно полагают, что могут говорить всё чё в голову пришло, никак себя не одёргивая.

Т.е. с атмосферой возни много. Объяснять приходится, что сеньор — это далеко не тот, кто работу делает лучше юниора, а тот, кто способен делать то, чего не могут юниоры. Старшие в командах хотят авторитета и уважения от молодых, но ведь оно на ровном месте не берётся, а появляется лишь по мере того, когда юниор сталкивается с такими вещами как false sharing в многопоточном коде или же на огребает проблем с нюансами strict aliasing. Важно, чтобы процессы разработки воспринимались не как сборище когда-то сложившихся ритуалов, а было видно и понятно зачем они, от чего защищают, как именно помогают.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.