Related
I have recently completed my bachelor's degree in Computer Engineer. I have had one small internship till now.
I have little coding experience.
After searching for months (Does not mean I am desperate for the job-Just wanted to clarify so that your answer is not based on it), I have been offered a job at a start-up to design and develop their web application for user interaction and management. I am the sole technical hire and will be the only person responsible for the development of the platform. The founders, though highly educated, do not have any sort of technical background.
It seems like an interesting opportunity but I am wondering if it too much responsibility too early?
I know this is not a standard programming question but I think this is a programming ability understanding type of question.
I would highly value your insight on this subject.
Thank you.
Just looked at your LinkedIn profile. Looks like you have great entry-level programmer qualifications.
Being the sole technical member of the team, with limited industry experience may be a great opportunity for growth.
However, the flip side argument is that you may be losing out on opportunities to grow with adequate mentorship. In all reality, the college/university CS/CE curriculum does not typically prepare you to handle real-world problems that senior-level software engineers address daily. In a company where you are NOT the sole technical staff member, you will have the opportunity to collaborate with and learn from experienced pros. In my opinion, that is a huge factor in selecting your first job.
So ... assuming this startup grows quickly ... are you qualified to:
Make day-to-day technical decisions regarding scaling, security, and prioritization of product features?
Interview, hire and evaluate the performance of additional technical personnel?
Develop the full-stack of a web application including setting up and administering server, database, APIs and associated frameworks, client side technologies?
If you are uncomfortable with any of the above (which is a very limited set of questions) you probably aren't yet ready. It takes a long time before any of us are. Before I took my first leadership position in a startup, I had over 10 years of experience in multiple industries and with several technologies. But that's me ... you have to make this decision for yourself.
Depends on the type of the company. If there's going to be interaction between the users and the site a lot and it just doesn't serve the purpose of providing information, then you'll have to handle things on the server side as well to provide proper response and you need to be quite good with your stack and as a fresher, it isn't quite recommended to be a sole performer in the technical section of an entire firm.
Since you tell, web application, I assume the user does have to interact. I wouldn't go for it if I were you. But you haven't told about the level of expertise you possess in your skill set. So, can't say whether or not you'll be able to handle it.
and this is just my opinion btw.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm currently learning to program, and I didn't take CS classes so I'm basically starting out on the bottom. I have been putting together code on and off for many years, but haven't really had a good understanding of essential concepts needed for enganging in bigger projects. Object-orientation is an obvious one, and I feel I'm beginning to understand some of the concepts there. Then there is a lot of buzz and methodology, such as MVC, UML, SCRUM, SOLID and so foth and so on.. I've looked at many of these but I'm always stumped as most explanations seem to require some understanding of other concepts.
I want to learn this stuff the "right" way, so where do I begin?
What are the overarching constructs I need to understand that enable me to understand all the underpinnings of software architecture/design/development?
What am I missing?
Are there constructs and concepts that can and should wait until I've cleared the foundation?
The SOLID principles are probably the most important.
From those you understand the motivation behind using a pattern such as MVC, why people think of persistence ignorance as important and so on. They are at the core of the majority of good practices.
Loose coupling, high cohesion.
And as for books, Code Complete covers almost everything at some level, at least.
Software development is a HUGE arena and you should be careful that you don't take on too much too quickly. Unless you're going to go in the direction of functional programming I'd suggest you start off by making sure you fully understand the concepts surrounding OO design and programming as this should be your foundation.
Once you understand that well you'll be able to understand design patterns a lot better and get a feeling for when to use them.
I'd suggest you try out a few languages till you find one you feel comfortable with, personally my favourite language is Ada which is a very pure OO language but in the business world I work in C# which still has a lot of issues but these are outweighed by the more vibrant job market.
I wouldn't worry too much about Scrum at this stage as you need to focus more on your dev skills before worrying about project management.
The most important thing is to work with as much code as possible, download lots of good reference solutions and work through the code till you understand it, and try and keep an eye on the development trends.
If its viable you may also want to considering attending some developer conferences too as these can be very inspirational.
Stay away from ACRONYMS (including those you've listed) and Methodologies(tm). At least in the beginning.
Read good books. Start with this one: Pragmatic Programmer. Learn algorithms and data structures, possibly from Introduction to algorithms by Cormen et al.
Write a lot of code. Practice is more important than anything else.
How to test software with unit tests. Being able to do that will solve 90% of all the other issue automatically since you can't test while they are around.
When you know how to test, you can start on advanced topics like design.
I'd recommend "Object Oriented Analysis and Design with Applications" by Grady Booch et al. The latest editoin has detailed explanation of concepts of OOAD including MVC, UML (which he invented), and discussions on how to manage the whole process of software development. The second part of the book exemplifies all this by developing 5 sample systems (with sometimes orthogonal aspects from the very core).
Another good one is of course Design Patterns by GoF which will give you an idea of loose coupling, ways to efficient encapsulation and reuse of code, etc
For what concerns the algorithmic part, take any book which is not bounded to a particular programming language. My favorite is Introduction to Algorithms by T. H. Cormen et al, it gets a bit theoretical at some points, but I especially like it when they are proving certain things and not just asking you to believe it.
When you are working with any modern general purpose language, it is probably a good idea to get a handle on patterns (MVC or Model-View-Controller is one). The book by the "gang of four" is a must read for this, or at least research a few and use it as a reference.
clicky
Refactoring is another concept that should be in your arsenal. The book by Martin Fowler on this subject is a very nice read and helps understand the aforementioned patterns better also a little explanation about UML is included.
Can't post more than one hyperlink so...
search on amazon for: Refactoring, Improving the design of existing code
When you want to communicate your designs UML (Unified Modelling Language) is the 'tool' of choice for many people. However UML is large and unwieldy but Martin Fowler (again) has managed to boil it down to the essentials.
search on amazon for: UML Distilled (make sure you get the most recent one)
SCRUM is one of many methods that is used to manage software development groups, I do not think there is much merit in learning that when you are just starting out or on your own. Especially not in detail.
Hope it helps...
PS: SOLID I haven't heard about yet, somebody else has to help you there.
You'd have a decent foundation if you surveyed basic Data Structures, Algorithms, and Algorithms Analysis.
I think that you should start coding real world problems to get a feel for problems in the programming domain.
Then you have a better background to understand why objects are important. Then, after managing objects, you will learn why patterns and OO principles are important.
Personally, I highly recommend the Agile Software Development, by Robert C Martin.
But it may be a long and tiresome read unless you have a feel for the problems being solved. I'm afraid that you may need 500-1000 hours of coding at the minimum before you get an appreciation that the problems being solved are real.
And it probably takes 7000+ hours before you develop an instinctive heart-felt pain from merely reading the problems, making this sort of book become the page-turner that it should be.
Regrettably, many of the sound practices that you should develop are only appreciated after having to live with your code over time. If you just do many excercises and abandon the code afterwards just "because it works", then you are missing out on the greatest pain of all. It is a luxury our industry does not have, and "technical debt" is a very very real and costly to those with large code bases.
I feel kinda silly answering my own question like this.. :) But one valuable resource I've found for learning to write code, is the Euler Project at http://www.projecteuler.net
It's basically a collection of mathmatical problems that you solve by writing your own solution to it. Once you've found the answer to a particular problem, you're allowed access to that problem's forum where different solutions are discussed. I was amazed at how much I was learning in a) solving a challenge, b) reading about other peoples approaches and c) how many programming languages there are out there! :)
The problems start out easy (you can tell by the number of people who's solved them) and progress to harder and harder problems.
Currently I'm working on problem #3, having solved the previous two... I recommend you start chippin' away at them, no matter your level!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Do you find that corporate buzzwords or heavy management jargon gets in the way of software project communication? for example using words such as
Mainstreaming
Holistic
Contestability
Synergies
etc.
Would you rather see a initiative within the industry to put a stop to jargon such as this to help people communicate better and keep project communication in plain English? Is it even a problem? What are your thoughts/anecdotes?
I actually like buzzwords, when they are used in moderation.
They became buzzwords for a practical reason: Even though the concepts may be very complex and/or abstract, there is a consensus on the meaning. So with only one word, you can convey a whole lot of information to a large group of people. I see it as a form of encapsulation of information.
(Notice the use of the slightly outdated buzzword encapsulation?)
Of course, that is exactly the reason why many people start to abuse them: They only convey the general concept (i.e. why it's great to do FizzBuzz), and avoid discussing the messy details (i.e. why it won't work).
And since using a buzzword gives the impression that you are deeply familiar with the subject at hand, it can be used to silence others in the discussion.
Conclusion:
Buzzwords are ok - if they are used in the right way. If you want to improve your team communication, train them in the proper use of buzzwords.
I think some kind of industry-wide initiative would be impractical as jargon is in the eye of the beholder.
I think all you can do is make sure that you don't use buzzwords yourself even when communicating with people who do. For example, use the word "people" when talking to a Project Manager who refers to you and your colleagues as "resources".
The use of technical language can both help and hinder project team's progress, depending on appropriateness.
First it's necessary to point out that what is considered "too technical" depends purely on perspective. "Mainstreaming" is as much of a technical term, as SSD, CORBA and SOAP. Something that sounds as jargon nonsense to one person is actually a shortcut to communicate a complex concept for another.
Software development as a rule is cross-domain activity involving in addition to the software knowledge one or more technical user domains. It is a big mistake to assume that sales, marketing, management and banking (just to name a few fields often incorrectly considered "non-technical") haven’t developed and advanced their own complex body of knowledge, in other word — technology: sales technology, marketing technology, management technology and banking technology.
And it’s project manager’s responsibility to facilitate productive communication between representatives of different technical domains. Some suggestions:
Make handy a project dictionary that can be accessed and updated by everyone involved.
Ensure that common denominator language used for cross-domain documentation (i.e. functional specs).
Introduce domain specific terms only when necessary, but then always provide a brief explanation of the meaning (don’t “build from scratch” —leverage the wealth of online encyclopaedias by linking where possible).
Make sure that there is common understanding amongst the project team of the key terms.
Remember that what is considered “technical” depends purely on perspective and you need to facilitate communication in all directions, not just one-way (which is often from software developers to business users).
At the end the software will have to work in the realm of users and you have to make a judgement on how much the UI will rely on specific domain language (this is going to be a trade off between easiness-to-learn and usage-efficiency).
Technical jargon (ORM, TDD etc.) makes one's speech more precise. Corporate buzzwords (aka management jargon), on the other hand, are designed to be able to express vague ideas when full information is not available.
As such, management jargon serves its purpose pretty well, in the sense that it does allow managers to effectively communicate about thins they have very limited understanding of. That said, good manager knows when NOT use the jargon, such as when talking with developers, or with executives, both of whom hate bullshit.
Based on the above, the (Anti-)Buzzword Movement, should rather increase awareness of the proper usage and application of management jargon, and encourage proper information encapsulation only with appropriate auditory.
Personally, I think that the jargon should be used more. I see this occurring more and more and IT people want to simply hide behind the technical elements of the world and act like it is completely the business folks responsibility to speak more geeky.
I'll be honest, speaking more GEEK is not something that the business people can do and you should not want that to occur. Learn the jargon. Become one with the jargon. Own the jargon. Then the next time you are discussing things, you'll not be back pedaling.
Take ownership of the business terms and apply them to the technical side of things...
What's wrong with "holistic" or "synergy"? These are normal plain English words.
Every field has it's own jargon, and that must tell us something - people like having special words, phrases or assigning special meanings to existing words that are only relevant within their own field. I suspect if we went back to the pyramids, there'd be a full set of architectural and building phrases that your average Egyptian just wouldn't understand. So banning jargon just wont work, creating an FAQ and glossary normally do the trick.
BTW This must be a case of pots and kettles. Does anyone outside IT think phrases like - "...We'll use an ORM, and then WCF will talk over HTTPS, throw in a bit of AJAX and some clever CSS on the client and we're laughing ..."
Absolutely. Since managers only talk in general, and we as developers want to understand the precise meaning. I personally fall asleep trying to read abstract writing filled with buzzwords.
The worst being SOA. Neither academic folks nor managers understand it though both use it extensively.
I can't stand buzzwords. One person's "encapsulation" is another's Orwellian destruction of language. Buzwords appeal to the same people who like "decks" rather than memos. For something to act as a representation of many possible things [e.g. "leveraging resources" can mean pretty well anything from using double-sided printing options to drafting people for the Army] there is necessarily going to be a dilution of meaning. If a senior lawyer in my firm were to ask me to "leverage the resources, then run it up the flagpole to get the ducks in line", I'd know that he was tossing back the Johnny Walker at lunch.
Conversely, if I were to respond to a senior partner's memo request with emtpy catch phrases such as those above, I'd be fired on the spot for being an idiot - and rightly so. Too bad the rest of the white collar world isn't like that.
Grouchy Old-fashioned Gen X'r
I'm OK with buzzwords so long as all the stakeholders (see what I did there?) are clear on the shared meaning of each word/phrase.
In general I think that buzzwords are good when used for encapsulating ideas and concepts. it simplifies communication between people who understand the words. However, I draw the line when people use a buzzword when a perfectly normal word would do. I know someone that will say they were "On an Audio" when they mean phone calls or say "dialogging" instead of talking. It makes me want to hit them. Hard!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Our company has been thinking about scrapping our interview procedures and bringing each candidate in for a 4-5 hours sit-down with some of the programmers and just do some pair programming.
I like the idea in theory but I am not sure how you can really make it fair for each candidate. How would you rate them? Wouldn't their input really depend on what each programmer was working on that day?
Any thoughts on whether this is a good idea/bad idea or how to make it work is what I am kind of looking for here.
Cheers!
EDIT:
RESULT - AS requested
We are going to conduct the first steps of the interview the same as before. Phone followed by face to face. Instead of bringing them back for a third and final grilling, we are going to bring 3 developers back to sit with all 7 members of the team. We have decided to let the team decide who is then hired.
We have come to this conclusion for a couple of reasons. We believe this will empower the developers by giving them a choice who they are working. The second reason is group dynamic. We think it is really important to have a good group dynamic and it is hard to tell until after you hire a person if they will fit in or not.
So the end result is we are going to go ahead with the pair programming sessions but in a completely different way and for a completely different way than was originally intended.
Any thoughts or criticism of this approach is more than welcome!!
(this edit is posted as an answer below so feel free to downvote if you feel this is not the best approach)
Unless you use pair programming extensively in your real-world development, I'd be very hesitant to use this. I've met any number of high-quality professional developers who have mentioned a strong aversion to pair programming and whose skill would not be well-judged in such a process.
I hope you have a bunch of steps ahead of this one. For this to work you need an excellent resume and phone screen. You don't want to spend oodles of time on candidates that you shouldn't be talking to in the first place.
So you suggest an initial interview
and possibly have the second interview
as the pair programming session? – Ted
Smith (1 min ago)
Yeah. You might even think of having a simple coding interview happen over the web using something like CoPilot.
The easiest way is to give each person the same programmer to work with and the exact same piece of code.
The problem you're going to run into, is that hiring isn't like programming. There isn't a step by step process to lead to the right answer as to who to hire. (you can have multiple steps to make the decision easier). You have to evaluate each one on their strengths etc. and essentially make an educated guess as to which is the best one to hire. Sometimes you guess wrong.
The other thing about pair programming you're going to have to watch out for is the amount of time necessary to have each candidate at that stage go through that kind of a test. If I were looking for a job, I would be hesitant to go an interview at a company that would ask me to do that. Why? Because that is a lot of time, and if I am interviewing at multiple places, I could spend literally days just going to interviews for jobs I may not even get or want. Someplaces like Google or MS would be an exception, but most places are not like those two. (Not to mention the fact that if they are working on real code, you are essentially asking them to do someone's job for free).
As a personal anecdote, I got smacked around in an interview because of a technique like this. I had gone far in their interview process; passed the resume checks, the code submission and this was the face to face portion of the interview.
I was fresh out of university and had never pair programmed before nor done TDD. They sat me down to do a deck of card exercise and it flopped. Badly! I didn't understand why the interviewer was writing tests that seemed so dumb* (IE "return null;") and they didn't explain why and of course being foreign to TDD I didn't know what questions to ask. The end result was that it looked like I couldn't program my way out of a paper bag.
If you're going to do this type of exercise you need to cater to the interviewee because they're going to be in different spots with their aptitude. This means that you'll get different assessments that may not be based on actual talent and are thus going to be heavily biased.
**Now that I understand TDD, I do understand tests like this and how it's supposed to work, but man did that ever seem stupid at the time!*
I just had an interview with a San Francisco based company that prides itself on Agile methods/etc. I was to interview the CEO himself. I have about 20 years of experience in the industry, but have never pair programmed or developed using TDD approach. I was told it would be a "programming interview" but had not idea what to expect, and before we started the guy said that he thought that I may agree that all interviews should be done this way. (which in retrospect was nothing more than an arrogant statement).
Anyway, at the interview the exercise was to develop a class using TDD. It took me a second to adjust my thinking on the entire process, again since I had never pair programmed or done TDD. While I stumbled here and there I did ok in the end. but his reply was the I did not exhibit the aggressive back-and-forth nature that they require for their pair programming environment. Now, that could also have been an underhanded way of saying that "I didn't think you did great" kind of message.
Luckily I didn't need the job and to be honest the experience made me realize that I'd rather find a different career than having to be a software engineer that HAS to work in pairs, day in day out, when it came to developing code. Odd thing is that on occasion I have worked with another person on code simultaneously, so anything is possible.
In end I guess it was a good outcome since they didn't think I was a good fit and I didn't care for their working methods. But we would have came to the same conclusion had I talked a for a few minutes more about myself and had he given me a little more info on how they go about their work. Which is to say that there are other ways of finding a good fit candidate than putting them through the stress of pair programming with a complete stranger; bogus way to gauge competency imo.
One particular company uses a technique called extreme interviewing. For the extreme interview they will bring in say 30 developers and group them into 15 pairs. They will explain that they are looking for people who work well with others. That they will make a hiring decision based solely on their ability to work with others.
They will provide a problem for the pairs to solve. They will emphasis that they are not interested in the solution just each programmers ability to work with others. For each pair they will provide an observer of the pair. During the exercise (about 2 to 4 hours in duration), the observer will takes notes about a person ability to pair ... not the solution.
They are amazed how many programmers focus on solving the problem instead of collaborating. Of the 15 pairs, they will identify about 4 to 6 developers for a second interview. Those developers will be asked to come back and spend a week with the team (they get paid). After a week, they decide who to keep. Generally about half of them (2 to 3 developers).
When they are done, they have developers that are able to collaborate and after a week working with various pairs, the team has a strong indication who can effectively develop software. The process is both innovative and effective. They have had a high success rate with those they have hired.
I just had a pair programming interview a few days ago and to be honest, I don't really like it. I was notified of this a day just before the interview and then the interviewer told me that pair programming is what eventually I am going to do anyway in work. I went into the office and was paired up with someone who is a very senior software engineer. The company is in San Francisco and they are a well renowned company for pair programming, everyone pair programs in the office. At first it seemed to be fine, he explained about all the tools they used, their own unit testing framework that they build, and a bit of the project. He then basically wrote a bunch of unit tests and wanted me to work on the implementation to make it pass. Just as an FYI, the code base that already exists is huge, I would say 10k lines, it's not like a super complex project, but it is complex for someone to just step in and then write code without prior understanding of the class hierarchy etc. I find it really hard to believe that he expects someone to jump right away in a 10k line of source code that already exists. It just doesn't match for a pair programming interview, a smaller code base would help. I struggled a bit from navigating through the classes and going back and forth because I can't remember class names as I was overwhelmed by the amount of classes/code that already exists. To be honest, this really made me do horrible in the interview process. In the end I didn't feel really good about it. I haven't done pair programming before, mostly is just during assignments in my college year.
To me the power of pair programming can be harnessed if you're already proficient/comfortable with your pair, but is not really suitable for interview. Sometimes I would like to ask questions to my pair, but then I thought if I ask too much questions, then they would assume I were stupid and can't perform. If this was already on a real job, I wouldn't hesitate to ask, but in an interview it's hard.. you want to ask because your pair should help you out when you're stuck, but at the same time it's an interview, so you can't really ask much.
That is just my experience that I have from pair programming interview, my suggestion if you really want to do this:
be sure that you don't give the candidate to work with a large code base, work with a
smaller one and therefore he/she can show his/her skills to the max
be up front with the candidate before pair programming interview, can you ask questions
when you're stuck, should you be able to do this and that, what can't you do
be as detailed as possible
In the end, I wouldn't suggest it. It's hard to measure a candidate's performance in pair programming, and it might be biased as well.
I like this idea. However I think it might be difficult to do since it would require the candidate to have some knowledge of the project you would pair on with him. Also, 4 to 5 hours seems a bit long. What if you immediately see that it is not going to work out, are you going to sit through the whole session with the candidate?
Good question though. Stuff to think about.
Why not? Also, it's not like interviews are always (or ever) fair. You should evaluate the end results of the new approach against the traditional interview-based approach.
Also, a mini interview before the pair programming session might be good to keep from wasting the programmers' time with people who would be a bad fit.
From my limited experience, my feelings are mixed. I like the idea of pairing as part of an interview, esp. if the company uses pairing often, because it gives both a better feel for the fit. As a candidate, I've often gone through interviews where I sat in a room answering questions for a few hours, but afterward didn't have a good feel for what it would really be like to work in their environment. Pairing may be more beneficial than a random coding exercise, unless the interviewer is skilled at working someone through those. And I like being able to discuss technical stuff from both sides. And as a candidate, I'd rather interact with someone than just answer questions or solve code problems on my own.
But... as others have noted, the time needed can be an issue. I've gone through a couple days of pairing interviews and found some periods good, while others felt like a few hours were wasted: one because the developer wasn't working on something that lent itself to pairing (esp. given my background), the other because an env issue prevented much useful work for a while. If the job doesn't work out, it can be frustrating to have taken a day or two off work for this.
One place trying this approach wasn't sure if they should have someone outside the company working on a customer's project. They also worried that explaining the domain and work being done would take too long, though without that the candidate may not be able to contribute much. So they chose an open source project the employee was working on.
This seems to be a key point: there needs to be a well chosen task that the candidate can understand quickly and be able to contribute to. The latter part will depend somewhat on the candidate's skills. Also key would be the employee's ability to evaluate someone with this approach. Not everyone is great at normal interviewing, and that's probably more true of a pairing interview.
Also, if a company doesn't do much pairing then this kind of interview may not be as useful. There does seem benefit in seeing someone code (as Joel Spolsky notes), and this could be a good way to do that. But if pairing is not a typical part of the job, then perhaps a full pairing session isn't appropriate. Maybe a modified version.
I'd be curious what companies who have taken this approach think of the results. Reading some of the other answers to this question shows that it doesn't always seem ideal from the candidate's view.
To keep it fair, you'd have to make every participating staff member have a prepared problem to evaluate the candidate on. Preferably something taken form the real world in their company experience, but something that has already been resolved. This is a good chance to evaluate the knowledge on a problem and evaluate not just programming skills.
I hate it when too specific questions are answered. I had an interview once where a programmer was testing my knowledge of the STL which I used extensively and was trying to get me to answer that a custom allocator was needed. I had heard of them but never used them (esp in windows) and was made to feel dumb. IOW, avoid being judgmental.
So my point is, ask practical questions that aren't so much about testing programming knowledge as you can evaluate more qualitative personality and problem-solving approaches if you use the "pair programming" idea.
Good question!
Honestly, that sounds like a great idea, though Jason Punyon is certainly right that you should do a lot of weeding before you waste significant amounts of your developers' time on culls. You get a glimpse at an important metric out of it that's otherwise nearly unobtainable in interviewing: what someone's like to work with.
I don't think there's really any need to be concerned about it being "fair" based on the subject matter or trying to present consistent situations to different candidates, if you maintain the right evaluatory attitude -- that it isn't about whether they "got the right answer" or jumped through the right set of hoops, but what sort of effort, problem-solving, communication aptitude and flexibility they showed. You'd lose most of the benefit of the exercise by turning it into an artificial test, not to mention changing it from something that your developers can get some benefit from (or at least still get some work done during) to a massive waste of their time.
Joel Spolsky has an excellent Guerrilla Guide to Interviewing which talks about, amongst other things, programming tasks.
Trivia: Joel Spolsky is a co-founder of stackoverflow.com
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I have a challenge I need some input on.
I am currently recruiting programmers for a new development department. I am looking for people that are brilliant at their work – so brilliant that they might “lack” some other things that I normally would require them to have (e.g. speaking Norwegian and (to be honest) – social skills in order to be able to meet the customer (I’ve worked with several of them before :) )).
My issue is in regards to communication between the client (customer) and the development team.
Background: We have a strategy of becoming our customers extended development department over the next two years. E.g. they consider us as their own department just sitting somewhere else. While we are on our way towards this target, we will have to make money on smaller projects. The work is there, so I am not afraid that we will not manage to stay alive.
But – we all know that good communication with the customer is one of the key elements on providing the customer with what they actually want (we are scrumming by the way) instead of something else. How do I manage to do this with people that do not speak the language, or again, does not even have the skills to communicate with the customer (you all know someone very bright that is going into deep technical issues with a customer that hardly knows the difference between Firefox & Opera)?
I have landed on a solution where I will be the interface towards the customer, the customer will join in on planning sessions, etc., and where the team will still do the demo. But in regards to continuous communication (daily) between the dev team and the customer, I will be the one doing the comms.
I know that this is not the optimal solution – being a middle man a lot of information can disappear between the customer, me and the team. Have anyone been in a similar situation?
Create a wiki. Create a page for your customer which contains pictures, business information, things to look out for, etc.
Have everyone contribute to the wiki, including the customer.
As time goes on, this page (or pages if you split the information on numerous pages) will allow
new developers to understand the customer faster
see the possible problems that may arise
your developers would contribute to the wiki since they have a tangible documentation where everyone can see how much they have contributed to the customer.
make the customer feel as if he is part of the development process
since the wiki is, by effect, a collaboration document, a common language will appear between everyone. It might not be the same as speaking your customer's language, but it will be a combination of your customer's and developer's language.
We've had a somewhat similar situation when we did "Beta programs" for select customers. When the customers had questions, they could only turn to the developers at that stage of the project because e.g. the helpdesk was not yet familiar with the new features.
We also used a "middle man" for doingt the communication with the customer and then passing it on to the developers, and this has worked quite well for us. What were the advantages? The customer alsways knew exactly whom to contact, the communication was consistent, some on the simpler questions could be answered without the need to "bug" the development team at all while some more difficult questions could be "boiled down" from a superfluous explanation to the real problem before handing the question over to the developers, both giving the developers more time to concentrate on what they do best.
Of course, if you want this to work, you'll have to make sure you pass on information between development and the customer in a timely manner, but I think it can be worth the effort (and in fact, our developers prefer it that way).
Communication skills are arguably more important than technical skills. A programmer that doesn't communicate well may well cause enough disruption to negate what they bring to the table technically.
Having said that, you still have to realize that not everyone is the best person to be "customer facing". You might designate one or more members of the team as liasons to your customers, and have the communication go through them when possible.
The developers should be shielded from the customers. Developers are usually hardcore technical people who eat C++ templates at breakfast. The customers are often very non-technical. A customer asking a badly formulated question on some trivial issue to the developer usually irritates the developer a lot causing at least a temporary loss of productivity. So it's better to have special paid people that work in between.
Don't underestimate the value of being in the same place. If communication skills are lacking, being able to point and say "look at this" can be far quicker and more effective than trying to explain everything in a meeting or email. But from "they consider us as their own department just sitting somewhere else" this doesn't sound like it is an option for you.
Generally I expect that at least some of your developers will be open to learning proper communication with the customer. Involve those developers with the communication (even if it's painful at first). English is a pretty universal language and your customer will probably be able and willing to speak it.
Shield the developers that DON'T want to communicate or learn to communicate with the customers. They may damage your relationship with the customer and you will damage your relationship with your employee.
Be careful about allowing written contact between the customer and your developers. Written communication often gets interpreted wrong, especially when written by people who do not have much experience writing carefully balanced e-mails, memos or letters.
As you build your relationship with your customer, you'll get to know eachother's personalities, and communication will be smoother.