Am citit pe blogul lui Steve Blank  „De ce avocații nu sînt buni antreprenori”. Plus „de ce întreprinzătorii urăsc avocații”.

Cică

  1. Nu vorbesc clar și concis, doar avocățeasca;
  2. Nu te țin la curent cu mersul lucrurilor;
  3. Te supra-încarcă cu toate *ăcaturile avocățești;
  4. Nu sînt capabili să te asculte și să-ți înțeleagă problema;
  5. Întotdeauna novicii vor face toată treaba, deși tu ai angajat o firmă mare;
  6. Se leagă te toate amănuntele pierzînd din vedere problemele importante;
  7. Nu le pasă de problema clienților;
  8. Costurile lor te cocoșează;
  9. Sînt de negăsit atunci cînd ai nevoie de ei;
  10. Pentru că sînt „deal-killers”.

G.

Am aflat că în sistemul sanitar american nu există scuze pentru doctori sau ceilalți din sistem dacă se întîmplă una din situațiile de mai jos:

  • înseminarea artificială de la un donor greșit (fie că e spermatozoidul greșit, fie că e ovulul greeșit)
  • uitarea/lăsarea/introducerea în pacient a unor obiecte care nu fac obiectul procedurii (chirurgicale sau de altă natură)
  • cît timp ești în spital sînt răspunzători pentru ce ți se-ntîmplă
    • medicație eronată (au greșit medicamentul, au greșit pacientul, au greșit administrarea, au greșit cantitatea șamd)
    • transfuzie eronată (au greșit grupa de sînge sau HLA sau te-au infectat cu HIV)
    • embolie (astuparea unui vas sanguin cu o bulă de aer)
    • moartea sau rănirea gravă în urma unui șoc electric (exitsă o procedură în care inimii i se aplică un șoc pentru reglarea ritmului)
    • arsuri
    • alte ulcerații de gradul 3 sau 4 (răni grave legate de chimicale, temperatură, frecare șamd)
    • moartea sau rănirea gravă în urma unei căderi (cam birocratică acestă idee)
    • sinuciderea pacientului (cam stupidă)
    • agresiune fizică sau sexuală
    • dispariția sau răpirea pacientului
  • greșeli chirurcicale
    • au greșit pacientul!
    • au greșit operația (fie au greșit piciorul, fie au făcut altă operație, fie nu au respectat protocolul)
    • moartea intraoperatorie sau post operatorie după o operație simplă (avem un caz cu unul care s-a dus cu mîna ruptă și n-a mai ieșit viu din spital)
  • moartea sau rănirea gravă în urma contaminării din spital, legată de unelte, medicamente sau oricealtceva
  • folosirea uneltelor în alt scop decît au fost create
  • ți-au dat alt copil sau l-au dat p-al tău altuia
  • moartea mamei la o naștere low-risk
  • moartea sau rănirea gravă asociată hipoglicemiei (măcar o perfuzie cu glucoză pot să-ți facă!)
  • moartea sau rănirea gravă a fătului legate de hyperbilirubinemia (ceva legat de icter la copii)
  • moarte sau rănirea gravă în urma spinal manipulative therapy
  • îți bagă pe gît alt gaz decît cel prescris (la anestezie încurcă gazul)
  • moartea sau rănirea gravă a pacientului legat de pat
  • orice incident legat de un fals doctor (sau orice alt rol din sistem)

Par de bun simț, de ce nu avem și noi astfel de reguli în sistemul sanitar? Sau măcar să fie considerate de bun simț la judacată?

G.

These days I’ve been asked to teach these junior software developers several advanced features of Object Oriented Programming and I’ve started this class of Design Patterns. This is a drought, a skeleton, to develop the course.

What are Design Patterns? I don’t know, ;). Can be thought as grounded best practices to solve a class of problems, to have the most general and flexible solution for them. To define what patterns are we have to think about advanced application design. The advanced practice in software developing is to separate the thinks that change from the ones that stay the same. We introduce this abstraction layer into our applications to isolate changes and keep them to propagate other changes throughout the code (of course, the difficult part is to identify what change). Once you have isolated the changes in your code you have some kind of a pattern. Is it a Design Pattern? Nope, you will achieve it when you go with the most general solution.

Four problem solving techniques:

  • language specific – when use language features to get the problem solved;
  • specific design – when use the described technique to solve specific problem;
  • standard design – to solve some kind of problems (repetitive reusable pieces of codes);
  • design patterns – the most general and flexible solution for a class of problems.

Do not let them fool you with words – generalizing is not a goal, is a means. Do not waste your time looking for patterns, start thinking about your problem and in time they will be revealed.

Classifying patterns:

  • Creational – how objects are created; used to isolate the details of object creation;
  • Structural – the way objects are connected with other objects so changes in the system do not affect these connections;
  • Behavioral – objects that handle particular actions.

The laws of application design:

  • the simplest solution is the best; of course you have to consider full application life-cycle, but simplicity is the base;
  • avoid duplication;
  • isomorphism – one abstraction per class, one class per abstraction;
  • consistency – keep your ideas in place;
  • low coupling, high cohesion – coupling refers to the degree to which the objects depend on each other, cohesion refers to the degree to which the objects belong together;
  • keep your code readable (my first choice);
  • keep surprises out;
  • make common things easy and rare things possible;
  • use YAGNI – the design is finished when anything cannot be removed;
  • keep your unit testing updated.

G