I’d be wary of applying causation based on that correlation. When you are the expert, people come to you for things. You communicate more, but that’s not what made you the expert.

I’d posit that attention and communication are both secondary to core competency in software development. My guess is that information synthesis and lateral thinking are the core competencies of great engineers. I don’t think you can get the information you need or as much lateral thinking without attention and communication, but that doesn’t mean they are the core competency.

I'm not sure causality goes that way. You communicate more if you are better at the technical parts. If you can solve most of the problem in your head and in that way predict most of the things you need before you start working you just go and ask for that information from everyone. However if you are worse on the technical side you will need more time working on the task before you have anything to talk about, and you might even miss some of the issues completely.

Forcing the second kind to communicate more wont make him better, it will make him worse. He will need to build up his technical skills before communicating more actually helps.

In my current project, we are basically coerced into pairing nearly 100% of the time and it takes active resistance not to pair on every single little thing like "remove this item from the list in the docs". Yep, it's that extreme.

In my personal experience and opinion, pairing makes sense for knowledge distribution and figuring out something hard together. Or onboarding, getting a project newbie up to speed for a couple of weeks.

But when overdone, it simply slows you and binds expensive developer resources that otherwise could be working on a parallel thing. Especially in the remote environment during Corona times. I basically HAVE TO have an always-on Zoom/Teams call with mic and camera.

Half the team seems to really love that mode of working, but I for one am rather puzzled how you are supposed to focus and really think things through this way. Always having to articulate every single little thing and then switching control just throws your flow completely out of the water.

And one other bad side-effect I observed is that reviews are now taken much less seriously. No need to do reviews, since a PAIR already worked on it, right?

Not in my opinion - I think that reviews and subsequent communication are a much better way of knowledge sharing anyway and pairing is often just a management oversight excuse rather than a helpful technique/mechanism. Some devs also seem rather desperate to have others help them do simple tasks. It feels like those people in school who tag onto your project because they know that you and that other girl will do all of the work.

If you're in the team for 3 years I would expect you to be able to read some code and understand what it does. Or read docs of some framework. But nope, some people just NEED others to tell them how it is done and by next week they already forgot it anyways. And when I want to read some docs? Enjoy those eyes and intermittent verbal injections from that Zoom call.

Uff - I am rather frustrated, but as mentioned early in my comment, I do see some real benefits of pairing. Just not 100% of the time all the time with always-on Zoom cams.

Couldn't agree more. I worked 2 years 100% pairing, it's just too much. I also have some mildly introspective personality and the extra overhead of communicating every single word typed not only interferes with my deep thinking, but would make me feel exhausted by 4pm, instead of my normal capacity to work long hours for quite a few days before starting to realise I needed to rest.

> Some devs also seem rather desperate to have others help them do simple tasks. It feels like those people in school who tag onto your project because they know that you and that other girl will do all of the work.

Ahh, the non-programming programmer strikes again! [0]

[0] https://blog.codinghorror.com/the-nonprogramming-programmer/

The non-programming programmer thing is kind of astonishing.

Are there actual CS programs somewhere where people can graduate without actually writing any code? Maybe theory, HCI, or hardware tracks? Those could still be great employees.

And don't many candidates have code on github where you can just look at the commit log and ask them about the code they wrote?

Moreover, tech companies seem to be infatuated with awful technical interviews that not only make you write code but often require you to solve some difficult algorithm puzzle at the same time.

> Are there actual CS programs somewhere where people can graduate without actually writing any code? Maybe theory, HCI, or hardware tracks? Those could still be great employees.

There are absolutely. I however, disagree with the idea they could lead to great hires.

I've also seen "masters" in CS that were really a lighter version of the undergrad coursework [0]. Of course, these were separate from the PhD track masters.

> And don't many candidates have code on github where you can just look at the commit log and ask them about the code they wrote?

Yeah. But the type of student that has an active github, even if it's full of assignments, isn't the type that will interview often. So you better make him/her an offer fast. There's a complete subset of great hires completely invisible to anyone because FAANG hired them first.

> Moreover, tech companies seem to be infatuated with awful technical interviews that not only make you write code but often require you to solve some difficult algorithm puzzle at the same time.

There's a reason they are doing it, to filter against these folks. Asking for algorithms also weeds out bootcamps where, more often than not, students are taught only one "trick" and stack and generally lack the fundamentals to be able to switch to an other stack or problem area.

[0] https://news.ycombinator.com/item?id=5786720

Still a gem, thanks!

I feel like this is mostly related to eliminating miscommunications.

A lot of people just jump right into developing without asking the right questions first. Especially when given ambiguous orders.

For real. I’m a contractor that bills by the hour which means I have a pretty good understanding of cost of features.

At a previous client I got a ticket that would mean rewriting a large part of the application, to the tune of €10k. Something didn’t sit right with me and I started sleuthing around the org chart, asking relevant people questions. The €10k ticket became €0.5k in research and two-line css fix + different copy in the UI

so how did they reward you for the cost savings you helped them to yield?

By renewing my contract for 6 more months.

I am a contractor, I get paid for hours spent. If I got paid by money saved I’d be a consultant. Small but important difference and wildly different business models.

The difference is clearly explained but then the contractor (@brtkdotse) does the work of the consultant but as a contractor and reduced their own billable hours.

Business renewed the contract because they're realizing they're getting both roles for the pay of one.

you did the work of a consultant. you surely have it in you. take the next step

I like to ask my colleagues often, brainstorm a bit with them etc when solving problems. Usually after pondering the issue a bit I get an idea of what a good solution would be, but often I can get valuable input from my coworkers.

Maybe I've missed an important corner case. Maybe my coworker has worked on something similar or relevant and has some code or technique I could use. Maybe I've been overthinking it and a stop-gap is better until we can make a more informed decision.

Sometimes just a tweak can make a significant difference, other times I end up going a completely different route.

I'll also email or phone customers if I sense a X/Y problem, or if I don't fully get their feature request or bug description. I'm not a domain expert and it's good to have context.

All in all, indeed it's usually a good idea to not jump straight into it. Mull it over, talk a bit with someone.

Putting in time to avoid unnecessary work caused by miscommunication or lack of communication could be seen as an attention focused workflow: It is about making sure attention and work is focused on what is actually the problem, and not everything else surrounding it.

This study, and some of the comments here that state the opposite are too generic. Whether communication or focus is more important depends on the nature of the product that someone most work on. Some projects require vast amount of communication, like working in a startup that's solving hard technical issues on greenfield R&D territory. But if you're working in a mobile dev shop and doing the Nth same iOS app for example, then probably you won't need to bounce ideas with co-workers but know exactly what you'll need to do, and it requires focus above all to finish it as soon as possible. Of course most of the jobs are somewhere in between these extremes, but even in those cases the tasks usually alternate between the two.

The Bell study sounds similar to research John Seeley Brown references from Xerox, in The Social Life of Information (2000), particularly chapters 4 & 5 discussing research of Julian Orr.

Xerox repair techs' secret weapon was the morning pre-dispatch coffee session, where war stories were swapped.

A similar later reference noted information transfer (or lack) between techs and phone operators --- physically separating the two cut down on the operators' knowledge and effectiveness.

Cal Newport addresses the tension between deep work and collaborative work in this blog post (https://www.calnewport.com/blog/2014/10/15/how-to-win-a-nobe...) and on some recent episodes of his podcast (https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3B...).

The TL;DR is, Bell Labs was designed to balance casual, collaborative conversations with solo deep work.

1. Instead of having a computer science building, a physics building, etc, they put every discipline in the same building. They had shared areas for eating & discussing which pushed people to run into each other, and have highly cross-domain conversations.

2. Inside the building, the offices were a hub and spoke model. Individual researchers had quiet individual offices for deep thinking they could retreat to AFTER they've bumped into someone at lunch from a different field.

In most open offices today, we've forgotten about the deep work spaces and ONLY kept the collaboration spaces.

I think you are thinking about this talk by Richard Hamming [1] at Bell. Search for “door closed” for the part you’re referring to.

[1] https://www.cs.virginia.edu/~robins/YouAndYourResearch.html

Well, I suppose someone can be very productive in building the right solutions for the wrong problems.

Both important. It’s just that the world today is gear toward communication to the point of overloaded your every sensory available. What left of attention are all stole by social media and their ilk. People just can’t focus anymore, and when one cannot focus, one cannot attain higher skill one wish for. That’s the point, in my opinion, of course.

You can always reference "You and Your Research" by Richard Hamming, which again is anecdotal and not the study.

https://www.cs.virginia.edu/~robins/YouAndYourResearch.html

How did they measure productivity?

It strikes me from working in tech that in practice, perceived productivity is often simply "communicated productivity" rather than actual productivity. I'm curious to see what the proxies for productivity would be used in studies such as this.

Couldn't find said study. I would be interested how they measured productivity.