I read an interesting article about programming today, the author says that learning to program is easy, it’s working “Deep” for long periods of time that is difficult. I think this a really insightful way of looking at mastering skills. It’s really easy to jump to the next email or ping when you’re learning because you’re afraid to fail at learning. When learning becomes difficult, people have a more difficult time keeping focused – even if they have an incentive (Pay check or paying someone) to learn.

This can be exacerbate by not having a good environment to learn in or a good teacher. A bad teacher that isn’t willing to give you the examples that you’re able to learn from in a constructive environment is wasting everyone’s time. However, if you’re self learning, then you’re going to be using mostly Google searches or maybe a few books here and there. The best way to learn then is to give yourself an interesting project related to something you care immensely about. I’m not an expert at programming, but I know when I’ve learned most successfully it’s been when I have a clear objective with the right tools in front of me to dig into the problem I’m trying to solve.

There are tools out there that make doing this sort of work easier and others that make this work more difficult. Git and all it’s various version are tools that can, once you learn them, make deep work easier, because you eliminate the fear of mistakes. If you screw up too bad you can simply start over from where you were. Breaking your project into chunks becomes much more important so you can work on items without risking the entire project.

There are other tools like Slack, that apparently, can really be a detriment to deep work. There was a breakup letter about this topic that’s been getting some attention. I think it’s focusing on the incorrect problem. Slack isn’t the issue here, it’s the person doing the work and/or the work environment that has caused the problem “Breaking up” with Slack is like breaking up a hammer because you’re unsuccessfully screwing in screws. The tool is not at fault, it’s doing what it’s designed to do, hammer in things, you’re applying it wrong or using the tool incorrectly. Yes, in this case it is not the right tool for the job, but you’ve done a poor job defining the problem you’re trying to solve with the tool.

At my company, I think we’ve come up with a pretty good solution to this. We don’t use Slack, but it’s competitor HipChat, pretty similar overall, but with the right tools integrated together, you’re able to create rooms for specific features. These are tied together between Bitbucket, Jira, and HipChat (yea we went all in on Atlassian), which means you’re able to see all the information you need about the problem the feature you’re working on is trying to solve. We’ve started to use this to pull in the voice of the customer (me in this case I’m not a developer) earlier into the process so that I am able to give feedback quickly to what the developer needs. This allows the developer to meet my acceptance criteria by getting quick feedback and then getting back onto the deep work of really writing the software.

In some cases can it be disruptive? Yes, but that’s only if people aren’t using it correctly and we work with them to change their behavior before it becomes a problem. Slack, Jira, Bitbucket, et al are only tools that are designed to reduce the burden of working with remote team members to enable us to get down to the nuts and bolts of deep work for programming.

Take a look in the mirror if you’re struggling with learning programming or using a tool like Slack. You’re the problem, create a structure around how you work and how your team works. Use your hammer on nails not screws.