Be An Engineer, Not A Frameworker | Prime Reacts
Вставка
- Опубліковано 21 вер 2024
- 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
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
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
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
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.
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.
I mean, that's definitely a thing that happens...
@@jenot7164 Do you know any good video that goes over such programming concepts? Testing the water into webdevelopment, would really love to get the basics down!
Yes be an engineer! If only companies listened and didn’t include a specific framework as “required” on their job applications…
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.
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
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 😂
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.
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.
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)
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 :)
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.
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.
Completely agree, trying to anticipate future changes always becomes a mess
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.
This is hands down my favourite programming/frameworking/engineering channel!
Prime "Don't define yourself by your framework"
5 seconds later...
"I'm an HTMX developer"
Keep it short bro. We don't have 27 mins for 2 mins of knowledge.
i also wish it was shorter but i dont think its his thing, injust fast forward a lot lol
I like listening to his voice when I'm falling asleep or writing code.
Keep it to yourself bro. We don’t have time for folks with short attention spans
It's good to listen to in the background to gain knowledge casually.
The less we watch, the less he is compensated for providing free education
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!
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.
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.
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
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.
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.
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.
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.
Being able to defend your ideas is something an engineer should be able to do
The bit about "building for a use case that doesn't exist" really hit. An engineer would build the product to the specification of the customer needs. "Anticipate their future needs" is a waste of their short term time at best, and a waste of everyone's time at worst.
Agree 100%, but sometimes it is not so easy to change context between different tools (frameworks especially)
yeah, it takes lots of time to deep understanding about the tools and It's uses.
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?
I'll do you one better: be a scientist, not an engineer
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).
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.
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
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.
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.
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...
If it's so bad to be a framework then why is it Prime Reacts and not Prime HTMX or Prime Angular? Got em'
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 employers are more to blame for this! They need framework devs more than the core language!
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.
I'm a programmer. I work with programming languages/standards/APIs/libraries to architect/design/plan, build, fix and improve tools and applications.
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 guy is hilarious. We need more frameworker programmer engineers like him
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.
I liked that: "Never use inheritance" ;) I like to use the class free approach with mixing-in functionality from other objects more.
Remember the preferred language of engineers (non computer ones) is MATLAB...
You bleeping rat and after bleeping nothing, made me laugh real good, thank you ❤
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.
And then there's me: a game designer, who learned programming because no one would do it for me. And became a quite decent programmer in the process. I don't care which tools to use, as long as they provide an easy means to make my ideas into games.
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
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?
This author has hit the Dunning-Kruger inflection point, give him another couple years
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.
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 thought I knew what I was doing when I was programing. Until I learned algorithm and data structures. Then I understood how stupid I was.
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.
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.
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?
I got roasted at the end about not being able to defend why inheritance is bad. Ouch
How can I make these things clearer in my head?
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
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
I think it is good to know the underlying things. but every driver does not need to be a vehicle design engineer.
Knowing only one framework is the best way to go.
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 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
Engineers make the plans and Frameworkers do the welding (Copy Pasta).
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.
"Don't define yourself as a (language) developer or a (framework) developer, you're a software engineer. Hurray!!!" And then proceeds to express all his personal prejudices against C# and asp snakes. Is Hypocrisy a framework they use at Netflix?
"A framework that calls itself a library is worthy of being the type of developer you are"
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
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
To weed out Engineers from Frameworkers: ask Java Frameworkers to build a web-application without any framework. A simple MVC application with just 3-tier layers and see for yourself
Regarding the "engineer" terminology, I have a hot take. I have a BS in Computer Engineering (and then eventually transitioned to web app development), and the education and systems (low and high) required for "engineering" is far more substantial. You don't know until you go through it. Yes, there are many parallels and complex software is difficult, but ultimately software is rules based, like hardware (an often forgotten concept), except without physics your system is defined by different kinds of rules. The floor of entry is different, but the heights are not dissimilar. The hangup I think really comes down to accepting that software is indifferent of physics; a foundational construct of "engineering".
I feel that engineering is an action anyone can do with no degree, but the concept of engineering a product will certainly require you to commit harder to learning than you've ever committed - unless you're a mechanical wizard, where it's probably a lot easier to understand abstractions and reconstructions. I didn't get to the part you're referring to yet, but Canada is relying on "legalese" to keep its people down in many ways
It's a really helpful & informative video. Which helps to understand the current scenario.
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 .
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
@@СлаваВолошин-ы3с 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
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.
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.
😂
Anticipating change is more often akin to premature optmiziation than good engineering. Keeping things simple and introducing changes only when required is a safer bet.
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.
"nobody is building a bridge out of C-Sharp"
So I built a full stack framework. It's called Flython. Flutter business in the front, Python party in the back. My solution to the interface problem smells a bit like Tom in that it involves specific formatting rules for a set of JSON models that are synchronized into auto-generated front and back end models that are immediately accessible as first class, simple objects with intellisense in both code bases. However, the rules are pretty simple. There's only 5 of them and they take about five minutes to read and understand if you've ever called a back end with JSON before. I chose JSON for the model format because it's something most web developers on the front and back end have encountered, and it only really gets confusing when you start adapting it for use cases it wasn't built for. There are ways to keep it perfectly interchangeable with SQL-like data structures for any kind of ML or data analysis you might need to do with the contents of your models. My rules are designed to achieve that.
Link or it didn't happen. This sounds like a wondrous abomination
note to self and other devs: in future, don't post Github links in UA-cam comments. They get removed apparently.
wow. So I guess either Prime or UA-cam are gitblocking my links to the repo. Just know that I am the owner of thecodekitchen, and I did a flython. The curious reader may theoretically infer a link from these facts in context.
@@andythedishwasher1117 thanks for the workaround 😎
@@Dotrund Thanks for looking at it!
i actually agree with the article, an engineer is not the same as a programmer, engineering requires designing systematic approaches to solving problems, you can be a programmer without doing this.
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.
First 2 days learning python on Mimo and my YT autod this and I’m embarrassed and so lost😅 love the passion hope to rewatch this soon again with more understanding 😂
I'm really glad I learned software development before frameworks were a thing. When you look under the hood of all these frameworks there's nothing new under the sun.
I actually do not care about framework/language, but the recruiter does! Even though I have 5 years of experience as software engineer, they or the ATS would just skip me just because I never work with a certain framework/language. So, this isn't merely a supply side problem, it's also a demand side problem
Don't like that this article went the "tight coupling bad, loose coupling good" route.
Solving a problem comes first and API design comes later (if it is even necessary).
If you're scared of refactoring that's almost always a bad sign, refactoring is trivial as long as you don't abstract
for the most part i can agree
Refactoring can have different costs based on adoption of your code and company policy.
For example, at some point I used to work at AWS, and the mantra there was "public APIs never change and can't be deprecated unless there is a huge issue with it", which meant that whatever you put out there was yours to maintain forever. Refactoring cost was effectively infinite.
On the other hand, internal tools with relatively few users are easy to refactor, because you can typically go into each user's codebase and adjust their usage.
@@Murihey you're 100% right, but this is also a big part of why I don't like cloud software :p
When a library changes their API I immediately get compile time errors and the upgrade process is usually trivial. When SAAS updates you suddenly start getting *runtime* errors out of nowhere. Both from the client and server perspective it's a huge liability!
ive already said it so many times frameworks were born because we developers got lazy over the years that we do not want to write code and we are looking for shortcuts
Avoiding abstractions for use cases that don't exists. Difference between mid level and senior engineer. One driven by enthusiasm, the other by efficiency.
If you think Framework is doing EVERYTHING for you, you aren't building complex enough sites.
In short: "if you use a framework, leave."
Got it.
Inheritance is the magic power sword of OOP that you should seldomly use.
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.
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.
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.