CSC295.02 2013S, Class 09: Jeremy Sheeley '08

Overview:
* None

Admin:
* Welcome back!

Links:
* http://veracity-scm.com/compare/
* http://www.chem.uiuc.edu/omg/

Some backstory
* Has kids.  Most of his lectures are to his kids, rather than to other
  professionals.
* Has worked about the past dozen years in development
* Has been a developer and a manager and more and ...

Three questions
* Have you been somewhere that requires a dress code?
* Have you seen Back to the Future?
* Have you used or seen profiling tools?

Part One: Version Control
* First project: Add remote access to some Microsoft version control
  project.
* Second project: Their own version control system
* Current project (Veracity); An enterprise-ready version control system?
* What is version control?
  * Dealing with multiple changes to the same codebase?
  * Important operations are add, commit, and diff
  * Branching projects
    Project in beta
    Then release in 1.0
    Start developing 2.0
    But, whoops, there were bugs in 1.0, so we do 1.0.1
    How do we get the changes in 1.0.1 into the 2.0 release?
* Distributed version control: Lots and lots of branches, easy to merge them back together
  * "You merge branches in all the time when working with DVCS"
* [Demonstration of the power of visualizing the branges]
* Version Control Systems are the dress code of software development.  You
  want to work at a place that has a clear "dress code" for your code.
* A desired feature in version control - the ability to check the line history - when was this line last changed?
* Keyframes can be useful.

Next topic: Bugs (and bug tracking software)
* If you get to be the boss of bugs, separate bugs from feature requrests
* Developing a language to talk about bugs is useful
* [Experience: Dealing with 1000's of bugs of various quality.]
* Empower your support people to put a bug in.

Profiling
* What percent of your time is spent in different parts of the code
* Drill down and figure out why the most time consuming parts of your  
  code are slow.
* Don't preemptively optimize.  That is, start by writing code that's easy
  to understand and see if it's fast enough.
* Also useful to do memory allocation profiling.
* One of those dangerous commands
  str = str + "hi";
  * You may see effects of lots of allocation and throwing it away
  * You may see effects of walking to the end of the string each time
* A profiler is much more interesting than Big-O notation.  It tells you
  where you're slow in a much clearer way.

Something else from the getting a job
* "The cover letter is really important.  Gives you an opportunity to say
  why you care about the job. "
* The cover letter is why your personality and excitement come through.
  [He'll send along a cover letter that demonstrates this.]

Side Projects
* Coding is a lot of fun
* Some folks can't stop coding (and that's something to show to people)
* Potential employers care that you love to code
* Side projects - Show that you care and that you have learned something new
* Sometimes his are to scratch an itch, sometimes to learn a new project
* Examples
  + Cribbage game.  Opportunity to learn applets and Java.  (And still runs
    more than a decade later.)
  + Reminder plugin for TiddyWiki system (one that can run on a thumb drive)
  * www.chem.uiuc.edu/omg/  (A chance to learn Flash)
  * Etc.
* Question: How do you learn this stuff?  Mostly online tutorials, Google,
  Stack Overflow, ...
* While a surgeon will never say "Oh, I think I should do neuroscience
  in my spare time", CS folks can often teach themselves new things in 
  their spare time.

End of prepared stuff.  Time for questions.
* Why have you stayed in this job for so long?  Started when his wife was
  in grad school.  But when she finished, they made a conscious decision
  to stay.  Why?  Because he's at a small company and he gets to do a lot
  of different things.
* How should you make it clear that you've used version control, profiling,
  etc.
  * List it on your resume, but "you should know how to put on pants"
    * Every place has their own policy on how to use the version control system
    * Having a presence on github can help - they can see how you use it
* How do you deal with burnout and death marches?
  * JS chose companies that has a good culture
* The treadmill of "there's always something new out there" can also be
  "cool, there's always something new out there"
  * Of course, there are technologies (e.g., Cobol and Fortran) that will
    be around nearly forever.  And you can get into those.
* Why isn't git an enterprise-ready version control system?  (Or why
  is Veracity better.)
  * One big difference (early on): Verifying that you're who you say that
    you are.
  * E.g., some government sites want tobe able to specify who can access
    which files.
* What should your cover letter do?
  * Express excitement for the job
  * Highlight the parts of your resume
  * Your cover letter shouldn't be an afterthought
* How do you show off your side projects?
  * Bullet points in the resume.  A link if it's online.  At the very
    least, a one sentence elevator pitch.
* What should your next side project be?
  * Scratch an itch
  * Or figure out what your want your next job to be and learn the
    technology for it.  (And that gives you a chance to figure out if
    you really want that job.)