Manifold Geometry // Многообразная Геометрия

Архивы

Про системное мышление, работу и всякое такое

Находясь под впечатлением от доклада Анатолия Левенчука о системном мышлении на тусовке TeamLead Conf 2020, я сделал удивительное (для себя) открытие. Оказывается, тот навык, который мы так стремимся развить в собственной команде условных «алгоритмистов» — это никакой не «научный метод». Это системное мышление. Если разобраться, в нашем прочтении научный метод — это заповедь аля «не изобретай велосипед», погугли, поизучай, не кидайся делать задачу сразу, потому что получится плохо. Скажем, вот ты собираешься распознавать конструктивные элементы CAD-модели. Прежде чем вооружаться топологическим итератором и кидаться программировать изощренные эвристики, почитай литературу. Там написано как надо. И как не надо — тоже написано. Но этого мало.

Во-первых, поиск материала не исчерпывается только академическими источниками. Часто нужно идти от конкурентов, смотреть и понимать, как работает искомая функциональность у них. Если работает, то каков принцип ее работы? Можно ли его вывести хотя бы из косвенных признаков? Во-вторых, важен контекст. Скажем, если мы занимаемся алгоритмом аппроксимации поверхности по облаку точек, то какова потребность в этом алгоритме? Не путаем ли мы требования и потребности? Не сопряжен ли данный алгоритм с другими, которые тоже придется делать, чтобы продукт стал полезен? Где та самая «целевая система», о которой говорит Левенчук? Попадем мы в нее со своим продуктом или промахнемся? Такие размышления требуют, как приговаривают некоторые управленцы, «видеть картину в целом». Штука в том, что никто не видит и никогда не увидит этой картины (за подробностями — к Талебу с его «Антихрупкостью»). Но кое-что можно делать в условиях, когда перед тобой задача и ты не знаешь, где у нее зад, а где перед. Нужно научиться перемещаться между дисциплинами и трансдисциплинами, понимать тот нарратив, в рамках которого возникает задача. Это — системный подход.

Для системных проблем не найдется простых решений. Здесь нужен метод, и этот метод, конечно же, лишь отчасти научный. Поэтому на собеседованиях следует по возможности выяснять, способен ли кандидат к системному мышлению. Готов ли развивать свой кругозор и быть не просто программистом, а «решателем» непростых задач. Вот и подвел к сути. Если кто-то из читателей желает присоединиться к коллективу разработчиков программы CAD Processor, дайте знать через контактную форму. Гарантируем много интересной работы, успех в которой попросту невозможен без навыков системного мышления. А о чем эта работа должно быть ясно со страниц МГ.

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

template <typename ElemType>
class HAlloc
{
public:
  
  struct THeapPtr
  {
    THeapPtr() : Ptr(NULL), Num(0) {} //!< Default ctor.
    ElemType* Ptr;
    size_t    Num;
  };
  
public:
  
  ElemType* Allocate(const size_t numElems,
                     const bool   doNullify = false)
  {
    ElemType* ptr = new ElemType[numElems];
    THeapPtr HeapPtr;
    HeapPtr.Ptr = ptr;
    HeapPtr.Num = numElems;
    
    if ( doNullify )
      memset( ptr, 0, numElems*sizeof(ElemType) );
    
    m_ptrVector.push_back(HeapPtr);
    return ptr;
  }
  
  const THeapPtr& Access(const size_t arr_idx) const
  {
    return m_ptrVector.at(arr_idx);
  }
  
public:
  
  ~HAlloc()
  {
    for ( int i = 0; i < (int) m_ptrVector.size(); ++i )
    {
      THeapPtr& HeapPtr = m_ptrVector.at(i);
      delete[] HeapPtr.Ptr;
      HeapPtr.Ptr = NULL;
      HeapPtr.Num = 0;
    }
  }
  
private:
  
  std::vector<THeapPtr> m_ptrVector;
  
};

Обновление: предложение о работе больше не актуально.