|
|
|
|
He'll appreciate that.
On a totally different note I thought the link to "Fart Blamed for Causing a Fire During Surgery at a Tokyo Hospital" to be equally as odd.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Some times the link is worth clicking on just for "WTF is that about"!
|
|
|
|
|
Mike Hankey wrote: On a totally different note
One might even say it's a brown note... 
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
|
|
|
|
|
This really is great. Why change anything as long as it does its job?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"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.
|
|
|
|
|
CDP1802 wrote: Why change anything
Because we can.
More ... bigger ... faster ... better.....
Ken
|
|
|
|
|
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?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"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.
|
|
|
|
|
All true, but you did catch me with the Win 3.1 and 3.11. Now if you insisted on 8" floppies, I might have an argument for that....
Ken 
|
|
|
|
|
RTek23 wrote: Seen this....
Yeah, seen this a few weeks ago in fact. Though I'll be damned if I can find it right now. But it was definitely in the lounge...
|
|
|
|
|
In that case, apologies for the Leslie.
Ken
|
|
|
|
|
Made me all nostalgic all over again for a C64.
|
|
|
|
|
|
Fried corn ball with nothing in it for breakfast (5,4)
If PeejayAdams ever spoke about himself in the third person, I would not vote for PeejayAdams.
|
|
|
|
|
If it was (4,5), I'd say hush puppy.
|
|
|
|
|
Bacon Roll
Anagram of corn ball with an 'o' (nothing) added.
Andy B
|
|
|
|
|
We have a winner!
If PeejayAdams ever spoke about himself in the third person, I would not vote for PeejayAdams.
|
|
|
|
|
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! 
It was broke, so I fixed it.
|
|
|
|
|
S Houghtelin wrote: read the project documents
...while keeping in mind that the actual product probably deviates substantially from the original documentation.
|
|
|
|
|
dandy72 wrote: ..while keeping in mind that the actual product probably deviates substantially from the original documentation.
Hence the "If you are lucky to work at a company that has decent documentation practices."
It was broke, so I fixed it.
|
|
|
|
|
I think it takes more than "decent documentation practices" just to ensure documentation is kept up to date, unfortunately.
|
|
|
|
|
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.
|
|
|
|
|
In the medical device industry if we do not have documentation, you will not be able to sell your device. It is a requirement and for good reason. Would you want to be on the operating table being monitored by devices with software of unknown provenance?
"Most developers do NOT document their work." and we wonder why the quality of the software out there sucks. That's called winging it and in my opinion it is unprofessional and if a developer is unable or unwilling to maintain at least some level of documentation I would not be inclined to hire them or to keep them in my employ.
It was broke, so I fixed it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
