Hi Everyone!

Iโ€™m excited to share that I just had a paper accepted in ACM Transactions on Software Engineering and Methodology (TOSEM) co-authored with @mastorey , where we present a grounded theory, rooted in cognitive science, of the developerโ€™s cognitive experience of troubleshooting and overcoming confusion.

Our theory ๐—ด๐—ถ๐˜ƒ๐—ฒ๐˜€ ๐—ฑ๐—ฒ๐˜ƒ๐—ฒ๐—น๐—ผ๐—ฝ๐—ฒ๐—ฟ๐˜€ ๐˜„๐—ผ๐—ฟ๐—ฑ๐˜€ ๐˜๐—ผ ๐—ฒ๐˜…๐—ฝ๐—น๐—ฎ๐—ถ๐—ป ๐˜„๐—ต๐—ฎ๐˜โ€™๐˜€ ๐—ต๐—ฎ๐—ฝ๐—ฝ๐—ฒ๐—ป๐—ถ๐—ป๐—ด ๐˜„๐—ต๐—ฒ๐—ป ๐˜€๐—ผ๐—ณ๐˜๐˜„๐—ฎ๐—ฟ๐—ฒ ๐˜€๐˜†๐˜€๐˜๐—ฒ๐—บ๐˜€ ๐—ด๐—ฒ๐˜ ๐—ผ๐˜‚๐˜ ๐—ผ๐—ณ ๐—ฐ๐—ผ๐—ป๐˜๐—ฟ๐—ผ๐—นโ€”๐—ฎ๐—ป๐—ฑ ๐—น๐—ฒ๐—ฎ๐—ฑ๐˜€ ๐˜๐—ผ ๐—ฝ๐—ฟ๐—ฎ๐—ฐ๐˜๐—ถ๐—ฐ๐—ฎ๐—น ๐—ฎ๐—ฑ๐˜ƒ๐—ถ๐—ฐ๐—ฒ ๐—ณ๐—ผ๐—ฟ ๐—ถ๐—บ๐—ฝ๐—ฟ๐—ผ๐˜ƒ๐—ฒ๐—บ๐—ฒ๐—ป๐˜.

https://artystarr.com/blog/giving-developers-words

@art3starr @mastorey Just read the blog article you point to here, and it's very interesting.. The idea of troubleshooting time as a direct representation of the growing complexity of software is very interesting, and at least for me, it aligns well with my personal experience.

One of the metaphors I've used, at least in my own mind, is the notion of software being "under my control", and although I doubt I ever attempted to give it a precise definition, I think it relates closely to the idea that whatever software I'm talking about doesn't give me many surprises in it's behaviour.

@DaleHagglund @mastorey Thanks Dale, it's interesting to hear about how this maps to personal experience for you, and what you've noticed about the words and subtle meanings.

I think that's probably how I got started on this thread, is similarly noticing the subtleties of sense, like with careful iterative building up of code and things making sense as "staying in control" vs when you're surprised and not sure what is happening any more.

@art3starr @mastorey Hey this resonates with my experience too, especially the drain and the inspiration I get from troubleshooting.

One of the dissonant concepts that is very hard to convey is the idea of "engineering harder or more formally" to make the process of software development more predictable.

It's possible to reduce chaos, of course, but beyond a certain point you add friction to the process and that leads to ... more chaos.

@grimalkina

@rhempel @art3starr @mastorey thanks for the tag, I look forward to seeing how cognitive science is integrated in the paper!
@grimalkina @rhempel @mastorey I'm looking forward to hearing your thoughts on it! I really tried to do a good job with pulling together all the background research and build a real constructivist grounded theory with some rigor. There's always limitations, and I also like the idea of resonance testing as validation, like the CGT paradigm is cool. Our troubleshooting theory is in the words the developers, which is pretty cool as an output. Peggy is looking forward to your thoughts as well. :)
@art3starr @rhempel @mastorey oh I missed that it was already posted -- congratulations on the publication! An interview approach to this feels like a great way to build theory
@art3starr @mastorey @JeffGrigg
Fascinating. I feel that in this land of cognitive complexity, there be monsters. Likely, malevolent code patterns (aka dark patterns) hide in projects beset with high indecipherability.