half of the people in this group, when they think of "future of coding", imagine more convenient, more grpahically interactive IDE environments, where you use drag and drop mechanisms, and extrapolate from autocompletion to not just a word but a phrase. Others imagine more robust languages which free the programmer from the drudgery of debugging, which some estimate takes 85% of all programming time. A lot of people over-estimate the time it takes to enter the code, and under estimate the time it takes to get it working perfectly. I would be very interested in the group members divulging what percentage they estimate of the total time making a program to be debugging.

I feel I do very little debugging. Most of my time — likely in excess of 80% — is spent designing and making things in the first place, and that time is spent struggling with the problem domain, not with the code I’ve written. Once I have something working, it’s rare that I ever touch that code again until I need to change or expand it to suit a new usage. There’s some non-trivial code I use daily that’s been effectively unchanged since I wrote it 4 years ago. Some horridly complex code my coworkers totally rely on that I haven’t touched since 2011. Sometimes things break and are fixed and break and are fixed, but that’s usually because I did a bad job of the initial design — this is the rare exception, in my experience. But my job/team is not typical. FWIW, I’m solidly in the “graphically interactive” camp. And the things I make tend to be visible or audible or in some other way nakedly apparent whether they’re working correctly or not. If I make a mistake, it’s almost immediately apparent what and where and why. (Perhaps this is why I don’t get why people are so gaga about types)

I have asked several thousand developers if they agree with the statement that they read code for at least 50% of their time. The vast majority agrees, and most say it's much more than that. At the same time, when I ask developers when was the last time they talked about how they read code, it turns out that that is not a subject of conversation. So, it looks like our industry is spending the largest chunk of the budget and energy on one single activity about which nobody talks.

@Tudor Girba did you publish a study? To use a metaphor from craft (which I do quite frequently), I think of the code writing as equivalent to “roughing”, i.e taking the raw piece of wood and quickly cutting away the excess that is definitely unnecessary, using a coarse gouge or a template. Then eventually debugging is the “finishing” which often requires contemplation and reflection, and can cause the design goals to be redefined somewhat. To make something really good requires a lot more finishing than roughing! I think this is true no matter how good the tools are, unless the thing being made is a familiar replica where the making is mostly by rote. I also don’t see anything wrong with this, as ultimately making something of quality is more of an aesthetic/philosophical debate, where time is a crucial ingredient.

I did not publish this explicitly, although I do talk about it since some years. You propose an interesting metaphor. I do not have any direct experience, but I find it interesting to see the parallel between “roughing&finishing” and the principles put forward by Tufte, namely “removing chart junk & increasing data ink”. In both cases, the former is about removing the unnecessary parts, while the latter is about adding value. Furthermore, in both cases, the latter is the one that requires the largest chunk of energy. I like how the metaphor emphasizes the iterative nature of the work and how the deeper layer can only be uncovered after you revealed the shallower one. When approached like this, crafting cannot follow a predefined detailed plan. The real plan is discovered during crafting. I find that to be a key ingredient of programming. I look at programming as being a representation of thought that gets refined as we formulate it. From this perspective, programming becomes executable philosophy. However, I do think that there exists at least one essential part that make programming distinct. A piece of wood has an intrinsic shape, and we interact with that shape both to figure the next step out and to create the new shape. The shape of the wood is essential for our ability to guide our actions, and in the case of the wood, the shape cannot be easily decoupled from the thing. However, software does not have a shape. The typical textual shape is simply the shape we use to create software. Developers read text. But, code is not text. Text is but one of its shapes. For the longest time, visualization was used to represent maps, which are representation of the intrinsic shape of physical space. It was only recently that we use visualization to reason about abstract concepts. In the process we learnt that by affecting the shape we can increase the effectiveness of reasoning about both large data sets and abstract concepts with orders of magnitude. Interestingly, effectiveness is proportional with how custom the shape is to match the problem at hand. In other words, as data can have many shapes, it is essential to pick the one (or few) that matches the current context. A software system is an abstract thing. It is a representation of thought in a data form. Its shape is given by tools. As shape is essential, it follows that tools are essential as well. For a long time, software was studied in isolation from tools. I believe this is misguided as it misses a significant part of the picture and it is prone to not produce satisfactory results. For example, we approach and measure the quality of code as being a property of the code itself. The assumption here is that certain measures indicate how well code lends itself for a human to reason about it. Indeed, if we assume that text is the only shape, then these measures can make sense. However, there is an increasing amount of evidence that shows that by changing the tool, we can affect the digestibility of code to a much higher degree than the satisfying of code metrics can. The existing of this very community is an argument to support exactly that thesis. Our tools are essential. However, not any tools will do. Tools must be moldable enough so that we can quickly and inexpensively explore shapes that are appropriate. We call this property moldability.

our industry is spending the largest chunk of the budget and energy on one single activity about which nobody talks.

@Tudor Girba A friend of mine has a pretty decent hypothesis explaining and justifying this disconnect: http://akkartik.name/post/comprehension

“Tightening the feedback loop” I believe is what at least some of us are trying to do. There’s also the metaphor of sculpting a digital material, where you have live feedback when you manipulate a system and can see what the effects are immediately, similar to what a sculptor does. Sculpting like that enables playful exploration, which is where a lot of discoveries come from. I’d say when you’re debugging that’s pretty much what you do, in a very limited way, so it is just the crutch that gets us closest today. I like to contrast programming with professional creation tools for music production or video editing. These domains have all “upgraded” from symbolic representations (think of musical notation and then the first sequencing tools, where you had to type in the pitch or notes) to more visual, interactive representations that allow quick and often immediate feedback loops and playful discovery. If programming was more like a musician improvising on his piano keyboard hooked into a synthesizer, changing sounds and effect chains on the fly, it sure doesn’t mean it would automatically be better, but for sure it would be more playful and approachable.

they read code for at least 50% of their time

Certainly true for me. I suppose it depends on how many incremental changes you make, vs writing something completely new. The bulk of software work in the industry is maintenance, the bulk of which is likely reading code.

On the contrary, i was not omitting the reading part in my estimate that 85% of the time is spent debugging; i didn't say who was doing the debugging. The whole aspect of readability is part and parcel of debugging, especially when you imagine someone other than the original author trying to upgrade/repair a big system. The difficulty of understanding a large system is a major problem in software today. Software lasts decades, and goes through many hands typically, and the handover from the original author to the new maintainers is a very tricky handoff. My actual supreme goal in beads is to create an era of interchangeable parts, where people can share code effectively. Right now, the GitHub repository is more of a graveyard to me than a useful resource. The number of projects with tangled dependencies, unknown debugging state, and a mishmash of different coding technologies makes it pretty useless for my purposes. I am sure others can sing the praises, but these large repositories are clearly not working that well. Why are the software as a service companies like Facebook, Salesforce, etc., able to charge such vast sums if programs were easy to make out of available parts.

@Kartik Agaram Thanks for the link. The observation is correct in that we read when we want to edit. And indeed, that is a good thing. We do not want to comprehend in general and as a whole, but enough to be able to affect a change. This is called decision making. Given that we spend most of our time doing that (making decisions about what to do next), 9 years ago I started to look at software engineering as being primarily a decision making business. I developed a theory and an associated method that I am validating in industrial case studies every since. You can read about it at http://humane-assessment.com. More recently we went a step further and created a whole IDE that is based on the idea that assessment should be supported first class.

https://futureofcoding.slack.com/archives/C5T9GPWFL/p1545775972054700?thread_ts=1545714776.037100&cid=C5T9GPWFL I read code just for fun with no intention of editing and have thousands of stars on GitHub... I understand I'm probably the exception rather than the rule but there have to be more people that enjoy reading code. "Fun" still means I have goals to educate myself usually, but often I read in order to understand someone else's approach or just for appreciation

I believe there are two distinct two reasons people read code: for learning/entertaining purposes, and for figuring out what to do next. Both are good reasons.

Gitpedia = a hosted code repository with hyperlinked symbols and links/references to dependencies, with robust search of course. Highlighting examples and documentation first could be helpful also. A more complex "map" like visualization could be interesting for exploration, even just a hierarchy that instantly showed you where else in a code base a function was called or class is instantied would be nice

That is interesting. Where do I find more details about it?

I'm also thinking about how to read large legacy code based, not inventing a new language designed for navigation and/or readability first, which could be interesting but when I think "read code" I think how can I understand parts Unreal Engine, Tensorflow or Chromium more quickly, a language designed for reading that no one uses doesn't have any code I want to read :)

Aha 🙂

The real goal is comprehension, is it not? Reading code (and then mentally connecting the dots) is only a path to comprehension. Yes, hyperlinks make the references easier to traverse, but what else can we do to get to the comprehension? Higher level maps, data visualization, scenario simulation...

Simulation would be great, in the context of supporting random legacy code bases it's harder, but when reading I'll often reimplement a function or small part of the code base in a simpler environment in order to get a better feel for how it works

Comprehension is a general term and while it is an interesting umbrella concept, it is too vague. For example, one might comprehend Schopenhauer’s work. However,q in software most of our effort is focused on the specific goal of making decisions. That is why I coined assessment as a term to deal specifically with how we make decisions.

Excellent point. Yes comprehension is in fact not the final goal, but in the service of decisions. I imagine custom 'reader directed' visualizations.

Precisely. So this means that the environment must accept visualization as a first class element and it must make it as cheap as possible to craft a visualization. We aim for minutes cheap.