Iyfjky

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?

Hi @Zak833 - I'm glad this question was migrated over to Workplace SE. I've edited it just a bit; please feel free to rollback the edits or edit further. — Dec 19 '12 at 15:56
Dune, Lord of the Rings, Some Asimov, maybe some H.P. Lovecraft... Oh, TECHNICAL books... nevermind. — Dec 19 '12 at 15:57
@Philip how could you not mention Hitchhikers Guide to the Galaxy and of course watching anything from Monty Python. — Dec 19 '12 at 17:09
Although I'm joking about it, familiarizing yourself with his cultural background could help with smalltalk and camaraderie, which go a long with to help communication. But that's a tangent to your question. — Dec 19 '12 at 18:15
Hi Zak, we've edited your question a bit to fit the scope of The Workplace, as the original version of the question asking for resources to learn about programming without actually becoming a programmer was off-topic. I hope we didn't change your question too much, but feel free to edit your question further if we missed anything. — Dec 19 '12 at 19:17

Communityâ™¦ 1 · Accepted Answer · 2017-04-13 12:48:42Z

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.}

Ordering Facts and Fallacies... Thank you.
â€“Â zakgottlieb
Dec 19 '12 at 22:23 — Dec 19 '12 at 22:23

Monica Cellioâ™¦ 43.7k17114191 · Answer 2 · 2012-12-19 16:04:17Z

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.

In this case, I don't think he has any good recs - but it's sound advice nonetheless. — Dec 19 '12 at 22:20

bethlakshmi 70.4k4136277 · Answer 3 · 2012-12-19 21:37:59Z

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.

Great answer, thank you @bethlakshmi. I might try to do some screen-sharing with my programmer at some point. — Dec 19 '12 at 22:15

Communityâ™¦ 1 · Answer 4 · 2017-04-13 12:48:42Z

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.

Instead of writing down terms you don't understand and then googling them later, why not ask right then, "What does X mean?" — Dec 19 '12 at 16:54
@Fernando There are many reasons you may not want to do that. The most common reason for me is not wanting to interrupt the flow of the meeting, particularly if the term isn't that important and could steer the meeting away from its primary purpose. But other times you sometimes don't want to show that you don't quite know what they're talking about. Or perhaps you feel you've asked enough questions, so you want to see what you can learn on your own first. But if its important you know what that term means at the time its being discussed, then by all means don't be afraid to ask :) — Dec 19 '12 at 16:59
@Rachel - I can't speak for others, but I personally have more respect for someone that acknowledges that they don't know something than someone who acts like they do, only to find out that we're not on the same page in a discussion. IMO, if you're up front about not being very knowledgeable, that gives me the ability to use words you're more likely to understand, and more receptive to even rudimentary questions that you might have. — Dec 19 '12 at 18:24
@Shauna Thanks. I wasn't trying to imply you should pretend you know what's going on when you actually don't, but there are times when you hear a term and it's not imperative that you know what the term means, so its fine to remain silent and just look up the term later. If you were actually expected to discuss something you didn't understand, and make decisions based on it, that's a different story and you should definitely speak up to clarify things before continuing in that case. — Dec 19 '12 at 18:35

GuyM 8,4332743 · Answer 5 · 2012-12-19 21:59:01Z

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.

Thanks for this answer. What platform do you use for the in-house wiki, just out of curiosity? I like that idea. — Dec 19 '12 at 22:28
Good question; its now actually something IT set up corporately called MindTouch (but I had to check) - it was part of our e-mail reduction campaign (but that's a different story...) — Dec 20 '12 at 0:39

Akira71 58956 · Answer 6 · 2012-12-19 15:50:17Z

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

Head First Design Patterns - Great for learning basics of Design Patterns which developers use all the time

Head First Software Development - Start here for a great overview of the software development process and lingo

Head First Programming - This is a learners guide and uses Python but it is a great place to start as well

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.

As much as I love O'Reilly's books, I suggest avoiding the Head First series. I've found that they rarely present a decent discussion of a topic. They are incredibly gimmicky and I don't think they'll help that much if you want to have serious technical discussions with professional software developers. — Dec 19 '12 at 16:02
@ThomasOwens I can see that, but I have found them to be invaluable with people who are just trying to understand what to say and the culture just a bit. Sure for serious understanding they are a launchpad only, but for a beginner that wants an overview I find them helpful. I am actually quite pleased that Zak833 wants to learn and understand more when working with other developers. — Dec 19 '12 at 17:08
I'm somewhat in agreement with @Thomas Owens here, having had a bit of experience with Head First books. That said, I am a total newbie, so I may well have a look at the first two you suggested. Thanks! — Dec 19 '12 at 22:14

swapnesh 1,2841928 · Answer 7 · 2012-12-19 16:00:37Z

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.

score 0 · Answer 8 · 2012-12-19 19:01:23Z

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.

JB King 15.1k22957 · Answer 9 · 2012-12-19 19:05:30Z

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.

Dancrumb 1,211816 · Answer 10 · 2012-12-19 23:32:28Z

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!

calum_b 1653 · Answer 11 · 2012-12-20 19:51:45Z

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.

Hi Scottishwildcat, welcome to the Workplace SE, the site for questions about navigating the professional workplace. Because our audience is potentially so large, we generally expect answers to address the entire question and provide a self-contained answer. This may explain the downvotes. It sounds like you have some valuable experience from these books, so my suggestion is to edit the post and highlight the key points from the books so that, even if people don't read the book, your answer is still valuable. Good luck! :) — Dec 22 '12 at 3:59

Lolcat 1 · Answer 12 · 2012-12-20 10:39:19Z

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.

this explains the problem from your perspective, but doesn't really answer the OPs question. Can you add some suggestions as to what the OP can do to improve communications? — Dec 20 '12 at 19:59

Communityâ™¦ 1 · Accepted Answer · 2017-04-13 12:48:42Z

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.}

Ordering Facts and Fallacies... Thank you.
â€“Â zakgottlieb
Dec 19 '12 at 22:23 — Dec 19 '12 at 22:23

Monica Cellioâ™¦ 43.7k17114191 · Answer 14 · 2012-12-19 16:04:17Z

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.

In this case, I don't think he has any good recs - but it's sound advice nonetheless. — Dec 19 '12 at 22:20

bethlakshmi 70.4k4136277 · Answer 15 · 2012-12-19 21:37:59Z

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.

Great answer, thank you @bethlakshmi. I might try to do some screen-sharing with my programmer at some point. — Dec 19 '12 at 22:15

Communityâ™¦ 1 · Answer 16 · 2017-04-13 12:48:42Z

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.

Instead of writing down terms you don't understand and then googling them later, why not ask right then, "What does X mean?" — Dec 19 '12 at 16:54
@Fernando There are many reasons you may not want to do that. The most common reason for me is not wanting to interrupt the flow of the meeting, particularly if the term isn't that important and could steer the meeting away from its primary purpose. But other times you sometimes don't want to show that you don't quite know what they're talking about. Or perhaps you feel you've asked enough questions, so you want to see what you can learn on your own first. But if its important you know what that term means at the time its being discussed, then by all means don't be afraid to ask :) — Dec 19 '12 at 16:59
@Rachel - I can't speak for others, but I personally have more respect for someone that acknowledges that they don't know something than someone who acts like they do, only to find out that we're not on the same page in a discussion. IMO, if you're up front about not being very knowledgeable, that gives me the ability to use words you're more likely to understand, and more receptive to even rudimentary questions that you might have. — Dec 19 '12 at 18:24
@Shauna Thanks. I wasn't trying to imply you should pretend you know what's going on when you actually don't, but there are times when you hear a term and it's not imperative that you know what the term means, so its fine to remain silent and just look up the term later. If you were actually expected to discuss something you didn't understand, and make decisions based on it, that's a different story and you should definitely speak up to clarify things before continuing in that case. — Dec 19 '12 at 18:35

GuyM 8,4332743 · Answer 17 · 2012-12-19 21:59:01Z

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.

Thanks for this answer. What platform do you use for the in-house wiki, just out of curiosity? I like that idea. — Dec 19 '12 at 22:28
Good question; its now actually something IT set up corporately called MindTouch (but I had to check) - it was part of our e-mail reduction campaign (but that's a different story...) — Dec 20 '12 at 0:39

Akira71 58956 · Answer 18 · 2012-12-19 15:50:17Z

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

Head First Design Patterns - Great for learning basics of Design Patterns which developers use all the time

Head First Software Development - Start here for a great overview of the software development process and lingo

Head First Programming - This is a learners guide and uses Python but it is a great place to start as well

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.

As much as I love O'Reilly's books, I suggest avoiding the Head First series. I've found that they rarely present a decent discussion of a topic. They are incredibly gimmicky and I don't think they'll help that much if you want to have serious technical discussions with professional software developers. — Dec 19 '12 at 16:02
@ThomasOwens I can see that, but I have found them to be invaluable with people who are just trying to understand what to say and the culture just a bit. Sure for serious understanding they are a launchpad only, but for a beginner that wants an overview I find them helpful. I am actually quite pleased that Zak833 wants to learn and understand more when working with other developers. — Dec 19 '12 at 17:08
I'm somewhat in agreement with @Thomas Owens here, having had a bit of experience with Head First books. That said, I am a total newbie, so I may well have a look at the first two you suggested. Thanks! — Dec 19 '12 at 22:14

swapnesh 1,2841928 · Answer 19 · 2012-12-19 16:00:37Z

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.

score 0 · Answer 20 · 2012-12-19 19:01:23Z

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.

JB King 15.1k22957 · Answer 21 · 2012-12-19 19:05:30Z

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.

Dancrumb 1,211816 · Answer 22 · 2012-12-19 23:32:28Z

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!

calum_b 1653 · Answer 23 · 2012-12-20 19:51:45Z

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.

Hi Scottishwildcat, welcome to the Workplace SE, the site for questions about navigating the professional workplace. Because our audience is potentially so large, we generally expect answers to address the entire question and provide a self-contained answer. This may explain the downvotes. It sounds like you have some valuable experience from these books, so my suggestion is to edit the post and highlight the key points from the books so that, even if people don't read the book, your answer is still valuable. Good luck! :) — Dec 22 '12 at 3:59

Lolcat 1 · Answer 24 · 2012-12-20 10:39:19Z

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.

this explains the problem from your perspective, but doesn't really answer the OPs question. Can you add some suggestions as to what the OP can do to improve communications? — Dec 20 '12 at 19:59

Search This Blog

Iyfjky

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

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

12 Answers
12

Your Answer

Post as a guest

12 Answers
12

12 Answers
12

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

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

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

migrated from programmers.stackexchange.com Dec 19 '12 at 15:40

12 Answers 12

Your Answer

Sign up or log in

Post as a guest

Post as a guest

12 Answers 12

12 Answers 12

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

12 Answers
12

12 Answers
12

12 Answers
12