Related
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 3 years ago.
Improve this question
I lead a small group of programmers in a university setting, having just moved into this position last year. While the majority of our team are full time employees, we have a couple of people who are traditionally graduate assistants.
The competition for these assistantships is fairly intense, as they get free graduate school tuition on top of their salary while they have the job. We require that they sign up for at least a year, though we consider ourselves lucky if they stay for two. After that, they get their master's degree and move on to bigger and better things.
As you can imagine, hiring and re-training these positions is time- and resource-intensive. To make matters worse, up to now they have typically been the sole developer working on their respective projects, with me acting in an advisory and supervisory role, so wrangling the projects themselves to fight the entropy as we switch from developer to developer is a task unto itself.
I'm tempted to bring up to the administrators the possibility of hiring a full- (and long-haul) developer to replace these two positions, but for a school in a budget crisis, paying for two half-time graduate assistants is far cheaper (in terms of salary and benefits) than paying for one full-time developer. Also, since I'm new to this position, I'd like to avoid seeming as though I'm not able to deal with what I signed up for. For the forseeable future, I don't think the practice of hiring short-term graduate assistants is going to change.
My question: What can I do to create an effective training program considering that the employees may be gone after as little as a year on the job?
How much time should I invest in training them, and how much would simply be a waste of time?
How much time should they take simply getting acclamated to our process and the project?
Are there any specific training practices or techniques that can help with this kind of situation?
Has anyone dealt with a similar situation before?
Do I worry too much, or not enough?
By the way, and for the record, we do the vast majority of our development in Perl. It's hard to find grad students who know Perl, while on the other hand everybody seems to have at least an academic understanding of Java. Hence this question which I asked a while back.
Why don't you ask the students what they find difficult and make cheat sheets, lectures, etc. for the parts of the job that they have trouble with? Maybe you need to create some introductory Perl lectures or purchase some dead trees. How about a Safari subscription at O'Reilly? I'd ask the students how they prefer to learn, though, before embarking on a training project. Everyone has different learning styles.
I'd also spend some time and capital creating a culture of professional software development at work. It'll be tough since academic programmers are often neophytes and used to kludging up solutions (I'm an academic programmer, btw) but the students will thank you in the long run. Maybe you can all go out to lunch once a week to discuss programming and other topics. You might also want to take some time to do code reviews so people can learn from each other.
With high turnover you definitely need to ensure that knowledge transfer occurs. Make sure you are using source code control and that your students understand proper commenting. I'd also make the students create brief documentation for posterity. If they are getting credit, make them turn in a writeup of their progress once a semester. You can put this in a directory in the project's repository for anyone who inherits it. As mentioned in other posts, a group wiki can really help with knowledge transfer. We use Mediawiki in our group and like it a lot.
One last thing I should add is that I find it helps to keep a list of projects for new developers that relatively easy and can be completed in a month or so. They are a great way for new people to get acclimated to your development environment.
This is a relative question, and should be taken on a case-by-case basis. If the new hire already knows Perl, you don't need to go over this piece of training (yes, you could put Perl as a mandatory prerequisite, but that would significantly limit your applicant pool), and their first bit of training should be something like fixing a bug in an existing application or walking them through an application they will maintain. Though, given that the developers are only there for a year makes me think the development styles are going to vary some (if not a lot).
Getting the new person up to speed with your process is very important, as long as your process works. In this high turnover environment, you should put a strong emphasis on documentation in your process. A Wiki is a great thing to have for this documentation, since it's centralized and any of the developers can access it. Having them try to figure out how a project works by themselves (with little to no documentation) is a waste of both their time and your time.
Perhaps I'm reading too much into the question, but if your university teaches java, why are you using Perl? Wouldn't it make more sense to use the tools that your students already know? This alone would cut the learning curve significantly. [once you eliminate the legacy code of course]
other than that, try:
break the projects up into month-sized bites
overlap the internships by at least 2 months, if not 6, so the new guy can work with and be trained by the old guy(s)
document whatever repeatable processes you have (as was suggested by Mark Nold)
if the grad students are cheaper than full-time pros, quit whinin' ;-) If not, go for the pros.
Have you considered making a "three ring binder" like Macdonalds and many other high turn over industries have? Have one folder which you can print out and hand to the new hire which shows the new hire some basics of getting up and running with Perl in your environment. This should be a "hello world", plus some basic regex and array manipulation. Lastly your manual should go on to show examples of the 5 things you find yourself doing all the time.
The example code may be authenticating users against an external security system, walking through recordsets or using ghostscript to create PDFs. Whatever they are, they should cover the basics of what you meet 80% of the time. More importantly the examples should show users how you expect the code to be written for clarity (eg: naming and approach), and give them some insight into servers and software in use and other practicalities which a generic book won't show them.
You won't get the binder right first time, but since you have a high staff turn over, you'll have plenty of time to test and improve it.
On top of this i would pick a single Perl programming book and give the new user their own copy of your three ring binder, plus "Programming Perl" to keep on their first day. At a cost of $50 per hire i'm sure it's a lot cheaper than the alternatives and you'll have them flipping burgers.... i mean cutting code in no time.
My initial couple of thoughts are that you should:
hire for the position, i.e. it's Perl-centric so make that a big part of the pre-requisites. That way you don't need that piece of training as well.
invest time in the on-boarding process, maybe use a wiki so that you can easily update it to help bringing them on-board.
Edit: Some extra points:
maybe have a chat and see if Perl can be introduced into the curriculum? If not, then make it known six months before the ads go up that applicants need to know Perl. This way you'll get people who have Perl experience and who have actively demonstrated their motivation.
can you open up some small projects so that they could be done by potential candidates during this six months?
approach the design of your large-scale projects so that they can be done in a piece meal manner. This is how The ACE Components have been done iirc.
allow a specific period for documentation and review of the work done by the departing grad student.
allow an overlap period of at least a couple of weeks where the new grad student can work with the departing grad student. They can learn the development environment and they can be guinea pigs for any updates to your wiki.
Still more to come...
HTH
cheers
That is a pickle, but it is not as uncommon in the commercial sector as you would think. I heard a statistic once that the average tenure of a programmer industry-wide is about 18-24 months. Normally I would suggest getting more experienced programmers who would require less ramp-up time and only need to be trained on the problem domain/technology updates and not the basics
I think your best bet is just to ask for about 30-50% more grad students than it will take to actually perform the job to account for the learning and ramp-up time and invest in some additional resources for testing as this environment is a recipe for mistakes since everyone is learning on the job. Also, this is probably difficult given the academic schedule, but try to stagger the start dates as much as possible to maximize the overlap between employees. Pair-programming teams of new-hires/old-hires might also help increase consistency and supplement the training without sacrificing too much productivity.
How much time should I invest in training them, and how much would simply be a waste of time?
Answer: It's not the amount of time or the amount of waste, but perhaps the approach. Would it be possible to video train - video yourself training one person and provide it as training for subsequent students/developers. You can add over time, but it does reduce your time needed to go through the same process.
How much time should they take simply getting acclamated to our process and the project?
Answer: This is all dependent on the person...min. of a day max of 2-3 weeks I would guess on avg.
Are there any specific training practices or techniques that can help with this kind of situation?
Answer: Video training (home made), having the current student/developer create/update a wiki of needed info, points of interest, etc.
Has anyone dealt with a similar situation before?
Answer: Use to be a 12-18 month avg. turnover - I would imagine that it's changed now (longer), but every company has turn-over, but perhaps not forced like yours due to the resource being students.
Do I worry too much, or not enough?
Answer: Knowledge lost through transition is a key risk area...
Is the application something you could consider open-sourcing?
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 3 years ago.
Improve this question
Steve Yegge's wisdom notwithstanding, most developers are faced with requirements which were gathered from non-technical customers. Sometimes there are project managers who deal with the customers and translate their requirements, other times not. In any event, the fact that the requirements will change is an inevitability.
Most of what consititues "good programming practice" has to do with developing systems which are adaptable so that they can withstand changing requirements. Principles like YAGNI, DRY, loose coupling, etc. contribute to this. Iterative development processes such as Agile also attempt to address the concern of trying to hit a moving target, and of course having a system under test makes it infinitely more feasible to make changes.
Nonetheless, it seems that for many of us changing requirements can not only hurt the quality of our software, but can also drain our motivation and make us want to stab someone.
This question is about how to manage the customer to make it possible for them to change their requirements in the ways that they need, while discouraging arbitrary or frivolous changes. How do you do it?
Do you have project managers to insulate the devs from the customer?
Do you have a formal change management process? Change managers?
How difficult is it for the customer to get a change when they really need it?
Conversely, how easy is it for a customer to get a change when it's "frivolous"?
How much detail do you give the customer when explaining the cost of a change?
How quickly are you able to give the customer this information after receiving a request for change?
What factors can torpedo the process (e.g. PM's who can't say no to the customer?)
What works for you?
If you are looking for the ideal world where the customer never changes his mind or you get the ideal spec - you are in the wrong business. That being said, the most effective mechanism I have found for managing customer expectations and change requests is to institute an accurate system of measurement.
This is how I run my team:
1) We start with user stories. The customer is involved in writing them and the development team estimates how long each user story will take in a relative manner.
2) Using prior experience I take these relative estimates (story points) and create a rough schedule for when major milestones of the project will be complete.
3) Within these milestones we run 2-week iterations. The customer is involved in setting the approval criteria and whether or not the story has been approved. A simple burn down chart shows the customer how close we are to meeting the launch goal.
4) Often time during the approval sessions the customer will request a change because the feature did not turn out how he expected it (even though it met his original approval criteria). At this time you generate a new story with a new estimate. You can also adjust your milestone dates appropriately. This then puts the ball back into the customers court:
Often times they realize their change request isn't worth it (they'd have to get approval from their boss) and we'll kill the new feature
Sometimes it is important so we'll delay the due date to get the feature in
And finally, there's always the option to kill another not so important feature that will take an equivalent amount of time.
The key is not to run away from change requests, but to establish that every change request has consequences on the product. There's no such thing as a free lunch.
I work as indpenedent developer and so contact with customers directly. It's normal that most of the time they have no idea what they actually want. So we start slowly and I give them prototype early on to play with and then the changes will be gradualy made. If I think that customers wants "frivolous" change then I tell him that this change doesn't work or is not needed. If it is 5 min of work then I might even do it anyway.
It helps to add later on to the contract some maintenance clause to get money for those small changes that will come up later on. For bigger changes you just charge by the hour.
Managing the customer is hard, and it is something that very easily can go wrong.
I find that as early as possible you need to gain the trust of the customer. For me I think you can do this by:
Ask the customer to appoint a product manager - who is clear thinking enough to communicate the requirements he/she wants, and look to build a strong working relationship with him/her.
Really try to understand their business - you don't need to be a domain expert, but you need to know where the customer is coming from.
Ask pertinent questions about what they want - don't assume what they ask for (at first) is what they really want.
At first welcome all changes. This is not the customer being annoying and fickle, it as an opportunity to better understand what the customer really wants. If this costs you time/money, then you may need to accept it as a loss leader.
Deliver a prototype early, and incorporate as much customer feedback as practicable.
Give the customer a kick arse product.
Once you have done this, and the customer trusts you, then you will be in a position to start knocking back unreasonable changes, or ask for extra payments/time for things that were previously considered out of scope.
Of course, you won't be able to build this sort of relationship with every customer, some are idiots (in this case see if you can have a different product manager appointed) but you should always do as much as you can to build an effective working relationship.
You can’t expect customers to know what they want at the start, so you must be adaptable. But also you need to stop change for changes sake.
This is for ‘internal’ customers.
I have found that bargaining with the customer is an effective way to go. They can have whatever feature they want if they wait for it, or if they sacrifice some other (yet to be implemented) features. This forces them to think about the value of the change they are asking for in relation to the system as a whole.
Sometimes this works well and a good compromise is reached. Other times the customer throws their toys out of the pram and goes however high they have to get the feature implemented and quality is reduced.
If the customer is paying, it is a different ball game. They need to be made aware that change costs, and that the cost increases as the product nears completion. This means that you have to do a lot of up front analysis about what you will deliver and make sure the spec is agreed upon. So then you can measure what has changed. This may not be the most effective solution for either party but it does keep things cut and dry. So they are not dissatisfied and you don’t end up doing loads of work for free.
In software engineering, change is just a fact. It will happen. For us, everything comes at a price. We'll make just about any change the clients wants, but there is always a time estimate and a cost associated with it. Do we ever tell the client no -- not normally, but sometimes the changes request comes in at a very high cost. We do draw the line at potential security threats etc. in which case we calmly explain to them that we can't accommodate the request.
How much do we explain to the customer, we explain where the money is going to be allocated, this much for development, this much for analysis etc. We don't explicitly tell them why something costs the way it does. Now I will admit, this does vary a little with some of our clients. Some of them get very detailed billing as to exactly how many hours are spent where. To get the contract we had to agree to it, although this is very rare for us.
We have sales people who can't say no at times, and that can cause problems. We have spent a lot of time working on that, but unfortunately it still crops up. We combat it by explaining how much money they cost us by quoting something without researching what it will take. Transparency is key at all levels. Everyone has to know how their decisions affect the bottom line.
Do we do frivolous changes? Yep. What you have to remember is that when you bill hourly most of the time a 5 minute change is billed at a full hour, so that is quite lucrative. We explain all of this before like we do with any change request so they are aware of it, but it tends to help discourage such behavior unless it is really important. The fact is that we treat all changes the same. We don't assume we know what is considered frivolous to them no matter how absurd we think it might be. We have a formal change process where the customer asks for something we write it down and get them to sign off that is what we evaluate it and present a Cost of Work Estimate. They either agree in which case they formally sign a document letting us know it is ok to start, or they rescind the request. We try to be diligent, but we let them know that it will take a few days for us to get a response to their request.
A coworker of mine gave me the best advice I have ever heard about managing customer relations ships. It's a give and take. To make the customer happy, you have to be willing to help them when they need something, but at the same time, you have to be able to say no. When dealing with people they want you to help them, but they also want you to have a spine and stand up for yourself. It becomes a win-win situation that way.
I’d prefer a term of evolving requirements to “changing requirements”. Professor M.M.Lehman (http://www.doc.ic.ac.uk/~mml/ and http://en.wikipedia.org/wiki/Meir_Manny_Lehman) has done a considerable contribution into research on software evolution; his works also suggest that not all types of requirements evolve. One might consider themselves lucky if they happen to work on one of these systems, where requirements stay the same (i.e. math libraries etc).
To the rest of us experience suggests that developers prefer as much information about requirements up front as possible, whereas customers or end-users value an ability to specify or adjust requirements as late as possible into the development process. The former need the detailed information to help planning and designing the solution, the latter can gain a strategic advantage through changing a requirement late, because it gives customer some room for manoeuvre to respond to the changing environment or information gained on as a result of the earlier stages / iterations of the project. A trade-off between the ability to have a detailed plan and change things largely determines the development process itself (waterfall, agile, spiral etc).
Some practical advice managing the evolution of requirements:
Build in some room into the initial plan to account for evolving requirements, multiple check points or iterations.
Either put volatile requirements into the beginning of the project so that some kind of prototyping or feasibility study is likely to clarify them or plan for the change late into the project.
Monitor that the requirements are still relevant.
Have an up to date, prioritised list of current requirements handy. Nothing else helps to keep evolution in control as a good visibility to all stakeholders of current “must haves” including their relative priority and cost.
Keep managing customer expectations on how long things are going to take; this also helps to keep focus.
Introduce a formal process for changing or adding requirements if you need. The process description needs to specify roles of these involved, frequency of reviews etc. It could serve as a good safeguard against some political and most opportunistic but not essential requirements.
Build in some time for refactoring even for the first version. You’re very likely to throw all or part of the solution as a result of additional knowledge gain during the development.
The customer comes to you to do something because they either don't have the time to do it or they don't know what to do (and want to pay you to do it for them). If you have changing requirements, it's because of the latter. In other words, they are paying you to figure out the details! And they know what they like and don't like but they won't know how it works.
Recognize this and whatever the solution needs to be falls in to place.
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 3 years ago.
Improve this question
Our profession often requires deep learning; sitting down and reading, and understanding. I'm currently undergoing an exam period, and I'm looking for ways to learn more effectively.
I'm not asking about what to learn, or whether to prefer blogs over books, etc. My question is much more physical than that -
What do you do when need to study, and I mean study hard?
I'm looking for answers such as
I slice my time to 2.5 hours intervals and make a break between them, but never during.
I keep a jar of water nearby.
I wake up at 6 o'clock sharp and start my day with a session at the gym.
What good learning habits did acquire, or wish you had acquired?
(I know this isn't strictly programming related, but it is programmers related)
I find the best way to set yourself up for learning is:
Get plenty of exercise and rest
Eat a balanced diet with little sugar and caffeine
Try to find a quiet area conducive to concentration
Try to practice what you learn from a book - theory is ok, but practice embeds the knowledge.
"The best way to test whether or not you know something is to try to explain it to someone else from scratch."
That has to be one of the best ideas I was ever given about knowing whether or not I really know something.
Make sure it's quiet and comfortable around you.
enough to drink and eat
don't just read but take notes, draw mindmaps and the like
don't just read but try
make a report, blog entry, presentation out of what you learned
learn the same thing from different sources: Don't just believe what person A has to say look for, read and understand the opinion of person B and C as well and understand the differences.
take nothing for granted
apply the knowledge to an actual project
I set aside time every day or x times per week. Otherwise I never do it.
I try to have a diff location every once and awhile (home / coffee shop / stay late at the office) keeps the tedium away.
I am careful about the music I use, try to make sure it is relaxing
Sometimes I leave headphones on even if music is off that way people don't talk to me.
I give myself specific goals before each break or for every session.
I reward myself
Read Andy Hunt's "Pragmatic Thinking and Learning" - lots of good suggestions there.
Tony Buzan wrote The Mind Map Book, describing his ideas for note taking. He also has some process ideas that I found very helpful. Foremost was this one: study new material for an hour, then take a short break (5-10 minutes) and then review the new material. Review the new material again an hour later, then two hours after that, then the next day. You need to refresh your exposure to the material multiple times over the course of time to really take it in.
While reading, I make sure I fully comprehend each section in the text before I continue.
Set up a time and take away all distractions. At home/dorm can be rough, so I would use the library while in college. Getting started is usually the hardest part, so don't set a specific time limit for when to quit. It is distracting, and you will be looking at your clock to see "how much longer you have." You don't want to be in that mindset. Work until you feel your brain is starting to lose focus, whether that is lack of comprehension or having to reread simple paragraphs repeatedly. Take a minute or two as a break, then refocus your mind. When that stops working, it is time for a real break.
Are you a night owl or early bird? Each person is different. I am very productive early in the morning, while my wife can barely function. We all have differences, so don't try to fight your nature.
+1 to what everyone else said. Making cheat sheet/notes were a very important part of my studying habits, whether I could use them on the exam or not.
I find it best to be fully dedicated to the task before I start. If you go into something with low morale, you will not do well. If you go into a task with high morale, you will understand things quicker, be able to apply it to real situations better, and will have a deeper comprehension. If I am not fully dedicated, I don't even bother. I've got better things to do with my time then half ass something, and you probably do too.
Expanding on a comment I left, see this article from Electronic Design from a few years ago: http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=5859.
If you can teach what you learned, you know it.
by Louis Frenzel
All learning is self-learning. Professors, trainers, and all teachers just organize and present the material to be learned. They don't teach it to you. You learn it. You're the one who actually absorbs, understands, and assimilates the knowledge by listening to the lectures, reading, thinking, solving problems, and other activities. Self-learning is a natural, human quality. While most of you have used this method in the past, you may want to do it on a more formal basis to speed up and fine-tune your methods. Here's a suggested approach (and trust me on this, you must write it down):
Clearly identify what you want to learn. Write it out.
Write some learning objectives for yourself. These statements clearly identify what you want to know and be able to do. For example, you should write something like "When I complete this learning assignment, I will be able to design and program an FIR DSP filter." The objectives should be expressed in "behavioral" terms, that is, using words that state some measurable outcome.
Identify some initial resources. Start with books at the local bookstore or go to www.Amazon.com or Barnes & Noble at www.barnesandnoble.com. Most cities don't have good technical bookstores, and it's tough to find anything at regular bookstores. Consider yourself lucky if you have a good technical bookstore or a good college bookstore. Plan to get multiple books to give you greater breadth of coverage with multiple explanations, examples, and perspectives. Don't forget to look through your stack of magazine back issues.
Check out online sources. Do one or more Web searches, or go to relevant company Web sites. You may run across an appropriate tutorial, white paper, or application note that will give you what you need. The large semiconductor and equipment manufacturers have tons of stuff on their Web sites, so start digging. Also check out the professional societies and other sources listed in the tables and sidebars.
Watch out for any conferences or seminars on this topic. Usually, such events never occur when you need them, but you might get lucky. If you find one, attend because it will provide a big head start for your own learning.
Organize your materials. Lay them out, mark them up, and then make an outline based on your objectives. See what you have and what you lack, and make an initial list of things to do.
Dig in. Set aside an hour a day or whatever you can to go through the materials. Turn off the radio, CD player, and television. Make a habit of finding some quiet time to read and learn.
Look for a human tutor. You could be working just down the hall from an expert on the very subject you're trying to learn. Pick his or her brain. Ask this person if he/she will help you understand and learn. Take this person to lunch or offer to pay for lessons. Most people will gladly share what they know, if you aren't too proud to ask. The best way to do this is to learn as much as you can on your own. Then, go for the professional, personal help with tough questions or when you get stuck.
Include some hands-on. Is there any hardware you can buy or put together to help you learn it? Maybe there's some software that will help. Buy it or have your employer buy it.
Write a paper or article or teach what you have learned. You have to know it to write it or teach it. There's no better way to learn for yourself than to have to explain it to others.
I generally find it useful to build a "cheat sheet" or other form of summary as I go.
On one hand, it forces me to reinterpret information and figure out what's really important.
On the other hand, I'm building a useful study tool for last-minute revisions, or future refreshing of knowledge.
2.5 hours without breaks seems like a lot. Experiment with different time slots to see what works best (personally, a sequence of 3x(20 work - 5 break) works well)
Pomodoro Technique for time management
http://pomodorotechnique.com/get-started/
(watch "how" tab)
And the code(for programmers)
while(day) {
for (int i = 0; i < 4; i++) {
work(25);
relax(i < 3 ? 5 : 15);
}
}
You should implement methods
void work(int minutes);
void relax(int minutes);
Variable day changes from other threads
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
You and I want to be the expert on computer programming or website design, but sometimes a customer would rather try their hand at your specialty than concentrate on real estate sales, marketing, or being a former member of the Israeli army. Then we have a choice: either figure out how to tell the prickly customer their logo would NOT be better spinning in 3-d with a righteous lens flare, or perhaps suffer the small indignity of making link texts as verbose as possible in direct opposition to any style guide ever written.
Have you been able to convince your customers to focus on whatever it is they are trained to do so they will let you execute your technical skill to the best of your ability?
I always try to point my clients in the right direction with regard to design. Sometimes it's just not possible though; they want something that's dreadful design, but they're convinced it's essential to their system. If they're unconvinced after a modest pitch, I just do what they want. They are, after all, the ones paying me (usually) thousands of dollars to build to their spec.
Often the reason the client wants to get involved is they are concerned consciously or unconsciously you don't understand the details of their business or how they do it.
The best approach is to work with the client to learn their business. This involves zero assumptions and learning the "how they do it" of their business. From that, discover all the data they use, what states the data sits in at what point in their process.
Keep taking it back to them and eventually they will realize that not only do you understand their stuff, what they want, and what direction they want to go in, but that you might even know the implications or impacts better than them.
After this they will usually stay out of your hair. This can be hard though when working with micromanaging types, or engineers. By nature they want to know how everythign works which is great. The timing of when it's best to learn how it works is the tough part.
Often you can get stuck in more conversing about solving a problem than it would take to just fix it. Maybe you can tell us more about the client's personality.
The trick is to get them to make the right decisions, but think it's their idea. :-)
You can't have this conversation with them easily in the abstract, but you can drill down and guide them towards the side of righteousness on each individual decision. Eventually, after you've been through this a few times, they'll start to trust you.
If possible, it helps to wait a day. Tomorrow they may be less clear on exactly what they asked for. (Do they really have their heart set on a flaming logo, or was it just a whim?) Then, in your response, you: describe what you recommend, and why. Restate agreed-upon objectives, and show how the solution meets the objectives. And make it sound like it was their idea. ("The point you made yesterday about xxx is really excellent, and I think that suggests a yyy solution.")
At this point you have a choice. You can ideally pretend you never heard their silly suggestion. Or if you feel you have to, respond to it tactfully and explain costs. ("I'm a bit concerned about the animated logo idea, because it may not convey the brand image the way you requested. Of course if you want to go this route, we certainly can--in which case I'd suggest we get our graphic design consultant involved. Let me know if you want to explore this further and get a quote from the consultant for his services.")
I found that customers are always easier to convince by "optical evidence" than by theoretical arguments - so you could e.g. show them logos or the general style used on websites which won a price for their usability, or maybe even show them how some big competitor is doing it, and then point out the benefits based on what they see.
I've also once managed to get rid of a really terrible user interface suggestion by making screen mock-ups of how this feature would actually look and work - and I made sure to make thes mock-up as unappealing as possible ;-) When I presented them, the client quickly realized that there were better ways of achieving his goal.
Knowledge is power. When you know a client is doing something wrong, have the facts ready as to why and present them quickly and in plain english. You need to remind them why they hired you in the first place.
Bearing that in mind, sometimes clients insist on shooting themselves in the foot. Have backups ready, use version control, but most of all: don't antagonize them. Your reputation is worth a lot more than their 3d-logo-spinny site.
Very carefully.
You've got several conflicting issues here: you want to keep the relationship (and the revenue), you want to do good work, and you don't want to end up with your name on a turkey.
Start by asking lots of questions about the business aspect: what do you want it to do, who do you want to reach, what impression do you want to give. Sometimes that will let you turn the discussion to more useful topics.
If that doesn't work, sometimes it helps to mock up the customer's idea and your idea, and compare them; if yours is clearly superior, they may see it.
If not, sometimes you have to remember that contracting/consulting is a form of prostitution; you do what the customer wants, whether it's your favorite thing or not.
The other thing to remember is a lesson I got from another consultant years ago: some customers aren't worth the trouble. he recommended that once you have enough business to live, you make a practice of firing your least liked 10 percent of the customers. Over time you develop a customer base that you can work with, and give the turkeys to someone else.
The problem with customers is that they are the customer. They have hired you to do a project to their specifications. What they seem to have missed in your example is that they have hired you because of your experience. You need to remind them of that fact in a gentle way. Perhaps a story such as "At one client, we used a logo like that and they expereinced a drop in traffic. Once we switched to a flat icon the traffic returned." Doesn't have to be true, per se, but you need to sell it.
All you can do it explain to your customer that they hired you for your expertise in design, but at the end of the day, the customer is always right.
If you find you don't enjoy working for customers like that, simply state at the beginning of a new project that you require complete creative control. If they still want rotating logos, then you'll have to put up with it for that project but at least you can decline any offers from the same customer in the future.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am currently a grad student, but I was in the industry for a few years before going back to school.
I am in a class which involves teams of 4 working on fairly ambitious projects. As a result of having been in the industry, I have a lot of "software engineering" experience my fellow teammates lack (they are using SVN for the first time this semester). They are all very good programmers; but they don't have a lot of experience in building "real stuff".
Since I had a fairly concrete vision for a project, and my teammates did not, my idea is the one we will spend this semester working on. On top of that, as a result of my experience, plus the fact that I admittedly have a somewhat strong personality, I've become a de-facto team lead -- established weekly meeting times, assigned initial tasks, etc.
I want to avoid the trap of being so forceful with my ideas for what we should be doing and how we should be doing it, that my teammates feel like they have no say and become uninvolved and detached.
So here is the question:
How can I keep my team of undisciplined but talented programmers motivated while enforcing basic best practices (version control, milestones, etc) and a coherent project vision?
Edit: Thanks to everyone who answered so far. I think I've overemphasized the "software engineering" aspect of things; I'm also looking for ideas for how to encourage my teammates to contribute to the design, and feel ownership in the project which is at the moment a little bit "The SquareCog (and friends) Show!"
The best method I've found has nothing to do with code: team lunches.
Get together in an informal setting where you each talk about your problems, concerns, ideas, etc. This helps team unity in a way that very little else does.
As for the actual code side of it, minimize the amount of work they have to do to work inside the framework you want them to. If you want them to use tickets, do the actual management side of things for them -- have them tell you what the ticket is and have you do the actual legwork of managing these things. This seems like it'd take a long time, but overall it's minimal compared to the cost of poor communication and coordination. It pays off very quickly.
For version control, show them why it truly benefits them. Programmers pick up on ideas and run with them when they see they actually help them rather than just being a PITA.
I think developers are really practical people.
Play with those traits of typical developer personality:
1. Creativity
2. Curiosity
3. Practicality
Following your direct example, source control:
Most of us (I mean by my own experience) will fail to see the point in source control in the beginning (just because), so always keep them aware of the reason behind using source control.
Another thing is.. who decided to go on SVN? There are alternatives, I for one would fight to the teeth not to have SVN because I am a Git! (pun intended)
Instead of pulling them by the nose, you should/could have explained to them:
We need source control, find one you like and lets vote it out what we use to control the source.. this way there is a common ownership..and not just a follow the leader exercise.
Another thing is, be flexible in what you implement.
Draw out a plan on necessities, but try to be ready to implement them as the need arises, or as it becomes obvious to all that x, y or z practice should be implemented.
Have them need to implement the tools and resources and planning techniques you know by having them come to you for advice. (this doesn't mean you can't lay out a best practices blog internally or some other way of giving them access to this information beforehand)
Developers like to learn and grow, but we need ownership and understanding in the direction we are going.
If you try to force feed and drive them too much, both you and them will just lose motivation, enlightenment requires self driven forces.
How about the Scrum (even if you don't call it that). Gives everyone a chance to have their say, and you listen. As the forceful personality giving the others a real chance to communicate what's on their mind (not yours) is a good step towards harmony.
On top of that they will learn from your tech experience, you will learn from their ideas and enthusiasm. A good leader is always open to communication, you set the direction and vision (and you did choose the project) they come up with the clever ways of doing it.
I've been in a similar position a number of times.
Sometimes I just take charge, and be damned. Fair enough.
And many times, I resist the urge; I try to encourage my colleagues to take the lead. Sometimes this works, sometimes not.
And sometimes, I just come clean. "I seem to be taking over, as is my nature. But I don't want to railroad you guys. Anyone else fancy taking the lead? If not, are you happy with what I have already suggested? Speak up if you have any good ideas...". Again, sometimes this works, but not always.
Ultimately, you can 'lead the horse to water'... Projects need the lead, if no-one else rises to the challenge, it is better that you do.
Once you have the lead, lead by example...
The project should be interesting enough to keep them involve
the technology should be also recent
let them know this is how the industry moves and that they will gain the necessary experience to be in top of other programmers
offer prizes and punish those who break the build
rotate the positions let them test their ability to lead
offer non-monatary prizes or awards
Give them their own areas to "own." Even though they may not take pride in the project, they will want to make their own areas excel. Make they question, can their area be refactor or improved. It will make them learn new techniques or practices.
Allow them to learn by fire (in small phases) and then show them the correct way. Let them fail doing it their way, but allow time for them to do it the proper way.
Update:
Sorry to make the above sound like the team-leader would be the one in control of what is correct. It is mean to be more of a code-review that can be done by any one on the teams. They can move forward with the changes/refactor together as a team.
I am doing my masters degree currently and have had frequent group projects. It is not unusual to have only 1 or 2 members of the group doing the project. Not just from my projects but talking with other people. Basically what you said about the "SquareCog" and friends show is not unrealistic.
Really the more people you have on the group the lazier people will be. Also the more time lost communicating with them as they invent tons of ideas that they have no intention of following through with. It is well known that there is a point where extra programmers do not help the project anymore. There is only so much you can break something up. Over doing it will slow things down more than just giving a part to one person and create more dependencies.
Also the average student has a comfort zone, so even if you can get them to do some work, the will stay within their comfort zone. Someone has to leave their comfort zone for most projects (unless someone already knows the information in the class) to succeed. Most of the time I find that I am the only one willing to do that in my group, and some groups have no one. The most radical example was a 7 person project where almost no one did anything. One other guy was willing to do some light sys admin tasks and then the web design, that were within his comfort zone. One girl did some database design (and I do mean some because I basically did the design as a high level outline that she formalized with column names/data types). The rest did absolutely nothing. The class was distributed systems, so someone needed to learn JBoss (and Enterprise Java Beans), Amazon Web Services, etc... But it doesn't matter the class. In a data mining class, someone will have to figure out which techniques to use and how to use the toolkit.
Also many students are not good programmers. In fact there was someone in one of my groups who couldn't program at all. Really based on his description an MBA sounded like the right degree for him, but anyway he went through with the Masters in CS by farming out his programming to friends/contractors... Many are just terrible programmers and not just in style, they couldn't debug hello world with visual studio.... Rather than understand what went wrong they will just keep adding code until it works by coincidence.
One thing that happens quite often is that people come up with fairly ambitious projects that are not realistic for a semester. Usually I end up taking he scissors and cutting it to a barebones project and offer that once we finish the barebones part, then we can refine it and add the more advanced stuff. What almost always ends up happening is that people drag out finishing it and in the end after we get the barebones done no one wants to do anything additional.
There are 2 types of grad students. Full time grad students who take 4-5 classes, in which case they cannot afford to spend 40/80 or even 20 hour work weeks working on the project. Or part time grad students who have a day job, in which case they take 1 or 2 classes and have a full time job so they have even less time. I would say as a general estimate you can figure 6 hours of homework per graduate class (most will spend less). Assuming a normal class, probably 3-4 or that needs to be spent on studying/reading for the class. This leaves 2-3 hours per week per person to work on the project. Even getting that much would be good.
Some of the ideas floated like team lunches are not realistic at all. Many grad classes have group projects, and the full timers can't do 4 or 5 team lunches per week, that is like 5 hours of wasted time per week that could be spent on a rpoject. Also there may be money issues if you go to restaurants and expect all to buy lunch. And for someone who goes part time like me, I'm not going to do a team lunch because I work 9-6+ or 8-5 on college nights.
Probably your best bet is to find people's comfort zones and figure out tasks you can assign to them. Also to identify the freeloaders and not waste your time with them.
Also using version control for a school project seems like overkill. If the whole class is just the project maybe not. But assuming it is a normal class with lectures, exams, and homework assignments with the project done on the side, then any time spent on infrastructure is time you are not getting the project done. Really, though unrealistic for a professional environment, school projects are like start ups. Get them done, even if the code is a mess. You can always clean up later. But if you don't get it done, your grade will suffer. And in reality once it is done, I don't want to clean it up and no one else does either.... Getting everyone to use source control (unless you share a machine) would waste a lot of time with set up issues, and adjusting people to using it. i don't know what your project is. But with many graduate projects you have to do some research/experimentation and then the programming code is relatively simple. One class got me with a 5,000 line project, lucky it wasn't a group project.
Again on the project keep it simple. You can just coordinate the parts, assign the different parts and as they are done check/test it and then integrate it with your version control and leave them free to work on the project whatever is most comfortable.
Many will be happy to let you design the thing, implement the thing, and then learn absolutely nothing and just get the grade. It is their loss because they won't get the lessons of the project. But they are quite happy with squarecog and friends being just squarecog. Some will want to contribute something, but they are in the minority. If you get one of them great for you!!! Also watch out for over engineering. You have to look at things realistically. 3 hours per week per group member would be great, but I find even that is unrealistic. When a project is due sometimes you might get 5 or 10 hours per week from someone who slacked off. But you can't expect more.
How to Win Friends and Influence People has the following suggestions:
Fundamental Techniques in Handling
People
Don't criticize, condemn, or complain.
Give honest and sincere appreciation.
Arouse in the other person an eager want.
Six Ways to Make People Like You
Become genuinely interested in other people.
Smile.
Remember that a man's Name is to him the sweetest and most important
sound in any language.
Be a good listener. Encourage others to talk about themselves.
Talk in the terms of the other man's interest.
Make the other person feel important and do it sincerely.
Twelve Ways to Win People to Your Way
of Thinking
Avoid arguments.
Show respect for the other person's opinions. Never tell someone
they are wrong.
If you're wrong, admit it quickly and emphatically.
Begin in a friendly way.
Start with questions the other person will answer yes to.
Let the other person do the talking.
Let the other person feel the idea is his/hers.
Try honestly to see things from the other person's point of view.
Sympathize with the other person.
Appeal to noble motives.
Dramatize your ideas.
Throw down a challenge & don't talk negative when the person is
absent, talk about only positive.
Be a Leader: How to Change People
Without Giving Offense or Arousing
Resentment
Begin with praise and honest appreciation.
Call attention to other people's mistakes indirectly.
Talk about your own mistakes first.
Ask questions instead of directly giving orders.
Let the other person save face.
Praise every improvement.
Give them a fine reputation to live up to.
Encourage them by making their faults seem easy to correct.
Make the other person happy about doing what you suggest.
In addition to this, "Top Three Motivators For Developers (Hint: not money!)" notes the Autonomy, Mastery, and Purpose ideas that can also be great motivators for people when it comes to creative work.