Ideas on on sessions /courses as Prof of Practce for Chandigarh University

 Sometime back I posted an update on LinkedIn about joining Chandigarh University as Professor of Practice.   

I am joining CHANDIGARH UNIVERSITY Computer Science dept as "Professor of Practice". This is part time. I plan to spend about 2 weeks every semester on university campus. And also want to do some online lectures/workshops. There are no particular time commitments. It more about Industry + Academia partnerships and sharing the experiences of with Students.

I also asked about ideas on sessions/courses that students will be interested in. I received lots of comments and suggestions. Here I am collecting all the ideas/suggestions at one place. Over time, I will keep on posting updates whenever I implement an idea/suggestion.

Nitin's Ideas

1. Few sessions in current academic topics related to software architecture and design but with sharing of experiences.
2. A 2 week hands-on workshop for 2nd/3rd year students on "professional software development" starting from using version control, and how to write a spec doc to coding, testing, etc.
3. A 1 week workshop for student teams who want to participate in hackathons.
4. Few sessions on diverse topics like 
• Algorithms in Daily life, 
• Costliest bugs in history of software, 
• Women Pioneers in Computer Science, 
• Basics of Cascading Style Sheets (CSS), 
• Hidden Life of a Google Search Request 
• (re)Inventing the Assembly Language.
• Do/Doing/Done is NOT Kanban
• Using Version Control Effectively

Ideas from Harish Walke

1. few topics around "Agile" too! Fundamentals and basics of Agile
• Typical day or sprint in the life of a Developer
• built-in Quality and what it means in Agile
• Scaling agile 
• Some useful concepts of Value streams, Lean Portfolio, Strategic Themes, WSJF for prioritization, Real life examples of Epic, Capabilities, Features
2. Topics related DevOps
• DevOps with CI/CD.
• TDD, BDD. Different compliances and their inclusion in Features as NFR (Non Functional Requirements)
• SecDevOps with mindset of "Built-in Security"
3.  Innovation mindset related
• Lean Startup, 
• Design thinking, 
• Think Wrong (Don't find solutions for the problems that do not exist).h
4. Use of Tools while doing the course projects
• Task or backlog management tools
• version control tools

Ideas from Anirudha Raste

1. OO eyes!
   Look around you, in your real life to find many OO concepts. People think all OO and other software concepts were 'Created' by software engineers and architects. Whereas, they are already present in real life. Need to see them in software way! Then one will find that software is not so 'alien' to real world.
2. 'Importance of logging while troubleshooting problems at customer end, where you do not have access to customer's environment, customer data, debugging

Ideas from K K George (KKG)

The importance of unit testing and show them how to measure coverage of the unit tests.

Ideas from Manish Ramrakhiani   

• Agile principles
• Rise of Data and related roles in the Data Engineering/Analytics space
• Sharing some of real successful archicture/design of your favorite projects (Nitin's comment ; I was also thinking on these lines. So probably will do this early)

Ideas from Nikhil Karkare

• Automation: automating testing, RPA
• Would sound basic, but using powershell or bash for basic scripting (using awk for example) - (Nitin's comment :  In my opinion, absolutely needed)
• Using any code editor to its full potential (Visual Studio / Replit)

Ideas from Laxmidhar Gaopande

 Some projects split in small teams to work on for 2-3 months after your sessions and review by making them presentation to you along with all.  (Nitin's comment : CU already have a concept of Project Based Course, where students learn by doing a project rather than attending lectures. Will be good ideas to incorporate these in the same framework)

Ideas from Vivek Gupta

1. code readability/ maintainability, 
2. logging/eventing/traceability, log analysis (Nitin's comment : Also suggested by Anirudha Raste)
3. ease of troubleshooting, 
4. importance of code reviews, 
5. threat modeling etc. 

Ideas from Surjit Patra

Go with very basic and core topic like Aniruddha Raste said OO things. But also go 1 level below 

• "How to realize or relate the software way of thinking to a real problem". 
• Or How to visualize the problem, is it from outside/ inside. 
• What is the best approach to find the possible solutions.
•  How to pick the best one out of it. 

If you have any other ideas, please add in comments

Where are the 'average engineer students' ?

I am pondering on this question for last 2 months. I will really like to hear from more people.

I work with Smart India Hackathon and was mentor to teams in Smart India Hackathon and Singapore India Hackathon. Here I work students who are enthusiastic and ready to learn. They are ready to experiment, they are confident, they are not afraid to fail initially to succeed later. Its a joy to work with them.

Obviously they are high in demand in job market and command premium for salaries. Recently I was recruiting for my startup and salaries of many of these students do not fit in our budget. Also lot of our work do not require high end talent. We are looking for students good in attitude and programming aptitude but may not be the best. We are also looking for interns.

For internship, we ask students for solve some small programming problems. I got 40+ responses from 2-3 colleges. 35+ students have copy/pasted the code from internet. Come on guys, I am using google since before your birth. I can find from where you copy/pasted your code in 5 mins. I still talked with 3-4 students and realized that they have not taken any efforts to understand the code. They don't want to take any efforts. I have similar experiences of interacting students with few colleges from Pune (not naming the colleges). These students are essentially at the bottom and practically unemployable.

Where did the average students disappear ??? Expected "normal" distribution will mean small set of students at both extremes and large number of average students in middle. However, now we have 'skewed' distribution with really large number of unemployable students at one end and small number of top notch students at another end and nothing in between. How did we land up in such a bad situation ??

Introspection : am I really a good programmer ?

Sometime back Prateek Jain posted a link to an article title 'Signs that you're a good programmer' on Geometric's internal portal. It has list of 'signs' that you are a good programmer. It made me introspect and see how many signs actually apply to me. Turns out that by this checklist, I am a reasonably good programmer. :-)

I realized I have done following from the list.

1. side projects.
2. Dabbling in other programming languages, especially ones from a different "family".
3. A tendency to suggest wacky and unrealistic solutions in meetings.
4. Willingly throws away weeks or months of work in order to adopt another programmer's superior code.
5. Refers to it as "the code" rather than "my code", unless accepting blame 
6. Doesn't take the spec by its word and tries to find out who wrote it and what they were thinking
7. Owns a book written by a guy called Martin Fowler. (Actually I own multiple books by Martin Fowler)
8. At least 10% or more of their commits reduce the line-count of the project without adding new functionality
9.  Shoves through a crowd at a party to get near someone who just used the word "Bayesian"
10. Envies but doesn't resent people with degrees in something they don't know 
11. Blogs about their work 
12. Not hesitant to pick up a marker and approach a whiteboard 
13. Commits changes to the repository that consist only of comments (but not commented code)
14. Is oblivious to how many times their cubicle-mate has gone for coffee, the bathroom, or the hospital (I don't even hear any sound if I am concentrating on the code).
15.  Not bothered by office politics 
16.  Can predict a bug before the code is ever run  (Done that a few times)
17.  Assumes their own code is the source of a bug before blaming the compiler, library or operating system
18. Disinterested by the outcome of elections 
19. Stock options and bonuses are ineffective 'retain'-ment techniques 

I have done all the signs/symptoms in section "Thinks In Code"

1. In casual conversation their readiest metaphors come from programming constructs (some time back I gave an example of classes/instantiation while explaining 'business offerings')
2. Spends the majority of their time "goofing off", but commits more bug-free code each day than their colleagues
3. Glances over your shoulder and points at a bug in your code with their finger
4. Correctly diagnoses bugs over the phone while drunk or in bed
5. Comes up with their best code while taking a shower*
6. When confronted with an obstinate bug, their instinct is to get up and go for a walk
7. They suddenly pause and stare into space in the middle of a conversation, then abandon you to hurry back to their terminal with no explanation (AKA "A Columbo Moment" or "Gregory House behavior")

Also few signs/symptoms in "Indifferent to Hierarchy"

1. Getting into arguments with the CEO (done that, probably multiple times, still in Geometric because I like working with Geometric CEO, Manu Parpia)
2. Quitting on principle 
3. Organizing teams without permission (I believe its easier to say 'sorry' than get permission)

Overall not a bad score. 

Brian W. Kernighan on debugging

Just discovered this quote of Brian W. Kernighan on Debugging.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it

If you are not sure what is means, here is a stackoverflow discussion about it.
http://stackoverflow.com/questions/1103299/help-me-understand-this-brian-kernighan-quote

And an article explaining the quote by Alfred Thomson
http://blogs.msdn.com/b/alfredth/archive/2009/01/08/are-you-smart-enough-to-debug-your-own-code.aspx

It takes some time to understand this quote. Its a kind of zen Kōan