I find interesting that you took the approach of explaining a console application instead of a form app. More interesting from a technical point of view but maybe less interesting for a someone who just wants to hack something together to see what happens. When I started using C I always found hard to follow this tutorial because I like to use what I learnt in my own programs but I really did had no ideas of what console apps to make. Instead with server languages (for example) I found it easier because I could create my website and therefore do something "mine". In the end just following the steps of a tutorial I think it's about 30% of the learning process. Making mistakes is a good 50%. And to make them you must try your own things.
as I explained in another question it's mostly so the reader can get really "hands on" and write the code out by hand without code completion and other assistance. It may not be for everyone, but for core language stuff I think it's essential. Later in the series I'll definitely be integrating Visual Studio more
I think you've made a good choice with keeping VS out of the picture. Understanding the basics of compiling from the command line is where I start with novices. No point blowing their minds with a gazillion IDE knobs and dials. You could take this further and teach some basic command line debugging :)
>> Using Statement - Defines the scope for your application’s objects and disposes them when they’re done. This isn’t super important now, but I’m going to cover some other ways we can implement using statements in C#. What you need to know now is it’s including the types in the System namespace in your scope so you can use them.
This is entirely wrong. The 'using' in your example is the using directive, not the using statement. They are entirely unrelated.
Also, I really don't see why you are focussing on using the command line to compile programs. This is really not user friendly. The possibility for mistake is very high, which will certainly throw the target user of his/her tracks.
After looking at the documentation I believe you're correct. I'll fix my explanation of this so it doesn't confuse. Thank you.
My reason for focusing on the command line is simply because I want the reader to focus on the code, and the nitty gritty. The possibility of mistakes is high, which they'll learn from.
Visual Studio is the greatest tool I've ever used and you can't really build anything valuable without it but as a new programmer it also serves as training wheels that can build bad habits and hamper learning. That's my reason for doing the notepad / command prompt angle.
I agree about the IDE building bad habits. Almost all people I know who started programming in Visual Studio have atrocious formatting habits - they believe code formatting is something they don't need to care about because the IDE will do it automatically for them.
> Also, I really don't see why you are focussing on using the command line to compile programs. This is really not user friendly. The possibility for mistake is very high, which will certainly throw the target user of his/her tracks.
I disagree.
In the Netherlands, the driving exam includes being able to accelerate from a standstill while facing uphill. On first glance, this is ridiculous, since virtually all of the Netherlands is flat (and by that I entirely flat). It is a big hassle and hampers learning, because driving instructors have to drive long detours just to get to a city's single 5 meter long sloped road. More learning time is wasted, because there's a queue before that slope, entirely made up of other driving students (not kidding!).
However, at second glance, you realize that learning this useless thing is great because it allows you to do more with your car than the absolute basics. For example, I can take a car holiday abroad or queue in parking garages without getting nervous about how that thing with the hand break worked again.
It's similar for programming. As these tutorials are clearly meant for learning C# as a first programming language, immediately giving the user tools that do some of the hard work for them hampers their learning, because it is difficult for them to separate between the programming language concept and its corresponding tool support.
By learning the concepts independently from the tool (both language constructs and compiler toolchain concepts), the learner gets a more general understanding of what's going on.
Need to do Go later? Ah, a compiler, I know what that is.
Need to do Ruby later? Ah, no worries, I've done without autocomplete before, and oh, hey, classes and methods!
Great start Jeremy, I've read the entirety of chapter 3 and skimmed chapter 1, you have a solid foundation.
However, I have a few, hopefully constructive, critiques:
(1) As mentioned by qwerty69, links to the other chapters would help a great deal.
(2) Your target audience is "newbies"? If that's the case, it makes sense that you would provide a little more explanation for critical concepts such as variables. In chapter 3, specifically, it feels as if you gloss over the topic by deeming it a "a space to put data." Maybe you're just looking for your audience to build an intuitive notion of the concept, but annecdotally I've always enjoyed learning the essential details when tackling new topics.
(3) Speak authoritatively; don't inject fluff into your sentences. It drains mental capacity. For some examples:
"You just press that button and it will compile and run your program. Or you can just press F5 and that will do the same thing" ==> "Press that button, or F5, to compile and run your program."
"The new method Console.ReadLine() is pretty self explanatory, it reads a line of text from the console" ==> "Console.ReadLine() reads a line of text from the console."
Concise, to the point, and much more effective. I prefer reading books that explain the most in the least words possible.
Either way, keep up the good work. The more resources budding programmers have access to, the better!
(1)I'm likely going to put in some sort of menu system for this on the side of the articles, I haven't figured out a great way to do it yet.
(2) Yes my target audiences is newbies who want a very thorough introduction. I plan on doing a whole tutorial on variables, my rough draft on types is huge, probably already bigger than this chapter was and I didn't want to crowd it up.
(3) You're dead on about the fluff, I probably should have let this sit a day and came back to it to strip it out. I may even use your suggestions verbatim.
My background: C# pays for my family, my wife is constantly jumping on and off random tutorials to learn some programming (interested in C# because of my dayjob and Python as a nice beginner's language with lots of learning resources).
If I look at this article I feel that the flow is missing. It is well written, has nice screen shots and explains a lot. But it seems to hop around a lot. I don't quite know who you're targeting, but I'm reasonably sure you'd confuse the hell out of my (intelligent, brilliant) wife.
The style is more documentation slash dissection of stuff, less introduction with a purpose. I miss a global "why", you provide more like "This is something we can do, let's walk through it together". Unless you're already a programmer or really into case studies like this, I think this way to present something is less accessible.
Don't want to bash on your work. I think what you did here looks nice. Just sharing why I don't think I'd subscribe or why I cannot recommend the series to my so.
I don't take it as bashing, I appreciate honest feedback. If everyone only contacted me telling me how great I am or how bad I am neither would help, so I prefer a good mix.
My aim here is for the serious beginner. By that I mean someone starting out who may have tinkered with a language or two but really wants to learn C# in depth. That's why it's so verbose and I try to cover the topics. A hacker who wants to learn the basics should probably go elsewhere.
I'm honest enough with myself to have already thought this through, and I may throw in some quick hacky stuff specific for what someone is searching for, but for the most part I want these to be a very thorough introduction to the language.
One thing that jumped out at me right away is your indentation style which is a wee bit messy. New programmers need to be taught good/consistent coding style in the early stages of their development as well as how to use the language. Your examples should reflect what are generally accepted, though not mandatory, conventions.
The first thing I do if I'm coaching/mentoring a C#/.NET novice is to get them to follow the C# Coding Conventions [1] with Allman style indentation [2] and the Design Guidelines for Developing Class Libraries [3].
One other thing I would do is liberally sprinkle the tutorial with links to relevant further reading in the MSDN docs. A lot of new devs are overwhelmed by the MSDN library and often have no idea where to begin looking for reference material. Giving them good entry points so they can familiarise themselves with the official docs would be a beneficial addition.
There's bad indentation e.g. a for block not indented, and a mixture of C and Java style indentation. I recommend following the standard Microsoft style indentation which is place the opening brace on a new line on its own.
Also, "it will compile and run, then ask the user to press a key go back". One missing 'to' doesn't seem so bad but the accumulation of these little details really adds up.
Really nice though, I like taking the user back to the console and command line and walking them through everything. Best of luck.
Thanks for the feedback. I'll make a note of that as the style I present the samples in, since this is tutorial for beginners the last thing I want to do is spread my bad habits.
You've made a couple of interesting decisions (that I may not have done if I were writing this myself):
* Picking CSC over Visual Studio for compiling initially
* Explaining namespaces thoroughly in part 2, then glossing over them in 3 (I also don't know if I entirely agree with what's under "Using Statement")
No major criticisms with structure/style/order. I find that when teaching a programming language you just wind up dumping information on the person learning until a point where everything clicks, so the order of explaining this stuff probably isn't that important.
One thing that I'd suggest fixing is the indentation on the code. The number of spaces being inconsistent is something that could massively throw off people who don't understand nesting. Other than this, it's a good set of tutorials so far IMO.
My explanation of the using statement needs some work as another HN member pointed out, and I'll be modifying it. I am starting with CSC so people can get their hands dirty on the core language stuff, I'll be moving into Visual Studio as we start building more advanced stuff.
Also I'm going to fix some indentation issues as well. Thanks for the feedback!
Yea I actually haven't installed express yet because my internet connection was at dialup speeds, I'll be replacing the screenshots, I plan on using express 2010 or possibly one of the 2012 versions for future tutorials. I know not everyone has the cash to fork out for MSDN or (as in my case) a company willing to pay for it.
Thank you everyone for your feedback on this. My reason for going to HN is because it's comprised of experts and people in the field which is not my target audience but can help steer me in the right direction. With your suggestions I'll be changing and adapting as I go, and I'll go back and make past ones better and the end product will be of far higher quality. So I appreciate everyone reading this and responding back, and I'm pretty sure the newer folks using these will to.
I think this tutorial is a fine start. I would like to see more like it!
I'm coming at this as someone who knows multiple programming languages and would like to get Java and C# under my belt. I'm not exactly a newbie, but I think a few years ago (when I was a newbie) I would have followed it pretty well.
I don't think you should target people who don't know what a variable is (i.e. true newbies) but rather write a separate {tutorial,set of tutorials} for that. I like how the focus here is just C#.
I think the style/presentation is spot on - conversational without being cheeky.
I got some good feedback last time, it's helpful to hear from other programmers whether what I'm doing here is going to help newbies. I swear I'm not spamming I don't make a dime for it anyway ;)
As I doubt I'll ever learn C# I won't assess your tutorial by its actual intellectual content, but visually, it looks great. Too often, tutorials and guides on programming don't use enough visual aids, which at the very least, help break up the dense text.
To echo what others have said: don't do video. You're right to guess that unless you're a skilled video editor/producer, it will eat up far more time than producing screenshots, and have marginally more effectiveness (if any).
You could add links to the other chapters at the beginning of each article. This way it will be much easier for readers to navigate through the series.
"Side Note: if we end up never putting anything in this variable the compiler will spit back an error. It’s ok to initialize with nothing as long as you populate it later."
You mean if we end up /using/ it before we put anything in it we'll get an error. If we never put a value in it, the compiler will spit back a warning.
Why take all the pain of creating/editing screenshots, explaining through an article? You could have made a video instead. I personally prefer videos to articles when it comes to learning something -new-.
I really hate videos to learn programming...I have to wait for you to write everything when I just want to see a little part but I don't know when it happens, most don't add the code to copypaste and generally I think it's harder to learn from videos.
Videos suck for learning programming in my personal opinion.
You can't search them for the thing you vaguely remember, you can't copy and paste code, you can scan them when they're too easy. You can't skip back and forth without loading delay.
I suppose this is really subjective, but I prefer the opposite - videos (to me) are either too slow, explaining stuff that's irrelevant, or too fast, skipping through items too quickly. When it's too slow, it's hard to fast-forward, as you don't know when to stop, and when it's too fast, I find myself rewinding too often, hitting pause, etc. Just way too inconvenient comparing to a text with screenshots, where I can navigate a lot more efficiently. YMMV.
Actually I'm going to be working on Videos to accompany every tutorial but honestly I don't know if I'll stick with it.
The reasons being: (1) I am horrible at editing and producing videos and that time I spend struggling could be time creating more written tutorials and (2) I'm not sure that people will really want / appreciate it yet. Many people (myself included) prefer text. You can't always be in a quiet place or have headphones on to listen, and reading a page at your own pace seems to be easier than video. But I am considering it, I'll do one or two and see what the feedback is for that.
A video has several problems:
- it can filtered by a proxy according to the place where you're trying to view it.
- it may be too slow if you don't have a sufficient internet speed.
- you can't copy/paste the code.
I prefer articles, as videos often go too slow. It is also a waste of bandwidth watching a 1080p video of something that takes a few screenshots to express.
I think it depends on the person. I much prefer text tutorials over video; it's too much of a hassle to rewind a video over and over again to see what the author is doing.
Agreed, I hate the trend to have tutorials as videos nowadays.
Not to mention that it also excludes deaf people unless manually transcribed, or if the speaker is clear enough that automatic transcription is possible, but I doubt that is possible with programming videos yet.
My target audience is newbies who want a very thorough course on the core language. It's not really intended for people looking for quick hacks to problems. Nothing wrong with that but I'm shooting more for the audience looking for a fairly deep understanding, though I know that target audience is much smaller.
