By Saul Costa
Recently several amazing visualizations of the various technologies used by web developers in 2017 surfaced on the Interwebs. One of...
For further actions, you may consider blocking this person and/or reporting abuse
This was soooooo encouraging. I'm not new at development, but was lately feeling kinda "down" about having to learn (and retain) so much.
Side note: someone should write a "Learning how to learn" for developers.
Look up Learning How To Learn on Coursera - that should keep you gainfully occupied for a while ...
Glad you enjoyed it! That's a great idea... maybe a follow up soon :)
Excellent advice, and don't forget the rubber duck debugging technique: explain your problem to someone (or something) else, and you may well spot the bug yourself as you talk. en.wikipedia.org/wiki/Rubber_duck_...
I am in the process of Learning How To Learn for the past 2 months. I will certainly write about it to share it with anyone interested.
Learning how to learn is VERY hard and you'd be surprised the amount of obstacles I face every day!
A bit of advice for now : don't lose sight over the goal!
Need to add to that list of
Something I don't think a lot of new coders are taught soon enough is that there is more than one way to get passing code, and more than one way to approach a problem.
Sure there are ways that are just ugly, or brute-force, or are re-covering old ground. But also some of the new technologies or experiments do exactly the same things as old ones, in new ways. That can be interesting to find out about, and pay dividends as a coder.
As an example one piece of my software stores a history of objects, and attached metadata.
Technically it can store anything, but others have solutions I can use and don't have to spend as much effort developing or maintaining.
The software it integrates with stores it's main DB in an RDBMS. To stop loading that system up with edge-case data or things we don't need an RDBMS for (separate documents, anything non-set based), it uses a separate storage for history and non-searchable data.
That same metadata service is used for prototyping. You send data in and get data out trivially compared to an SQL store or something more robust.
It doesn't make a lot of decisions, just "Have I got data?", oh I'll store {X} in {Y} (directly addressable vs searchable). You'd be surprised to know how fast it is to say store {X}, in {Y}, get {value} from {key}, than given {A,B,C,D,E,F,G} find me {X}, check if it exists, etc (what most CRUD systems do).
When we have context for decisions of system design, or data-structures we can make smarter choices. We're able to composite ideas that others have pre-verified to make a new cool thing that helps solve problems for people, feel good about ourselves, get paid & get things done!
Well done, I feel like to many times people new to development are scared away by the endless mountain of technology and mountains of concepts. As you stated, it is about learning to look, at and know how to leverage, a technology applying some basic concepts; documentation, patterns, debugging, and asking for help.
Couldn't agree more. I learned pretty quickly that its entirely unreasonable for either myself or an employer to expect I know everything. However, I do expect myself to be able to pick up pretty much anything by using my trained problem solving mind to get out of a sticky situation.
Just starting out on programming and this chart is awesome! Makes things so clear. I can see my learning path before me now haha
This should be made Programming 101 for every developer.
excellent material, thank you for sharing your experience for the people we initiate is very useful