rasiim shabazz Profile picture
Aug 1, 2020 13 tweets 3 min read Read on X
hard or soft code and design? that is the question. and welp, there's a reason we call it "soft" ware
the soft in software means that the code and design must be malleable and durable

- malleable code is easy to change/refactor without having to jump many dependency/build/compilation hurdles
- durable code is easy to change/refactor without breaking other parts of the code
the design ninja masters and even doting design stans like myself talk about "good" solid design, and about supple and strategic design (#ddDesign). design that elicits high UX for other devs i.e. DX (@CarlosRucker); regardless of paradigm i #ooDesign #functionalProgramming, etc
good supple design/code is arrangement of software elements, in a way such that

- the code clearly expresses it's intent and corresponding user scenario in the stakeholders' language
- the code is SOFT, i.e. malleable, changeable, durable
the soft supple design/code we wanna produce is achieved through use of modeling patterns like:

- interface revealing interfaces
- side effect free functions
- assertions
- conceptual contours
- standalone classes
- closure of operations
and "beautiful looking code structure, objects/ APIs that are enjoyable to code with come also come out of

- solid, grasp, principles
- gang of four patterns
- kiss, damp, dry, yagni, tda, pola practices
hardness in design and code can manifest as rigidity and or fragility

- fragile code is easy to change/refactor but also easy to break
- rigid code is hard to change/refactor due to constraints with dependencies/build/compilation
being able to name these conditions of hard and software rigidity, fragility, arms you with justifiable motivations for
demanding the time and space needed to produce the code quality you want to; here you know how to concisely describe a situation you want to avoid
appendix: there are more terms that illustrate poor design like immobility, and viscosity

- immobile code, you avoid reusing as it carries too many dependencies or tech baggage
- viscous design is all over the place, without a clear theme or vision, not uniform, hacky
and there is brittleness vs durability which afaik are other qualities that go more into the functional aspect of the system;
but here im more interested in application design/architecture than the runtime aspects
my code used to stink at first. and stink bad. i have produced all manner of rigid, fragile, immobile, viscous, brittle, rotten code in my time.
then i learned about code smells, developed a sense for anti-patterns over time. learned about patterns. and the anti-patterns i was following. and after breaking things, making coding life hard for myself and other devs, now my code is still funky but in the better sense lol 😅
anyways that was another lil ramble for the time being; these are some patterns and principles i practice in my work daily; always a work in progress toward self/craft mastery
ref: the blue book #DDDesign
ref: cvc.uab.es/shared/teach/a…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with rasiim shabazz

rasiim shabazz Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @refactorfiend

Oct 18, 2020
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
domain driven

- problem focused
- to stay focused on the actual problem
Read 122 tweets
Oct 17, 2020
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
with the quickness #manifesto
Read 6 tweets
Sep 30, 2020
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:
1. pick a language, any language. or framework, library etc.

no tech is perfect. don't sweat it the choice too much. they all have pros and cons - but do try to pick one that has good community adoption so you can get help when you run into blockers
Read 13 tweets
Sep 30, 2020
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:

1/3
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

2/3
Some benefits:

- helps keep the class/application at the appropriate size

- helps make the class/application be easier to understand/work-with

3/3
Read 4 tweets
Sep 30, 2020
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
"you're the worst president evarr"
Read 4 tweets
Sep 28, 2020
"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 ...
but man is it an over-abstraction time suck when trying to just focus on "keeping it simple" KISS minimum viable product. gotta draw the line somewhere and make concrete classes and move forward ...
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(