After 5 years of using Pharo by far the best way to understand code is to ask questions here.��

I have read and still read a fair amount of code, but in 50% of the cases I have no clue what I am reading because following the chain of method calls can be confusing and frustrating even inside a cool IDE like that of Pharo.

The good news is that pharoers here we have each our area of "expertise" even those like me that cannot be regarded as "pharo experts".��

My method is what I call "nuclear bombardment from orbit type of questioning" aka "I will question the hell out of this mailing lists".��

I miss the gene of shame when it comes to food , questions and some other things.��

So far, none has got angry with my unending streams of questions, quite the contrary I see evidently a trend of masochism of enjoying answering even the simplest questions, something that has infected me as well the last few years.

As a workflow I love tests.

I have to confess I am not a big fan of TDD development but I do abuse a lot Playground and Inspector. Reading tests can be also helpful if they are available. Its slow , its tedious at times but it almost always gets my questions answered if the mailing list cannot answer them. Its a kinda freestyle TDD, if you could call it TDD.��

I also love "self halt" aka debugger breakpoint. Debugger comes with its own inspector and Playground/Workspace so basically you got all the great tools in one place and is easy to see the stream of execution. But knowing where to put your breakpoints can be a challenge which sends me back to Playground.��

Finally I am the ultimate sinner and I generally avoid learning things I can easily create myself. I just find it far more productive. In theory it should not be, but in practice it is, especially against non documented complex APIs.

For example with morphic, I have created my own buttons, switch buttons, input fields with automatic formatting for time etc. Most of these things do exist but I never bothered even subclassing them because creating them from scratch was faster and easier than understanding how to manipulate code that already exists. It also gives me more confidence when it comes to bug fixing which is the most annoying part of coding.

There is however one case this approach went terrible wrong, with recreating the taskbar support , the api for that feature is just plain insane and I still have no clue how it works in its entirety. But it was a fun challenge more the less.��

We also doing surprisingly well in the documentation department and we have to thank the awesomeness of me, stephane, nicolas heis , Damien and many others that are regular contributors together with those that are not. Things are night and day compared to when I was introduced to Pharo back in 2011.��

We still have a ton of things that need documentation desperately but in 2016 was the first year I actually stopped complain like a child about the documentation because it has improved a lot and that makes feel all happy inside. I am sure it made other people here even happier that I stopped complaining.��

The nice thing is that Pharo code is a bit like puzzle, you start with no clue with what piece goes where but if you starting putting down the obvious/easy ones it gets easier and easier down the line.��

As a closing thought there is one advice I find the best advise that is given inside the PBE and basically says that is ok not to know how things work. At first I found it silly but now I see that knowing what you should invest on learning is an art and a skill by itself that every coder has to posses.��

Many questions here have been answered with people having no idea how something works but nonetheless the brainstorming ensuing after the initial question is enough to find the solution which of course as you probably know is so simple that is looking at our face . Its actually a fun experience which bonds our community close together in some cases with hilarious results.��

On Thu, Jan 5, 2017 at 9:25 PM Siemen Baader <siemenbaader@gmail.com> wrote:

Hi All,

I may be missing the obvious, but what are good strategies to understand the structure of existing code? Specifically, I'm trying to understand more of PharoJS to solve my own problems and eventually also to contribute back - but this is a general question.

There is this one MOOC exercise:��http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exercises-Pillar/Pillar-Questions.pdf that helps, and reading tests and comments helps if they exist. But I often get trapped in drilling down a long call stack and opening many, many browser windows, a new one for every message send to a new class.

While writing this it occured to me that I can use the debugger to follow a call stack by putting a breakpoint in the top level method, then stepping down using the debugger. There is also a MOOC lecture on that that I will look at again, ��http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W5/C019-W2S-VideosDebugger1-UsingTheDebugger-V2-HD_720p_4Mbs.m4v.

Any tips? I think I don't see the forest for the trees here I'm afraid :)

thanks,
Siemen