Skip to main content

Three things I learnt from The Pragmatic Programmer - Chapter 3

Three things that I learnt from the Pragmatic Programmer - Chapter 3.  Link to chapter 1 here. 

1. Achieve editor fluency to make you so much faster. Try to do the following without using the mouse and preferably in one keyboard combo:

    - select characters, words, lines, paragraphs
    - format and indent code
     - comment/uncomment block of code
     - undo and redo changes
    - spilt the editor into multiple panels
    - navigate to a line number
    - search for strings
    - create multiple cursors based on a search term
    - run all tests
    - find compilation errors

2. Debugging but can't find a bug? Use the Binary Chop method - split code in half. Which half causes the bug/gives you unexpected values? Repeat. Most efficient way to track it down.

3. Keep an 'Engineering Daybook' or personal physical notebook. Keep important things you jot down in here; a record of all you're working on at one point in time. A personal addition that I have found useful is adopting the bullet journal style of numbering pages and keeping an index at the end of the book. You never run out of space and can find any note again.

Link to Chapter 4 here.



Comments

  1. Cards are dealt face-up, results time is stored to a minimum and each sport round is accomplished in a suspense-packed 27 seconds. Eight 52-card packs are shuffled collectively and dealt by the croupier from a dealing box, known as a shoe, which releases one card at a time, face down. Among different issues, guests will discover a day by day dose of articles with the latest poker information, live reporting from tournaments, unique videos, podcasts, reviews and bonuses and so much extra. Note that the Tens and the face cards are all counted as zero points. The different cards are worth their face worth and, to not create any misunderstandings, let me make clear that the Ace is counted https://casino.edu.kg/%EC%86%8C%EC%9A%B8%EC%B9%B4%EC%A7%80%EB%85%B8.html as one level.

    ReplyDelete

Post a Comment

Popular posts from this blog

Three things I learnt from The Pragmatic Programmer - Chapter 2

  Chapter 1 link here I'm currently reading  a book called  The Pragmatic Programmer  by David Thomas and Andrew Hunt. The first chapter is an easy read, all common sense. The second chapter starts introducing code and is a little more technical. Here are three things I learnt from the second chapter: 1. Every design principle is there to make your code easier to change (ETC). If you're not sure what code design principles to follow and when, use ETC as a guide. 2. Eliminate effects between unrelated things. (Increase orthogonality - parts of code that don't rely on each other). Keep code decoupled, avoid global variables, avoid similar functions, be careful of third part toolkits. 3. Get good at estimating. Every time you have a task, estimate how long it will take. Think about each little step in the task before you provide an answer. When you finish the task write down how long it took, and if you can, why your estimate was wrong. You'll learn to spot patterns....

Three things I learnt from The Pragmatic Programmer - Chapters 5 and 6

Link to previous chapter here. Here are the three things I learnt from these chapters: 1. I'm at the start of my journey and it's totally okay not to understand everything. I do not have to force myself to read things that make no sense to me yet. At some point I'd love to come back to this book and see what I can learn here as I'm sure its good.  2. Elixr, a functional language, has a pipeline operator that takes the value on its left and insert it as the first parameter of the function on the right. It's a more readable way of transforming data. Thinking of code as a series of nested transformations helps make functions shorter. 3. Be careful with inheritance. It can get messy if not all of a parent's methods are suitable for the child, or if the parent's code will ever be edited. Try things like traits/mixins/delegation/interfaces instead.

Three things I learnt from The Phoenix Project

Recently I read the Phoenix Project by Gene Kim, George Spafford, and Kevin Behr. Here are the things I learnt: 1. I much prefer reading a novel to a textbook. This was a great book to trick my brain into learning DevOps basics without having to read a textbook. I shall have to find more books like this. 2. DevOps is when developers and operations work together to create a seamless process that delivers features quickly. 3. Good IT teams could often use the following: - Kanban boards for visibility of all work that's in progress - Teams where knowledge is shared and documented instead of staying with one person - All people understanding the prioritisation of their tasks - Prioritisation of tasks to follow the goals of the business as a whole - Well designed environments and processes so that changes can be deployed up to multiple times per day into production - Security and controls that are built into deployment - Management that is open to change I enjoyed this book and will rea...