Подкаст мне и слушателям понравился. Поэтому решили раз в две недели делать очередной выпуск. Сегодня поговорим про библиотеки. До встречи через час!

Подкаст "Програмісти та бібліотеки — від любові до ненависті за один реліз." ❤️🔪

6 липня о 18:00 Володимир та Оксана обговорять що таке бібліотеки в програмуванні, як вони допомагають програмістам, але й як вони можуть ускладнити життя всієї команди.

Наживо на YouTube ➡️ https://youtube.com/live/E-Nc5dduWxM

Для моих нужд нужен дизайнер, кто умеет дизайнить pitch decks, они же маркетинговые презентации. Портфолио и условия сотрудничества пожалуйста на почту obrizan@dnt-lab.com или в личку @obrizan. Спасибо.

Моя сотрудница интересуется. Просьба написать лично мне @obrizan или в комментариях.

“Ребят, привет! Я с необычной просьбой, но мало ли. Может у вас есть знакомые консультанты, врачи онкологи в Польше или Израиле? У моей лучшей подруги у брата Остеосаркома на позвоночнике, ему 28 лет. В Польше с лечением отказали, вот еще ищут возможности… если кто-то есть или вы слышали, видели, напишите пожалуйста 🙏”

На цьому тижні розпочав курс з 10 лекції по програмуванню хмарних сервісів на прикладі AWS. Перше відео вже на каналі. http://youtube.com/@reliable-software-ua Підпишіться та дайте посилання тим, кому цікаво навчитися програмувати додатки в хмарі AWS.

Писать «исправили ошибки и оптимизировали производительность» в описании к очередному обновлению — это какой-то дурной тон. Интересно же, что именно исправили и что именно оптимизировали. Хуже этого только когда пишут какими-то шуточками вроде «наши эльфики на фабрике санты починили нолики и единички». Детский сад какой-то, а не бизнес-приложение.

Навчити — найкраще що я можу зробити як керівник

Усе почалося в 2011 коли мені пощастило стати керівником компанії Design and Test Lab. Моя організація проходила декілька етапів розвитку щодо відношення до навчання співробітників.

На першому етапі в мене не було навіть уявлення, що співробітникам треба щось вивчати, щоб працювати продуктивніше. Ми просто брали замовлення з сайту freelancer.com, виконували їх, заробляли якісь гроші та все в нас було наче добре. Але згодом нам почали надходити складні проекти, як з точки зору технологій, так і з точки зору керування проектами. Ми не знали як їх правильно виконувати, тому робили інтуїтивно, і воно не дуже гарно виходило. Замовники почали відмовлятись від нас, тому що в нас була погана якість, або ми робили проєкти набагато довше ніж ми обіцяли.

На другому етапі я вже зрозумів, що співробітникам треба щось почати вчити, щоб вони могли виконувати складніші завдання. Але як це я робив? Лише на словах: “Тобі потрібно вивчити автоматичні тести”. Але я не казав де можна це вивчити, яку книгу почитати, який курс пройти, та не говорив, що на це треба виділити якийсь робочий час. Тому таке навчання (якщо його можна назвати навчанням) було дуже неефективним.

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

На четвертому етапі ми вирішили дати певний час співробітникам на те, щоб навчатись та впроваджувати це на роботі. Стало дещо гірше, тому що ми ще не мали ніякого результату та й час співробітників спливав в якусь чорну діру. 😂 У звітах забагато часу йшло під назвою “навчання”.

На пʼятому етапі ми вирішили контролювати, що співробітники там впроваджують. І тут я зрозумів одну з найголовніших проблем — не було чіткої програми як впровадити те, що вони вивчають у книгах або десь там в інтернеті. Так, вони вивчали щось корисне, але це було не зовсім те, що ми вимагали на роботі.

І ось на шостому етапі я вирішив обрати найактуальніший для нас напрямок та зробити свій навчальний курс QA Automation Selenium + Python. Цього разу я заклав у програму навчання лише ті знання та навички, які підходять нам. Лише те, що ми використовуємо на роботі. Цього разу результат був вже гарним: ми перекваліфікували деяких співробітників з Manual QA на QA Automation, та й ще найняли талановитих випускників моїх навчальних курсів в First Institute of Reliable Software.

А на сьомому етапі ми ще й зробили щотижневий семінар, де спільно працюємо над проблемами впровадження автоматичних тестів, та розробили research & development план, як можна покращити процеси тестування в нашій компанії.

За ці 10 років які я працюю як керівник, то я дійшов до розуміння, що найкраще, що я можу зробити для своїх співробітників — це навчити їх.

Друзі, цього року пробуємо новий формат для мене — LinkedIn Live Event.

Завтра робимо стрім з нашим співробітником Іллєю Бондаренко, та поговоримо як він будував з нуля до 1 млн користувачів iOS та tvOS додатки для Netflix-подібного сервісу.

Запрошую відвідати цей онлайн-івент (англійською мовою):

https://www.linkedin.com/posts/obrizan_tv-ott-ios-activity-7155949620790009857-XLY4

За 20 хвилин буду на подкасті “Шо по коду?” обговорювати статтю на тему “чи готує універ студентів до реальної software engineering-праці”.

Усім привіт!

У черговому випуску подкасту ми будемо обговорювати статтю від Mensur'а Durakovic'а, у якій автор висвітлює 10 (неприємних) фактів про програмну інженерію, що важко визнати.

Пан Руслан усе ще відсутній, тому якщо хтось хоче зайти в гості, дайте нам знати!

Приєднуйтесь до нас як завжди в суботу о 19:00 за Києвом. Будемо раді побачити ваші питання та коментарі під час прямого етеру!

https://www.youtube.com/watch?v=xpVBl8b7UKc

I'm working on a SaaS tool which helps Project Managers, Engineering Team Leads, Engineering Managers observe software engineering performance: see best performers, worst performance. The observations are non-intrusive, the software engineers don't need to report anything. You have already the data, my tool helps you to visualise it.

If you feel such pain that it is hard to observe software engineering team performance, — please DM me, or explicitly state your interest in comments. I'd like to have a discovery call with you to talk about your pain and show possible solution for it.

There are no poor or good metrics in Software Engineering.

Have you ever heard that “line coverage by tests” is a poor metric? Or that’s you who said that?

Ok, have you ever heard that “km/hour” is a poor metric? No? Why?

Because out of Software Engineering it is nonsense to say that relation between something is a poor metric!

For example: is 60 km/h is slow or fast? In which context? By foot? By bicycle? By car? By Formula 1? Reverse? In inhabited area? In heavy traffic? By a person who sits his first day behind the wheel? What’s the motor rate per minute? 2500? 6000? Straight road? 90-degrees turn? In vacuum? In water?

That’s just a small fraction of circumstances which must be considered before I judge if 60 km/hour is good or bad. But I don’t judge “km/hour” itself!

The same with any metric in Software Engineering.

“Test coverage is a poor metric”.

Really? Do you count all pros/cons? Do you know my context?

So childish and immature statement.

You don’t like cats? You just don’t know how to cook them.

CODE vs. PEOPLE

Sometimes I see narratives too focusing on code: code quality, code style, code standards, CLI tools, IDEs, themes...

They all missing the fact: the code is just a PRODUCT produced by PEOPLE. If we want to improve the CODE (PRODUCT) the solution is not a new code standard, or new tool.

The solution in minds of PEOPLE, who produced this CODE.

I've seen messy codes produced by great IDEs and tools.

But I've never seen messy codes produced by skilled PEOPLE (even without tools).

When I see that the code quality is bad: I don't look for a better tool, I go and do a lecture for my teammates, buy a specific book for them, record a video tutorial how they can do the same work much better. So I fix not a particular code issue, but improve skills of people who produced this code.

In poor processes lots of issues are found during transferring work between stages: from developers to testers, from testers to customer, from customer to users.

And in most cases no one expects a huge amount of issues.

For example, developers estimated to complete MVP in a single month. They shipped it to the customer and users, and they found 20+ issues. Which estimated time to fix sums up to 2 weeks of work. Wow! That’s 50% of original estimate!

That’s create a consistent sense of urgency: “we need to fix issues ASAP, and ship”

No one comes up with idea: “Hey, how does it come that we have big amount of errors, and how we underestimated by a half?”

Even if such an idea comes to someone’s head, but the managerial decision: “fix all ASAP!”

And that’s a common managerial mistake! Why? It doesn’t leave room for team’s improvement.

The management so focused on current deliverable, to fix issues in the product, that they forget about the biggest asset they have: the team of engineers.

And such managers lead the team by path of a death spiral: fail — fail — fail. No time to learn, ship and fail!

The much better approach I prefer: fail — learn from failure — do new project — fail again — learn again — … — at some moment of time you will succeed!

What I really like in working with true professionals: ability to re-use broad knowledge and experience from past for new projects.

We have Dmytro Krasylnikov on our team at Design and Test Lab (USA). He has 13 years of experience building apps for Apple iOS with Objective-C and Swift.

This year one project came in and we decided to build it cross-platform with Flutter and Dart. We've assigned Dmytro as our most experienced developer. And time line is the following:

One month — install the environment, go through tutorials on Flutter and Dart, doing proof of concepts.

Another month — building the MVP with Flutter, doing weekly releases for product owners, iterating.

Aaaaand... less than 3 months passed and the app is in Apple App Store and Google Play Market!

Again: less than 3 months from "never seen this other mobile framework" to "I've published a full-featured app into stores".

The app itself is a gig-workers marketplace.

If you want to build and publish fast (less than 3 months from idea to AppStores), please DM me.