The job of a software developer can be summarized into two words: constantly evolving. Anti-static. The nature of software demands it since modern ...
For further actions, you may consider blocking this person and/or reporting abuse
This is a wonderful idea for learning languages, frameworks, and any/all of the fundamentals. However, I think the process of black-boxing is still incredibly useful, as long as you use it correctly. As you said, sometimes it's good to reinvent the wheel. But at the same time, you can't know everything, so you have to find a way to, at the very least, comprehend those other concepts.
I absolutely agree. The black-boxing (abstracting behavior) of things is what programming is all about. My goal with this post is just to bring attention to the fact that the underlying experience of programming brings so much intuition and power to the developer if he invests in the basics, not just the high-level tools. Both developers will achieve the goal - but the one that has the basics covered will use their tools better. :)
Totally agree. I mean, going deeper is a good thing to do. Still, I think the black box idea should go first. Since you are taking time to learn, go black-boxing rather than go deeper. Seeing things not working or struggling with something may be frustrating sometimes.
This is something that I have started to notice. A few decades ago, software engineers didn't really have abstractions that we have today so they learnt how the systems worked under the hood. We developers have it easy nowadays.
I have recently started learning the internals of how Rails framework works and it's internals. I don't understand half of it but what I understand is just beautiful. I hope more people will try to learn the interns of their favourite libraries/frameworks and try to implement even a small feature of it on their own
i totally agree with your post. Nowadays, Many modern developers including popped out from boot-camp, to get a job easily, just made abundant projects without fully understading how they worked. And when faced with technical interview, they didn't explain the process of their projects due to the lack of deep-comprehension.
So this is my conclusion: make a project one-by-one with fully understanding.
It is a very insightful post! After all, it is all about the developers' mentality in learning. I came across few people, one is a self-claimed backend developer and a young chap who just learnt about shopify in 1-2 years experience. Self-claimed backend developer just sticked with Hugo static web generator and refused to learn more about the latest technology(other frameworks, cms etc) and more on html, css and javascript further.
Another young chap who worked as a marketing executive and had 1-2 years experience in setting up shopify, fired his boss and thought he knew it all.
"Stay hungry, Stay Foolish" will be a good learning mentality as always. Like Oscar said, no one will know everything, at the very least, comprehend those other concepts. And also, there has always been new frameworks and technology to keep up with.
It will be great if developers in dev.to community can work synergistically on game-changing projects and make impactful breakthroughs with our skillsets.
This. So much this.
A frightening number of new developers I interview are - to my mind - worryingly incompetent (for want of a better word). They have a convenience culture mentality of programming where they just want to do 'cool stuff' as fast possible (to get 'likes'), without having any real understanding of how the stuff they've built with 'off the shelf' components actually works.
This really needs to be addressed... I think it is a big problem for our industry.
Learning fast is great
I did my first course ever two years ago. HTML and CSS. And JS was my first programming language ever (and it still is). In these past couple of years, after making so many mistakes -and keep making them of course, but we are friends now), and going through courses, Udemy, Full Stack Web Development Bootcamps, and many different books; after CRA and thinking ok, it's enough, I'll learn Webpack, I think -it's just my humble personal opinion-, that too many abstractions when you are just beggining, well, does not work. I mean, and I'll give three silly examples: 1. If I am asked if is it possible to build a constructor function in JS using arrow functions and I'm not sure, or can't give proper arguments for my response, I would wait until I begin to learn whatever JS library or framework is around. It might not be wise to put another layer of abstraction over a layer of abstraction that I don't really get.
If I use too many divs or spans in my code well, I would start all over again.
If I can not replicate the layout of an average web app with pure CSS, I would not bother myself with Tailwind, BootStrap, Chakra, Material...
I really think this is basic stuff.
I won't talk about backend until until I learn why and how (and learn is being able to explain it to others), async/await are just promises with restrictions, until I get CORS, and the Internet Protocol Suite. And of course write some proper SQL without an ORM.
Very nice article I have got it at the right time, but I think it's also very important to know when you should re-invent the wheel and when not to, cause it's not good for business, time efficiency and can hinder progress, but at the other hand it's very rewarding and it can get you like a virus and you start wanting to re-invent everything or am talking about the curse of curiosity if you like, here is my joruney in brief:
wherever possible don't attempt digging into why and how a wheel works or how it was made, it's a very death reckoning journey, I wanted to make react context better by making it a full blown state management library, guess what I found 🤦♂️🤦♂️🤦♂️ 3 months upto date am still researching the topic, near everyday and it has quite helped, cause over this weekend I was able to roll out state management in this framework am making using plain js, thanks to my digging into how react does it, so you can try to look through and also give some feedback: github.com/javaScriptKampala/z-js/... but back to this,
yes if I knew what I was getting into, I wouldn't have started, it turns out state management is one of the hardest things in react, I think if react ever makes it inbuilt it will become the most powerful framework of all time but now it's a library and they too know it's a hard topic that's why we have these third party libraries like redux to tap it, and in my workings, at some point I just ended up re-inventing some existing libraries and cross checking to find they work exactly as what I had got to, and then I iterate and like that, it was a terrible idea to start with, though rewarding,but in all I want to make a global useState hook for react thus even whatever existing is not enough, this is what am working again to solve state management in react but github.com/javaScriptKampala/react...! 😂 but know when to re-invent the wheel.
You should always re-invent the wheel when learning something new. Your comment only applies to people who already know the tech in question.