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 want to work as a programmer in a game modification team. Most teams require a portfolio to show.
I haven't any previous experience with game programming and I would like to know what I should program and include in the portfolio
Thank you
I'd seriously consider writing one or more small, simple games yourself before embarking on joining an established team. You'll learn a lot about yourself and the technologies involved in games development, and you'll be putting together your own portfolio as you progress. You may find that you'll be in over your head if you join the mod team directly, especially if you have no experience at all. If the team is modding a particular game like Half Life or Unreal, then I'd use the time to get familiar with those tools - using the assets which are already there will give you a useful jump start.
Your games needn't be complex or graphically rich. Concentrate on ideas and simple execution. It's too easy to get bogged down with detail, especially if you're trying to impress. How about a simple puzzle game? Or tacking on flight simulator style controls to cruise around an FPS level? :)
Best of luck!
A portfolio should present what you consider to be your best work in various categories. For a programming portfolio, you don't necessarily need to put exclusively games in it, even if you're looking to join a game development team.
For a portfolio that you want to present to a game development group, my suggestion would be to break down the different aspects of what makes up a game and include completed and polished programs that highlight certain aspects.
Suppose you break down the game development pipeline and come up with the following list which shows the skills you want to highlight:
3D Graphics
Physics
Human Interaction (Gameplay and UI)
Artificial Intelligence
Take a project for each category and make that aspect shine! Make each one interesting for the end user. Having different programs highlighting different skills shows that you are multidimensional - you're not just a one-trick pony.
Now, there's one more thing a portfolio should do, and that's highlight you! The small projects highlight your skills, but usually it's good to include one major project that shows many skills and, more importantly, your personality. This should be something you're proud of making, and something that you're excited and passionate talking about. Passion is contagious! When you show passion about something, people can't help but take interest.
Hope this helps.
Program anything you think you could do well. A portfolio is not as much about quantity as it's about quality.
It's been a few years since I interviewed with game companies so some things could have changed, but here are some notes from my experience:
If you are in college, try to get into summer internships with game companies. Microsoft, Blizzard, Epic, etc all have summer programs that will help you build your portfolio. Most of the time, they will have you work on tools for their full time developers to use, but that is how you get your foot in the door.
If you are coming out of college (or, as was my case, have been developing non-game applications for several years) and don't have titles you can put your name on, you'll have an uphill battle. The best way to approach it in this case is to do one of the following:
a) Develop your own custom game engine and make some simple games with it. This will show knowledge of the basic fundamentals the game companies are looking for.
b) Develop a mod of a popular game. A good example of this is DotA (custom scenario for Warcraft III), or various Unreal Tournament mods.
c) Develop some games with an opensource, or somewhat inexpensive game engine (e.g. OGRE, Torque3D, etc.)
Despite having 5+ years of application development (with shrink-wrapped software used directly by customers), I'd get to the 2nd, 3rd, or even 4th interview only to get the response, "You have a very strong background in application development, but you don't have much of a game portfolio. Please work on that and apply again in the future. Thanks."
Good Luck!
All of the suggestions made so far are wise, I'll also add this.
Games in the idea stage are pretty dangerous. You'll keep thinking of things you want to add, technologies you want to use, and so on. Get out of that as quickly as possible for every project.
Start by thinking of a core idea for a game, ideally this should be a short, one or two sentence description. Even better would be a two word description: "Asteroids RPG!". Then come up with a bullet point list of the features it should have.
Once you've got that list, absolutely never change it and never stray from it while you are coding. If you have new ideas and you just have to explore them, start a new list for another game.
Hopefully you'll have something you can actually play by the time you've completed one to three of those bullet points; you can make the character move on the screen, or enemies do their thing, something you can interact with. At this stage, although the game isn't very deep, it should already be fun. Just moving your guy around in an interesting way should feel a bit stimulating and make you actually want to play the rest of the game.
If it doesn't, figure out why not and fix it. If you can't figure out why it's not fun by this stage, or you can't figure out what would have to change for it to be fun, drop it immediately. If the core gameplay mechanic, the first thing you needed to make the game a game, isn't fun now, it won't ever be fun.
You need it to be fun if you want to use it in your portfolio. If it's not fun the interviewer won't play it much. You don't want it to be too much fun, of course, you really want the interviewer to be interested in it and then move on to the source code or the next game. You want to show them a variety of ideas you can explore, and a variety of techniques you can use.
Include the best programming examples that you have.
C++ is used in the development of a lot of games so try to use that language.
You can use other languages as well through if they show off your programing experience a certain topic.
If you have any well polish projects that involve computer graphics, AI, physics, or multithreading include those since are topics that are used very often in game development.
Another good idea is to go through these projects and provide comments if you haven't already. Include a description of the project and the goals somewhere easy to find in the project.
Overall you should try to use examples that feature the above areas and that show that you know how to structure a large programming project. Game development is alot smoother when you have a good project layout.
To quote an old professor: The first time you program a project you do it the wrong way. The second time you do it in a way that works but is not effective (difficult to modify, not efficent). The third time you program the project it's acceptable.
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
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 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
Some developers when given a task go straight into the IDE and start coding with very little design. They may have an idea of where the application is going as they are coding. I am 1 of these developers. I do this because I feel that if I spend a lot of time designing my application delivery time will be much higher as compared to if I just sit and code away the ideas in my head. My question is that how does application design effect the delivery time of the project and does it have a big advantage over coding the agile way?
Give you a example, when you want travel,
If your destination is near or in your town, you can start right away.
When you want travel to another country, you need package your self first.
Design is for preparation, without it , you cannot go too far(or go the wrong way).
It is not a black and white situation: for some projects it is much better to jump in and start coding, for some it's better to have an extensive planning stage, and for others it is not clear cut.
If the project is small and simple enough that only a single developer is working on it, and how to build it is obvious enough that they can imagine every aspect of it in their head, then they can very well jump in and start designing.
The need for more extensive planning comes about when you have multiple developers, or when the project is large and complicated enough that a developer cannot know everything possible about how it will work from the outset, because it is too complicated to know all aspects of it in your head.
What you describe only works well if you are writing something well well understood and contained. If it is similar to other software you've written you don't need a new design because you can just re-use the old one. however, if it is something totally new, designing on the fly will get expensive. You'll find yourself rewriting too much of the code or worse, stuck with a poor architecture which slows you down. Likewise, if you need your code to be extensible, planning ahead is necessary. If you need it to work with components from other people, planning ahead is necessary.
This approach only really works well if you are working on your own. If you have to work within a team of people, it is important to have a good plan so that everyone else knows what you think is the end goal. This doesn't reduce creativity it just allows you to make sure everyone is on the same page, and it reduces the opportunities for confusion.
(source: yang.id.au)
Just to add a line of thought to your equation scenario, let me contribute this little bit hereafter: I work in a business called YES INTERNATIONAL CORPORATION (www.yesintl.com.au) Sometimes, it does happen that developers may have developed something before so in that case the design is already in the mind. For example, I have developed database solutions in the past which makes us a very fast delivering corporation compared to our competition when I sit down and start developing a project. More experience will make you super perfect as the time goes by... I hope this helps... Andy
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
What are the main reasons personal projects (software apps etc) never get to the level of competing with your salary?
To me one big problem is "on-the-fly" feature expansion, with this problem, the end only gets further and further away!
For me, it's simple: I work 8 hours a day already. I spend a few more hours a day keeping current. I have a girlfriend, some local family and a decent circle of friends. I have (gasp) non-computer-related interests and hobbies. In other words, I have a life.
So ... Time. Time is not on my side. Would that it was ... My blog might be a bit more current if there were just two more hours in every day. :)
(Originally posted by John Rudy.)
If you want your hobby to become your job you have to acquire all the other skills you need to be in business. At the end of the day your pet project has to stand on its own two feet in the real world. At the same time you are enjoying the coding you need to get yourself a concrete plan to commercialise your activity.
Most hobby projects fail to make the big time for one of two reasons:
The idea is not commercially viable
The discipline necessary to commercialise the idea is missing
Just because you are a great technologist does not mean you'll be a great businessman. You may be, but the two are not necessarily linked. It is no weakness to consider partnering with someone who has no technical skills but a good network and some proven business acumen. Quite often people like that are looking for techies too so you might find a great partnership. That person can provide the structure and commercial discipline that you probably lack if feature creep is pushing your completion backwards.
I think the primary reason is the simple work overload that most developers experience. Most personal projects take place in the evening and weekends, and as excited as most of us get about our ideas for personal projects, after 40 hours (or more) of salaried programming, it's hard for "more work" to compete with watching a game while sipping a beer or spending quality time with the family.
Different skill sets are required to start and maintain a business than to develop software. Entrepreneurship skills can be learned, but not every has the skills to make it happen. A lot of times the skills it takes to get something started and off the ground are different than the skills it takes to finish it and polish it. For me, I know that I have the creativity to make software and find ways to solve problems, but I have little interest in finding funding for a business and marketing a product or service.
Assuming that you're a developer, it's most likely due to the fact that you do not know when, or are incapable of, stopping development and focusing on other things, like marketing and sales.
Time and Losing Interest, there is always a new tool or technology that can take your attention away from completing projects.
I'm not sure if I understand your question, but here are a few answers:
Adding "on-the-fly" features isn't necessarily a bad thing. In fact, it's the expected model of Web 2.0 and Web 3.0 projects. The key is to keep them very simple, only roll them out once they've been tested, and listen to your users. If you try to dump the kitchen sink in on the first release, it will most likely be ugly, confusing, and buggy.
Being a great programmer is only a part of it. You need business skills, marketing, knowledge of the user's needs and how to meet them, artistic/design skills, and a hell of a lot of luck.
Lot's of people have great ideas. Often different people have the same ideas. Most never get implemented. Of those that do, very few of them succeed. In some cases, revolutionary products took years to convince the buyers and users that they even wanted the product. Often the people or companies behind the first few iterations failed miserably and then a third or fourth person or company finally hit the market at the right time with a right product. Apple is great at both ends of this by the way - they not only innovate (first Mac, the Newton, etc.), but they also wait until the market need grows and they sense a place to pounce in and take advantage of it (the iPod, the Mac vs. Windows issues, etc.)
Most of these bullets apply as much to software as they do to widgets and services. The big advantage that software has is lower startup costs. Just like the saying "On the Internet, no one knows you're a dog" - "When looking at a web app, the user doesn't know if you are a multi-billion dollar company or a single guy sitting in your underwear in your parent's basement." If your software is good, that is...
I'd say one of the big reasons is that by nature, personal projects don't get as much attention as your job will.
I have a slew of personal/side projects I'm working on, but they get far less of my attention that my 'real' work does because, right now, that's what's paying the bills.
If I were to take a month off and work only on my personal stuff, it'd probably be pretty cool / worth money.
developers often design for themselves instead of for their customers
developers tend to put off releasing products until things are 'perfect' - and they never will be
Weakness of mind and spirit. Build a team around your product early.
Scope creep. Concentrate on selling what you have already got: "The customer can have any color he wants so long as it's black". Henry Ford
Small feature set. Leverage features of your product by what is already available on the market.
Not enough hours spent daily. Often achieving something might depend just on simple routine, putting your time in.
Deep down I think its a lack of belief in the project. If I believed in what I was doing I would not stop in completing the project.
Desire to build an ideal product
For example: There are various ways (algorithms) to get a particular task done. But, people wait to discover that one ideal solution. Even if there are multiple solutions for the same problem already available. That ideal solution is never found.
Procrastination
Your personal software projects don't compete with your salary for one reason.
What do you do for your salary? Whatever that is -- however much you may like or dislike it -- it more valuable than your software product.
"But my day job involves a lot of stupid time-wasting meetings." So? Clearly, someone will pay you more for wasting your time in meetings than for your software products.
"But my day job forces me to waste months in useless analysis and design documents and test plans that never even get used." So? Clearly, someone thinks this activity is more important than writing software.
"How can meetings or useless documents be more valuable than software?" I don't know, but look at your experience. Companies love to pay programmers relatively large amounts of money to hang around and waste time.
Companies don't love to pay for software.
Your personal projects don't compete with your salary because your time is more valuable than your products.
The biggest reason? Because if you can write it yourself and people like it, someone else can make an open source version with much better support than you can provide alone. Why not skip the middle man and release it as open source yourself? Sure, you miss out on the direct profit, but that looks very good come hiring time.
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 find way too many projects to get involved in, way to many languages to play with (and way too many cool features within those languages), and way too many books to read...
How do you guys stay focused and actually get anything done, rather than leaving a trail of partially complete "experiments?"
Seems like there are two types of developers: Tinkerers and Entrepreneurs.
Tinkerers want to know how every little thing works. Once they get the hang of something, they're distracted by everything they don't know. The tech world is brutal for a Tinkerer because there's so much to learn and each new year creates more. Tinkerers are proud of their knowledge.
Entrepreneurs want to know enough to build something really great. They think in terms of features and end-user experiences. You never hear them argue about Python over .NET over Java over C because they just don't care. They're more interested in the result of a language versus the language itself. Entrepreneurs are proud of their user-base.
Sounds like you're struggling with your Tinkerer tendencies. I've got the same problem and have found only one thing that helps - find an Entrepreneur developer that you thoroughly respect. When you put the two together, it's unbeatable. The Tinkerer plumbs the depth of every technical nuance. They keep the Entrepreneur technically honest. In turn, the Entrepreneur creates focus and opportunity for the Tinkerer. When they catch you browsing the Scala site (assuming you're not a Scala developer), they reveal a new challenge in your existing project. Not only that, they're much better at understanding what non-Tinkerers want.
Money, and the feeling of accomplishment that goes along with actually finishing something. When I first thought about working for myself I started coming up with ideas of software that I would develop and then later sell. Of course, I really didn't know if what I was making would actually sell, so it was easy to get distracted and jump at new ideas.
So I decided to go with being a contractor/consultant. When you know that there is a buyer for what you're making, and that somebody is waiting on it, it gives you motivation. If it's an interesting or challenging project, there's a rush associated with finishing it. So that adds extra motivation because you want that rush more and more.
Once I got a fairly steady flow of work-for-hire projects, I found that I can stay focused on my side projects better because I have incentive to practice good time management. I give myself a certain amount of time every day or week to work on my side projects, and it helps me stay focused when I take that time.
Of course, I still go off on tangents occasionally and start new side projects as well, but the ones that I am most interested in I have been able to stick with.
Also, after you finish some projects, then you get a better feel for what it actually takes to go from conception to completion, and it makes it a lot easier to do it again and again.
I think a good programmer may well have lots of unfinished "experiments" hanging around, this is a good thing.
Usually with a good manager, you will be held accountable if your work is simply not getting done. If you're a student, though, it's tougher. I realized that it is impossible to learn everything you want to.
I limit myself to only learning 1 or 2 new languages per year, and only 1 book per month. That seems to be a nice balance between programming chaos and getting my job done well.
Kudos for having a great learning attitude :)
Probably the best motivator (for a team or an individual) is to set goals early and often.
One of the best methods I've observed in project management was the introduction of "feature themed weeks" - where the team (or an individual) was set goals or deliverables which aligned under a general flavour, e.g "Customer Features", "Reporting and Metrics" etc. This kept the team/person focused on one area of delivery/effort. It also made it easy to communicate to the customer where progress was being made.
Also.. Try to make your (or your team's) progress visible. If you can establish an automated build process (or some other mechanism) and "publish" incremental implementation of work over a short period of time you can often gain traction and early by-in which can drive results faster (and help aid in early course correction).
1) I leave a utterly MASIVE trail of unfinished stuff, all side projects of course.
2) When I need motivation to work I open my wallet... That usually does it for me.
I'm building an app I plan on selling and see it as a way of making extra money or reducing the amount of time I spend working for other people.
My wife likes this idea and her encouragement has managed to keep me focused longer than normal as it's now "work" rather than "play"
I find that getting involved with the "business" side of the equation helps tremendously. When you see how much benefit the actual users of your program can get out of your creative solutions to their problems - it's an extreme motivation to provide those solutions to them. :-)
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.