Not only is this waste of money but also non eco friendly buying all that hardware
104 karma · joined November 10, 2014
Not only is this waste of money but also non eco friendly buying all that hardware
If I don't understand something at all, i usually search for code samples in Github someone might have used or look for questions related to it on stack overflow. This gives me a general idea if what i am learning is complicated stuff, or considered difficult or unused or is complete bullshit.
At the end, I implement something by taking pieces from all chapters, & keep that project for later reference.
Also, when I am learning about something which is more of a framework, I try to find reasons of why something is done like that, look into internal implementations without getting into much complexity so that if ever this framework support goes off, I know how to implement my own smaller version atleast
I am a slow reader and I don't like any disturbances so I pick the best time to learn something, probably night time.
Just write unit and integration tests
What i meant was applications should be self documenting, something like swagger comes to my mind.
In the process of learning a distributed system, the process of looking at the code as its documentation is not the ideal way. One could spend enormous amount of time to just understand a simple business usecase.
But then just because it takes time doesn't make it untrue.
I would rather accept a system which self documents itself with every change.
The point of breaking things is all well and good but to truly understand everything, after breaking also one needs to put the together one by one and understand their interactions so that if any one in the pool of modules fails, one knows what exactly would have caused it and how to be more resilient towards failures.
I did not think anyone would take time to answer so many of my questions. I agree with you on lots of points you mentioned above. Regarding the documentation I usually trust it if the module or the system is new, but if its old enough, i assume its outdated, architectural drift exists and only take that as a reference of how the system was planned to be like.
This also gives a lot of use-cases to begin with and understand the control flow. Regarding test cases, integration and regression tests help a lot in finding failures but I feel more confident about them if written by the same developer as the original thought for the code change is more pure with him and the reviewer.
For knowledge tracking, I guess there is no easy way, one learns from experience and time, but it would be great if there were some great tools to capture thoughts and map them to a definite state in the application without making any change in the codebase.
I have been in my academics for 6 years doing my bachelors and masters and less than a year in my professional career. The sheer amount of stuff one needs to know about building scalable and distributed applications is just amazing and nerve-wracking at the same time and I will keep your secret in mind :)