How can I learn to communicate better with colleagues from another profession?

Question

My experience is in online marketing, UI/UX and web design, but I know virtually no programming. I have recently been hired to build a new, fairly complex site from scratch, for which I will be working with an experienced programmer with whom I have worked extensively in the past.

Although I have a decent understanding of certain technical concepts relating to web development, I would like to build a better appreciation of the programmer's craft, in order to improve communication with my programmer, as well as the client.

I been thinking of reading some programming books like Code Complete to learn some basic programming, but don't actually want to be a programmer.

What can I do to better understand the most common concepts from another profession so that I can communicate and work more effectively with professionals and colleagues from that field, without actually learning their profession?

Answer 1

Are books even the way to go, or are there other ways that I can learn more about how best to communicate with these colleagues?

The way you originally describe your approach makes me somewhat pessimistic about its feasibility. Learning all that one may (or may not) possibly need up front to build a better appreciation of the programmer's craft could just take too much time.

• Software specifications, issue tracking, estimation techniques, design approaches and development methodologies, functional and regression testing, technical debt and maintenance considerations etc etc etc - getting into all this could be like drinking from a water hose.

I think that more realistic way to communicate with programmers for a non-programmer who just wishes to understand the most common concepts and issues involved in building software are regular 1:1's.

For a reference on how to do that, consider an excellent article The Update, The Vent, and The Disaster. This article is written from a perspective of a dev team manager but in my experience similar approach also worked in a collaboration between a client/designer and a programmer like you describe.

...I’m not suggesting that every 1:1 is a tortuous affair to discover deeply hidden emergent disasters, but you do want to create a weekly place where dissatisfaction might quietly appear. A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team.

...The sound that surrounds successful regimen of 1:1s is silence. All of the listening, questioning, and discussion that happens during a 1:1 is managerial preventative maintenance. You’ll see when interest in a project begins to wane and take action before it becomes job dissatisfaction. You’ll hear about tension between two employees and moderate a discussion before it becomes a yelling match in a meeting. Your reward for a culture of healthy 1:1s is a distinct lack of drama.

• ^{A very strong point of above article is that it is self-contained, in the sense that besides explaining benefits, it also provides a set of practical recommendations basically allowing one to start practicing regular 1:1's without digging into other sources (although looking for additional information won't hurt, you know).}

With regular 1:1s you will be able to pick and focus on learning particular topics that are of specific importance in every given moment. If you do it right - if you talk, ask and listen carefully - you will have enough time to find and study needed resources, without being pressed by unexpected urgency matters: "Your reward for a culture of healthy 1:1s is a distinct lack of drama".

---

_{Regarding books, since you mentioned Code Complete, one probably can't go wrong using it as a general reference (here, I am talking about Second Edition, the one I studied). It's a masterpiece, a fundamental and well presented overview of professional software development giving deep analysis for every imaginable area of it. Since you already have it, consider skimming through chapter on Collaborative Development Practices: per my recollection it has been most compelling of all I've read on these matters so far.}

_{Code Complete is a truly profound resource, great for a thorough study - but exactly because of this, I would really hesitate recommending it to someone needing a quick introduction to the concepts of software development. For the latter, I'd rather pick Facts and Fallacies of Software Engineering - small, easy to read book. References provided in each section allow for a deeper topic study if needed. Recommended reading for those interested in getting software right.}

Answer 2

There are lots of great books out there, as noted in other answers. But asking us for recommendations isn't the best approach: any time I have needed to learn more about the domain of a subject-matter expert, I have gained the most by asking that person for recommendations. You and your coworkers are partners working toward a common goal, and it's in their best interest for you to learn more without wasting your time on stuff that won't help. They're in the best position to guide you.

Answer 3

For communication, it's more important to understand another person or group's way of life than to necessarily know the major points of all the steps of their profession. I'd focus on:

• War Stories - not only do people want to tell them, but listening attentively will tell you a lot about how they see their work, the environment they work in, and what is hard vs. easy in their world - all key things to know for collaboration. Plus, the PR side - people like to be listened to, and getting a chance to tell a new guy their war stories, and have thoughtful questions asked back is also going to generate positive feeling towards you.

• Jargon finding - There is a TON of lingo in this kind of work. Tools, languages, processes, methodologies, models, and more - all have unique names. Some span the industry (put a J in front of it, and it's probably something related to Java), some are unique to the office (like the TPS report in office space). When I've had to ramp up here, Wikipedia is my first line of defense, followed by asking for terminology dictionaries, and internal sites that define processes.

• Code Complete, specifically - is an interesting read because it is about the business of good software development. It may be a nice resource for that, as it's all about good ways to do things, rather than the how-to of the basics of the thing. One thing to watch for is that any software group will have its own ways of working that may or may not adhere to best practice, so be wary of making unilateral assumptions based on a book like this.

• Talk to the programmer & client - Sometimes knowing everything about how someone does his job is a detriment. The important part is being sure that you communicate clearly and leave them the ability to do what they do without providing hindrance through ignorance. Talk alot about why you want to do what you want to do, ask for recommendations, ask for feedback on whether you were clear, ask for restating of your request or offer the same - and ask why, why, why.

• Ask to witness the work - I found in doing software development, there was a style of working and a magical chemistry to how one does work in this field that no book could possibly summarize. The Nerd Cave is part of it, but there's more to it, and it may be that only by being walked through it will you get what are the real pain points and glorious moments of the job. FYI - Rands in Repose isn't a bad site for more developer inside info, but he can often use short hand or assumed cultural metaphors that may not be universal for an outsider... not sure - I've only ever read him with an insider's view.

Answer 4

There are some great answers here to the (original, specific) question, but as currently posed :

What can I do to better understand the most common concepts from another profession so that I can communicate and work more effectively with professionals and colleagues from that field, without actually learning their profession?

I would suggest this is an example of a wider situation I have frequently encountered, and not just in the software industry. From my perspective, the goal of the OP is to create an effective, multi-discipline team in as short a time as possible.

The key barriers to this are usually getting an understanding of the workflow processes the other profession uses, as well as the jargon that is employed.

It tends to be a lot harder when dealing with areas that are distinct and separate, but a “layperson” would see as the same – geology and geophysics for example – perhaps as part of the need for a separate identity can orginate when people are first trained.

I’ve resolved this in a number of ways (as team member, leader, and manager) and while self-education (via books, videos, blogs, articles) and one-on-one discussions have played their part, we’ve also put some other key things into play that might be worth thinking about.

• we have an in-house Wiki that’s used to define jargon, terminology, workflows and process. Its part of making what we do robust, but it’s a great place to start.
• we send people on (formal) training courses (an introduction to XXX)
• we have the occasional, short presentations on how/why people work in certain ways

For small, agile (in the non-coding sense!) teams that are reliant on technical experts working well together, these approaches can help shave some time of the learning curve.

I would suggest, however, that all “factions” of the team need to meet in the middle for this to be effective.

From an organisational standpoint it can be useful to get management buy-in, especially if training or "overhead" time is needed. This can be a challenge, however hopefully they will see the need to be able to create an effective, robust and scalable multi-disciplinary group.

Answer 5

While there are many good books on development one of the best series of books I have ever seen to get beginners and people just interested in development up to speed on the lingo and actually learn a bit of development is the Head First series from O'Reily.

I have included a few of my favorites to share with learners below

1. Head First Design Patterns - Great for learning basics of Design Patterns which developers use all the time
2. Head First Software Development - Start here for a great overview of the software development process and lingo
3. Head First Programming - This is a learners guide and uses Python but it is a great place to start as well
4. Head First Object Oriented Design and Analysis - Great for a more in depth understanding of these techniques which often come up when working with developers

Now I know the series of books might look a little hokey at first, but trust me there are effective and actually fun to read. If I had to choose for you to start with one first, either the Software Development book or Programming one just to get the right lingo and process down when working with your developer.

I hope that helps.

Answer 6

If i am correct then I believe you are not going to write lengthy codes for the project. Your main goal is to co-ordinate with the experienced developers time to time.

• Its a big project as you mentioned so i assume it must go module wise, ie the whole project is divided under different modules which has to be delivered on time.
• Programming is nothing but breaking the complexity of real world problems in code style.
• Try to understand each module and on what basis the project is divided under different modules.
• Think logically why a module is consuming time during the development phases.
• Co-ordinate with the team and try to co-ordinate with each member and most important listen what your team mate suggests.
• Ask them honestly about the hindrance they might face during the development process.
• If you think someone needs guidance/support for the task which you think on your personal level is not be a big one try the senior member to in co-corporate with the member to enhance the productivity and reduce the timelines.

For the technical leads you can follow some good Ruby/Python books or even some online courses are thr too over the web. Check http://codeacademy.com/ -> good to start as well. You can wiki some text also like this about the Agile development Agile Development

I believe these points not only going to help you in the recent project but will also help you during other project managements as well.

Answer 7

If you're not actually interested in becoming a programmer, reading programming books might not be the best way to learn how to communicate with programmers, as they'll be full of things you probably won't need.

Instead, I would suggest simply asking about terms you don't understand as they come up, or writing them down if it's not imperative that you know the definition of them right away, and Googling them later on. Often while you're learning the meaning of one word, you'll come across related words you don't understand and can ask about or Google those as well.

It shouldn't take you long to get up to speed on the most commonly used terminology for your situation, and to effectively be able to communicate with both the programmer and the client using their language.

Personally I prefer to write down terms and look them up myself later on unless I need to know the meaning of something immediately to do my job effectively, however as Shana mentioned in a comment below, if you're up front about not being very knowledgeable, that gives others the opportunity to use words you're more likely to understand, and they will likely be more receptive to rudimentary questions that you might have.

Answer 8

Short Answer: Ask your programmer college about this topics that you may wonder. I hope you have friendly environment and he will be more than happy to direct you on a right source.

In addition to the classical book "Code Complete", i would strongly advice to consider the - Facts and Fallacies of Software Engineering. That books is kind of a revelation and has a number of true facts proven by statistics and researches.

The practice of building software is a “new kid on the block” technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative “newbies.” In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about.

However, depending on the requirements of the application that you would be working on it, you may also need to get a framework/language specific book.

Answer 9

I would like to build a better appreciation of the programmer's craft, in order to improve communication with my programmer, as well as the client.

Take a look if there are any Code Camps in your area where developers will get together and build things during the camp that could be quite illuminating. There may also be user groups or Meetups where developers could gather that may be useful to socialize with other developers to get a better feel for them and try to make generalizations to some degree, though one does have to be careful about dependence on generalities that aren't universally applicable.

What can I do to better understand the most common concepts from another profession so that I can communicate and work more effectively with professionals and colleagues from that field, without actually learning their profession?

You could look into the SDLC that may help with the big pieces of IT projects though I'd be more tempted to suggest being aware of slang terms and then talk about them in a social setting so you can understand what they mean. Kludge, hack, and patch would be just a few words that I'd imagine could easily be misinterpreted if one doesn't know the context of how it is being used. The key here would be picking up on the lingo used which may or may not be easily known. Another route is to consider researching various companies within your specialization as well as knowing a bunch of acronyms.

Answer 10

Don't underestimate the value of just talking to your programmer colleague.

Books are fine, but your goal here is to improve your ability to communicate with your partner. Consider the improvement in your rapport if you explicitly demonstrate a desire to learn more what he or she does.

In addition to your learning experience, it will help your programmer to feel like a valuable partner and, hopefully, will encourage them to learn more about what you do, in kind.

The book suggestions above are great and you can learn from them... just don't forget to talk to people too!

Answer 11

In addition to the other book suggestions, I'd recommend Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology, which describes the progress of a (fictional) software project from the perspective of both a UX designer (Ellen Isaacs) and its developer (Alan Walendowski), the challenges they meet and compromises they make as they have to work together towards the common goal.

Answer 12

As a programmer, I have observed that the reason communication is strained with non-programmers is quite simple.

Programmers must think very, very precisely. They think that way because they need to be able to communicate to a computer how to operate and they require very precise instructions.

Most people don't think or communicate in this way.

For example, someone in sales might suggest, "You know what would help, a new tool for generating leads!"

The UI guy thinks, "It'll look like this", without any determinate amount of precision. He'll rely on his creative/artistic instinct a lot, and if he's any good, sound design principles with a backed body of research and data.

The programmer will think, "How will leads be generated? How should they be stored? How should they be presented? What about security? What type of security? Simple transport layer encryption or data encryption? What type of encryption? What type of block cipher mode?" etc etc etc

Programmers need to think this way because they must build the thing from the ground up. It's like a carpenter having to think about the right type of screws to use or about city ordinances while laypeople are relating to them in generalities like simply wanting a house.