Pull to refresh
63
0
Анна Тарасенко@AnnieOmsk

Предприниматель, ИТ-шник, стартапер, коуч

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

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

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

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

Ну и когда выбираешь вместе со всем остальным еще и «дали больше денег», деньги лидируют. Но вот вопрос — а ушел ли бы ты если бы деньги были ЕДИНСТВЕННОЙ разницей?
Мы на 23-е февраля парням делали целое меню из итальянского ресторана, где блюда были переименованы на ИТ-шные. В этом году, наверное, на конференции на афтепати поразвлекаемся :-)
Именно так и стараемся действовать, когда заказчик позволяет участвовать в работе Product owner-а. Я уже писала об этом подробнее — есть тут и персоны и еще некоторые инструменты, которые позволяют более глубоко проникнуть в шкуру пользователя. Давай замутим доклад на HappyDev?
Ну охота пуще неволи, разберетесь, значит :-)
После динамических языков очень сложно переключиться обратно. Мотивации будет крайне мало. У Вас должна быть чудовищная сила воли, чтобы не бросить это быстро :-)
Ну тут же все понимают это, не нужно объяснять про константные строки и увеличения размера строки путем копирования в новую.

А насчет преоптимизации — это правило на другие случаи распространяется, со строками лучше все же сразу применять. А то сначала строчка для лога клеится кем-то из 2-х кусочков, потом приходит кто-то и подклеивает еще 4. IDEA умеет это заменять, но не все пользуются этими средствами, а даже если и пользуются — не все понимают, почему она это предложила.

У нас к счастью это все в универе было, когда структуры данных на основе массивов и указателей построишь — потом объяснять не надо простые вещи, можно и Java-коллекции использовать. Но уметь сделать их руками на указателях ни разу не вредно. Джоэль Спольски про это целую статью написал и я с ним согласна. Он утверждает, что люди, которые не в состоянии понять указатели и работу с памятью, потому что у них отсутствует необходимая для этого часть мозга, не должны попадать в профессию. Раньше вузы это все успешно отсекали при помощи тех самых курсов с использованием Си. Сейчас многие вузы перешли на Java или Python в качестве стартовых языков и в итоге фильтр отключился.
Си++ надо в универах изучать (можно и без плюсов, конечно), просто чтобы работать с памятью и указателями научиться. Чтобы потом помнить, что объект в Java — указатель, и понимать, почему строки при помощи + объединять плохо, особенно в длинном цикле.
Подбельский неплох для начала. Чтобы просто понять, что к чему.
В любом случае, это доказывают не криками «Я Senior». Вот когда про тебя 10 уважаемых людей так скажут, когда ты не слышишь — вот это да.
Архитектор — это опыт больше 5-ти лет, а лучше 10-ти. Причем интенсивной разработки и проектирования систем, конечно, а не просиживания штанов на саппорте замшелого энтерпрайза.

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

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

А уж чтобы людьми руководить и решения принимать — тут уж точно надо отрастить ответственность и опыта набраться. Когда мало видел, последствия своих решений сложно оценить. Был у нас один архитектор в свое время… Юный и горячий. Наколбасил и уехал на повышение — ну перерос же уже. А дядьки седые потом чертыхаясь разбирали мусор, которые за ним остался. Ни его одна система не выдержала реальности.
Весело и зажигательно :) Спасибо за пост. Местами прямо так и хотелось заорать — да-да-да, вот мы вчера как раз это и обсуждали!
Путь к осознанию был долгим, но вряд ли он мог быть другим. Зато все правильные понимания пришли, а это главное!

Насчет программиста в партнеры. Найти со стороны сложно. И даже не потому, что все такие безответственные и т.д. Посмотрите на все истории успеха такого рода. Чаще всего ребята дружили себе некоторое время, а потом ВМЕСТЕ сочиняли продукт. Один больше, другой меньше, но тем не менее — общая вовлеченность была всегда. Когда партнер приходит позже и со стороны — он все равно не так горит этим, как Вы.

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

Кстати, а где те, с кем была рок-группа? Может быть, партнером-программистом как раз побыть самому, а гитаристу доверить остальное?

Information

Rating
Does not participate
Location
Омск, Омская обл., Россия
Date of birth
Registered
Activity

Specialization

Chief Technology Officer (CTO), Product Manager
Lead
People management
Project management
Building a team
Development management
Organization of business processes
Business development
Company management
Startup management