rasiim Morale & The Big Steppers Profile picture
refactoring engineer, software lyricist, enterprise ghostwriter, spittin dat queen's ebonic patwa java js. tdd ddd goon. buglife πŸ‡―πŸ‡²πŸ‡»πŸ‡¨πŸ‡ΊπŸ‡Έ
Oct 18, 2020 β€’ 122 tweets β€’ 23 min read
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 moral of the story if/when the toxicity and burnout gets to be to much - make lateral moves
Sep 30, 2020 β€’ 13 tweets β€’ 3 min read
How do y'all like to ramp up on new tech?

🧡 For me, when the need for a new language, library, framework, shiny thing, etc pops up - i find that i usually take the same general steps

and the 7-bullet list i jotted down in my notes became this thread:
Sep 30, 2020 β€’ 4 tweets β€’ 3 min read
re: adding code comments with respect to the single responsibility principle

As a #selfDocumentingCode fanatic, I do appreciate that some kinds of comments go a long way:

One comment/ blurb (1-3 lines):

- at the top of a class about the single responsibility of the class

- in the project readme/wiki about the single responsibility of the application

Sep 30, 2020 β€’ 4 tweets β€’ 1 min read
phrases never (before tonight) heard in a #PresidentialDebate

"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? πŸ˜† ImageImage thx yall, for pointing out this part Image
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

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)

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

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

Sep 8, 2020 β€’ 4 tweets β€’ 1 min read
what's worse for a project?

software teams content with anemic domain models?
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

Sep 2, 2020 β€’ 4 tweets β€’ 2 min read
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

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

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?

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)

The solution is to stop over-promising.