Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have some experience in ASP.Net and can work my way around it without much trouble, however there are a lot of gaps in my knowledge of asp.net and .net in general.
I know the basics of c# and asp.net so I can accomplish most things. But I don't know anything at all about LINQ, Entity Framework, ADO.NET, delegates, ASP.NET Ajax, ASP.NET MVC, Providers, the different api's provided with asp.net (such as membership), the default controls that come with asp.net as well as the normal patterns used to create rich, stable and high performance asp.net sites. The list goes on and on....
I have really been wanting to upgrade my skills now and become a well rounded .net developer before I get left too far behind in the curve. I also have been meaning to look into ASP.NET MVC partially because I`d like to extend an open source project.
The problem is every time I get down to learning I get too overwhelmed. I dont know where to start, whats relevant, whats not. I basically need to figure out in what order should I be approaching all these different things and tackling them?
Should I get down with one of those monstrous asp.net 3.5 books (such as asp.net unleashed...1500pages) and read it from start to finish? And then pick up some book on ASP.NET MVC? Do I need to actually read such books from start to finish or are there topics I can safely skip?
Sorry if the question is badly worded but I think my problem should be evident. I feel .net is evolving very fast and I am getting left behind more and more. Aside from that I really want to be a good asp.net developer because web development is somewhat of a passion of mine.
Books I currently have in my possession...
ASP.Net 3.5 Unleashed
Building a Web 2.0 Portal with ASP.NET 3.5
Pro ASP.NET 3.5 in C# 2008
Javascript: The Good Parts
Pro C# 2008 and the .NET 3.5 Platform
Write ASP.NET applications.
The best way to learn any platform is to write in it, and as you run into something you haven't seen or know how to do look it up. When you do that you are self teaching and will learn more and remember more if you read it form a book.
Get started here. It is a free book on MVC. Type in the examples rather than just reading it and modify the code slightly to something different. Then go out on your own. Your skills will increase quickly.
To echo what others have said, you have to write code. However, don't stop moving forward when you hit a wall. If you're stuck on "the best way to do X" (best practices) either look it up if it's simple enough, or pull it off to the best of your knowledge THEN look it up and either go back and refactor it, or the next time you come across it implement it with the new techniques you've picked up.
As for what to learn and the order to do so, I suggest focusing on what you feel you really want to pick up OR what you think is going to be the most relevant and applicable to your job. Granted, you might not work somewhere that is constantly using the latest technology, in which case you'll need to learn things on the side through some mini-projects. There's a lot out there, so narrow it down.
Another suggestion would be to start a simple project and decide to implement parts of it using a particular technology. So, for example, you might pick LINQ to SQL or the Entity Framework for your data access side. Then pick AJAX or jQuery to verify a form using simple validation. Store some data in XML and read it using LINQ to XML. LINQ to Objects opportunities are many with in memory collections, string parsing, etc. In other words think small and implement some items with a particular technology and you'll touch upon many things. From there you can begin to expand your scope and may decide to explore a particular technology further and do more with it.
I agree with David Basarab's recommendation for the free ASP.NET MVC ebook. In addition, be sure to check out the http://www.asp.net/mvc/learn/ site. There are many videos and the StoreFront series is a well known example to follow along with.
Geez man, have some fun with it.
Pick something that you'd like to make and then start making it. If a book helps you to make it faster/easier/whatever then get the book. If the project is at work, then learn the necessary skills needed to do the project and get it done.
I'd say I've learned the most by reading some blogs, and doing my own projects because they are fun. Who the hell goes and sits down and reads a 500 page book on tech crap? You could, and you could have no life. Or you could be pragmatic and use parts of the book to get real world things working and learn more about the process of completing something than just coding. Course, you'd learn coding along the way.
Even i am also in your same position. What i am doing is spending more time for coding the new things and thinking which one is working good and which one is not working good.
Along with that read the blogs , books, online videos ,online meeting , participate in online communitis like stackoverflow etc
I totally agree with the write code answer, but to add to it, you'll learn more than reading by working with the source code of a well written app that covers your weak points. Load it up, build it, make modifications, additions, and trace through it.
When you start from scratch, sometimes it can be overwhelming to decide from where to begin. With a pre-built solution, it's an accelerated start.
With coding, the hunt and peck is much more fun because you are an active participant and then after you're done coding, some sit back and read front to back about what I just did works for me.
I would not argue against books when you begin to work on a new platform.
I always try to have the one and only best book. I first start to programm an application. If the first unsolvable problem occurs I go to the bookstore or use google books to see what book has the best solution to my problem. This is not necessarily the best book. But after a couple of solved issues I know what is the best book for me. I only buy this single one.
This keeps my bookshelf clean and after a while I know my books very well. To be honest right now I only use 3 programming books at all and 1 on a daily basis.
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 9 years ago.
Improve this question
I am not the only programmer, but I'm the only .NET developer, everyone else works with Perl, Ext JS, and related technologies. I'm primarily self taught, using Codeproject heavily to learn new techniques.
Without any mentors at my company specifically knowledgeable in .NET, I'm unsure whether classes, or online tutorials, books, or perhaps some other avenue might be most effective at helping me to become a better developer.
My goal, optimistically, is to become a developer capable of managing the next .NET developer we hire, or at least to integrate well with him/her.
I'm currently taking on the task of documenting my programs in such a way as to receive review from the more experienced developers at my company regardless of them not knowing .NET, and I expect this will be rather general, but hopefully still beneficial.
Does anyone have suggestions or advice for how to most effectively learn good practices without direct oversight?
Without mentors around, there are several things you can do to improve your skills:
Take classes...especially if your employer will pay for them.
Read books. They're the next best thing to a class.
Read developer blogs. They may not teach you best practices, but they'll keep you abreast of what's new in the development world. That'll help you keep from falling behind.
Courtesy of the Community Listen to Podcasts (Hanselminutes, Stackoverflow, etc.) and watch Screencasts (Dimecasts has tons of good content).
Participate in the community. We may seem harsh at times, but you'll hear the most about best practices, coding techniques, design patterns, etc. and different ways to apply everything.
I have always worked like that. My ways to improve are:
Reading high-quality blogs
Applying what these high-quality blogs recommend (whenever it fits your project and when time allows, of course)
Reading high-quality open source project's source code
Writing as much code as you can, always keeping in mind what you've learned and always trying to raise the quality bar. Practice does not make perfect. Only perfect practice makes perfect.
Keep an eye on stuff that's unrelated to your own line of work. For example, if your main job is coding ASP.NET in C#, read stuff about functional programming, F#, Haskell, other web frameworks like django, Ruby on Rails, etc. I'm not saying that you learn them, just see how things can be done differently. It will broaden your perspective.
When you gain some self-confidence: contribute to open source projects, write a blog.
About books: IMHO the books that are highly-technical (i.e. "Buzzword 2.0 in Action!") aren't worth your time. Everything happens so fast that they'll probably become obsolete 6 months after their release. The only books worth buying are those that deal with the underlying CS or architecture issues.
About classes: it's very hard to find high-quality non-university classes that aren't a waste of time/money. Most of the time you can learn faster by yourself. (UPDATE: fast-forward to 2013, MOOCs are an amazing, high-quality, free learning resource)
Also be wary of codeproject, there are lots of articles there with errors and/or general bad advice.
I am in the same situation you are in. I learn mostly from
previous projects/mistakes, especially when you take over an old project from someone else (50%)
google (25%)
forum/stackoverflow (25%)
Change employers. I'm not trying to be a jerk, seriously. The most growth your going to have as a developer is by working every day with someone significantly better than you.
Join some OSS project which works with .NET to get feedback on your code from experienced .NET developers. In addition looking at other people's code is a great way to learn new things - just as you have been doing. I also agree with Justin also that reading blogs like Eric Lippert's is very rewarding
Take advantage of the chance to learn the languages and technologies being used by by your colleagues.
They'll introduce you not just to syntax, but more importantly to techniques, idioms, and paradigms that you won't find in .Net, but that will challenge you to think about how you could apply or build those thing in .Net, or why .Net doesn't have or shouldn't use those things.
Why is Perl weakly typed (or is it)? What's Perl better at than .Net? What is .Net great at the Perl is just terrible at? Why do these differences exist? How might you implement a Perl interpreter in .Net? Why might you want to?
Why's everything in a JavaScript a hash? How does .Net class inheritance compare to JavaScript prototypes? Are JavaScript's first-class functions a great tool or a source of obscurantist abuse, compared to .Net's strongly and statically typed classes?
What are the fundamental data structures in each language? For each language, why are those types fundamental to that language? What were the different design decisions (or lack of decisions) that motivated and informed each language's design and implementation? Can you discern any common "ancestral" languages among the languages used at your workplace? Why don't we have "One Language To Rule Them All"? Should we?
Finally, excellence at any one language is really great to have, but unless you're sitting on that language's Standard Committee or writing compilers/interpreters for that language, a broader knowledge of the underlying algorithms and data structures and patterns that are common across languages is probably more important to your development as a programmer -- and certainly to managing programmers, if that's your goal.
Look for local .NET user groups. In most cities, you are likely to find at least one. User groups are a great place to develop contacts, ask questions about the technology and basically get answers to problems you may be experiencing. If there are no user groups in your area, try looking online.
If you are free to choose how you develop, and you get new projects fairly often, pick a new technology you're not familiar with to use on each project. Of course, do your research first and make sure it makes sense for the project.
At my last company, I was pretty free to use whatever I wanted as long as it made sense and worked. I always tried to use something new on each project. The last project I worked on, I used NHibernate. No one told me to learn NHibernate, but I took it upon myself to use it to expand my knowledge. Of course, I made sure NHibernate was acceptable first.
The best way to learn something is to use it. Classes and books are good, but nothing will make it stick more than using it in a real project.
My goal, optimistically, is to become
a developer capable of managing the
next .NET developer we hire ...
In that case, you should be looking to expand or improve your people/project management skills as well as developing your technical programming and design skills in your chosen technology.
I also subscribe to the view that it is not a good idea to focus too much on a particular technology; e.g. .NET. Too much specialization tends to limit your career prospects.
A year ago I was pretty much in the same boat and it's interesting when I look back at the things I wasn't so good at. Awareness of the technology you are using is an important one, many people have suggested reading books/blogs etc which are good.
One thing that may help you, is to look at the MCTS material, starting with a foundation exam (I'm working toward 70-536 .NET 2.0 Framework exam) to make sure you have a good base. One of the advantages of this is one that it is credited by Microsoft so you can add it to your CV for the future and it gives you a more structured approach than just reading books.
Secondly read up on design practises, or even design principles (such as Gang Of Four). Do your best to not cut corners, and develop your code in the best re-usable way. This keeps you thinking about design and maintainability which is extremely important.
Finally I'd probably suggest trying to ensure you're not doing the same thing over and over. Don't just work with databases, or UI's etc... Try to get a mixture of things to try new techniques and learn new stuff.
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 6 years ago.
Improve this question
I'm beginner programmer in the amazing world named ".Net".
I've a lot of questions
well, what I should learn C# or Vb.net
What's the best blogs which talk about .Net technology and Open source projects
Where can I find good tutorials, free books and ideas of projects
how can I progress in ".Net"
please, share your knowledge , your OPML of your favorite blogs or web sites about ".Net "
I'm waiting your advices, opinions, etc.
As far as which language you should learn, well what are your experiences thus far? I prefer C# over VB.NET. Though, eventually, you should be able to program in VB.NET even if you say with C# as your primary language (the same is true vice versa for VB.NET). You might want to check the syntax of each language and see which you prefer just by first glance. You will probably find that whenever code examples are provided for .NET and both languages aren't present, typically the examples are in C#. This is not a big deal though. I find C# (and similar languages) to be less verbose but that is a preference. Here are some good resources. I highly recommend the LearnVisualStudio.NET videos; start with the beginner tutorials and advance to more advanced topics.
Some great resources include:
http://www.dotnetrocks.com (podcast)
http://www.se-radio.net (general software engineering podcast)
http://www.haacked.com (Phil Haack's blog)
http://weblogs.asp.net/scottgu/ (Scott Guthrie's blog)
https://stackoverflow.com/questions/551315/which-c-net-blogs-do-you-read (previous question with a good list of blogs)
http://www.learnvisualstudio.net (good place to find video courses, cheap)
https://stackoverflow.com/questions/54423/best-net-podcasts (previous question)
What good technology podcasts are out there? (more podcasts)
Open Source projects:
http://www.codeplex.com is great for Open Source .NET projects.
Also:
http://csharp-source.net/ (not bad, some projects are old and not maintained)
http://sourceforge.net/softwaremap/trove_list.php?form_cat=271 C# as SourceForge
Open Source C# Opportunities (previous question with good infor)
Also check http://www.codeproject.com/
I'd start with Fabulous Adventures In Coding, which is a great blog by one of the people who actually work on C#. Then i'd also take a look at CodeProject and MSDN. Finally, you can't forget Joel Spolsky's web site!
For Regexes, look no further than here. Cosmos is a neat project though a little heavy for beginners, and DevExpress has the best VS addin this side of the earth! Personally, i don't like ReSharper but plenty of other people do.
(marking it CW so anyone can contribute)
Excellent suggestions so far. Another site to always keep in mind for open source code is Google Code. Plus Google has excellent search features for finding just about anything in their code base.
Things i am following
https://stackoverflow.com/
http://www.codeplex.com/
http://msdn.microsoft.com/hi-in/default.aspx
If you are interested in web development, check http://www.asp.net.
Also, checkout MSDN Magazine, 4 Guys From Rolla, and the Linq Project.
You can find a Comparison of C# vs VB.NET here
Also this Article in CodeProject describes the complete differences between C# and VB.NET. You will get large number of opensource projects from CodeProject
You can find an exiting project TextPad, which will help you to learn more in C#
I also had these question in my mind when I started learning .NET. I prefer C# over VB. But then its purely a personal choice. In my view start with a nice book like Beginning Microsoft Visual C# 2008 or Head First C#. And the online source which I find very useful MSDN.
As to your question whether to learn VB.NET or C#... Well, there are personal preferences and there are realities.
If you want to make a living out of this, keep in mind that relatively and generally speaking c# will make you more employable.
Example. As of right now, Dice lists 4421 matches for c# versus 1131 for vb.net.
I can recommend "Beginning ASP.NET 3.5 in C# 2008: From Novice to Professional" from Mathew MacDonald. It does not rely on deep C# knowledge and even for someone who knows C# it's interesting to read. I'm almost half through, and it is really nice to read.
Don't be shocked by the almost 1000 pages - lots of code listings and pictures are inside.
I think there is even a VB.NET edition, but I prefer C# - and I still think that this is the language Microsoft puts more focus on.
For GDI (graphics) programming in C# / VB.Net, look at the "Beginners guide to GDI+" section at bobpowell.net.
I have worked through many of the advanced topics, and they're very well written and give great examples.
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 9 years ago.
Improve this question
I've been programming for a few years in C# and XML. I used only the basics of those languages and have survived on the web for info like arrays and text manipulations. But when I am get interview, the interviewers ask only advanced questions - I found the answers later in the Advanced sections in the books on the subject.
Why do the interviewers ask such advanced questions? The job looks almost the same as what I was previously doing, so there's need for advanced knowledge, like what class delegate is or XPath commands.
Questions are:
What version of XSL does .NET 3.5 uses?
What XPath command to use to get value in element X?
What are class delegates in C#
Does C# allows multiple interface inheritance?
How do you access GAC in C#?
There are two reasons that I ask them.
To see a person actually say "I do not know the answer to that", as opposed to trying to BS through the question.
To see what kind of logical problem solving skills a person has.
Usually a question will be of one or the other, but not both. Both are extremely valuable in screening a perspective employee, however.
Also, the question might not actually be "advanced" for the position. It is reasonable to assume that Senior-level and/or Architects can answer questions that a Junior to Mid-level might not.
Perhaps because they are trying to find programmers who know more than the basic stuff. If they are trying to distinguish between a field of candidates, it isn't helpful to ask questions that everyone knows the answer to - how do you select among those candidates? If you're going to hire only 1 or 2 out of a pool of candidates, you need to find some harder questions that only 1 or 2 out the pool can answer.
Getting the answer wrong is what I want from an applicant in some cases.
One of the reasons I like to ask a question that I think the applicant will get wrong is to see how they adjust to the situation. How they handle getting something wrong and handle someone telling them how they should have answered etc. If they are very defensive or rude when you tell them they are incorrect then it is a good indication of how they will work on a team when many times your ideas will be challenged.
If they take the solution or recommendation and realize they can learn from it or even add to it that is usually a sign of someone what is easy to work with and willing to work 'outside of their box'. If they just make excuses and dance around trying to say why they could be right or should be right (in cases where they are clearly not) then this tell me when the same issue arises in the future this applicant is going to cause headaches.
Not so worried about the answer, more interested in how they react to the question / solution.
Another reason would be to gauge their level when hiring as well. You might be hiring for a bunch of positions but not sure where this applicant fits. Hard questions that show problem solving and attention to detail can sometimes make it easier to categorize their skill set.
I ask advanced questions for a few reasons:
Some of my questions are advanced usage of things everyone should know (not a trivia question) -- I want to see you reason through the answer using knowledge you have, but in a way that isn't common.
I want to see what happens when you don't know something -- do you give up?
I want to hire people that are serious about what they do. People that really care about the technologies they use tend to want to know the advanced stuff.
I want to see if there are gaps where you just don't know that an entire area of knowledge even exists. For example, in your XPath example -- I might be ok with: "I believe that XPath could be used to help solve this, but I don't know it well enough to write it out here" -- then I would show them a little XPath and see if they could apply it. If you don't even know that XPath exists, google isn't going to help you.
Likely they're just getting a gauge of where you are. They probably got stuck on this problem themselves and perhaps wanted to see if you could think of an answer on your feet.
I've experienced the same types of questions, and considering when I program I use excessive resources, this type of thing usually throws me off. Their loss.
Because competency as a programmer involves both depth and breadth of knowledge.
The interviewer is trying to devine your level of knowledge, and he is copping out by "borrowing" a question from the last chapter of that book.
Really, this is sloppy work on his part, relying on one question to guage your expertise level. You may have low programming skills, but recently come across the buzz-word, and are able to ace the interview.
I did get burned once in interviewing a candidate who professed high levels of C expertise. It turned out that he was reading "C for Dummies" and managed to BS through the interview process. I admit that I wasn't concentrating on his programming skills, but was looking for other aspects, which he also managed to BS through. Turns out his whole resume was a pack of lies.
Nowadays, I make sure the candidate has working knowlege of variable scope, persistance, pointer arithmetic, basic algorithms, structured programming, object-oriented programming, polymorphism, multitasking and inter-process communication. I will quiz him on his debugging skills, and zero in on details such as race-conditions, heisenbugs and security vulnerabilities.
Depending on the job, I will ask about experience in the target language - such as key=>value maps (arrays) in PHP, Swing programming in Java, event handling in C#, tables vs CSS in html -- you get the picture.
If the candidate passes the first part of the interview (I usually know within about 5 minutes), I will then give him a binder and send him into the coffee room (nice couch and table there) to prepare for 20 minutes for a code review on a selected module.
That's when I send in the troops - employees are instructed to use the coffee room normally, introduce themselves and make conversation for about a minute.
What I'm looking for is the ability to concentrate on a task (blatant ADHD), the ability to work under pressure, and interpersonal dynamics.
When the candidate returns, I have him act as main presenter and start our normal code review process. The first thing I look for is if he read the page titled "Code Review Process". I'm not looking for him to complete the review - about 10 minutes is enough. As a matter of fact, the fewer main lines processed, the better - within reason.
I haven't been burned by a new hire for a long time now.
Your username suggests you like coding (duh), but your question suggests you don't. If you really liked coding, then you should love to learn about it. Those questions that you listed are not that advanced.
Even if those questions were advanced, the interviewer is trying to gauge how much knowledge you have in the area that you say you have knowledge in. They are also trying to gauge how well you would fit into their group.
P.S. Not to be mean, but if you program using XML and don't know what XPath is, then you are a little far behind.
They probably want to see if you really know what you're talking about or if you're a novice programmer who gets along on the web using only what he has picked up through trial and error...
1.What version of XSL does .NET 3.5 uses?
Because they can't tell important things from non-important ones. Bad sign.
2.What XPath command to use to get value in element X?
Because they want to see if you know XPath. This can be either because they use it extensively and you need it to get they job done or because they think XPath knowledge == skill.
3.What are class delegates in C#
(I've never heard the term "class delegate" and a google search shows no definition, so I assume you mean just "delegate").
Delegates can hardly be considered an advanced topic.
4.Does C# allows multiple interface inheritance?
If they really asked about "interface implementation", it's part of the most basic concept so it's a valid question (although too simple to really mean anything). If they really asked about "interface inheritance", it's more of trivia, but I would still say acceptable. Bonus point for them if they asked what "interface inheritance" really means.
5.How do you access GAC in C#?
This is the kind of thing every team MUST have one person who knows. I'd say it's also a indication of seniority (which BTW, I don't care much about) since nobody reads about these things, the only way to find out is to be forced to solve a real-world problem.
I ask advanced questions to try see how people work through the problem. I like to ask questions that I don't know off the top of my head for that reason.
I want someone who is a critical thinker rather than just an academic who can recite text books to me.
They want to find someone with practical experience that extends beyond what is taught in beginner courses. When my company interviews candidates, we often find that most of the applicants cannot solve what we would consider to be very basic programming problems simply because they don't know the API or don't understand when to use various basic data structures.
If you want to impress an interviewer, work on your own programming projects outside of class. Learn a good chunk of the language API, and start learning about third-party libraries that can greatly simplify your work.
Another reason is to gauge your response to a question they really don't expect you to know the answer to. Problem solving skills are essential, so asking you questions you already know the answer to is not going to address that, is it?
There are even instances of companies asking odd, non-programming related questions just to see how you think your way through a problem. There is the classic "Why are manhole covers round" question, reportedly asked at Microsoft interviews.
More Microsoft interview questions
I'm not meaning to offend you but maybe your understanding of the job is not deep enough and it in fact requires knowledge of advanced techniques.
Also, you can do a lot of things with basic methods but advanced methods might the better way to implement regarding complexity, time to implement or maintainability.
There are many possible reasons. They may:
actually use those techniques (delegates and XPath aren't particularly rare or obscure)
have a large pool of candidates and want to try to find the more knowlegable ones
want to see where the limits of your knowlege are, so they ask question up to the point where you start to be unable to answer well
want to see how you might approach areas that are unfamiliar to you - to see how you might adapt to new stuff
want to show off their own knowlege (probably not a legitimate reason, but it certainly happens)
I've heard these really aren't in use anymore, or at least not nearly as much as they used to be, but you might be interested in this. I picked up a pretty cool short book a few days ago that has to deal with the "Microsoft style" logic interview questions that are sometimes asked. I'm a few chapters in and it gives a neat little history of the tech field's interview style and has a ton of logic problems, complete with answers in the back.
It's called "How Would You Move Mount Fuji" and it's on amazon for pretty cheap.
http://www.amazon.com/gp/offer-listing/0316919160/ref=dp_olp_used?ie=UTF8&condition=used
I've just completed a round of interviews, where I use a three or four stock 'simple' C# code fragments that the interviewee will look through and attempt to explain what the expected result will be. In each case the code sample is no more than ten lines of clearly-formatted code that utilises basic C# skills (inheritance, generics, anonymous delegates); also in each case there will be a 'gotcha' - but like others have stated, I don't put these in to be spiteful, they're there because I want to see how the candidate reacts when confronted with something that doesn't work as expected.
We had a candidate recently that had sailed through the first part of his interview; impressive CV, was apparently the Lead Developer of a team of 10 and had been developing code in C# since 1.0; yet apparently had no idea what "Console.WriteLine()" did (nor could he even hazard a guess), nor could he even begin to cope with the tiny anonymous delegate example.
Another candidate was self-effacing, and didn't know how to grade herself as a developer - she'd had less experience than the former candidate yet she sailed through the code samples, fell for a couple of the 'gotchas' but asked the right questions to get the correct conclusions and genuinely learnt from the experience. Needless to say, she was hired.
If you're claiming domain-specific knowledge (like XML) you should expect to be asked specific (and sometimes hard) questions about that domain; if I'm interviewing a senior ASP.NET developer and they've got no idea about HttpModules or HttpHandlers (like some recent interviewees) then alarm bells start to ring.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How can I increase my proficiency in programming? I have a grasp of the basics of C#, but don't feel too confident about my ability.
Code something in C#
Read C# Code and try to understand it.
Read a C# Book (and please none of the C# in 21 Days books)
The confidence comes with the experience.
Read Stack Overflow every day :)
Seriously. Try to solve interesting problems. Even if you don't post your solution, come back later and see if other people came up with something similar, why their solution might be different, etc.
Project Euler.
http://www.asp.net/LEARN/videos/
Voile, you are programing ASP.net.
Keep in mind that you may need a little more grasp on C# as your codes evolve. For that use a good book, most Microsoft's learn C# are pretty neat(The learn ASP.net is quite lame).
Of course, thats what I did back then(about 2 years ago), nowadays you should be able to find some awesome tutorials online.
Good luck ;)
Think of a fun project of some complexity (more that "Hello, world") and code it.
Practice, practice, practice!
Also read forums, blogs, participate in discussions. You will learn many things that aren't even mentioned in books.
read lots of code, write lots of code and keep a copy of C# 3.0 in a nutshell handy.
Learn new programming languages. Learn data structures and algorithms and design patterns. Learn regular expressions. Learn databases. Learn HTML/XHTML/DOM. Learn learn learn learn learn.
In programming, knowledge === power.
Work on something, even if it's reinventing the wheel. You can read books, watch videos and listen to podcasts all day, but the real experience comes from actually building an application. Don't build an application that you know you can build - instead, create an application that is slightly out of your reach, then rinse and repeat.
The experience when you realize that you created a mess of spaghetti code that is unmaintainable cannot really be substituted, as this then really allows you to look into techniques to improve your code. Sure, feel free to read on MSDN about Events, Delegates and Lambdas, but reading about them in the moment you need them means that the knowledge really burns into your memory.
I try to have a rough knowledge about as many topics as possible, but that's usually rather shallow: I know that a technique exists and roughly what problem it solves, so that when I need it I can learn about it.
In my opinion, the only alternative to first-hand real world experience is even more first-hand real world experience.
http://www.appdev.com/csharp.asp
:)
You say you are learning ASP.NET and C#. Have you ever done any programming or web development? Because, if you have not, then you need to take a step back and learn the basics of HTML, CSS and get a grasp of how data is passed via HTTP between client and server. I would also strongly advise getting a grounding in basic SQL, because most serious web development will utilise databases at some point.
After that, some basic OOP (Object-orientated programming) theory would do you good. That way you have a good grounding in the subject-matter before diving into the coding.
For learning C# the I'd suggest a couple of good tutorials:
The C# Station Tutorial and Softsteel Solutions C# tutorial.
I also found the ASP.NET Quickstarts useful when I was learning ASP.NET - I prefer to learn by example than by theory.
As for confidence, I'm afraid that only comes via experience. Perhaps try answering a few questions here? Getting a few up-votes might just give you that boost. Good luck.
This fits in to catagory of answers you've received thus far, but review open source projects.
Understand how they work and maybe even why they were put together in a given way. Not only will it improve your ability to write C# but it will also improve your understanding of Software Engineering which is ultimately how you put a programming language -- C# or otherwise -- to good use.
Creating a Project that makes use of a lot of different technologies is a good way to grasp a 'big picture' view.
As an example, think of an n-tier application where you input a value into a very simple web page, this value being sent into a web service, and behind that WS a simple business layer that switches between readings into a table of a data base, then you return the value finishing the output in a postback of the initial web page. In my Personal opinion, every element of the layer is a simple one, but, making the whole system work without errors is good beginner's challenge, that way you could build a confidence in your skills, enabling you to undertake any other idea.
Well, that were my two cents. Good Luck!
There may be so many projects that u can make.choose the project that makes u.it's true take a project that you consider difficult for your level.
1) analyse your project
2) define the objective
find things that are necessary to achieve the objective
3)then derive an algorithm which clearly explains the workflow
4)then start woking
In my experience "Learn By Working" is a good idea.first grab the basics then start the work soon you'll learn step by step.never give up ,be a ceaseless crusader.
practise practise it's a only way of surviving as a programmer.
Being a best programmer requires a lot of patience,thinking skills,Attention,a thrist for knowledge.
Wise people always replace the fear of unkonwn with curiosity
Actively participate in programming (and non-programming) forums.