×Закрыть

Елена Денисенко — о карьере программиста и должности Team Lead в 19 лет

О карьере

Лена, как вы пришли в ИТ?

— С раннего детства окружающие замечали у меня неординарные способности в области математики. То, что другим давалось тяжело, не вызывало у меня никаких сложностей. Во втором классе школы я уверенно владела математической программой за 5 лет обучения. Стала интересоваться более сложными вещами, выходящими за рамки школьной программы. В это же время мне попалась на глаза книга по С++. Прочитав первые 3-4 главы, осознала, что это и есть то, чем мне будет интересно заниматься. В ней отмечалось, что некоторые операции гораздо легче программировать на С#.

По моей просьбе мне купили книгу по C#, объемом более 1000 страниц. Тогда я впервые столкнулась с трудностью понимания и изучения. Пришлось сильно потрудиться, проявить терпение, настойчивость. Как награда — через год я могла программировать достаточно сложные Web-приложения, в том числе знала SQL и front-end. Тогда я осознала, что способности не гарантируют успех, а самое важное — постоянно работать над собой. После этого мне и открылись двери в сферу IТ.

Во сколько лет начали работать?

— Мой неофициальный опыт коммерческого программирования начался в 10-летнем возрасте — разрабатывала сайты, отдельные компоненты, как back-end на С#, так и front-end. Заказчиками были мелкие фирмы и предприниматели.

Официальная профессиональная карьера началась в 15-летнем возрасте в должности Software Engineer в компании, оказывающей услуги в области авиации. К этому времени я уже закончила среднюю школу. Так получилось, что я была знакома с несколькими программистами, работавшими в этой компании. На тот момент у них не было специалиста с квалификацией в области безопасности серверных компонентов. Мне предложили работу, и я согласилась — хотела получать реальный опыт, мне нравилось программировать.

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

Как развивалась ваша ИТ-карьера?

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

Потом мне рассказали, что компании более охотно приглашают на собеседование кандидатов с профессиональной сертификацией. Я считаю, что сертификаты не в полной мере свидетельствуют о профессиональной подготовки специалиста, но для увеличения своих шансов на лучшее место работы в 16 лет я получила квалификацию Microsoft Certified Professional. В дальнейшем мне это очень помогло получить достойную работу. Мой совет молодым программистам — обязательно получать профессиональные сертификаты. Они способствуют позитивному восприятию работодателями.

В аутсорсинге я впервые начала работать в IBA Group в должности Software Engineer. Благодаря этой компании изучила стек Java технологий. Потом получила должность Senior Software Engineer в компании EPAM, работала с .NET, С#. Мне повезло с Team Lead-ом, я многому у него научилась.

Качественный скачок в профессиональном росте произошел, когда я работала одновременно в двух зарубежных небольших компаниях на связанных проектах в качестве Software Architect. Там получила опыт создания с нуля мощных алгоритмических конструкций, распределенных параллельных вычислений в облачных средах, Big Data, NoSQL.

Как вам удалось стать Team Lead в 19 лет?

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

Мои обязанности предусматривают полный спектр технических вопросов разработки ПО, от проектирования архитектуры до запуска программного продукта. Для меня это очень важно, так как позволяет мне совершенствоваться и как архитектору программных решений, и как менеджеру.

Процесс трудоустройства прошел очень быстро и гладко. Были собеседования и в компании, и с заказчиками. Меня никто не спрашивал про возраст. Вопросы касались только проверки профессиональной квалификации, опыта работы, личных качеств.

В то же время всегда находятся люди, утверждающие, что настоящим Senior разработчиком можно стать только после 30 лет, и так далее. Хочу сказать, в большинстве случаев они правы, но есть исключения, и не только я. Таких молодых людей достаточно много, а если бы система IТ-образования базировалась на современных методиках, было бы еще больше.

Каким видите свое дальнейшее профессиональное развитие?

— Мне ближе развитие в техническом направлении, поэтому в ближайшее время собираюсь сосредоточиться на работе в качестве Software Architect в областях Big Data, Data Analisys, Functional Programming, Cloud Computing.

О науке

Где вы учились? Приходилось ли совмещать учебу с работой?

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

По учебе проблем никогда не было, так как при изучении учебных предметов я не ограничивалась программой обучения университета. Всегда изучала дополнительные материалы, в частности курсы MIT и другие. В университете участвовала в научных конференциях, писала статьи. Пользуясь случаем, хочу поблагодарить руководство Гомельского государственного университета — ректора А. В. Рогачева , первого проректора С. А. Хахомова, декана математического факультета С. П. Жогаля, заведующих профильных кафедр и всех моих преподавателей за их помощь и поддержку.

Научные интересы развиваете?

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

Недавно я получила приглашение стать кандидатом на избрание в качестве члена Совета попечителей организации «F# Software Foundation» (FSSF), что стало приятной неожиданностью. Эта организация представляет собой сообщество признанных экспертов, которые определяют будущее развитие языка F#. Результат голосования будет известен в конце апреля — начале мая.

«Способности не гарантируют успех, а самое важное — постоянно работать над собой»

О работе

Как ладите с подчиненными, которые вдвое старше вас? Воспринимают ли они вас как начальницу? Возникают ли сложности?

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

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

А как реагируют заказчики компании? Доверяют вам как специалисту?

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

Были ли какие-то интересные случаи, связанные с вашим юным возрастом на высокой должности?

— Лично со мной не происходило ничего необычного. Но я могу рассказать интересный случай, произошедший с моей сестрой Натальей. Ей 16 лет, и она тоже работает в компании Luxoft в должности Software Engineer. В первый рабочий день она пришла в офис и попыталась пройти на свое рабочее место через пост охраны. Там ее остановил сотрудник службы охраны, спросил, куда она идет и какова её цель визита. Наташа ответила, что она здесь работает. Однако в ответ он посмеялся и долго её не пропускал. В итоге всё-таки пропустили :)

Как вы думаете, почему в IТ мало девушек?

— На самом деле в IТ их достаточно много. Девушки работают в сферах тестирования, бизнес-аналитики, разрабатывают документацию, работают в службах поддержки и т.д. Другое дело, что среди разработчиков и инженеров их небольшое количество.

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

В Западной Европе и Северной Америке ситуации иная, и там количество женщин в IТ постоянно растет. Я думаю, что и в Украине, и в Беларуси ситуация вскоре начнет меняться.

Нравится работать в мужском коллективе?

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

В чем заключается самая большая сложность в работе Team Lead?

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

Какие навыки важны, чтобы грамотно управлять командой?

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

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

О личном

Сейчас в ИТ-кругах популярна тема о переезде за границу. А вы об этом не задумываетесь?

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

Я убеждена, что именно IТ-отрасль наряду с аграрной способна кардинально повлиять на рост ВВП в стране, и это не 10-20%, а возможность роста в разы. Тогда никакого желания уезжать из Украины у программистов в принципе не возникнет.

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

Расскажите о книге, которая повлияла на вас больше всего.

— Наибольшее влияние оказала на меня книга по С++, про которую я упоминала. Я не прочла её полностью, но именно благодаря ей убедилась, что программирование — моё будущее. К сожалению, я не помню точного названия и автора. Эта книга ценна для меня не столько своим содержанием, сколько как источник интереса к профессии программиста.

Чем занимаетесь в свободное время? Есть хобби?

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

Что можете посоветовать молодым людям, желающим стать IТ-специалистами?

— Во-первых, не стоит идти в IТ, если тобой движет только желание много зарабатывать. Это достаточно сложная профессия, требующая постоянного обучения. Одни только деньги не смогут стать мотивирующим фактором.

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

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

LinkedIn

Лучшие комментарии пропустить

Я б статью озаглавил как-то так: «Компания Люксофт (NYSE:LXFT, с капитализацией $1.77B) научилась продавать тинейджеров по рейтам $30+/h»

23-річні сініори курять в стороні

Долго искал суть в этом интервью, но нашел:

Расскажите о книге, которая повлияла на вас больше всего.
— Наибольшее влияние оказала на меня книга по С++, про которую я упоминала. Я не прочла её полностью, но именно благодаря ей убедилась, что программирование — моё будущее. К сожалению, я не помню точного названия и автора. Эта книга ценна для меня не столько своим содержанием, сколько как источник интереса к профессии программиста.

Это шедевральная фраза, вот что отличает будущего начальника от исполнителя.

Прикольно Вы обосрали только что тех, кто добился чего-то в других областях, но в IT пришёл как раз годам к 40.

697 комментариев

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

Как-то херовастенько девочка выглядит для 19 лет :((

При начальствовании и программирования уже не до внешнего вида и здоровья.

очень даже неплохо выглядит.
просто видно что много работает на первой фотке

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

Про себя напишу, мне пример близок. Начал писать какой-то код в 14, к концу школы потрогал программируемые калькуляторы, бейсики, x86 asm, фортран на ЕС, паскаль на Мэре. Некоторыми моими (мягко скажем) «поделиями» люди пользуются с 1990 года по сегодня. Да только вот в студенчестве пришлось обеспечивать себя самостоятельно, а рынка труда программиста не было. Пришлось заниматься торговлей, для поддержания штанов, и все программирование сузилось до рамок институтских лаб и курсачей. Я бы дорого дал, чтобы с 2 курса пойти работать на работу по специальности, за деньги, на которые можно прожить.

По поводу героини материала мнения не имею.
С одной стороны, нет ни одной профессии, которой нельзя научиться за три года, до среднего уровня. На год посмотрите, 2016. С другой, все знают, что нужно для быстрой карьеры в корпоративной среде. Развитые социальные навыки.

Поки круті, досвідчені стерпери сіньори обговорюють сири, рекрутерів та де знайти живу бабу, школярка пише виступи для інфокю — www.infoq.com/...cord-net-machine-learning

Однозначно підтримую!

Мені завжди подобалось, як старші співробітники люблять ржати з молодих, які явно ефективніші за них, фразами типу «сініор в 23», «teen lead», «продають тінейджерів за 20$/годину» і т.д. Люди чомусь наївно думають, що сініорами стають за кількість років :) Як на мене, це чисто совковий стиль мислення і боязнь здорової конкуренції.

Не знаю, чи настільки вона насправді крута, як в цій статті сказано, але точно знаю, що молодь (20 — 23 роки) зараз на порядок ефективніша, ніж старші розробники мого віку (27+), що не може не тішити.

В чем эффективнее? В дотке?

Це вони ще не спіткалися з бандами чотирнадцятирічних досвідчених хакерів. :)

Як на мене, дівчина дуже молодець, хоча вже і не працює в Люксофт, але її успішна історія розвитку може стати предметом натхнень і мотивацій для інших програмістів: дівчат і хлопців.

молодець, хоча вже і не працює в Люксофт,
pbs.twimg.com/...media/BeLljDECMAAnTeJ.jpg

Особисто мене мотивують розумні дівчата!

А розумні хлопці — демотивують?

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

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

воевали же! деды... да и не было раньше так плохо... учились... образование... чтобы врачом быть... и другие престижные слова...

Боже, зачем?

Вообще тот факт что в люксофте работают такие специалисты и на такой должности должен мотивировать остальных программистов обходить компанию стороной.

Невероятно мотивирующая история ^__^
Молодец, Лена!

Боже, только не говорите мне, что у ребенка в 19 лет может быть что то больше, чем ветер в голове. Опыта жизеннного нет, не может она толково руководить людьми, так как не понимает их проблем.

что за снобизм?или это зависть?

Это всего-лишь была константация факта.

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

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

Не, возможно она очень уникальна и полностью отличается от 99.999% людей.

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

Ой, даладна!
«Взойдя на престол в возрасте 20 лет после гибели отца, македонского царя Филиппа II, Александр обезопасил северные рубежи Македонии и завершил подчинение Греции разгромом мятежного города Фивы.»

Что как-бы было не в 20-ом веке. И срок жизни тогда был меньше, и мы говорим про царскую персону в поколениях, которого с детства, с пелёнок готовили _править_ то есть, по сути быть тим-лидером.

и закончил свою жизнь в 33 погубив кучу людей.

о каком «жизненном опыте» речь? что это? в чем он исчисляется? «А жизненный опыт набивается шишками на лбу и временем»
каким шишками и при чем здесь время?

У всех по разному. У кого-то вполне физические шишки, у кого-то моральные.

Частенько спорил бы с Вами, но вот тут — соглашусь.

Cамой девочке — решпект за целеустремленность. Но вот правильно руководить — надо мудрость. А тут даже годы не всем помагают.

Есть старая поговорка.
Со старостью приходит мудрость, но часто старость приходит одна.

не то и не другое. Просто банальное непонимание того что человек может обладать умением решать поставленные задачи вне зависимости от возраста или опыта.
Иногда наоборот бывают непробиваемые старпсиньЁры с каким-то опытом постоянного подставляния одних и тех же костылей. И никакие уговоры почитать Макконнелла или Фаулера не помогают. Даже бенчмарки не действуют.
IT развивается и очень стремительно. Да, есть какие-то уже давно опробованые временем решения, но восновном, они в библиотеках. И чем моложе мозг тем легче ему подстроится под этот темп и ритм.

Ну почитай, к примеру, биографию Мечникова. Есть и другие примеры. Зачем завидовать или злорадствовать чужим успехам?! Лучше радоваться. Тем более все мы люди и все уникальны, даже если и не техлиды в 19.

у «ПХП кодеров» пуканы бомбят))) ИМХО те, кто больше обсирают других (от зависти конечно), совсем недалеко продвинулись в своей профессии.

неистово плюсую

Да пошло всё, пойду в супермаркет работать.

Я так понимаю, у них это семейное, и родители придумали саму идею сдавать школу и институт заранее. Мне просто интересно, насколько легко ей дались все эти предметы экстерном и жёстко ли спрашивали или она тупо сдала все эти литературы и географии на тройбан и сразу пошла в универ?

Ты не замечал, что девочкам в школе учиться легче, чем мальчикам. Среди них больше отличниц. да, есть вот такая разница между мужчинами и женщинами.
Школа-то что требует, чтобы ты получал хорошие оценки и все.
С другой стороны школьная программа безумна по своей раздутости и построению. Если выкинуть кучу мути и преподавать с учетом конкретного ученика, то типичные года можно сжать до нескольких (3-6) месяцев. Школьная программа сейчас — это ориентация на самого тупого и куча бредней от чиновников в министерствах и госнииобра.
Если родители плотно с ней занимались и решили, что экстерном лучше, то ничего удивительного здесь нет, кроме геморроя с чиновниками в случае экстерна.
Дальше ВУЗ выбран очень убогий, туда берут всех. Вот если бы какой ФизТех хотя бы — это да, уже посложнее.
Программить научить ребенка не сложно, главное суметь пробудить интерес и ему должно програмить больше нравиться, чем на компе поиграть или на велике покататься или с друзьями потусоваться.

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

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

знавал одну стундентку, училась в параллельной группе на отлично. Но говорила что учиться скучно. Откуда пятерки? Отвечала — привычка со школы.

Элон Маск недавно школу открыл для своих детей и детей сотрудников Теслы. Могу поспорить что дети оттуда выйдут на порядки продвинутые и приспособленные к жизни чем дети ходившие в государственные школы.

— Папа, а я смогу стать полковником?
— Конечно, сынок, поможем, и станешь полковником.
— Папа, я а смогу стать генералом?
— Конечно, сынок, поможем, и станешь генералом.
— Папа, я а смогу стать маршалом?
— Нет, сын, не сможешь. У маршала свои дети есть.

Кумовство в АйТи? Вроде этим пороком мы не страдаем.

в айти притонах почти всегда есть родственники топ руководства на самых разных дожностях

Папа, а шо лучче, ахвіцер чи камандір?

Смысл этой статьи в чем? Как за 9 лет стать тим лидом? Я понимаю если бы она за годик-два всех — как тузик тряпку)).

«...Бивни черных скал и пещер тупой оскал,
Человек среди гор ничтожно мал,
Треснула скала и лавина вниз пошла
И его как песчинку унесла...»
Ария «Бивни черных скал».

З.Ы. Люди поистине находят то, чем хотят заниматься, после того как входят в класс Раньте, если конечно не сопьются от лени и следовательно скуки.

Отличное интервью, прочитал с удовольствием. Лена молодец :)

#1 среди всех сотрудников Luxoft. Это я про рейтинг профиля Лены в LinkedIn.
Я выше 19-го подымался :)

#lenadroid с тебя бутылка Бейлиза за раскрутку :)
PS как раз на мой завтрашний деньрик.

А пока народ тут обсуждает, хорошо или плохо быть тимлидом в 19 лет, и куда катится наша отрасль, Лена спокойно выступает на зарубежной F# конференции ;)

www.hanselman.com/...BracketsBUILDAndMore.aspx
twitter.com/...status/588280590190960641

А где-то есть такой KPI — количество выступлений на международных конференциях? Пан Владислав Каськив помню тоже много выступал, на международных ...

Конечно, есть. Вы разве не знали?

Для тим-лида, на коммерческом проекте? нет, не знал. А компания — таки да, имеет и KPI, и PR, и мы тут помогаем, со статьей :)
По крайней мере, насчет эффективности выступлений пана Каськива мнения совпали :8)

Ничего не знаю по поводу Каськива. И вообще не понял, зачем вы его сюда притянули.
По поводу KPI — это был сарказм.

1. Удивило количество людей не умеющих радоваться успехам других. Хотелось бы знать чего они добились в свои годы и со своим стажем. Чье имя было в одном списке среди таких имен как Scott Wlaschin, Tomas Petricek или Mark Seemann?

2. Всем кто стремится работать в IT, и в частности программировать, стоит обратить внимание на ее совет:

Во-первых, не стоит идти в IТ, если тобой движет только желание много зарабатывать. Это достаточно сложная профессия, требующая постоянного обучения. Одни только деньги не смогут стать мотивирующим фактором.
Тот факт что в Украине в IT индустрию люди идут лишь ради денег я считаю негативным фактом.
Чье имя было в одном списке среди таких имен как Scott Wlaschin, Tomas Petricek или Mark Seemann?
Кто все эти люди?
2. Всем кто стремится работать в IT, и в частности программировать, стоит обратить внимание на ее совет:
Во-первых, не стоит идти в IТ, если тобой движет только желание много зарабатывать. Это достаточно сложная профессия, требующая постоянного обучения. Одни только деньги не смогут стать мотивирующим фактором.

Во-во, именно поэтому появляются 30-летние джуны и темы типа «Пацаны, с чего начать?», «Пацаны, какую книгу лучше прочитать, эту, или эту?», «Пацаны, посоветуйте курсы в Киеве по...».

Если бы люди могли питаться только через фотосинтез, то тогда никто не шел ради денег.

когда тогда? Если !

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

Зачем таких брать на работу?
Уровень же легко определить на собеседовании...

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

ну люксофту сильно не хватает специалистов в распознавании образов. Или Ява и К если первое сильно сложное.

Еще можно в нейронные сети и дип-лернинг поигратся — тоже требуется некоторое напряжение мозга.

напряжение мозга везде требуется.

даже в дотку или варкрафт..Только эти отделы мозга редко оплачиваются)

Только эти отделы мозга редко оплачиваются)
Награда за первое место составила около 6,6 миллиона долларов. Завоевавшая серебро CDEC получила около 2,8 миллиона долларов
lenta.ru/.../2015/08/09/dota2winners
Организаторы чемпионата объявили, что призовой фонд турнира составит 250 тысяч долларов
www.igromania.ru/..._250_tysyach_dollarov.htm
редко
Это гораздо сложнее выиграть такой чемпионат ,чем стать рядовым сыроедом..

Але якщо виграєш, то вже по крупному

В лотереи играете?

Не ризкую, всіх змінних незнаю, щоб там вигравати

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

а чемпионаты ето только отмазка зля задрота))) много знакомых мне розказывали про них чтоб я не мешал поиграть но ни на какие чемпионаты они и не собирались вовсе ))) єто задротство от недостатка игрушєк в детстве чтоли?

работал когдато на игровых лохолотерейках так могу сказать что за три года ни одного выигравшего
Ну я казав за державні лотереї, казино в принципі не признаю. Чи різниці нема хочете сказати?

а держава то хто? не путайте поняття держава і країна. держава то та структура яка беспощадно грабить населення і щось дає чучуть в замін щоб народ не взбунтувався ))) 20 ПДВ налог на багатих як в європі всі платять навіть бабульки в аптеці а що взамін маємо? глянь довкола. може дороги як в германії чи інфраструктуру як в франції? чи соціалку яка тільки в передвиборчих обіцянках зявляється час від часу)))) проводив експеримент, питав колег скільки вони податків платять, казали шо ніскільки процентів 90, решта казали шо всі))) а про пдв навіть ніхто незаікнувся так всі до нього привикли шо за податок не рахують )))

вони зовсім не державні це фікція гра слів. під назвою державні лотереї і спортивний покер, працюють ігрові автомати і казино ))) а мінти тіпа їх і не бачать поки їм регулярно заносять )))

На интернешнле слив был, инфа 100%
Да и вообще после TI3 и финала Нави-Альянс игры там кончились и начался бизнес)

игры там кончились и начался бизнес
Місце, в якому водяться гроші автоматично вже переходить в бізнес
Тот факт что в Украине в IT индустрию люди идут лишь ради денег я считаю негативным фактом.
А я считаю такое явление позитивным, во первых цепочка больше людей — больше проектов — больше спрос — больше верхняя планка зарплаты. Вот допустим в Индии они могут легко застаффить проект на 100-200 человек, займет это буквально пару дней, а в Украине кто так может?

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

Даешь не 70к айтишников, а 700к!

Удивило количество людей не умеющих радоваться успехам других. Хотелось бы знать чего они добились в свои годы и со своим стажем
А если скромность не позволяет хвалить себя?

Еще.. Читая, я вдруг понял, что в мои 10 лет самым технологичным устройством в доме, был черно-белый телевизор «Весна» ЛАМПОВЫЙ :))))

Впечатляет) И ответы хорошие :) Хочется спросить, что Лена думает об образовании в сфере IT. Не в том смысле, какое оно сейчас, а какое должно быть))

Я в 20 лет тоже был уже Team Lead, по большей части благодаря ошибкам высшего начальства. Наделал ошибок и столкнулся с проблемами рано и без ущерба своей карьере, получил ценный опыт. Не могу сказать, что это справедливо для компании, в которой я работал.
То что не было проблем — так они будут в любом случае, только может быть намного больнее, если подъем был без тернистостей.

Мне одному показалось подозрительным что она по сути более года нигде не работала? (Если верить профилю линкедина)

Знаете, в 19 лет многие еще вообще не начинали работать))

Например, в армии служили.

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

Не совсем понимаю, чего все так налетели? Конечно, её фотогеничность разбивает шаблоны о том, что умная не может быть красивой, но исключения бывают, да и посмотрите на современных детей, они в 2-3 года уже планшетами пользуются а к пяти годам уже будут программировать. Вполне допускаю, что девочка ботан и пока другие курили в подъезде она троллила на стековерфлоу.

когда первый накал от красивого личика прошел понял ... что достаточно дельная статья и таких детей в 14 лет называют вундеркиндами, чем человек удачно воспользовался :)

ну...судить вундеркинд или нет мы будем по референсам, может кто-то с доу работал с человеком и расскажет как есть на самом деле, думаю 19ти летний тимлид долежн быть известен в определённых кругах. Может Тёма что подскажет или его верная оруженоска.

они в 2-3 года уже планшетами пользуются а к пяти годам уже будут программировать
я не был бы так категоричен. Зачастую как раз детям дают планшеты что бы ими не заниматься, а заниматься своим делами. Нужно привить интерес к коду, а это не так просто.

Пишу в эпичном треде...

Мне одному показалось что это Гарри Поттер?

Нет) Реально похожа)

Ну это большой человек, и ей тогда уже 33 года было en.wikipedia.org/...aret_Hamilton_(scientist

Я подозревал. Но на вид совсем молода) Наверное просто фото такое.

Если женщина смотрит за собой, то до 40 ты с трудом определишь ее возраст.

Бедный любитель милфочек))

А че, ниче так девочка.

наверное, уже устала удалять пачки «Приветкакдела?»

Черт, я в 10 лет в луже палкой ковырялся. :) Про ПК тогда вообще единицы из взрослых слышали.

Судя по профилю, ты 1988-го года рождения. 10 лет тебе было в 1998-м году. В Украине уже интернет-провайдеры появились в то время. В какой норе ты жил, что там взрослые не слышали про ПК?

Ну, про «не слышали», думаю, что он преувеличил. Но мало у кого был ПК в 98 году. В стране очередной кризис был, не до ПК как-то.

Ой да ладно. ZX Spectrum у меня появился еще в 91-м кажись. Про всякие EC/IBM речь, понятно, даже не шла, но уж спектрум-то шагал по планете во всю.

ну Вам пощастило. Це не значить що у всіх були такі можливості. Перший комп в моєму оточенні зявився в 98му. Свій перший, я купив аж в 2000 чи 2001му). І це Львів, звісно не Київ, але і не райцентр.

я свой первый комп купил почти через год, как пошел работать после ВУЗа.
в 2001-м...
Дипломная работа была — составить программу, своего компа не было....

Pentium 100, кажется, с 14″ монитором в 95 стоил если я не ошибаюсь штуку баксов. «Потому что приличный комп всегда стоит штуку баксов. А 500 баксов это несколько неприлично.» :) .

Не видел еще пентиумов тогда. Насколько помню, тогда четверки продавались и за 2 штуки. И редко кто покупал. Пентиумы и другие как-то более массово начали покупать уже где-то с 98 года. 94-95 год, только первые четверки начали покупать (первые компьютеры в нашем привычном понимании), до этого были двойки, троек почти никто не видел, неудачная серия. И массово для дома покупали спектрумы.
А так, да, Павел лет на 10 ошибся. В 90-м единицы слышали и то скорее про спектрумы или какие-то электроника. А в 2000-м вещь была достотачно массовой и программистов уже было достаточно.
Хотя, конечно, компьютеры тогда были не настолько обязательными и вполне многие их не видели и даже не умели включать. В вакансиях на различные работы указывалось в требованиях «знание компьютера». Подразумевалось, что человек сможет включить и хоть как-то пользоваться мышкой в винде и набирать текст в ворде.

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

с 2000 баксов я видимо ошибся, с гривнями перепутал, давно было ) Так что вы правы, просто я их тогда еще не видел. Где-то через год их начали покупать.

Запомнилось объявление в московской газете «Поменяю Камаз на IBM PC/XT» в 94м. Не пересказываю — сам видел.

Я в 10 лет (1996 год) ещё не программировал, но игрался на Спектруме вовсю. У нас были и джойстики, и даже редкий дисковод (обычно все вспоминают магнитофоны, но у меня был дисковод и куча дискет с играми и программами, за несколько лет до этого переписанных папой с кассет)

Вот и я о чем. Ассемблер я еще на спектруме изучал, — в далеком 1991-м. А тут товарищ говорит что в 1998-м никто не слышал про компьютеры. Диво дивное.

Мужская часть рунета какая-то очень странная (спасибо, что есть женская часть, которая более адекватная). Все норовят перекрутить смысл фраз, чтобы рассказачать, как остальные неправы.
Написано черным по белому:

Про ПК тогда вообще единицы из взрослых слышали.
И ваша фраза:
товарищ говорит что в 1998-м никто не слышал про компьютеры.
Можете перечитать мою фразу пару раз. Поможет понять смысл фразы. Имелась ввиду Украина и мой город
Можете перечитать мою фразу пару раз. Поможет понять смысл фразы. Имелась ввиду Украина и мой город

И в чем проблема? Я лишь сказал что в той же самой Украине уже наблюдал несколько интернет-провайдеров, — и то что в Запорожье «слышали единицы» меня банально удивляет.

то тебе просто повезло, у меня во дворе у первого появился комп в 2003м, а с компом познакомился в 1996м у папы на работе, но как всегда бабла у родаков не было что бы купить цяцю((

Повезло в чем? В том что я пошел работать сразу после школы и там был ПК с интернетом?

у тебя был доступ к железу, чего не имели многие

Многим никто не запрещает купить/собрать ZX Spectrum или идти работать.

ага канешн, а то что в то время пожрать нечего было то никто не помнит?!

Ты девочка-истеричка? Иди работай — и жрать тебе будет, и все остальное.

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

Не было ничего, и тем не менее я месяц махал лопатой на археологических раскопках на Сиваше от местного краеведческого музея (1990 год, мне было 12 лет). Как раз заработанных денег хватило на чёрнобелый монитор-зубило для спектрума и на четверть необходимых микросхем для Ленинграда-2.
service4u.narod.ru/...es/zx/Leningrad-2-now.jpg

В общем было бы желание.

в 90м я только родился) к чему этот разговор? у кого то были возможности заработать, у кого то нет, когда мне было 12 лет я тоже искал подработку, первый компьютер получил в 13.

Тогда к чему разговор про отсутствие жрачки в 90-е?

P.S. В 2002 ZX Spectrum с монитором можно было купить со сдачи в магазине.

вы что не жили в 90-е? проблема в том что мои родители не могли себе позволить купить железо, в 2002м спектрум мне не нужен был уже. или мы из разных слоев населения, или из разных стран, так как эта проблема постигла не только меня. конечно у меня папа собирал комп сам, но до релиза не дошло, а потом и не зачем было

вы что не жили в 90-е? проблема в том что мои родители не могли себе позволить купить железо
В том то и дело, что жил, причём в одном из самых сильно депрессивных регионов. Конечно, денег ни на что не хватало, надо было много работать и ещё подрабатывать на 2-3 работах.

сейчас проблем вообще нет, согласен, хоть бутылки собирай на растбери

Raspberry. Rastaberry — это немного из другой оперы.

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

Все программеры на piton такие нервные?

Эээ, джентльмены, этот тип, кажется, хочет обидеть нас! Какой ещё рунет? Это Доу, уанет.

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

Скажем так, я живу не в супер ИТ развитом городе. А тогда так вообще )

У меня комп появился в 2004, но интернет появился в частном секторе позже.

В 10 лет (это было в 1990-м соответсвенно) я жил в закрытом военном городе — и даже там уже имел счастье познакомиться с ZX-Spectrum, сериями ЕС, СМ и МС. Всякие НГМД размером с небольшой дом и все прочие прелести советской электроники. А в 1998-м в Украине я работал на предприятии, где уже был Интернет по диал-апу. И было это в Полтаве — еще менее ИТ-развитый город, чем Запорожье.

бесполезная для меня информация

бесполезная для меня информация

Спасибо, это очень важное знание для всех нас.

У нас в конце 80-х ZX-Spectrum были только в компьютерных клубах) по бешеной цене 3 советских рубля за час..Дело не только в развитие IT- тогда компы были для большинства родителей- дорогой, ненужной роскошью:)

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

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

А нічого що їй тільки 19? Як для її віку вона й так занадто крута

Ну, целый тимлидер.
А ты? Всего какой-то програмер в бодишопе, еще небось и меньше ее зарабатываешь.

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

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

А вы ещё дома посидите, и вас уже и SE не будет устраивать. Вот были, мол, инженегры-прогромисты, и нормально! А то позаводили рюшечек не по-нашему ;-)

А что это такое

SE
? Оно мне надо?
? Оно мне надо?
Так отож, mon ami ;-)
И архитектов вам тоже не надо.

Не надо. Понимаю одно название должности: программист.

Так и хочется сказать, что всем по... Но не буду, я же вежливый.

Не всем, иначе срача этого бы не было или в много раз меньше.

техлид — толковый синьор

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

Точнее толковый и опытный в данном проекте программист.
нет, не в данном, а объективно толковый и много понимающий именно в программировании, не привязанный к предметной области

Программирование сильно разное и подходы разные. Вот тебе пример. Толковому программисту дали задачу спортировать код с матлаба в плюсы. Он утонул. Это кстати меня убедило, что тот кто разрабатывает алгоритм на R или матлабе или питоне должен сам портировать на плюсы те же.
Если ты не дока в безопасности, то ничего приличного не напишешь, будет дыра на дыре.
В том же вебе я нуль и если напишу что, то будет угребище жуткое.

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

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

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

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

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

Получается, техлид — это тот, кто умеет пользоваться гуглом.

ну вот задача, например, выбрать js фреймворк, их куча, у каждого из них свои плюсы и минусы, в гугле миллионы сравнений, какой брать? самый популярный и потом переделать, если не подойдет?

Я же написал, что в вебе ничего не знаю. Лучше когда выбирать будет тот, кто в js и вебе собаку съел.
Вот тебе другая задачка выбери либу для математики, что с матрицами хорошо работает и удобна. Я ответы сходу знаю, из-за опыта. Их 2, но выбор какой из них, уже исключительно вкусовщина.

Их 2, но выбор какой из них, уже исключительно вкусовщина.
А Intel MKL есть среди этих двух?

Нет. Точнее те либы могут использвать, как ее, так и ACML, так и LAPACK с BLAS.
Ладно, одна Eigen, вторая armadillo. Лично мне больше нравиться armadillo, но многие предпочитают Eigen.
Если ли не крутишься в области вычислений, то ты долго будешь их искать.

Лучше когда выбирать будет тот, кто в js и вебе собаку съел.
ок, заменяем веб на выбор sql vs nosql и какой именно, не обязательно понимать что-то в веде чтобы понять пример про выбор фреймворка
Вот тебе другая задачка выбери либу для математики, что с матрицами хорошо работает и удобна. Я ответы сходу знаю, из-за опыта.
я же не говорю что ты бестолковый, наверняка проработав долго с матлабом ты знаешь про него почти все, но техлидом это тебя не делает, ты просто знаешь непопулярную технологию, техлид же наоборот знает тучу популярных технологий, не на 100%, но выше среднего, плюс глубоко свою любимую область(и), от этого он типа ходячая экциклопедия, часто техлиды просто программистами работают да и все, не всем нравится чтобы к ним за советами ходили

Все хорошо, но я вполне и не раз выполнял эту работу техлида в своей области. И начальником был и архитектором. Вот почему и пишу, что все эти лейбочки фикция и зависят только от проекта.

ну так-то да, везде свой набор тайтлов и можно быть в одной конторе джуном, в другой синьором :)

Тайтл у меня на последней конторе был СНС.

Система национальных счетов?)

У папы или мамы спроси что такой СНС (с.н.с.)

низший менеджер))) чего только не выдумают чтоб оправдать своё сидение на попе ровно)

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

Откуда пошла байка о том, что тимлид это человек далёкий от технической части? В последние 10 лет моей работы большинство менеджеров и тимлидов были не только опытными управленцами, но и обладали развитыми техническими навыками. Мой прошлый босс — оч. умный чувак, сапер и девелопер, мой текущий босс — не только менеджер департамента, но и ведущий специалист, босс моего босса — бывший программист. Так что хватит петь эти пестни, в нормальных конторах тупых не делают тимлидами, а делают тех, кто и умный и общаться умеет.

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

обладали развитыми техническими навыками
бывший программист
они бросили профессию и пути назад уже нет

хочется быть менеджером — надо сразу идти в менеджеры

Так что хватит петь эти пестни, в нормальных конторах тупых не делают тимлидами, а делают тех, кто и умный и общаться умеет. 
в 90% контор тимлида нанимают готового, а не делают, а умный он или нет определяет часовое интервью, впрочем точно так же с любым наемным сотрудником, не неси бред

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

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

Как же я всё-таки скучаю здесь по простому доувскому хамству)) А то аж как то скучно стало с этими их заморскими хелов, хаваю и экскюзми.

P.S. Софт для нашего датацентра наговнокодила широкоизвестная в узких кругах компания из трёх букв. Думаю такой передовой девелопер как ты может смело написать в IBM и указать на промахи в их «говнокоде».

Цікаво те, що на foundation.fsharp.org/...oard_of_trustees_campaign дійсно є її ім’я. Але разом з нею у списку знаходяться організатори локальних F# груп, etc. Є ще Евеліна Габасова, зі (здається, хреститься) невеликим, але цікавим блогом і непорожнім GitHub: github.com/evelinag . А що в нашому випадку — незрозуміло. :(

та ладно тебе Серега) Я считаю, что девушка в ее возрасте употребляющая слова «монада» и «функциональное программирование» — крутая by default)

Так никто не спорит, просто непонятно почему такие мозги в Люксофте маринуются )

Ух, как много букв и желчи, похоже успехи этой девочки задели за живое :-)
Я тоже не особо верю в чудеса, но то что она работает в Люксофте и значится тимлидом уже кое-что значит. Возможно мы являемся свидетелями рождения нового таланта, вай нот?)
Хочу пожелать ей успехов и не комплексовать по поводу возраста и комментов лузеров ;)

Официальная профессиональная карьера началась в 15-летнем возрасте в должности Software Engineer в компании, оказывающей услуги в области авиации. ...
На тот момент у них не было специалиста с квалификацией в области безопасности серверных компонентов. Мне предложили работу, и я согласилась — хотела получать реальный опыт, мне нравилось программировать.

1. Почему 15 летний спец может программировать «серверные компоненты» в авиации, а 15-летних пилотов пассажирских лайнеров нет? Не справедливо! А в 19 лет — уже капитан экипажа!

2. Как можно быть «специалистом» не имея «реального опыта» в чем-то?

1. Почему 15 летний спец может программировать «серверные компоненты» в авиации, а 15-летних пилотов пассажирских лайнеров нет? Не справедливо! А в 19 лет — уже капитан экипажа!
Лучше 15 летний хирург.
2. Как можно быть «специалистом» не имея «реального опыта» в чем-то?
Это приходит с опытом %)

Про хирурга тоже думал вписать, но уж слишком тривиально было бы.

Ну да, коронарное шунтирование вы на кухне не сделаете, а для того что бы написать любую сложную фичу нужен только ноут, голова на плечах и желание.

И много времени и знаний. Что далеко ходить, напиши синтез речи (например украинской) или идентификацию диктора по голосу. Или что нетривиальное из визуальных образов. Или архиватор не хуже современных.
А так сайтик по быстрому слабать можно.
Очень немногие хирурги шунтирование делают, большинство же делает простые операции типа грыжи и вырезания аппендикса.

З.Ы. Вот что уже реально достало, так это уверенность многих программистов, что им нужен только ноут, а они сделают любую программу.

Суть в том что бы стать синиором в реалиях современного энтерпрайза не нужно знать хорошо математику или статисику, или быть экспертом в DC, или чем-то подобном, большая часть энтерпраза это пилить dao, заварачивать их в сервис слои, на которые навешены транзакции, и выплевывать это куда-то в UI через MVC/REST, или другим апликухам в качестве тех же soa/rmi/JMS/че угодно еще, при чем что бы понимать всю эту дрибедень можно всего-то 3-4 книжках прочитать, которые гуглятся за 15 минут.
В наших странах синьер это тот кто знает как работают ЯП и несколько фреймворков, + немного базы данных, и пофиг на опыт.

Так бы и написал выше.
А то я больше в других областях и там вечно, хер что сразу и просто получается. Пока что-то сделаешь задолбаешься с экспериментами и данными. То не так, это не так, а это вообще еще никто не знает как сделать или кто-то сделал, но блин за его статьи и язык там убить того хочется. Часто, чтобы понять, что он написал в статье и реализовать надо его еще предыдущие найти и те на которые ссылается и там разбираться и так пока статей 15 не поймешь хер сделаешь. И часто сидишь просто и тупишь, как понять то, что написано и реализовать максимально быстро и просто, или блин того хуже ночью только о теме сны (мозг выносит). А еще сделаешь и на твоих тестах, базе (в смысле корпус) работает, а другое подали — все жопа — ничего не работает правильно.
Как уже приводил пример синтез русской речи сделали за 2 года и человек 15 в сумме разных специальностей, но основывались на предудыщих разработках на 10 лет и добавили немного нового. Для одного человека или пары такие объемы работы просто не подъемны, особенно, если с нуля начинать. Там одних знаний лет 5-10 набирать надо минимум. Да можно и попроще, VAD напиши. До сих пор статьи пишут с разными подходами — работающего в общем случае алгоритма (хотя бы на уровне человека) до сих пор нет.

Ну да, только большинство современных проектов куда проще, обычно это банальные манипуляции с данным, расчеты, агрегации и все. Продуктовых проектов которые бы представляли бы собой новые не тривиальные концепции или реальную научную проблему единицы. В общем в реально жизни планка пониже, для формашлепства этого всего не нужно... С другой стороны эти банальные вещи приносят кому-то миллионы...
Ps Может поделитесь ссылками на интересные, понятные материалы или свой блог?

Своего блога нет. Не умею писать красиво. Кроме того то, что я делал уже устарело, о нем уже нет смысла рассказывать. Сейчас вообще переключился с речи, пытаюсь разобраться в визуальных образах. То же постоянно натыкаешься на сложности и непонятки, да даже с тем же opencv (до чего сырой продукт) постоянно в инете решения проблем искать приходится. Хорошие подборки литературы на forum.sources.ru есть и здесь dsp-book.narod.ru по речи и ЦОС.
Но вот, чтобы просто и понятно, таких не знаю. В этой области в любом случае основы ЦОС знать надо, а это уже не просто.
Еще азы можно почитать в лекциях Тони Робинсона от 98 года (svr-www.eng.cam.ac.uk/~ajr/SpeechAnalysis/.
Много чего из реализованных алгоритмов есть в RASTAMAT — если для своих экспериментов.
По идентификация французы возобновили пиление опенсурс проекта ALIZE. Там студенты какого-то их универа новейшие алгоритмы добавляют. Их в одиночку или малой группой не догнать (не говорю уже про коммерческие фирмы в этой области, тот же ЦРТ или кучу американских).
Да, миллионы не приносят эти продукты. Если бы бюджет ЦРТ не состоял на 60-70% из госзаказов давно их бы уже не было. Самая большая их продажа была единожды — поставка полной системы фоноучета в Мексику за $10M.

Синиор синиору рознь.

в реалиях современного энтерпрайза
Это в отношении обсуждаемого где?

Вы будете смеяться, но хирурги — это по сути такие же ремесленники как и программисты. Расскажу реальную историю. Когда я учился в медицинском, нам препод по факультетской хирургии с большим разочарованием рассказывал о том, как один школьник 10 класса успешно сделал операцию на щитовидной железе (чтобы было понятно, это довольно сложно, ибо она хорошо кровоснабжается и кровит сильно при операциях, плюс, там небольшой орган и удалять много нельзя — недостаточность будет). Причем, он не просто на крючках стоял, а был главным хирургом. Да, его учил папа хирург, да, оперировал под контролем. Но сам факт...

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

Но в медицину такого «спеца» все равно без образования никто не возьмет, а в ИТ все можно.
То просто вы все привыкли к такому ИТ (вернее к его тёмной стороне) и считаете что другого ИТ не существует.

Наоборот, это одна из самых светлых сторон ИТ)))

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

www.youtube.com/...O8&feature=youtu.be&t=26s

На этих фразах мой буллшитометер закоротило...

Если вы не понимаете смысл сказанного, это не значит, что там буллщит

Ну, я понимаю. Это всё равно буллшит.

Ну перескажите суть научного труда своими словами, раз «понимаете», что уж...

объясните мне, как можно вести разработку алгоритмического конструктора с помощью искусственного интеллекта? Это же всё равно что искать новый способ электрического соединения с помощью вольтметра — вещи близкие друг к другу, но совершенно но вольтметр тут особо не поможет.

С помощью достаточно мощного искусственного интеллекта можно делать всё...

Ага, как в истории про С++ за 21 день...

Это единственный вопрос по сути работы, который у меня есть. Для начала нужно узнать, что именно она вкладывает в понятие «масштабируемый алгоритмический конструктор» с использованием монад. А «искусственный интеллект» там вероятнее всего представлен в виде каких-то Machine Learning алгоритмов, supervised или unsupervised, с помощью которых и составляется алгоритм. Я за последнее время видел столько нестандартных применений ML, что уже ничему не удивляюсь :) Достаточно только посмотреть спектр курсовых задач по конволюционным сетям студентов Стэнфорда, выложенных в онлайне. Там даже обученная модель для игры в шахматы есть, причем с неплохими результатами, хотя 95% остальных применений — это обработка изображений. Просто ребята догадались представить шахматную доску в виде «картинки» 8×8 — и понеслась.

В общем, явного булщита в её теме исследования нет. Есть лишь вопрос, какие именно алгоритмы и для какой финальной задачи она использует. Из темы это неочевидно.

Хотя тут же есть специалисты, которые знают, что это буллщит даже до прояснения материала и прочтения самой работы...

Какое отношение имеет «масштабируемый алгоритмический конструктор» к функциональному программированию? При чём тут вообще монады? Она бы ещё написала «пишу искусственный интеллект с помощью циклов while».

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

Да не надо. Уже достаточно того, что в одном предложении упоминается искусственный интеллект и монады. Я уже сказал, на что это похоже.

Пардоньте, а с монадами что не так? :) Они по сути на что угодно неплохо ложатся.

Не могу согласиться. Цикл while — лишь один из строительных блоков, в то время как монады — абстракция над вычислениями. А какой программист не любит абстракции?)

И цикл — абстракция, и монада — строительный блок.

Извините, а вы специалист в области искусственного интеллекта? Уверены, что знаете, о чем идет речь в этой работе?

В общем, явного булщита в её теме исследования нет.
Это смотря что понимать под булшитом. Если бы «алгоритмический конструктор» появилось в печатной работе — 99.99% булшит, так как использование нестандартного неочевидного термина — очень плохой признак. Исключение одно — «вперше запропоновано...», но не думаю, что это тот случай. Но для устной речи это может быть допустимо, ведь все мы делаем ошибки.

Мне, напротив, очень понравилась ясность в ответах. Лаконично и грамотно.

Immutable data structures для функциональных языков давно реализовали в 90ых годах. Что такое алгоритмический конструктор? Каким образом она будет использовать монады? Это все что сказать, а давайте я буду функциональный анализ применять, что бы построить построить аппарат квантовой механики.

Вывод: троллинг высшего класса эта статья.

вот у меня такое же впечатление.

Вы серьезно думаете, что человек не в курсе за ваши монады?

Не пробовали сначала прояснить детали у автора работы, а потом уже делать выводы, тем более такие? Может, там действительно что-то интересное исследуется? А то получается как «Пастернака не читал, но осуждаю».

Да я вот пытался нагуглить, чем она занимается. Увы, не вышло.

Это научная работа в университете, вряд ли она пока опубликована. Надо у самой Елены спрашивать.

Пытаясь найти корни данной фразы нашел math.gsu.by/index.php/ru/vmpzav. Да прямо кладец талантов — в 30 лет стать завкафом может даже круче, чем в 19 — тимлидом.

навеяло :

Молодая, симпатичная девушка приходит в церковь, подходит к священнику. На ней ни макияжа, ни бижутерии, одежда консервативно-строгая. Потупив голову, спрашивает:
— Батюшка, а как вы понимаете концепцию протеирея Феофана о социально-патриархальном единении души человека с Господом Богом на основании его религиозных воззрений, высказанную для русской православной епархии в Париже?
Батюшка:
— Замуж, дура! Срочно замуж!!!

Обычный нормальный шовинизм на почве мракобесия. Аналогично, когда я здесь писал об информационном метаболизме и антропометрии.

Удачи тебе Лена во всем, ты одна из лучших инженеров, кого я лично знаю )

Ok, Google. Ну и что сидишь? «надобрать» ))

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

какие-то очень смешные клише

в унисон со статьей, не находите?

Руслан, когда бабло вернёшь? :D

Хаха, Люкс, что делаешь? Прекрати!

Ну а если серьезно, если это реальный персонаж — респект девочке за то, что умеет хорошо использовать мужской ресурс. Для меня это самая неубедительная история, о том как ребенок в 10 лет уже знал бэкэнд,фронтэнд, Sql и работал на иностранных заказчиках. Сейчас ей 19 а на гитхабе как будто еще та 10 летняя. Мне стыдно такой код показывать, даже если я джуниором бы был. Тех лид в 19)
время ох66тельных историй!

Она вполне может быть миддлом, я знаю парня в Люксе который миддл и в то же время тимлид.

Native Name: Денисенко Олена Олександрівна
Account: UBS
Position: Team Lead
From Luxoft Employees Directory
По теме: lol.

да сейчас кто угодно может быть мидлом

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

Скорее всего пошлятина у вас прочно засела в голове. Я имел ввиду способность девушки делегировать свои тех. задачи на ребят в коллективе. Или опять пошло, Вадим?

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

Никто никого не обср.л, умничка.

Слегка бомбануло:)
А вообще огромный респект.
P.S. Еще и фотки обрадовали;)

На мой взгляд, есть два качества, без которых невозможно эффективно управлять командой. Первое — высокая профессиональная компетентность Team Lead-а. Второе — уважение к каждому инженеру-программисту в команде.
— ну прям Лео из Путешествия в Страну Востока, Гессе. Пока такие люди есть — у нашей планеты есть шансы! А зубоскалить, искать соринки, завидовать и грустить — фу фу фу!

Я просто оставлю это здесь dou.ua/...icles/team-lead-position
А то мы начали забывать, как должен выглядеть Тим Лид....

Те люди,у которых бомбануло, как раз и не забыли.

Меня пугает один момент. Возможно героиня топика действительно гений и незаурядный инженер. НО. Большинство хавает материал as-is, не удосужившись закопаться в факты и происхождение персонажа, да еще и про «диарею», «горящие пуканы» и тд. выражаются.

Это я к тому, что мы еще что-то на вату гоним, что они хавают бред из сми, когда среди интеллигенции такое...

в багатьох почалася гостра діарея

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

Девушка молодец, Luxoft трижды молодцы — продали, продекламировали. Комментаторы — троли и завистники.

Люксофт ничего не продавал на самом деле. Тут была другая история.

Так может расскажите?
Вечер восхитительных историй в разгаре :)

Собственно я вышла на Лену через комментарий Димы всё тут же на ДОУ -
dou.ua/...these-children-it/#629737

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

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

Можна десь подивитись на її код, на github або bitbucket, щоб розвіяти сумніви у її геніальності і утерти ніс всім снобам тут?)

Guys, this is not even funny...

Commits:

fixing links
fixing typos
update README.md
Update about.html
update post
Added stylesheet
added related video
fixing english error :)

and the best one:
Dzisus, kurwa, ja pierdole! lenadroid authored on Nov 6, 2014

*facepalm*^2

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

Да не суть в назві комміту, а суть в тому шо коду там майже нема...
Достойне продовження:
www.youtube.com/watch?v=UzUUYHzTh7A
www.youtube.com/watch?v=khYWkgbuv9s
www.youtube.com/watch?v=2aE27G_PpoY

Вот блин, я слоупок. А нынче уже не принято линейкой меряться, как в старые времена? Теперь если нет 16 мегабайт кода на гитхабе, то не мужи программист?

Ми говорим не про заурядного програміста, а про кандидата у члени опікунської ради"F# Software Foundation"

Чтобы стать кандидатом в этот совет, нужно быть сильно публичной личностью или что?

Мені просто здавалось, що члени фундацій мов програмування мають мати якийсь прогуглюваний вклад в розвиток цієї мови програмування))). — Common sence

Как подсказывают из зала, коммит про kurwa смахивает на дефейс. — К.О.

Passionate Software Engineer. Perfectionist.

это у которого комментарии в коммитах:

fixing links
fixing typos
update README.md
Update about.html
update post
Added stylesheet
added related video
fixing english error :)
and the best one:
Dzisus, kurwa, ja pierdole! lenadroid authored on Nov 6, 2014

Покажите нам свой код, раз уж Вы “passionate about designing and crafting modern and efficient software using latest technologies”, чтобы мы тут все наконец поняли, к чему надо стремиться.

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

А если вы не вьехали в моё предыдущее сообщенько — поясню:
Как по мне — у перфекциониста не может быть таких сообщений в системе контроля версий, ибо нахер оно надо вообще тогда?

Давайте я намекну при помощи следующей параллели:

Как вы думаете, ходят ли настоящие перфекционисты у себя дома исключительно в смокингах и вечерних платьях?

Судя по вашему профилю — вроде ж взрослый человек, а пишете ерунду какую-то.

Не вижу смысла продолжать диалог в виду отсутствия конструктива и логики в ваших ответах.

На мой взгляд перфекционисты дома ходят в выглаженых, чистых домашних одеждах, а не в грязных, засаленых шмотках.

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

Мне кажется (перекрестился на всяк), что у Вас какие-то предрассудки касательно перфекционистов. А может Вы просто путаете их с педантами.

На мой взгляд перфекционисты ходят дома в любой удобной одежде, потому что она выполняет свою задачу perfectly. Если я художник-перфекционист, я могу ходить дома в одежде, заляпанной красками, потому что мне так удобнее. Если я программист-перфекционист, которому пришла идея по-быстрому реализовать свою идею в виде пет-проджекта, может даже исключительно в образовательных целях, то я использую VCS как многоуровневый save/undo, потому что больше мне в таком случае не нужно. Но это абсолютно не значит, что на работе я не буду придираться к тому, что у одной из кнопок в приложении смещение на пиксель больше, или, например, что я не буду давать по рукам за отсутствие отступов в коде после код-ревью.

К нам на проект пришел как то ui девелопер, рубаху на себе рвал, рассказывал какой перфекционист. В итоге оказалось что гонит обычный UI c обычными косяками, просто делает это в 3-4 раза дольше.

Я меня не лучше комит месаджи в бложике — github.com/....github.io/commits/master :)

мужчины занервничали :) ... ну хоть фотки не надо было.

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

Народ, досить себе порівнювати один з одним. Тим більше, ті кому за 25. У сучасної молоді купа можливостей для реалізації себе в ІТ, і ця чудова дівчина — красномовний доказ. Я впевнений що скоро напишуть про якогось 18-річного архітектора, а потім знову і знову. Це не привід критикувати себе чи заздрити.
P.S. У неї є хлопець?)))

P.S. У неї є хлопець?)))
хороший вопрос.
ИМХО столь ранний старт компенсируется оставанием в психоэмоциональном, гендерном, социальном развитии.
Очень хочу ошибаться

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

ага.
«Москва слезам не верит» — все смотрели?

А Роман Хміль відкриє дитсадок для майбутніх програмістів з держзамовленням?

Ребята, завидовать, это фу-фу-фу)
Ну а девушка — молодец, нам бы таких побольше!

Одновременно и мотивирует и демотивирует.

Теперь буду всем говорить, что у меня 20 лет опыта. Хеллоу ворлды на бейсике для Ориона писал еще в 6 или 7 лет.

А интересная компания Люксофт: и 19-летняя тим лидерша, и ее 16-летняя сестра софтваре инжинир. Интересно, а какая еще компания может похвастаться использованием детского труда в области разработки ПО и у какой компании самый минимальный возраст детворы?

Не так давно эксплуатация детского труда процветала.

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

Я в глобале в 17 лет начал, стажером.

через год я могла программировать достаточно сложные Web-приложения, в том числе знала SQL и front-end
НЕ ВЕРЮ!!! По-моему, это как Крамаров в «Джентельменах удачи»: — Пойду переводчиком — английский я знаю!

Чему тут не верить, в универе давно учился?
Сначала форсируют плюсы, лабы и прочее на других языках не принимают впринципе.
Затем на каких-то «распределённых системах» ставят задачу за неделю написать балансируемый бекенд на шарпе в не менее три узла, с внешним «кешированием» на веб сервисе (собственноручно написаным — в моём случае ASMX, некоторые WCF пользовали) и с кластеризированой базой. Так что за год можно и до достаточно сложных систем прийти

Похоже в самом деле Джунам здесь пора в резюме писать учебы в институте, как рабочий опыт, а еще и школьные поделки туда вносить.

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

Констатировать факт.

Так что за год можно и до достаточно сложных систем прийти
Система, которая пишется за год «в одно рыло» — НЕ сложная! Вообще ситуация классическая, но недоказуемая для молодежи. Понимание приходит с опытом. См. ru.wikipedia.org/..._знаю,_что_ничего_не_знаю

Да, давно знаком с этим принципом.
Но когда-то Андрей Аксёнов сказал что сложных задач нет
так может и сложных систем нет

очень мотивирующая статья, пойду неуч застрелюсь

Да ладно тебе. Знания не главное:

Расскажите о книге, которая повлияла на вас больше всего.

— Наибольшее влияние оказала на меня книга по С++, про которую я упоминала. Я не прочла её полностью, но именно благодаря ей убедилась, что программирование — моё будущее. К сожалению, я не помню точного названия и автора. Эта книга ценна для меня не столько своим содержанием, сколько как источник интереса к профессии программиста.

да и не в знаниях дело, всегда завидовал людям с мат складом ума)

Этот склад ума в жизни больше мешает, чем помогает. А в современном программировании потребность в знаниях математики мизерная. Посмотри по тем же вакансиям.
Обычно этим складом ума награждают людей, которые в эмоциональной части полные лохи. Они на все смотрят через призму рационального, а в жизни рационального очень мало. При определенных условиях и способностях могут получаться из них таких, как Борис Березовский.

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

Только на Джинне таких толпа, только вот вакансии для них нет. Большей части вакансии где математические знания не требуются.

я все не читал, скажите просто в какой компании она работает?

Technical Team Lead — Luxoft

А детства-то у нее, видимо, и не было

Девчонка ОК! Желаю успехов не только в карьере :)

Класно я вас этим фейком тролянул. Могу еще ее брата создать в linkedin
Какой набор патернов ему прописать? Нужное подчеркните.

— Architecture Patterns (Abstract Factory Pattern, Builder Pattern, Factory Method Pattern, Prototype Pattern, Singleton Pattern, Adapter Pattern, Bridge Pattern, Composite Pattern, Decorator Pattern, Facade Pattern, Flyweight Pattern, Proxy Pattern, Chain of Responsibility Pattern, Repository Pattern, Service Layer Pattern, Single Responsibility Pattern, Command Pattern, Open Session In View Pattern, MVC, SOLID, TDD, DDD, HDD, SDD and etc.);

Давай сеньор C++ в 15 и своя програмерская контора (поставь там что-тот типа СТО) в 18.

Думаете, всё-таки фейк? Профили вроде есть, фотки гуглятся где нужно.
Но интервью какое-то уж очень шаблонное...

Ви читали їх лінкдін? :)))

Вже глянув, якась тупа еклектика (це ж такі да, треба додуматися, GoF патерни перераховувати). Але людина з таким ім’ям точно є лідом на Люксофті, як мені повідомили знайомі люди звітам.

З іншого боку, в такому віці пишеш в CV усе, що коли-небудь колупав :-)

Single Responsibility Pattern все таки принцип а не паттерн, та и вообще чувство что повписывали для веса) А я уже почти поверил(

мож они в матрице. подключился — хопа загрузились патерны прямо в голову. и сразу мастер патернов :)

Так в том и дело что загрузились неправильно, ну никак нельзя назвать Single Responsibility паттерном, я по крайней мере не слышал такого выражения. Single Responsibility Principle слыхал, а паттерн нет. Архитекторам/тимлидам следует отличать все таки паттерны от принципов.

Вот тут обидно было. В свои 19 всё ещё middle

А каково тем, кто в 25 и Джун?

нафиг так жить? :(

В лодку и по Днепру.

А в 31 безработный джун? слабо ;)

у меня все хорошо с самооценкой так что лодка мне не светит ;)

Вы тоже в 10 начали «задротить»?

В 7 классе. Мне было интересно и разобрался с комплексными числами.
Потом, позже, когда отец из командировки из Москвы привез MK-51 на нем прогал что-то. Уже и не помню за давностью лет. А уже в 9 классе Гауcса для систем линейных уравнений и всякие теругольники Паскаля и т.п. программировал для EC-1022 на фортране — такие у нас в школе задачки были. Да информатики еще не было. Предмет назывался «Основы вычислительной математики».

А вообще, уверен, что большинство здесь «задротить» начало еще в классе 5-7. Девочки созревают на пару лет раньше, посему и «задротство» может проявиться раньше.

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

Извините, Вы что-то путаете. У меня в детстве тоже был микрокалькулятор МК-51, отец мне его купил в 90-ом году. Очень хороший калькулятор был, но он не программируемый!
ru.wikipedia.org/wiki/Электроника_МК-51
А вот позже, классе в 9-ом, у меня появился МК-61, вот он программируемый.
ru.wikipedia.org/wiki/Электроника_МК-61
Наверное его Вы и имели в виду, ну или его аналоги.
Я на нём тоже программировал простенькие задачки типа решения квадратных уравнений и т.п. Разбирался самостоятельно по прилагаемой к нему инструкции. Там было всего 105 программируемых «шагов» (кажется так они назывались) и 15 ячеек памяти, если не ошибаюсь. Тогда мне это было очень интересно! Оба этих калькулятора до сих пор у меня сохранились в рабочем состоянии дома у родителей.

А я такой (61) в диване нашел когда был в 8 класе. О компе тогда только мечтать мог. Раз в месяц ходил к маме на работу, чтобы поигравть в принц на 3.1 винде. Мечта была — писать игры. Но программировал только калькулятор ибо на комп денег небыло.

О, да-а, МК-61, первая самостоятельно написанная программа «Угадай число» — это у меня в детстве такой своеобразный Hello World был :), писал ее потом первой под каждый попадавшийся в руки комп...

Тоже где-то в 6-7 классе дело было

Вступать в клуб 27.

Значит все-таки тян нужны :)

Нормальний ріст, при тому мінімум 4 роботи за 4 роки. Молодь, міняйте роботи як можна частіше, це дає різноманітний досвід, не слухайте казки HR-ів про лояльність і що треба працювати в компанії мінімум 2-3 роки.

Ок, будем менять каждые пару месяцев.

www.youtube.com/watch?v=welujPURijE ведь тоже можно сказать что какой молодец, такая молодая и уже депутат.

uk.wikipedia.org/...лєва_Альона_Володимирівна в неї батько «директор Харківського лікеро-горілчаного заводу» тепер ясно, чому ляшко взяв її до себе))

Ну шо ж... Не только не фейк, но даже упоминалась здесь :)
Только имя по-белорусски www.linkedin.com/...profile/view?id=211264183
А вот и упоминание dou.ua/forums/topic/6383

23 летние синьйоры это прошлый век

In the middle of August 2012, Alena Dzenisenka joined EPAM team in Gomel as a senior software engineer. The fact would not be a remarkable one if it were not for one thing: at that time Alena just turned 17.

Интересно, это профессиональное? Во всём искать fake/not-fake.

Как говорил один персонаж «Левиафана» — я верю фактам.

Програмісти навіть коли переходять дорогу з одностороннім рухом, то оглядаються в обидві сторони ;)

І не лише програмісти, це умова для виживання на території України =)

Нет. Это необходимый навык для выживания во время информационной войны.

Именно так. Я же не только на ДОУ пишу и читаю.

молодец! А есть профиль на github?

по нулям, говорит о многом :)

Но, главное, профиль же есть.

«Joined on Apr 9, 2015» — активная разработка там может не вестись, у Microsoft/.NET могут быть свои аналоги

Joined on 9 Apr 2015 может есть еще один аккаунт о которым вы не в курсе?

Ни о чём не говорит в общем случае

О да:) уровень фронта мне стал понятен.

мені чомусь це більше сподобалось github.com/.../despair.js/js/despair.js . Особливо це:

Dzisus, kurwa, ja pierdole!
Видно, що дівчина польську знає))

Желаю Алене удачи и профессионального роста в той компании, которая станет (стала) ее вторым домом.

Одни только деньги не смогут стать мотивирующим фактором.
Если у тебя нет страсти и любви к тому, что ты делаешь ты ничего не добьешься, об этом многие забывают, особенно те, кто хотят быстро создать стартап, чтоб позже продать и жить в удовольствие.

Долго искал суть в этом интервью, но нашел:

Расскажите о книге, которая повлияла на вас больше всего.
— Наибольшее влияние оказала на меня книга по С++, про которую я упоминала. Я не прочла её полностью, но именно благодаря ей убедилась, что программирование — моё будущее. К сожалению, я не помню точного названия и автора. Эта книга ценна для меня не столько своим содержанием, сколько как источник интереса к профессии программиста.

Это шедевральная фраза, вот что отличает будущего начальника от исполнителя.

А мне вот это понравилось:

книга по С++, про которую я упоминала. Я не прочла её полностью
но именно благодаря ей убедилась, что программирование — моё будущее. К сожалению, я не помню точного названия и автора. Эта книга ценна для меня не столько своим содержанием, сколько как источник интереса к профессии программиста.
Кто читает книжки по С++, чтобы понять, как на нем можно программировать, а кто-то быстро понимает, какие же эти программисты странные и как их можно разводить.
У автора еще небось такая странная фамилия была что-то с мертвыми и страусами связано.

Вряд ли, если в книге уже упоминался C#

Расскажите о книге, которая повлияла на вас больше всего.
— Наибольшее влияние оказала на меня книга по С++, про которую я упоминала. Я не прочла её полностью, но именно благодаря ей убедилась, что программирование — моё будущее. К сожалению, я не помню точного названия и автора. Эта книга ценна для меня не столько своим содержанием, сколько как источник интереса к профессии программиста.

А теперь то, что она писала про эту книгу вначале:

В это же время мне попалась на глаза книга по С++. Прочитав первые 3-4 главы, осознала, что это и есть то, чем мне будет интересно заниматься. В ней отмечалось, что некоторые операции гораздо легче программировать на С#.

Вангую Шилдта или Джесса Либерти.

Во втором классе школы я уверенно владела математической программой за 5 лет обучения. Стала интересоваться более сложными вещами, выходящими за рамки школьной программы. В это же время мне попалась на глаза книга по С++. Прочитав первые 3-4 главы, осознала, что это и есть то, чем мне будет интересно заниматься.
А чего вы ожидали от девочки начальных классов? Что она прочтёт и начнёт программировать аки Торвальдс?

Угу :( Не полностью, не помню, но повлияла ... В свое время было бесподобное интервью Алексея Белика, так вот среди прочих перлов, на вопрос «Ваша любимая книга?» он морознул: «клубный журнал ФК Шахтер». При всем уважении к их талантам, принципиальной разницы ма.
А может стоило бы умненькой девочке почитать что-то из классики ... ну Библию хотя бы.
И мне очень хотелось бы видеть как она, как тим-лид, менеджит людей. Возможно я неправ, но по этому «К счастью, я никогда не испытывала сложностей в управлении командой», у меня сложилось впечатление, что ее мужики ей нехилую скидку на детство дают. Ау, тим-лиды! у всех никогда не было сложностей!? или мо’быть дело в том что «никогда» — это аж за полтора месяца!?.
Вопщем, успехов Елене. Но без обсчечеловеческого бекграунда и опыта преодоления трудностей ей предстоит сделать для себя еще много открытий.

Потому что это очень умная и древняя книга, на которой чуть менее, чем полностью основана наша и не только культура. И даже если вы воинствующий атеист, Библия-то причем.

Я не атеист, просто не люблю читать неинтересные книги. Библию открывал, Старый и Новый Завет открывал — не пошло. Boring.

И зря в притчах Соломона и Экклезиасте очень много полезного, особенно в части того, что человеки за 2000 практически не изменились.

Не говорите Юрию про

Экклезиаста
вы себе представляете, если он исповедь напишет, по мотивам Толстого или Экзюпери?))) Вон вверху есть «не читал — но хочет знать» dou.ua/...ars-old-team-lead/#690817 заметте какой прогресс по сравнению с «осуждаю» ещё каких-то 50 с малым лет назад))) Так что прав был Соломон «почти», но крошечные сдвижки есть, я в это верю! Ещё пару миллионов лет и люди будут вообще молодцы!)))

Что такое 2000 лет для эволюции? Так, миг..

За это время человек уже изобрел ядреную бомбу и интернет.

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

многие под библией понимают эту книгуВозможно именно её она и читала

А как же Ричи и Керниган?

Ознакомиться с основами, типа не убий, не укради, не лжесвидетельствуй ... процитировать при случае: «Всему свое время, и время всякой вещи под небом» ;) (но это уже из extended версии :)) )

Ау, тим-лиды! у всех никогда не было сложностей!
Лейбочка ничего не говорит о том, что человек делает. Я могу прилепить лейбочку, хоть Господь Бог, но им от этого не стану. Мне лейбочки приклеивали исключительно для заказчиков некоторых (ну вот нужно было им, чтобы в конторе было сеньоров не меньше N) или для местной бухгалтерии (в РБ есть какие-то нюансы).
А в реальности в одно м проекте, ты как разраб, в другом как тимлидер, в третьем как архитектор и т.д. Когда-то нужно и админством заняться, когда-то запустить процессы разработки.

З.Ы. Ну представь, как человек с таким жизненным опытом может руководить людьми. Тут хоть выпрыгни, но пока с разными людьми достаточно не пообщаешься, как по жизни, так и по работе, опыта не наберешься, нефига толком руководить не сможешь. Или руководство заключается в варианте «передаст» (делегирование).

Вы бы еще Коран и Тору посоветовали программистам читать))

Эх, а я вот понял, что программирование — моё будущее, благодаря Mortal Kombat. Очень помогает в работе, особенно лидом.

Виктор Федрыч, это Вы? Вы не только писатель, но и читатель!

Отлично, девушка полностью перекрыла темы аля «почему сеньйоры в 20 и ПМ в 19».

Просто великолепно :)

Даешь сеньора в 15 и ПМ в 12.

Даешь корочку архитектора в роддоме.

Это уж передергивание. Но, практически каждый ребенок может научиться програмить к 13 годам. Мой вон тоже в LabView адаптированной EV3 программирует в 11 лет (правда на предложение поучить какой С++ сказал: «Папа, иди в ... Я по тебе вижу к чему приводит программирование»).
Но надо понимать, что такой ребенок может напрограммировать и если 15 летние программисты в комерческих проектах становятся нормой, то это говорит только об уровне проектов конторы.

Ну и как не лайкнуть, где тут это сделать?

Один мой хороший друг здесь, в Украине, к 19 годам тоже добился схожих результатов.
Думаю, это прекрасно, что у нас в стране есть такие талантливые и трудолюбивые люди.

Елена, вы молодец! :)

Чтоб притормозить карьеры обоих?

нет, что бы продолжили поколение

Оу, спасибо Андрей =)
Елена, поздравляю!

Я неоднократно натыкалась на ее профиль в Линке, но и подумать не могла, что ей 19! О_о

Не хило ... не считая «неофициальный опыт коммерческого программирования [который] начался в 10-летнем возрасте», 5 мест работы за 5 лет. Ну и скилзы у неординарного человека неординарно представлены ... перечислить все арх.паттерны чтобы лишний раз не спрашивали — хорошая идея :)

Неожиданно. Еще и очень симпатичная )
Лена, удачи!

Попахивает сексизмом.

Сексизмом что угодно может попахивать, всё зависит от того в какую сторону нос повёрнут.

Особенно если нос не повернут в сторону защиты сексизма)

Вы сломали мне мозг — «защита сексизма». Спрошу у сестры что это такое — она как раз адвокат, и тоже очень симпатичная)

С булевой алгеброй не очень, да?

Сарказмом что угодно может попахивать, всё зависит от того в какую сторону нос повёрнут.

Точно! И я предпочитаю свой поворачивать в сторону сарказма а не сексизма — хотя каждый в праве делать свой выбор!

Сексизм из парт оф аур калчерал айдентити

Неординарный человек, поступивший в вуз в 15 лет и начавший официально работать программистом в том же возрасте, вполне способен к 19 годам стать и синьором (в понимании индустрии), и тимлидом. Приятно видеть, что такие ребята есть, и интересно будет посмотреть, чего Лена добъется к 25 годам :)

(в понимании индустрии)
Хорошая оговорка, ибо чтобы на том же С++ прилично писать и 5 лет мало. Я за 20 лет, всех нюансов плюсов не знаю.
чего Лена добъется к 25 годам :)
Интересне будет, чего к 50. А 25 такой же ребенок, как и в 19.

Совсем необязательно. Вполне может какой-нибудь успешный стартап сделать за 5-6 лет.
А к 50 годам даже многие середнячки успеха добиваются.

Ну, будем посмотреть. Это самый возраст для стартапов.
А к 50 ты уже обычно понимаешь, что в жизни всякое случается и даже Россия может напасть на Украину. И сегодня ты на коне, а завтра в дерьме, причем по причинам, не зависящим от тебя. А вообще об этом очень хорошо написано в Экклезиасте (поэтому в деталях объяснять не буду).
Лично я уже много раз в жизни был и на коне (в моем восприятии) и в дерьме.
Могу даже примеры привести из давнего прошлого. И 5$ получал и дворником работал в 90-х и $250 в 1995 в месяц, когда разрабатывали идентификацию диктора в НИИ (и даже сделали и обогнали мир, как сильно позже понял на 5 лет где-то). Согласись, $250 в месяц в 95 — это можно считать успехом, а работу дворником — неуспехом.

ну так вы ж наверно и не гений ?

Конечно нет. Обычный средний человек.

Неординарный человек, поступивший в вуз в 15 лет и начавший официально работать программистом в том же возрасте, вполне способен к 19 годам стать и синьором (в понимании индустрии), и тимлидом. Приятно видеть, что такие ребята есть, и интересно будет посмотреть, чего Лена добъется к 25 годам :)
хотелось бы надеяться, что в 40 лет, сидя в одиночестве на кухне собственной квартиры в клубном доме она не скажет : «а нахрен мне все это было нужно...»

Думаю, она сама как-нибудь с этим разберется. Не нужно никого обижать.

никто никого не обижает.

Вечер занимательной психологии от специалиста по Oracle.

а нахрен мне все это было нужно..
в одиночестве на кухне собственной квартиры в клубном доме
собственной квартиры в клубном доме
в клубном доме
В квартире больше чем за пару лимонов особо не груститься.
В квартире больше чем за пару лимонов особо не груститься.
WAT? То-то большая часть суперзвезд в депрессии и/или на тяжелой наркоте, а кто-то и кончает жизнь самоубийством. Прямо образцы счастья. Что за подростоквые представления?
Прямо образцы счастья. Что за подростоквые представления?
Это у тебя подростковые представления, ты походу мир только из монитора/тв виидшь, этих суперзвезд в мире всего пару тысяч и единицы из них ведут подобный образ жизни.
В то время как миллионы людей в разных странах мира ведут скучную, серую жизнь и едва сводят концы с концами.

p.s. У меня все хорошо, не жалуюсь.

Ты что сказать-то хотел? Что людям, живущим в бедности — грустно? Так и богатым грустно. Причем тут вообще то, что ты написал?

У меня все хорошо, не жалуюсь.
I could not care less.
P.S. Подростковые представления — это думать, что деньги ведут к счастью. Особенно большие.

Деньги это необходимый компонент счастья в современном мире. Пусть и не всем достаточно для счастья только денег.
Но если денег нет — нет и счастья.

Если бы ты написал это, вместо

В квартире больше чем за пару лимонов особо не груститься.
то и спорить было бы не с чем. Ты же написал то, что людям в очень дорогих квартирах редко бывает грустно. Это и есть подростковые представления.
Ты же написал то, что людям в очень дорогих квартирах редко бывает грустно. Это и есть подростковые представления
В том то и дело что нет) Я сужу по людям которых я лично знаю, а ты по суперзвездам.

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

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

Тревожно это все... Про Нику Турбину слыхали?

Слышал, конечно. Есть много и положительных примеров. По-моему, неправильно проводить подобные аналогии, Лена же будет читать всё это.

Будет знать, чего остерегаться.

Так все-таки Алёна или Елена?

И все-таки, Федор!

Я б статью озаглавил как-то так: «Компания Люксофт (NYSE:LXFT, с капитализацией $1.77B) научилась продавать тинейджеров по рейтам $30+/h»

Можно было опустить информацию о работе именно в Luxoft, а то выходит явный product placement

Но начала же она не с Люкса, вот:

Официальная профессиональная карьера началась в 15-летнем возрасте в должности Software Engineer в компании, оказывающей услуги в области авиации. К этому времени я уже закончила среднюю школу. Так получилось, что я была знакома с несколькими программистами, работавшими в этой компании. На тот момент у них не было специалиста с квалификацией в области безопасности серверных компонентов.

Обеспечивала некой конторе в области авиации безопасность серверных компонент.

Видимо, не сумела стать там Тим Лидом в 15 лет. Уходила вместе с сестрой

Мне вот интеренее в какой конторе она безопасность обеспечивала. Очень надеюсь, что не для БелАвиа. Из Минска толком ничем больше не вылетишь.

Вроде как написано «БелАвионика», если профиль на Линкедин правильный

Ви сильно недооцінюєте Luxoft. Таких тінейджерів по $60+/h.

если бы я её не знал до этого интервью, то согласился бы с вами, а так — люксофт тут не при чём, если человек талант, то с одной или другой конторой он выбьется в люди

Лена — молодец! Сейчас в топике ее 40 летние джуниоры и прочие великовозрастные неудачники начнут стебать.

>Team Lead
Все вы тимлиды такие. Злые :(

Злые :(
Ага, Yegor зубами себе тимлидство выгрызал, судя по его каменту и суровой аватарке))

Прикольно Вы обосрали только что тех, кто добился чего-то в других областях, но в IT пришёл как раз годам к 40.

дети они ж злые.
их считают добрыми и милыми потому что к ним испытывают теплые чувства.

кстати, вангую что стебаться то будут как раз не 40летние, а дети чуть за 20.

Очевидно, что Егор имел в виду другой тип людей :)

То ли дело обосрать тех, кто не добился. Их-то можно, верно?)

Конечно можно — естественный отбор.

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

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

Просто пока молодой, кажется что еще все впереди и ты сможешь добиться всего, главное поднапрячься. В возрасте уже осознаешь, что тот, кто писал Экклезиаст был умницей. А в старости уже просто тихонько доживаешь свой век.

Такое к несчастью (или к счастью) нежизнеспособно. Спарта в пример.
Я об этом и говорил.
И даже сострадание с толеранстностью
Не уверен. Для многих людей эмпатия и сострадание — продукт интеллектуального труда, как и уважения.
Просто пока молодой, кажется что еще все впереди и ты сможешь добиться всего, главное поднапрячься.
Я вот, вроде бы, молодой, а так не кажется. Что-то со мной не так, видать.
А вообще, меня просто раздражает формулировка «чего-то добился». Она просто дурацкая. Поэтому я и начал этот тред.

А что ее стебать. Она умница. Очень чутко прочуствовала фишку и на коне. Молодец.
Кроме того, ее интервью говорит много о том, что знания как таковые в аутсорсе, особенно для карьерного роста не нужны совсем и только мешают. По сути девушка очень хорошо умеет разводить лохов, коими мы тут в большинстве и являемся. Особенно старперы со своими устаревшими взглядами на знания и умения.

По-моему, только что воспламенилось кресло, на котором вы сидите

В общем-то да. Каждый раз думаешь, что местному программингу падать больше некуда, но каждый раз стучат снизу. И понимаешь, каким был придурком с советским патриотическим воспитанием и в 90-е не свалил по примеру всех знакомых евреев.

Вы знаете много ребят, которые экстерном закончили школу и поступили в вуз в 15? Может, всё-таки предположить, что мы имеем дело с талантливым человеком, а не очередным примером идиотизма нашего аутсорсинга? Да и потом, пусть о степени её профессионализма и соответствия занимаемой роли в команде судят её коллеги.

Экстерном закончить школы — это одно. А руководить людьми — это совсем другое. Для руководства людьми в первую очередь нужен жизненный опыт, который, к несчатью набирается только обычным брутфорсом. Я не раз был начальником и знаю, что это за работа. Именно поэтому и категорически сейчас отказываюсь от такой работы — очень устаю от нее.
Я бы не удивился, если бы она была талантливым програмером, но ее слова про С++ полностью разрушают эту идилию.
Кстати, если про гомельский речь, то последнее время он прославился посадками, ну а про уровень этих местечковых ВУЗов и говорить неохота. В РБ есть только 2 относительно приличных БГУ и МРТИ (БГУИР нынче). И эти приличные капитально сливают многим московским и питерским и возможно киевским некоторым. Я уже не говорю про зарубежные.

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

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

А меня как раз её тимлидство в 19 не смущает. Она же не менеджер отдела на 50 человек, команда может быть и небольшая, и вполне молодая. И вообще лидами обычно ставят того, кто берёт на себя ответственность за результат и имеет хотя бы какие-то лидерские качества, а это относится скорее к личным качествам человека, а не опыту.

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

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

Не вижу, откуда из её слов про С++ книжку можно сделать подобный вывод, и не понимаю, почему все доколупались до этой цитаты. Девочка в младших классах открыла книгу по программированию, почитала, даже что-то поняла, хотя и на запомнила автора. Тут что, кружок гениев-самоучек, которые в младших классах уже уверенно программировали на плюсах?

Смотреть надо на факты, а они таковы — в 10 лет уже начала программировать что-то несложное, причем на заказ, в 15 лет устроилась на официальную работу, и уже очень скоро перешла в крупную компанию. Если это не свидетельство таланта в программировании, то я уж и не знаю, что тогда.

Толком ничего не знал и не умел, но как-то справились сообща.
Вот об этом и речь. Как-то, где-то, кое-как..

So what? Проект был сделан более чем успешно, все технические проблемы решены, набрались полезного опыта. Или если в роли тимлида не синьор, то это не комильфо?

Тимлид — это всего лишь роль в команде. Не надо путать её с должностью.

В люксе это должность.

Это уже менеджерская ветка или еще техническая?

Т.е. выше синьора?

А нет, напутал. Менеджерская, у моего знакомого тайтл — Team Leader/Senior .Net Developer

Team Leader/Senior .Net Developer
это не должно, а сплошное чсв делегированное фирмой, чтобы не повышать зп :) долго проработал в качестве Team Leader — уже давно не Senior .Net Developer, был Senior .Net Developer получил внезапно должность Team Leader — очень фиговый Team Leader

ага, a может тим лидом быть даже Middle QA. =/

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

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

Я попытался сделать вывод из его поста.

На меня повесили небольшой кусок проекта и команду на первом месте работы меньше, чем через полгода после начала работы джуном. Толком ничего не знал и не умел, но как-то справились сообща.
Проект был сделан более чем успешно, все технические проблемы решены, набрались полезного опыта.
И другого
Когда в 19 лет я был джуном, моим лидом на проекте для EA Mobile был мой одногодка. И ничего, справлялся.

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

Тем более, что опыт тимлидства у каждого тимлида когда-то бывает в первый раз. У кого-то он в 19 лет, у кого-то в 23, у кого-то — в 30. А у кого-то — никогда, что поделать, нет у него внутренних качеств для этого. И если человек справился с этой ролью, значит, ему незря её доверили.

на основании двух кейсов
А сколько надо? Или ты предлагаешь сделать мне репрезентативную выборку и провести исследование?

Я, кстати, вроде не говорил, что у чувака из кейса № 2 мало опыта. Или немало — это минимум 15 лет?

Когда в 19 лет я был джуном, моим лидом на проекте для EA Mobile был мой одногодка. И ничего, справлялся.

Когда в 19 лет я был джуном, моим лидом на проекте для EA Mobile был мой одногодка. И ничего, справлялся.

Вот и получается, что после 35 на помоечку.

Можно помидорчики начать выращивать.

Кому ты нафиг нужен в баристах, там не меньше народа на одну вакансию, чем в программинге.

В 10 лет кодить на заказ? Are u kidding me?

Все вопросы к Елене:

— Во сколько лет начали работать?
— Мой неофициальный опыт коммерческого программирования начался в 10-летнем возрасте — разрабатывала сайты, отдельные компоненты, как back-end на С#, так и front-end. Заказчиками были мелкие фирмы и предприниматели.

Тут на форуме кто-то шутил по поводу, если завести ребенка в 20 лет, то через 10 лет можно будет уже сажать за несложный фротенд.

-почему не готов сайт?
-мы с машей и катей играли в дочки-матери, простите, дядя
-я дам меньше конфет
-я буду плакать! ;(
-ну мы же договаривались на сегодня
-все я обиделась, я с тобой не разговариваю!

Как правило такие люди — интроверты, а то и аутисты вовсе. Нестыковочка-с.

Знаю минимум одного такого чувака. Крайне незауряден и социально активен. В комментах на ДОУ он тоже появляется временами, но пальцем тыкать не буду, конечно.

В любом правиле есть исключения.

Ну я закончил школу и поступил в ВУЗ в 15. И тимлидом в 19 не стал, так что это не показатель.

Я где-то написал, что каждый, кто поступил в вуз в 15, должен стать тимлидом в 19?

Вы знаете много ребят, которые экстерном закончили школу и поступили в вуз в 15? Может, всё-таки предположить, что мы имеем дело с талантливым человеком
Звучит как будто закончить школу и поступить в ВУЗ в 15 — это талант, который намекает. Хотя тот же Галуа два раза не поступал в Политехническую школу, в 17 и 18 лет, но это не делает его менее талантливым.
Я имел в виду как раз это.
И да, разве тимлид — это талант, а не тайтл?
Да и потом, пусть о степени её профессионализма и соответствия занимаемой роли в команде судят её коллеги.
Ну а вот тут — полностью соглашусь.
Звучит как будто закончить школу и поступить в ВУЗ в 15 — это талант, который намекает.
Я прямо даже не знаю :) Как минимум, это большая редкость, которая свидетельствует либо о неординарности ребенка, либо является следствием внешних факторов (переезды, стремление родителей, и т.д.). Хотя, конечно, медаль на межнаре — это существенно бОльший намёк на талант. В вашем случае как было?
И да, разве тимлид — это талант, а не тайтл?
В данном случае я не подразумеваю какой-то особый «талант». Скорее, неординарность, которая может помочь человеку быстрее найти себя в жизни или достичь особых высот. А может и не помочь. Тут как с динозавром, никогда нельзя знать наверняка :)
В вашем случае как было?
Мне тупо было скучно в 1-м классе (люди, не понимающие, что 1+1=2 и все такое), и меня экстерном перевели во второй. Хотя если бы не был таким ленивым, мог бы и в 3-й сразу же, благо там не было ничего сложного. Ну и плюс — отсутствие 4-го класса. Вот и получилось, что закончил школу/поступил в ВУЗ в 15 (и ужасный почерк как результат отсутствия уроков каллиграфии как бонус :) ).
Скорее, неординарность
Обычно, для достижения каких-то результатов нужно просто-напросто вджобывать усиленно (если ты, конечно, не гений, придумавший свой гугл, там добавляется еще и гениальность, но см. п.1). Ну или связи, что, к счастью, в айти-сфере играет гораздо меньшую роль (ну или я чего-то не знаю).
А можно просто сидеть на попе, работать работу, и довольствоваться тем, что уже есть :)

Мне тоже было скучно в 1м классе (пошел с 6-ти). Пока остальные учились читать по слогам, я сидел и читал Трех мушкетеров :) Жаль, что никто из учителей не предложил перевести на класс выше.

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

В Украине действует программа Росток, там скучать не приходиться, скорее наоборот.

Вы знаете много ребят, которые экстерном закончили школу и поступили в вуз в 15?
Я встречал в своей жизни четверых, двое из которых даже закончили школу раньше. Все четверо стали программерами, да, хорошими, но ... они далеки от тех, кого называют fucking great developer. Для себя же я отметил, что fucking great developer != genius. В большинстве случаев fucking great developer заканчивали школу между 3 и 4.

А по поводу таланта, быстрый поиск показал, что протагонист топика пишет о себе в разных местах разное. Например на одном сайте она Software Architect, на другом Team Lead, причём талант тут играет самое последнее значение. Безаговорочно соглашусь с нашим «пришлым белорусом» Виктором %), что опыт играет самую важную роль. Только через 5-6 лет находясь в коммерческей разработке я понял, что меня не устраивает архитектура ни одного созданного мной и другими людьми продукта над которыми я работал. Я начал заниматься портированием приложений с одной платформы на другую, на что я потратил ещё 10 лет своей жизни, изучил досканально тысячи чужих продуктов и понял, что хорошая архитектура приложения на все случаи жизни — это далеко не всё, что мне нужно. Возвращаясь из opensource в коммерческую разработку я понял что мне не хватало — угадывать желания заказчика, знать заранее в какую сторону отнесёт заказчика и прорабатывать архитектуру только с учётом понимания того, что движет заказчиком. Ведь заказчик не оценит красоту кода и величие архитектуры, он оценит только то, что любое его пожелание выполняется за константное время и ему не говорят «упс, а тут нам надо все переписать с нуля». И спустя следующие 5 лет я только лишь приблизился к тому, чтобы угадывать основные направления пожеланий заказчиков. Скажу только что моя профессиональная карьера началась даже раньше, чем у героини топика. Примеряя сейчас разные шапочки, я могу сказать, что могу вполне быть архитектором, техлидом, но не тимлидом, мне банально не хватает опыта в том, чтобы ответственным за teamwork и team building. Некоторые шаги и действия моего нынешнего тимлида я просто конспектирую на будущее, чтобы в дальнейшем проанализировать и сделать правильные выводы. На нынешней работе я впервые за многие года почувствовал себя зелёным и неопытным, а значит есть чему учиться дальше.

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

Обычно, психология и воспитание заставляют людей поступать иначе. Эго. Программист стремится быть главнее заказчика, диктовать ему условия. И разрывается между тем, как угадать или навязать ему свое видение. Поэтому возникает диллема. Как следать один лишний шаг и как бы этот шаг совпал в будущем с тем, что захочет заказчик. Было бы круто, заказчик сказал бы какой ты молодец...

А ларчик открывается просто: не угадывать и не делать никакой отсебятины. Тогда и проблемы нет

It really depends. YAGNI — хороший принцип, когда он не касается архитектурных решений. Отлично работает в стартапах, где быстрая проверка идеи и time to market важнее результата, да и сам результат обычно не слишком сложен. Плохо работает в сложных решениях, где стоимость архитектурной недоработки сейчас станет слишком дорогой потом. Кроме того, YAGNI очень любят девелоперы, не желающие или не умеющие планировать что-то наперед. Сейчас мы быстро что-нибудь бездумно нахерячим, а потом будем разбираться, что там еще планируется сделать. А потом клиент платит за бесконечные переделки, ведь мы не подумали сразу.

Поэтому YAGNI — точно такая же НЕ серебряная пуля, как и всё остальное. Это своеобразная другая крайность big upfront design. А крайности редко когда бывают хороши.

Чем минималистичнее и проще архитектура, тем легче ее потом расширять.

Что такое минималистичная архитектура? Только давайте не абстрактными понятиями.

Минимальное количество интерфейсов и минимальный их размер, минимальное количество связей, минимальный код достаточный, чтобы запрограммировать требования. Правило простое, чем меньше, тем лучше.
Например, функция на 300 строк уже не минимальная, нужно ее разбить на функции чтобы влазили примерно в страницу экрана.
В общем случае расказать про все нельзя, но, например, для сущности, что должна обрабатывать некий поток данных, достаточно Get-Set-Config и Process. Всё.

Кто ж в здравом уме будет против подобного подхода? :) Борьба со сложностью в различных её проявлениях — это основной challenge создания программных продуктов. Вот только все стараются следовать данному подходу, а потом всё равно — бабах! — и надо рефакторить, потому что сложность и технический долг всё равно накапливаются, как энтропия, в любом коде.

Пишут же многие, а потом рефакторят.
Лично я пришел к простому выводу, кода должно быть меньше, интерфесов меньше и сами они меньше. Если можно вообще не писать что-то, то лучше не писать. В общем всего поменьше.
Даже в самом коде, если можно что-то написать в одну короткую строчку, то лучше так и написать, чем городить ифы с циклами.
А и да с виртуальностью туда же, если можно без нее, то лучше без нее.
То есть основное правило — писать код должно быть лень и писать, только тогда, когда по другому никак.

С одной стороны — согласен. Если можно что-то не писать — это писать не нужно. Если какой-то код можно удалить то его удалить нужно. С другой стороны злоупотребление этим подходом приводит к тому что многие разработчики описывают только HapyPath Case и забивают на обработку ошибок, типа её ведь можно не писать — и так ведь работает... Потому стоит помнить что не всё что кажется что можно не писать действительно можно не писать. Ещё есть хорошая статья по этому поводу.

Ну тут как всегда «заставь дурака богу молиться — он себе лоб разобьет».

А если кода вообще нет — то вообще идеал, нирвана!
К сожалению в реальной жизне не видел задач, которые требуют 0 строчек кода для решения.

Да. Это идеал. В реальной же жизни идеального нет, отсуда и код приходится писать.

Улыбнуло. Если коротоко — сложность нельзя уменьшить. Можно по разному декомпозировать, но если задача сложная, то сложность никуда не денется. Если решение задачи требует 300 линий кода, то от разбияния этих линий по методам задача не станет менее сложной — станет больше методов.

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

300 линий кода, то от разбияния этих линий по методам задача не станет менее сложной — станет больше методов.
Станет. Разбираться в коде будет проще и сложность понизится.
Мы же говорим о обычно-человеческом восприятии понятия сложность. Или давай определение, его сначала обсудим, а потом уже мерять будем.
Во-первых, мы пока не умеем измерять сложность постановки задачи, кроме метода экспертной оценки.
Если вы не умеете, то рекомендую научиться. Хотя возможно мы по разному трактуем термин «сложность».
Станет. Разбираться в коде будет проще и сложность понизится.
Разбиение метода на 5 других методом «абы побить» только увеличит сложность. Грамотное же разбиение, которое поможет «потом проще разобраться» требует усилий и опыта(зачастую в разы больших чем требуется на сапорте) на правильное выделение сущностей, абстракцций, их композицию и т.д. — вот она сложность, осталась. Просто затраты на борьбу со сложностью видоизменились.
Если вы не умеете, то рекомендую научиться.
Ну так объясни. Пока же выглядит так, что ты сам сел в лужу, но признаться в этом не хочешь.
Разбиение метода на 5 других методом «абы побить» только увеличит сложность.
А не абы нельзя?

А прочитать следующее предложение в посту шаманы не позволяют? Но мне не сложно, я скопипастю.

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

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

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

Определени объективной сложности в студию. Тогда и говорить о ней будем. Пока же речь мы ведем только про субъективную.

Вот оцени, что сложнее, алгоритм идентификации диктора по голосу или слежение за несколькими объектами на видео?

Определени объективной сложности в студию. Тогда и говорить о ней будем. Пока же речь мы ведем только про субъективную.
Например можно мерять количеством типов бизнес сущностей и взаимосвязей между ними.

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

Я когда-то пытался разбираться в этом вопросе, потом забил ибо в этой области — оценка сложности пока практически 0 в мире. И это с теорией.
А если практику привести. Вводя интерфес, вместо прямого использования библиотеки некой мы повышаем сложность или понижаем? С точки зрения субъктивной сложности можем понижать. В твоем случае же добавили 2 связи и сущность => повысили.
А как изветсно все наши измышления и теоретические построения долны подтверждаться практикой, иначе это просто фантастическая теория и все.

У вас очевидно проблемы со чтением. Вы понимаете словосочетание, сори за капс, БИЗНЕС СУЩНОСТЬ и ее отличие от девелоперских сущностей?

Я вообще не понимаю этого термина, пытаюсь угадать, что ты имеешь под ним в виду?
Ну и пример для определения сложности я уже подкинул.

В общем случае расказать про все нельзя, но, например, для сущности, что должна обрабатывать некий поток данных, достаточно Get-Set-Config и Process. Всё.

И как это согласуется с

Например, функция на 300 строк уже не минимальная, нужно ее разбить на функции чтобы влазили примерно в страницу экрана.

если Process не влезет из-за сложности задачи в страницу экрана, и даже в 300 строк?

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

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

я вот наоборот считаю, что любое место которое можно не делать нужно не делать, любое место, которое можно упростить нужно упростить, лбюбой ненужный кусочек кода нужно удалить, именно так можно избавится от технического долга, и не взрывать мозг программистам сложными лагаси кусками и заделами на будущее, будет солид будет возможность доработать любой кусок к существующей системе, но закладываться что солида где-то не будет и переработка будет дорогой и сложной это разработка через страдания, зачем страдать? жизнь и так боль :)

SOLID, конечно, работает, но он не совсем про архитектуру. Если вы в начале разработки неверно проработали (или вообще забили) на performance requirements, и в результате выбрали хранилище данных, которое вам никогда не даст нужной производительности, то цена этой ошибки будет намного дороже, чем если бы вы провели нужный анализ upfront.

А структуру вашего кода для максимальной гибкости вы делаете по умолчанию. И вот тут уже SOLID. Хотя любители KISS и YAGNI и тут вам расскажут, что вы своим SRP чересчур всё усложняете, и «вам это не понадобится» ;)

Когда возникнет проблема с хранилищем, выберете другое хранилище. Вы же его не пишете, верно? Тогда попробуйте прикинуть время, необходимое на переезд. Тут два варианта: или небольшое, по сравнению со временем на проект, либо большое, потому что код хреново написан и завязан на работу только с этим хранилищем.

Если второе, то как раз будет самое время поправить код.

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

может быть. Но вообще, я к тому говорю, что даже в случае завязки на хранилище конец света не случится, придется код порефакторить и развязать. Если кто пробовал, то на такие вещи времени уходит совсем немного. Гораздо больше нервов и времени уходит на планирование наперед.

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

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

Да, и еще непонятно, что мешает подумать о скорости выполнения вашего кода в процессе его написания и сразу же написать хорошо, чтобы не исправлять и перетестировать всё потом? В чём прикол?

Кнут запрещает. Авторитет в оптимизациях.

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

Ну потому что когда вы угадываете по участкам кода, что будет быстрее, работать и приводите к своим представлениям, вы стремитесь к ЛОКАЛЬНОМУ максимуму оптимизации. Цементируя при этом код.
А когда код простой и уже написан, и вы замеряете слабые места и оптимизируете в порядке от самых узких мест и дальше, вы ближе к глобальному максимуму.

Я говорю о оптимизациях совсем другого уровня, чем приведены у Кнута. Похоже, для вас оптимизация — это исключительно перевод кода x * 2 в x << 2. Если у вас запрос вынимает из базы данных только одну страницу данных, которую нужно отобразить, а не запрашивать всё содержимое таблицы, чтобы потом провести необходимые фильтры и пейджинг в памяти — это оптимизация или нет? Нужно ли программисту задумываться о таких простейших вещах в процессе написания кода? Конечно, да.

Если же думать наперед об оптимизации, вы получаете на выходе не только плохой код с т.з. ясности, легкости поддержки. Но и еще ацки тормознутый код, который уже нельзя оптимизировать.
Простота и читабельность кода vs. его расширяемость либо скорость — это всегда tradeoff. Пассаж по поводу «ацки тормознутого кода» я не понял. Если он оптимизирован, тогда почему же он «ацки тормознут»?
Пассаж по поводу «ацки тормознутого кода» я не понял. Если он оптимизирован, тогда почему же он «ацки тормознут»?

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

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

Зачем задумываться об оптимальности? Только о простоте. Если вы будете принимать во внимание, что код будет дальше многократно меняться, читаться, переписываться, то не делайте лишних движений. В данном случае лишние движения — это выгрузка в память и написание собственного кода для фильтров. Чем в запрос к базе данных добавить WHERE и возможно ORDER BY

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

Не всегда. Да, очень часто PolyglotPersistence есть очень хорошим решением, но не менее часто это — никому не нужный оверхед

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

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

Хочу прояснить свою позицию по поводу YAGNI. YAGNI — это хорошо, когда в меру и не используется как отмазка для банального нежелания думать или анализировать и управлять рисками.

Мой опыт говорит обратное. По ягни разработка идет в разы быстрее и освободится время на подбор хранилища 10 раз. А вот проекты с планированием в лучшем случае в два раза больше забирают времени, чем планируется изначально. Это если завершаются вообще.

Окей, я понял вашу позицию. Если спланированные проекты забирают в 2 раза больше времени, чем неспланированные (а что мерять-то вообще, если и плана-то нет?), то у меня больше нет вопросов :)

Если спланированные проекты забирают в 2 раза больше времени, чем неспланированные

Нет, раз 6-10. Я говорю, что в два раза спланированные проекты в лучшем случае занимают больше, чем планировали. Т.е. проект на полгода просчитали, в лучшем случае через год можно ждать, и это еще удача.

Это я не стебусь, опыт у меня такой.

А неспланированные занимают ровно столько, сколько занимают. Потому что это же программирование, тут всё сложно, rocket science прямо. Я понял идею :)

А неспланированные занимают ровно столько, сколько занимают
Нет :)
Неспланированные поэтому и неспланированные, потому что их точно не оценивали и не планировали. Время может быть любое. Но фокус в том, что если вы скажете просто на глаз на проект 2 месяца, то это время гораздо вероятнее сойдется, может быть меньше, больше. Чем если проект распланировали по водопаду, этот же, и выбрали полгода. Это такая магия, зачем-то люди планируют, а время никогда не сходится. Проще уже монеты подбрасывать.

Планирование != водопад. Странно, что приходится это писать.

По поводу планирования — клиенты, как правило, хотят знать, когда они получат заказанный товар, и план работ, чтобы отслеживать прогресс. Хотя бы приблизительно. И проектные менеджеры тоже хотят. Только программисты не хотят, это ж какую отвественность надо на себя взвалить! :)

Планирование != водопад.
Это меня поставило в тупик )
Скажем так, водопад — это крайний случай управления проектами на основе планирования. Можно разрабатывать вообще без плана и без фаз и итераций — противоположный случай. И есть разные варианты между ними. Например, заказчик может наблюдать за процессом на основе сданных требований, а проектные менеджеры не планируют конец проекта, а делают считают количество выполненных требований, количество появляющихся, время выполнения требований и проводят оценку, экстраполируя графики. Тогда и следить можно за процессом. И предсказать как-то, когда проект завершится и не планировать завершение.

МакКоннел бьется в истерике. Кен Швабер нервно курит в туалете. Профессоры SEI(поголовно!) написали заявление об увольнении по причине профнепригодности. Это все после того как им дали прочитать эту ветку. Ведь все же так просто — выдать естимейт на глаз и проект

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

Планирование может быть сильно разное. Недаром сейчас аджайл подхды во многих конторах.

Вы наверное невнимательно прочитали пост на который я ответил. Там предлагается вообще не планировать — типо так лучше для всех.

Мне кажется, что здесь начинается спор о том, кто что хотел сказать и не четско выразился. Просто планирование сильно разное. ИМожно пытаться спланировать весь проект в виде Гантт диаграмы и потом убедиться, что не угадали будущего. Можно спланировать вехи. Можно вообще планировать только на 2 недели вперед и смотреть дальше по тому, что необходимо. В последнем случае можно сказать, что плана как бы и нет. Есть реакция на запросы пользователей — заказчика.

Вы явно научились только писАть. Хорошо, я таки процитирую Вам исходный пост:

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

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

Как в анекдоте:
— Как нужно определять время на проект?
— Спросить у программиста, умножить это время на два и добавить две недели.
— А две недели почему?
— Вот за те две недели в конце, программист и сделает проект.

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

Интернет и литература полны гениями, не только Макконелом. Кента Бека почитайте.

Не представляете — читал и Кента Бека. Приведите пожалуйста цитату, где он рекомендует эстимировать «на глазок»?

А это рекомендация от меня. Вы тут не можете спорить, я же указал: это мой личный опыт.

Вообще, прием так себе, представлять, что за вами незримое большинство, а я ничего из себя не представляющий одиночка с ДОУ.
Речь тут зашла сначала о ягни, а потом о его применимости и перешла в русло, планирование vs гибкая разработка. И две крайности есть: водопад и разработка вообще без планирования.

Если брать Кента Бека, то например в книге «Экстремальное программирование» целые главы описывают, как разрабатывать без плана, или что то же самое, все время изменять планы (корректировать). Так что мне не интересно доказывать очевидное, выискивая фразу, где он говорит, что надо эстимировать «на глазок».

как разрабатывать без плана, или что то же самое, все время изменять планы (корректировать).
Это не тоже самое. Банально потому что, чтобы корректировать план, необходимо этот план иметь.
Таким образом ты легким движением руки взял и обьединил 2 совершенно разных понятия: гибкое планирование и отсутсвие планирования. Ну и дальше тебя понесло.
Это не тоже самое.
Если план все время меняется на другой, то что такое тогда план? Или хотя бы сроки? Вчера мы планировали закончить через 10 дней, сегодня план поменялся, теперь через 15, маршрут оказался длиннее.

Хотя, можно планом считать метаплан, в котором одна задача: менять планы ))

Скорее, там подразумевается, что есть цель, а план (маршрут) ее достижения меняется при любом событии. Еще метафору приводит, мол выстреливает в любую сторону, а далее полет пули корректируется.

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

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

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

Что автоматически приводит к отсутсвию прогнозируемости. Прямой путь к завалу проекта.

Вы не путаете прогнозируемость и успешное окончание? Если вы не знаете дату окончания проекта, из этого не следует что ее нет. Так же как если бы я потерял документы и не было даты рожнения — это не значило бы, что я не рождался.

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

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

Так думают обычно менеджеры: наличие дат создает иллюзию контроля. А без дат, естественно, ничего не делается.

Вы не путаете прогнозируемость и успешное окончание?
Прогнозируемость есть главный фактор успешности проекта. Даже если планы менялись по ходу дела.
Если вы не знаете дату окончания проекта, из этого не следует что ее нет. Так же как если бы я потерял документы и не было даты рожнения — это не значило бы, что я не рождался.
Если мы говорим о полделках или опен сорце — то я соглашусь. Это как eventual consistency. Но в бизнес проектах, у которых есть бюджет, необходимо знать что и когда будет сделано. Представьте себе что вы наняли рабочих для ремонта, а на вопрос о сроках они отвечают — «если вы не занете дату окончания ремонта, это не значит что ее нет». Будете с ними связываться?
А можно пытаться требовать даты, чтобы была прогнозируемость. Но это уже шашечки. Ездить можно без них.
Осталось только понять, кто будет оплачивать этот банкет.
Так думают обычно менеджеры: наличие дат создает иллюзию контроля. А без дат, естественно, ничего не делается.
Наверное есть и такие менеджеры. Но есть и другие, которые говорят что наличие дат и выкатывание функционала согласно этим датам дает возможность планировать бюджет, фичи, рекламные компании и т.д.
Осталось только понять, кто будет оплачивать этот банкет.
Тот кто понимает такой подход. Ведь условие в таком подходе — сэкономить деньги, сделать в максимально сжатые сроки. Т.е. исходя из условия это будет в любом случае быстрее, чем другими способами, например, с планированием.

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

И с нулевой итерацией тоже можно прогнозировать. Т.е. собирать требования, фиксировать, оценивать частоту их появления, частоту их исполнения, их трудоемкость, общий объем требований. И можно прогнозировать с каким-то обоснованием, что будет дальше и когда приблизительно всё закончится.

Тот кто понимает такой подход.
Риски очень высоки. Да и масштабируется это плохо. 2-3 человека еще как то и пройдет, но если «надо сделать срочно», работают полсотни человек — без планирования никак.

Ок. Хотя я бы цифру увеличил до 10-15.

На счет полсотни, это меня всегда убивало. Почему-то все представляют себя капитанами ледоколов, когда кругом только рыбацкие лодки.
Если проект, что-то вроде написать операционную систему или офис (ворд эксель) и много участвует людей, хотя бы полсотни, то планировать надо точнее.

Но почему-то офис раз написали и больше никому не нужен, гугл тоже написали или пишут, один проект и всё. А в нашей реальности нужны проекты, в которых нужно максимум 10 человек. И это уже партизанский отряд с двумя предателями ))

Я как-то не сталкивался с такими огромными проектами, где нужно много людей. Если где-то и видел больше людей, то скорее они неэффективно работали и бюджет был резиновый.

Но почему-то офис раз написали и больше никому не нужен, гугл тоже написали или пишут, один проект и всё. А в нашей реальности нужны проекты, в которых нужно максимум 10 человек. И это уже партизанский отряд с двумя предателями ))
Банальная арифметика. Если проект заэстимирован на 20 человеколет, то 20 человек сделают его за год. Ведь критерий «как можно быстрей!»
А в нашей реальности нужны проекты, в которых нужно максимум 10 человек.
Реальности они разные. Проекты на 20+ человек совершенно не редкость что у продуктовых контор, чтоу крупных аутсорсеров.

А Вы веселый, однако. Банальная арифметика — если женщина вынашивает ребенка 9 месяцев, то 9 женщин выносят его за 1.

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

Это в первую очередь зависит от задач, что вы делаете и имеет очень опосредованое отношение к «профессиональному девелопменту».
И тебе уже привели предельный пример в случае с ребенком.

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

А бАдишоп такой бАдишоп. И оценивается по FP, а продается по T&M, и SoW свободно корректируется в процессе, и масштабируется, а параллелится, и проекты на 50 девов существуют. Прям манна небесная.
P.S. А про конвеер вы верно подметили, только проекцировать на всех не надо.

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

Еще бы Samsung сюда приплели.
Во-первых, не путайте праведное с грешным — то, о чем говорим мы, и то чем занимаются «гиганты» — как говорят в Одессе: «Это две большие разницы».
Во-вторых, с позиции своего опыта общения и собеседования скажу что в Facebook и Apple (можно я их к гигантам тоже отнесу) работают не самые квалифицированные разработчики. Во всяком случае я ожидал откровенно другого уровня.
В-третьих, «диктуют мейнстрим»... Кому? В какой сфере?
В общИм, спасибо, дальше не интересно.

Во-вторых, с позиции своего опыта общения и собеседования скажу что в Facebook и Apple (можно я их к гигантам тоже отнесу) работают не самые квалифицированные разработчики.
Конечно же самые квалифицированные работают в ООО «Рога и копыта».

Вы сейчас абстрактно или хотите на что-то тонко намекнуть? Чтобы я понимал стоит ли доставать линейку. Как в анекдоте: «Не уверен — не играй.»

Господи, даже дискуссию о планировании к членомерянию свели.

Банальная арифметика. Если проект заэстимирован на 20 человеколет, то 20 человек сделают его за год. Ведь критерий «как можно быстрей!»
Соответственно 40 человек за полгода? )))
А 80 человек вообще совершат невозможное!
Вас обманули. Почитайте на ночь Брукса.
А 80 человек вообще совершат невозможное!
при должном уровне организации работы — запросто. Конечно, такой уровень менеджмента могут обеспечить буквально единицы компаний в мире, но...
Почитайте на ночь Брукса.
Почитайте его днем — может лучше поймете разницу между «увеличение команды в конце проекта», про которое говорит Брукс, и грамотным планированием в начале проекта, про которое пишу я.

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

Уже обсуждали про «9 женщин» — аналогия красивая, но увы мимо.

Нет. Это предельный и самый понятный пример того, что не все можно распараллелить. В проектах тоже самое.

Еще разщ по складам и с капсом: эволюция, приведшая к 9 месячному вынашиванию детей одной женщиной, НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ К ИНЖЕНЕРНОЙ ДЕЯТЕЛЬНОСТИ, которую мы тут обсуждаем.
Если тебе интересна философия, то вся суть научно технического прогресса состоит в том, чтобы всю научно-деятельность человека поставить и конвеер и автоматизировать.
Именно так это и работает гдет с 17 века и по сей день во всех(!) научно технических отраслях.
Сейчас даже передовую научную работу успешно параллелят, большинство исследований делаются коллективами ученых.
А ты тут пытаешься рассказать про софтварные «нераспараллеливаемые проекты» — да есть и такие, только не здесь и не для контингента ДОУ.
А унылый ентерпрайз, гейм софт и прочая лабуда которую делаем мы параллелится на ура.

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

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

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

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

А унылый ентерпрайз, гейм софт и прочая лабуда которую делаем мы параллелится на ура.

В «унылом энтерпрайзе» вообще не о чем думать. Тут единственное, с чем я согласен: Брукс таки писал о пионерских разработках (как OS/360 в его время).

существенная часть процессов, которые составляют ключевую часть разработки программного продукта (не «унылого энтерпрайза», см. ниже), не могут быть ускорены в принципе
Давай не будем голословными — перечисли какие «процессы создания софта не могут быть ускорены в принципе» по товему мнению. И напиши свою оценку, сколько % времени разработки они занимают.
отому что параллельные работы не сокращают время от начала подозрения некоего открытия до его реализации — они или дают параллельно много возможностей что-то исследовать, или сокращают необходимость поиска за счёт покрытия всего пространства возможностей.
Замечательный пример взаимоисключаюих тезисов водном предложении — сначала постулируется что «не могут сократить время выхода» — затем описывается механизм, посредством которого это время выхода сокращается :D
Аналогом в IT будет не один большой коллектив, а конкуренция на плотно забитом рынке, где только один получит покупаемость своего продукта, а остальные — ничего.
Бред — аналогом в IT будет параллельная разработка большим коллективом.
В «унылом энтерпрайзе» вообще не о чем думать.
Ентерпрайз уныл н епотому что там нет сложных задач, а потому что там «не о чем думать», а потому что валом бюрократии и согласований — и это неизбежное зло.
Если ты думаешь что «ентрепрайз» — это CRUDL на 3 таблички на 20 пользователей, то это говорит о твоем полном непонимании темы, на которую ты пытаешься рассуждать.
Давай не будем голословными — перечисли какие «процессы создания софта не могут быть ускорены в принципе» по товему мнению.

Проектирование при отсутствии аналогов или знания их устройства. Фидбэк от заказчика.

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

Вам следует читать внимательнее. Параллельная проба наугад это чрезвычайно затратный механизм, который используется в науке только потому, что иного пока не придумали. Коммерческая разработка софта, даже включающая R&D, не может себе такого позволить.

Бред — аналогом в IT будет параллельная разработка большим коллективом.

Бред у Вас. Параллельная разработка большим коллективом в IT не подразумевает много работ над одним и тем же.

Если ты думаешь что «ентрепрайз» — это CRUDL на 3 таблички на 20 пользователей, то это говорит о твоем полном непонимании темы, на которую ты пытаешься рассуждать.

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

Проектирование при отсутствии аналогов или знания их устройства. Фидбэк от заказчика.
Аж целых 2 активности в списке, одна из которых своершенно не аффектает команду разработки. Оставим фидбек от кастомера, т.к. это внешняя активность для команды.
Проектирование — пожалуй соглашусь что проектирование некоторых систем плохо параллелится. Но
1. Какой % этих систем разрабатывается в украинском IT? Мое мнение — 0,01%
2. Какой % разработки этих систем занимает проектирование? Мое мнение — 20% — 50%.
Т.е. по сути 99% активностей украинского IT замечательно параллелится — что и утверждалось с самого начала.
Аж целых 2 активности в списке, одна из которых своершенно не аффектает команду разработки. Оставим фидбек от кастомера, т.к. это внешняя активность для команды.

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

1. Какой % этих систем разрабатывается в украинском IT? Мое мнение — 0,01%

Какая разница для данной дискуссии, какой из этих систем процент именно в украинском IT? Не уводите разговор в сторону.

Т.е. по сути 99% активностей украинского IT замечательно параллелится — что и утверждалось с самого начала.

Совсем недавно Вы утверждали:

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

Теперь почему-то вдруг 99% именно украинского IT занимается тем, что подпадает под конвеер, а раньше были гиганты, которых в Украине нет. Хорошо подтасовываете, можно даже купиться.

. Потому что пока заказчик не осознал, что же ему нужно — работать толком не над чем (можно только угадывать), а когда осознал — результаты этого влияют на разработку на всех уровнях.
Переехали от фидбека к требованиям. Ок. Процесс выяснения требований и формализации требований от кастомера может плохо параллелиться. Лучшие собаководы (SEI) рекомендуют 2-5 дневную сессию в одном митинг руме со всеми стейкходерами. И даже дают целый набор рекомендаций как это сделать максимально эффективно. Вопрос: 2-5 дней для ~5 человек трансформируется в 10-25 человекодней вообще. Какой это % эстимейта среднестатистического проекта?
Какая разница для данной дискуссии, какой из этих систем процент именно в украинском IT? Не уводите разговор в сторону.
Я не увожу — я изначально подчеркивал направленность именно на украинское IT т.к. аудиторию ДОУ именно отсюда и рассуждает именно о том, что к ним не имеет никакого отношения — перечитай мои посты выше.
Теперь почему-то вдруг 99% именно украинского IT занимается тем, что подпадает под конвеер, а раньше были гиганты, которых в Украине нет. Хорошо подтасовываете, можно даже купиться.
При выдергивании фраз из контекста можно додумать все что угодно. Конкретно там были приведены примеры что задача параллельного девелопмента уже решена гигантами — и точка. Впрочем можно с тем же успехом заменить гугл с майкрософтом на епам и люксофт. :)
Переехали от фидбека к требованиям. Ок.

А если фидбэк и есть новые требования? ;)
Никто не переезжал. Просто если вы оформляете это так, что «требования» это только то, что нарисовал собственный рисователь ТЗ, то вы просто замутили картину.

Вопрос: 2-5 дней для ~5 человек трансформируется в 10-25 человекодней вообще. Какой это % эстимейта среднестатистического проекта?

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

По крайней мере в моих краях именно так.

Конкретно там были приведены примеры что задача параллельного девелопмента уже решена гигантами — и точка. Впрочем можно с тем же успехом заменить гугл с майкрософтом на епам и люксофт. :)

Полагаю, 99% данного «решения» это предоставление уже готовых примеров и шаблонов со словами «ах, не можете выбрать? умножайте цену на 20 и мы вас успешно разорим, а потом продадим другим». В целом для отрасли это, конечно, лучше. Но для жертв — не очень.

Конечно, такой уровень менеджмента могут обеспечить буквально единицы компаний в мире, но...
Это которые?
Почитайте его днем — может лучше поймете разницу между «увеличение команды в конце проекта», про которое говорит Брукс, и грамотным планированием в начале проекта, про которое пишу я.
Во-первых, не в конце проекта, а по факту обнаружение отставания. А это может быть любой этап.
Во-вторых, грамотное планирование — это утопия, посмотрите статистику.
В-третьих, любое планирование не исключает факта, что чем больше команда — тем больше тратится времени на внутрикомандное согласование, учесть которое в свежей команде невозможно априори.
В-четвёртых, любое планирование не исключает недоработки в проектировании, неграмотный операционный менеджмент, тупость или наоборот звёздность исполнителей, и так далее, и так далее.
В-пятых, если мы уже говорим про Брукса, то по Бруксу измерять объём работы в человекогодах и потом его делить на количество исполнителей — это уровень, когда работа состоит из забивания гвоздей. Да и то... Разные плотники забивают с разной скорость и с разной вероятностью сломают себе палец.
Во-первых, не в конце проекта, а по факту обнаружение отставания. А это может быть любой этап.
«Мифический человеко-месяц или Как создаются программные системы» — книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения, центральной темой которой стало то, что привнесение в проект новых сил (!!!!) на поздних стадиях разработки (!!!!) лишь отодвигает срок сдачи проекта. Эта идея стала известна под названием «закон Брукса».
Во первых прочитай наконец хотя бы статью в вики о мифическом человекомесяце.
Во-вторых, грамотное планирование — это утопия, посмотрите статистику.
Во вторых — это не утопия. Просто это дорого и сложно, как я уже писал. Буквально единицы компаний в мире могут оранизовать такой процесс. Впрочем по факту, 99% бизнеса готовы просто подождать и не переплачивать за менеджмент.
.
В-третьих, любое планирование не исключает факта, что чем больше команда — тем больше тратится времени
В-третьих, эфорты на коммуникацию безусловно имеют место быть. Но при грамотной организации труда — ет константа, при почти грамотной она растет на 10%-30% при росте естимейтов.
В-четвёртых, любое планирование не исключает недоработки в проектировании, неграмотный операционный менеджмент, тупость или наоборот звёздность исполнителей, и так далее, и так далее.
В четвертых, безусловно нужен грамотный менеджмент чтобы минимизировать все озвученные факторы.
В-пятых, если мы уже говорим про Брукса, то по Бруксу измерять объём работы в человекогодах и потом его делить на количество исполнителей — это уровень, когда работа состоит из забивания гвоздей. Да и то... Разные плотники забивают с разной скорость и с разной вероятностью сломают себе палец.
В пятых, это элементарная задача менеджмента — высчитать среднюю производительность труда и вероятность производственных травм и с учетом этих факторов скорректировать план. Все уже 200 лет как придумано и поставлено на поток. Специфика ИТ — молодой возраст и как следствие — нет достаточного количества менеджеров, понимающих специфику, и как следствие — плохо организованные процессы, и как следствие — личностый фактор отдельных разработчиков в успехе продукта, любящих рассказать про то что их никто не заменит и пока не пройдет 9 месяцев, результата не будет. Но к счастью, крупные конторы этот этап уже прошли, лапшу на уши про «9 месяцев» можно вешать только неквалифицированным спонсорам.
Во первых прочитай наконец хотя бы статью в вики о мифическом человекомесяце.
Ясно. Глава 2, подглава «Действия при срыве графика». Читать внимательно. Смотреть графики. Там же — формулировка закона Брукса в её оригинальном виде, а не толковании автора статьи в Вики.
Во вторых — это не утопия. Просто это дорого и сложно, как я уже писал. Буквально единицы компаний в мире могут оранизовать такой процесс.
Это такой толстый тролинг? Я уже один раз спросил, какие именно компании, раз их не так много. Ответа не получил. Тут тоже всё ясно.
Но при грамотной организации труда — ет константа, при почти грамотной она растет на 10%-30% при росте естимейтов.
Коммуникационная составляющая напрямую зависит не от поправок на эстимейты, а от количества членов команды и уровня ротации.
Откуда такие цифры вообще?
В пятых, это элементарная задача менеджмента — высчитать среднюю производительность труда и вероятность производственных травм и с учетом этих факторов скорректировать план.
Эээ? Как можно высчитать производительность новой команды до начала работы? Она проявляется только после нескольких итераций. Как можно учесть гипотетические травмы? Ввести в план, составленный с точностью до дня, эмпирический коэффициент от 1 до 3 на весь таймлайн? Отличное планирование. ))
Все уже 200 лет как придумано и поставлено на поток.
Ясно. Понятию «Программная инженерия» лет 50 как, научное направление считается очень молодым и крайне сложным в плане систематизации.
Специфика ИТ — молодой возраст и как следствие — нет достаточного количества менеджеров, понимающих специфику
Проблема не в менеджерах, а в том, что их не по чему учить. Нет научного бэкграунда. Есть только чужой опыт по срыву проектов и свои собственные шишки, набитые на сорванных проектах.
Есть общие базовые принципы управления проектами, командами, проведения продукта по всем стадиям цикла разработки. Есть достаточное количество метрик, которые можно посчитать и оценить успешность любого звена бизнеса. Тут не секрет. Но нет никаких принципов, по которым можно построить конвейер, гарантированно и срок выдающий программный продукт без багов. Это утопия.
Но к счастью, крупные конторы этот этап уже прошли, лапшу на уши про «9 месяцев» можно вешать только неквалифицированным спонсорам.
Такому взгляду на мир в бодишопах специально учат или так само получается?
Глава 2, подглава «Действия при срыве графика».
Цитирую:
«Действия при срыве графика
Что делают, когда важный программный проект начинает отставать от графика?
Естественно, добавляют людей. Как показывают рисунки 2.1-2.4, это не всегда
помогает. »
Т.е. обычно — помогает. Ну и неужели ты всерьез думаешь, что управление софтварными проектами со времен Брукса не улучшилось?
Я уже один раз спросил, какие именно компании, раз их не так много. Ответа не получил. Тут тоже всё ясно.
IBM, Google, Microsoft — ваш кэп
Коммуникационная составляющая напрямую зависит не от поправок на эстимейты, а от количества членов команды и уровня ротации.
Эпик фейл. Если коротко, то менеджмент вообще то нужен именно для того, чтобы озвученные риски минимизировать и свести к константе. И, представь себе есть компании которым это удается.
Откуда такие цифры вообще?
Средние цифры по отрасли, озвучены в каждой второй книге по менеджменту. Первоисточника не вспомню.
Эээ? Как можно высчитать производительность новой команды до начала работы? Она проявляется только после нескольких итераций. Как можно учесть гипотетические травмы? Ввести в план, составленный с точностью до дня, эмпирический коэффициент от 1 до 3 на весь таймлайн?
Отличное передергивание — я не предлагал планирование с точностью «до дня» до начала работ. Но ты неплохо сочинил, да.
Кстате болезни, травмы и т.д. элементарно считаются статистически на сколько нибудь значимом количестве людей.
Ясно. Понятию «Программная инженерия» лет 50 как, научное направление считается очень молодым и крайне сложным в плане систематизации.
И за 50 лет достигнут окуительный прогресс — сейчас это еще одна ветка инженерии, со своими сложностями и рисками, но процесс поставлен на поток. Сравни например количество человеколет, потраченных на разработку windows 1.0 и windows 10 — масштабирование работает.
Проблема не в менеджерах, а в том, что их не по чему учить. Нет научного бэкграунда. Есть только чужой опыт по срыву проектов и свои собственные шишки, набитые на сорванных проектах.
Спаисбо поржал — про научный бэкграунд, про собственный опыт.
Наверное у доморощенных гениев так и бывает.

Зависит от проекта. Например копание ям можно распараллелить на количество ям — по одной на человека. Все зависит от проекта, есть проекты, что хорошо параллеляться, а есть в стиле «9 женщин ребенка за месяц не родят».
У оппонента возможно проекты легко и хорошо параллелятся.

Зависит от проекта.
Безусловно, есть активности в проекте, которые плохо параллелятся. И есть проекты, на 99% состоящих из таких активностей. Но их доля мизерна и они сосредоточены вокруг R&D и всего такого — на укране их вообще нет. Поэтому когда говорят что «проект не параллелится в принципе» — это первый признак непрофессионального менеджмента.
Но их доля мизерна и они сосредоточены вокруг R&D и всего такого — на укране их вообще нет.
Не спорю. R&D тоже можно параллелить, сам делал такое.
Просто
Банальная арифметика. Если проект заэстимирован на 20 человеколет, то 20 человек сделают его за год. Ведь критерий «как можно быстрей!»
так обычно не работает. В любом проекте и плане будет критический путь. Что-то сможешь распараллелить, а что-то никак, только последовательно.
так обычно не работает.
безусловно — коммуникации добавят около 30% к эстимейту.
В любом проекте и плане будет критический путь. Что-то сможешь распараллелить, а что-то никак, только последовательно.
При грамотном проектировании и управлении командой, последовательные активности будут занимать около 10%-20% от всех эфортов на проекте. Т.е. они очень слабо скажутся на конечном сроке.

Ну так надо было уточнять: 20 человеколет легко прогнозируемого и распараллеливаемого формошлёпства. Тут вопросов нет.

ну дык именно этим и занимается 99% посетителей доу, ваш кэп.

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

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

Там бывают требования в стиле, мы делали пассажирский, а теперь запказчик хочет истребитель?
Как обычно у программистов, причем в лучшем варианте: Запилите по быстрому прототип. О круто. А теперь давайте туда навешивать еще и еще, пока под собственным весом продукт не рассыпается.

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

Вот думаю, чего так к авиа-конвейеру все привязано, а тут НАУ — всяк кулик свое болото хвалит. С чего вдруг данный процесс «акуитительно сложным», не понятно. Если же вы о проектировании новых версий самолетов, так в IT все также, жаль что вы в сфере конвейера ибо последнее ваше утверждение многое о чем говорит.
Заметьте, я нигде не говорил о бесполезности планирования, меня сильно поражает ваша вера в то, что все легко параллелится.
P.S. По поводу колективов в десятки-сотни человек. Вы сильно удивитесь, узнав размеры команд первых версий культовых ПО.

. С чего вдруг данный процесс «акуитительно сложным», не понятно. Если же вы о проектировании новых версий самолетов, так в IT все также
Извини, но ты наверное очень плохо представляешь себе что такое «проектирование новых версий самолетов». Если коротко, то наверное не просто так буквально несколько стран осилили полный цикл проектирования и производства самолетов, а софт педалят на ура во всяких индиях и украинах.
жаль что вы в сфере конвейера ибо последнее ваше утверждение многое о чем говорит.
Я еще раз повторю — по «схеме конвеера» успешно работают гиганты индустрии, производя флагманские продукты. А вот «ручная полировка софта» — удел всяких маргиналов и ремеслеников.
Заметьте, я нигде не говорил о бесполезности планирования, меня сильно поражает ваша вера в то, что все легко параллелится.
Причем тут вера — знание и опыт. Ничего более.
P.S. По поводу колективов в десятки-сотни человек. Вы сильно удивитесь, узнав размеры команд первых версий культовых ПО.
Ниразу не удивлюсь — я знаю эту инфу. Но ты наверное понимаешь разницу в функционале «первых версий культовых ПО» и нынешних.
Кстате хороший пример — наглядно демонстрирует прогресс в управлении проектами и рост сложности этих самых проектов.
буквально несколько стран осилили полный цикл проектирования и производства самолетов
Это никак не связано со сложностью, это связано с высоким порогом входа для данной индустрии, требующей поддержки государства. А э сугубо политический фактор выбора. Если государство захочет — быстро осилят.
гиганты индустрии, производя флагманские продукты
Какие флагманы эти гиганты создали, а не купили в последнее время?
Причем тут вера — знание и опыт. Ничего более.
Если сферы разные — компетенции это не добавляет.
Но ты наверное понимаешь разницу в функционале «первых версий культовых ПО» и нынешних.
Ключевой функционал, который зарабатывает миллионы, а то и миллиарды не изменился, максимум — эволюционировал.
Это никак не связано со сложностью, это связано с высоким порогом входа для данной индустрии
Высокий порог входа есть прямое следствие сложности — твой кэп. Самые сложные инженерные, технические, управленческие задачи находятся вне отрасли софтостроения — факт. Спорить с эти по моему глупо.
Какие флагманы эти гиганты создали, а не купили в последнее время?
Купить полурабочий прототип и довести его до продакшн состояния — тоже вполне себе годный бизнес.
Возьми тот же андроид — купили полуготовое говно, ввалили сотни человеколет и получили вполне приличную мобильную ось. А вот эппл свой ios с нуля сделал.
Если сферы разные — компетенции это не добавляет.
Т.е. еслив в разных сферах работают одни и тежи методики — то это «не добавляет компетенции» — это что-то новое, жги дальше :)
Ключевой функционал, который зарабатывает миллионы, а то и миллиарды не изменился, максимум — эволюционировал.
ну да — как виндоуз 1.0 рисовало окошки, дак виндоуз 10 и будет продолжать их рисовать.
Ведь основной функционал не изменился — максимум эволюционировал. А еще, на одноядерных девайсах обе оси могут эмулировать многозадачность :D
Ты все таки подумай над фразой — «Ключевой функционал не изменился, максимум — эволюционировал.» — классический пример взаимоисключающих параграфов в одном предложении (facepalm)

Чуть выше как раз об этом и написал. Если надо забить 20 гвоздей, то скорее всего 20 человек управятся быстрее, чем 1. Это если тупо разделить работу на количество исполнителей и не подумать о том, что суть работы придётся объяснить не 1 человеку, а 20. Кто-то из них скажет «данунах» и их останется 19. Их нужно будет расставить по своим местам. Выдать молотки, провести инструктаж по технике безопасности. Утрясти конфликты типа «а чё это он пердит мне под нос?» И наконец финал действа! Один дружный удар молотком и забиты 10 гвоздей нормально, 5 забили хреново, 4 погнули, 20-й забивал лично прораб. )))) И это всё при том, что все 20 мог забить один проверенный человек один за другим, быстро и качественно.

Короче. :) Да, есть очень простые проекты, которые можно раскидать на несколько человек и если они не видят друг друга первый раз, то работа быстро сладится. Но изначальный посыл был в «20 человекогодах поделить на 20 человек получам год» и это вызвало у меня некоторый когнитивный диссонанс. :) Проект на 20 человеколет — явно не тот проект, который можно тупо подробить «ты — пилишь, ты — красишь».

Проект на 20 человеколет — явно не тот проект, который можно тупо подробить «ты — пилишь, ты — красишь».
99% проектов выполняемых на украине запросто делятся на «ты — пилишь, ты — красишь».

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

Ага. А проекты сопротивляются и почему-то срываются по срокам. )))
Банальнро потому что менеджмент не успевает за технологиями.
Думаю, сложные и потенциально красивые проекты в Украине есть.
А я думаю что маленькие зеленые человечики управляют мировой политикой. Шутка. Но такие заявления было бы неплохо подкреплять хоть какими то пруфами.
А я думаю что маленькие зеленые человечики управляют мировой политикой. Шутка. Но такие заявления было бы неплохо подкреплять хоть какими то пруфами.
Любой продуктовый близкий к R&D проект. Их мало, но они есть. Если кто не в курсе их существования, это не моя проблема, рынок труда полезно знать.
Что творится в аутсорсах и какие там проекты — я без понятия, никогда не работал и не планирую.
Любой продуктовый близкий к R&D проект.
За этим надо ехать в калифорнию — на украине таких проектов попросту нет. А то что пытаются обозвать R&D — сопли и детский сад.
Рад бы ошибаться, но поверю только пруфам.

Вы пропустили тег «сарказм», который был написан кеглем 0.02.

Какой-то странный опыт. Вы точно пробовали планировать и доводить проекты до готового состояния с нуля (только в этом случае планирование показывает хорошие результаты).
А вообще я просто оставлю это здесь www.stevemcconnell.com/psd.htm

Что мне ответить? Я не пробовал планировать и доводить проекты до конца, я постоянно (за 12 лет опыта) видел и участвовал в таких проектах. Есть даже 10-летние проекты. И были проекты без планирования, иногда в разы сложнее, а заканчивались в 2-3 месяца.

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

Бюрократия порождает простои. Например. Ваша работа зависима от кода коллеги. Вы сталкиваетесь с чем-либо, что нужно обсудить. Ваши действия? Отрывать коллегу от работы? У него не запланирован митинг с вами. У него есть план, сегодня доделать фичу. Все должны следовать плану. Итак, резервируем у него время и полдня в лучшем случае простаиваем.

Если вы в начале разработки неверно проработали (или вообще забили) на performance requirements
если сразу известно что производительность не особо важна, то правильно будет на нее забить, если производительность важна, то нужно тому кто побольше понимает прикинуть где будет узкое горлышко и от него строить все остальное, если фиг пойми что будет ну беда тогда :) ревьювить код чтобы никто не напаскудил, но продумывание и заделы на будущее тоже не сильно помогут здесь
А структуру вашего кода для максимальной гибкости вы делаете по умолчанию. И вот тут уже SOLID. Хотя любители KISS и YAGNI и тут вам расскажут, что вы своим SRP чересчур всё усложняете, и «вам это не понадобится» ;)
я тот самый любитель ягни и кисс, оно может показаться что конфликты во всех этих буквах, но нет, это рекомендации, а не жесткие правила, можно расставить приоритеты и по ним следовать, я для себя определил такой порядок: первым делом единственная ответственность, потом максимальная инкапсуляция в идеале класс получается с одним методом и все, потом применяем кисс, начало по идее будет подпадать под него тоже, но не всегда, а дальше остатки солида с оглядкой на ягни, на выходе получается очень легкая архитектурка, которая рефакторится по щелчку пальцев, сразу собираешь каркас приложения таким способом, после этого набиваешь его функционалом с тем же подходом, самое страшное что может случится это невозможность дописать функционал из-за того что все инкапсулировано — это провал, каркас собран неправильно, нужно его отрефактирить добавив нужные модули для наращивания функционала, добавить методов и убрать часть инкапсуляции никак нельзя, с таким подходом получается простой и понятный код, в «крайних» классах, которые взаимодействуют с одним из классов каркаса и больше нечем даже можно говнокодить :) они ни на что не повлияют, поэтому из без раздумий можно отдавать самым зеленым джунам, едиснтвенный минус этого всего то, что юнит тесты не всегда хорошо ложатся, но так как зачастую многие их пишут всегда зелеными это приемлимая жертва за дешевый багфикс и разработку

Забываете уточнить что классы бывают разные. Классы, описывающие сущности — с private пропертями и геттерами/сеттерами
Классы сервисы — как раз то, что вы описали с одним уточнением —

класс получается с одним public методом
. Внутри он может состоять из нескольких private методов с читабель