In movies, programmers usually sit at a terminal and type pages of dense computer code, at breakneck speed.
In reality, programming new GUI code tends to go more like this:
- Try a few Google searches to see if someone has written a tutorial on how to make the new thing. If not, search Stack Overflow for related questions.
- If that is not enough, look through the list of Cocoa or MFC classes for anything already designed to do the new thing. Search again for tutorials on how to use those.
- If desperate, check the indexes of a few reference books. Try more searches with slightly different words. Or give up, and try a completely different approach.
- After getting a vague idea of how to proceed, search Google and GitHub for sample code. Apple and Microsoft both have tons.
- If there are sample projects, run them and see if they do the job. If so, step through the code in the debugger and try to understand it.
- If no samples, search. Probably some smaller code samples, somewhere.
- Copy/paste the likeliest code into the actual project. Tweak as necessary. If totally desperate, write a few lines of brand new code. It rarely takes more than 5 or 6 lines to do the job. Often it’s just 1 or 2.
- Run it and see if it works. If not, step through the code in the debugger and find where it breaks.
- Test it, tweak it, test some more, tweak some more. This requires a small amount of typing, but most of the time is spent running the program, dozens or hundreds of times per day.
- In some cases, throw it all out and try a different approach. Repeat steps 1 to 9.
If it weren’t for debuggers, it would be nearly impossible to write complex software. “Debugger” sounds like something you can wave at bugs to kill them, but unfortunately it’s not that easy. Instead, you set a “break point”, then run the program. When it gets to the break, you step through one line at a time, and see exactly what changes when. Sometimes the problem is obvious, and sometimes it takes many trials.