There are a few things every developer should know but usually don't realize until it is too late. I'm going to give you five tips you should know early in your development career (or hobby) to save you a lot of time and frustration.
Stop using tutorials
This is one of the big ones, as a new developer tutorials are your training wheels. It isn't until a child removes the training wheels he can get good.
Tutorials are a great help early on and you will always need to use them, but start building things on your own as soon as possible. When you do, you will really begin learn and grow. Tutorials generally use poor development practices to keep them simple and focused. You also don't exercise your problem solving skills.
Learn Git
Git is everywhere in the development world and it requires a lot of practice to get proficient with it. Starting early will not only protect your code and your time but it will give you valuable practice with one of the most used tool in the industry.
There are numerous free training videos and tutorials for using git, this looks like a good video that is under an hour.
Remember rule #1, stop doing tutorials and just Do it!
Fail Fast, Fail Often
This is so good advice I frequently say this in business to colleagues and other business owners.
It is easy to be stuck in Analysis Paralysis phase where you spend all your time thinking about how to solve a problem instead of actually doing it.
The secret to development and almost anything in life is to just do something, anything, and when you fail, adjust and do it again. The more you try, the more you fail but the more you succeed.
Failure is also the best mentor.
Michael Jordan says it best.
Review the docs
Initially you will be limited to tutorials to learn the basics. The documentation is a fantastic resource for learning more about whatever project you are working on. Initially you will just use it to solve immediate problems, but you can learn best practices and features that can save you a lot of time by frequently reviewing the documentation.
Don't try to memorize everything
Just don't. Documentation is there for a reason, it is a reference. No one can remember everything, and if you focus on trying you will greatly slow down your progress. A big part of development is being aware certain features exist not memorizing how to use them.
One of the best skills of any developer and knowing where to look when you need something. Develop that skill!
Hope this helps!
This is a perfect advice. I agree with all your points. Just one thing. While watching the tutorials we should be watching tutorials from different people to catch different coding style. Of course we can just stick to one coding style but knowing the others is also good. Nice article. 👌
'should learn fast'?
Some tutorials are good to get you into something new as the documentation can often be lacking. Building your own projects, even if they are useless to others is the way to go as you often have to learn stuff anyway and you will fail. It's rare that anything works first time. Debugging is a crucial skill.
The programs I used to write as a kid were really 'useless to others'.. I remember we had these fancy new TRS-80s that they installed in a computer lab when I was in 7th grade that came preinstalled with BASIC. Our teacher - I'll use that term loosely, was actually the school wrestling coach.
I wrote this really elaborate program and loaded on the teacher's computer that emulated a fake TRS-DOS prompt. Whenever he would type out any command, it would spit back complaints and refusals to function. It may have been pointless and mischievous, but all this experimenting really taught me a lot.
All I had for tutorials back in those days was the back pages of PC magazines with long lists of useless programs in various flavors of BASIC. So the tutorials are helpful, but at some point you definitely have to start experimenting and diving in to the deep end of the unknown.
I used to type in some of those programs and learnt a few things from them. I would even try to convert some written for other computers, but the versions of BASIC were different enough to make that tricky, especially if graphics were involved. We operated on a lower level than most programmers these days. No fancy editors or debugging tools.
Yeah, I remember the frustration of finding some cool looking game code that was only in apple flavor, but I had an Atari 800. I would try to translate it but usually fail miserably!
Done. I fail every line.
But yea, the stop using tutorials and start doing your own things is the best way. Find a reason to actually need to do something and you'll force yourself to learn it. And google helps when you are stuck.
The hardest part for me was taking that initial jump after spending close to one year learning how to code, using tutorials of course. Trying to code without the tutorials felt daunting and referring back felt like a step back. I still struggle with that especially reading the documentations. Quite the borefest sometimes. 😅
There are so many bro-grammers out there making tutorials these days that will really send you down a bad path. A weird programming culture has developed over the past 20 years that has kind of driven me away from enjoying it much anymore.
I remember back in the day I ran a local BBS (around 1991-1993). The idea of video tutorials was a fantasy. All I had was some shitty reference manuals on the C programming language and the rest I learned by trial and error. My board was running WWIV which I had to customize and recompile if I wanted to make any major changes.
Nowadays people use youtube videos and online tutorials as a crutch. They mindlessly copy and paste snippets of code without having any clue what is actually happening. Massive bloated libraries are used where 3 lines of code could do the job.
So yeah, as you put it, take off the training wheels. Jump into the deep end and experiment! I would even suggest that people learn some kind of a lower level language like assembly which forces them to get closer to what the computer is actually doing. Perhaps write some simple programs just to build a stronger foundation.
But maybe I'm an extremist? Personally I've lost the love for coding, which is kind of sad. Perhaps I'm becoming one of those grumpy old guys I used to laugh at when I was a kid.
Great Info @themarkymark...And Thank You! Hey I know that you are very busy, and I won't take up a lot of your time. But, I do have an idea for a New HIVE project. It is called HIVE "HONEY". HIVE "HONEY" is a Smart Contract that lets you earn a specific number of Liquid HIVE by typing In a couple of keyboard characters, within a certain time limit. (24 Hours per contract) All while using your own Liquid HIVE as collateral to honor the agreement. I have also made a post about it here:
https://hive.blog/development/@steemit-life/a-hive-honey-smart-contract
If you have some extra time, please give it a read. I would love to know your thoughts on this idea. The Good/Bad/Ugly (well hopefully not too ugly!:) ...Could HIVE 'HONEY" be done? Or, some kind of platform like it? You probably know a team of Devs who could create something like this for HIVE. (Hey I gotta get the best, right?) :) I've already sent a message to @netuoso. Hope that he gets it too. I really think that it could be a game changer in the future for HIVE. Okay thanks for your time and attention @themarkymark! & Take care:)
That is so hard to get through to people in any business. It is much better to know where to find the information you need than to rely on a faulty memory or to have missed a small upgrade to something.
The best part is...sound logic works in so many other spheres of life and work, too :) Thanks for all the advice, I might get to it at some point, even though more as a hobby.
Thank you for your wise advice. I wish you creative success and excellent health.
And if there is health , there will be everything else...
And you are right we all learn from mistakes and failure is really the best mentor!
Right on time when my coding career is on the runaway.
Great advice, thank you. If you like drones feel free to follow our blog.