[erikb]

A common discussion I have with other developers.

For a developer I'd say I'm a little more people minded than average, and a lot more big picture success oriented. And in both regards your personal productivity doesn't really matter.

The biggest problem in software development is actually not per-coder-performance but that the right things get solved, and that the solution are actually good and quickly finished. Think about how much time you wasted using a colleagues API that simply wasn't designed well, at least for your usecase.

So, if more information means you are working on the right things, and that you understand your users better, and therefore make your tools more intiutive and usable, a hit to your performance, even 50%, is not a problem.

The funny thing is from a big picture perspective sometimes it would be good if some developers would just reduce their code output, without providing anything else, because it would help keep all other developers in the loop.

[shadowmint]

This is well said... although I think its unlikely to be a popular opinion with people at a personal level, but I hope the people who find themselves disagreeing take a moment to reflect on it.

While I think it's fair to say these sorts of applications do disrupt people and reduce their productivity, I'm certain that they help focus team efforts in a way that meetings just don't.

You can't split off 3 members of the team and have an important technical discussion during a meeting (or if you can, your project manager / meeting organizer isn't doing their job). You can't come back later and see exactly what it is you said that you'd do after a meeting. You can't tell a bot to create a bunch of tickets or what the current status of a system is.

If you find that your chat apps are not providing you with any value, maybe you're using them for stupid purposes like sharing funny pictures & this mornings cool tech blog post, or you're subscribed to the support channel, or your team is treating them like a social hang out space.

It's not that its a bad tool; its that you're using it wrong.

[foobarian]

I don't think funny pictures are a stupid purpose. They cheer me up and expose a different side of my coworkers, increasing morale and team cohesion. Of course they happen to be the right kind of funny pictures/links. :)

[epicide]

I think the point was: if that's all that you use it for, then of course it won't help productivity. It's like any other tool: it can be used to build or destroy.

[tomphoolery]

the question is more "do we need a bot for this" and not whether the actual action is productive

[morinted]

It doesn't help that emoji and giphy are listed as prime features in this new offering.

You're right that the applications can be used productively. I find that my work Slack is a lot less focused on being productive than the dev channels that I follow in Discord for open source projects.

The other big issue is the discussion of asynchronous versus realtime communication: https://blog.doist.com/why-were-betting-against-real-time-te...

I do find that in some Discord servers we accidentally exclude people living in different time zones, which is not as much the case with an async medium like Google Groups or other mailing lists.

[jjrh]

> If you find that your chat apps are not providing you with any value, maybe you're using them for stupid purposes like sharing funny pictures & this mornings cool tech blog post, or you're subscribed to the support channel, or your team is treating them like a social hang out space.

There is nothing wrong with doing that if it's in the right place - the off topic channel. The same is true if discussion that doesn't concern you is happening in a general channel - you tune out and don't see a message that are relevant to you.

[Retric]

That's still small picture thinking. Dropping efficiency by 50% is the equivalent of spending 4+ hours in a meeting every day.

If your team needs that kind of overhead then something massive is broken and a chat room is not going to fix it.

As a general rule, on large teams informal communication is vastly less efficient than formal communication. A major goal should be avoiding having the same conversation repeatedly.

[cobbzilla]

I wholly agree. If you measure efficiency by code production and feature/bugfix turnaround time, I guarantee you can lose a huge percentage of your efficiency very easily. How about a 15 second interruption every 10 minutes? The amount of useful work you got done that day might be well below 50% of an "undistracted" day.

The overhead of constant context switching has a high price. If this is happening on your team, no tool can fix it. You have to fix the culture, and that's much harder.

[halfteatree]

But no one is saying you should use instant messaging or informal communication for everything. It's a tool, and it's good at certain roles, for example, a log that includes context for investigations into incidents.

For design docs, formal notifications, etc., there's still email and services like Quip. They are not mutually exclusive.

Having day to day discussions in informal channels and consolidating them into a more formal form of communication is a workflow I enjoy working with.

[erikb]

You need to consider that a coder most oftne self evaluates performance as time spent writing code. If he spends 50% of his time planing, learning, comunicating, and 50% coding he will consider it a 50% performance drop.

[nerpderp83]

My productivity is measured on

1) me understanding the domain

2) finding a well factored solution to the problems in that domain

These things are incredibly hard. Using chat is like skipping a meal or a nap. Communication isn't valuable in and of itself.

[tigroferoce]

I like 1) a lot. It is too often neglected, but understanding the domain, actually understanding what the customer really wants are very difficult tasks.

[gxs]

As a product manager for one of the big tech companies in the bay area, I agree.

Most problems that we solve on a daily basis aren't cutting edge, they are complicated business logic or customer facing UI that needs to be tested more than anything else.

Communicating requirements and vision at this point become more important than having your "rockstar" engineers outshine everyone else.

That said, one thing I've learned is that you can't please developers.

The same people on this forum that are deriding "personal communication" in favor of more formal communication are the same ones that complain about project managers and "unnecessary" status updates and communication.

I typically just do whatever the team wants, makes no difference to me whether they like to figure out everything in conversation or desire more formal status updates etc.

At the end of the day if I see the team gelling and working at a good clip, I don't mess with them and try to stay out of their way.

[sjellis]

"That said, one thing I've learned is that you can't please developers.

The same people on this forum that are deriding "personal communication" in favor of more formal communication are the same ones that complain about project managers and "unnecessary" status updates and communication."

I agree with all of your points, except this one. My own view is that managing a technical team is just extremely demanding, and many managers simply aren't up to it. Developers are educated, intelligent professionals who spend a lot of time thinking and talking about a range of specialized technical stuff. If managers can't keep up with their team on their own resources, they end up asking for more of the team attention to compensate. And from the point of the view of developers, that is unecessary communication that they don't get value from.

[gxs]

I think what you're saying is that if a manager can't adequately track what their team is working on and how they are doing, they put the burden of that gap in communication on the developers.

This is a valid point, some kind of asymmetry in the communication.

I don't think this contradicts what I said, rather branches off into another subject, whether your reporting manager is doing a good job or not.

[nerpderp83]

These are all people tooling problems.

[quickthrower2]

You are correct but so often we are measured on individual productivity. And you get what you measure. So team members will want to work distraction-free to max their KPIs.

Your insights good, it needs to be needed by managers and staff that the team is working as a team.

[Kadin]

I recently re-read the classic "Peopleware" (written 1974) and I think it's a bit unfortunate, given all the innovation elsewhere in the field, that there hasn't been much innovation or even experimentation about the nature of employment or how teams are constructed and actually execute work.

Sure, there's a new "method" every few years but these seem like tinkering around the edges.

I admit this is not a fully-formed idea but I've wondered about a concept where an entire team would be compensated as a team, but then the team would be responsible for hiring/firing. (Which seems only fair -- if you're going to be compensated as a team you should have control over it.) A group "audition" interview technique is discussed in Peopleware that I have sadly never seen implemented, but something like that could form a part.

But as long as people are compensated on an individual basis there will always be an incentive to treat communication and particularly assistance or training of other team members as a second-tier function, to be done only reluctantly if at all. But viewed from the throughput or potential of a team, someone who increases the performance of multiple other developers has a much greater shot, in my experience, of being the mythical "10X developer" than even a very strong individual contributor. And the reverse is certainly well-known to be true: someone who hurts the performance of people around them, even if they produce good code at a reasonable rate, may actually be worse than useless to the team as a whole. Producing an incentive structure that takes those issues into account that's based on measuring individual performance is extremely difficult, and I've begun to think impossible, given that the industry has been trying to do it for decades with little apparent progress.

[lovich]

The team based compensation is interesting but I don't think any company other than some startups would go for it. The main reason would be falling afoul of discrimination laws. The teams would be highly incentivized to exclude people that they thought would be less productive, say a pregnant woman who the team thought would be out for a long period, but the government will be holding the company accountable and not the team itself.

It's the same result of you get what you measure

[mmirate]

Isn't this problem theoretically also suffered by e.g. ~5-person contract/consulting shops?

[lovich]

It is and in my experience small consulting shops are a lot more open to folding if something goes bad and reopening as a different entity or with a slightly different group of people. Any larger firm or group that's in it for the Long haul doesn't have that option.

The more I think about it the more it seems like small consulting shops basically are team based comoensation, but it still ends up with 1-2 people deciding who gets paid what more often than not

[erikb]

I haven't experienced that at all. Okay, yes. When you ask your boss what he measures you about, he'll give you performance data. Tasks closed, commits sent, LOCs produced, etc. But what he really measures are top features you produced. And that happens rarely. I think for a really talented guy it's 0.5-1 top success per year. And these don't need to be measured, they are team memory.

Ask your team who is most talented in their eyes. They'll agree on a small number of names. And if you ask them why they believe it, it's something like "because he wrote our test automation" or "he's the guy you ask about that really nasty part of ancient code". Everything else is only for self-fulfillment of the developers.

E.g. https://www.youtube.com/watch?v=oyVksFviJVE

[quickthrower2]

YMMV as they say

[sidlls]

I make sure that the people manager of the junior engineers I mentor know that my view of the productivity they are evaluated on is that it's related to the quality of their engineering, not output quantity, or even output per se. A significant part of engineering is bringing clarity to a problem, usually by engaging in a proper process of requirements analysis and design. Time spent slapping code into an editor ought to be less than the time spent doing other engineering tasks. Frequently it ought to be much less.

[erikb]

And that's what people think (me too, no exception here) two years after they come out of university.

[sidlls]

What do you mean by "that?"

[nerpderp83]

Chat breaks the flow, flow is necessary for cohesive elegant solutions. If we develop under a state of distraction, we end up making bulldozer-code.

Furthermore, chat is not high quality communication. It is mostly junk comms. If we wanted to encourage communication that moved the organization forward, we would have a structured medium that would automatically populate a knowledgebase.

Chat is not that medium. Chat is shat.

[com2kid]

> Chat breaks the flow,

Until I encounter a problem, switch into chat, and find that someone else already solved that problem and it was archived by the chat system.

Flow maintained.

My chat apps run on a separate monitor that is purposefully not within my visual range of the monitors used when I'm coding.

[quickthrower2]

Then that's asynchronous messaging. Like email.

The thing I hate is the opposite. When I'm told off for not replying to a message. Ergo need to keep it in visual range and stop what I'm doing on each message. Even if it's an inane broadcast from a team member.

[Too]

With chat everybody has the same persistent view. Email everybody organizes differently.

Some people delete emails after reading them, some put in folders, some tag everything, some have an inbox with 100000 unread emails. If I tell a colleague that I emailed them the info a week ago half of them will not find it and just ask me to send it again.

With chat I can just say "it was posted in the QA chat room about 2 weeks ago" and everybody will find the info equally easy.

[com2kid]

> Then that's asynchronous messaging. Like email.

Except organized differently, and easier to author rich content with. And the performance is better, messages are sent instantly. The overall UI is better in many ways.

That said email having subjects makes it different.

[ec109685]

Look at Chat when you have a free moment. Leave the app icon badge on but turn off intrusive pop-up notifications. Problem solved.

[tboyd47]

I agree with you completely on your main point, but you must admit that a person needs some time to concentrate in order to produce code. Even just 2 hours a day.

Unfortunately, a lot of companies are starting to measure "time working" via "time on Slack." My company is one of them, but it works out for us because my team exists in multiple time zones (making the interruptible hours of the day fewer).

This is not a problem that's specific to Slack. I guess if you're working in an open floor plan, you would have the same problem - or perhaps many people would be more shy to bother someone in person than online. Slack (and apparently this new tool too) doesn't help though. It seems to support an ever increasing array of notification options. You can set your status to "do not disturb," but people can and will still ping you when they feel like it.

[ThrustVectoring]

In-person has non-interrupting ways to get information about how busy someone looks. Chatting someone up at the water cooler is much different than someone at their desk, which is different still than someone who is looking through things with headphones on and a puzzled look on their face.

[kelnos]

I think there's more of a balance between collaborative & big-picture work, and heads-down focus, than you let on.

Sure, teams need to be working on the right things, in the right way, and need team leaders who can focus on the overall product itself, as well as the overall technical direction. But sometimes (often?) you just need people to avoid and ignore distractions and get their work done.

This doesn't just apply to developers; I hear from many non-technical staff where I work that things like Slack sometimes cause more interruption then they're worth, and need to sign out to get their job done. There is definitely such a thing as information overload, and there is definitely such a thing as interruption/notification overload.

[morinted]

You're right, but most communication to solve big issues for me do not come from chat apps, but that's also affected by the fact that the company I work for doesn't have remote workers.

[Flenser]

> sometimes it would be good if some developers would just reduce their code output, without providing anything else, because it would help keep all other developers in the loop

Oh yes!

I once worked with someone that was so prolific that I had no chance to keep up-to-date with their changes and get my own work done.

[mlevental]

very insightful. thank you.

[ahuth]

Well said!