8 ms·
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 orie
by erikb 9y ago
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.
- mlevental 9y agovery insightful. thank you.
- morinted 9y agoYou'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.
- ahuth 9y agoWell said!
- shadowmint 9y agoThis 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.
- morinted 9y agoIt 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-team-messaging-521804a3da09?gi=46bb9c55f8bc 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.
- foobarian 9y agoI 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 9y agoI 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 9y agothe question is more "do we need a bot for this" and not whether the actual action is productive
- jjrh 9y ago> 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 9y agoThat'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.
- halfteatree 9y agoBut 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.
- cobbzilla 9y agoI 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.
- erikb 9y agoYou 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 9y agoMy 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.
- deleted 9y ago[deleted]
- quickthrower2 9y agoYou 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.
- sidlls 9y agoI 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 9y agoI 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 https://www.youtube.com/watch?v=oyVksFviJVE
- gxs 9y agoAs 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.
- nerpderp83 9y agoThese are all people tooling problems.
- sjellis 9y ago"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 9y agoI 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 9y agoChat 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 9y ago> 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 9y agoThen 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.
- com2kid 9y ago> 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.
- Too 9y agoWith 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.
- Flenser 9y ago> 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.
- tboyd47 9y agoI 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 9y agoIn-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 9y agoI 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.