I've worked as a solo software developer for the government for a little over a month now. Basically one person hired me as he doesn't know programming. I find it challenging for me to do my job well as there's a large disconnect in the bodies of knowledge: the people I work with are foresters. To remedy this I've tried taking the time to talk to my immediate supervisor and ask questions. This hasn't worked so well.

I was mentioning to another supervisor that I'm having communication issues and he painted it as 1) the person grew up in the Soviet Union and has a very different culture than ours 2) I need to earn his respect before he will be open to new ideas.

I think I'm being misinterpreted. 1) I understand there's a cultural difference but asking questions such as "will this module always be called by this module or could some other module call it?" I'm not sure how to reword it to better fit his culture. 2) I wasn't trying to do things differently. I was doing what was asked of me (or at least my interpretation of it).

I really want to communicate the distinction between "I'm having trouble understanding this person" vs "I don't like this persons culture/communication style".

For the technically inclined: I implemented the requirements using an object oriented approach. The requirements asked for "2 modules" so one was the main file and the other was a class. The programming language was required to be Python but an executable file was required. To do this I used a python to executable converter but it only outputed 1 single exe file and my manager wanted more than 1. I did ask him if the second module would be called by anything except the first and he said no. This is just an example and I don't hold prejudice, I'm just unsure how to prevent this from happening again in the future.

2 Answers 2


It's good that you recognize communication issues, but you seem to be taking the approach that the other person needs to change in order for you to be successful. You do not have control over your supervisor, but there are things you can do from your side to make the communication more effective:

  • Think about assumptions you might be making and confirm back to your supervisor that you and he are truly on the same page. For example, "You say that the program should have two modules. I want to be sure I understand what you mean by module. Are you referring to classes, packages or something else?"
  • Explain what you are doing and ask for explicit confirmation before taking action. For example, "You said that these modules would never call each other so I am planning on combining them into a single executable. Is this OK?"
  • Ask for intermediate feedback on what you're doing. For example, "Yesterday we agreed that there would be two modules. Once I got into the details, it didn't make sense to have them be two separate executables. Here's what it looks like now. Is this OK?"
  • Also, after any verbal communication where a decision is made, send a follow up note to confirm the decision. For example, "Hi XXX, As we discussed today, I will implement this as two separate modules inside a single executable. Regards, Codey12"
  • Before jumping into your actual question, be sure to provide enough context to your supervisor so that he can understand why you are asking that question. For example, compare these:
    • "Can I implement this as a single executable?"
    • "Yesterday we discussed implementing this as two modules. I started creating two different classes as we discussed. It seems to make more sense to put these into a single executable. What do you think?"
  • Be sure to clarify for yourself what your real question is and try to ask that first. Compare these two examples:
    • "Is it OK if I combine these two modules into a single executable?"
    • "Will these modules ever call each other?" .. "No" .. "Are you 100% positive that these modules will never call each other?" .. "No" .. "Are you still sure you want it to be two separate modules." .. "Yes" ...

You're saying that your manager doesn't understand programming, and then you start asking him programming questions. As Eric points out, you can't change his communication abilities, but only your own. And you need to quit speaking geek to him, and start speaking a language he understands.

Avoiding speaking in jargon can be hard, but when you're talking to non-technical people, it's very important. You need to understand what he's talking about when he said to make "2 modules", you need ask what that really means (if the spec doesn't clarify it in a technical manner). You need to understand the business needs for 2 modules, and then solve the problem in whatever technical way that makes sense and fits the business requirements.

If he asks for something that makes no technical sense (like 2 exes), then try to understand what his real concerns are. But you're going to have to speak in his language only, and skip all the technical jargon. If he's not technical, he shouldn't even know or care about the underlying solution, the number of executables. Show him what it does and see if it's solving his need and fitting the requirements. Words like 'object-oriented', 'executable' -- avoid words like that unless you know he really understands what you're talking about. Right now, it sounds like he doesn't.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .