На что лучше учиться на бухгалтера или программиста 1с
Обновлено: 05.07.2024
На бухгалтера учишься 5,5-6 лет в ВУЗе, потом, на предприятии тонкости познаёшь - лет 10-15, к этому времени ты начинаешь более-менее понимать в экономике.
Как правило, женщины-бухгалтера, тормозятся в своём развитии на уровне рядового бухгалтера, единицы - вырастают и становятся главными бухгалтерами. Зарплаты, примерно от 30.000р. и дальше.
Курсы бухгалтеров - это развод на бабки, ничему там не научат!
Да, современный бухгалтер пользуется многими прогами и сервисами, но без знаний в экономике ими не сможешь пользоваться. Тут приветствуются знания в области программирования и в целом познания в области IT, но не обязательно - много сервисов, он-лайн, калькуляторов т т.п.
К вопросу о "вымирании" профессии. Да, в последнее время много программных продуктов, которые автоматизируют бухгалтерию.
Есть некоторые "эрзац-бухгалтерии" - ими, к слову, банки манкируют. но, они бухгалтерский учёт не заменяют, а подсаживают на сервис (прогу) и ты становишься заложником этого сервиса (проги), из бухгалтерии, там примитивные операции: счёт выписать, платёжку, накладную.
Но бухгалтерский учёт на предприятии они не организуют: регистры налогового и бухгалтерского учета не сформируют. и это до первой проверки в налоговой или банке.
Потом, заплатив, кучу бабла на налоги, в лучшем случае, а ведь есть ещё уголовный кодекс: статьи: 159, 174, 198, 199 - тут и сесть можно. Отмазка, что ты не знал не прокатит.
И, вот, такие "экономные" нанимают профессионального бухгалтера.
Теперь, к программёрам: бухгалтер, может стать программистом, программист бухгалтером -никогда. - здесь разность мышления, тем более: корреспонденция счетов - это один из первых языков программирования.
Профессия - бухгалтер не вымрет, она трансформируется, а к спецам новые требования предъявляются.
Сегодня, грамотный бухгалтер - это специалист в области экономики, юриспруденции, продаж, немного IT, переговорщик и т.п., короче, - решатель проблем.
(1)Сначала понять кем в 1С экосистеме хочешь быть. Мнение со стороны, что программист1С только и занят тем, что пишет код на русском - не совсем корректно изначально и чем больше времени проходит, тем дальше оно от реальности.
Сейчас бОльшую часть времени "сферический программист программист 1С в вакууме" посвящает не написанию кода, а внедрению типовых конфигураций и ответам на вопросы пользователей.
Лет 10-15 назад можно было не знать типовой программы, но умея быстро читать код, разобраться в любой проблеме пользователя на лету. (ну почти в любой. рекурсивная процедура ДоходыНалогиВычетыСотрудников на 4тыс строк в ЗиК 7.7 была исключением). В современных конфигах, если дело дошло до чтения кода - запасаемся терпением и страдаем.
Появилась , или вернее сказать оформилась, целая категория "программистов1С", которые не умеют писать год, зато разбираются досконально в возможностях конкретных конфигураций. Те же 10-15 лет назад в эту категорию попадали "женщины за 40", бывшие бухгалтера и ценился их труд не особо высоко. Любой бородатый программист мог заменить такую, просто порывшись в коде 10 минут. Сейчас это люди в костюмах с весьма обширными познаниями и хорошей зарплатой, которым вышеупомянутый программист вообще не нужен.
Могу привести ещё много примеров, но попытаюсь обобщить. Фирма 1С последние лет 15-20 только росла, ширилась и развивалась. Представим себе расширяющийся круг. Внутри круга задачи которые 1С уже решила в типовых программах, либо они решены лучшими из партнёров 1С. В этой области программисты почти не нужны, зато нужны консультанты. Граница круга - это направления, где 1С еще не имеет готовых решений, либо они ущербные. Тут мало работы консультанту, но много работы программисту.
Решай что тебе ближе.
Если Консультант - учи выбранный раздел учёта, подписывайся на периодику, мониторь новые законы(именно они основной источник хлеба для начинающих консультантов), ставь и настраивай типовые программы, пытайся организовать полный цикл учёта в вымышленной организации.
Если Программист - тебе курсы Гилева, книги мастодонтов1С типа Радченко, а еще, очень желательно второй(третий итд) язык программирования, для упорядочивания знаний. Вполне возможно, что кодить придётся не только и не столько в 1С
Когда-нибудь мы станем совсем бабульками. Наденем платочки и валенки, сядем на лавочку во дворе и будем гундеть про падение нравов у современной молодежи. И сожалеть, что мы были, пожалуй, последними бухами, кто знал про бухучет ВСЕ, кто умел руками писать бухгалтерские проводки и делать баланс даже с закрытыми глазами, а также мог виртуозно посылать налоговую на Налоговый Кодекс.
Но! Начнём мы гундеть сегодня, ибо нравы нынешних бухов летят вниз со свистом Челябинского метеорита, даже может уже и Тунгусского.
Началось все с того, что понадобился еще один бухгалтер в штат. Да-да, несмотря на кризис наш бухгалтерский бизнес процветает, ибо собственники научились считать деньги, стали выгонять своих горе-бухов и переходить на качественный аутсорсинг.
Даём объявление в газету (хаха понаберут по объявлениям), и за сутки валится на почту порядка двухсот резюме.
Чтобы как-то отфильтровать совсем уж печальных и убогих, ваяем простейший тест из 10 вопросов типа «Напишите проводки по реализации любые» или «Какой проводкой отражается в учете начисление зарплаты, например, в торговле».
Приходят на собеседование дамы разного возраста и опыта, но на это не смотрим совсем, только на квалификацию. Разброс возраст от 20 лет до 56 лет опыт от 3 до 20 лет. При устном разговоре все бьют себя пяткой в грудь, какие они профессионалы и как они круто работали. Киваем друг другу как китайские болванчики, мило улыбаемся и даем заполнить этот простенький тест уровня первого курса церковно-приходской школы, ну так на всякий случай. По наивности полагая, что уж из двухсот бухов кого-нибудь да выберем. На первичку.
Не было ни одного правильно решённого теста!
Пришлось выбирать из тех, кто хоть что-то ответил. Вот про них собсно и разговор.
Все финалисты имели оконченное высшее экономическое образование и опыт работы бухгалтером от 3 лет, в том числе на самостоятельном балансе. Были и матерые главбухи, хотя это они себя так считали, а на деле пшик.
Никто из финалистов не написал проводки по реализации более-менее правильно.
И вишенка на торте, хотя какая вишенка, тут целая стриптизерша - приписка на одном из тестов «а зачем это знать-то, есть же программа».
У меня остался один вопрос: «Как человек мог работать главбухом 15 лет в крупной строительной компании, не зная совсем проводки и не понимая бухучет?». Хотя ответ нашелся быстро. Программист! Ёпрст, есть же программист! Если в программе что-то не работает или не закрывается, то мы зовем программиста, он все поправит. Вот и выходит, что лучший бухгалтер это ПРОГРАММИСТ!
До сих пор в поиске буха. А не надо было выпендриваться с проводками. Тоже мне, прошлый век винтаж. Проводки никому не нужны. Программа все считает. Сиди только кнопочки жми и улыбайся. И жди, когда на твоё место робота посадят. Роботессу.
ПЫСЫ Время таких бухов заканчивается. Это про них говорят, что профессия бухгалтер умрет, на замену придут роботы, Логично и закономерно. А тех, кто знает бухучет и умеет работать, будут походу в музее показывать под стеклом, вот смотрите они умели в уме считать и балансы делать хоть на счетах.
Кажется, мы делаем всё, чтобы писать хороший код: читаем книги, слушаем подкасты, ходим на конференции и изучаем лучшие практики. Почему же результат оставляет желать лучшего? Новые языки осваиваются медленно, код превращается в адского монстра, а джуны месяцами учатся понятно называть идентификаторы.
Наш гость сам себя называет генералистом. Пишет на большинстве мейнстримовых языков разработки, кроме Haskell, и интересуется нейрофизиологией. В какой-то момент он посмотрел на свой предыдущий опыт работы и понял, что ему нравится писать документацию, объяснять сложные вещи простым языком и общаться с разработчиками, но не руководить. Поэтому позиция DevRel (Developer Relations) оказалась для него оптимальной.
Хороший код, что это?
Объективные критерии назвать сложно, у каждого свое мнение. Главное ― понять, для чего мы пишем код. Конечно, есть разработчики, которые относятся к коду как к искусству, но в основном он нужен бизнесу, чтобы решать бизнес-задачи и позволять людям взаимодействовать друг с другом и с информацией. Добавим, что IT как индустрии всего лет и не все компании понимают, что именно они хотят и как написать ТЗ с первого раза. Иногда самое интересное открывается только после начала разработки. Поэтому хороший код ― это поддерживаемый код, который не «гниет» от собственной сложности за полгода, его можно расширять в разные стороны или пивотнуть в любое время. Новые разработчики смогут разобраться с хорошим кодом за разумное время.
Плохой код ― когда бизнес просит поменять цвет кнопки, а разраб отвечает, что это займет неделю, и это не отговорка, а реальное положение дел.
В чем, собственно, проблема?
Скорее всего, почти у всех нас было такое: написал какой-то код, все сделал правильно, добавил контроль ошибок, автотесты, написал документацию. Возвращаешься к нему через полгода ― кровь из глаз. Делаешь ревью кода команды ― тоже адище. Год за годом одна и та же ситуация: пишешь код, стараешься, а результат как на картинке ниже.
Взято на Bonkersworld.
С обучением молодых разработчиков та же проблема. Обучаешь их азам (как именовать идентификаторы, как писать понятный код, проводить декомпозицию, почему не всегда надо наследовать, что значит юнит в юнит-тестах), а они меняют работу быстрее, чем учатся.
К примеру, у Григория обучение разработчика до уверенного мидла занимало три года. В среднем по рынку разработчик меняет место работы через полтора — поэтому он начал искать способы ускорить обучение. Ведь если мы умеем учить бухгалтеров, то почему с разработчиками так сложно?
Герой перебрал немало методов и остановился на нейрофизиологии, которая дала ответы на некоторые вопросы о мозге и как его правильно использовать.
<рекламная пауза>
По статистике g-mate, минимум 30–50% работодателей готовы рассматривать удаленку, а релокейт среди локаций на второй месте по популярности. И надоевший всем коронавирус — не препятствие: за время пандемии и в России, и за рубежом наём ускорился в 3 раза.
Регистрируйтесь в @g_jobbot, подходящие вам вакансии с релокейтом будут приходить в Телеграм.
</рекламная пауза>
Немного теории
Современная нейрофизиология понимает множество деталей, но полноценных гипотез о работе памяти или внимания пока не так много, да простят нас популяризаторы науки. Мы понимаем, что в процессе запоминания нейрон и глия вокруг него меняются, но что конкретно из этих изменений обеспечивает память, сказать не можем. Во многом система внутреннего подкрепления (Reward system) выбирает, что именно мы запоминаем. Она связана с эмоциями, но как именно она определяет, что важно, нам тоже до конца неясно. Эмоционально окрашенные вещи запоминаются лучше, на этом основано множество попыток «хакнуть» механизм, но пока безрезультатно.
Когнитом. Из презентации К. В. Анохина от 2015 года
Для нас в этой теории самое ценное, что в мозге кроме нейронов и их коннектома (всех связей нейронов одного организма) есть дерево смыслов ― когнитом.
Объясним, что это такое. Ребенок рождается с некоторой топологией общего назначения, которая готова к распознаванию лиц и обучению речи, но в ней нет программ, это почти чистый лист. В процессе роста мозг бомбардируется огромным количеством информации. Обрабатывая ее, он ищет закономерности и постепенно строит дерево смыслов: свет обычно светит сверху, от огня горячо, а вода мокрая.
К двадцати годам получается программист, в голове которого дерево миллионов смыслов. Он использует этот когнитом, чтобы думать, читать и писать код. Элементы дерева связаны с другими элементами практически как граф, у дерева есть некое поведение. Чтобы в когнитом добавить что-то новое, нужно много раз активировать окружающие это смыслы. Например, повторять иностранное слово и его перевод, строить предложения с ним.
У когнитома есть два режима: быстро «думать» уже известным способом, либо очень медленно обучаться. Кажется, все происходит в реальном времени, как в шутерах от первого лица (FPS), а на самом деле, большую часть времени в нашем мозгу исполняется когнитом, который обучился за десятки лет нашей жизни.
Например, Григорий утверждает, что за время нашего разговора, он не может ни увидеть, ни подумать, ни сказать ничего нового. Он может только креативно комбинировать то, чему уже научился.
Чем нам это поможет на практике? Решить с сегодняшнего дня делать все правильно — недостаточно
Мы говорим джуну: «Тебе надо давать читаемые имена идентификаторам», и нам кажется, джун, как в FPS, взял новый BFG из Doom и пошел в бой. Но нет, джун в пошаговой стратегии: чтобы новый навык приобрести, ему нужно множество раз повторить одно и то же действие.
Чтобы проявить свободу воли и освоить новый навык, нужно практиковаться в течение нескольких месяцев.
Например, мы учим новый язык программирования Ruby. Мы прочитали книгу «Руби для чайников», у нас активировалось множество смыслов в когнитоме, а потом потухло. Через месяц мы не помним практически ничего, кроме нескольких кусочков, которые задели наш эмоциональный отклик. Чтобы действительно выучить Ruby, нужно кодить на этом языке и методично практиковать написание каждого элемента синтаксиса, который нам плохо знаком.
Для запоминания нового обязательно используйте интервальные повторения (Spaced repetition). Можно пользоваться приложениями наподобие Anki или специализированными программами. Даже в IDE есть функции, которые подсказывают, что здесь можно было использовать hotkey, а здесь ― такую-то особенность языка. Сотни повторений в разных контекстах ― верный путь к успеху.
Мы есть то, что мы делаем: не думаем, не мечтаем, а именно делаем. Если просто слушаем и читаем что-то о навыке, то мы те, кто хорошо читает и слушает, но не те, кто этим навыком владеет.
Чтобы добиться результатов, нужно:
- определить, какой навык хотим прокачать;
- сфокусироваться на нем, не ожидая быстрого результата;
- повторять в разных контекстах и разными способами.
Звучит просто, а на практике? Рассмотрим на примере онбординга.
Онбординг разработчика с разных точек зрения
Допустим, к нам приходит новый мидл или сеньор. При онбординге мы три часа что-то объясняем, ненадолго активируя пять-семь частей когнитома нового программиста, которые помещаются в его рабочую память. Потом мы объявляем перерыв на обед, и после него рабочая память новичка абсолютно чиста. Как бы крут наш сеньор ни был, большую часть из того, что мы рассказали, он или она забудет к следующему утру. Поэтому при онбординге главное ― организовать процесс обучения и повторения.
Например, когда человек приходит в Evrone, информация и лучшие практики выдаются по частям, а соответствующие механизмы и ритуалы, как утренние стендапы и встречи один на один, обеспечивают повторение. Через несколько недель или месяцев человек понимает, как компания пишет код, как деплоить, как устроен GitOps и уникальная конфигурация технологического стека. Просто кинуть человеку документацию сработает в очень редких случаях.
В Evrone перед новым бойцом стоит задача освоить весь инструментарий за первые три месяца и научиться им пользоваться. Для внутреннего общения разработчиков используются slack-каналы. Например, для фронтендера будет доступен канал его проекта и канал фронтендеров. Можно задавать анонимизированные вопросы как в канал фронтендеров, так и в общий технический чат. Также у каждого сотрудника есть доступ к дашборду, где он отслеживает свой текущий уровень и векторы развития.
Взято на TeamLead Conf
Современная разработка софта — это командная игра. Как бы ни был крут сотрудник, он обязан освоить процессы компании.
Можно ли подготовиться к выходу в новую компанию?
Чтобы войти в курс, потребуется несколько месяцев. Хорошо бы проработать ежедневную практику в любой ToDo-программке ― десять пунктов, которые вы будете выполнять каждый день: посмотреть как устроены репозитории в компании, пройтись по истории последних коммитов, прочесть одну статью из внутренней wiki, посмотреть один code review и тому подобное. Этот механизм нужно отладить, и после выхода на работу добавлять в список новые элементы, ключевые для конкретной компании.
Как все-таки писать хороший код в реальных условиях?
Идеального мира не существует. Мы часто ограничены либо во времени, либо в ресурсах. Если присутствует хотя бы одно из ограничений, значит сейчас написать код хорошо уже не получится. Надо подумать и честно ответить на вопрос: чем можно пожертвовать и что нанесет минимальный вред в будущем.
Если мы ставим костыли, то готовы ли мы в будущем вернуть технический долг и когда? Договоренности о костылях происходят во время цейтнота, и если не запланировать исправление, костыль останется навсегда. Не потому что программисты плохие люди, а потому что так устроен наш мозг. Чтобы чинить код, нужно организовать процессы. Если релиз выходит с недоработками и костылями, то в системе управления задачами сразу запланируйте с менеджером недостающие часы разработки на решение багов и уборку костылей.
Если удалось избавиться от недоделок, то остается проблема. Как написать простой код, понятный другим разработчикам? Из-за того, что индустрия молодая и нет универсального обучения — мы все самоучки, несмотря на профильное высшее образование. Пятнадцать лет назад обучали ООП, а сейчас Rust и Go считают наследование антипаттерном. Как результат, когнитомы у всех разные. Если взять двух хороших программистов, то пересечение деревьев смыслов у них может быть всего Код будет понятным программистам с более похожими участками когнитомов. Поэтому читаемый код ― это код, написанный привычными конструкциями. Привычными в этом языке, в этом стеке и в этом году.
Крутой код, использующий нишевые свойства языка, будет понятен программисту, который его написал, но не мидлу или генералисту. Они не найдут в нем знакомые конструкции и не смогут поддерживать такой код. Поэтому в определение читаемого кода входит также понимание, кто будет его читать ― джуны или сеньоры, генералисты или узкоспециализированные разработчики. Больше про читаемый код можно посмотреть в этом выступлении.
Способность к обучению и возраст
Согласно современным гипотезам, если исключить болезни, с возрастом ломается не способность к обучению, а система подкрепления. Мы перестаем осознавать пользу в новом. С точки зрения мозга, активность по изучению забирает больше ресурсов, чем польза от нового навыка, система подкрепления «душит» эту активность.
Бывает, что пожилой родственник годами не может разобраться с айфоном, а потом что-то происходит, и он за полчаса разбирается и все решает. До этого момента он просто не чувствовал ценность нового знания.
Считается, что если изучение нового стало ритуалом, то система подкрепления держится в тонусе, и проблем с обучением не возникает. Как только человек вышел на пенсию и сел перед телевизором, система подкрепления начинает быстро деградировать. Через несколько лет человек не захочет изучать что-то новое.
Универсальное заклинание
Поделимся методом, который наш спикер использует сам и рекомендует другим.
Разработчик написал код и хочет понять, насколько он хорош. Задаем вопрос: «Рассказывает ли этот код историю?». Если другому разработчику нужно два часа, чтобы разобраться, ― это нехорошо.
Как код может рассказывать историю? Идентификаторы отвечают на вопрос «Что это?», а весь код ― на вопрос «Зачем?». Важно помнить, что когнитом образованного человека может активировать пять-семь не связанных друг с другом участков одновременно. Поэтому важно писать код, для осознания большинства частей которого не нужно активировать больше пяти участков.
Что такое пять участков?
Приведем пример. Вы запоминаете подряд семь названных вам цифр (пример такого ряда: 1 9 8 4 4 5 1). Каждая цифра ― это один элемент, который необходимо удерживать в памяти. Если вашему мозгу удалось распознать паттерн или проассоциировать эти цифры с датами или книгами, то в памяти нужно будет удерживать только две единицы информации (1984 и 451 по Фаренгейту), а не семь. Этот прием называется группированием или свертыванием (Chunking).
Для программистов, читающих код, это может быть создание объекта или проход по списку пользователей. Размеры элементов и смыслы, стоящие за ними, для всех различны. Это добавляет трудности в использовании метода, но Григорий работает над поиском решения и можно ожидать улучшения этого «заклинания».
Напоследок нам хочется отметить, что все люди разные. Кто-то от природы мускулистый, хотя из тяжелого только сумки из супермаркета приносит, а кто-то всю жизнь сидит на строжайшей диете. Есть люди, которые от природы обладают развесистым деревом смыслов, цепкой или расширенной рабочей памятью. Они наверняка пишут крутой код, быстро читают чужой и не имеют с этим трудностей. Для всех остальных ― для нас ― хороший код писать сложно. Каждому стоит разобраться, почему это сложно лично для него, искать решение проблем и обмениваться опытом с другими. Надеемся, вместе мы сделаем IT-индустрию чуточку лучше.
Читайте также: