I/Session

Design Heuristics identity competing heuristics de-escalate technical discussions Idea of the session came from attending a session from Mathias Verraes in one of the previous conferences. This idea of Design Heuristics stuck in my head. And recently I found Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018 This talk was partially sharing what I’d learned learning from others that know more about it discuss it And also checking if others see the use of using competing heuristics to de-escalate technical discussions...

approaches start from a negative experience, flip it around, this is what you value in a job this list is external focused though find your why & how & past what’s first, then you’ll see that you can be much less demanding of those above values which activities gave you energy & what does that tell you about yourself how you spend time what you do effortlessly what you put in a lot of effort pet projects hobbies … what things have you wanted to improve/change/fix in your environment what do you want to experience next what do you want to learn next what do you want to learn towards

Conflict of interest if a recruiter is paid by the company, but not by me Headhunters vs recruiters Sports manager vs recruiter Long term career advice Mentor Salary negotiation @author-of-book-developer-hegemony wrote a blogpost about networking “help people selfishly” > help ppl without asking anything in return, and you will get indirect benefits later > cf “pay it forward” CTO breakfast Build your own network vs buy a network Solve problems for a company vs a job...

types stream aligned (“feature team”) enabling teams (experts, coaches) platform team complicated subsystem (eg. image recognitions) Interactions (collaboration modes) collaboration (looks like 1 team) acts as a service (platform -> stream aligned) facilitating why? size of team cognitive load reverse Conway maneuver looking for low-bandwidth communication Model_ required vs actual communication Model_ pioneers, settlers, town planners (ref: Book_ Team Topologies - Matthew Skelton & Manuel Pais) (src: Conference_ SocratesBE 2022)

Session: Event Sourcing Applicative Profunctors - Jeremy Chassaing Event Sourcing in function programming decide pure function, immutable objects evolve takes 1 event applies it to the state Link it together -– initial state -– now we have Event Sourcing command: only what is needed to ‘decide’ event: only what is needed to ’evolve' cf Aggregate Take any aggregate, and it has enough information to run, without needing external data -we can rewrite any aggregate to this -without needing external data...

Model: Design Heuristics Model: 3 kinds of heuristics guide you closer to the solution design pattern DDD pattern structure for event source records api design approach guide you to other heuristics determine our beliefs or values eg. DDD guiding heuristics compose based on subdomains ubiquitous language domain events Competing Heuristics Do you do TDD? Kind of why? depends on complexity of the problem Heuristic: Don’t checkin (a large chunk of) code without tests ; before or after does not matter...