Related
I've been a "passive user" of Stack Overflow and other Stack Exchange sites for years. I have derived enormous benefit from it (many thanks!!), and I finally decided to become more active. It seems difficult for a "new" user to get started.
A relatively short time ago, I finally created an account to start answering and editing and posting and commenting! I was full of excitement and vigor and immediately tried to upvote (nope!) and post a comment (nope!). I need (threshold) amount of rep to do comment on this or that, or even upvote certain things... which is totally reasonable (perhaps "necessary" is a better term).
So I browsed a bit (such as whats-reputation). Advice to new users seems to be: just ask, answer, and suggest edits! But there are so many questions and good answers, a truly good question and new question seems hard to create. To truly give justice to all previous questions on a topic requires as much effort (or more?) as posing a question. And there are so many users that to troll-and-pounce the new-questions board could be a full-time job. And BTW, you can only put 2 links in a question when you have <10 rep, so it's very difficult to show due-diligence and to pose a truly good question to begin with!
I didn't find any actual "question" on this topic of how to get started -- but found a few gems like six simple rules, walking a (presumably-intentional) delicate balance between productive debate and provocative cynicism.
So I decided to post a question on this topic! Meta.SO seemed like the right place. NOPE! I needed 5 rep to even post a question. Probably also for good reason.
Now that I have >5 rep (w00t), here I am. After all that background (sorry) --
How does anyone get started around here these days?
My understanding now boils down to the following:
You have no choice but to start slowly.
Be patient and try to do contribute where you can.
Be prepared to accept initial rejection and failure.
Learn how to edit and make stuff pretty.
What am I missing? Do I "get it"? Have I completely missed the point? How can The System encourage new users who are here for the "right reasons" to quickly start contributing meaningfully and harness their energy for the Common Good?
It seems like you get it. Long gone are the days of camping on the front page to gain fast reputation by quickly answering softball questions. The questions are coming in too quickly, site standards have changed drastically, and there's a lot more competition to either answer or close easy questions.
The one piece of advice that I'll give you that you haven't mentioned is to pick some favorite tags that you're an expert in and add them to your favorites list (in the main page right sidebar).
This will highlight questions with those tags when you view the list of Newest questions, and it will even filter the list of selected questions when you view the Stack Overflow home page so that you see more questions with your favorite tags. By focusing your attention on your favorite tags, you'll see more questions that you're interested in and may be able to answer. You'll also be better able to suggest good edits to questions in your area of expertise.
You can also block tags for languages that you don't know by adding them to your Ignored tags list. By default, questions with Ignored tags will just be greyed out, but you can hide them entirely from the Preferences tab in your profile.
If you need a little bit of inspiration, here are a few users that have gained a lot of reputation in a relatively short amount of time, despite not having joined the site at the very beginning:
akrun - Member for 2 years, 6 months with over 220,000 reputation
Wiktor Stribiżew - Member for 2 years, 5 months with over 150,000 reputation
Jean-François Fabre - Member for only 6 months, but already has over 24,000 reputation
What do they all have in common? They answer tons of questions!
There's an alternate route to obtaining basic privileges, if you're finding the competition here too intense.
Utilize the association bonus
If you hit 200 rep on any site, you'll automatically receive a +100 association bonus on all sites. In my experience earning reputation on the beta sites is extremely easy due to reduced competition. Find a topic you have some expertise on, become a valuable contributor there, and you'll quickly earn your basic privileges. Even better, now you're helping out two sites!
Think of it as someone else vouching for your trustworthiness, so don't let them down by coming back here and making a mess.
Take the tour, earn a badge.
If you are reading this, you are probably the sort of person who has the ability to succeed on Stack Overflow. Even so, the tour provides the big picture of how the site ought to work. It also gives you a badge. Another easy badge is Autobiographer, which has the advantage others can learn who you are as a person.
Consider editing.
The next easiest badge to earn is Editor. Anyone may submit a suggested edit for community review. If you find a mistake or outdated information on any post and you know how to fix it, click on the edit link and suggest a change. Editing is a good way to learn what the community expects from posts and also will familiarize you with how posts are formatted with Markdown. In addition, successfully suggesting edits earns a small amount of reputation.
Answering is often easier than asking.
It's almost certainly gotten exponentially harder to ask questions than when many of us earned our (now slightly dusty) beta badges. This chart tells the story:
year questions avg_score deleted_rate closed_rate dupes dupe_rate
---- --------- --------- ------------ ----------- ------ ---------
2008 70372 18.40 6.4 3.9 1145 1.63
2009 394567 6.19 4.5 3.6 4800 1.22
2010 820161 3.43 6.3 3.4 10162 1.24
2011 1445142 2.18 7.9 5.7 21103 1.46
2012 2065664 1.28 10.2 7.9 34471 1.67
2013 2759442 0.61 14.7 10.9 52002 1.88
2014 3040440 0.17 17.9 10.4 68500 2.25
2015 2061746 0.08 17.2 8.7 52759 2.56
New questions are more likely to be closed or deleted than in the past. It's gotten harder to ask questions that haven't already been asked. In the best of times, asking interesting questions is harder than answering them. So I'd recommend looking for questions you can try answering before starting to ask.
If you have a different way of looking at a question, it really doesn't hurt to add another answer even if there's an accepted answer. The goal isn't to just help the one person who asked the question, but to help anyone with that same general problem who might find the question via search. There's no guarantee that your answer will be upvoted, but as long as your answer is accurate, clear, and noticeably different than others, it's not likely to be downvoted.
Consider learning a new language.
There's a good chance that your question in C, C++, C#, Objective-C, Java, JavaScript, JavaFX, or JSF has already been asked. Less popular languages have less duplication and fewer grouchy grognards who have seen the same few questions asked over and over again. Newer languages tend to not reach that level of saturation, so it might be worthwhile to learn a new language for the purposes of getting started on Stack Overflow. Plus it's a great way to teach yourself programming in 10 years.
Debug before asking.
Sometimes, you just need some help solving a problem in your code at which point a question on Stack Overflow would be a good entry point. Don't make the mistake of posting your code verbatim. Instead, search for the handful of lines that seem to be buggy. Surprisingly, doing just that is often enough to discover the problem. If your goal is to participate on Stack Overflow, don't be afraid to ask and answer your own question. Be sure to check for duplicate questions before posting (in which case, consider posting your own answer), but don't feel as if your question is wasteful if you already know the answer. Remember that helping the initial asker is not the primary goal of Stack Overflow.
Learn from setbacks.
You will almost certainly be downvoted at some point using the site. You might get critical comments, have a question closed, or a post deleted. In those situations, it's important to know that:
it's not personal,
there's almost always something you could have done better, and
recovery won't be hard if you take a few minutes to understand what happened.
Far and away the biggest mistake people make when using the site is ignoring advice they don't immediately understand. When people continue to post without learning what those signals are trying to say, they start running into suspensions, blocks and rate limits.
Get help and get meta.
Most of the common problems people run into are answered in the help center. In particular, read how to ask and how to answer. If those don't help, look around on meta for other people who have had the same problem. If that still doesn't help go ahead and ask about your specific situation here on meta. Be aware that meta has very similar conventions to the main site. Much of the above advice applies here too.
Try answering at a time of day or day of week when there are fewer users on Stack Overflow and presumably less competition for answering questions. Yeah, I get that Stack Overflow is an international site and people are on it at all hours of the day, but there are times of the day with significantly less traffic as seen here:
Please note these times are GMT.
See this post for more details.
It appears that Stack Overflow's heaviest users are North America as seen here so the lightest times are when North Americans are sleeping.
I would imagine there are days of the week that are also that are lighter eg Friday
Perhaps it is just a coincidence, but I found this out the hard way. I was burning the midnight oil so to speak and posted a question at the lowest activity time and received no answers.
I started at the end of last year and it was easy enough to rack up a reputation score. I'm a Java expert so I just started browsing the latest Java questions and when I saw a question that looked interesting I posted an answer for it.
A lot of those questions only need a few lines or a paragraph to answer them. My first ever answer wasn't much over 3 lines but I was lucky and got 6 upvotes. My next few answers got 0 or 1 votes but I persisted and over time got better at answering - and as a result the number of votes I started getting for answers started going up.
Don't expect to get upvotes or accepts on all of your answers but it only takes a few upvotes to start removing the new user restrictions. One thing that does help a lot is replying both fast and accurately. With multiple correct answers generally the first one posted will get the upvotes.
It's actually much easier to get reputation on answers than it is on questions. There are always questions in your favorite topic waiting for you to answer them.
There are no limits on how many questions you can answer - so find a way to isolate the questions in an area where you have expertise and then focus on answering the new questions that do not have good answers yet or questions where the existing answers are incomplete. Duplicating existing answers will get you nowhere although sometimes people do post the same answer simultaneously but that cannot be avoided.
Bill the Lizard and Cupcake provide excellent answers. I would just add a few things.
Learn how to identify motivated question askers. If the asker has been responding to comments, he still needs an answer. If he hasn't, he's more likely to have abandoned the question, so you won't get rep for answer acceptance.
Consider looking at bounties, especially on tags where you actually are an expert. Anyone who is spending their own rep to get a question answered is likely pretty motivated to get that answer, and will probably be back to select a correct answer - and also to answer requests for clarification, which can help a lot in producing an accepted answer. It can be worth spending quite a bit of effort to answer these questions; for example, on my most successful bounty attempt, I learned parts of an unfamiliar library for a platform I don't write for, but I got 525 rep for it.
As you allude to, editing questions is a way to grind past the early newbie levels. In particular, lots of newbie questions have unformatted or poorly formatted code; edits that format the code properly are usually accepted and as a bonus are very helpful to anyone who subsequently reads the question.
There's something that isn't really touched on in the other answers, at least that I saw. I read them all but if this is covered in another post, well, oops.
The other answers seem to be focused on how to gain reputation and what not. And if that's your goal, cool, those are great answers.
But if your goal is to really contribute to the community, do your job (or hobby or whatever it is when you're programming) and when you run into something difficult, post a question. I know answers are much better than questions for rep, but for really learning Stack Exchange, you have to be personally invested.
If you go answer someone's question, you might have some attachment to it. Might. But when you ask your own question, it really brings it home. The question that really brought it home for me was this one. I had a problem at work I was given because I was a Java guy and that must mean I knew SQL. But I didn't. But I wasn't one to shy away from the task. So I sought to really understand the problem and thought to myself "I can describe this in English so easy... and this has to be a common problem... but I can't find the solution anywhere with the terms I'm using..."
And then this guy came along and completely saved the day. My manager was super happy, and when I told him I just made a Stack Overflow post, he about had to change his pants. He couldn't believe that someone out there just looked at my question and gave me the code snippet I needed to get my job done right. And so quick - it was about half an hour between asking and having it answered.
And ever since then, it's been personal. It's been "there's people out there with problems, and I want to help them like I was helped." I want to help get people out of a bind (when I can, I find I have stretches where there isn't much time). And if you want to feel driven to help people, you have to know what it's like to be helped. And that means you have to ask questions.
The only useful tip I can add, that I've found to be extremely convenient, in addition to following your favourite tags, is to make yourself a custom Stack Overflow bookmark; it really helps to weed out everything except whatever it is that you are interested in. Mine, for example:
Clicky
https://stackoverflow.com/questions/tagged/delphi+or+c%23+or+plc+or+.net+or+labview+or+assembly+or+x87+or+vb.net?sort=newest
This gives a landing page with posts curated to seven of my key tags and sorted with newest posts on top. Obviously you can customize as desired. It saves a lot of clicking around, and it lets you always drop in on new and active posts. In addition, I find that I'm always learning something new along the way, because nearly every question that shows up is automatically relevant. Also, regardless of how frequently people are posting in a given tag, newer posts almost always need answers more than older posts. This isn't to encourage bottom feeding, certainly, but all other things being equal... you still have to be mindful of what you shoot for.
Read through, pick things that are interesting to you, and just try to answer them. Even if you don't know the answer or even if there is already an answer, just do it anyway - pretend it's a test and you have to come up with a solution; like a personal challenge. Sooner or later you'll be the one coming up with the answer first, best, or both. It's excellent training for general problem solving skills even if you don't get the repuation points most of the time.
It's been seven hours and fifteen days*
It took me nearly three active months to get 2k rep and this thread helped me quite a lot, so I decided to contribute some findings.
I can do whatever I want, I can see whomever I choose*
Choose your favorite tags: Choose a topic you really know something about and have fun thinking and learning about. Be prepared to do some research in order to answer a question. You'll learn a lot. (And earn some rep along the way)
I go out every night and sleep all day*
Take advantage of timezones: You'll observe that most answers happen during certain hours a day, in my Tag when Europe or the States are working. At other times of the day or during weekends there is much more time to prepare a "fast" answer and less competition.
I could put my arms around every boy I see*
Be clear about your knowledge: Don't try to answer each question which sounds somewhat familiar. Only answer when you are sure you are right and you can contribute something useful. There are many smart people around here, you will get bad comments and downvotes when you say something 'silly'.
Tell me baby where did I go wrong*
Accept critique: It is unavoidable to do silly things in the beginning: bad answers, silly comments. You'll get downvotes and bad comments. Try to understand what they try to tell you and improve.
I went to the doctor and guess what he told me*
Imitate: Quite soon you'll discover that people from the same small gang tend to be faster, have better answers and get a lot of upvotes for the same questions you are working with. Try to find out what they are doing and try to do the same. In my tag it is #Jon Skeet: He is always well informed, gives very understandable answers with nice code examples, which are explained in layman's terms if necessary. Just study what he is doing and try to do the same.
I know that living with u baby was sometimes hard, but I'm willing to give it another try*
Don't give up: The very first active steps on SE are hard. In fact the first steps are the hardest. After your first upvoted answer things start to be fun and it becomes easier with every answer you write, later every comment, every edit. Try to survive the first few active days.
* Lyrics by Prince for Sinead O'Conner: Nothing Compares 2 U
Easy steps for getting started at SO.
Read the rules.
Learn the formatting.
Ask questions.
Understand that not even SO is immune from bullying, ignore the ones who are impolite, they are a very vocal minority, but JUST a minority
Enjoy the site
Contribute
Don't be a taker
Build your own rep, but remember, there are people who will vote you down no matter how good your question or answer is. Don't take it to heart. Keep trying until you get the feel for this place.
Use your up-vote power generously when you get it.
When someone gives you a good answer, choose it as the best answer. They get a reputation bump and it is the best way to say "thanks"
Don't take criticism too hard, to those of us who have been doing this for a while, it looks easy, we forget that it's not to a new
programmer, or to one who has switched disciplines.
Start slow, watch, and read. There are some helpful people in here, and there are some who are not, just like everywhere else.
The people here really care about the site. They may seem harsh at times, but it is out of a sincere concern for the site and for the people here.
Just like everywhere else, there are people here who are not helpful, while they are the most vocal, that does not make them the
most numerous.
Be patient. This place gets flooded with bad questions and by people who just want to take what they can get without contributing anything to the site itself. Because of that, they have created a "tiered system" to screen out people who are not serious.
You will not be cut any slack. This is a professional site, you will be treated as a professional.
You will encounter the occasional jerk, if this happens, flag for the staff to deal with, don't get into the mud.
As was already mentioned above, answering is the best way to gain reputation.
Here are some "pro" tips of how to maximize your reputation points per unit of time spent on Stack Overflow, based on personal experience (observing and answering):
Try not to answer questions that you do not understand. Chance is you will not get it correctly, and/or it will take unreasonable amount of time to argue with OP about "what they really wanted". If you feel like the question is unclear, consider leaving a comment, and skipping to the next question. If your comment is later answered, and the question becomes clear enough, and it's still unanswered - now it's your time to give an answer.
Try to only answer questions if you immediately know the answer, or can figure it out in 2-3 minutes by doing a simple Google search + maybe 1-2 minutes sandboxing in your development environment. This way even if you don't get any reputation points (for example, someone did it faster), you've only wasted 5 minutes of your time. It's very unrewarding to spend even 0.5 hour on someone's question only to find out they already accepted an answer, and never bothered to check other answers. This is relevant to the next point.
The faster you answer, the more reputation you can get. This is because other people visiting the question may upvote your answer. You posted late, they've already been to this question and are definitely not coming back just to upvote your answer. There is a caveat - you answer incorrectly - you may get a lot of downvotes. So your initial answer must be fast, precise and actually address the issue in full. You may later edit it and add links to documentation, relevant articles, other Stack Overflow answers, etc. to make it nicer. Don't even try to write a perfect answer from the first attempt. There is a high chance some other user will provide a "fast" answer, which will get upvotes, get accepted, and then you finally post your answer, to find out nobody's there to read it.
When answering a 1-2 hours old question, be prepared to waste your time. If a question was not answered immediately (within 10-15 minutes), and especially if it has no upvotes, or worse - a negative score, there is a high chance (I'd say 90%), you will not gain any reputation here (or get an accept 5 days after and that's it). Unless it takes you 5 minutes to answer (generally when it's a complicated subject, but you are an expert in this area), it's best to move on.
I stumbled on this Q&A and was surprised (or honored :)) to find me quoted in the accepted answer.
I feel I can share my experience in a detailed answer that I had written earlier but seemed to be off-topic for the question so I deleted it.
I think it will be more on topic here, and won't hurt people into thinking I'm providing techniques to accumulate rep unfairly. This still requires a lot of work on the site, and it's certainly not designed to game the system (I deleted some upvoted answers because they were wrong, so no, reputation is not the ultimate goal, it's just a consequence of being helpful)
A few hints to get started & get some reputation/badges on SO. Those are "techniques" I used, but I feel that those aren't gaming the system and are fair.
On the new questions:
You need to be ahead. Being to be one of the first to read the new questions is a real must have (to answer newer questions on popular tags like python, java, C++, C). That means you have to spend a lot of time on the site, or frequently check new questions all along your day.
To be ahead, tune your filters to avoid seeing all questions. You won't be able to follow, and you cannot know all the languages/technologies.
Don't lose time answering crap questions. A question with a score of -4 is very likely to be closed / ignored. You'll waste your time, and won't even get an acceptance from OP who doesn't have a clue (you might get 1 upvote, maybe or some downvotes). And in the meanwhile, you're missing better questions.
For some questions, you have to be a FGITW (be the fastest to answer), but your answer must be spot on. So stay sharp and drink coffee (with a straw so you can keep on typing)
For some questions, it's better to comment, ask clarifications, leave other FGITWs answer (and do it wrong because they actually didn't read the comments). While all bad answers are being posted, hone yours, make it better/more detailed/more performant than the others and post it afterwards. The combination of "a lot of comments" then "an answer" is appreciated by followers, because you took your time before answering properly.
Don't answer obvious duplicates. Instead, vote to close / hammer them if you can. You'll be punished by some (specially if you have a high reputation) by answering. You should know better. Instead, you can answer the "original" question if you feel something is missing. I did that once, and my answer now has a +10 score.
On the old questions:
There's a "new answers to old question" review queue. I think that's where I got my first +1, because I added a above average by answering to an old question and I was a newbie so someone wanted to encourage me.
Of course if you're a specialist of some obscure/less popular tags (like Ada) you'll get upvotes on older answers by followers of those tags / people who have the "active" setting in SO page to see not only new questions, but active ones (which is impossible to follow on the popular tags BTW)
On any question:
Once you posted, edit your answer to add details. If it's already good, you can get upvotes, but enhancing it makes it "active" again, and if it's better you may get more upvotes.
Answer the comments made on your answers. Some commenters upvote if you answer them (better: edit your answer to take their questions into account if worth it). Plus it means that you care.
If you feel it's wrong, delete it, edit it, undelete it. You'll save a stray downvote.
Upvote concurrent answers if they're good (you'll even get a "sportsmanship" silver badge for that eventually). It creates a gap between your score and the other(s) answers, which isn't necessarily bad. Some may even think that yours have not enough votes // the others and that could even play your way (don't do that just to achieve that result, though)
If the question is bad, but you still want to help, you can comment on what's wrong. Doesn't hurt, and you'll get known as a nice fellow.
Don't answer like you would comment. If you don't feel like answering, then don't, and just comment.
Also upvote the good questions. That'll make them visible, only if it's worth, not to indirectly promote your answer. A lot of people forget to do that. Good questions need love too.
A bonus: by keeping a spotless behaviour (asking for precisions in comments, be reactive to comments, helping some users with typo questions by commenting on the error "for free", not answering turds, not answering obvious dupes, closing as duplicates with a small personal note to the OP, creating excellent answers,being nice most of the time :)) you may get unrelated upvotes: people wanting to upvote you twice (not recommended, but not serial voting yet), people visiting your profile and finding other good stuff you wrote in the same style and upvoting it)
Asking (good) questions & answering on meta also proves that you care for the site, not only for the rep. That can have strange effects (I frequently get downvotes on my questions after posting on meta, but upvotes on some answers at the same time!!), but globally it has a positive effect on your "reputation" (the one you don't measure with points). Can't hurt.
Gaining a couple of reputation points is not all that hard if you know enough about a certain topic. Just filter for it and start helping people out. A lot of times there is plenty of stuff to add, even if a certain question is answered. Elaborating on a very old question is a good way to earn reputation points and improve Stack Overflow and Stack Exchange. Once you have those 10 reputation points you can edit and improve your own answers with more links.
If there are no more questions you can answer or improve and there are no more questions you can ask, then I'm wondering why you want to get started here. If you can not improve there is no reason to get started. On the other hand, I'm a novice hobby programmer, and I can still help out people here and earn some reputation points when I am active enough. I am sure everybody with some knowledge can improve Stack Overflow and Stack Exchange.
Finally, this site is about putting up good questions with good answers attached to them and not about earning reputation points or some kind of reputation points challenge. Just start, gaining the first 10 reputation points is a cakewalk and from there you can do everything Stack Overflow and Stack Exchange is intended for.
Edit question, +2 each time suggested edit is accepted => 25 edited questions for reaching the magic 50 threshold
Fact is if your domain of expertise is C++ or Java or any super well known domain , it is almost impossible to find a good enough question not answered/accepted, and if you pick up the newest, it will be answered before you have sent your response.
But there are thousands of questions out there that can be improved. Most of them have some Tags missing or some Tags not relevant.
Somes can be improved to help understand the issue.
I was full of excitement and vigor and immediately tried to upvote (nope!) and post a comment (nope!).
That's indeed the main problem with the blessed site of Stack Overflow. People take this site as fun, as a game, as anything but sharing knowledge.
So, I'd tell you how to really start.
Register.
Start answering.
NEVER read the question body, but only tags and title
Write an answer that just looks like a good one (preferably just copy and paste some code snippet from manual, or other answer, if you want to bring some explanation along), but has no real relation to the problem.
Get deserved and hard-earned upvotes a ton
Don't be afraid of getting some downvotes - as long as your answer looks like a good one, the only downvote you can get from someone who have a clue and time to bother, but such people are scarce. Yet for every downvote you will get a comforting upvote - this site is for fun and happiness - remember?
Start your desired "activity" with votes, comments and unicorns. That's the real fun and purpose of this site.
Enjoy!
Apparently my old advice was SO bad, it wasn't even good, it was just bad.
So, here is what NOT to do under any circumstances:
1. Write 'Any help would be greatly appreciated' at the end of each question, because that's obvious.
2. Do what I did, and pretend that someone's comment was helpful just to influence them into re-upvoting your question, even if it does give you better rep. Stand up for what you really think! It's better for the community.
3. Ask a question that you haven't researched, especially one that has a good answer on the very same website (you might embarrass yourself, or make people unreasonably angry).
Here is what you should do:
If someone answers well regarding a piece of code, but you realise that what you posted was a much simpler version of what you're actually attempting, and you now want active help for your HARDER piece of code, just post another question instead of editing your old one. It's not cheating! Someone told me this and said my EDIT was a completely different question, and more people would notice it if I dedicated it to a new question.
If programming, then post your precise error - it's easy to do, and it's really hard to get any sympathy without it.
Be concise with your English. It makes a difference: e.g, 'it is important to note that I have already tried X, Y, and Z' could be said as 'I have already tried X, Y and Z'. Or, 'overly complicated' could be said as 'too complicated'.
Also, don't include anything that DOESN'T help people answer your question. For example, backstory. No-one cares. This is an exaggeration, but e.g, 'I've been doing this really hard project at this workshop with an old version of X and we're not allowed to use imported modules for some reason, other than X, and it's taken me ages and I feel like I'm missing something totally obvious; lots of people I know seem to have managed it just fine, but by the way, I was never quite sure if it would be better to do X, Y, Z' will probably alienate your audience. Also, don't say 'I'm really a beginner, I only started python X months ago', because you may as well say 'I don't know anything, I'm so sorry, I'm completely wasting your time'. It's not going to make people answer your question any better.
I believe answering those questions which you feel comfortable with. Favorite tags will present you specific set of questions.
However, if you genuinely feel an urge to answer a question out of knowledge or interest, then you can go ahead. Don't worry about an up vote or reputation. If you are engaged in a programming language, you yourself got some errors at that particular time, but you resolved it with the help of Google or Stack Overflow. Try to answer such questions, which you are very sure of.
I don't think it is necessary to answer on a daily basis. Unless and until it's within your helping range, don't go for it.
You should first ask yourself why do you want to join this community.
Figure out weather this is a community you want to be part of. Spend some time and research the type of people that are active contributors here (especially the elitists that run this site). Make sure you take your information from sites that are not under the stack exchange umbrella, since the content of those sites is moderated.
In hindsight, that would've made a huge difference, at least in my case.
So, to sum up and answer your question, the first thing a new user that wants to join stackoverflow should do is to understand what he's getting into. Failing to do so will result in a lot of wasted hours.
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 13 years ago.
Improve this question
We've all been there. You have written some code and unit tests, the tests all pass, and the code is decent (nothing's perfect, right?). Then, someone who is sure that they know better than you comes along and decides to change your code or the interfaces to your code just because he/she does not like the variable/class names that you used. No "real" refactorings, no real optimizations, no real improvement -- just different words -- not necessarily better words, just different.
My real problem with this is that (a) its a waste of time and (b) it shows a blatant disrespect for the fellow developer that wrote the code in the first place.
My visceral response is to lash out, but that's counter productive. Instead, I though that I might wright a paragraph or two as sort of a "Charter" or "Philosophy" that is adopted for the project. I'm wondering if anyone else has tried this, and if so, was it successful?
After looking at the initial comments below (which are appreciated), I think that my problem is primarily that this change broke the build for code that was already working. So time needed to be spent to fix the code for what was (in my opinion) a non value-added change.
-- Thanks
...decides to change your code or the
interfaces to your code just because
he/she does not like the
variable/class names that you used.
My real problem with this is that (a)
its a waste of time and (b) it shows a
blatant disrespect for the fellow
developer that wrote the code in the
first place.
My visceral response is to lash out...
I see some VERY CONCERNING things in those statements.
naming is REALLY, REALLY important. It is worth rewriting code to get it correct.
It is not YOUR code
How is it disrespectful?
You are taking it too personally.
I once worked with someone who freaked out when I made changes to "his" code. His code as horrible; it was buggy and unmaintainable. He was always staying late, fighting fires and breaking things - basically a negative contributor. I rewrote all his bad code for a big piece of functionality for a project one weekend and when he came back in on monday had a hissy fit. I am not saying your stuff is horrible, but maybe you need to calm down and be more objective about it.
Don't take it so personally. Step back and think about it - maybe "your" code needed fixing
We might be able to give better answers if you posted the code and changes, or at least some better idea of the situation with an example or two.
EDIT:
After seeing the code change and finding out that the build was broken, I am going to have to change the tone of this answer. I understand Steve's frustration - and i agree - that is not a good change. It makes a specific typedef more general and not very descriptive any more.
While I think some of my points are valid, in this case it looks like the changes were not appropriate.
The issue of code "ownership" is irrelevant. If the code changes are useless then everyone on the team should not be happy. If they are good changes then everyone should be happy about it. If there is a difference of opinion then you all need to find a common ground.
Breaking the build is not a good thing.
Steve, sorry if I came down harsh - it looks like in this instance you are justified in your frustration, but not because it is "your" code.
One thing that might help in this sort of situation is to require code reviews for all changes. People are less likely to make pointless changes if someone else has to review it first. If they can actually convince another developer that their change should go in then maybe it isn't so pointless after all.
Heey,
Guys! WE all need TO TALK!
Just sit together and TALK! There are always reasons to change and there are always reasons NOT to.
Decide together!
Don't just go to StackOverflow or a forum and say ask this kind of questions.
The new dev does it - he gets responses from community probably positive (yeahh, bad code should be refactored).
The current dev does it - he gets responses from the community too: "What an idiot could do such kind of changes!"
And the result is: Counterproductive, destructive, offensive environment for a long time.
Who wants it?
Just put your arguments on the table and that's it.
New dev needs some introduction too.
Old dev needs to listed TOO.
This should be collaborative work AND not pissing each other off.
Decide together, talk, as THE TEAM.
And... better ask questions like "How is it better to refactor this?"
Cheers.
In any software development team with a size > 1, standardization is key. Not only for each developer to understand the other's code, but so that the people that come along in 2 years, 5 years and 10 years can look at any part of the code and see a clear and consistent pattern. Will you... and the rest of the team... seriously still be there, working on this project, years down the line?
If you both "just have your way of doing things" and there is no formal standard for the project/company, I suggest you work with the team and/or your boss to suggest a formal standard be adopted. There are many standards already published for the various environments that you can use either as the standard, or as a starting point.
If there is a formal standard, everyone on the team is obligated to follow it... no matter how much "better" they think their way is.
So much for the hard skills.
Now on the soft skills side...
You and your colleague need to develop a healthy relationship, or decide to work in different places. Tit-for-tats that result in people feeling that they want to lash out will make everyone unhappy, not to mention gravely jeopardize the project everyone is being paid to complete. Look for a person you both respect (maybe your boss, maybe a respected and level-headed senior member of the team, maybe HR if you have a good HR department). Explain to that person what the problem is and that it makes you feel unvalued and disrespected. Ask for help talking through the situation with your colleague and agreeing to a better way of working together.
Finally, you need to be open to the possibility that your colleague may be making subjectively correct changes, even if the manner he's doing it in offends you. Separate the correct coding from the correct interpersonal interactions. Do the right thing for the project.
Well if that guy is going to maintain your code, let him do whatever he wants to.
Just remember that it is not "your" code. The code belongs to the company for which you work for. You wrote the code and you got paid for it. Let the Management do whatever they want to do with it.
Don't take things personally, move on.
Sometimes, changing names might be justified. It can be confusing if half the project refers to a person's sex, and then you check in some new code that refers to gender or something. Okay, this might be a bad example as technically they are two different things and their meaning is most likely still obvious. But if a project's code uses two different terms to refer to the same concept, it can be confusing.
Usually I try to leave people's code alone, unless I have some justification for refactoring. Luckily the same seems to go for my colleagues, so no, I have not had the need for writing such a charter yet.
How about using an automated build system, so when this person changes the code and breaks something the team will get an alert about it. This solves your problem with having to waste your time fixing something broken by someone elses change to your code. This way everyone will know that so and so made a change and broke the build, and can see for themself. The rule is "dont break the build".
You should be discussing this with the person who did it, in a non-threatening manner.
I believe every developer should take responsibility and hence own some of the code, but not all of the code. I understand the code that I've written better (irrespective of how good/bad it is) than any other guy that has ever seen it. Therefore the changes I make will be faster and less prone to error.
I don't mind anybody changing the code I've written later on, but I have a couple of conditions:
If you change the code and that causes something else to break, you are responsible for fixing it, not me.
If I don't agree with the changes you made I will change it back to the way I want it since I have to take responsibility for this piece of code in future.
Not all developers should be making changes to all the code, all the time. Only some of the time, for the purpose of getting to know the code (sharing knowledge).
I've never worked for an employer that endorses a "everyone can change anything any time" policy. Developers own certain parts of the code and they are asked specifically to make changes/refactor based on a development democracy.
You touch my code and break something, (1) you better have a good reason for the change that all developers agree with and (2) you better not leave broken things broken or ask me to go do the clean-up for you UNLESS you're my superior. I will humbly submit if that's the case.
I agree with Laurence that code reviews might help. This is an issue of how your team should work together. What might help is the notion of Egoless Programming - in a nutshell, considering the code as a joint product of the team, and trying to make decisions for the sake of the code rather than because of the programmer's ego. Your teammate violated the fourth commandment of egoless programming - "Don't rewrite code without consultation."
Maybe if your team is made aware of these principles, things will improve. I would try this.
Perhaps not completely on topic, but .... If you have developers who have the time to make changes to code just because they don't like the variable names used, then maybe the conversation should be about whether you have too many developers and which ones should be shown the door ... or how you're going to justify to management the bloated staff you have, especially in the current economic circumstances!
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
During hiring a .NET web developer I give the candidate a coding test.
I tend to limit the candidate to MSDN installed on the test server - I think it holds everything the candidate needs to complete the task.
I admit, this is not the normal case as I don't expect the candidate to do his work without use of the web.
On the other hand I don't want the candidate to google for a complete example and copy-paste it, i want to evaluate his skills.
The question is do I need to allow free use of the web during the test?
If you think the whole coding test is wrong - I would like to hear alternatives you may have for me.
As you say, 'I don't expect the candidate to do his work without use of the web' why not allow it too during the test? And what if he does copy and paste? I do that too. Surely the key is to know where to look, be discerning with what you find and apply it intelligently. Do you want to hire someone with a terrific memory or someone who can develop software for you?
When I was at school, calculators were just becoming affordable. As their use was seen as unavoidable, the exams were changed. Simple number-crunching was no longer tested in the way it was before (it was important then). Rather problem-solving techniques were to be tested.
I usually allow candidates to use whatever resources they want. After they're done, I sit down with them and go through their code together, ask questions like why they chose that particular approach etc.
If a couple of minutes of Googling was enough to not just copypaste some code but to learn enough about it to be able to defend the decisions within, then he's intelligent enough!
There are tests, where web access can be given, and there are where it doesn't really make sense.
Case where its fine to allow web access
When its unlikely to find even 60 percent of the code over the net
When you will ask to explain the code after he/she completed the code
A very specific solution using SQL query, which is unlikely to be found on the web
Case where its fine to not allow web access
Some basic programs like, recurssion, fibonacci, factorial, string manipulation, small trick programs, etc. There is no need of computer even in some of these cases
I'm very sceptical about coding tests during interviews. I think that a lot of the test I have seen, represent very specific (artificial, non real-world) problems where you would use the internet to solve them.
I think it's not really important to know how to solve such problems by heart - often time it is much more important that you know how and where to search for answers.
If you want to test the persons during the interview, I think it is better to ask them some conceptual questions instead of a specific programming problem. E.g: questions about object orientation, polymorphism, design of n-tier application, etc. etc.
Or as an example from the ASP.NET world, ask the interviewed person question such as: what is ViewState, what is a postback, what is session-/application-state, etc.
If you want to get an idea of how a candidate will perform in a job, I think it's best to try and make the conditions of the test as close as possible to the actual working conditions.
It should be pretty easy to prevent copy-and-pasters from slipping through the cracks by asking the candidate to explain his/her code.
Well, one thing you want to be aware of is that the developer you hire might not know everything that he will be thrown during the time he is working for you. If you ask him a question that he doesn't know off the top of his head you would want and expect him to research it and come back to you with proof that he understood the concepts that he just learned.
I say let them use the web - but ask them to explain in their own words how their code works. Most of my knowledge comes from online resources. However, I make sure that every line of code I write I understand.
There is a baseline knowledge that developers in a particular field should know; but you also want to figure out how quickly he can learn new things. A good test IMO is to throw a question you know he doesn't know and see how long he can figure it out using the resources he would have if he were an employee of your company.
Is your goal to see what basic knowledge the candidate has and if he can code without copying solutions from the web, then don't allow internet access. If you want to see what strategies he employs to get to a solution, let him use the web if he wants to.
I personally find it more interesting if a candidate can solve problems on a larger scale than just solving a simple programming problem. So I tend to ask him about the methods he uses when programming (Unit testing? Ever worked with it? What do you think of it?). This gives me a better picture than coding in an interview situation.
Sometimes it helps if you ask the candidates beforehand to bring a one-page coding sample to take a look at their coding style. This also saves you time during the interview.
It's important to make sure a candidate is resourceful - you don't want your programmer sitting there when they get stuck, not moving forward; you want them to use whatever resources are at hand - be it MSDN, picking someone else's brains, using the web, etc - to get the job done. Cut-n-paste from the web does seem like cheating, but (a) if you design your task carefully then it will be unique enough for there not to be a standard answer they can copy from the web, and (b) isn't re-using existing code a key part of building software? It's not much different from using 3rd-party libraries, to avoid reinventing the wheel. On the downside, of course, you also want them to show they can develop algorithms, so the unique task needs to include some element that requires that without the solution already being on the web. Trouble is, forums are the achilles heel to all of that since they can simply ask for the solution and someone, somewhere, is going to hand over the answer unwittingly!
Allow the candidate to use the web but tell him beforehand that if he used the web, you will have to evaluate HOW he solved the problem.
If he used the web for something simple such as finding the syntax or parameters which he forgot, don't mark him down. This is normal.
If he used the web for something like look at how a specific function is used, don't mark him down. This is normal.
If he searched for a specific code and then copy-paste it, then ask him about how the code works. If he can explain how the code works, then there's no reason to mark him down. If he can't explain it without looking at the site where he got the code, you have to mark him down.
If he used stackoverflow.com, check his profile for questions, answers and badges. From there, you can check how good a programmer he is.
It all depends what you want out of your successful candidate. I contest the view that knowing how to google makes you a good programmer because the simple fact is that the internet is full of bad examples as well as good ones. You don't really want your codebase to reflect how lucky your googler was on the day he cut and pasted all his code off the web. You want it to demonstrate sound practices, proven methodologies & elegant, efficient solutions that your team understand and are enthusiastic about. Not a jumble of styles that don't resemble each other. There's a wealth of good to be gotten from knowing how to get help from the interweb but real knowledge and ancient wisdom is being lost every day that people who don't really understand what they are doing are given jobs because they appear to solve problems with their ability to "google it".
If you really want to give your candidates access to the web then by all means do, but make the questions hard and scrutinise the results to see if they've picked the first solution they found or if they've picked the best solution to the problem.
As do many other respondents, I'd rather employ a resourceful developer who know how to use the web to the fullest to draw on other's experiences and previous work, than a developer who limits himself and his applications to the MSDN way of doing things.
I copy other peoples code all the time - daily in fact. The knack of it depends on finding the right solution quickly and integrating it into your existing work.
So let your candidate use the web and ask him how he came to his solutions. You might learn more about him from his methods than from how will he can remember previous solutions.
Three things I'd do.
Let applicants send in a coding example along with their cv.
Let applicants produce some real-life code (maybe even pair-program with a developer on your team) this will show you if they can actually use the tools. Internet is a tool too so they should be able to use internet.
Let applicants solve a problem in pseudo code on a blackboard during the interview. In this case you can be their "internet" by helping them.
These three approaches will show you different things. The first is a good early warning mechanism but can easily be faked (they could just download oss code from the web somewhere). The second is good to see if they can actually code but they might score badly if they're unfamiliar with the tools you use. The third will show you if they can solve theoretical problems but won't show you if they actually are good team players or if they write maintainable code.
I recently had a friend start talking to me on IM, he was in a coding test job interview. He had a couple SQL questions. At first i thought, hell you've got to do this yourself. I'm not going to help you cheat during an interview.
Then i thought about it again. I've been answering questions and talking to him about various technical issues for years on IM as part of his work. So when he encounters problems in the real world with the job if he gets hired, he'll do the same thing.
We don't talk about it much, but having a good network of friends to ask questions, and knowing how to search out relevant answers on the net are a big part of being an effective programmer or sysadmin. I've met people who were super smart programmers, but didn't really know how to find information online. They missed a lot, were kind of out of the loop. Knowing how to use resources should be important.
When i do interviews i often ask people what websites they read, what development tools they use, and why. It's a similar thing. Sure it's not about how they write x line of code, but it's about how they work.
No how to get around somebody just copy and pasting "answers". Well first, don't ask questions which have pat answers. Secondly when i'm interviewing i like to give people some code, ask them to refactor it, have them talk through what they are thinking. Then ask them to write some new code which implements a feature. Pair program with them. It's hard to hide inability to code when pair programming. While they are pairing, it totally makes sense to say, "let's go look up the api on the date time library."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We're neck deep in a project right now, schedules are tight (but reasonable). Our general strategy is to get a strong beta done, release it for testing, and get feedback from our testers.
Quite frequently, we're being hit by small things that spiral into long, time-costing discussions. They all boil down to one thing: While we know what features we need, we are having trouble with the little details, things like 'where should this message go' and 'do they need this feedback immediately, or will it break their flow, so we should hold off'?
These are all things that our testers SHOULD catch, but
a) Each 'low priority' bug like this drains time from critical issues
b) We want to have as strong a product as possible
and
c) Even the best testing group will miss things from time to time.
We use our product, and we know how our users use the old version...but we're all at a loss as to how to think like a user when we try to use the new version (which has significant graphical as well as underlying changes).
edit - a bit more background:
We're writing a web app used by a widely-distributed base of users. Our app is a big part of their jobs, but not the biggest (and, of course, we only matter to them when it doesn't work). Getting actual users in to use our product is difficult, as we're geographically distant from the nearest location that serves as an end user (We're in Ohio, and I think the nearest location we serve is 3+ hours away).
The closest we can get is our Customer Service team (who have been a big help, really) but they don't really think like the users either. They also serve as our testers (it really motivates them to find bugs when they know that any they DON'T find may mean a big upswing in number of calls). We've had three (of about 12 total) customer service reps back here most of the week doing some preliminary testing...they've gotten involved in the discussions as well.
Watching someone using the app is a huge benefit to me. Possibly someone who is not entirely familiar with it.
Seeing how they try to navigate, how they try to enter information or size windows. Things we take for granted after creating/running the app hour after hour, day after day.
Users will always try and do things you never expected and watching them in action might bring to light how you can change something that might have seemed minor, but really makes a big impact on them.
Read Don't make me think.
Speaking generally, you can't. There's not any way you can turn off the "programmer" part of your brain and think like a user.
And you're right about (c), testing groups don't necessarily catch all the bugs. But the best thing you can do is get a testing group comprised of real, honest-to-goodness end users, and value their feedback. Draw further conclusions from their general comments.
If you want to know how your users will see your system, the closest you can get is usability testing with real users. Everything else is just heuristics and experience, and is also subject to error. There's no such thing as a bug-free product, but you should be able to get a "strong" product with usability testing.
Buy a cheap, easy to use video camera and record your testers using the app. Even better, get some people unfamiliar with the app. to use it and video them. It's relatively cheap, and you'd be surprised what it will highlight.
I like policy of "eating your own dog food"("http://en.wikipedia.org/wiki/Eat_one's_own_dog_food). It brings you one step closer, because you become a user, although you might think like one.
Try to use your app when you are very hurry (e.g. you have someone who waits for a dinner).
You will see all this little things because you have to wait, you have to go back to the mouse of the keyboard, etc.
And also, make your wife use it. Or your mother.
Another useful test : help someone to use it, by phone. If he can't find the button with your directions, that's probably a bug.
The important thing is to get enough information that you yourself can become a "user". Once you do that you can answer most questions yourself.
The way I always do this is to go talk with them about what they need to do, what they typically do, and how they use their current tools to do it. Then (very important) sit with them while they do it. Make sure you get on with them well enough that you can come back to them with questions about how they handle edge cases you think of later (often the answer will be the appalling "we go around the system manually for that").
I will almost always notice something they are doing that is a royal PITA that they didn't bring up because they are used to having to do that and don't know any better. I will always notice that their %90 typical workflow isn't the easiest workflow the tools provide.
You can't really rely on plain old-fashioned requirements gathering by itself, because that is asking them to think like a developer. They generally don't know what is possible to do with your software, what is easy, and what is hard. Also they typically have no clue on GUI design principles. If you ask them for design input they will just tell you to put any new control on their favorite page, until the thing looks like a 747 control panel.
The problem is often that even the users don't know what they want until they are actually working with the software. Sometimes, a small oversight can be a big usability problem, sometimes a well thought out function that was requested by many users sees only little use.
My suggestions to decrease the risk of not implementing the right usability features:
Take a look at users actually doing their day to day work. Even if they use another software or no software at all. You will be able to determine the artifacts they often need to get their job done. You will see what data they frequently need. Concentrate on the artifacts, data and workflows most used. They should be the most usable. Exotic workflows may be a bit more time consuming for the users than often used workflows.
Use working prototypes of the GUI to let users work through a realistic workflow. Watch them and note what hinders them and what works well. Adjust your prototypes accordingly.
If an issue arises in an often-used part of your software, it is time to discuss it now and in details. If the issue concerns a seldom used part, make it a low priority issue and discuss it if you have the time. If issues or suggestions are low priority, they should stay low priority. If you can't determine if solution A or solution B is the best, don't run in circles with the same arguments over and over. Just implement one of the solutions and see if the beta testers like it. The worst thing you could do is waste time over tiny issues, while big issues need to be fixed.
A software will never be perfect, because the viewpoints of users differ. Some users will think that a minor problem breaks the whole application. Others will live with even severe usability issues. People tend to lend their ear to those who argue the loudest. Get to know your users to separate the "loud" issues from the important ones. It takes experience to do this, and sometimes you will make wrong decisions, but there is no perfect way, only one of steady improvement.
If you can, set aside a certain amount of usability development resources for the rollout phase of your software. Usability issues will arise when people start working with it in a real production environment. Sometimes it is not important to present the perfect software, but to solve issues quickly as they arise.
The flippant (yet somewhat accurate) answer to how to think like a user is put a knitting needle in your ear and push really hard.
The longer response is that we as programmers are not normal and I mean that in a good way. I scratch my head at the number of people who still run executables they receive from strangers in emails and then wonder how their computer got infected.
Any group of people will in time develop their own jargon, conventions, practices and expectations. As a programmer you will expect different things from an operating system than Joe User will. This is natural, to be expected yet hard to work around.
It's also why BAs (business analysts) exist. They typically come from a business or testing background and don't think like programmers. They are your link to the users.
Really though, you should be talking to your users. There's no poitn debating what users do. Just drag a few in and see what they do.
A usability test group will help.. tests not focused on discovering bugs, but on the learning curve of the new design, made by a group of users, not programmers.
I treat all users like malicious idiots.
Malicious because I assume all users are going to try and break my code, do stuff that is not allowed, avoid typing in valid data, and will do anything in their power to make my life hell.
Idiots because again I can't assume they will understand simple stuff like phone formats, will run away screaming if presented to many choices, and will not make any leap of faith on complicated instructions. The goal is to hold their hand the entire way.
At the same time, its important to make sure the user doesn't realize you think they're an idiot.
To think like a user, be one. But are these actually bugs that your testers are reporting? Or are they "enhancement requests"? If the software behaves as designed per requirements and they just don't like the way it operates, that's not a bug. That's a failure of requirements and design. Make it work, make it rock solid, make it easy to change and you'll be able to make it what your users want.
I see some good suggestions here, especially observing people trying to use you app. One thing I would suggest is to look at the order in which things are presented to the user on paper forms (if they use these to do data entry from) and make the final data entry page mimic that order as closely as possible. So many data entry errors (and loss of data entry speed) are from them having to jump around on the page and losing their place. I did some work for a political campaign this year and in every case, entering data was made much more difficult because the computer screen did things in a differnt order than the paper inputs. This is particularly important if the form is one that can't be changed (like a voter registration form, a campaign has to use what the state provides) to match the computer screen. ALso be consistent from screen to screen if possible. If it is first Name last name on one form, making it last name first name on the next will confuse people and guanteee data entry errors.
If you are truly interested in understanding users though I strongly suggest taking a course in Human factors engineering. It is an enlightening experience.
The 'right' way to do this is to prototype (or mock up) your new interface features, and watch your users try to use them. Nothing is as enlightening as seeing a real user try to use a new feature.
Unfortunately, given most projects time and resources, this is not possible. If that is the position you are in I would recommend you discuss in the team who has the best grasp of usability, and then make them responsible for usability decisions - but that person will need to regularly consult real users to make sure his/her ideas are consistent with what the users want.
I'd suggest doing some form of usability testing; I've participated in such in the past, and found them quite useful.
If you were writing a ticketing system, for example, bring up tasks, and ask questions like "how would you update this ticket" or "what do you expect to happen if this button is clicked".
You don't necessarily need a full application, either, in some places screen shots can be used.
You could take the TDD/BDD approach and get the users involved before beta, having them work with you on refining requirements as you write your unit tests. We're beginning to incorporate some of those trends into our current project, and we're seeing fewer bugs in the areas where we have involved the users earlier.
There is no "think like a user" technique, get your hands on someone who knows nothing of the project and throw what you have done at them.
It's the only way to see how the look + feel + functionality present themselves to the end user.
Once you shocked that person who knew nothing of the product, listen to all of their idiotic (or so you think they are) complaints, fix them, arrange every silly cosmetic thing they point out (either by fixing the UI or by improving whichever documentation you had)..
and after you have satisfied the person you chose to look at your app from zero knowledge on the subject first round, pick another ...and another... until they stop being shocked when they see it, and they don't get stuck on.. "ok.. what does this do?" kind of phases.
You (as a member of the project, be it the project manager, developer, etc) will never think like a user is my answer to that question.
Old saying: You can make something "fool proof" but you can't make it "Damn-fool proof".
Additionally: When you make something "idiot proof" the world invents a better idiot.
Other than that, I agree with what everyone else said.
Ask someone with absolutely no knowledge, insight or programming experience to use the program and try to figure out every function of the program.
People who would NEVER use such a program are most likely to find bugs.
See it as a new Safari user (or FF) who tries to put the URL inside the search field...
As a programmer you guess no-one would be that stupid (or, well.. unknowing), but people actually sometimes find themselves in these situations. As a programmer, we miss these things.
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 work on a complex application where different teams work on their own modules with a degree of overlap. A while back we got a Mediawiki instance set up, partly at my prompting. I have a hard job getting people to actually use it, let alone contribute.
I can see a lot of benefit in sharing information. It may at least reduce the times we reinvent the wheel.
The wiki is not very structured, but I'm not sure that is a problem as long as you can search for what you need.
Any hints?
Some tips:
Any time someone sends information by email that really should be in a wiki, make a page for that topic and add what they put in the email. Then reply "Thanks for that info, I've put it into the wiki here so that it's easier to find in the future."
Likewise, if you have information you need to share that should be in the wiki, put it there and just send an email with a link to it, rather than email people.
When you ask people for information, phrase it so that putting such documentation in the wiki should be considered the default or standard: "I searched in the wiki but I couldn't find it. Have you put that info up there yet?"
If you are the "wiki champion", make sure other people know how to use it, e.g. "Did I go through how to create a new page with you yet?"
Edit the sidebar to make sure it is relevant to your work.
Use "nav box" style templates on related pages for easier navigation.
Put something like {{Special:NewPages/5}} on the front page, or recent changes, so that people can see the activity.
Take a peek at Recent changes every few days or week, and if you notice someone adding information without being prodded, send them an email or drop by and give them a little compliment.
As I mentioned before, a Wiki is very unorganized.
However, if that is the only argument from your developers, then invest some effort to create a simple index page and keep it updated (either do it yourself or ask people to link their contributions to the index). That way, the Wiki might grow into a very nice and quite comprehensive collection of documentation for all your work.
We've been using a wiki in some form or another for a while now, but it does take a while for people to get on board. You might find that you will be the only one writing articles for some time, but bear with it, other people will come on board eventually.
If someone sends an email around that contains information related to the project then helpfully point them in the direction of the wiki - and keep doing that - they should get the hint.
We have a SharePoint portal and use the wiki from there - we customised it with our own branding so that it "looks the part" - I really feel this has helped to improve the uptake of it.
Make sure that everyone is aware that the wiki is even more informal than email.... because there will be a "fear factor" that people may think anything they add to the wiki will be over-analysed.
I think most of the answers so far are spot on - the more you plug away at it yourself, the larger the body of useful information will become, so slowly but surely people will naturally start to use it.
The other approach you could use is this: Suggest that every time someone asks another team member a question about the project, they should answer the question as normal, but also add the answer to a section of the Wiki. This may take a few minutes extra, but it will mean that the next time someone asks the same question (which they inevitably will), you can save time by pointing them at the Wiki. This, in turn, should help people to start using the Wiki as a first source of information and help overall up-take.
You can't force developers to do something they do not have an incentive of using for; unfortunately wikis, like documentation (well, in fact wikis are documentation) rarely have any "cool" value for developers. Besides, they're already deep into dev work -- could you really bother them with a wiki?
That being said, the people who pushed for the wiki (e.g., you) should be primarily responsible for updating it, and you really would have a lot of work cut out for you if you're serious about it.
You might also try the ff:
It's not very structured you say -- a lot of people get turned off from ill-structured (hard-to-search/browse) wikis. So maybe you can fix that first
Maybe you can ask lead developers/project managers to populate it with things that are issues for them: things like code conventions and API design for your particular project
Lead by example: religiously document your part of the system. Setting a precedent may encourage others to do the same
Sell the idea of using the wiki to the developers. You've identified some benefits, share those with the developers. If they can see that they'll get something of value out of it they'll start using it.
Example advantages from What Is a Wiki
Good for writing down quick ideas or longer ones, giving you more time for formal writing and editing.
Instantly collaborative without emailing documents, keeping the group in sync.
Accessible from anywhere with a web connection (if you don't mind writing in web-browser text forms).
Your archive, because every page revision is kept.
Exciting, immediate, and empowering--everyone has a say.
I have done some selling and even run some training sessions. I think some people are turned off by the lack of WYSIWYG editing and ability to paste formatted text from Word or Outlook. I know there are some tools to work around these, but they are still barriers.
There are some areas where the wiki is being used to log certain areas, but people who update those are not doing anything else with it.
I will use the wiki to document my specialised area regardless as it acts as a convenient brain extension. When starting a new development I use it as a notepad for ideas that I can expand on as it progresses.
It would help if management would give it some vocal support, even if it is not made mandatory.
I have a hard job getting people to actually use it, let alone contribute.
One of the easiest ways to get people to contribute to a wiki, is to actually have them provide contents in a wiki-suitable fashion, i.e. so that whatever they post using their usual channels of communications (newsgroups, mailing lists, forums, issue trackers, chat), is basically suitable for inclusion on the wiki.
So that others (users/volunteers) can simply take such contents and put them on the wiki.
This sounds more complicated than it really is, it's mostly about generalizing questions and answers, so that they are not necessarily part of a conversation, but can be comprehensible, meaningful and useful in a standalone fashion.
For example a question like the following:
how do I get git to clone a remote repository???
Can be answered like this:
Hello,
Just use git clone git://...
But questions can also be answered in a less personal style:
In order to clone a git repository, you will want to use the clone parameter to git:
git clone git://....
What I am trying to say is that most discussions in a project can and should be easily used to become documentation eventually. With this sort of mindset, your documentation can actually grow rather rapidly. You only need to get people to keep in mind that useful information should be ideally provided in a fashion that is suitable for wiki inclusion.
I have witnessed several instances where open source projects started to use this approach to some extent and while some people (largely new users) complained that answers were not very personal, the body of documentation was increasing steadily, because other people simply monitored such discussions and started to copy/paste such responses to the wiki.
Basically, this is one of the easiest ways to get people to contribute to a wiki, without requiring them to actually use it themselves, the only thing that's required of them is a shift in thinking.
If the developers still need to maintain 'real' documentation (s.a. Word documents), I see no way to meaningfully duplicate that on a Wiki.
It does not make sense for people to write twice
Any duplicated data is prone to get out of sync, soon.
What my current customer has done is move all this to Wiki. So I only document once, and I do it on the Wiki.
This is okay. Working with Wiki is more tedious than with Word, but at least the doc is online and others can mix-and-match with it.
Another working solution (imho) would be to store docs alongside the source, on subversion. But then the merging system needs to be able to cope with rich text etc. as well. I don't know, if any solution for that exists (other than using HTML or LaTex, which actually would not be bad picks).
Find "sticky" items (sub-3 pg. docs / diagrams / etc) something that the team seems to be creating again and again & post it on the wiki. Make sure everyone has access to the wiki and knows its there - set up a notification mechanism if possible. With some luck, the next time they have to access, rather than dig it out of version control or their machines - they should hit the wiki.
If they still don't, try to see if the team has enough slack to actually use the wiki - Subtler issues may lie beneath their reluctance.
Take a look at the advice at http://www.ikiw.org/ Grow your Wiki
Just to add to some of the excellent advice being offered here...
As a dev in a small company that does largely gov't contract work in the 6-24 month range, I find that my time is often split between development and writing status reports (right up there with writing documentation, only worse!) Having a wiki to slap down unorganized thoughts and notes as we go along has made report-writing a lot less painful (not pain-LESS, but better all the same).
Further, if you're already in the Mediawiki world, you might want to look at SemanticMediawiki. It allows you to take the organization of your data to another level by semantically tagging it. That doesn't mean a lot on its own, I know, but I can tell you (for example) that it can drastically improve the relevance of the data returned from searches. It is definitely worth a look.
Generally good advice here. I'd like to add:
You really need a champion - someone pushing this to developers and management (without being pushy - that's a challenge!) and providing support & tutorials when possible. This person also needs to be a peer (so a fellow developer, not someone in a remote IT department) and really customer focused i.e. ready to make changes when requested.
Speaking of changes, some people here say wikis are unstructured. I disagree. Our MediaWiki installation is structured using categories, particularly with two extensions:WarnNoCategories (to require users to add a category when saving a page) and CategoryTree to show how all the categories fit together (this can be linked to from the sidebar). I've got more tips on how we keep this low threshold, if you're interested.