Suggestions
Eli Mydlarz
AI Software Engineering R&D, x-SadaPay, x-Gojek, x-ThoughtWorks
Eli Mydlarz is a software engineering professional currently working as a self-employed Founder.23 Based in Bangkok, Thailand, Eli has extensive experience in the tech industry, having previously held roles at companies such as SadaPay, Gojek, and Cogent.co.2
Professional Background
Eli's career trajectory showcases a progression from freelance design to leadership positions in engineering. He has served as Head of Engineering, demonstrating his expertise and growth in the field.
Current Focus
As a self-employed Founder, Eli appears to be involved in various aspects of software development and engineering. He maintains a personal website where he shares insights on software engineering practices, particularly focusing on topics such as code coupling and behavioral coupling in software design.1
Thought Leadership
Eli is known for his perspectives on software development practices:
- He emphasizes the importance of understanding and managing both static and behavioral coupling in code.1
- He advocates for writing code that relies on programmatically guaranteed information rather than assumptions based on current system behaviors.1
- Eli has also written about the challenges of using deadlines in software development, encouraging a focus on controllable factors and accepting uncertainty.5
Network and Influence
With over 7,000 followers on LinkedIn, Eli has established himself as a thought leader in the software engineering community.3 He actively shares insights and job opportunities in the tech industry through his social media presence.4
Eli Mydlarz's LinkedIn username is indeed elimydlarz, as mentioned in the query.3
Highlights
People worry a lot about static coupling, but not nearly enough about behavioural coupling.
Coupling in your code is easy to see and even measure. You can tolerate quite a lot of it, as modern IDEs are so good at helping us understand what’s going on.
Conversely, behavioural coupling is a silent killer. People usually introduce it with good intentions, not realising the damage they’re doing.
It feels like a eureka moment. In a flash of insight, you realise that because some external system - which could be another unit of code or a distant microservice - works a certain way, you can solve some problem very easily in your system by just doing x.
Of course, this makes us feel smart. We are using holistic knowledge of our software (and problematically, other people’s software) to save effort - which feels like efficiency - and produce briefer solutions, which feels like elegance.
But if our solution was formulated based on knowledge of how external systems behave, it will intrinsically depend on those behaviours and therefore be coupled to them.
Worse still, this coupling will be invisible. You won’t even know where to look for it. It might be in a simple function call, or hiding in complex patterns of message publication and consumption spanning major organisational boundaries.
Such solutions sit around like landmines. Every change in behaviour starts to feel risky, because you don’t know where it’s safe to step.
I’ve figured out how I have been avoiding this, but maybe it will sound a bit weird.
When I’m writing a unit of code, I’m inhabiting it. I think and talk with my pair about what I - as the unit of code - am able to know through properly defined interfaces. I’m not allowing things outside of that to interfere with my behaviour (the behaviour of the unit), because I (as the unit of code) just don’t know about that.
For example, if my pair wants to assume a string passed to some public method will never be empty (say, because the current consumer is getting the value from validated user input with a minimum length), I put my cursor inside the method and say “Well, we (as the method) don’t know that right? We just know it’s a string.”
It’s important that our solution not rely on information that is known to the programmer but not to the program, because it could lead to - in this case - an implementation that explodes when an empty string is provided, which of course could happen at any time through a new consumer or a change to the existing consumer.
These things we feel clever about knowing and leveraging aren’t safe to build software on. They are and should be shifting ground, because behaviour should be easy to change.
Maybe this practice sounds a bit silly, but I’ve been doing it automatically for years. I think it’s helped me see the difference between what I believe is the case and what is programmatically guaranteed to be the case, which are very different things that can feel similar if you aren’t careful.
You can argue almost anything with SOLID. In my experience, elegance is more important.
An elegant solution is immediately understandable by everybody. It’s a way of thinking about the problem that becomes everybody’s way, as soon as they see it. Questions about how we would handle x, y or z have obvious answers - they follow naturally because an elegant way of thinking gives us leverage.
In general, we should judge our ideas less by how well they conform to some design pattern and more by how well they bring understanding to our team. By how much leverage they give us to solve our problems, by their simplicity, and - sometimes - by their brevity. To me, that’s elegance.
