I need to teach someone to program.



  • So one of the helpdesk crew who has graphic design experience as well as being fairly technically savvy has defected to develpment.  unfortunately he know very little about programming.  I've got him reading a book on c# right now and then an asp.net 2.0 book.  I was thinking datastructures/algorithms next and sql server 2005.  Any suggestions on how to turn this kid into anti-wtf machine?  He's got a great attitude and work ethic and is pretty bright.



  • For some reason K&R always comes to mind, even though you're not teaching him C.That might be the only good book ever written to teach someone how to start programming, as evidenced by its brevity and page count. Somewhere along the line how-to-program books became gigantic (and bad).

    Other than that, teaching someone simplicity is difficult, but IMHO that's the only real mark of a good developer. Everything as simple as possible and no simpler - as the quote goes.



  •  C#?  How hard is it to teach somebody to drag and drop.... j/k :)

     

    I personally would not go into algorithms.  That subject can really be avoided by 95% of all programmers.  How often do you develop your own algorithms in real practice?  Usually most people will use the generic default algorithms (or built in ones like Array.sort()).  If he is interested in them and is pretty bright at math then go ahead :), but I don't think that for general purposes (espicially web development) that going too indepth is going to do him much good. 

     

    I would stick with the basics of OO design and how to develop short clean code.  The SQL (at least SQL and Oracle statements) is a must.  I wish that I was tought some of that in school.  For some reason, even though 99% of all companies use data out there, my college decided that any database classes were a waste of time for CS students *shrug*.



  • After he has enough knowledge to start programming, let him do some non-time-constrained stuff. Then after he is finished show him how he should have done it, and especially don't be afraid to radically alter his code. I've managed interns before and used to make the mistake of saying "well you can do it that way too" when i knew it could be done better/cleaner/more readable.



  • After he's got the basics down I would suggest getting a variety of non-WTF code in front of him.  In my opinion, dissecting well engineered code is invaluable when learning a new, or your first, language. For example, I constantly run into code wherein the original developer obviously did not understand object oriented design.  There seem to be a lot of otherwise good programmers out there that just haven't been exposed to enough code good to do it correctly.  Frankly, I blame all the teach yourself xyz in 24 hour type books that give you just enough information to get the job done, but not in any sort of maintainable fashion.



  •  All good suggestions in this thread.

    First teach him stuff to let him debug his own code. Nothing is more frustrating to a noob than writing stuff and having it break or do nothing and not knowing why. Teach him how to produce quick output of values and states.

    Don't go all academic on his ass, but stay practical. A good "smart-workhorse" programmer is not he who writes the most genius algorithms, but who knows to structure code properly, and write code that is mainatainable by coworkers.Teach him good variable names, and teach him proper commenting styles.

    If he's good at it, and falls in love with programming, then you can talk about the finer points of computer instructions, such as Don't Optimize, and Don't Optimize Yet.  :)



  •  Don't forget to introduce him to this site later on.

     

    "Uhhh... Should I use 3 letter names for my database columns? It'd be faster to type them." 

    "Hold on, let me find a url...." 



  • Thank you guys for the response.  We've got him working me on some projects as well as a few that don't have deadlines (stuff we'd like done).  I'm going to take the advice and go over everything and point out where things could have been done better/simpler.  I'll then have him rework his code to fall in line with that.  He'll skip the data structures/algorithms for now.  He also is aware of this site as he's watching me type this.  I'm going to be a stickler about good OO design.  SQL will also be a big thing as will Database Design. but that I'll introduce slower so as not to overload him.



  • @galgorah said:

    skip the data structures/algorithms for now.

    I think skipping data structures is a bad idea. Obviously I don't think it's necessary to know how to implement all of the various data structures, but knowing the difference between linked lists, arrays, hash tables, stacks, queues, deques, et cetera and their strengths and weaknesses can really help a lot in the long run. Especially if it helps him avoid writing loops to look for particular elements in one structure that would be easy to find in another. Being able to pick the right structure is damned important.



  • Teach them about objects, with UML and design patterns.

    The world does NOT need another OO developer who doesn't understand how OO is supposed to work.

    Yes...it's you "Mr functions.cs", I'm talking to you...



  • not design patterns, not at this stage.

    The world does NOT need another person calling himself an OO developer who's idea of a good program design is blindly putting some patters together out of a book.



  • Screw design patterns. They will come naturally if he's any good, and only later will he realize that his work is a common pattern, i.e. a Solved Problem.



  •  Just have him sit with you for a week andyou explain to him everything you do so he can take notes.  Then have him read the source code for a project from start to finish.



  • @Salami said:

     Just have him sit with you for a week andyou explain to him everything you do so he can take notes.  Then have him read the source code for a project from start to finish.

     

    That isn't helpful, just sadistic.  Making somebody brand new to programming read thousands of lines of code that they don't understand?  Remind me to never ask you for help.



  • @amischiefr said:

    @Salami said:

     Just have him sit with you for a week andyou explain to him everything you do so he can take notes.  Then have him read the source code for a project from start to finish.

     

    That isn't helpful, just sadistic.  Making somebody brand new to programming read thousands of lines of code that they don't understand?  Remind me to never ask you for help.

    Your right it would be a bit much.  some of our apps are 100,000+ lines of code.  Right now we're just giving him smaller changes.  started off with just html modifications to get him used to the structure of our websites.  Now he's moved up to minor code behind tweeks and a bit of supervised minor database work.  We go over his code before it goes live to make sure it works and its of good quality.  He got to learn the hardway (from another developers mistakes) why we have certain policies in regards to source control. (My morning was a nightmare).  He helped me fix everything and we went over it afterwards.  All in all he seems to be picking things up fairly quickly.  (though we have allotted him 4 hours of straight studying time where he reads books, does examples, he experiments, making his own apps, and we talk about what is good and bad about his code


  • @amischiefr said:

    @Salami said:

     Just have him sit with you for a week andyou explain to him everything you do so he can take notes.  Then have him read the source code for a project from start to finish.

     

    That isn't helpful, just sadistic.  Making somebody brand new to programming read thousands of lines of code that they don't understand?  Remind me to never ask you for help.

     

     

    You have no projects less than a hundred thousand lines of code?  And, in my 2 sentence post, how did you miss the part where I said he should shadow him for a week and explain everything?



  •  @Salami said:

    @amischiefr said:

    @Salami said:

     Just have him sit with you for a week andyou explain to him everything you do so he can take notes.  Then have him read the source code for a project from start to finish.

     

    That isn't helpful, just sadistic.  Making somebody brand new to programming read thousands of lines of code that they don't understand?  Remind me to never ask you for help.

     

     

    You have no projects less than a hundred thousand lines of code?  And, in my 2 sentence post, how did you miss the part where I said he should shadow him for a week and explain everything?

    Personally, no we don't where I work.  I didn't miss the part where you said "shadow" him for a week, I just don't think that somebody with very little knowledge about programming is going to be able to "shadow" somebody for a week, then read the entire source code and actually understand but a very small part of it.  I think your idea may work for a very few individuals, but for the rest out there its just plain stupid.



  • @amischiefr said:

    I personally would not go into algorithms.  That subject can really be avoided by 95% of all programmers.  How often do you develop your own algorithms in real practice?  Usually most people will use the generic default algorithms (or built in ones like Array.sort()).  If he is interested in them and is pretty bright at math then go ahead :), but I don't think that for general purposes (espicially web development) that going too indepth is going to do him much good. 


    I agree with your statement, but sometimes when someone who knows the basics of how algorithms work, they get thinking in the right direction on how to make other stuff more efficient. So I do think that a basic overview of some algorithms is beneficial. Just enough to understand what the operations do, not all the dirty details.



  • @pitchingchris said:

    @amischiefr said:

    I personally would not go into algorithms.  That subject can really be avoided by 95% of all programmers.  How often do you develop your own algorithms in real practice?  Usually most people will use the generic default algorithms (or built in ones like Array.sort()).  If he is interested in them and is pretty bright at math then go ahead :), but I don't think that for general purposes (espicially web development) that going too indepth is going to do him much good. 


    I agree with your statement, but sometimes when someone who knows the basics of how algorithms work, they get thinking in the right direction on how to make other stuff more efficient. So I do think that a basic overview of some algorithms is beneficial. Just enough to understand what the operations do, not all the dirty details.

     

    I completely agree, that is why I said "I don't think that for general purposes ... going too indepth is going to do him much good."  I agree that a basic understanding of algorithms is pretty fundamental.  Just because you use Array.sort() doesn't mean that you won't be using for loops or nested for loops at all, and it would be good to understand why your program is running so slow because you have 4 nested loops.

     

    The basics as I see it, in order of newbie importance:

    1.) Commenting (David, if you are reading this, put some fucking comments in your program ffs!) 

    2.) Writing clean, readable code.

    3.) Taking an OO approach (if applicable).

    4.) Writing efficient code (your web page shouldn't take 30 seconds to load, espicially if its porn, I don't have all day ffs!).




  • Teaching someone to program vs. teaching them to be a programmer are two different things.

    Give them The Pragmatic Programmer after they have learned a language or two. Make sure they learn how to use command-line tools, source control, and dynamic languages.

    Also, I'd argue that it's more important to learn how to comment *right* than to just comment all over the place. And learning OO is completely unrelated to learning how to program. It just happens to be a common paradigm. Teach them Smalltalk if you want them to get OO quickly. Then, let them learn Java and wait for the *facepalm* that ensues when they realize how retarded some "OO" languages are.



  • @djork said:

    ..Snip only descent part of comment...

    And learning OO is completely unrelated to learning how to program. It just happens to be a common paradigm. Teach them Smalltalk if you want them to get OO quickly. Then, let them learn Java and wait for the *facepalm* that ensues when they realize how retarded some "OO" languages are.

     

    So would you suggest that we all go back to programming in COBOL and just write 100,000 lines of straight execution?  The only thing wrong with Java is people like you who don't know how to use it.  I will use morb's line [citation needed].  Care to back up what OO languages are crap and why?



  • @amischiefr said:

    @djork said:

    ..Snip only descent part of comment...

    And learning OO is completely unrelated to learning how to program. It just happens to be a common paradigm. Teach them Smalltalk if you want them to get OO quickly. Then, let them learn Java and wait for the facepalm that ensues when they realize how retarded some "OO" languages are.

     

    So would you suggest that we all go back to programming in COBOL and just write 100,000 lines of straight execution?  The only thing wrong with Java is people like you who don't know how to use it.  I will use morb's line [citation needed].  Care to back up what OO languages are crap and why?

    There is more to programming than OOP vs. a formless blob of code. In any given situation, you may find that OOP is in fact the [i]wrong[/i] paradigm, and a functional, procedural, prototype-based, or declarative approach may work better.



  • @djork said:

    @amischiefr said:

    @djork said:

    ..Snip only descent part of comment...

    And learning OO is completely unrelated to learning how to program. It just happens to be a common paradigm. Teach them Smalltalk if you want them to get OO quickly. Then, let them learn Java and wait for the *facepalm* that ensues when they realize how retarded some "OO" languages are.

     

    So would you suggest that we all go back to programming in COBOL and just write 100,000 lines of straight execution?  The only thing wrong with Java is people like you who don't know how to use it.  I will use morb's line [citation needed].  Care to back up what OO languages are crap and why?

    There is more to programming than OOP vs. a formless blob of code. In any given situation, you may find that OOP is in fact the wrong paradigm, and a functional, procedural, prototype-based, or declarative approach may work better.

     

    However in the context of C#, referenced in the original post, OOP is the way to go here.  The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.



  • @Atticus said:

    However in the context of C#, referenced in the original post, OOP is the way to go here.  The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.

     

    You ARE kidding, right? It is quite possible to write non-OO code in a purely OO language.

    Example: I once had the misfortune of working on a 100K+ LOC Java application that entirely depended on a single class which started off with the comment "This class contains all the business logic of the application". And the comment's author wasn't kidding. The class in question consisted entiredly of static methods. Every other class was merely a data container. You don't even want to know how often we needed to add methods to the main class and how long it took to recompile. Needless to say, the "lead programmer" on the project had no clue about encapsulation, MDA, even the most basic architectural concepts. Java is a purely OO language, but that was NOT an OO app.

    To quote one of my long-ago CS instructors, "there are data structures, and then there are algorithms, and that's all programming is." I can't for the life of me imagine trying to teach someone OOP without covering those two subjects. Even the simplest while loop is an algorithm. Even a string or an integer is a data structure. No, you don't necessarily need to use the big scary words when discussing those subjects, but the entire point of OOP is to encapsulate data and its associated methods/algorithms, for pity's sake. 

    But back to galgorah's original question. Since your coworker/student has some graphic design experience and is presumably conversant with HTML, perhaps there's some fairly simple ASP pages you could put him to work on? Teaching him SQL is also a great idea. Screw DDL for now; if you can get him up to speed on DML and then perhaps introduce stored procedures that would be a good way to get him productive quickly. Finally, since all the time you spend with him means less productivity for you (and also because you're not a trained teacher) it would actually be best if you could convince your powers-that-be to spring for some classes for him at the closest two-year college, or on-line if classroom instruction isn't possible. Get the company to pay for his tuition and books, pay him for the time he spends in class, let him do his homework in the office, and then you and your co-workers take some time to discuss it with him.I think that in the long run you'll find that he gets a sounder, more-rounded basic understanding of programming, which, when coupled with the knowledge that you can give him about your particular organization's needs, could turn him into an outstanding contributor.

     Best of luck to you, and I hope you keep us posted on how things go.



  • @Dianne said:

    ...
    i second everything Dianne said.  This much wisdom has not been found on these forums for many a moon.

  • :belt_onion:

    @Atticus said:

    The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.
    F#

    Now back to you...



  • @Dianne said:

    @Atticus said:

    However in the context of C#, referenced in the original post, OOP is the way to go here.  The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.

     

    You ARE kidding, right? It is quite possible to write non-OO code in a purely OO language.

    Example: I once had the misfortune of working on a 100K+ LOC Java application that entirely depended on a single class which started off with the comment "This class contains all the business logic of the application". And the comment's author wasn't kidding. The class in question consisted entiredly of static methods. Every other class was merely a data container. You don't even want to know how often we needed to add methods to the main class and how long it took to recompile. Needless to say, the "lead programmer" on the project had no clue about encapsulation, MDA, even the most basic architectural concepts. Java is a purely OO language, but that was NOT an OO app.

    ...

     

    Ok, so because you had the misfortune of working on shitty code created by a hack artist that means that OO shouldn't be the priority when using an OO language?  Of COURSE you can write straight, in-line code in Java.  Should you? FUCK no.  Why would you want to teach a new programmer how to use an OO programming language the wrong way? Atticus's statement of "is the only paradigm in this case" is valid.  Since the OP WILL be using an OO language why would we not want to teach him proper OO?  Why would we teach him to be a hack?

     

     



  • @Dianne said:

    @Atticus said:

    However in the context of C#, referenced in the original post, OOP is the way to go here.  The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.

     

    You ARE kidding, right? It is quite possible to write non-OO code in a purely OO language.


     Yes it is possible.  That fact does not however make it correct.



  • @bjolling said:

    @Atticus said:

    The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.
    F#

    Now back to you...

    Good point.  What I should have wrote was in all .NET based languages excluding F#, OOP is the only correct paradigm. Gee whiz...



  • @Atticus said:

    @bjolling said:

    @Atticus said:

    The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.
    F#

    Now back to you...

    Good point.  What I should have wrote was in all .NET based languages excluding F#, OOP is the only correct paradigm. Gee whiz...

     

    And you would be just as wrong as you were before.



  • @tster said:

    @Atticus said:

    @bjolling said:

    @Atticus said:

    The .NET Framework is object oriented.  Therefore OOP is the only paradigm in this case.
    F#

    Now back to you...

    Good point.  What I should have wrote was in all .NET based languages excluding F#, OOP is the only correct paradigm. Gee whiz...

     

    And you would be just as wrong as you were before.

     

    I apparently have my head too far up my own ass to see how uninformed I am.  I stand corrected. 



  • @Atticus said:

    I apparently have my head too far up my own ass to see how uninformed I am.  I stand corrected. 

    I guess you could write functional-style code in C# too...

    listB = listA.Select(x => x.somerandommethod()); // forgot exactly syntax and name

    compared to

    listB = map (\x -> somerandommethod x) listA

    in a functional language.

     



  • @HypocriteWorld said:

    @Atticus said:

    I apparently have my head too far up my own ass to see how uninformed I am.  I stand corrected. 

    I guess you could write functional-style code in C# too...

    ...

     

    There are other paradigms that functional and OO.  For instance declarative (.NET 3.5 has support for this kind of stuff with LINQ I think).  You can also look at other languages, Iron Python, IronScheme, IronRuby, etc.  

    You can also think about the fact that a paradigm is something more important than the structure of the language.   It's how you think of the system that you are building.  While .NET is OO, most of the languages (like C#, which was mentioned) are also procedural.  So they are OO and procedural, and you can't say "procedural is just having lots of static functions."  Procedural is the paradigm of having a list of commands that are done in sequence.  You can also have OO and functional or OO and declarative.  

    Saying .NET is OO and therefore OO is the only correct paradigm is taking a much to narrow view of what a paradigm is.



  • @tster said:

    There are other paradigms that functional and OO.  For instance declarative (.NET 3.5 has support for this kind of stuff with LINQ I think).  You can also look at other languages, Iron Python, IronScheme, IronRuby, etc.  

    You can also think about the fact that a paradigm is something more important than the structure of the language.   It's how you think of the system that you are building.  While .NET is OO, most of the languages (like C#, which was mentioned) are also procedural.  So they are OO and procedural, and you can't say "procedural is just having lots of static functions."  Procedural is the paradigm of having a list of commands that are done in sequence.  You can also have OO and functional or OO and declarative.  

    Saying .NET is OO and therefore OO is the only correct paradigm is taking a much to narrow view of what a paradigm is.

     

    Of course, the idea of a "paradigm" is actually pretty pointless these days as many languages do support all sorts of "paradigms". The 3 languages that you listed cannot be classified into a paradigm. Ruby is designed as OO but it's also procedural and functional. People view Scheme as functional but it's just as good a procedural language. Same with .NET languages.

    That's why I was talking about a "functional style", not a paradigm. Say you want to print out a list of stuff, then both of the following are valid (in sorta-C#):

    //procedural style

    foreach ( anElement :someList ) Console.Writeline(anElement);

    //functional style

    someList.ForEach(Console.Writeline);

     Anyways, the idea of classifying languages into paradigms is outdated.

     


Log in to reply