• Что такое навыки программирования, "программистские скиллы", и почему они утрачиваются?

    Zifix
    @Zifix
    Barbatum
    Мозги засыхают.

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

    Вернуть навыки можно, но, в зависимости от длины перерыва, придется практиковаться от месяцев до лет, плюс подтягивать отставание от развития библиотек и языков.
    Ответ написан
  • Кто работал с two wire interface (I2C), почему так сложно получить подтверждения передачи адреса и данных?

    @vanyamba-electronics
    Почему-то подтяжки, встроенные в ATmega, с интерфейсом TWI не работают. Нужно физические резисторы добавить.
    Ответ написан
  • Уехал в Москву, но не тяну по сложности, стоит ли возвращаться домой?

    qlkvg
    @qlkvg
    python backend developer
    Был в похожей ситуации года 3 назад, только без обрубания концов и релокации. Совсем не тянул, спрашивал мелочи у коллег и стыдился, ничего не понимал. Хотелось все бросить и вернуться на прошлое место работы, где можно было спать до обеда. В итоге через 3 месяца ада, ощущения собственной ничтожности и штудирования книг в любой удобный момент, что-то начало получаться. В итоге дорос до человека, у которого джуны спрашивают мелочи.
    Сейчас понимаю, что первые несколько месяцев нужно было просто пережить. Это нормально для зеленого новичка в индустрии. Если вы не устроились на позицию сеньер фул-стека, адекватный работодатель не будет от вас требовать мгновенного результата. Если переживаете, честно поговорите с непосредственным начальником, что не вывозите, нужно время на раскрутиться
    Ответ написан
  • Какие самые нужные, общие знания в программной инженерии и embedded разработке?

    32bit_me
    @32bit_me
    Программист, встраиваемые системы
    Я занимаюсь эмбеддед-разработкой очень много лет (лет 20 примерно), и если я мог бы выбирать сейчас, я бы выбрал просто программирование. По одной простой причине - больше платят. Раньше я разрабатывал и железо, и схемы, и платы, и вообще делал всё, вплоть до испытаний и документации, но уже много лет я всем этим не занимаюсь, а занимаюсь только кодингом, по той же причине - больше платят.
    В целом, если вы хотите именно в эмбеддинг, начните с микроконтроллеров семейства Stm32, купите недорогую плату Discovery или Nucleo и разбирайтесь. Также необходимо будет знать основы схемотехники. Даже если вы не будете сами разрабатывать схемы, всё равно придётся разбираться с готовыми схемами, и нужно будет полностью понимать, как что работает. Уметь держать паяльник и работать с осциллографом также будет большим плюсом.
    Потом можно будет освоить FPGA и язык Verilog, но это очень на любителя и только при большом желании, потому что с зарплатами тут вообще печаль.
    И да, английский нужен обязательно, без вариантов. Чтение технического текста свободно, быстро и без словаря - в любом случае, разговорный - только для международных компаний или при работе на иностранного заказчика, но это как раз самое вкусное. Так что английский нужен.
    А так, программирование, оно и есть программирование. Языки: С - чаще всего, С++ - иногда, С# и другие - для "верхнего уровня", но тоже не помешают. Алгоритмы могут спросить на собесе, но сильно их заучивать не стоит. Более важен практический опыт, чем теория. Операционные системы - для верхнего уровня - Windows, Linux, для нижнего - различные РТОС или "голое железо". В мощных железках - Linux, так что с ним лучше дружить очень хорошо.
    Ответ написан
  • Какие самые нужные, общие знания в программной инженерии и embedded разработке?

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

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

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

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

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

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

    Может сложиться образ эдакого супермена в голове читателя. Но тут важно понимать, что любое явление обладает набором параметров. Допустим по первому свойству у вас 3, по второму 4, зато по 5+. Это делает вас как разработчика непохожим на других разработчиков. И если для какого-то проекта нужно подтянуть английский, например, то приходится подтягивать по ходу.
    Ответ написан
  • Как вы читаете литературу по программированию и запоминаете?

    QQQ-RRR
    @QQQ-RRR
    После прочтения применять практику по прочитанному или конспектировать например ручкой на бумагу
    Ответ написан
  • Почему я должен писать именно так, а не иначе?

    jcmvbkbc
    @jcmvbkbc
    http://dilbert.com/strip/1998-08-24
    Почему я не могу убрать скобки, или ещё что-нибудь, и написать так, как мне хочется. В общем, где все это определено?

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

    si1n3rd
    @si1n3rd
    Осилите эту книгу значит, скорее всего, напишите. Вообще в интернетах немало литературы на эту тему, да и статей тоже.
    Что мне просто необходимо знать прежде чем писать компилятор?
    Уметь программировать хотя бы на одном пригодном для этого дела языке.
    Сколько времени уйдёт на это?
    Зависит от вашего уровня, количества потраченного времени и степени тугодумности.
    Смогу ли я поднять свой уровень программирования, написав компилятор?
    Немало полезного точно узнаете. А поднимите или нет, не знаю, мы же не знаем ваш уровень, ваши способности и т.п.
    Ответ написан
  • Что делать если youtube занимает слишком много времени?

    CityCat4
    @CityCat4
    У тролля даже мозги - и то каменные!
    Почему прокрастинаторы прокрастинируют...

    Заблокируйте ютуб.
    Заведите девушку :)

    Эти два совета при всей их феноменальной глупости - помогут. Девушки требуют постоянного внимания... и денег :) Здоровый секс требует хорошей физической формы. Все это требует времени, времени и времени - на трубу его просто оставаться не будет. А если будет - не будет оставаться сил :D
    Ответ написан
  • Что делать если youtube занимает слишком много времени?

    Kadzi
    @Kadzi
    Ом
    Тут речь о мягких навыках, в частности про управление собой и концентрацию.

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

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

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

    У меня была точно такая же история, только вместо ютуба я читал тостер)))) Понимая, что не могу с собой ничего поделать, я начал просматривать по 300-400 советов из разных тематик ежедневно в том числе рубрики в которых я полный ноль. А позже я культивировал полезный поиск + сбор полезных материалов, в том числе из комментариев.

    Я купил ежедневник, где что-то зарисовываю или записываю о том, что я смотрю и читаю, подстегивая себя к новым знаниям. Это своеобразная медитация. Скептически всегда относился к ежедневникам, но оказалось забавно, как такая штука может якорить и напоминать: не останавливайся, чувак!

    В один момент, я понял, что хочу углубляться по вопросам и перескочил с тостера на видео, книги и практику. Начинал так же, с банальных вещей, которые культивировал. Например, что такое цвет? И по 15-20 мин ежедневно что-то читал, смотрел изучал, пока не захотелось это делать по 30 мин в день. некоторые вещи я хочу делать теперь по 3-4 часа в день.

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

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

    Мягкие навыки 1
    мягкие навыки 2
    40 правил философии ответственности обрати внимание на 2 правило
    теория психики
    рекомендую его заметки

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

    0. Никаких резких перемен не будет.
    1. Почитать про софт скилы и что формирует их.
    2. Продолжить смотреть ютуб, разбавив ежедневной рубрикой "полезные 15 минут"
    3. Окружить себя инфополем текущего уровня, пока не захочется на следующий. А захочется, так как эти 15 минут превратятся рано или поздно в 20, а потом в 30. Культивация полезного действия.
    4. Попав на новый уровень, проделать тоже самое.

    Культ полезного действия применим к любым жизненным ситуациям. Учиться учиться, учиться правильно читать, искать, серфить, смотреть и слушать. Это тоже навык.
    Ответ написан
  • Есть ли русскоязычный сайт знакомств для удаленщиков?

    PavelK
    @PavelK
    Зачем ещё один? Порнхаб же уже есть, особенно если до комментов пролистать.
    Ответ написан
  • Объясните алгоритм чисел Фибоначчи?

    hint000
    @hint000
    у админа три руки
    Не зная, что такое рекурсия и как она работает в программировании, вы не сможете понять любой рекурсивный алгоритм, даже такой простой, как этот (проще только рекурсивный алгоритм вычисления факториала). Не зная, как работает стек - в принципе понять рекурсию можно, но не полностью.
    Так что курите рекурсию и стек до просветления.
    Ответ написан
  • Какой новый полезный язык программирования или технологию изучить?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Самая частая причина снижения когнитивных способностей одновременно самая банальная - недосыпание.
    Ответ написан
  • Насколько подробно в резюме стоит указывать навыки?

    Madeas
    @Madeas
    UX/UI designer | Frontend developer
    Можно написать что-то вроде "Дополнительно владею: ..." или "Изучаю". Лишним точно не будет. Это ваши плюсы, пусть и маленькие.
    Ответ написан
  • Как логично и структурно именовать переменные?

    dollar
    @dollar
    В английском языке существительные в начале превращаются в прилагательные, а в конце - существительное, к которому они относятся.
    Сравните: "stone wall" (каменная стена) и "wall stone" (камень из стены).

    То есть первым делом нужно определиться с главным существительным, то есть ЧТО имеется в виду. Если это имя, то название переменной должно оканчиваться на _name (или Name в зависимости от стиля).

    Далее, если не придираться к правилам, то последовательность прилагательных лучше делать так: чем важнее, тем ближе к существительному.
    Шаг первый: product_name
    Шаг второй: homepage_product_name (при этом вам должно быть очевидно, что не home_page)

    Далее, ничего лишнего быть не должно, и должно максимально точно отражать суть. Например, настройка, говорящая о том, что уведомления можно посылать только если приложение неактивно.
    Не правильно: notify_if_inactive (вообще не понятно, не логично)
    Правильно: is_notify_if_inactive_only
    Приставка is_ в данном случае является соглашением в нашей команде, указывающем, что это булева переменная, можно также юзать b_ например для той же цели. Или, скажем, если это константа или меняется очень редко, можно записать капсом или добавить приставку c_

    Вообще дальше уже начинаются тонкости и вкусовщина. Основные принципы изложены выше - это четкий порядок построения и соответствие сути.
    Ответ написан
  • Стоит ли учить JS или Java если поступаешь на Software Engineering?

    @ikfah012
    Дебил
    Вы если хотите именно на software engineer, то зачем вам веб-разработка? Вы будете заниматься более глубокими и фундаментальными вещами. Языков вам будут преподавать не меньше 5, но как уже выше говорили, более-менее разбираться вы будете только в одном (в зависимости от вуза - c++ или java или python), заодно познакомитесь с лоу-левел разработкой. Вы получите фундаментальные знания по всему, что вам нужно знать о разработке и тогда разобраться за пару месяцев с javascript вам не составит труда.
    Насчёт того, что сложнее - java или js сказать трудно, т.к. это разные языки с разным подходом и разными областями применения. Освоить основы js будет проще, т.к. все скрипты обрабатываются браузером без установки виртуальных машин и т.п. Хотя, я встречал проекты, сервер которых был полностью на нативном js, т.е. при желании этот язык тоже может быть универсальным.
    А так по-хорошему вам бы определиться с тем, что вы хотите делать. Потому что вы скачете от фронтенда с html и css до java и алгоритмов.
    Ответ написан
  • Каков предпочтительный стиль / оформление исходного кода на C#?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    • Можно многое почерпнуть о правильной организации кода из предупреждений FxCop.
    • Про навигацию - один класс - один файл. Имя файла == название класса.
    • Partial classes меновать следует так чтобы срабатывал File Nesting.
    • Если сильно хочется иметь "table of content" - можно чаще объявлять интерфейсы и ориентироваться по ним.
    • Есть также базовая навигация по коду.
    • Ну и, если пользуетесь, средства навигации по коду от ReSharper.
    Ответ написан
  • Как вы освоили шаблоны проектирования?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    Когда начался бум и восторг вокруг концепции паттернов проектирования, выкрики "GoF рулит!" и так далее, я озадачился тем, чтобы понять, что за шум?

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

    По аналогии в проектировании софта имееются свои архитектурные вопросы вроде разбиения приложения на компоненты/модули, организации зависимостей между ними, распределение функциональных обязанностей и т.п. Как ловко подметили авторы книжки из этой банды четырех (The "Gang of Four") в нашей индустрии можно также выделить некоторе количество типовых шаблонов, проверенных на практике, чтобы тем самым не наступать на уже обойденные другими грабли.

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

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

    К изучению паттернов я дам такие советы:

    1) Прочтите пару книжек, чтобы понять, что это за зверь и с чем его едят. Можно взять одну из вариаций книжки GoF или какие-то производные для вашего стека разработки - познакомиться с основными популярными шаблонами. Сразу после этого я посоветовал бы прочесть книжку "Горький вкус Java" (Брюс Тейт) - она про анти-паттерны. Это чтобы понять обратную сторону их использования. Мне понравилась и уберегла думаю от многих проблем. То что на примере Java - неважно. Речь идет о шаблонах, так что представителям других стеков (к которым отношусь и я) будет просто понять все равно.

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

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

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

    Я даже пожалуй посоветовал бы подойти к освоению айтишной архитектурной мудрости с другой стороны - со стороны нефункциональных требований или так называемых "-ilities" - их много. Тут вот описаны 7 штук. А вообще их десятки.

    Среди прочих - такие как maintainability (простая поддержка кода), scalability (масштабируемость), extensibility (расширяемость), availability (устойчивость ) и тп. Если, проектируя свое приложение, вы задумываетесь об этих "илитях" и стараетесь их обеспечить в необходимом проекту объеме, то, как правило, ваше приложение будет иметь отличную архитектуру. При этом шаблоны проектирования в ней появятся лаконично сами собой.

    Поскольку идея использовать шаблоны - это попытка опытных программных инженеров дать десяток готовых рецептов менее опытным, чтобы пока они не научились варить "вкусную кашу", они не варили уж что-то совсем несъедобное. :) Учитесь "готовить", разбирайтесь в -ilites :) и все будет хорошо
    Ответ написан
  • Как правильно работать на oDesk?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    На фрилансе с иностранными клиентами важно:
    • Знание английского. Про уровень писал недавно 'Freelance FAQ: какой уровень английского нужен?'
    • В целом - умение вести официальную (формальную) переписку / переговоры с заказчиком (включая тех, кто далек от технологий и может поставить только бизнес задачу)
    • Умение конвертировать бизнес задачи в технические (составить план проекта, описать техническую часть работы, оценить объем работы)
    • Умение вести отчетность (daly status reports, time tracking, etc..) и управлять рисками (своевременно предупреждать о вероятности их появления, предлагать способы устранения)
    • Умение выдавать вовремя результат (не ждать что кто-то вас будет пасти и подгонять когда надо) и гарантировать его качество (то есть помимо разработки, уметь проверять и перепроверять результат своей работы)
    • Еще раз - знание английского. Умение эффективно вести коммуникацию на понятном клиенту языке - это 80% успеха. Оставшиеся 20% - это уже дело техники. Так что практикуйте этот навык постоянно. Читайте, пишите, слушайте, смотрите все, что нравится на английском. Если есть возможность общаться - не упускайте шанс. Пусть даже письменно. Пусть не с носителями.
    • Ну и следите за спросом - какие технологии в тренде и наиболее востребованы. Старайтесь добавлять в свой патронташ те из них, которые вам максимально близки, постепенно расширяя список или даже - полностью меняя свой стек разработки
    Ответ написан
  • Какие есть хорошие книги по архитектуре приложений?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    По архитектуре приложений ничего дельного нет. Все что мне доводилось видеть - это описание того или иного подхода, рассморение его достоинств. Общего обзора по этой теме нет (я не встерчал). Чтобы разбраться в вопросе архитектуры ПО, начинайте читать отсюда и дальше по ссылкам из блока see also. Это, пожалуй, будет самый быстрый способ. Если что-то непонятно по тому или иному вопросу - подчитывайте статейки по этой теме (их много даже на русском на всяких хабрах и подобных ресурсах).

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

    Я сам так сделал когда-то. Весьма неплохо разобрался :)
    Ответ написан