Software courses, what should and should not be

Back in the day, i have written about education in this blog. The subject of that post was the dire situation of education system in my country. Since i am a software instructor for the last 3 years, i have written about the ideals of a software training. I am not technically an instructor graduate. That is why i didn't have much opinions of what it should be when it comes to education. But i think i can write something about how a software training should be, since i am a developers who have spent hundreds of ours learning and teaching software development. I also have my own opinion about being a software developer in 6 months at the end of the post :)

But i will start the post by asking "what it shouldn't be". Because software development became a very popular field lately. And people started to think that software development is an easy field and everyone can easily be a software developer because the hype grew so fast. I have written about that particular problem in my post about software. Software teaching is as important as developing a robust software. You need to establish a mindset. But let's first take a look at the common mistakes in the name of software tutoring in this very popular field.

What shouldn't be?

The #1 biggest problem i see these days is putting a constraint or a limit to software learning. Some will say 100 hours is required, some will say 1 month, some will say 3 or 6 months or even a year. I think being a complete software developer doesn't have a specific timeline, it instead have a minimum required time spent. This duration changes according to the nature of the software language. This duration is not related to the skills of the instructor. It is rather an average that depends on the trainee's ability to understand the details. This duration is also not just information transfer time. It is also transferring experience, making mistakes and questionings. Therefore there is a minimum experience to be lived through even for the smartest developer in the world.

Problem #2. What is the target level of the training? There are lots of software trainings these days but they usually don't mention what level are they aiming for you to achieve. Instead, they usually emphasize getting a job. For example, bringing someone without software development knowledge to senior level with a training is impossible. You can aim bumping a mid level to senior or a newly graduate to mid level. If your ship doesn't have a route, winds won't help you.

Problem #3. Project based learning is just coding experience. Sadly, there is a very big population who thinks you can learn software development by building projects. Yes i know you can't be an actual software developer without coming up with ideas on a real project but you can't develop projects without acquiring the ability to produce ideas. I mean they are going the wrong direction. They only acquire the skills of developing a certain domain and solving problems of specific cases. They are talking about battle strategy instead of gathering ammo. Therefore their ammo becomes useless in the battle if the strategy changes.

Problem #4. Library based software development trainings. This occurs a lot in the languages that use libraries and frameworks a lot. The instructor sometimes overlook the software language and teach the libraries in detail. Yes we do use libraries a lot in software development. But our purpose is not just learning the libraries here. Instead, we want to be able to construct ideas on top of them. Sometimes an instructor looks like teaching a language just by exploring libraries. And this is not durable. We have another mistake of instructor too.

Problem #5. Instructor's narrative. As a software developer, i do have my own experience and knowledge at some level. I have my own perception of software development. But i shouldn't impose them like they are the de-facto standard to be applied in every situation in the world. That is why i frequently say "this is my opinion" or "to my knowledge, this is the way but there are others too". If the instructor is not conscious of their duty, they will give you the software development experience of their own world and perception.

Problem #6. Instructor without empathy. The situation here is that instructor believing they are in another level and forgetting they asked the same questions and had the same problems back in the day. It is not logical to ask "what didn't you understand" instead of pondering why they are asking those questions. You need to think if there is another way to explain things. It is not art to know things, but it is an art to explain things. Knowing software doesn't make you a teacher.

What should it be?

I'll try not to talk so certain in this part. Because software languages have their own characteristics and differences. They have different mentalities. It would be wrong to apply the same logic to all languages. Nevertheless, i think there are some basic ground rules here.

An instructor has to have patience, empathy and know how to listen. If you are hesitating to ask questions, it is not a proper training. The instructor must be open to all kinds of questions. Because you can't expect all the good questions from students since they don't have much knowledge about the subject. You should always think "this question is asked but am i sure i know the right answer". You should even be able to reflect this on students. I mean there must be a strong relationship between instructor and students, so that students don't think you are inadequate about the subject, you are just trying to find the right answers all the time.

Of course, the instructor shouldn't have the mindset of learning the bare minimum. They should first apply the code themselves and not be bored with the details. Only software developers can overlook certain subjects if they won't use it later. The instructor is the one that constantly have curiosity and learn without pragmatism, without getting lost in the details.

The instructor must say "this code exists so that we can do these", instead of "to achieve this, we write this code". They must also show what alternatives are there for that piece of code. These will feel too technical and boring. But software development is not just coding. If it were, believe me, there would be millions of them around these days. Our aim is to understand the philosophy of the language too. You must be able to find your way around in the project or a framework without getting lost. You need to be able to rely on your skill at the end of the day.

The instructor must be able to show connections and reasoning. Because at the end of the day, we learn software to be able to apply it to different situations, instead of developing a certain project. You need to be able to explain those situations a little bit. If the instructor just memorizes information and recites them, it is not more than an AI 's capability. We constantly face with choices and problems and we decide based on a certain mindset. So at the end of the training, you must have students that have confidence and can make their own decisions.

You must give opportunity to talk, sometimes force them to talk or give them responsibilities. You must be handing out homework and making exams frequently. Don't get this the wrong way. It is not meant to be homework and punishment based system. On the contrary, this system is based on self-devotion to take your time to understand where students are having trouble. It is not ideal to have a crowded class without being able to listen to any of the students properly. Sometimes you talk about the homeworks, sometimes criticize codes. Sometimes have a brainstorming session. If you ask me, students must be active as much as the instructor.

Software languages usually have some sort of background or a story behind. And languages like Java have concepts of C, C++ and JVM behind it. We first have the question of "why this language exists" at the beginning. If we skip a little bit of a philosophy of the language and consider development as just coding or turning projects into code, we basically skipping the first steps and the basics.

If an instructor is unable to directly answer a question, this may not always mean they are bad. Software development is not a fields that one can know literally everything. In this situation, instead of making up answers or replying "this is a ridiculous question", be honest and say "i have never seen it, let's take a look at it together". Doing it together is important. Because time to time, you may learn new things or look for things or make deductions yourself. This will be a permanent experience if you do things together.

I have mentioned that project based learning is not ideal. But that doesn't mean you shouldn't implement any projects. I think there must be a comprehensive project for around 2 weeks at the end of the training. The students must be able to find their own solutions, or work in pairs, for certain requirements. If they haven't reach that level, that means somethings in the past is lost during the training. Maybe technical and boring stuff were too boring and they weren't able to follow you. The project phase is the part where students ask "what did i get from all this".

Lastly, a software training might be a boring process. With lots of technical details and working day and night and listening a teacher all day long for a long time seems boring to me :D But i don't get boring while teaching a group for 3 months straight. Actually, the problem is students getting bored. Therefore you need to be able to establish long term relationships with people and sometimes include motivational activities to lessons.

Teaching is an art :)

If you ask me, a good teacher has a broader skillset and qualifications than a software developer or even a software architect. The measurement of a teacher is his/her students. We have a number of problems like knowing too much but failing to explain, explaining but failing to convey, trying to convey but failing to establish humane relations or being offensive.

And we have the question of being a software developer in 6 months these days. If you consider the most popular languages like .Net, Java and Python or Javascript + Frontend Frameworks, no one can be a software developer in 6 months. If you already have some form of software development background, you may be as good as a train to ride on rails. The prerequisite for this is an ideal software training and 1 or 2 months of practice. Without any programming or engineering background, if you want to be a proper software developer, one must spend lots of effort for around 1 year. If you want to learn everything yourself from scratch, on websites like youtube or udemy, you are looking at 2 years or something. But during this time, your rivals will be moving forward, faster than you do. So i would say, you can't be a software developer without any training. And i think nobody realizes this yet.

My last personal opinion. I think the most tiresome thing for an instructor is getting questions about subjects that i already explained :) In the learning process, there is no such thing as non-sensical question. But if we have seen and spent time on a certain subject already, sometimes questions feel boring :D This doesn't happen to me much but repeating the same things is mentally tiring. Teaching requires lots of patience. It is basically taking time to learn details, educating yourself first, willing to explain things and being self devoted. See you at the next post :)


Leave a comment