PV168

Course Summary

What have you experienced?

  • Let's try to remember what has happened in PV168
  • What do you think about the real purpose of all that?

Programming is hard

  • It's not that difficult to fulfill
    • compiler's rules
    • current requirements
  • However, it's a completely different game
    • when other people are involved
    • and requirements evolve over time

Essential vs. Accidental Complexity

  • Essential complexity is integral part of the problem
    • cannot be eliminated completely
    • can only be minimized
  • Accidental complexity is what we add to the problem
    • by using inefficient tools
    • by using inefficient methodologies
    • by obscuring the intent in the code

Naming things is hard

  • Good names reveal the intent (semantics)
    • not the data type used (e.g. listEvent)
    • not the physical position (e.g. northPanel)
  • Good names lie in the problem domain
    • not in the solution domain (Computer Science "jargon")
  • Naming things remain hard
    • even for masters
  • Naming is an incremental process

Structure matters

  • The same problem can typically be represented in many different forms
  • Some of them are better than the others
  • Deciphering bad structure is not what you want to do

Interactions with PMs are tough

  • Nothing is as evident/unambiguous as demos
    • misunderstanding are clearly identifiable
    • corrective actions can be planned
  • It's better to demo
    • less functionality but actually working
    • stuff you know why it's there
  • "When in doubt, leave it out" (Josh Bloch)
    • missing things are easy to spot

Functionality vs. Graphics

  • Functionality is important to have first
  • Graphics is also important but not at first
    • investing into it too early is typically waste
    • developers are seldom good visual designers

Duplicity is the Root of all Evil

  • Similarity is not necessarily duplicity
  • Magic numbers and string literals are almost always evil
    • in production code you have to use constants
    • however, in tests the situation is different
  • Repeated code blocks of the same semantics are always evil

Refactoring is hard

  • We need to have solid test suite in order to do it safely
  • Keeping increments small is tough and non-intuitive
  • What you typically do is Rewriting instead

Team work is hard

  • You've typically optimized the amount of code produced
    • Bus factor remains low
    • In PV168 the thing to optimize is the amount of stuff learned
  • In the industry you have to optimize the amount of functionality
    • For really difficult parts it's wise to go in tandem
    • "Doctors never operate alone" (Michael Feathers)
  • Camera turned on is a must for on-line cooperation

Copy & Paste can be dangerous

  • Unless you know what you're doing
  • When using sources such as Stack Overflow, Geeks for Geeks
    • you need to understand the difference in context
    • adapt the proposal to your specific case
    • and get to know the details to be able to defend the solution

Law of the Instrument

If the only tool you have is a hammer, it is tempting to treat
everything as if it were a nail. (Abraham Maslow)

  • Especially newly gained tools/techniques tend to be "hammers"
  • Not a single thing is ultimately good for everything
    • You always need to think in context

Source Code is Text

  • Programming by mouse isn't efficient
    • it's not accurate enough
    • it's not fast enough
    • it's exhausting your mental capacity
  • Programming is only a craft
    • not a science neither an art
  • Craftsmen have good tools and operate them efficiently
    • keyboard is the ideal tool for programmers
    • IDE is the ideal tool for programmers

Thank you for your hard work!

You've learnt a lot about programming already.