For a large codebase, normally I use the thing, note the different UI elements and messages, search the code to find where they are created and set up, pick one, and look into what happens when that particular element is triggered by the user.

In other words, ask "how does button ABC do its thing?" or "where does message XYZ really come from?" and plunge down the rabbit hole. This tends to be a more fruitful approach than trying to understand how the whole application works from start to finish.

Moreover, with existing codebases it usually happens that most of the issues are not in starting and finishing, but in all that happens in between.

In terms of IDE support, for me the most important feature is good search. When I stumble upon a hairy-looking method, for example, I want to be able to quickly see where and how it is being used.

You let the IDE do all the work?

That's also something I'd want to filter out, developers that are entirely reliant on their IDE and can't do simple things without it. I love Visual Studio, but there are way too many working developers that assume something can't be done if if Visual Studio doesn't have a built in menu option to do it, or they assume that the built in VS way is the only way.

People like this tend to be the type of developers that can make stuff work, but because they aren't curious they never really learn how things are put together and their lack of knowledge comes out in several ways. The most common one is wheel reinventions, because googling available wheels isn't something they'd ever think of. Another common one is writing very inefficient code because they don't understand what's under the hood.

and if that technology doesn't have IDE support? Lets say that due to an emergency you are the only person that can look at a problem with a WinForm client and there is an issue with Initialisation prior to the WinForm loading. Lets say (since this is a _very_ good example) that you need to create an architecture to share components between WinForm. Without knowing of static void main within program.cs you're not going to find the entry point and any attempts to share components is going to result in static sadness without doing some sort of service container gubbins or constructor shenanigans (although that will fuck the designer) prior to Application.Run(form) hitting in static void main.

The ignorance of static void main is a key reason why so many WinForm applications actually suck and why so many developers make the sad mistake of putting their user interface FIRST which has the knock on effect of making code reuse problematic. This is fine when people make utils but I have a very long experience of seeing companies struggle with this issue as their util grows into something more complex. The entry point IS important and if you're trapped in an IDE you suck. Go read pragmatic programmer the chapter: Wizards. You need to know how Wizards do their magic or you get burnt hard when the magic breaks.

you state that it's a problem when programmers don't know about the main function and I agree. The article on the other hand complained about people not knowing the exact function signature of main without thinking.