Skip to main content

Three things I learnt from The Pragmatic Programmer - Chapter 1

 Currently I'm reading a book called The Pragmatic Programmer by David Thomas and Andrew Hunt (20th Anniversary Edition). It's great to read at the start of my career as it shows me what I'm aiming for and why I need to keep learning. 

The three things I've learnt from Chapter 1 are:

  1. My career is my own. I have the power to make it as personally satisfying and rewarding as I can. 
  2. Quality matters, keep on top of it as you go. This includes documentation, build it as you go along. It'll slow you down today, but speed you up next time you look at your code.
  3. Keep learning. Read about new technologies, developments and tools. Try things out. Knowledge can quickly become stale.

Comments

  1. nadrayamashiroNovember 8, 2022 at 7:26 PM

    The on line casino comes full of over 250 on line casino video games, with round 200 of these being slots. This is essentially simply one other reload bonus, however you declare it on the weekend. It’s a massive provide and you can declare this twice over the course of the weekend . Wagering is slightly higher 강원랜드 쪽박걸 than different bonuses, at 40x the combined bonus and deposit amount. The most lucrative is the reload bonus, you will be able to|which you'll} declare an unlimited number of instances.

    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....
2 comments
Read more

Three things I learnt from Animal Crossing

Like many people during lockdown, I ordered a copy of Animal Crossing New Horizons. I also want to escape my real life chores by ... performing daily chores in cuter format? Several months later, I'm no longer playing daily, but each time I do return my experience is a calm, joyful one. Here are the three things I learnt from the game: 1. Don't compare yourself to others. Yes some people have the most gorgeous islands. Some people also have far more free time. Some are more talented. Copy ideas you like, because why not? It's just for you and your friends to enjoy. 2. There's such joy in creativity - try out a little bit, don't jump in attempting to make everything exactly how you planned it from day 1. Perfectionism is the enemy of creativity. 3. If you're playing a game and feel stress more than enjoyment - it's time to take a break. Remember it's only a game, rotten turnips have no negative impact on your real life. This game in particular rewards...
Post a Comment
Read more

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.
Post a Comment
Read more