@AmigoRRR Алексей, подход, в целом интересный и логичный. Он действительно помогает устранить некоторые "зазоры" между разными уровнями погружения. Однако же надо помнить и о том, что обратная сторона универсальности - это оверхед. В данном случае в устройство добавляется множество избыточных программных компонентов, которые не относятся напрямую к его работе. А вот повлиять на неё негативным образом - могут.
И в добавок - маленькая просьба. Не могли бы вы из уважения (хотя бы) к читателям не использовать ИИ в качестве "писателя"? Ладно, код было лень писать - понимаю. (Хотя по легенде его должен был школьник написать сам). Но речь о тексте, непосредственно. Во-первых, эти режущие речевые обороты уже надоели - они просто везде. Это сильно снижает желание читать. Во-вторых, статья могла бы быть значительно короче, если бы одни и те же мысли в ней не повторялись много раз (а это значит, что больше людей дочитали бы её до конца).
Не воспринимайте как жёсткую критику - с самим смыслом всё в порядке. Но уверен, что сами вы бы написали значительно лучше и интереснее!
Несколько лет думаю над обозначенной проблематикой. Но не со стороны HR, а как технический руководитель. В погоне за достижениями, показателями, метриками компании "оранжевого" типа получают очень посредственный результат. Типа "вам надо затрекать 8 часов, так я и затрекаю", а потом ещё часов 40 на рефакторинг через несколько недель/месяцев.
В тех случаях, когда целевым показателем являются такие вещи, как "ТТМ" (время выхода решения на рынок) мы имеем явный конфликт интересов. Большинству разработчиков немного интереснее создавать качественный продукт, нежели поделку. Даже если они этому не научены, они всё равно этого хотят. Поэтому во многих компаниях часто видят риски при приёме на работу очень опытных инженеров.
Во-первых, у них часто есть мнение как делать правильно. Во-вторых, их бывает трудно убедить сделать быстро вместо сделать хорошо.
Собственно, к чему я) Как говорит один умный товарищ (Тимур Шемсединов) - современному "рыночку" не нужны программисты (имеются в виду люди с хорошей базовой подготовкой). Ему нужны кодеры.
Хотел бы увидеть продолжение этой статьи, возможно у автора есть мысли на этот счёт. Как правильно и без игры на грани закрытия бизнеса произвести такую трансформацию на уровне компании? Ведь существующих "бирюзовых" компаний на всех не хватит :-)
@AmigoRRR Алексей, подход, в целом интересный и логичный. Он действительно помогает устранить некоторые "зазоры" между разными уровнями погружения. Однако же надо помнить и о том, что обратная сторона универсальности - это оверхед. В данном случае в устройство добавляется множество избыточных программных компонентов, которые не относятся напрямую к его работе. А вот повлиять на неё негативным образом - могут.
И в добавок - маленькая просьба. Не могли бы вы из уважения (хотя бы) к читателям не использовать ИИ в качестве "писателя"? Ладно, код было лень писать - понимаю. (Хотя по легенде его должен был школьник написать сам). Но речь о тексте, непосредственно. Во-первых, эти режущие речевые обороты уже надоели - они просто везде. Это сильно снижает желание читать. Во-вторых, статья могла бы быть значительно короче, если бы одни и те же мысли в ней не повторялись много раз (а это значит, что больше людей дочитали бы её до конца).
Не воспринимайте как жёсткую критику - с самим смыслом всё в порядке. Но уверен, что сами вы бы написали значительно лучше и интереснее!
@nletra Очень хорошая статья, спасибо.
Несколько лет думаю над обозначенной проблематикой. Но не со стороны HR, а как технический руководитель. В погоне за достижениями, показателями, метриками компании "оранжевого" типа получают очень посредственный результат. Типа "вам надо затрекать 8 часов, так я и затрекаю", а потом ещё часов 40 на рефакторинг через несколько недель/месяцев.
В тех случаях, когда целевым показателем являются такие вещи, как "ТТМ" (время выхода решения на рынок) мы имеем явный конфликт интересов. Большинству разработчиков немного интереснее создавать качественный продукт, нежели поделку. Даже если они этому не научены, они всё равно этого хотят. Поэтому во многих компаниях часто видят риски при приёме на работу очень опытных инженеров.
Во-первых, у них часто есть мнение как делать правильно. Во-вторых, их бывает трудно убедить сделать быстро вместо сделать хорошо.
Собственно, к чему я) Как говорит один умный товарищ (Тимур Шемсединов) - современному "рыночку" не нужны программисты (имеются в виду люди с хорошей базовой подготовкой). Ему нужны кодеры.
Хотел бы увидеть продолжение этой статьи, возможно у автора есть мысли на этот счёт. Как правильно и без игры на грани закрытия бизнеса произвести такую трансформацию на уровне компании? Ведь существующих "бирюзовых" компаний на всех не хватит :-)