1 of 15

STDIO Ghana

CABP

STDIO Ghana:

a course on

Software Engineering

2 of 15

STDIO Ghana

CABP

The Course:

Two Weeks, starting today

Each Day:

Warmup, Discussion Session (AM)

Framework Session, Project Work (PM)

Group Activity / Instructor Presentation (evening, optional)

Course concludes with Group Presentations of Product

list the planned warmups; final course handouts should have a detailed list + description of the warmup activities, but these will not be distributed in advance. Emphasize: warmups are NOT optional, and are critical opportunities to practice good habits. They are an opportunity to get in the right headspace for this work, and are a useful way to actually approach work (e.g., practice cleanup in some "dusty" area of code mornings to get yourself ready for the main task of the day)

list the planned discussion+framework sessions, provide handout / link to courses + reading materials. Reading materials are not "read all of these things before class" - they are long term references; however, students should browse them for 30 min - hour each evening before. Make a note about the "?" framework session and that the vote for that will be the end of Friday.

Project work is a big emphasis of the course, will talk more about that later in this session. The course capstone is a product presentation / demonstration to the class, with feedback (targeting ~1 hour for presentation and questions / feedback combined)

Evenings will be off; students are invited to attend planned social events. Handout [link to schedule?] for those. Emphasize the value of decompression, the power of not-thinking about a problem to let you see it fresh, and encourage students to do that even if they don't attend social events

3 of 15

STDIO Ghana

CABP

Instructors

- Carl Pearson

- Dane Brown

- Tom Hladish

4 of 15

STDIO Ghana

CABP

Instructors

- Carl Pearson

- Dane Brown

- Tom Hladish

5 of 15

STDIO Ghana

CABP

Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project.

-- Linus Torvalds

A quote to open this session proper. This is a quote about making software -- and is especially import perspective relative to the projects you will all be undertaking -- but keep it in mind relative to this course (and perhaps life in general). There will be a lot to the next two weeks - try to take it all in, and you will drown. Let it wash over you, and just feel out the edges - don't obsess on anyone piece, just try to arrange the pieces relative to each other. Like how one might start a jigsaw puzzle - find the pieces that are edges or corners, group pieces by color, etc.

However, there's a flipside to this quote: there are good habits that successful software engineers (like Linus) have. These habits make them tend to avoid bad behavior on these small scale projects -- the sort of decisions that make it really hard to ever turn a small project into something more.

6 of 15

STDIO Ghana

CABP

"Normal" coding process?

7 of 15

STDIO Ghana

CABP

The process we want to avoid:

have some data, need some answer

When the answer is obtained, move on to the next problem

do {

slap_code_together()

} while(getAnswer(data) == null);

8 of 15

STDIO Ghana

CABP

Why avoid that?

9 of 15

STDIO Ghana

CABP

Lifecycle associated with Bad Habits:

need answer => code-code-code => get answer*

...need slightly-different answer 6mo later?

try to re-use code-code-code,

...try-harder,

...waste time,

ultimately start from scratch

...some else needs to use code?

they try to re-use code,

...try harder, waste time,

but ultimately start from scratch

...and now don't like you or your work

*not necessarily a right one!

Software engineering is about making products with two features:

- informed confidence in the answers

- reusability

(These two features are fortunately entangled)

It is also an activity among several people - at least your future self (who will likely have a different perspective, no longer be holding the nuance of the code in their head, etc), but also potentially other developers, and likely other users (directly of the software, or indirectly of the answers). "Informed confidence" is about being able to comprehend (and test, potentially) what's going on, which is also a necessary component to re-using code.

n.b. - there are also several practices beyond just the code itself that are necessary to re-use. We'll talk about those in the sessions on version control and using libraries.

10 of 15

STDIO Ghana

CABP

Lifecycle Possible with Good Habits:

frame question =>

code/test/document =>

get answer*

...need slightly-different answer 6mo later?

review docs, write test for new requirements,

code/test/document to pass new + old tests,

deliver

...some else needs to use code?

they review docs, solve their problem

...are so happy with how easy it was,

they give you their modifications

*still not necessarily a right one, but better odds!

11 of 15

STDIO Ghana

CABP

So what ARE these Good Habits?

12 of 15

STDIO Ghana

CABP

Some Good Habits We Will Practice:

- framing the problem (what is needed, when),

also known as: requirements

- breaking big problem into small pieces

(and re-assembling them)

- using the right tools, using the tools right

- delivering a product that is not just an answer

Some Perspectives:

- code as expression of problems, transformations

- (programming) languages as being a way of thinking

- balancing grace vs gritty pragmatism

13 of 15

STDIO Ghana

CABP

bad habits can be faster

obsessing on good habits can make for more work, same crap product

Software Engineering is NOT a formula;

it's a recipe, it's a style

We can learn good vs bad, but

there is a lot of room for taste between them

&

there's no equation to guarantee success

!! WARNING LABEL !!

14 of 15

STDIO Ghana

CABP

What tools do you normally use?

15 of 15

STDIO Ghana

CABP

Some Software Engineer's Tools:

version control

team coordination:

e.g., schedule, assigned tasks

documentation

automation tools:

e.g., build tools

understanding tools:

e.g., syntax highlighting