2 What We Teach🔗

5 September 2024

(part of the time estimates account for writing some key ideas down)

... or actually what you might learn in this course.

- "I took SE and I got an A but ... my roomate took Sw Dev and learned a lot but he couldn’t explain what he learned."

2.1 How the Course Works🔗

2.1.1 Project🔗

• [2-5min] create a robust, (mildly) distributed sw system, systematically

  • provide simple explanations of the following but defer to future:

    • what is a "sw system": we will explain in the future

    • what is "robust": we will explain in the future

    • what is (mildly) distributed: we will explain in the future

• [2-5min] the process: 10 milestones

  • how each milestone works

    • design the next stage

    • program the current spec

    • integration-test the sw sys as of the preceding milestone

• [2-5min] creating code over time:

  • several times over the course of the semester you will revisit old code

    • to fix bugs

    • to add functionality

  • you will switch partners to practice on-boarding and being on-boarded

2.1.2 TAHBPL🔗

• [5min] 3 warm-up exercises so that you get to know your TA HB PL:

  • corners of this TAHBPL that you might not be aware of, such as

  • command-line args

  • JSON and streaming parsers

  • simple (!) TCP

• [1min] you can then make a decision whether you want to stick with this PL

  • this is how rational decision making works in industry

2.1.3 Social Processes🔗

[1-2min]

• pair programming++

• this course adds new social elements:

• presenting your code base to your peers on a regular basis

• paneling someone else’s code base

• how this works

2.2 So What Can You Learn Here, What do We Want You to Learn🔗

• we want to change your mind(set) about the nature of sw

• the psychology, the sociology, and the technology of creating sw in your TA HB PL

• applying the principles from F I thru III under (time) pressure

  • we have to create the pressure for you; don’t worry we know how to do this

2.2.1 Technical: What you’re likely to remember most ...🔗

[10-15min]

... and what matters least.

• basics:

  • managing git, managing a project (a little bit, esp. technical debt)

  • new IDE tricks

  • searching the web for basic knowledge

  • AI is useful and yet you will hate it

• your programming languages:

  • features you didn’t know about

  • libraries you have never used

  • distinguishing good libraries from bad libraries (JSON, TCP)

• programming:

  • focus matters (a concise clear thesis statement guides the design of every unit of code)

  • tests matter: unit tests, regression tests, integration tests

  • organization matters:

    • keep methods short (Squeak)

    • keep composite methods separate from atomic methods

    • all of this makes code comprehensible and navigatable

• design processes and concepts:

  • design patterns in (large-ish) contexts

  • new design ideas: how to turn a monolithic system into a distributed system:

    • will you ever do so in industry? unlikely

    • what’s the point: most of you will succeed in getting a complex system to run the first time

    • why: because we expose you to systematic design at scale

• designing specifications:

  • we will give you an opportunity to design

  • you will fail

  • you will reflect on the failure and hopefully learn from it

  • one day you will be someone specifying things for others

2.2.2 Sociology of Programming🔗

[7-12min]

• mind set: sw is a message to others across time

  • you

  • others

  • it doesn’t matter: you are responsible for their time (loss)

• real sw dev is thinking; real thinking is hard work in your head (AI can’t)

• pair programming helps with hard work and thinking

• coping with a partner: "he’s so arrogant", "she’s so mean", "he’s so ignorant" ...

  • we have heard it all

  • learning from strong partners: you’re lucky; use every minute to improve yourself

  • learning from a weak partner: you’re lucky; the best way to understand something is to teach

  • coping with absent partner: alert us as soon as it happens a second time

• technical conversations:

  • focus on technical points

  • stay focused

  • using technical terms

  • fighting/shedding the fear of presenting

  • fighting/shedding the fear of speaking up

• presenting:

  • explain what’s visible not fancy ideas

  • listen to technical feedback and react to it

• paneling:

  • comprehend in real time code that goes by; your life depends on it

  • in real time, spot problems; start with little ones and unravel the code to find the big ones

2.2.3 [5 mins] Psychology of Programming 🔗

• F I–III are (supposed to be) teaching "go slow, go systematically, it increases your chances of success"

• this is a hard one on anyone’s psychology

  • it makes the whole process feel like walking in molasses;

  • "we know how to do this quickly"

  • learn from the mistakes and scars of your elders: in the long run, it works better

• negative feedback

  • your partner will expose problems in your thinking

  • your panelists will.

  • your TAs will.

  • your instructor will.

  • you will get frustrated.

• learning to give negative feedback:

  • critique is good; trash talk is bad

  • sandwiching feedback is BS (and I don’t mean the degree you’re getting)

  • be direct; give it in the spirit of

    • help this person improve his product

    • help this person improve himself

• learning to receive negative feedback:

  • egoless programming: "it’s really about delivering a product that doesn’t kill people, not my personality"

  • but since this is college, it’s also about me:

    • Stop! You’re a learner. You can learn.

    • Take a breath.

    • Which aspect is about your work habits?

    • Which of these do you control? Can you improve?

2.3 We’re Here to Critique You Because We Think All of You Can Improve🔗

TOTAL TIME: 40-60min