The purpose of this course is to scale your software development skills and attitudes from Fundamentals I, II, and OOD to a reasonably large scale of systems building.
You will also learn some specific skills, which will probably be irrelevant in a few short years.
So software creation and life cycle look like this:
-- prototype --+ -- bury
| --- bury
| ------ bury
| ------------ bury
+-- harden -- develop -- test -- deploy -- maintain --maintain --maintain --maintain --
And we know this, which is why we teach a rather different core programming curriculum than most schools (and companies acknowledge this).
– If your software survives the prototype stage,
– it will survive you.
– treat your software well and it will treat you and your successors well.
– if you construct this software systematically,
– you and your successors will have a huge advantage
– creating software systematically
Where this course fits in. It is the last course on your development as a programmer. It is not a software engineering course.
* <--- SW DEV
" first CO-OP
* <--- OOD
Logic ---> * * <--- Fundamentals II
* <--- Fundamentals I
For details, you may wish to read the design rationale at Developing Developers
social/psychological relationship to software
technical/coding relationship to software
– code as if the future maintainer of your code is a psychopath who ...
– this future maintainer might be you, and you don’t want to hate yourself
– code calls for permanent good care, because you never know where it ends up.
Another aspect of code is that it is creative artifact and we are
creators. Arguably, the invention of software has turned millions of people
into “paid creative artists.” An artist creates artifacts; we create
software systems. A typical artist also associates his “ego” with his
You must disassociate your ego from your code and yet use your ego to become a great developer.
Reading The hand-out is a chapter from Weinberger’s Psychology of Programming and it is the only required reading in this course.
You will not learn to use the latest and greatest languages, IDEs, tools,
frameworks, web foobars, and app barfoos. Tech schools teach this
a basic idea of what "plan top-down, build bottom-up" means
an eye for specifying interfaces and protocols ... and their limits
a sense of the value of good tests and test harnesses ... and their limits
- some insight into systems integration:
the planning that goes into it and
the failures that must be planned for.
as a scientist I count those people as my friends who constantly try to
poke a hole into my theories. (The others are just pretenders.)
So this course will therefore resemble a course in the fine arts with permanent crits. Like artists, you will present your code and others will critique it. You will watch such crits and mentally apply the dialogues to your own code base on days when you’re not involved.
- from pair programming
communicating properly with a partner (see ’log book’)
working with someone whose skills differ from yours
working with someone whose personality differs from yours
coping with an irresponsible partner (see ’log book’)
- from presenting your artifacts
what it takes to present code so that others understand quickly
accepting flaws and errors in your own code that others point out
reacting to such discoveries in a positive manner
- from serving on a review panel
reading code on the fly for a problem you know
- discovering problems:
gaps in the design
failure to match specs
how to improve your use of your chosen language