Writing and Understanding code [closed]

I few months ago, I was introduced to large code bases with multiple unfamiliar languages. I diligently recorded all my experiences on Google Docs. Here are the tips that I have gathered:

1. Read the documentation. We must always remember to refer to the documentation. Actually, it is not really important to read the documentation. The important thing is to have the various .pdf documentations at hand for you to search.

2. Ask the author (not too often as you should try web searching for the answer first). Ask the forum / mailing list. The most specific forum is best, especially where the developer is active.

3. Use Notepad++ (npp). Use "Find in Files" for a particular keyword. Regular expressions can be very helpful.

4. Special characters are the most difficult to decipher. They are also not searchable by Google. Symbol Hound is a search engine specializing in special characters. It is not as far reaching as Google. Solution: Have a folder or file to keep special characters for the language used, e.g. shell commands.

5. Generate a fully commented set. This is a typical file where you insert as many comments as you like for your reference. We don’t need comments for every file and company source codes hardly have any comments.

6. Form an association table. Even though there may be no comments in the code, programmers have a very fixed way of defining things. By observing similarities in the function calls, we can see that certain variables belong to the same group.

7. Multiple languages are often used. For each type of file extension, find out where one language ends and another language starts. e.g. Lua / C / shell / Linux / GNU / BSD.

There's a saying my professor in college quoted, don't know where he got it but i'll be borrowing the same quote from him

If you want to learn, Read  
If you want to understand, Teach  
If you want to master it, Code

So lets go into a bit of detail on that.

Read, that means, read up on the documentation/tutorials/books about the topic. You can ask people who know about it in person, or a mailing list, or a forum, or even here on StackExchange/StackOverflow. Before you can begin to understand something, you should first learn a bit about it. Even just simple one liner descriptions on the function documentation is enough to get you to learn something about it.

Teach, now this can be interpreted in many way, I choose to interpret it like this. This simply means that if you want to understand a certain framework, you should learn enough about it to be able to explain what it is to a person with little to no IT background. It can also be interpreted as being able to write good documentation of your code, since documentations are a form of teaching others what your code is. Being able to properly explain what something does with confidence is proof of understanding.

Code, experience is the best teacher. Period. Reading and Speaking/Writing can only get you so far especially since not all code works as stated in the book, most of them act differently depending on the environment. You need to use what you want to learn/understand if you want to master it or if you want to know beyond scratching the surface. Experiment with it, physically learn its boundaries, what it can and cannot do. You can take pet projects or join open source projects to practice this.

As for managing time to learn with productivity, Try ask a senior programmer to pair program with you, that's a fast way to break the ice with new concepts, not only do you get to seem how you should code, but you also get someone to ask if you don't understand something. Its hitting two birds with one stone, you get to learn and at the same time, manage to be productive at work.

How to develop deep understanding of any framework or stuff that we are working on?

Practice - there is no substitute.

How to not scrape on the surface only?

By not scraping the surface only? I mean what you work on, and how you use something is up to you. Some people will do better here because they can infer/intuit how something works by making assumptions about its implmentation. This comes with experience, but also is effected by the programmer's natural abilities.

If you want deeper knowledge then use more of the framework. Tinker with it. Consider how you would implement that behavior and what implications that has rather than just following some sample code mindlessly.

The key to learning a new language is to define certain goals you want to achieve in that language and then go for it.

For example, the things I usually go for are:

• hello world
• open, modify, save txt files, csv files, XML-files and so on
• write a calculator with a GUI (error handling for the divide through zero case included)
• establish a database selection, initiate a query

This will give me an idea on how to solve most problems I come to face in a normal working day. If you need more, feel free to define new goals and continue.

Generally Patterns & Practices covers a lot of this, as a lot of the time when working with different platforms/languages you do not always remember 100% of the syntax or the method names of a framework etc. However you do remember the paradigms and patterns used for a platform.

Take for example closures, if you have worked with javascript and know what closures are, then you can go to another platform (lets say Ruby) and look at the syntax for closures, you no longer care really about the individual syntax per language (you will often remember it anyway) you just remember the pattern used to solve the programming problem.

To look at patterns and practices a bit more then once you know what a builder pattern or a factory pattern is, you can easily pick up how to use certain frameworks as you know the pattern it is using. Same for practices, if you are versed in writing testable and mockable code you will know how to separate your concerns etc on whatever platform you are working with.

Ultimately you need to practice, you start off learning one language and its syntax, then you learn the platform features, then you learn another language and you see the similarities between the 2, or the differences in some cases, either way you are constantly learning. The more frameworks, platforms, languages you have used the easier it is to pick up new one.

One final thing to mention is Domain Context, as working at the same company for 10 years may make you an expert in their specific application or workflow, however domain context is just useful for an individual role, if you went to another company that knowledge you have about hedge fund value analysis for a bank may not be that useful in your next job, as it doesn't improve your technical skills in any way, it just lets you understand a single clients problems better. So just be weary of investing too much time learning how 1 bit of software works in your specific scenario, and concentrate more on learning technical solutions which can be applicable in other roles.

Of course there are many concepts you must master to be a good developer. Like anything, practice will help you sharpen your skills.

One of my favorite concepts is to write your function names so that they tell readers exactly what they do. Two things you will find are:

1. You will not need comments that eventually lie anyway as they become out of date.
2. Your functions will end up doing one thing only.

While you are writing code, you spend most of your time reading other portions of your code that you have already written, so you benefit from this practice probably more than someone else maintaining your code.

Read the book "Clean Code - A Handbook of Agile Software Craftsmanship" by Robert C. Martin for discussions on this and other EXCELLENT advice.

I find that I fall ill when I read code I read 10 years ago, cringe when I read code I wrote a few years ago and take pride in code I wrote today. On this, I hypothesize that my practice is paying off and I am getting better. If 10 years from now the code I wrote today doesn't make me sick, I'm afraid I will have stopped learning, and that's the worst case of all.