I feel that in various communities, in various languages across different framework and languages, there are lot of tutorials but those are mostly for beginners.
I really wanna ask that how can I grow myself from somewhat better than beginner to expert developer as always I do coding required to make the needed piece but i always think would there be any better way ( to which I have no clue how to reach) ?
Collaborate in open source projects. You will get amazing feedback and you will be forced to read other peoples code.
Read about algorithms and design patterns. You won’t necessary be using them but they will improve your algorithmic thinking.
Always strive for KISS and DRY
Learn erlang syntax and then read through otp and erlang docs and books.
DRY IMHO is often wrong goal in itself, because as I heard it first from Sandi Metz “Duplication is better than Wrong Abstraction”, and I wholeheartedly agree with this. I think the best way is not to over-engineer things, that’s why agree with the KISS part.
Write a code that is easy to read and does what it needs to do, if possible (and more often it is than isn’t) break big chunks of code into smaller, write functions/modules/classes that do one thing and they do it correctly. Don’t write code just because You think you may be needing later, because if you will need it, you will write it then, and if you don’t you have a piece of dead code that only makes it harder to reason about whole function/module/application.
And solve problems, write more and more code to become better programmer. Because it’s practice is what really is needed. But to be honest the most important part is not actually writing the code, but thinking about it. Over the years I taught myself to start coding with paper and pen. Just write/draw program/function flow on paper (for yourself), think about potential edge cases, can they be avoided, should they be avoided and/or handled. If you can don’t search and learn libraries for simplest tasks, but write the code yourself, think how you would solve given simple problem and then compare it with solutions from well known/used solutions. Often your own few precise lines of code are going to be better solution for given problem than a generalized library. But don’t do it for big things that are really complicated. i.e.: I won’t write my own SQL data mapper (i’d probably use Ecto), but I won’t be using library (other than http client) when I need to fetch and parse some data from elasticsearch (because it’s often more complicated to make library to work, than craft an http request and parse response yourself).
Just my 2 cents.
… maybe you should try to write your own mapper - in order to more deeply understand what the design decisions involved are and why Ecto may have made its particular implementation choices. Writing code to throw away may not seem “productive” but is sometimes necessary for building skill and understanding.
Even “expert” developers are beginners at something - they just have to skim past the “basic stuff” to get to the interesting bits. And with new technologies “beginners” are usually the larger audience.
One thing that will get people stuck in a “beginners loop” is if they never grow beyond the “framework user” stage because that type of knowledge goes stale incredibly quickly. Typically learning investment into mastering core technologies stays relevant a lot longer. By extension the technology independent, computer sciency stuff has the longest useful life. In order to “be productive” you need to find the right framework/core/CS skill balance.
With that balance your should have enough background “to build your own framework”, not to put yet another framework on github but to create an understanding of the design challenges involved. That understanding should make it possible to choose the right framework for the job (rather than going by popularity), have a better understanding of the framework being used, or building a more suitable minimalistic version. It also should make it easier to avoid “framework fatigue” when moving to the next framework because a lot of the core ideas don’t change.
If it’s about me, then all I can say I did, in Java, exactly for learning purposes. And the most valuable lesson I learned is that often all the ORM’s are abstracting too much, and they makes simple tasks easy, but they tend to get in a way when the queries gets complicated. And by “I won’t write my own SQL data mapper” I meant, but was not clear about it, that often you don’t need to write a general data mapper, because translating SQL records to data structures in any given language (I know) is really simple, and learning that goes a long way; the SQL composition is the hard part, and no ORM/DataMapper won’t give you the flexibility raw SQL gives. But its also a tedious work, when it comes to translating db records to app structs in simple CRUD’s so id rather offload it to said Ecto.
And if it’s a general remark… it’s hard not to agree with what you wrote
Read books and do recommended online courses.
I can’t stress this enough - there is so much fantastic info and knowledge in books, especially those that are published by top tech publishers such as PragProg and Manning.
And this is important to experience first hand - before that point
So while in general it still makes sense to reuse something that already exists, especially something that has been battle tested, one needs to be aware what tradeoffs are being made like:
- Is this library/framework pulling it’s weight to justify another dependency (and all it’s dependencies)?
- Is this imposing abstractions that aren’t appropriate to the problem being solved?
FYI: Framework Bound
ORM/DataMapper won’t give you the flexibility raw SQL gives.
Data Mapper technology tends to be easier to grasp once you understand SQL (which draws on set theory) - core technology before library/frameworks.
DRY IMHO is often wrong goal in itself, because as I heard it first from Sandi Metz “Duplication is better than Wrong Abstraction”, and I wholeheartedly agree with this.
- Development by Slogan with DRY: Part 1, Really DRY (2015-Jan-01)
- Development by Slogan with DRY: Part 2, The Tower of Coupling (2015-Jan-08)
- Development by Slogan with DRY: Part 3, DRY vs WET (2015-Jan-09)
I think the best way is not to over-engineer things
It tends to be over-engineering when we are trying to predict the future - which most of us are notoriously bad at. However then you have this:
I have to assume that it was successful because the architecture embraced change without trying to predict the shape of change. But they didn’t get there in a straight line. By 2014 WunderList was on its third rewrite. And right now Microsoft seems to have difficulty assimilating it (possibly due to cultural reasons).