theNorthWind

samba.

> Захотел заниматься тем же, чем и он. Поступил в колледж на эту специальность и узнал от препода,
> что никаких языков программирования мы учить не будем
Естественно. Основная сфера деятельности специалистов по безопасности, особенно с данным профильным образованием - это офисная работа с документами.

В сериале - главный герой - программист высокой квалификации, занимающийся смежной областью инфобезопасности.

Пожалуйста, скажи что ты не серьезно! Как можно выбрать специальность посмотрев сериал? А если посмотрел бы Доктора Хауса пошел бы посвятил 1000500 лет своей жизни медицине?

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

Сменил 15 языков и с десяток специализаций. А наличие вышки вообще не при чём.

Читал статью по ссылке с hackernews, что умственно-творческой работой можно заниматься плодотворно не более 4 часов в день, два раза по два часа.
Лично я так и замечал, что больше 4-х часов смысла работать нет, начинаю тупить, ошибки делать и т.п.
С сомнением читаю отзывы про людей, которые кодят по 10-12 часов подряд Ж)
Возможно, такой овердрайв и бывает, некоторое время, а потом пробки перегорают.

https://evileg.com/ru/knowledge/qt/
https://evileg.com/ru/knowledge/QML/

На начальном этапе изучения Qt очень помог youtube канал, а также книга Шлее.
Плюс ко всему у Qt очень хорошая документация с примерами.

Где-то читал, что примерно 500-1000 строк для бизнес логики.

Но:
1. Количество строк никак не может зависеть от качества кода. У вас может быть 500 строк плохого кода, который не разберёт даже автор. Но если у вас код хотя бы по DDD, то с таким кодом жить проще. А если ещё есть тесты, то вдвойне лучше.

2. У вас код может быть и на 1500 строк из-за подробной документации кода. Или же много строк получается из-за большого количества передаваемых параметров в методах. И такой метод приходится переносить - каждый параметр 1 строка. Пример.
3. Не стоит ориентироваться на количество строк. Если код поддерживать и читать не сложно, то не заворачивайтесь. Если сложно - рефакторинг.

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

открываешь ссылку
https://leetcode.com/contest/globalranking
если находишь себя в топ-100 - значит 100% умеешь программировать
я не умею((((

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

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

Программист - это тот кто умеет создавать программы.
Программы бывают системные и прикладные.

Если ты можешь создать работающую программу - ты программист.

Другое дело - работа в профессиональной индустрии.
Там надо не просто уметь программировать, а надо уметь стандартно программировать, то есть знать профессиональные инструменты и фреймворки.

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

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

А в инди-разработке ты сам себе хозяин.

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

Все очень просто.
Представь наш мир, который НЕ поделен на объекты:

Представь, например, автомобиль, у которого двигатель приварен к кузову, генератор приварен к двигателю, а колеса приварены напрямую к ступичному узлу. Как ты колесо поменяешь? Да в общем-то никак.

Представь, например, строение компьютера, где всё железо - это один монолитный блок. Допустим, у тебя повредилась какая-нибудь незначительная деталь - разъем для USB. Всё - компьютер за 50 круб в помойку?

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

Так же и в программировании. Большая задача разбивается на подзадачи, бизнес-логика компонуется по объектам, что обеспечивает для разработчиков простоту поддержки и "долговечность" такого кода.

Абстракции являются способом добавить системе модульности. Потому что требования к (крупной) системе постоянно меняются. Тут заменяемость и расширяемость - важные факторы. Обычно это еще называют "гибкостью". Привязываться к конкретным имплементациям - очень быстро выходит боком. Поэтому все на абстракциях, даже там где они возможно не нужны. Но поскольку инженер не знает, что заказчик захочет завтра - сразу все заворачивает в абстракции. Отсюда появляется масса кода который просто поддерживает эту расширяемость. Поэтому когда смотришь на конечный продукт и на тот код из которого он сделан, думаешь это ведь можно было уместить в 100МБ, а у нас система на 6 Гб. Да, если конечный алгоритм отлить в железе он будет компактным но не будет расширяемым. Это "цена" за возможность внесения корректировок в систему, не переделывая систему целиком.

Низачем :)

Если задача решается и без него. ООП - всего лишь инструмент и его нужно применять там, где его применение обоснованно. Если применять его не имеет смысла - не применяйте :)

ООП применяют в enterprise потому что это легче тиражировать, поддерживать и продавать.
В институтах популярна функциональщина вроде Haskell потому что больше похоже на формулы, красивше, легче защищать диссертации, все равно никто ничего не поймет.
В лабораториях вроде превалируют С и Fortran, когда нужно действительно что нибудь посчитать.))