Domain Driven Design (DDD) made plain broke down to the bone gristle. cus i need that science to level up my code, but miss me with all the stuffy acronyms and jargon. 🧵
domain
- the actual problem
- what we're trying to solve with the code for the user
- the set of problems that the users ask the developers to solve
- the subject matter
Oct 17, 2020 • 6 tweets • 2 min read
switching from management roles to individual contributor roles and still making the same if not more bread is a slept on power move
"shut up man"
"do you understand what this clown is doing"
"shush for a minute"
"lemme shut you down for a second"
"he's a fool"
"nobody cares"
I feel some more coming on
Sep 28, 2020 • 4 tweets • 1 min read
"Always implement things when you actually need them,
never when you just foresee that you need them." - Ron Jeffries
i feel attacked 🙄
(over-abstraction is one of my guilty pleasures) 😅
like, sometimes i'll take that advice to "code to the interface" to the extreme, just cus i can, and i'll make everything an interface. what you can do with polymorphism and dependency injection is fun ...
Sep 26, 2020 • 9 tweets • 2 min read
imho, the senior / junior comparison is moot
but questions like this are asked a lot in the community, and i challenge myself on it:
Q: what is really the edge i would give *myself* over the junior developer, 10 yrs ago, version *myself* ?
A: i have more humility as a "senior" about what i might not know, more awareness of what might be my own blind spots
and not by any moral virtue over my junior self
i've just been bitten enough times by being "sure" of something, only to be proved wrong
Sep 23, 2020 • 23 tweets • 2 min read
Everybody wants less bugs in their code but nobody wants to _______.
use #vscode 😅
Sep 23, 2020 • 13 tweets • 3 min read
check out this cool talk - Getting Rid of CRUD: Revealing Intent With Your API - by my man Michael Brown @browniepoints for all u crud/rest/ddd fiends
"fair warning this is a domain driven design talk hidden as an api best practices talk" 😆💪🏾
this is pretty much how i feel like starting during daily standups
Sep 21, 2020 • 4 tweets • 1 min read
the fact that you can write/mutate and read/query from the same call or transaction in #graphql.
powerful flexibility or anti pattern?
by same call i mean same transaction, same request response cycle
Sep 20, 2020 • 5 tweets • 2 min read
so blatant. his whole strategy seems to be copy/paste going off of a number of his others as well. 👀
any guess as to what this guy's code looks like? 😆
thx yall, for pointing out this part
Sep 19, 2020 • 4 tweets • 1 min read
kill that noise, design patterns are dope
i kinda don't think people are lashing out against design patterns tho
i think it's more backlash against certain figures in the field, who are hard core advocates of design patterns, and the dogma that some of they preach
Sep 11, 2020 • 4 tweets • 1 min read
refactoring is always the right answer
because time is always passing
and with time passing, technical knowledge develops
and with time passing, domain knowledge develops
in either case, more than likely, in hindsight,
you now know, how to better code,
what was coded before
2/4
Sep 10, 2020 • 8 tweets • 2 min read
the internal software quality of a code base correlates to the level of emotional intelligence shared among stakeholders. EQ leads to ISQ
it's like the the code is a reflection of the conversations being had across the team
and the quality of the communication (where we need the EQ) shows in the Internal Software Quality (ISQ)
2/
Sep 8, 2020 • 4 tweets • 1 min read
most of coding/ software design, is about getting your code to be 3 things:
a) easy to change via b) loose coupling and c) high cohesion
it's not really about OOP FP DDD TDD *DD or Java or JavaScript or Python or any other pattern or paradigm or language
1/3
a) what's hard to change?
b) coupling - code entanglement - have to break/change several methods/classes to just change one method/class
c) !cohesive - easily misunderstood - vars, methods, classes that seem like they should be together are in different classes or folders
2/3
Sep 8, 2020 • 4 tweets • 1 min read
what's worse for a project?
software teams content with anemic domain models?
or
software teams content with "anemic domain meaning"?
i.e. while the objects do have some behavior they are still "anemic" of any of the language, or concepts that the users use
so there's the anti-pattern of the "anemic domain model" - objects with no methods other than accessors
some dev work (e.g. enhancements, modernization) is
"tweak/refactor + copy-paste + tweak/refactor"
w/ varying amounts of "tweak" depending on the work
i.e. there's this thing that "works" already; they want a slight enhancement, or new look n feel
like a transplant
1/4
most attention/energy expectation is paid to the level of effort it takes just to do the "copy-paste" part
and dev teams have a hard time justifying that it takes more than just ctrl+c, ctrl+v
we all want to believe that the work is just two key strokes and a mouse drag
2/4
Aug 31, 2020 • 5 tweets • 2 min read
on an agile team, whenever someone uses the word "story" and "requirement" to mean the same thing, an angel loses her wings
how do you point out the benefits of using one over the other?
"story" frames with problem, with the person at the center
"requirement" focus on the product, teh soul-less tech
Aug 27, 2020 • 6 tweets • 1 min read
black parents and guardians, having convos with our sons, daughters, nieces and nephews about "how to not be murdered by the police" - the same people who you call when you need help - it's an experience that will never really be understood by any other group of people in america
and probably the most infuriating part is not having a concrete and absolute answer; other than - try your best to make decisions that put you far the fck away from them as much as is humanly possible; cus you never know when you will come across a shesky
Aug 26, 2020 • 5 tweets • 2 min read
i been calin it the #dddfl for kicks - the domain driven design feedback loop
ubiquitous language <-> domain model <-> design <-> code
now i think team structure needs to be in it to account for conways law 🤔
getting crazy pushback 'gainst knowledge crunching n other #ddDesign habits. methinks def due to org culture;
Aug 22, 2020 • 5 tweets • 1 min read
Who doesn't hate the unrealistic deadline, and the customers, clients, managers who impose them?
Frustrating, stressful yes, but I believe it only takes a perspective shift to fix it. Any thoughts on this?
1/4
The problem is not the unrealistic deadline, or "they" (customer/client/manager) who impose it.
The problem is us over-promising:
- on how fast we'll do it (time estimates)
- on how much we'll do (scope, level of effort estimates)
thx yall, for pointing out this part 