macOS Tactics for teaching someone software engineering

[jiminaus]

Hi guys,

I have a friend who just experienced what I would describe as the most atrocious Java course in existence. In the end he did learn some Java, but his confidence is shot.

So I'm going to tutor him over the summer break (southern hemisphere) to try to build up a solid foundation of software engineering skills before he re-embarks in learning Java.

One of the things he complained about what not being able to see the forest for all the trees. He was feeling lost because he couldn't see where he was in the big picture. So I thought I would start will a bird's eye tutor of software engineering. Not going into tremendous details, but with the goal that he would understand the concepts and how that fit together.

Chown33 posted thread

Non-programmers think the hard part of programming is the "magic programming language". It's not. The hard part is problem-solving: breaking things down, figuring out how things work (and how they don't work), then solving numerous smaller problems (sometimes mind-numbingly small and numerous), and eventually building bigger things from those smaller solutions.

So I was thinking of taking him through an iterative process. In each cycle he would touch on all the phases, learning at little more about each. But I don't want him getting bogged down in Java. I want him to keep focused on the software engineering concepts and building the foundational skills like braking down a algorithm and organising the behaviour and data. So I want him to use pseudo-code.

I've never seen a book that does this. Does anyone know of one?

Can anyone see a flaw in my approach, or have any other advice?

(BTW If it's an issue, he's not paying me for this).

Regards,
Jim

 

[chown33]

I suggest broadening the scope so it includes things other than software.

The process of breaking things down is not exclusive to software engineering. It's how all engineering works. It's really how all problem-solving works. It goes back and forth between attempting something based on current understanding, and observing results to gain necessary understanding. Plus the whole "Don't reinvent the wheel" thing, which implies looking at books and other references to gain the foundation for understanding what you're observing.

I use the same process when designing electronic circuits, building a chicken coop, modifying a cookie recipe, or fixing the wall of a friend's house.

I didn't start out doing software. I'm trained in electronics. But I've always been a tinkerer, and a "How does that work?" kinda guy. One of the reasons I got into software was to make the hardware that I'd built do something. Then I found I could build cool things that didn't require a trip to Radio Shack for parts. And there's much less soldering in software.

 

[MorphingDragon]

Go look at your PMs.

 

[notjustjay]

I use the same process when designing electronic circuits, building a chicken coop, modifying a cookie recipe, or fixing the wall of a friend's house.

As I was reading the OP's title and post, I was thinking the same thing. Look at it from other applications and get a feel for the process.

Imagine baking cookies by just grabbing random things from your pantry and throwing them together, hoping they'll taste good. The batch didn't work? Throw it all out and try something different.

Imagine building a bridge by trial and error. It couldn't hold the weight and broke? Oh well, try another.

Of course we don't do it this way. We do extensive research. We Google for existing cookie recipes and modify them to suit our current needs. We read textbooks on structures. We do mathematical calculations. We build scale models or test recipes in smaller batches. When we do need to experiment, we take a structured approach, document everything, and learn from previous failures.

Think through the software engineering process and find analogues in the real world. That should help.

 

[jiminaus]

Thanks guys for your feedback.

Becoming an independent learning is definitely a worth goal. I'll incorporate that. And I'll take on board the idea of broadening the domain for ideas wider than just software.

 

[subsonix]

Take a look at UML and think about design without actually doing any programming. It gives the opportunity to think about how different components of a system fits together and weigh the pros and cons of different approaches. IMO it's also a good way to get OOP to stick.

 

[chown33]

Take a look at UML and think about design without actually doing any programming. It gives the opportunity to think about how different components of a system fits together and weigh the pros and cons of different approaches. IMO it's also a good way to get OOP to stick.

UML still has a vocabulary, which must be learned. And in order to learn it, one must have a foundation. Otherwise it's all just squiggly lines and funky boxes with magic words.

I think an informal boxes and lines approach is one possibility, but I don't think it will work that well unless the person is already a visual thinker. For example, some art-teaching books teach the reader to visualize the component shapes (ovals, lines, boxes) and relationships (in front, behind, beside), and actually sketch them out to lay out a drawing. That doesn't mean the skill of seeing those basic shapes is necessarily easy to acquire. Book suggestion: "Drawing on the Right Side of the Brain".

 

[subsonix]

UML still has a vocabulary, which must be learned. And in order to learn it, one must have a foundation. Otherwise it's all just squiggly lines and funky boxes with magic words.

Yes so? How much of a foundation do you think one need? You need to understand what a class, variable and function is, which I presume this person does. You would not need to know all of UML but perhaps use cases, class diagrams and sequence diagrams. I always thought it was a good idea to hide all the details and still be able to discuss and model a system without being overwhelmed by details.

 

[MorphingDragon]

Yes so? How much of a foundation do you think one need? You need to understand what a class, variable and function is, which I presume this person does. You would not need to know all of UML but perhaps use cases, class diagrams and sequence diagrams. I always thought it was a good idea to hide all the details and still be able to discuss and model a system without being overwhelmed by details.

You misunderstand the OP's intentions.

The OP essentially wants to teach the basic Mind Processes, Creative, Critical Thinking and Problem Solving skills applicable to all the Sciences and Engineering fields. He DOESN'T want to teach Software Eng/Comp Sci yet.

UML is superfluous and a distraction at this point.

 

[subsonix]

You misunderstand the OP's intentions.

The OP essentially wants to teach the basic Mind Processes, Creative, Critical Thinking and Problem Solving skills applicable to all the Sciences and Engineering fields.

Really? I'm just giving a possible approach to this, you will get an even higher level of abstraction compared to pseudo code. Get familiar with inheritence, isa, hasa, generalisation/specialisation and so on, these are fundamental concepts. Again, I'm just giving one possible idea, feel free not to use it.

I want him to keep focused on the software engineering concepts and building the foundational skills like braking down a algorithm and organising the behaviour and data. So I want him to use pseudo-code.

I've never seen a book that does this. Does anyone know of one?

Can anyone see a flaw in my approach, or have any other advice?

 

[chown33]

Yes so? How much of a foundation do you think one need? You need to understand what a class, variable and function is, which I presume this person does.

I wouldn't presume that. Think of how often people confuse a class with an instance of a class, just on these forums. Unless one comes from a background where classifying things according to various criteria is commonplace (and sometimes inventing the criteria for classification), then the distinction between class and instance can be confusing. Or the distinction seems superfluous: "All I want is one dog: Ginger. Why define an entire Dog class, when all I want is one?".

 

[MorphingDragon]

Really? I'm just giving a possible approach to this, you will get an even higher level of abstraction compared to pseudo code.

I talked to the OP in PMs.

He wants to teach the person how to fish, not give him a fish. Specific techniques in Software Engineering are just a distraction at this point.

---

Oh Jim,

I just remembered another thing you could try. Every thursday at my University a whole lot of students in both science and engineering from all the disciplines come together and just try find solutions to problems that the University brings forward. Sometimes its been beneficial, like helping create a new technique to research to improve health care at hospitals.

You might not be able to do it on the same scale, but when you friend gets the skills, it could be a good way to practice applying them.

 

[subsonix]

I wouldn't presume that. Think of how often people confuse a class with an instance of a class, just on these forums. Unless one comes from a background where classifying things according to various criteria is commonplace (and sometimes inventing the criteria for classification), then the distinction between class and instance can be confusing. Or the distinction seems superfluous: "All I want is one dog: Ginger. Why define an entire Dog class, when all I want is one?".

Ok, ok, I will leave and shut up! Happy now? We learned about UML about the same time as Java at university. What you describe is a chicken and egg situation, where it's impossible to move on, to learn A you need B but to learn B you have to know A.

 

[jiminaus]

Yes, I really want to him to learn problem solving skills. However, the little UML he learnt, he did seem to take to. Perhaps he is a visual learning/thinker. I'll keep that in mind.


One of the reasons he struggled was because he was expected to research stuff himself, but he was neither told that nor taught how to do that. For example, he was told of javadocs, but never taught how to read and use javadocs. We take it as a basic skill, but watching him try to do made me realise it not all that intuitive. The javadocs can get really technical especially when tried to target both platform users and platform implementers.


His assignment called for him to validate an email address. Using his basic skills he did manage to code a loop to count the number of @'s and reject the email address if the count wasn't 1. He was criticised by his tutor when he presented his assignment for not using a regular expression. But at no point (and keep in mind that this is his very first programming course) was ever even introduced to regular expressions, let alone taught how to use them. When he queried that, his tutor told he should have just googled it.

This experience has left me conflicted. On the one hand, how many times do we get questions here that google would've just answered. On the other hand, if your paying for a course, should you be googling stuff. I'm see that as potentially raising a crop of copy'n'paste coders. If my friend (and I think many of fellow classmates) had of just googled an email regex, they wouldn't have understood what it was or how it worked.


I'm currently looking at Head First Software Development. I'm thinking of starting with a wirl-wind orientation. Then taking him through OOA&D. And finally getting bogged down into algorithms.

 

[MorphingDragon]

Yes, I really want to him to learn problem solving skills. However, the little UML he learnt, he did seem to take to. Perhaps he is a visual learning/thinker. I'll keep that in mind.


One of the reasons he struggled was because he was expected to research stuff himself, but he was neither told that nor taught how to do that. For example, he was told of javadocs, but never taught how to read and use javadocs. We take it as a basic skill, but watching him try to do made me realise it not all that intuitive. The javadocs can get really technical especially when tried to target both platform users and platform implementers.


His assignment called for him to validate an email address. Using his basic skills he did manage to code a loop to count the number of @'s and reject the email address if the count wasn't 1. He was criticised by his tutor when he presented his assignment for not using a regular expression. But at no point (and keep in mind that this is his very first programming course) was ever even introduced to regular expressions, let alone taught how to use them. When he queried that, his tutor told he should have just googled it.

This experience has left me conflicted. On the one hand, how many times do we get questions here that google would've just answered. On the other hand, if your paying for a course, should you be googling stuff. I'm see that as potentially raising a crop of copy'n'paste coders. If my friend (and I think many of fellow classmates) had of just googled an email regex, they wouldn't have understood what it was or how it worked.


I'm currently looking at Head First Software Development. I'm thinking of starting with a wirl-wind orientation. Then taking him through OOA&D. And finally getting bogged down into algorithms.

For the latter part, there is something that comes to mind.

This Book:
http://www.amazon.com/Data-Structur...S6QO/ref=sr_1_5?ie=UTF8&qid=1318813179&sr=8-5

This was the Compulsory text for COMP203 (If that really means anything to you). At the beginning it also has a rather nice introduction to Java, and at the end Swing.

I think it's unfair that they're expected to just Google things like Regular Expressions. There's a lot of language theory thats needed to be known to use them properly that would be hard to find on Google, like what is a Regular Language. What are DFSAs and NFSAs? How do you convert NFSAs to DFSAs. How are Regular Languages, D/NFSAs and Regular Expressions related. What is a Regular Language. What does its notation mean. We had to take an entire paper which was mostly about Regular Languages, Grammars and Turing Machines and hes just expected to Google it?

What the hell? What University is he attending?

Though one thing that truly annoys me is why Java and C# doesn't use the standard regular expressions syntax.

Something simple like 0(0+1)*1 can have all these other completely retarded characters.

 

[macsmurf]

Can anyone see a flaw in my approach, or have any other advice?

It depends on how he learns. I learned programming by programming. Software engineering is a very broad subject and for me that would be difficult to grasp at the time. If you can do it without hand waving that's great but what would be a typical topic?

Why not teach him a bit of Java? Teach him some basic stuff. Have him do a few exercises and then teach him how to improve his answers while identifying trouble spots in his understanding of the subject.

IMHO, all you need is a good Java book.

 

[chown33]

And finally getting bogged down into algorithms.

When you get there, I recommend the "Algorithms in Foo" book(s) by Robert Sedgewick, where "Foo" is actually the name of a programming language, such as C or Java. The book contains concise descriptions of algorithms, uses both diagrams and descriptions, and has a distinctly practical "real world" flavor, distinct from, say, the Knuth books.

I also recommend Edward Tufte's three books on visual communication: "The Visual Display of Quantitative Information", "Envisioning Information", and "Visual Explanations". They're a pleasure to experience, as well as to examine and dissect the graphs and other visuals therein. I don't think I've ever so enjoyed looking at the elements of graphs and charts, and then reading the reasons why the combination works. It's like sitting at a chef's table savoring a meal, while having the ingredients and preparation expertly but clearly explained.

 

[jiminaus]

What the hell? What University is he attending?

I'd better not say.

Why not teach him a bit of Java? Teach him some basic stuff. Have him do a few exercises and then teach him how to improve his answers while identifying trouble spots in his understanding of the subject.

He needs a break from his negative Java experience.

When you get there, I recommend the "Algorithms in Foo" book(s) by Robert Sedgewick, where "Foo" is actually the name of a programming language, such as C or Java. The book contains concise descriptions of algorithms, uses both diagrams and descriptions, and has a distinctly practical "real world" flavor, distinct from, say, the Knuth books.

I also recommend Edward Tufte's three books on visual communication: "The Visual Display of Quantitative Information", "Envisioning Information", and "Visual Explanations". They're a pleasure to experience, as well as to examine and dissect the graphs and other visuals therein. I don't think I've ever so enjoyed looking at the elements of graphs and charts, and then reading the reasons why the combination works. It's like sitting at a chef's table savoring a meal, while having the ingredients and preparation expertly but clearly explained.

Thanks for all the suggestions. I was about to say that I'm not a visual person myself, but that's totally not true. I love diagrams. I'm totally a visual person. What I'm not is artistic.

 

[MorphingDragon]

What I'm not is artistic.

Rubbish. Everyone is artistic. They just need to realize their artistic medium.

#include <stdio.h>
#define PO(o,t)\
(((o>64)&&(o<91))?(((t>96)&&(t<123))?(t-32):(t)):(((t>64)&&(t<91))?(t+32):(t)))  

      void main() {                                       char *poo= "poot",
      *Poo="pootpoot"      ,O[9];int      o,t,T,p;(t=p   =0)||(*O='\0');while
      ((o=       getc(   stdin   ))!=(   EOF))if  ((p==   0)&& (((o>64 )&& (
      o<91       )) ||   ((o>     96 )   &&(o<     123)        ))) (
      t!=8       )&&(O   [t]=     o)&&   (O[++     t] =        '\0')
      ;else {if (t>7)    {for     (T =   0 ; T     <=7;        T++ )
      printf("%c",       PO(*(   O+T),   *(Poo+   T)));       printf
      ("%c",              o);}else if     (t>3){for (T        =0;T<=
      3;T++)                                                  printf
      ("%c",                                                  PO(*(O
      +T),*(                                                  poo+T)

) ) ; printf( "%c" , o ) ; } else  printf ( "%s%c" , O , o )  ; ( t =  0 ) || (
* O =  '\0' ) ; ( o == 60 ) && ( ++p ) ; ( o == 62 ) && (p!=0) && ( --p ) ; } }

 

[jiminaus]

I appreciate your point MorphingDragon, but that hit my anti-"look at me, I write obtuse code, I'm so l33t" nerve.

 

[chown33]

I love diagrams. I'm totally a visual person. What I'm not is artistic.

Because appreciating art is only for artists?

Because utility can't be artistic?

Take a close look at a scythe. That sinuous handle is functional, yet I know of few curves so graceful. That tapered blade is also functional, and also iconic: harvest, autumn, reaping, death.

 

[MorphingDragon]

I appreciate your point MorphingDragon, but that hit my anti-"look at me, I write obtuse code, I'm so l33t" nerve.

I didn't write that code. I don't even know if it works.

It was supposed to be an ironic way to prove a point. Stop ruining everything I've worked so hard to produce. Why don't you do more in the running of this household! D:

(I just copy and pasted it from an ED article)

Because appreciating art is only for artists?

Because utility can't be artistic?

Take a close look at a scythe. That sinuous handle is functional, yet I know of few curves so graceful. That tapered blade is also functional, and also iconic: harvest, autumn, reaping, death.

I have a decorative Katana that looks like this but has the inscription:
"The Good will prevail by the songs of the Innocent Dead" - At least thats What I think it is.

I would keep it up on my wall, but its very valuable and is actually sharp.

Though...

Writing GOOD code is an art.

Writing GREAT code is a Black Art.