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

Сколько раз вы ставили задачу, получали результат, который вас не устраивает, но принимали решение не давать обратную связь, потому что это - выход на конфликт?

И в конце-концов просто говорили "спасибо", и переделывали задачу сами?

Не вижу, но знаю, что вы улыбаетесь - ответ положительный.

Но на длинной перспективе не давать корректирующую обратную связь опасно и не продуктивно:

Успешная карьера разработчика — это не только навыки и знания, но и умение «продавать» себя, сохранять баланс между работой и личной жизнью, а также избегать выгорания. В этой подборке рассмотрим книги, которые помогут пройти путь от новичка до профессионала, оставаясь на гребне волны в быстро меняющейся IT-индустрии.

Эта статья посвящена разработке многопоточной базы данных. Мы рассмотрим основные компоненты, такие как хранилище данных, транзакционные системы, многопоточность, журналирование и восстановление, а также создание API для взаимодействия с базой данных. Примеры кода на языке C++ помогут лучше понять реализацию различных аспектов многопоточной базы данных.

В предыдущем посте я написал о том, что делать, если Заказчик приходит с просьбой сделать часть работ бесплатно. В этом посте хотелось бы поговорить, как сделать так, чтобы либо подобные вопросы в проекте вообще не возникали, либо чтобы процесс был управляемым.

Сразу оговорюсь, что эти ситуации применимы на больших проектах с внешними корпоративными Заказчиками. На фрилансе, в госах, на небольших проектах и тп могут быть другие нюансы, тут у меня опыта немного.

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

Привет! Меня зовут Никита Грибков, я Flutter-разработчик в AGIMA. В сети море статей о различиях между SQL и NoSQL, но в большинстве из них много теории и почти совсем нет прикладных советов. Я пошел другим путем: ниже постараюсь внятно объяснить, какую систему и в каком случае выбирать. Спойлер: всё зависит от проекта и амбиций заказчика. Конечно, сосредоточусь на мобильной разработке, но основные принципы подойдут и в вебе.

Как выглядят тайтлы и уровни у программистов в зарубежных компаниях, сколько надо лет опыта чтобы быть достойным их, ну и самое главное какая зарплата (до налогов) на этих уровня?

Я не претендую на истину в последней инстанции, это всего лишь мое видение, любые корректировки/добавки/комментарии - приветствуются

Привет, Хабр.

Скорее всего то, о чем я сейчас расскажу, уже было реализовано и не единожды.

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

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

Так появилась задача однотипной замены номера договора и его даты в каждом из *.xlsx файлов, которые были расположены в папках, названных по адресу объекта. Таких папок было множество и некоторые ещё имели вложенные подкаталоги.

Ручной способ, который состоит из использования сочетания клавиш Ctrl + H хоть и позволял сделать замену во всей книге Microsoft Excel сразу, но подразумевал что придётся открыть каждый файл по отдельности, нажимать несколько раз (под замену не только номер, но и дата) сочетания клавиш для замены, сохранять книгу Экселя, закрывать книгу, открывать новую книгу. В общем совершать множество механических действий.

Я конечно же стал думать, как можно наиболее простым для себя способом сделать это множество автозамен. Выбор сразу пал на VBA - Visual Basic для приложений. Ведь при помощи VBA можно заставить Эксель делать то, чего он не умеет по умолчанию.

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

Спустя года наблюдений за hr’ами и руководителями в стартапах и корпорациях я нашел достаточный путь к тому, чтобы расставаться с сотрудниками и в большей степени сохранять их лояльность ко мне как к руководителю и не оставлять плохие отзывы о компании.

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

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

Далее мы рассмотрим каждый из принципов более детально, чтобы понять их суть и способы применения в разработке приложений.

Хабр, привет! Сегодня рассмотрим кейс, в котором классические статистические критерии не работают, и разберёмся, почему так происходит. Научимся строить свои собственные критерии по историческим данным. Обсудим плюсы и минусы такого подхода.

С развитием микроэлектроники, rtl дизайны становились все больше и больше. Реюзабилити кода на verilog доставляет массу неудобств, даже с использованием generate, макросов и фишек system verilog. Chisel же, дает возможность применить всю мощь объектного и функционального программирования к разработке rtl, что является достаточно долгожданным шагом, который может наполнить свежим воздухом легкие разработчиков ASIC и FPGA.

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

1. Запустим Design Rule Check, чтобы проверить возможность произвести нашу схему
2. Запустим Device Extraction для сравнения нашего Layout с целевой схемой.
3. Произведём сравнение наших компонентов из Layout и нашей схемы, которую мы нарисовали в XSCHEM.
4. Сгенерируем netlist с паразитными конденсаторами и резисторами (PEX).
5. Просимулируем netlist с паразитными конденсаторами и резисторами.
6. Сгенерируем LEF файл.
7. Подведём итоги этой серии статей.

Одной из самых распространённых задач аналитики является формирование суждений о большой совокупности (например, о миллионах пользователей приложения), опираясь на данные лишь небольшой части этой совокупности - выборке. Можно ли сделать вывод о миллионной аудитории крупного мобильного приложения, собрав данные 100 пользователей? Или стоит собрать данные о 1000 пользователях? Какую вероятность ошибиться при анализе мы можем допустить: 5% или 1%? Относятся ли две выборки к одной совокупности, или между ними есть ощутимая значимая разница и они относятся к разным совокупностям? Точность прогноза и вероятность ошибки при ответе на эти и другие вопросы поддаются вполне конкретным расчётам и могут корректироваться в зависимости от потребностей продукта и бизнеса на этапе планирования и подготовки эксперимента. Рассмотрим подробнее, как параметры эксперимента и статистические критерии оказывают влияние на результаты анализа и выводы обо всей совокупности, а для этого смоделируем тысячу A/A, A/B и A/B/C/D тестов.

В последнее время я все чаще и чаще сталкиваюсь с мнением о том, что тимлид не должен писать код. И, если лет эдак 15 назад это была просто шутка, то сейчас это мнение становится чуть ли не мейнстримом в индустрии. Поэтому я хочу чётко сформулировать свой взгляд на этот вопрос.

Я достаточно давно решил ознакомится с ассемблером архитектуры Arm. По большей части для ознакомления и понимания внутренних процессов архитектуры. Чем больше я изучал литературу и различные источники, тем больше я понимал, что нужна практика. Я решил вспомнить ассемблер для x86-х машин и заодно потренироваться на архитектуре Arm.

Но как всегда для практики надо быть подготовленным, а как оказалось, я был не подготовлен...