Things I didn't learn at carleton

carleton.md

Things I didn't learn at Carleton {#Things I didn't learn at Carleton}

(..but I wish I had)

• how to run a meeting:
  • Have an agenda & a goal to accomplish.
  • http://leancoffee.org
  • unconference http://unconference.net/how-to-diy-unconference/
• comp sci:
  • unit testing
  • parameter testing
  • source control
  • systems thinking
• generate ideas:
  • Edward de Bono's principles of innovation
  • intersect datasets (that's where interesting things happen)
  • look for constraints (too weak, too complicated) This is how engineers innovate, q.v. TRIZ
• questions that are useful:
  • three questions: What do you want to improve? What will you change? How do you know it worked?
  • If you're wrong, how would you know?
  • What will make a relationship for you? What will break a relationship?
• Anscombe's quartet. Interocular inspection. Try to get a look at what is happening: profiling, visualize data, some second opinion.
• DevOps, After action review, Field Guide to 'Human Error'
• git for 4 and up: https://www.youtube.com/watch?v=1ffBJ4sVUb4
• Inventing on principle: https://www.youtube.com/watch?v=PUv66718DII
  • find a guiding principle for your work, for your life
• pyschopath code: https://legacy.gitbook.com/book/hintjens/psychopathcode/details
• wardley maps for strategy: https://medium.com/wardleymaps/on-being-lost-2ef5f05eb1ec
• Demming: "Drive out fear"
• six thinking hats:https://www.youtube.com/watch?v=719k6SqjAV0
• vim

Matt's List

1. Personalities and work

   • There is not just a continuum of 'techincally skilled' vs. 'technically unskilled.' People not only have a lot of different skills, but their soft skills are really important (more important than tech skills in most ways).
   • Learn what personality type you have and make the most of its strengths (and weaknesses). How do you recharge? How do you balance your slow-brain and your fast-brain?

2. Learn about the process of how good work gets done.

   • e.g. I read Where Good Ideas Come From and it really changed my perspective on how innovation occurs.
   • Some of the modern terminology of agile, scrum, etc. is used pervasively in the community.
   • CI/CD is a key concept behind most of the work I do. It's very different from typical programming assignments.
   • Code reviews! They are they key to longevity of your code.
   • Projects' longevity in the "real world" are much longer and have different considerations than in class projects:
     • Refactors, others need to understand code, etc.

3. Make the job about your capabilities and strengths, not just what is on the job description

   • Most jobs are depicted as 'here the job you should do.' I have always turned the question around (after getting the job) of 'what is the way I can best get great results?' One place hired me as 'a database guy' and I turned it around to an application architect.
   • Learn what places will best fit your strengths. Working for a big name (Facebook, Amazon) may be great for building a resume, but it may actually not be good for your well-being and it may focus you in the wrong area. Focus on finding a place that will make your individual goals and capabilities shine, rather than just thinking about the 'next big job.'

4. Think about the right tool for the job

   • IDEs. They are actually very useful, despite my occasional choice to forego them.
   • Many people just want to use the tool d' jour; personally I find this to be problematic
   • My opinion: Object Oriented programming is actually very bad (at least in the kind of work I do). It took me many years to unlearn OO and still most colleagues have a rough time sloughing off its yoke. Learn how to think non-procedurally. Although JS is procedural at its core, most of my work takes better cues from functional programming (without actually being full FP), and this really helps reduce bugs.

5. Ah yes, bugs. I'd love to teach a course just about bugs.

   • Learn about where bugs come from (e.g. cyclomatic complexity). I read a good book from Microsoft Press where I got some inspiration about how to reduce bugs (although it wasn't the book's content so much as the process of thinking about bugs). :)
   • Learn about strategies for reducing bugs. Mine involve: simple statistics to help predict where bugs will present themselves, developing common routines for a given language/context to reduce bugs (using stateless functions, etc.)
   • Tests: most developers take a long time to learn how to write good tests. Part of this is related to HOW you program in the first place (e.g. stateless functions are much easier to test and guarantee correct than stateful functions). Test-Driven Development (TDD) is a great concept but I've never actually seen it work. But conceptually, that is how a good prorammer programs; set clear goals, then achieve them totally.

6. Presentations and Public Speaking

   • I can't say enough that my successes have largely been built on my ability to:
     • write well,
     • pose valuable insights and questions,
     • and make persuasive presentations.

7. Be aware of what you're getting into with a job

   • e.g. Microsoft "you don't need a life" or Amazon "you join a project until death"

8. Strategic thinking

   • Actually, Carleton does this well IF you take a true variety of classes (I was an English major)
     • Post-Modern American Novel
   • Relate your personal goals with those of the place you're working for