The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
A while ago when I still had Windows 3.1, a friend came with his copy of Windows 3.11. He really forced me to install it and insisted that everything was sooo much better. I did not see a thing.
Never change a running system unless you have a very good reason. Marketing blah blah is not a reason for anything. Computers actually age well. They can work for decades and don't get slower. Even the workmanship used to be better, so what do I need bigger, faster, better for if the old machine was and still is up to the task?
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada."
If software development were a circus, we would all be the clowns.
Do you have any recommended strategies for a junior developer when attempting to learn a large new codebase? One of my goals is to make some commits on something like ASP.NET MVC (.NET Core now), Entity Framework, Node.js, or some other major project on GitHub.
Not surprisingly however, when I open the project file for these, it can be tough trying to figure out where to even start. Of course I can view the issues and try my hand at solving one, but I found that even that often requires a general idea of the project's moving parts.
Do you have any suggestions or resources on breaking down a big project like this to bite-sized chunks that can be learned over time in hopes of a serious contribution?
One strategy I've tried is looking at the classes that I am familiar with from using the software and also looking at the unit tests to get an idea of whats happening. Thanks.
If you are lucky to work at a company that has decent documentation practices, read the project documents. To get an overall idea of what a project is about read the specification document. Then read the code description, if there is one. Also, try to follow the flow charts. These are standard documents in medical device design and manufacturing.
If you are into database or web design, good luck!
I've been at this for 40 years and have yet to find a company that had more than completely minimal documentation at a level that could help a developer. It has always been a learn-as-you-go process. Most developers do NOT document their work.
Last Visit: 31-Dec-99 19:00 Last Update: 20-Jan-17 20:10