I would like to share the short notes on book content from 14 HABITS OF HIGHLY PRODUCTIVE DEVELOPERS.
I find these habits extremely useful and practical. Happy that I got to read this book. Author shares experience from different techies from top IT companies. There are many things in this book that we can learn from others experience. I have shared the main content of each habit that I can refer later, which could be helpful for others as well.
Habit 1: Look For The Signals
"The oldest, shortest words – yes and no – are those which require the most thought." ― Pythagoras
Cherry-pick what is relevant to you at this point in your career.
Accept the fact that you simply can’t learn everything. Remember, desires are endless; needs are limited. Accept the fact that newer is not always better. There are people working with ancient programming languages and still making a lot of money. Practice daily the subtle art of saying ‘no’. No to that newest library. No to that fancier platform. Say more ‘noes’ so you can say ‘yes’ to what really matters to you.
Take away -
Create a list of all technologies and tools that you would like to learn. Now label each of them with a different priority: “This Week”, “Next Month”, “Next Year”. Whenever you feel like you’re missing out on some new shiny trend, revisit this list and reorganize the priority.
Habit 2: Focus On The Fundamentals
“You can practice shooting eight hours a day, but if your technique is wrong, then all you become is very good at shooting the wrong way. Get the fundamentals down and the level of everything you do will rise.” ― Michael JordanIf you decide to become a great developer, it’s important to understand core concepts such as algorithms, logic, network, accessibility, security, and user experience. You don’t necessarily need them to build your first app, but knowing them will help you build the next ten complex applications you will create in the future.
Take away -
Spend some time researching what the fundamental concepts in your field are. Grab a piece of paper and divide it into two columns. On the left side, list all the knowledge that you already have. On the right side, list all the knowledge that you still need to acquire. Plan a dedicated time of your day to study those concepts.
Habit 3: Teaching Equals Learning
“Power comes not from knowledge kept but from knowledge shared.” ― Bill Gates
The process of digesting content to someone is what makes you really understand it. The process of writing down how to do something is what makes you memorize it. The process of teaching is what makes you truly learn it. The catch is you have to do it in public.
Take away -
Find an event online and submit a presentation. Open a screen share software and record yourself doing something.
Create a blog and share an article. Choose any topic that you want to learn and try to teach it instead.
Habit 4: Be Boring
“Everything that needs to be said has already been said. But, since no one was listening, everything must be said again.” ― Austin Kleon
In the software world, intensity is always praised. How many times have you heard someone say “I spent the whole night programming” and everybody around was impressed? We admire those who go the extra mile to get something done. I can’t count how many times I’ve slept at the office, but I always remember feeling like a superhero after doing so. On the other hand, how many times have you heard someone say "I can’t handle this anymore, I’m burned-out"? There’s a fine line between intensity and burnout. Many of us have already crossed this line and it’s very hard to get back.
Programming is an infinite game, even though most of us act like it’s a finite game. The players are known and unknown — there are always new programmers entering the job market. The rules are changeable — new paradigms emerge, new patterns are invented, new bugs are found. The objective is to keep playing — you can’t win in programming, you can only keep evolving the software to be better, more scalable, and more useful every day.
Programmers who are playing the finite game are focused on their bonus at the end of the year or waiting for that freelance project to end. Whereas programmers who are playing the infinite game are less worried about intensity and are more focused on consistency. They don’t know exactly when they will see results. In fact, different people will show results at different times. Still, without question, they all know it will work.
Take away -
Are you playing a finite or infinite game? How much time do you spend going after short-term gains vs. investing time in long-term outcomes?
Habit 5: Do It For Your Future Self
“When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.” ― Martin Fowler
Don't write the code for current self. Instead, write for your future self. Your current self has all the context needed to understand that block of code, whereas your future self will be involved with other things and probably won’t even remember what that function X means.
Don’t try to be clever, don’t try to code something to make you feel smarter, you don’t need to show off all the new tricks you just learned. Just write readable code. Think about maintainability, and use meaningful names for your classes, functions, and variables. Next time you start developing, ask yourself this question: “Will the future me understand the intention of this code?”
Habit 7: Master The Dark Side
Dark side mentioned here is the business. As a programmer, we tend to think our job as translator who translates the business requirements into system functions. In some places, programmers don't directly interact with clients, instead business analyst will be communicating and come up with the acceptance criterias.
Knowing the business, saves time. Though we spend hours of time before coding, there will be shatters a edge cases comes during development. If we have better understanding on business, those edge cases can be resolved my ourselves, instead of setting up meetings with another business experts for the solution.
Habit 8: Side Projects
“Failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment.” ― Scott Galloway
Some people start side projects to create a new product and eventually build a successful company; however, there are many other reasons why working on side projects can be helpful. And you don’t need to have an entrepreneurial spirit or give up your full-time job to do it.
If you’re just starting your career, side projects can be a tremendous opportunity to grow your portfolio, build a résumé, and showcase your skills.
You can read many books on any particular subject, but there is nothing like getting your hands dirty and side projects can be that sandbox for you.
If you’re already established in your career, side projects can still be very useful. They allow you to experience and learn new skills that your daily work might not offer. Also, there’s no pressure, schedules, or specifications imposed by anyone, which means that you can use all your creativity and have fun doing it.
Habit 9: Mario or Sonic?
Mario is always jumping from one place to the other. If he was a programmer, he would be one of those people who stay at their job for six months and then move to another. Mario is confident and strong, but most of the time he’s really just avoiding dangerous situations. You might think of that one friend who is very smart, but is for some reason afraid of going for that job interview.
On the other hand, Sonic is always willing to face the biggest challenges he can encounter. If he was a programmer, he would be always looking for complex problems to solve and for the most cutting edge technologies to work with. Sonic is fast, he can learn new things, adapt to new challenges, and doesn’t stay behind.
Habit 10: Active Listening
“Wise men speak because they have something to say; Fools because they have to say something.” ― Plato
Habit 11: Don’t Underestimate
“It’s only going to take 5 minutes.” ― Every Developer Ever
There are many reasons for this, let’s see if any of these sound familiar to you.
- We want to impress others: Each of us wants to be recognized by our work. We want to feel important, we want to feel valuable, we want to feel superior. So when it comes time to give an estimate, we say it’s going to take a short amount of time in order to impress others. That way, we hope they will see us differently, they will see us as someone who can finish things faster than others.
- We forget that’s not all about coding: When we are assigned a ticket, the first thing we want to do is go straight to the code. That’s normal, developing is definitely the most exciting part of the job, but we must remember the entire software development lifecycle. We still need time to build, create unit tests, document the fix, merge conflicts, respond to pull request comments, attend daily meetings, etc.
- We don’t focus on one thing: We are often working on multiple projects at the same time, waiting for one person to finish their task, so we can move forward with our part. As a result, we’re constantly being pulled into and out of context. There’s a real cognitive cost associated with constantly having to refocus on your current task. In other words, it takes time to “get into the zone.”
- We think everyone is the same: If you’re a team lead, it’s possible that you might be giving estimates not only for you, but for the rest of your team. It’s common to think in terms of average time it would take to finish a task. However, we must understand that estimates are strictly individual. The time it might take for Jim to finish task X is different from the time it might take Dwight to finish the same task X.
- We can’t handle the pressure: Sometimes it’s not about ourselves.
- External clients, project managers, product owners, or even the CTO might be facing an extremely high pressure from others and they might be transferring that same pressure to you. They need to get something done as soon as possible and it’s hard to show them that it’s not going to be that easy.
Habit 12: Specialist vs. Generalist
Specialist – Pros
- You can achieve very good compensation in that specific field.
- You can typically gain a lot of technical authority in a particular subject
- You need to keep up to date in only one platform/language
Companies are always searching for specialist people in that specific field.
Specialist – Cons
It can be hard to find a position if your specialization is too narrow. If the chosen technology has a risk of becoming obsolete, it will be hard to start from the bottom again. It’s possible that your knowledge may be too company-dependent, which will make it difficult to apply the same skills somewhere else If there’s an urgent need to use another technology, there’s a chance you will take longer to complete a certain task.
Specialist – Work Opportunities
- Senior positions, especially at big companies.
- Research projects at universities.
- Freelancer in a specific field.
Now let’s take a look on how these lists compare to the same lists for a generalist.
Generalist – Pros
- You are used to learning new technologies fast.
- There’s a wide variety of opportunities that you can pursue in different industries.
- If you need a new job, you are flexible and easy to transition
- If you need to switch context to a different type of task, there’s a chance you will find a solution faster than others
Generalist – Cons
- It’s hard to stay updated in a lot of different languages and technologies.
- It’s possible that you’ll take a long time to solve very complex and technology-specific problems.
- It’s difficult to reach a leadership position if you are changing fields constantly.
- Even though it’s easier to find a new position, it may be arduous to show that you’re the best candidate.
Generalist – Work Opportunities Startups/Early stage companies Consultancy opportunities Start your own business
Hopefully these lists will help guide your decision process.
Habit 13: Control Your Variables
“The only thing you sometimes have control over is perspective. You don’t have control over your situation. But you have a choice about how you view it.” ― Chris Pine
If you have a problem and you have control on how to solve it, then you no need to worry about it.
In other case, if you don't have solution then also don't worry since any the problem is not in your control.
This is applicable to the programming problems where problem in your program is in your control which you will have a solution. Problems from external dependencies are not in your control. There are many variables that causes the problems.
All you need to think about if the problem is in your control or not.
Variables that you can control:
- Your thoughts
- Who your friends are
- What you eat and drink
- How you spend your money
- What you do with your time
- How you treat your body
- How much you appreciate the things you already have
Variables that you cannot control:
- The weather
- The economy
- The public health
- How people treat you
- What people think of you
- What people like or dislike
- What happened in the past
Stop wasting time on variables that are out of your control. Focus on the variables that you can change.
Habit 14: Stop Waiting
This is simply a power of now. Dont delay things for tomorrow. Behind every goal, there is a series of tasks that can be done today. Stop waiting.
Comments
Post a Comment