7 Tips to Grow as a Developer
Vložit
- čas přidán 29. 06. 2024
- I meet many programming students. Here are 7 opportunities to grow that I see time and time again.
🙌 / christopherokhravi
Books and talks from mentors that have shaped the way I think:
SANDI METZ
⚙️ geni.us/APcJLnI (Practical Object-Oriented Design)
• RailsConf 2015 - Nothi... (Nothing is Something)
MARTIN KLEPPMANN
🏛️ geni.us/Pj6IS4U (Designing Data-Intensive Applications)
RICH HICKEY
• "Simple Made Easy" - R... (Simple Made Easy)
• Rails Conf 2012 Keynot... (Simplicity Matters)
• The Value of Values wi... (The Value of Values)
ROBERT C MARTIN
🧼 geni.us/IBhtLnh (Clean Architecture)
MARTIN FOWLER
🛠️ geni.us/k8KhT3 (Refactoring)
KENT BECK
😸 geni.us/7PBVNF (Tidy First?)
🏎️ geni.us/Iwa0NPw (Extreme Programming Explained)
GARY BERNHARDT
• Ruby Conf 12 - Boundar... (Boundaries)
MISKO HEVERY
• The Clean Code Talks -... (Global state and Singletons)
DANIEL KAHNEMAN
🧠 geni.us/Jtc6 (Thinking Fast and Slow)
PETER DRUCKER
🧑💼 geni.us/LqFHE (The Essential Drucker)
CONTENTS:
00:00 Intro
00:07 Don’t Fear Deleting Code
01:53 Define The Goal
02:54 Embrace Debugging as Learning
04:09 Find & Follow Mentors
05:12 Articulate Your Ideas
06:10 Learn Fundamentals, Not Frameworks
06:55 Explore Other Paradigms
07:18 Outro
Learning fundamentals instead of frameworks is a godlike rule
Step 8: Follow this guy❤
Man, I am really happy that you have returned to yt. one of the best programming advice/tutorials, I've seen
Agree. Nothing quite like this on CZcams. So incredibly valuable. Thank you!
I was a software developer for 30 years using all the major languages. I was a manager of a team from time to time. We hired both contractors for short term projects and full time people to keep over the long term. So I interviewed a lot of candidates. My usual stock question was "Tell me ways to make sure your code never, ever fails when it goes into production. How can you make it fail-safe?" How they answered this question told me a lot how well they coded to handle various situations and how they tested their code. It demonstrated experience and maturity. I will say that if you want to be a good developer then think about my question before you release your code to production. Think about how it handles all situations reliably, smoothly, and solidly.
Excellent question. Thank you very much for sharing. 😊🙏
Git is a godsend when it comes to #1. If you're like me and feel a frantic fear of some part of your memory being erased when you delete code, by all means, learn to utilize git. Deleting your code is more like cleaning your workspace and less like killing your pet cactus, when you understand that the best place for the code might not be right in front of you.
Teaching others is not only a great way to learn, but also to inspire others to do the same! On more than one occasion, a person I was mentoring has taught me something new, which hours of reading documentation couldn't. People are innately communicative, so it's important to capitalize on it.
My "mentor" is Scott Wlaschin. He's so good at explaining functional programming concepts it's very life-changing
Ooh I had forgotten about this guy. Thank you for reminding me 🙏. Now I need to dive into that rabbit whole for a few days 😊😊
Good to see that you're active on CZcams and uploading new videos. Thank you
these videos make me so happy you're the perfect blend of animated and articulate that scratches my intelligent and juvenile tendencies i'm learning so much and you haven't spoken a single line of code i LOVE this channel
Thank you very much 😊🙏
My "mentor" was John Carmack, the guy who programmed Commander Keen, Wolfenstein 3-D, Doom, Quake and so much more. I always read any article he made, and because of him I learned how to debug at an early stage, and selected a Minor that taught me Functional Programming (I now easily understand C code that borrows some FP notions like "callbacks"! :D ), Parsing AND Regex.
I'm pretty sure I've become a much better programmer because of his articles alone.
I've found the best way for me to learn is to decide on something to make and just start making it. The first 15 tries are never very good but I learn something at every step. Eventually I get there and am better for it.
I very much agree. Thanks for sharing 😊🙏
Great that you are back! Amazing content and inspiration
You're the best! Continue sharing content, tech needs it. Thank you Chris.
This is my first comment for a video in English. You are the number one who explains everything clearly and simply. You are a great teller. Thank you a lot.
Thank you 😊🙏 I'm happy that the content is useful.
You are my virtual mentor ❤... really first principles and fundamentals... very few teach on YT like you
Christopher you're amazing. I really like your videos and your passion when talking about your ideas. Keep it up =)
Love your energy man!
Loving your tutorials! 🎉 thank you!
excellent tips on so many levels...teaching, learning new paradigms, stick to fundamentals...these are all much more powerful than many will realize
You're such a blessing. Thank you.
Thank you! This was great!
Great tips. Love your content
Thanks for sharing your mentors mate.
Thanks, Great sharing.
Again another great content. Thanks a lot
I needed this 🎉
Great content buddy, I really enjoy your thoughts.
Amazing and informative thanks man
I love that you recommend books. I bought a few of your recommendations (design patterns, elegant objects) and they've been incredible. I've found reading long form text is a great way to reinforce fundamentals. Thank you 🙂
Thank you for letting me know this. Also thank you for buying the books 😊🙏
Amazing tips!
Thanks for your mentoring
it si very motivating watching ur videos, thank u for ur time
Thank you!
Excellento! Thanks
Good tips. Thanks
Legend is back!!!
Great video thanks!
While I see the value in the tip "Articulate your ideas" as a way to grow by teaching others, I have mixed feelings about it. While teaching can indeed reinforce one's own understanding, I believe it's crucial to have a solid grasp of the topic first. Publishing technical articles without a thorough understanding could potentially lead to misinformation and waste the readers' time. It might be beneficial to suggest that one should assess their proficiency in a topic before attempting to teach it to others.
PS: You have been a mentor to me
thanks for the tips
I love his energy
Thank you this is the usfol tip I will do it
Absolutely concur, though I must diverge on point four. Frankly, 80% of these so-called mentors are utterly redundant-don't bother seeking and shadowing random individuals. They merely regurgitate academic drivel. The genuine mentors, the ones truly worth their salt, will naturally appear once you've immersed yourself in the genuine professional milieu. Stick to that path.
Great content! I would love a video providing examples for some of those rules, e.g. (Learn fundamentals instead of frameworks)
Great idea. Thanks!🙏
Best way of learning is teaching
Oh! Video for me ❤
Afraid of deleting code -> Accumulation of more tech debt -> Feature conflicts with existing debts -> Necessity to delete even more code to rewrite and address the issues.
Having your opinions is very crucial. There is a bad reputation around the C++ programming language, due to the complexity of debugging null pointers, ugly syntax, etc. That reputation prevented me from picking C++ for a while, but I gave it a chance. To be honest I found it quite intriguing and that complexity and freedom are what I mostly like in that language. It is my third language and first low-level language.
Thanks for the video!
I can suggest Tim Cain videos on CZcams. It's more game development oriented but still he has lots of great videos about team work or about problems that programmers might have.
Thanks! I’ll check him out immediately. 😊🙏
Nice 👏
You deserve more views !
Thank you 🙏😊
Learning with you is very interesting ❤
please provide us with more channels for great mentors, and I want a place to let me have a mentor to learn and to ask and to guide me in software journey
you are good mentor. :)
Wishes for future video: Version controlling! After 1, I started thinking, there must be deeper thinking and different approaches there as well?
Tack Jon! 😊🙏
8. Know the difference between Data Oriented Design, OOP (class oriented programming), and BOOP (Smalltalk object oriented programming)
9. ABC
Always
Be
Sell- I mean Curious
About the tools and design philosophies
10. Have side projects to explore your curiosities outside of your main work
11. Learn digital communications to properly align with product and sell your solutions well without being mean or unconfident
12. Get good at sketching out your ideas quickly both digitally and on paper/whiteboard ;)
13. Practice steelmanning other people's decisions because we already get plenty of practice strawmanning everything as it is 😅
14. Know that no requirements are set in stone, so check in with stakeholders at every development stage to make sure there's no surprise behavior. This kind of development is a team effort, after all.
Thanks for all the detailed ideas. 😊🙏 Steel-manning is indeed very underrated. 😊
Can you make a video on Metaclasses metaprogramming and ites importance
"Rich Hickey". Ok, Sir, you have my thumbs up ;-D
😊😊
Can you recommend a good starting point and mentors for functional paradigm?
P.s. if you find yourself interested in entrepreneurship you must read Peter Drucker’s books.
I would add "do things even if you don't know exactly how it works, then learn through the process". But perhaps it's part of the topic 1
Great point. I agree ☝️😊
4:50 Cristopher Okhravi
🙏
Deleting code is the most difficult to me. But I am getting better at it by first commenting it and then after a few days delete it saying to myself "I forgot what it was for, so away with it"
It is difficult to me too, but at least with more 'modern' versioning systems it is now a good deal easier (I use the "Oh well, I can always find it again, if I *really* need to" argument). Often, I like to commit the old code as commented-out, it shows the code wasn't so much fixed/repaired as it was simply retired.
I've gotten into the habit of type git reset --hard. Often that is the fastest way to the solution.
we don't got the right tools and patterns for making good software, we can get close with a mix of stuff but we still don't get the right stuff.
we need a language that is made for the ever changing software, we need to index all the kind of errors we make, and add patterns to the language that "save" us from making the errors.
Rust is closer to this, but then they added lifetimes and made a whole new group of errors and problems.
95% of errors is null ref. or null errors, so we need Maybe from FP. build in to the language.
can you see a group of problems or errors ??
then think of a way you can remove it from software?
8: Console logging is the best debugging method.
Fight me
Actually I tend to prefer that as well since I’m a heavy Vim user 😊😊
@@ChristopherOkhravi i also found that any race conditions won't really show up when debugging normally, but will show in console logs, since you'll realize that the logs will be out of sync compared to what order you thought they would be in.
6:43 did he misspeak here? wouldn't you want lower-levels of abstraction (minimal frameworks)
Thanks for the feedback. I suppose it’s a matter of interpretation. I’m not big on focusing too much on low level code. I tend to favor learning big abstract ideas that are broadly applicable. Think: Learning map and reduce rather than the difference between pre-increment and post-increment (as an arbitrary example). So it’s in that way I was meaning that we should learn the abstract ideas that are found at the core. I can see how this formulation might seem like an oxymoron however 😊. Thanks for the question and for watching 😊🙏
Funny guy 😂
1.
Please, yes, delete code, dont riddle the codebase with comments that will never be brought back to use.
1:17 instructions unclear, deleted the entire Facebook codebase
😆
Thank you!