As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I'm in Des Moines, Iowa and we have a good number of user groups in our area considering our size. Ruby, .Net, Java, Agile, *nix, etc... Well, tonight a good number of us "leaders" of said user groups got together for a couple drinks and to talk about how we can work together to help make the "DeMo" (I keep seeing this on Twitter) user group scene better.
We came up with a number of rather good ideas, but I'm curious. What compels you to attend your local user group(s)? Dig deep here guys. Maybe it is the free pizza, or the give aways. But I'm more interested to know about things out side of the freebie stuff.
I've always found the professional networking to be completely invaluable. I got my current job because of the Denver Java Users Group and it was one of the best choices I've ever made.
I know of 3 different types of events around here for local user groups where each has its own pull:
1) Presentations/Talks - Where someone comes in and talks for an hour or two on a subject to either introduce or advance the knowledge of a technology. So, an introduction Dependency Injection or Windows Workflow are a couple of examples. There are also what are called "deep dives" where the idea is to get really down into the topic and see various tips and tricks and try to improve how all of us develop software well. There are times where Microsoft will rent a movie theater screen for a day and have a series of 4 presentations about their latest technologies would be another example here. This can also include things like the Agile Project Leadership Network.
2) Code camp - These are sooo cool, I love these where part of the idea is that people volunteer to show something off, and the work isn't canned. By canned I mean that the demonstration code is all prepared and we can't see how long it took to get the code to be that way, e.g. a dozen files of code that took a dozen hours to get from nothing to this state that in a demo may seem like this should just come out within a few hours which isn't realistic. Here they have taken a few rooms at a local university to do it. One blogger's view of one a couple of years ago.
3) Open spaces - This was an awesome event that I really look forward to the next one. A bunch of other developers come together and self-organize discuss whatever we want in a sense. The discussions had were varied and in some cases the results weren't great, like how do we get others to take their off time and come to these things or other ways to volunteer our skills beyond open source projects. What was going on the first day link.
Each of the last two occur on a weekend so it isn't during work hours. Sometimes the joy of seeing something new or a better way to do something can really be rewarding, in addition to the good networking opportunity where you'll never know where the people are that come to these things as the Open Spaces had a few people from other countries present which added a nice diversity dimension to things.
Are there other local user group type events?
Many people really have different reasons for attending, with many of them denying it but are really just after the food and schwags (of course I kid ^_^). But there are a few other things that interest me, particularly:
Professional networking (as Eric stated above)
Ability to find out what I've missed out on (if I'm not "drinking from the fire hose" on Google Reader because I was uber-busy)
Certificate of participation (some employers use UG participation as points towards merit)
Brownie points on resumes (if you are the speaker, that is)
Food and schwag (oops, mentioned that already)
I really just like the idea of meeting people who are as excited about a certain topic as I am; it's exciting and inspiring. Especially since I live in a fairly small midwestern town, people with common interests in computer technologies will not be very abundant, so the social aspect is really appealing
I agree with Eric. I also enjoy seeing how others approach problems and what solutions they have in place. The reason is, if you're not a consultant, you work with the same set of individuals and it helps to bring fresh new ideas into the group.
I have been attending local JUG meetings for some time and based on that I would say:
Networking, this is important for me as I have recently relocated
Organizing the event itself can be fun
Free beer!
A little different approach, but I can tell you what keeps me away... I've always been interested in going, but just don't make it to any of them.
Most of them seem to be in small towns an hour away, right after work, so I'd miss a significant portion of the meeting.
The rare one that meets here in the city seems to want to meet at night in a part of town I don't want to go to even during the day.
Because I get to see cool things like this (video - RFID deadbolt with embedded RFID tag. And I do mean embedded!)
Of course, this is one of the few groups I make time for - I don't have time to attend every group I'd like to, but this one has a mix of interesting Make, software, etc so they're never boring.
Try to understand what your users need, and provide it is the best advice I can give. Only you know your audience.
-Adam
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I often work with sales and marketing types that cannot figure out how to use Excel, let alone understand the scope of their requests from a technical perspective. Of course, it would not be fair to expect them to, but that still leaves me with a problem.
What is the best way to show marketing and sales types that they have asked for something that requires a lot of complex programming and some patience?
Could you please share examples of problems and solutions?
Could you please recommend books on this subject?
Thanks!
Break the problem up into as many sub-divided tasks as possible. Provide a per-item estimate in hours beside each one.
When they think of a project as a whole, it seems simple. However, when they see each individual thing that must be done and the number of hours each item will require, it is putting it into terms business people can understand. Suddenly the software solution they want isn't a "black box" to them anymore and they now have some insight into the process.
If you are looking for books I would suggest Software Estimation - Demystifying the Black Art.
The computer will do what you told it to do, not what you want it to do.
Any form of abstractions needed be translated to exact details.
source http://c2.com/cgi/wiki?TeachMeToSmoke
Teacher: "It's hard to express ourselves clearly. You're a smoker, right?
Are you pretty good at it? [Student nods.]
Let's pretend I'm a man from Mars and you are going to teach me to smoke.
Do you have a fresh pack? Let's start with that.
[Takes pack.] OK, now tell me what to do."
Student: "Tear open the pack."
T: [Tears pack to shreds. Cigarettes fly everywhere.]
S: "No, no, tear off the top of the pack!"
T: "OK, sorry, do you have another pack? No? OK, let's just start with this cigarette. [Picks one up.]
S: "Put it in your mouth."
T: [Puts whole cigarette in mouth.]
S: "No, no, just put the end in your mouth!"
T: "Sorry." [Tears filter off, puts whole filter in mouth.]
S: "No, no, don't tear the cigarette, just hold it between your lips!"
T: "Oh, sorry, give me another one." [Places new cig sideways between lips.]
... and so on. You can play the game for a long time. It's hard to give clear instructions, even when you know the domain. Programming will endure for a long long time. -- RonJeffries
I had a friend who could do the Rubik's Cube in seconds.
That made me think of this way of explaining to my manager why did our latest project FAIL!
Olivier takes an average of 10 seconds to completely sort all colors of a 3x3 Rubik's Cube after looking at it for approximately 5 seconds.
If you ask him to make an estimate of how long it will take to sort it, you give him the cube, start the clock and after 5 seconds he will say:
"OK, as soon as I start I will be done in 10 seconds"
you smile and say: "Start!"
After 3 seconds you ask him to stop.. give him another Rubik's cube and say.. sort this one instead...
4 seconds after he starts the second Rubik's cube, how long do you think he will take to sort the first one again?
If you answered 7 seconds approximately, congratulations: You're upper management material!
(and Olivier would be rightly entitled to force you to eat the cubes)
I agree with Simucal in the sense that managers tend to do better when you break a problem into hours, rather than into programming tasks. For example, saying to your boss, "That should take about two hours to complete, but I have a few other things that I have to complete first, so I should have it to you by tomorrow." is a lot more useful than saying, "Well, first I have to design an interface to communicate between objects, and then create the classes to implement the interface, and so on." Managers understand what they can see, so anytime you can explain your task in terms of end-user effects, you will likely have more success.
With that said, don't let your manager intimidate you into making promises that you can't keep. You may know that all they want to hear is "I'll have it by the end of the day.", but if you know it can't be done, don't say that it can, hoping that if you have it to them sometime in the next couple days, that it will be "close enough". If you start factoring in time for designing and testing and give them appropriate estimates, eventually they will start to understand how long it takes to accomplish certain types of tasks, and stop expecting everything to be done by yesterday.
I've also noticed that tangible results along the way tend to put their nerves at rest (temporarily, at least). My boss starts demanding finished results when he starts to panic as to whether or not a task will be completed on time. However, when he is able to "see" the step-by-step progression, then he is more likely to understand that we are, in fact, making progress, even though it isn't in the finished product yet.
Also, as you start this process, try to look at things from their point of view, and understand that until you get to a point where you can spend the amount of time you think is necessary, you may have to find a happy medium. There came a point in my experience where I needed to develop a Cache object, and while I would have loved to take several weeks to design and implement a configurable and extensible Cache that could be widely distributed across multiple applications, I had to limit myself to the task at hand. Just make sure that if you decide to scale back or follow through with a short-sighted design, be sure that it is well-documented so you can go back and fix it when you have time (or so another developer can pick up on the train of thought that you were unable to finish). Also, don't sacrifice good coding standards and style, as this will also make your code easier to maintain and update properly in the future.
Good luck!
This one may be a good book for non-programmers to understand some of these issues and pitfalls of runaway requirements:
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
In all seriousness, I think the best thing it to actually tell them that some things are complex and do require complex problem solving, analysis and design. There is a gap between what they do, and what the programmer does and its unfortunate that they will never understand the full implications. You sometimes just have to be firm and explain that it can take alot of time.
Perhaps a breakdown of the task into subtasks and giving them estimates may help.
Make sure you understand their issues too. People will often bring solutions to the table ("we need this feature") rather than start with root business needs. The more you understand the problem the more likely you are to be able to suggest a compromise.
On occassion I've been told a certain large feature is absolutely essential, but I've been able to deploy much simpler solutions that substantially addresses the problem. Sometimes these interim solutions have grown into vital features, just as often I've been able to remove them two releases later without anybody noticing.
In my experience, whenever I started to explain to sales people in the past why a task takes a certain amount of time, they quickly admit that they do not really want to know the technical details, and I am fine with that. I usually do not want them to explain to me why they still have not nailed down that big sale after n days either. To do work effectively, everybody has his own area of responsibility.
Just make sure that your relationship with the sales people that you provide estimates for is good and they trust in your ability to do proper and reasonable estimations and get the work done. IMHO there should be no need to explain and reason an estimation in every detail, but if there is, I would say the real problem lies elsewhere.
And I wholeheartedly agree with "It depends" above.
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 5 years ago.
Improve this question
I want to avoid the situations when my developers do not share the common knowledge (solutions for the problems they encountered, cool tips, common mistakes, shortcuts for achieving particular goal, configuration issues, partial requirements, etc.) with each others. I'm taking about the situation when such lack of communication is accidental (a result of the misunderstanding or improper management) - I'm not thinking about the situations when developers deliberately keep the knowledge for themselves.
I believe that the following techniques are extremely useful to improve the information flow within the developers team:
XP pair programming - due to the knowledge exchange within the pair (and due to the regular pair mixing).
stand-up meetings - due to the occasion to tell the others on what you're working on and what problems you encountered.
trainings/presentations/coaching prepared by the lead-developers to the rest of the team/department.
"web 2.0 tools" - techie blogs for the company/department, dedicated twitter account of team leader, wiki's and stuff like that.
Any further ideas? What techniques do you use (or did you) in your company? How would you encourage developers to share the knowledge between themselves?
Trust.
You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)
I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc.
It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.
And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.
An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.
Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.
I'll add a few more
Hire the right people - This is essential if you want to create a great dynamic (asocial people require a lot more effort)
Pre-mortem and post-mortem. We use the wiki for this, create a page for each of your projects, split it into section of recurring things (both goods and bad). At the end of each milestone, have the team meet to do a post-mortem. At the end of the project (or after a fix lenght of time), have project coordinator compile this into something easy to read for posterity (and put it on your wiki)
Daily stand-up are a must! You already said it, but I find it so helpful!
If you have multiple teams in the company, organize conference about one of their greatest achievements. If possible on a regular basis, even accros department, you would be surprised how artists can be interested into programmers work.
Lunch is a good time to share, in our company we have the president breakfast, project leads lunch, end of projects supper. I love them all, mix and match for greater results.
Offsite meeting with the whole company is great, we do it at least once a year (morning we present what's coming up in the futur, afternoon, is activities to learn about the projects)
Wikis are great, but beware of informations that can become false over time (this is a reccuring problem with any written informations)
A few more things to my mind:
Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.
Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.
Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?
Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.
I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.
I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.
However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.
For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.
I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.
Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.
This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.
My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.
If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.
There are several requirements for this to work, which are quite easy to attain:
- commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early);
- use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down);
- ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.
Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.
An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.
Time.
Official
Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.
It's also easy to budget: N developers go to meeting for T hours.
Unofficial
"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.
In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.
Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.
Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.
no walls - Have all of your developers in one large, non-walled room - where everyone can see and talk with each other.
common goals - ensuring your team has a good understanding of goals INCLUDING the goal of self-improvement
rewarding - rewarding - even if nothing more then communication - reinforces what you are looking to accomplish
Socialization and common goal always encourages exchanege of information.
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 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.
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
Do you use a formal event to get people talking in your IT department? Like a monthly meetup in a social place, a internal wiki/chat space or just a regular "information market" with some presentations about technology or projects made by your staff for your staff? Do you invite Sales people to participate or is it a closed event for programmers only?
How do you get people to participate in these events? Do you allow them to spent work time on knowledge transfer? Or do you understand it as an integral part of the work time?
I wonder how to monitor the progress of knowledge transfer itself. How do you spot critical one-person spots of failure in your projects? There are several methods to avoid it, like staff swapping or the "fifo" attempt on bug fixing.
Note: Ok, this is a very very noisy question and I hope to fix it after a few comments. Sorry for the mixup.
edit: My personal experience is that there is a very high barrier for people to start contributing. It looks like they won't put in the (minimal) extra time to edit our wiki, or spend the hour in the afternoon to talk about technology topics with the developing staff. It's like people don't like our wiki, our document management system or the meeting. Maybe it's because it's all free-to-use and not forced by the management. But I don't like to force people into it - but is it the right way?
One example: Our wiki holds pages about projects, telling who worked on it to get a first contact in case of questions. But nobody besides a colleague and me is creating this pages...
Knowledge Transfer and Knowledge Management have one drawback. They seem to cost an aweful lot: if everybody knows what I know, am I still needed? All the time I use to bring others up to speed, what do I gain from it?
The best way to go about this is to be an example. Share your knowledge; in a wiki, blog about it, talk about it, make it easily accessible, and talk about the benefits you have from that: less people come to interupt and ask you stuff, as they can get an answer easily without even getting up. And show them that you are still there.
This with all the other things mentioned will actually win out. One more thing: one of my employers kept on paying me 1/3 of my salary for another year after I left (on my own initiative), just to keep my knowledge-base up and running. Did he have to? No, it was his property anyway. But it motivated people still working for him to share their knowledge.
I think all of the above. But you're forgetting the most important way.
The most efficient way to transfer knowledge is to have people work together. You might think about doing 1 on 1 code reviews or even pair programming and make knowledge transfer an intergral part of the work.
I think it depends on the knowledge you are trying to transfer. I've found the following:
Technical Knowledge: "How to guide" with screenshots and a short demo - similar to the way you will see new features at a conference. The added benefit of this is what you have got is documented for when you leave the company.
Problem solving: informal discussions, short internal projects, lessons learned and an internal FAQ system which EVERYONE is responsible for updating.
Soft Skills (people skills): social meetings/outings/informal events etc.
Measuring that is going to be difficult though, as no matter how you transfer your knowledge there will always be varying degrees of uptake, after all, just because I do something one way doesnt mean its correct. Another developer/designer/manager may have a different way of doing the same thing with the same end result.
Mauro
At my workplace we use a wiki. The workplace is small enough (~20 people) so that you can always ask the person who was most involved in a particular project, however it is expected that you have searched on the wiki before you ask "the expert". If you cannot find your answer in the wiki, then you should add it after you have discussed it with your co-worker.
One word: Lunch
You should encourage people about things that you want them to do. You should "feed the animal". Look at stackoverflow; what do you think about badges? Why do you think this wonderful things exist? Thanks to ego, there is nothing you can't get it done. Give them badges, real badges, wearable badges. They will wear with happiness, they will do with happiness.
Btw, yes, I am a boss :)
Although i am still a student, when i did work experience 12 months ago, the all IT departments from within the corporation (I was 'working' for large corporation which own several mines in the area) would have a daily telephone conference, where each employee would say what they had been doing etc, and then talk about something new they had discovered and any other interesting tid-bits.
Couple ways I have seen so far:
Wiki is suitable for internal knowledge, for example environment, project specific topics.
Open doors policy
Encourage asking questions.
Voluntary presentations. Find out who have special knowledge and make it easy and attractive to set up a short presentation about it.
Project post mortem documents. A wrap up meeting moderated by someone outside project team held after project is finished or terminated.
Compulsory presentations.
Project presentation when they go live. Technologies used etc.
In case someone is sent to conference, he should have a presentation about new technology he saw.