How a Non-Technical Guy Become An Efficient programmer !

The best way to learn any program is to give a try and make your hand dirty ! Yes, it is !! In straight forward, learning to code through just reading is simply waste of time. The sooner you start programming, the better it is to learn coding.

There are few most common confusion that a new programmer faces and stuck up in that vicious circle as mentioned below:

1. Which programming languages to learn first?

2. Whether test editor or Interactive development environment (IDE) to use?

3. Which text editor or IDE to start with?

4. Is math or statistics are mandatory?

5. Whether laptop or desktop is best for programming?

6. Which programming languages are most paid?

7. Which programming languages are good for beginners?

It needs to be kept in mind that great thing takes time and it comes with toughest challenges.

General Guidelines:

It needs to bear in mind that everyone's taste is different from each other. So, what is good for one doesn't mean that it will be suitable for other.

The answer against all of the above question is that just start with any one programming language and become familiar with it. Learn it how programming languages works. Automatically, you will find your way on what to learn next. For the time being, Just kick off and stick on it. !! 

1. Just google and start with any one of general purpose programming languages such as C, Java, Python.Just focus on the basic syntax and write a simple code say write a code which will have a output of "Hello World".

2. Chose any simple test editor which runs over all the operating systems. For the very beginning, Notepad++ is a good choice (Please click here for download). Don't start with IDE because its better to learn driving through manual car rather then automatic car which helps to learn the very basics. I will write a separate blog on IDE shortly.

3. Learn with patience and maintain the routine strictly. It is strongly recommended to do practice programming everyday for at least 90 minutes.

Please refer to my post over on Python with Sublime for an easy and organized start.

Caution:

1. Don't Go with any advanced Level materials at the beginning stage, at least for the first programming language to learn.

2. Don't start learning many programming languages concurrently at the beginning stage. 

What For Next Level:

When you are familiar with any general purpose programming language, try to develop something  new practical or try to get engaged with any online projects. Github is a best place to cooperate with other well known programmers who are very much supportive.

Basically, it is very important to determine what you want to learning programming? Actually, it is the very basic question regarding which programming languages you should get familiar with them.

If you want to develop website, you have need to learn HTML5, PHP, CSS. If you want to learn data minning, you can learn Python, R, Matlab. If you want to develop games, you can learn Java, C#, C++. If you want to develop full scale operating application, you can learn C.

Optimization of the basic:

With basic knowledge and expertize, you can surly write super code, but you need to understand the arhitecture of machine and how it interactes in order to develop Superb code. Hence,  it is required to sharpen you computer literacy. There are many free but awesome materials which you can use to enhance your capability. Like Introduction to Computer Science (Course Code: CS50) of MIT is an excellent source which offers basic to advanced level knowledge through Video lecturer, assignment, periodic test etc. It is available on edX at free of cost (click here for the web link).

General Guidelines for becoming from nobody to at least somebody!!

I am still learning and from my experience, the following principles can be helpful for becoming a good programmer to have understanding over different languages, paradigms, frameworks and other aspects.

1. Optimization VS Readability. Forget about optimization. 

Always write code that simple to read and which will be understandable for developers. Because time and resources that will be spent on hard readable code will be much higher than what you get from optimization.
If you need to make optimization, then make it like independent module with DI, with 100% test coverage and which will not be touched for at least one year.

2. Architecture first. 
I saw many people who was saying “We need doing things fast we have no time on making architecture”. And about 99% of them got big problems because of such thinking.

Writing code without thinking of its architecture is useless in the same way as dreaming about your desires without a plan of achieving them.

3. Have Vision what you r doing! 

Before writing the first line of the code, you should understand what it will be doing, how, what it will use, how modules, services will work with each other, what structure will it have, how it will be tested and debugged, and how it will be updated.

4. Test coverage. 
Tests are good thing but they are not always affordable and make sense for the project.
- When you need tests:
- When you are writing modules, micro-services which will be not touched for at least one month.
- When you are writing open source code.
- When you are writing code that touches financial channels.
- When you have resources for updating tests at the same time as code was updated.
- When you don’t need test:
- When you are a startup.
- When you have small team and code changing is fast.
- When you write scripts that can be simply tested manually by their output.

Remember that code with badly written tests can be more harmful then code without tests.

5. Keep It Simple, Stupid (KISS !).

Don’t write complex code. More it simpler then less bugs it may have and less time needed to debug them. Code should do only what it need without tons of abstraction and other OOP shit (especially it concerns java developers) + 20% of things that may be needed in future to update it in simple way. so, follow the KISS principles !! 😉

6. Comments.
Comments showing bad code. Good code should be understandable without a line of comments. But what to do to save time for new developers? — Write simple inline documentation describing what and how method work. This will save much time for understanding and even more — it will give people more chances to come up with better implementation of this method. And also it will be good start for global code documentation.

7. Hard coupled VS Less Coupled.
Always try to use micro-service architecture. Monolithic software can run faster than micro-service software, but only in the context of one server.

Micro-services give you possibility to distribute your soft efficiently not only on many servers but sometimes even on one machine (i mean process distribution).

8. Code reviews.
Code review can be as good as it can be bad. You can organize code review only if you have developer who understand 95% of the code and who can monitor all updates without wasting to much time. In other situation it will be just time consuming and everyone will hate this. On this part got to many questions so describe this more deeply.

Many people think that code review it’s a good way of teaching new guys, or teammates who works on different part of code. But the main target of code review it’s maintaining code quality, and not teaching. Let’s imagine that your team making code for controlling cooling system for nuclear reactor, or space rocket engine. And you made huge mistake in very hard logic, and then you are giving this for code review to the new guy. How to you think what would be the risk of accident? — On my practice more than 70%.

Good team is where each person has own role and responsible for exact piece of work. If someone want to understand another piece of code then he goes to a person responsible for it ant ask her. Impossible to know everything and better excellent understand small piece of code than all but on 30%.

9. Refactoring does not work.
During my learning session, i heard many times “Don’t worry we will refactor it in future”. And in future this results in big technology debt or in deleting all the code and writing from scratch. So don’t get a debt unless you have money to develop you software few times from scratch.

10. Don’t write code when you are tired or in a bad mood.When developers tired they are making x2–5 more bugs and mistakes then when they are full of energy. So working more is very bad practice. That’s why more and more countries thinking about 6 hours work day, and some of them already have it. Mental work is not the same as working with your biceps .

11. Don’t write all at once — make developing iterative. Before writing code analyze and predict, what your customers/clients really need, then select MVF(Most Valuable Features) that you can develop with good quality in a short term. Use such iterations to deploy quality updates, and not waist time and resources on unreasonable desires and sacrifice with quality.

12. Automation VS manual.
Automation is a 100% success in a long term. So if you have resources to automate something right now it should be done. You may think “it takes only 5 minute, why i should automate this?”. But lets calculate this. For example it’s an everyday task for team of 5 developers. 5mins * 5devs * 21days * 12 month = 6 300mins = 105hours = 13.125days ~ 5250$. and how much this will cost if you have 40 000 employees?

13. Go out, get hobbies.
Work differentiation increases mental abilities and gives new fresh ideas. So make pauses and go out on fresh air, talk with friends, play the guitar, etc.

Learn new things as you get free time.

When people stop learning they start to degrade. So, keep on learning……..

Happy Coding !!! 😃