7 Replies - 6857 Views - Last Post: 01 May 2012 - 07:44 AM

The level of skill needed to contribute to Open Source

Posted 11 April 2012 - 01:17 PM

Greetings from captain noob. I have been studying c#, LINQ, SQL, etc for the last couple months because I want to move into my companies development department. It was recommended to that I was ready to go to the "learn by doing" stage and GitHub would be a great place to do that.

So I signed up, downloaded, figured out how to fork some stuff, and clone it to my box. The problem I am having is none of the projects I have seen, look to be in my expertise range. Everything i see on there is for new frameworks, operating systems, games, and other stuff way beyond where i am right now. I'm looking more for some actual applications, web or otherwise.

So i am wondering if I need to just browse further or look to another open source hub. Any helpful tips, hints, comments would be appreciated. Thanks.

Once you have that MSDN page that describes the function, you may not be familiar with out to actually get useful information from that page. There is a LOT of data there. So what is the important parts? Read this guide to reading the MSDN.

Don't think you are the first person to ask a question. Try a search on this site to see if someone has already brought up this problem. Also, as soon as you post your question go to the bottom of the updated page: You will see where the system has already analyzed your question and tried to find similar threads for the same question, so check those links out.

If this sounds like you

Newbie/Rookie said:

I have a little programming experience but I need to write ...

read this section

Spoiler

You need to start there. I can't say "I have little experience in speaking Russian, but I have been assigned to write a mystery novel in Russian. Can you help me?"

We can help you by saying "First learn basic programming and the language of C#. Then take on assignments." Could someone here write this program for you? Sure. Could someone here map out all the processes you need to follow and do the Software Design part of this in the slim hope you could code it from there? Sure. But we don't volunteer to do the job that you're either getting paid for, or getting a grade for. You may want to read this.

For now, just work on the lessons. Do a self-teaching book from cover to cover. Then consider writing a program.

Don't try to create a useful working program to fit a need of yours (or a for-pay contract) as your introduction to coding project. When you are learning to code you don't know enough to code a program, let alone know how to engineer the architecture of a program. It would be like saying "I don't know how to read sheet music, or play an instrument. I think I'll write a 3 act opera as my first learning experience."

I don't say this to be mean. We've seen lots of new coders take this approach and we know it doesn't work. Trying to design your own programs before you understand the basics of the code language you've chosen just leads to problems, frustrations, and 'swiss-cheese' education (lots of holes).

Otherwise, you can just jump to the resources here:
Some of the tutorials below are for C# or Java not C, C++, VB.NET [...]. But the conceptual stuff of classes, object oriented design, events etc. are not language specific and should give you enough guidance in theory of program development for you to be able to look-up specific code example in your chosen coding language.

But honestly, just typing away and seeing what pops up in Intellisense is going to make your self-education take 20 years. You can learn by trying to reverse engineer the language through banging on the keyboard experimentation - or you can learn by doing the tutorials and following a good "How to learn C#" book. There are so many great "How do I build my first application" tutorials on the web... There are dozens of "Learn C# in 21 days", "My first C# program" type books at your local book seller or even public library.

Martyr2's mega project ideas list is a great place to start on developmental projectst that you can learn from; rather than trying to make something complex like a game as a self-teaching tool {that never works for anyone}

C# Cookbooks
Are a great place to get good code, broken down by need, written by coding professionals. You can use the code as-is, but take the time to actually study it. These professionals write in a certain style for a reason developed by years of experience and heartache.

I urge you to work through the C# learning series here on DIC, and to work a self-teaching book from cover to cover before you even think about designing your own applications.Microsoft Visual Studio Tips, 251 ways to improve your productivity, Microsoft press, ISBN 0-7356-2640-5 Has many, many great, real-world tips that I use all the time.

Some of my common tips (some may apply more than others to your specific style):

You have to program as if everything breaks, nothing works, the cyberworld is not perfect, the attached hardware is flakey, the network is slow and unreliable, the harddrive is about to fail, every method will return an error and every user will do their best to break your software. Confirm everything. Range check every value. Make no assumptions or presumptions.

Take the extra 3 seconds to rename your controls each time you drag them onto a form. The default names of button1, button2... button54 aren't very helpful. If you rename them right away to something like btnOk, btnCancel, btnSend etc. it helps tremendously when you make the methods for them because they are named after the button by the designer.btnSend_Click(object sender, eventargs e) is a lot easier to maintain than button1_click(object sender, eventargs e)

You aren't paying for variable names by the byte. So instead of variables names of a, b, c go ahead and use meaningful names like index, timeOut, row, column and so on. You should avoid 'T' for the timer. Amongst other things 'T' is commonly used throughout C# for Type and this will lead to problems. There are naming guidelines you should follow so your code confirms to industry standards. It makes life much easier on everyone around you, including those of us here to help. If you start using the standards from the beginning you don't have to retrain yourself later.
You might want to look at some of the naming guidelines. Its a lot easier to start with good habits than to break bad habits later and re-learn.

Try to avoid having work actually take place in GUI control event handlers. It is usually better to have the GUI handler call other methods so those methods can be reused and make the code more readible.

Don't replace lines of code that don't work. Instead comment them out and put your new attemps below that. This will keep you from re-trying the same ideas over and over. Also, when you come back to us saying "I've tried this 100 different ways and still can't get it", we can actually see what you tried. So often a failed attempt is very very close and just needs a little nudge in the right direction. So if we can say "See what you did in attempt 3... blah blah" it helps a lot

If you are using Visual Studio you can select a block of lines and hit control+k control+c (Kode Comment) to comment it out. control+k control+u (Kode Uncomment) to uncomment a selected block.

I strongly suggest installing VMware or some other virtualization technology on your development PC so you can create a couple virtual computers for testing. This would allow you to debug and test inside: WinXP32, XP64, Vista, Win7x32, Win7x64... etc. without having to actually have 5 physical PC's. Visual Studio will let you send the debug directly into one of these virtual machines so you can watch it operate, check its variables, see the crashes and so on just as if it were debugging on your real machine.

This can't be stressed enough in today's world of cell phone messaging:Don't use txt/sms/leet/T9 speak like: u no, u r, dnt, wut i m do-n, coz, al gud, b4, ny1, and so on like this guy:

Spoiler

dis not b d'hood dawg... You are sitting at a real keyboard with a real monitor, not a cell phone. You are not here texting your high school posse to come to your kegger after their shift at Taco Bell. You are here asking for help from senior coding professionals who graciously donate their valuable time to helping the next generation of coders with their chosen craft. Please try to show them, yourself and the industry some respect by writing at least at an eighth grade level. (IE: English not ebonics or SMS, real words, punctuation and so on). If you can't take your own problem/question seriously enough to write like an adult, then why would you expect anyone else to take it seriously?

When you write a post you are presenting yourself. Your writing style is all you have to show others who you are and what you stand for. When I see posts filled with lack of capitalization, SMS text like 'Urself', lack of punctuation and so on; what I see is someone who just doesn't care to make even an eighth grade presentation of themselves. I also see that you feel we are not worth the effort. Posts that look like this show that you don't feel the person you are talking to is worth speaking to as an adult. If you show this level of contempt or apathy towards someone you are asking for help how can you expect to be taken seriously or expect to receive that expert's fullest attention and time to help you?

Re: The level of skill needed to contribute to Open Source

Posted 11 April 2012 - 09:02 PM

If you want to start in working on an ongoing project, you have to start with a great degree of humility. Remember that there are people here with a hell of a lot of experience, and the aggregate experience here is simply enormous. Start by simply trying to understand how good it is - and I mean literally, assuming that everything about it is brilliant and it's your job to figure out how. Any time you come across something that you think must be a mistake, change your mind and assume that it's actually marvelous, and you just don't understand it yet, and go looking for evidence to support that assumption.
After you do this quite thoroughly, you might come to almost believe this. At that point - and only then - can you allow yourself to believe that maybe you've found something that's just a little less marvelous than all the rest, and even that you've seen a way that it could be a little more marvelous than it is now. And you can raise that question and offer your notion.

The idea, of course, is to avoid the temptation to come charging in and arguing with the community already working on this project, who have spent a fair bit of time working on and thinking about this. Learning that project backwards and forwards will, for a start, make you a better developer. After all, knowing a large codebase is part of your stock in trade. The more times you do this, the better you'll be at picking up these details quickly and deeply, which constitutes a win.
Developing that humility to assume that your impressions are wrong until proven right means you'll actually test your hypotheses before you assume they're correct, which means you'll be right a lot more.

And, of course, studying that code and tweaking it on your home machine, and trying to figure out why it's this way and not that way will make you a much better programmer, which I think was the point of the exercise.

Re: The level of skill needed to contribute to Open Source

Posted 12 April 2012 - 10:18 PM

I'm just wondering...considering the amount of effort it takes to successfully contribute to a project, do most experienced, active-in-the-community programmers actually do it after they come home from their full-time job?

from what I read about Linux development, the vast majority of work is done as part of someone's job.

This post has been edited by The Architect 2.0: 12 April 2012 - 10:19 PM

Re: The level of skill needed to contribute to Open Source

Posted 30 April 2012 - 04:27 PM

The Architect 2.0, on 12 April 2012 - 10:18 PM, said:

I'm just wondering...considering the amount of effort it takes to successfully contribute to a project, do most experienced, active-in-the-community programmers actually do it after they come home from their full-time job?

from what I read about Linux development, the vast majority of work is done as part of someone's job.

I am using an open source library in the project I am doing at my job. I found some bugs in the library so I fixed them, while I was at work. That is probably very common, because any time you use an open source library for your job you might find bugs, or things you want to improve. If someone is contributing to open source at home, just for fun, then I guess they are working on their own project, rather than helping to fix someone else's.

Re: The level of skill needed to contribute to Open Source

Posted 01 May 2012 - 07:27 AM

I have been getting some great answers to my post, but nothing yet that fully answers the question, so I want to clarify it a bit.

I am looking for a place to contribute to open source applications. Not operating systems, APIs, new fancy frameworks or games. Just regular old c# applications, web or otherwise. If anyone knows of a place, please let me know. Thanks.

Re: The level of skill needed to contribute to Open Source

Posted 01 May 2012 - 07:38 AM

Our own jobs forum is littered with people claiming to pay out at the end of the program development if the program sells and makes money.

Those are just regular old applications. Since open source is guaranteed to not make you any money, if you approach those "opportunities" with the same mind-set you won't be disappointed and there is always that slim chance you might make a few bucks. Pretty much a no-loose situation.

Re: The level of skill needed to contribute to Open Source

Posted 01 May 2012 - 07:44 AM

tlhIn`toq, like OMG! Thank you, I never even thought to check that out. I'm not looking to make money at it write now, so if someone wants to take my code and run, as long as they let me know if it works before they bolt I will be happy. Have an excellent day.