Admin
Photo by 4nitsirk on Flickr

I was on Twitter the other day and stopped in a tweet of a developer (@adelatorrefoss) who had given a talk and had had a bad experience.

The talk was about how to face a legacy code that was newly given. The talk was going fine until some attendants started to disagree with the choices made by the speaker and the speaker’s company. He tried to explained better but the talk completely derailed.

Problem and solutions

It’s ironic how hard software is. We, software developers, are the people with less soft skills in the world. We have problems managing our feelings and building our proposals.

The speaker

When we are the panelist, we should have clear a few points:

  • We are offering our experience, not necessarily our expertise or wisdom. We might be wrong and the choices we’ve made might be mistakes.
  • We are summing up complex situations, so the solutions that can be shared by attendants might not be suitable for your situation (there could be suitable for other attendants, though).
  • Your main aim in your career is to be wiser than the day before. We should accept and show that we are willing to take into account proposals offered by others.

With the previous points, we should have prepared answers like:

  • We didn’t think about it.
  • We tried it, but that was not possible at that time. I’m afraid I cannot remember the problem with it
  • We tried it and, if my memory serves me right, we couldn’t keep with it because of…

On each of these answers, there should be clear that you are willing to:

  • Request more info from the person offered the solution (what? why? how?)
  • Try it again on Monday when you get to the office.

The attendant

Having ideas in our head is one of the beauties of being developers. However, we keep having problems expressing them. One of the worst things you can do when expressing your ideas is hurting others. The only way Github could be successful is because pushers are not afraid of failing. There isn’t an army of haters laughing at that 2010 commit you pushed after discovering what Python was.

We have to be grateful and careful with this gift of experience sharing.

Every time you give a solution, you should have clear a few points:

  • What you are giving is your solution, a solution you might have thought 2 seconds ago after someone explain their problem. Remember that time when you discovered the client didn’t explain to you well the requirements and the solution you implement was no longer suitable? Imagine your client giving you the requirements for a new project in a talk.
  • The speaker is not the master of the universe, if you have a valid solution for their problem, you should present it to them, not throw it to them.
  • Choose Your Own Adventure. A: The other day, I was in a talk where the speaker was a completely dumb and I had to make them realize about it. B: The other day, I was in a talk and could help the speaker to solve a problem they had and didn’t know about it.

With the previous points, we should have prepared answers like:

  • I’ve just thought you could… Did you tried? There was a problem when you tried…?
  • I had a similar problem a while ago and we did… We could do it because of this, but I’ve heard people having problems because of that. Is that your case?

On each of these answers, there should be clear that:

  • You don’t really know their problem. You’ve just listened to 15 minutes of them.
  • You are willing to know their problem in a deeper way and check again whether your solution is valid.
  • You are willing to know if the path you’ve chosen is actually wrong so you can fix it on Monday because it might come back to bite you 3 months later.

We are missing the point of being here if we don’t collaborate with each other as much as we can.

If I have seen further it is only by standing on the shoulders of Giants. – Isaac Newton