►Software Development
▼Lectures
►Lecture 36 :   The End
On this page:
Programming Details
Software Design
Communicatinng, Technically
8.3.0.10
    contents  ← prev  up  next → 

Lecture 36 : The End

Programming Details

This is what you’ll likely remember most. It also accounts for only 5% of your graede.

Here are some things you learned:

  • Get to know your tools.

  • Parsing JSON.

  • Stream parsing is different from batch parsing.

  • Creating a simple drawing GUI.

  • Connecting via TCP.

  • Dealing with exceptions.

  • Dealing with timed pre-emption or threads.

  • You know more about your language.

  • You know more about its libraries.

And there are many other details that you figured out.

Good. But now keep in mind that you will probably not program in this language alone and for all that long. So here is the real lesson:

  • Get to know your language tools as well as possible and as fast as possible.

They are your primary “weapons.”

Software Design

This material should have been (mostly) a review of what you could have learned from Fundamentals I through III.

It’s worth 25-30% of your grade.

At the beginning of the course, we mentioned that a typical developer excuse is

“oh, I didn’t have time to write tests before the deadline. There was too much coding and debugging to do”

In response, we kept telling you

“no, you didn’t meet the coding deadline and you had to debug so much because you didn’t write tests.”

That’s the biggest take-away of all.

Communicatinng, Technically

Technical communication—turning your code into an informative document, presenting code well, and questioning presentations—is the most difficult aspect of making a career out of software development. The course dedicates most in-class time to this topic, because controlled practice is the best way to see it and learn it.

That’s also why we let you vote on this issue. In your mind, there should be two votes. The first is about the grade you want to show to your parents and employers. The second is the one you really deserved. Deep down you know that the grades you voted for aren’t even close to what they mean. Now work on the issues you have discovered during this course.

We allocate 65-70% of your final grade to technical communication, because this is what software development is really all about.

Here are three lessons about presenting code:

  • Start with an overview so your listeners know what you’re talking about and where you’re going with the presentation.

  • Spend time on problematic pieces of code. Avoid obvious code.

  • Repeat questions and criticisms. Then respond with rational code-oriented explanations:

    “No, the code actually works properly. Take a look at ...”

    “Yes, I see what’s wrong. This part breaks the invariant that ...”

And above all, be happy about every design flaw and coding error a review helps you find. It’s not you that is being criticized; it’s your code. And your proper response criticism will improve your skills (and work).

Here are four lessons about looking over code:

  • Slow down the presenters and even ask them to be quiet for a moment.

  • Understand what data representations mean from the code, not oral explanations.

  • Question every function/method that exceeds 10 lines.

  • Ask for tests when it isn’t clear from the name/purpose what the method does. This should provide sample calls and results.

The design recipe’s six-step process is a good guide. So are the above observations about coding.

    contents  ← prev  up  next →