Be An Engineer, Not A Frameworker | Prime Reacts
ฝัง
- เผยแพร่เมื่อ 17 ก.ค. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Article: / be-an-engineer-not-a-f...
Author: John Raines - / johndanielraines
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact - วิทยาศาสตร์และเทคโนโลยี
I'm a Senior Staff DevOps Full-Stack Prompt CloudOps SecOps Engineer.
Your name should be Tom!
No big data?
Bro you're not a engineer you're a company.
@@Emerson-mv4hm nooo tom is Hyper Senior Staff DevOps Full-Stack Prompt CloudOps SecOps SRE Engineer
You’re hired
Prime: "No one builds a bridge out of C#"
Unity Game Developers: "Are we a joke to you?"
😂😂😂
No no.. that's a framework ..
Don't destroy my ambition of making the newest gui with unity.
Am I programmer or an entity manipulator ... joke .. I'm a rustling
@@bluedark7724 You mean you are a framework builder?
nice joke
Keep it short bro. We don't have 27 mins for 2 mins of knowledge.
After 30 years of experience I can say, all you need is 30 years of experience and you're good to go!
Nah its still not enough 😅
Yeah! 30 years of experience but you need to have 25 years old
Rip i startee at 25 when im ready ill be retiring
Lmao damn it's that simple 😂
Well darn I might just die before I'm ready
Frameworks are not scaffolding. Scaffolding is something you put up temporarily and remove when the building is completed. A framework is more like a foundation you build on top of, including plumbing, electrical, sewage and gas lines. It can't be changed without demolishing your whole building and you're limited by how sturdy the foundation was made.
I agree, it is even on the name.
A framework is indeed, a frame for your work, you work between its limits, endure a lot of pain if you try to work outside, usually gives you a solid foundation, depending on the frame material.
I recognize frameworks as plugins for my apps. I design an application.
@@atam3977 I wish I could say the same, but if I shut down a "plugin" pretty much the whole app dies haha
True but also frameworks like certain building designs fail in particular situations where some situations/emergent phenomenon expose the fragility of that system.
The designer/engineer has to be able to not only reconstruct designs but even deconstruct them and be able to develop filtration methods to subtract other abstractions that increased system fragility and create a different system that responds to the problem in a resilient manner.
@@georgeokello8620 Everything fails, eventually
Imagine instead of hiring senior cook for a restaurant you would only hire senior spaghetti maker because your main dish is spaghetti. 😂
Ehhhhhh I don't know if I agree. You are more than likely going to use some framework wherever you are.
Call yourself a framework software engineer, idk.
The bottom line is you are developing a lot of the stuff inside some sort of framework and it's no different than learning the syntax of a language.
@@justSomeUserOnYTBut the ultimate goal shouldn’t be to learn the syntax. The goal should be to learn programming concepts that can be transferable across programming languages.
@@jenot7164 Completely agree. It takes me like 2 weeks to learn a new syntax. Yeah obviously I’m not going to be great and i’ll probably have to do a lot of googling and gpt-ing while I learn. But once you have lots of core programming concepts embedded in your mind, syntax/language really is a secondary thing. Every single “react dev” would be able to switch to Vue, Angular or Svelte with 1-2 weeks of learning the syntax. I wanted to try out PocketBase for my new app so I learned Go, it’s really not difficult with the plethora of online tools there are now.
Learning to read code at all effectively was by far the hardest part of learning to code for me.
I think this will always be hard as people write code differently. It is definitely easier if the code is written well and the coder have good practices.
Yeah cause last time I checked there wasn't a framework for reading code
Yeah, writing code is way easier than reading code!
Any tips on how to do this?
@@SCALENE5 Firstly write a lot of code, then read good code from good sources and try to recognize patterns, they usually come again and again. Over time it sinks in. It is hard tho.
I prefer to be called a Wizard or Magus, I compose software with my runic scripts that somehow compile depending on how far away we are from a new moon. Edit: Also, I have yet to figure out how to turn the copious amount of caffeine in my system directly into code, but when I do, I will trully acsend.
My Gosh, this sentence sounds so caffeinated
I prefer Technomancer as my job title, as it most accurately reflects not only the mystical status I seem to have in my clients eyes when I solve their problems but also the often esoteric means by which I am able to fix the problems in the first place. Sometimes, I myself don't even know or can't explain with mere words the seemingly supernatural power which flows from my fingers to tame the digital chaos before me; and like any practitioner of a magical art I often need to spend much time meditating on mystifying obtuse webs of seeming nonsense before I am able to move forward intuitively with confidence.
i felt that last part 😂
Honestly I think techpriest works better. Sometimes you just have to pray to the machine spirits that the code compiles and does what you want.
I see myself more like a tech priest, pray to the omnisiah, honor the machine spirit, give some blessings to the server and hope everything works out
the crazy issue about the tech world is that most employers refuse to hire the guy if he doesn't know the framework they are using, it doesn't matter if you are a powerful engineer who knows how to work on complex projects and solve problems or not
This makes me think of the best lesson I got getting starting programming. Knowing what you are wanting to do is more important than knowing how. You look up how, it's a matter of finding the right doc/stackoverflow/generitve AI output. Knowing why and what you are actually trying to do is what actually matters. After than you can figure out what tools would work to give you that.
One of the biggest lessons I learned while programming in the late 2000s and early 2010s was YAGNI. Yes, be careful not to make your stuff *too* rigid, but never prematurely add complexity for flexibility you might never need. Hell, that's one of the biggest problems with "enterprise OOP".
Fizz buzz enterprise edition
So true, so many devs get stuck with dogmatically applying stuff like 'clean architecture'. As if abstractions always increase code quality. Its always a tradeoff but it takes time to be able to properly judge when it's worth it and when not.
This is hands down my favourite programming/frameworking/engineering channel!
Dude, this is the kind of content I didn't know I was looking for. It's super relatable - these are the things I think about, but don't hear others talking about.
It's great to get fresh perspectives (doubly so when you* are challenging your own perspective).
Agree 100%, but sometimes it is not so easy to change context between different tools (frameworks especially)
Spot on, the feeling of realizing this could be done in all those unexpected new ways!, when looking at existing solutions to a well-defined problem in a language you're only starting with! It's precious, like stepping across a mountain pass to see a new vista. Love it
And sorry if I multiple-comment as I watch the vid but NO, in 8 cases out of 10, PLANNING for change is a bad idea. You barely get it right because the systems you work on are, in all likelihood, on multiple levels of abstraction, almost too much to hold in your head, and then you undertake to imagine how those abstractions may evolve? That's hubris. Short of a few trivial things, never worth the trouble. WHEN the need arises, change to adapt, not BEFORE.
Earlier in my career I was doing a lot of front end dev. Used Backbone extensively (with JQuery for DOM manipulation, hell yeah) and was unaware of the Marionette framework for Backbone so ended up making my own framework over a few years. Learned a lot during that period. Was really fun, too.
Woah. How did you even do that? That sounds really cool.
@@datboi1861 Cool is pretty subjective. After the my team started to grow new devs would say "this is crazy, you made a framework. Why didn't you just use Marionette?" XD
@@Muaahaa I understand what you mean haha. I personally think it's cool cuz the farthest I've gone with something like this is opening a server socket, parsing requests from an input stream and sending back responses with no frameworks in Kotlin.
I never got past that stage, so I think it's really cool that you were able to make a whole framework.
@@datboi1861 Ah, I see what ur saying. This was the result of spending a lot of time working on the same project for a couple years. And since this was for work, other people depended on me to build features, unlike most side projects. My side projects rarely go very far, too. Certainly never worked on a side project close to one year, let alone several.
@@Muaahaa You did that as part of your job?? That's very interesting! I hope to achieve the basic functionality of a web framework from scratch one day, hopefully in my free time and not during work or something lmao. Very cool stuff.
Good article, it drives me insane when I see people hiring for engineers named after frameworks, this article needs to be seen by more recruiters.....😂
Oceangate should have hired a carbon fiber engineer
@@thewhitefalcon8539damn, that’s deep.
Exactly this. I wish I had found this passion to always learn in this never done solving world of coding. I have hammered fundamentals for a year so far, and feel like I'm just now scratching the surface with a tiny bit of understanding.
This morning happened a funny thing. I'm an Arduino intusiast, today I was searching if there is an Arduino library that helps me with paralelism, because is a bit tedius to handle multiple tasking by my self and the code ends up a mess. But knowing how to handle paralelism with my own hands helped me A LOT to figure out how to use some of the libraries that I found. I think read and copy code at the beggining, paying atention to the code patterns and strategies, is the key to progress
Good take but yet another thing to fuel impostor syndrome. Now it's not just the usual worries, but also "am I just a frameworker?"
Nah man, first accept that you are a human that is capable of anything. This alone will keep you going in life with a rock solid confidence
I like imposter syndrome, keeps me on my feet
Hot take: impostor syndrome is only a thing because there really are impostors.
Do you learn stuff? Would you say you know more about code (be it framework, language or whatever) than you did last week, month, year? Then you are not a frameworker, or if you are, you'll soon graduate to engineer. Keep learning
@@xslashsdas I think this is a great perspective to combat this issue and impostor syndrome in general too. I am quite confident to say that I can apply most of my knowledge regardless of frameworks or even programming languages, so I guess I'm not a frameworker or at least working toward becoming an engineer :)
20:00 this is what I like about agile more than waterfall. All of the waterfall projects I've worked on end up with requirements so defined and design built around that when we inevitably found out it they were wrong that it just feels like a gut punch. Finding out that a month of work was off target is just less painful.
It's a really helpful & informative video. Which helps to understand the current scenario.
Completely agree, trying to anticipate future changes always becomes a mess
Man... This is a wake up call for me. I suppose I should hit the books more on programming essentials that I missed in college ed and have let atrophy due to complacency.
It's easy to let that knowledge go when there's no direction on what problem you're trying to solve and how you're supposed to solve it.
Guess I need to find/make my own and learn how to build an app from backend to front.
Thanks Prime. If you have any educational content on how to "Become an Engineer" I'm certainly tuning in to/buying that to learn from.
Most valuable skill for an engineer: Being able to ask client the following questions: what is exactly the problem you want me to solve? Why do you want to solve this problem? Why do you think solving this particular problem will help your business? Why do you think your way of operating your business is the one you need? Will you still have this problem if you switch to more optimal operation flow? Why do you think you're qualified to operate your business...
Why do you think your qualified to operate your business 😂
Honestly prime even tho i am in ur discord every other day for nvim help i wasn't 100% certain that ur youtube channel was really for me but at exactly 10:25, you got me man. I love ya dawg i'm IN
I have a great use of inheritance at my job that I designed. Basically a forms engine and I have a base component that has a lot of the core functionality setup. It then makes it super easy to develop new form components that work with the engine. It's only 1 level of inheritance though and it's a lot easier to manage. Either extend the base component or implement the form component interface and set everything up manually. It's been a very flexible solution so far and we haven't had much issues. It can definitely get out of control and I don't reccomend using it everywhere.
Inheritance make things easy, so it is hard to implement.
1: You need to be Novelist to handle 5 layer of super-/subgroup naming and semantics of objects, and after that, no one else can't understand your novel. Use only two level of inheritance if you are a novelist.
1. a: Most people are damn bad at naming things, so this cannot happened in general. So, only one layer of inheritance.
2: Never redefine superClass interface in subclasses. Not expand or subtract any part of interface.
If you have urge to do so, you know your object definition is bad from a start and your subclass is not a version of superClass.
I think reading someone else's code is pretty similar to reading a book. You attain good chunk of knowledge you don't know before or get a different perspective of something you already know. Both are pretty useful in the long term.
Great analogy. Let me add that reading a bad book that is 10000 pages is more par for the course.
Go Devs: We don't need a framework!
Also Go Devs: Gin, Beego, Echo, Revel, Martini, Fiber, Buffalo, FastHttp, GorillaMux, HttpRouter, Chi, ...
I like that "just use the language" mindset so why does this happen?
im not sure youre going to find many "gin devs" or "echo devs" in the go community. these frameworks (some are literally just http routers) you listed just provide some qol for handling, maybe validating, http requests and thats kinda about it. they dont prescribe how you should structure your project, they are not tied to some orm (like django, laravel, etc). even if you use gin, echo, fiber or whatever, youre probably still a go dev, not a framework dev
@@felipefelix92if we cut all the fancy words: There's no gin way or echo way to write go,but there's absolutely react way to write js.
@@spl420 exactly
@@spl420 It's just a library though. Can't change that much.
@@felipefelix92 I get your point. All of them take a standard handler-function with the request & response-writer and match it with a url. The frameworks like gin do the same but add a logger & validator.
It's fun to see the go community create so many tools for that though.
It's not gatekeeping. It's Quality Control. Bootcamps are an opportunity to get a foot at the door, not the end of the learning drive.
It only makes sense, considering that *alllllllllll* the learning resources for most CompSci are *free*. The Internet was *literally* made for this. Yes I am an entry level dev and I support this message. Don't slow down on learning in CompSci, until you're familar with Type Theory and college engineering math, can build your own compiler (bootleglang from a bootcamper maybe?) and are comfortable with Stats (ML and AI are made of that). Not sarcasm.
Never stop learning.
Preach
Agree. But also, stats and building a compiler are only useful to know if you need them. If someone is passionate about web dev and is planning on staying in web dev, what would those do? I believe every branch of development should learn different things
@@StarGuardianKassadin Agreed about being specialized :)
Just also being careful about knowing the invariant fundamentals when market changes and/or AI expands (either by actual capabilities or by market hype/management choice)
Example: understanding how compiler works helps in part create better frontEnd tools like Svelte. Also helps optimizing Javascript based on what the engine does. Might also come in handy when Wasm expands.
Stats can help for SEO. Even understanding the fundamentals can only bring a competitive advantage.
As usual, just IMO. But totally agree that specialization at this point is unavoidable (although dangerous in the medium-long term)
The journey from Frameworker to Programmer to Engineer is a crucial one in the software development world. While frameworks provide essential scaffolding, it's the deeper understanding of programming languages and the underlying principles that truly make one an effective software engineer. As a software development company, we couldn't agree more. Embracing this progression not only opens up diverse opportunities but also equips individuals to tackle complex challenges with confidence. It's about honing a holistic skill set that extends beyond tools and empowers you to build solutions that stand the test of time.
hey there, Prime!
I'm at the beginning of my programming journey, just a little junior dev with a little bit of experience in a lot of JS and TS projects, you know, being a side-kick here, there and in-between.
Definitely feeling that impostor syndrome, but recently, as i'm gaining experience, i've been leaning deeper and deeper into "yeah, this project is written like shit" territory and i don't really like it. Watching your videos gives me that so much needed confidence in codebase I'm working with. Not every project has to be perfect. Sometimes not abstracting is fine. Sometimes 300 lines abominations of functions are fine. Hell, sometimes even working with bad code and writing bad code is fine.
You sound so humble and so down to earth in your programming ambitions, your words ring a lot of bells and help me formalize a lot of my own not yet former thoughts and opinions.
Thanks for that!
If it's so bad to be a framework then why is it Prime Reacts and not Prime HTMX or Prime Angular? Got em'
This assumes your client or company will allow you to refactor. Most people are not given the opportunity to fix the behavior or generalize because they're too focused on short term features, fixes, and add-ons.
I would say that part of the problem is our industry itself. You might say "hey, I'm a frontend engineer", and they will ask you if you know React, they will go in the little devious (unecessary) details about React, and you might say "screw then", but "then" is a lot of people and sometimes you have mouths to feed.
Lot of people missing the point of the article - they're not saying to avoid knowing a framework, but to avoid ONLY knowing a framework
For topic around 19:30
I think it should be called "premature abstraction/complication is root of all evil" - it was never "premature optimization" but prematurely complicating stuff.
Yet I still think it is a balancing act of anticipating and generalizing the right things - and not at all set in store what does not need to be set in stone.
Premature abstraction can even make performance isues. One real life example:
inside a object method there was montrosity of list zip that are transformed back to list. Zip is pointer iterator, but now you have to make copy of those lists (memory manipulation performance issues)
But why transform to new list? Because you needed length of the zipped list in two rows down....
All this because you used list comprehension abstraction to cather data, then zipped result and after that you realize you need length of list and are forced to make copy of lists and calculate length. And all this is called in loop that replicate same calculation many many times in second.
Which could've been calculated once and stored to instance memory. (Fun time to refactor, when there was inheritance problem (interface violation) that was bind to this abstraction.)
The second pain is to make interface to every object variable, which just dilute the point of encapsulation and designers intent.
You really need to be damn novelist to be good at supergroup manipulation and prediction. Otherwise prediction is just noise to your future self, who now has knowledge of future and realizitation of failed prediction.
@@InforSpirit I also saw this done... Had worked with a project where I had to invent TemporalSpaceCache technique or optimizing an already badly entrenched architecture. It was cad/planning 3d software that literally recalculated whole-scene 2D clippings when you moved walls around... I could have made everything so local - that you only calculate anything locally, but goodness gracious to refactor whole codebase so I had to compe up with a caching system instead that helps performance with time and location locality at least....
So its basically a DP-like solution just because architecture was shit - but even the perf boosted solution is very sub-par to what would came from a non-overcomplicted architecture...
3rd part is textbook overengineering and preparing for the future that generally never comes. You can plan the nicest path for your software but then guess what? Life happens, business environment changes, etc. etc. In professional environment (not a hobby weekend project) good enough is enough. If you are trying to predict all bumps and engineer around them in advance, you will ship late (if ever) and life will still kick you in the nuts rendering all the good plans null and void.
I started questioning why I have to use Vue all the time for everything, especially since I really felt that I was lacking something beyond my usage of the framework. I realised I had no clue how these frameworks worked and that in the end I was just the end-user of a tool built by actual engineers. So I started looking into framework creation, even built my own tiny framework, and it turns out the concepts under the hood are quite simple to grasp. I really need to focus more on the programming language and not the tools for the programming language from now on.
I agree with you on not abstracting for presently non-existent cases. I used to waste so much time/effort trying to do this, and it was very rarely sufficient for projects which grew. It just further complicates the inevitable rewrite.
Being able to defend your ideas is something an engineer should be able to do
I like the overall premise "work on fundamentals instead of the framework" (especially when many people wrongly name fundamentals "basics"). I've seen so many candidates who memorised Spring manual but couldn't explain basics like immutability or buckets in a hashmap...
I think that "frameworking" is just a result of how industry works. Many companies don't want to hire generalist engineers and invest in them to learn some framework when they could "just" hire a developer with already few years of experience in that framework under their belt. It's the companies who make openings like "react dev w/ 3y exp needed" create a demand for Frameworkers.
Engineering principles ie "experience" can be taught at university, and honestly with the way the industry is trending. There will be a 1-3 year "trade school" where you learn frameworks or even programming. And then a 4-5 year honors/masters program where you learn software engineering. It's a fledgling discipline still, and roles aren't well defined.
My job has had way too much fighting developers on over generalization too soon. One of our major products went this route and now the code is not only almost unreadable but has duplicate cross-cutting functionality. That means some things happen TWICE in the same request when once was sufficient.
I call it a framework, if it is hijacking the main loop or entry point.
I call it an engine if it is limiting the language usage, or works independently (like a super-framework).
Otherwise it is a library.
loved what you said about not abstracting intentionally, that's wisdom and it comes from a place of humbleness, the people who create the monstrous cathedrals we see every day are arrogant and hubristic and unable to see their own stupidity
So i was learning Django built in authentication, and i was limited to the forms and User model fields in Django, i wanted a profile picture field for my users, but Django didn't provide one, so i had to create a custom user model subclassing the original user model in Django, and then specify the new fields i want. This was only possible because i know how python works under the hood, if i was not a PROGRAMMER, i wouldn't have been able to do that, i would just sit at my desk trying to fix a bug that isn't even there.
I liked that: "Never use inheritance" ;) I like to use the class free approach with mixing-in functionality from other objects more.
Prime: Stop saying that you are a Framework developer!
Me: Okay. I'm a Vim developer.
which vim framework are you using :)
@@vaisakhkm783NvChad😂😂
@@dmytrk Yo fellow gigachaders 🗿
Why can’t you use it though?
Imo anyone can program but not everyone can problem solve and provide solutions. Some people have brillaint minds and others are average. Its the way the world is.
A bitter pill many try to push aside
What text book, best seller or blog do I need to read to translate the advent of code problems to English and then to an equation that makes sense in pseudo code?
That welding analogy was pretty great.
My father use to tell me Be a JACK of all trades and to this day i dont stay within a framework and I look for any project to get into with the languages i come to know.
My favorite thing is going back to my old code to implement some new functionality and find out that I had already future proofed my code with that kind of functionality in mind.
Listening to you read and comment on an article about how bad of an engineer I am on my way to work to go code is something I really really needed. I didn't even recognize how bad they needed it. I hope you can do more of these in general about anything
still watching, but one minute in already I have a hot take: Saying you're a react dev is like saying your a Porsche mechanic.. sure you could work on Toyotas or any car, but specializing has benefits in that it filters out the crappy jobs you don't want.
well, it is a hot take, i'll give you that
These guys cannot differentiate between "this is the only thing i know" and "i learned to do everything but i settle for one things which is the most suitable for me".
I am .NET and Angular full stack dev. Does that mean I only know these stuff? No. I learned C, C++, Java, JS, Assembly, network stuff, security stuff, everything. I just choose a specialization for myself, that I wanted to be in depth with c#, thats it. I dont know why americans are so full of bootcamp developers, seems like most of the problems these blogs are pointing out is "you did a bootcamp, but dont stop there". I feel like this is not that big of an issue here in Europe, we have very few bootcamp coders in developer positions.
I will hire a Pro React developer to build my app, I will not hire a vanilla Js master who does not know any frameworks, unless I'm stupid enough to want my app built in vanilla Js.
@@envo2199 I was thinking about that recently, why are people so against specialization in our field? Practically, all the other industries don't work like that, like the mechanical example, if you are a mechanical engineer, you know everything that is taught at Uni, but after that you are going to specialize in something, Porches, Ferraris, Engine, Brakes, Gears etc ... and that is ok, you're not expected to know everything about all the things related, usually you work along other specialized people to achieve a common goal.
I think in our field, it is only good to have no specialization for money purposes, it is cheaper to hire someone that believe can take care of everything, people bought into that ...
@@RicardoSilvaTripcallshould this also apply to the Porsche engineers assigned to develop the next model?
23:00, 100% agree, configuration is not always the right answer. The more you abstract, the more you can end up in a maintainable hell. It’s a case by case basis.
Long time ago I used inheritance excessively. While it was a nice, complex structure that was logical, it had these moments where it I had to cast. In hindsight, I'd have fixed that problem today. But oh boy, I am glad I made that mistake and learned from it. I use inheritance rarely today. I use it in my big project at one point... and it may be a better idea to simply use composition instead.
This guy is hilarious. We need more frameworker programmer engineers like him
I plan my composition so that my code is modular for both abstracted and non-abstracted use cases
This vid really hits the spot. I want to like this 100 times.
If I hear one more job posting that says "this and that tool" I'd lose my mind. Too bad really.
I think Primagen’s take on knowing when to use certain ‘tools’ is the most important takeaway here. I worked on a framework for 15 years. We were constantly building abstractions in order to provide extension points for the framework. We had a rule that for every abstraction/extensibility point, we had to have at least 2 concrete and non-trivial implementations that utilized the abstraction. This ensured we spent sufficient time thinking about the abstraction before building it, and that we had really good use cases that justified building the abstraction in the first place.
"nobody is building a bridge out of C-Sharp"
The most versatile abstraction is an empty source file. Can't get more extensible than that. It also can never be legacy code, so that's an added benefit.
Why do optimizes that fit NN parameters use a fixed learning rate instead of determining step size via a line search or trust region like normal optimizers?
9:00 that's also common to infra/devops guys who have limited knowledge. Teach them about firewall rules and suddenly every issue is because of the firewall. It's just due to lack of reference points.
I'm a programmer. I work with programming languages/standards/APIs/libraries to architect/design/plan, build, fix and improve tools and applications.
You bleeping rat and after bleeping nothing, made me laugh real good, thank you ❤
This is true on paper but not really. If I am out job hunting and two places say we need a frontend engineer, and in the "fine print" one says we primarily use React, and the other list Angular, I am definitely not applying to the Angular shop.
I think employers are more to blame for this! They need framework devs more than the core language!
Got a Masters degree in Software Engineering and learned a ton so I consider myself an engineer but also I’d rather just be frameworker and program react for years
I've used inheritance the last week without regretting my decision. It is an extremely basic use-case but inheritance was simply the only thing that made sense.
I guess I'm a programmer according to this article. I could build something in pure JS/TS and I know what React can do. My problem now is that I cant really picture my way forward leaving me pretty scattered.
I'm looking at other languages, how to build servers, what a server needs to handle, wasm, native programming and all that. But it's just so overwhelming. I want to be able to do so much I pretty much run head first right into a wall of information.
I’m you, just replace the frameworks. I feel you, but I think if we just stick with it and never stop growing, then we’re gonna be fine. Life is long, we just can’t become complacent with what we currently do know I believe
The problem is trying to improvise your own educational path with a lack of structure due to the unknowns you do not know.
Look at mit opencourseware etc and backfill the basics. Or go the hardway and get old C programming books , data structures and algos, etc.
@@TheNewton thank you so much for the tips. Any structure to my future is welcome!
Hmmm ... bro, all I have to say is if you are really a programmer, then you are a really good problem solver. All you need to do is define the right problems, frame the right problems to solve ... and the rest you'll take care of. I mean, what are you gonna do in the next 5-6 months, how to allign your next career move with your interest and make it fit in the big picture of your Dream! All the best .
The "welding" analogy seems like the problem being described would be addressed with the use of mircorservices.
I think some of this is born of a natural response to job posts that just say React, .NET, Django, etc
Senior Engineer wanted.
Requirements: learned the react library
i can remember when i told my colleagues that i am experimenting with android in my free time and learning on how to write those android apps, and they were asking which spring framework is supported by which android version 🙈
Problem with that is that all frameworks take months to learn and your amount of hours per day is limited. If you learn Svelte, you can make any type of website, so you don't need to learn Angular or React to make websites. If you get hired at a React job, you'll be less valuable than if you were at a Svelte job because you'd need more time to get to a good skill level and speed that you were previously.
months? if you know what you are doing with JS/TS and with the framework you are already using, switching framework takes at most 2 weeks if it's something complex like Angular, which is using rxjs and services, which is possible you weren't using with whatever other framework you wrote in before.
Because if you know what you're doing it's just syntax, there's little new concepts, so it's really nothing to learn.
Say you're using Angular and want to switch to React.
You already know that to iterate a block of html in your template you need to use ngFor, all you have to do is discover that on react you use .map
what a banger video
thanks :)
man your streams are so fun lmao
I think the author is really driving at something more like "architecture" and every good engineer knows architecture is a luxury tax paid by tradesfolk (programmers) to keep managers confident their back pats are well earned.
😂
As a Canadian who can't use the term "engineer" because it's protected, it was very funny when he said "NO ONE'S BUILDING A BRIDGE OUT OF C#" lmaooooooo
Why??? Why can’t Canadians use it?
Engineers make the plans and Frameworkers do the welding (Copy Pasta).
Anyone know why he selects the text he is highlihghting so that the first and last letters aren't highlighted?
its such a small thing but I just notice every time
Sometimes I do interviews with "react developers" which even don't know about passing value by reference. There was one case wen JS dev spent about half of a day trying to figure out why his object is accidentally changed. He had objB = objA, then he mutated objA and he did not suspect that at the same time he mutated objB too. That was funny :)
Me too, they may even dont know how many bit in a byte. They are tooling programer, they can use tool but having no fundamental knowledge
Who trained this developers? Isn't Object.assign one of the first things they show you when talking about objects, even in academies?
@@StarGuardianKassadin they are self taught
@@user-ht6tu6ks3u well than no wonders they don't know anything. It's not even their fault, they lack the structure.
@@StarGuardianKassadin it is their fault, because they learned badly and started from framework and skipped language basics
what is up with inheritance ? can you share an example where it breaks ?
Avoiding abstractions for use cases that don't exists. Difference between mid level and senior engineer. One driven by enthusiasm, the other by efficiency.
I like that the most replayed point of the video is at 13:37. Feels appropriate.
I think when people say they are a framework developer is just to sound like the better candidate for a specific position that hires for that framework
I personally use this rule of a thumb to reduce premature abstraction: First two occurances are copy&paste&edit and the third occurance is the earliest point in time when it could be actually good idea to create an abstraction.
I hate premature abstraction and think that premature abstraction is even worse than premature optimalization.
If I wanna do migrations in PHP (I know you'll hate me for picking it) for instance I need to firstly build a simple crud with a flush button to flush dB & denigrate tables from the beginning ?? If I wanna understand a feature I have to reimplement it from scratch?
Reinventing the wheel is what makes you progress.
Knowing how something works and understanding how it works are entirely different .
Having a problem in a framework and not being able to solve this problem right now: This video hit me right in the feels but it's true.
Never studied CS though so I'd say I'm still an average bad programmer.
Edit: In case someone's wondering. I've moved my NextJS-App into tauri and would like to use trpc through websockets with an external server running prisma. I should probably rewrite it in Rust lol
20:10 I’ve definitely felt the pain of a typing system that was unnecessarily strict. For example, a function in Python that required a list when any iterable such as a tuple would have been just fine. There wasn’t even any consistency. Because of poorly thought out typing systems I was converting between lists and tuples all the time. Bad typing meant I had to do extra defensive programming. Sigh, I no longer work at that dumpster fire company. Thank the lord!
"reading lots of code"
That's the problem with black box frameworks. They assume you won't have to read the code, but that's a lie
reading code fast is probably the main distinction between being senior and being junior SE.
Boot camps definitely create this problem most often as they have a very limited time to teach a proper foundation and emphasize a lot more on specific technology stacks, one always needs a solid problem-solving and reasoning foundation with intrinsic curiosity of how things work. They are great at cutting out a lot of fluff on the plus side, but people in those programs have to do way more work externally.
I think the config approach needs a second thought. Keeping strings used in a UI in a config can help with maintaining, customizing, editing and translating all text in an app.
Still, if you are making a small app for with a single use case it's just adds unnecessary complexity and is a premature ejac-straction.
Prime: "you should know how things work"
My employer: "you're too worried about how things work, just fix what breaks"
Me: ....?
Without more info it's hard to know who's in the right here. At the end of the day you have deliverables to meet, and it _could_ be that you're spending too much time fretting over whether you have complete system knowledge before making progress. It could also be that your employer is being unreasonable and asking you to be a brainless code monkey. Hard to tell.
"What I find is that when I plan for a feature that may be , I create a path to hell." Soo good.
build for individual client at first. then maybe refactor/reimplement if more clients come.