Дмитрий Макаров

В том и разница. В синтаксисе.
С указателями еще можно всякой адресной арифметикой заниматься.

Мне как программирующем на C# с ссылками работать удобнее, чем разбирать зубодробительный синтаксис с указателями: лучше маленькие такие точечки, а не вот это вот все (*->&)

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

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

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

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

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

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

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

Оставлю это здесь Теория «Черного лебедя» и фундаментальная уязвимос...

Tom Nolane и flafy4 Геттеры и сеттеры нужны не только чтобы "выводить приватную переменную наружу".

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

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

уведомить об изменении состояния объекта:

string _StateValue;
public string stateValue
{
    get {return _StateValue; }
    set 
    {
        _StateValue = value;
        OnStateValueChanged(value); //этот метод генерирует событие на которое подписаны все кому интересно изменения этого поля, например при изменении поля могут по событию перерисовываться форма
    }
}

выполнить отложенную инициализацию поля, хотя есть и другие способы это сделать, например через Lazy:

string _CaсhedValue = null;
string cachedValue
{
    get
    {
        if (_CachedValue == null)
        {
            _CachedValue = CreateValue(); //этот метод вычисляет значение
        }
        return _CachedValue; 
    }
}

вычисляемые свойства

PointF _Start;
PointF _Stop;
PointF center 
{
    get
    {
        return new PointF((_Start.X+_Stop.X)/2,(_Start.Y+_Stop.Y)/2);
    }
}

это только первое что в голову пришло...

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

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

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

Еще интересная тема с математикой: колоризация ч/б изображений и видео. С подсказками, без подсказок, с автоматическим поиском подсказок в интернете (поиск изображений сходного сюжета, гугл вроде какой-то такой сервис предлагал).

Обработка изображений со спутников. Мониторинг лесных, водных ресурсов (пожары/наводнения), динамика/прогноз.

Представим, что двумерный массив - это граф, где каждая клетка - это узел. Данные узла: его координаты, цвет, массив ссылок на соседей, булево значение посещен/не посещен.

Отметить все узлы непосещенными.
На вход алгоритма подается узел графа.
Процедура P:
1. Выдать координаты входного узла.
2. Пометить входной узел посещенным.
3. Применить процедуру Р ко всем непосещенным соседям такого же цвета.

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

5 лет за компьютером занимаюсь кодингом + до этого 7,5 лет занимался за компьютером схемотехникой.

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

В какой-то момент, когда вес перевалил через психологическую границу - понял, что пора что-то делать. Стал бегать по утрам и ограничил себя в еде. Минус мучное, минус явные жиры, минус сладкое, минус соки-газировки. После 20.00 не ел. Ел по пять раз в день по немногу.
Итого за 3 месяца минус 13 кг. В организме легкость. Но заболели колени. Ударная нагрузка на колени при беге из-за избыточного веса, неправильной техники бега и, как потом выяснилось, плоскостопия. Перестал бегать, перешел на спортивный шаг.
После год физкультурой не занимался и не особо следил за едой. Опять набрал 5...7 кг.
Пошел в фитнес-клуб, где и занимаюсь до сих пор. Сейчас вес приблизительно такой же, как был до всех похудений, но, по ощущениям, набрал где-то 50 на 50 мышцы/жир. Живот ощутимый есть, но осанка хорошая. Отдышка не мучает. Сердечно-сосудистая система работает. Становая - 100кг, Присед - 100 кг, жим лежа - 80кг. Это не на раз, это рабочие. Последняя тренировка с гирей 16кг по наручному кардиомонитору: 1ч20м, ср.ЧСС 150, махЧСС190, ккал1200.

Образ жизни кодер формирует себе сам. Он не обязательно сидячий. У меня двое коллег программистов в выходной устраивают себе велопокатушки на 70...80 км.
А прогрессирующий лишний вес появляется когда количество поступающий с пищей калорий превышает количество используемых. Плюс качество поступающих калорий, конечно, тоже важно. Углеводы надо получать из каш (низки гликемический индекс), а не из булок. Больше белка. Контролируемо - жиры.
А если питаешься не очень калорийно или от природы с метаболизмом повезло, но с физкультурой не дружишь, то все равно будет грозить фигура беременного кузнечика. Когда мышцы спины не развиты - собственный вес будет скручивать в сутулую закорючку. Но скелетно-мышечная система - это не сумма отдельных мышц. Все мышцы/кости друг с другом связаны. Тут перекачаешь - тебя мышечный дисбаланс в другую сторону свернет. В идеале надо гармонично заниматься. И осознанно.

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

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

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

В свое время когда я начинал программировать с QBasic`а и TurboPascal`a, особых вариантов куда дальше развиваться не было: С++. Реальный язык для решения реальных задач.

Для работы с GUI в Win логичным продолжением было Delphi и С++Builder. MFC от M$ был настолько корявый (по моему мнению), что даже смотреть в его сторону не хотелось.

Затем меня надолго унесло в сторону микроконтроллеров и там С/C++ мне помог в работе наиболее полно: быстрые программы, полный контроль над памятью - то, что нужно.

Потом, мне опять понадобился GUI. Как раз .NET и С# к этому моменту поборол свои детские болезни. С# мне показался очень цельным языком и легким в обучении. С С# я наиболее полно разобрался с ООП (в С++ я с ООП как-то плавал: не складывалась цельная картина). Сейчас C# продолжает развиваться. Это современный язык. Есть много задач, для которых он идеальный инструмент. Впрочем С++ не отстает и современные спецификации тоже включают в себя практически все новинки. Но все равно С++ сложнее: есть куча способов запнуться на ровном (как минимум с точки зрения С#) месте, муторная работа с памятью.

Сейчас при работе .NET с С# иногда возникает необходимость работать со старыми библиотеками, написанными на С++. В .NET есть такой язык как С++/CLR, который с одной стороны умеет работать с .NET, а с другой стороны спокойно работает с "чистым" С++ и становится спасительным мостиком в таких случаях. Кроме того, пару раз мне приходилось реализовывать в С++/CLR сложные, с вычислительной точки зрения, задачи. Сейчас правда вижу, что можно тоже самое было сделать не выходя за рамки С#, но в С++ это получилось все равно сделать проще.

В общем, в моем случае мне сильно помогло, что я начинал с С++. Но работаю я все же в основном в C#. Как бы не получилось так, что начав с С#, как с более простого, вашему знакомому будет потом сложновато в редких задачах, где понадобиться навыки работы в С++.

Совет, наверное, стоит сделать такой: изучайте С# для GUI, попробуйте для развлечения поковыряться с микроконтроллерами: там где реально нужно будет самому на С++ писать. Можно, например, для ардуино на с++ писать: и паять не нужно ничего, и стоит недорого. Не скетчи, а именно разобраться как с С++ работать.

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

Про веб знаю чуть меньше, чем больше, но в целом...:

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

Все это в итоге удорожает/замедляет процесс разработки.

Поэтому, подход "Некогда думать - надо код кодить" не работает или работает плохо. Когда проект большой роль "думать" выпадает отдельному человеку, которого называют "архитектор".

Архитектор анализирует общесистемные требования, разделяет систему на подсистемы и модули, определяет интерфейсы взаимодействия систем и модулей и определяет требования для подсистем и модулей.

Еще по идее он должен знать про паттерны проектирования, uml, idef.
А еще он должен иметь опыт программирования, иначе будет продуцировать "ересь" и его никто слушать не будет.

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

О...9 лет. 6 класс. Я в этом возрасте в спектруме какие-то штуки набирал/запускал, а в школе нам про бейсик рассказывали на укнц и кубейсик на 286, а в седьмом классе уже турбопаскаль начали.
Но это давно все было. Сейчас надо про ооп что-то. Все говорят что питон самый лучший язык для начала обучения программированию. А я скажу, что с# тоже довольно неплох в этой роли. Я начинал изучать ооп через с++, но шло очень туго. Через какое-то время стал смотреть с# и все стало как то киристально ясно. Может правда это мой персональный путь с учетом школьной базы с бейсиками и паскалями, но все же то же самое школьное можно делать с помощью с#.
В школе проходили базовые понятия программирования: массивы, циклы, ветвления, подпрограммы, рекурсии, структуры, деревья. Базовые алгоритмы: сортировка, поиск. Без этого конечно никак. Сейчас добавляем ооп, ui и лучше сразу тестирование в каком то виде. Отладкой так и так придется позаниматься. В какой то момент когда набьются шишки можно познакомить с git'ом (через год).
Все это лучше изучать через небольшие проекты.
Вот как то так я бы себя молодого учил будь у меня такая возможность =)

Читал где-то, что в зависимости от возраста человеку необходимо разное количество времени на сон. Ребенку от 9 часов, пожилым и 4х часов достаточно.
Кроме того, важно еще и качество сна. При свете дня и шуме газонокосилки за окном сон не даст то, что он должен дать. Это связано с выработкой мелатонина и глубиной сна. Плотные шторы и, возможно, беруши должны решить эту проблему.
Это актуально сейчас особенно, когда часовые пояса туда/сюда передвигали и сейчас в 4-5 утра летом уже светло. (По Екатеринбургу сужу).
Сам стараюсь в будни спать по 6 часов (после фитнес-тренировок больше), в выходные 8 часов. В любом случае не больше 8 часов, а то уже голова начинает болеть, если больше.

Если это будет ШРИ или ШАД Яндекса с дальнейшим трудоустройством туда, то почему бы и нет.
Или возможно другая какая-нибудь наукоёмкая современная контора обучит вас (возможно в содружестве с каким-либо ВУЗом), если в вас есть потенциал.
Вам очень срочно нужен большой практический опыт. Через пару лет сами поймете куда вам и зачем развиваться.