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
2. commit. stop worrying about other tech for now. make space. no fomo here.
you're gonna need to commit some time, space, energy to this one thing for a lil while. so be kind to yourself and remove distractions as much as possible
3. spend first few hours on articles, videos, tutorials, etc.
doing is the best way to learn, but initially you'll need to spend some time learning the basics. read, watch videos, do a quick tutorial or course, whatever suits your steez. spend 1-2 days max
4. imagine an app you want to exist, or to extend or re-create
look around at existing apps you like, can you do a spin off of it, can you extend it, or make a simpler bare bones version? if you're at work, look at your existing systems' code bases and use your imagination
5. code it in the language you chose
this is the fun part. create your app, tool, utility, extension. bring your idea to life. manifest your vision. have fun.
6. don't give up on it
when you hit a snag, the documentation, google and stack overflow are your dawgs. work on it until you're satisfied with the app/s you built, or until you're confident about considering yourself "ramped up"
7. repeat steps 2-6 til u make that language bow down
some tech is more complex than others, so you may have to take more time on it. that's fine. this process of getting a good grasp of it is only developing stronger skills.
so that's basically my workflow. i've done a version if it many times over the years on both professional and side projects.
ive taken these steps for like every single language or framework over the years, easily 2-4 times a year
im actually doing it right now tryna ramp up on #graphql (im at step 4 now)
and i'll no doubt be taking the same approach in the next few months or so, into the future
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
"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 ...
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