Welcome to the fourth issue of 10 Reads weekly newsletter. Below are the 10 posts that taught me something useful and unique that will help me become better software engineer. Total time to read this newsletter is 190 minutes. Continue reading “Issue 4: 10 Reads, A Handcrafted Weekly Newsletter for Humans”
A couple of weeks back I re-read Rework book by Jason Fried and David Heinemeier Hansson. Following are the twenty lessons that I learned:
Meetings are toxic. Either schedule meeting for 15 mins or 2 hours. The default duration of 1 hour is not the right duration for most meetings.
- Say no to feature requests. Keep your product minimal and coherent. This way you can build a product that is more useful for the client. Creativity is subtraction.
- Look at by-products of your work. Blogging, books, other ideas form from your base work. Don’t miss this opportunity. When you make something , you always make something else
- Hire a better writer. If you have to choose between two programmers then choose the one who is a better writer. Writing requires you to explain things clearly. A good writer knows the important of good communication.
- Embrace laziness. Wait till the right appropriate moment before building a feature.
- Learning from mistake is overrated. Build the smallest possible thing that is successful and then iterate on it. Success is the experience that actually counts.
- Small is not just a stepping-stone. Small is a great destination in itself. The best way to build things is Do things that don’t scale. Sometime small is the right size.
Start making something. What you do is what matters, not what you think or say or plan.
- Embrace constraints. Constraints are advantages in disguise. Limited resources force you to make do with what you’ve got. There’s no room for waste. And that forces you to be creative.
- Start at the epicentre.
- Ignore the details early on. The reason: Detail just don’t buy you anything in the early stages. Besides, you often can’t recognise the details that matter most unit after you start building. That’s when you see what needs more attention. You feel what’s missing. And that’s when you need to pay attention, not sooner. This is the reason I feel discovery sprints are useless. They give an illusion to client that you can magically figure out everything in 2 week without building stuff. The real questions arise once you start building. This is when you can validate your assumptions, clarify doubts, reason along, and try different approaches.
- Be a curator. There’s a lot of stuff off the walls than on the wall. The best is a sub-sub-subset of all the possibilities. Don’t be a hoarder. Be a collector. Creativity is subtraction.
- Focus on what won’t change
- Don’t get obsessed over tools. The content is what matters.
- Sleep 8 hours daily
- Say no by default. Customer is not always right.
- Don’t confuse enthusiasm with priority.
- Learn to say Sorry.
- If everything is high priority then nothing is high priority.
Inspiration is perishable.
I wanted to learn what I wanted to know, but they wanted me to learn for the exam — Albert Einstein
Today, I spent most of my day in meetings, thinking, and preparing backlog so I couldn’t do much code.
Learning 1: IntelliJ Copy Constructor
Today, I was reviewing a piece of code where we had to create an object with 30 fields. The code had a constructor with 30 fields and then in the calling code we were passing those 30 fields. How error prone and tiring is this? A simple example is shown below.
Continue reading “TIL #2 | IntelliJ Copy Constructor Refactoring”
Each day I learn something new while doing software development. From today, I have started documenting them. I will be posting/sharing tips and tricks that I discover.