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
humility and awareness opens me up to different ways of doing things. different possibilities. and at the end of the day, generally speaking - better, more useful code, designs, and skills
as time passes i am quicker to take the position that - a) whoever is on the other side of an argument, with whatever title, knows something that i don't know, and that - b) time is the best teacher
the prerequisite to this is that a person actually wants to accept and adopt the best and brightest ideas from others, who hold whatever title, at the expense of the stroking of his or her own ego
and that's a whole 'nother story 🙄
on the flip side, sometimes i question myself about whether or not i was hungrier then. but no - im just as hungry if not hungrier, just that the hunger is a bit more particular about what i will, or have time to eat, so to speak
so like i said imho, the senior/junior comparison is moot - fuck a title - it comes down to having respect, empathy, compassion for, and collaboration with the people you work with - in all directions. up, down, to the left and right of the org chart - senior to junior to senior
but that's just me. one guy one pov. thx for letting me ramble, now back to coding and gaming and parenting and the so called adulting us "seniors" do on 2020 Saturday afternoons 😅😋😆 respek szeein 🙏🏾
what do you guys think about the whole comparison and the debates around it?
i am very open to hear other perspectives on it.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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
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
"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 ...