Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.
First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.
Second, I want to share my findings with you. I hope that you can use some of them in your daily work.
Let’s get started and find out what I learned in week 33.
What I learned in Week 33
I love that the goal of the “Mob Programming movement” is not recommend Mob Programming. They are simply sharing what is working for them, and what helps them to improve team work. I think that this is a worthy goal.
If you are interested, you can get more information about Mob Programming by reading the Mob Programming Basics.
Second, Branding matters. I read Brilliant Marketing by Richard Hall this week, and I realized that often developers (including me) are not very good at building their personal brands. Most of them probably don’t even realize why this would be beneficial to them. I used to think this way too but reading Brilliant Marketing opened my eyes.
I realized that every software developer has a personal brand (this applies to other professions as well). This brand determines how he is seen by his colleagues, customers, and potential employers.
Do you see my point?
If you don’t build your personal brand, these persons will see you only as a software developer. There are many developers out there and you are seen as one of them. You might have a reputation as a solid developer but you are essentially just a replaceable cog.
On the other hand, if you build your brand, you can decide how these persons see you. You can build yourself a reputation as an expert of something, and differentiate yourself from the grey mass. Think about Adam Bien. He has branded himself as a Java EE expert and he looks pretty damn impressive.
If you would have to choose between Adam Bien and some random Java EE developer, which one would you love to have in your team?
Exactly. That is why personal branding matters.
Third, If you promote shared code ownership, you should consider removing author information from the source code. Let’s think of a situation where our team consists of three developers:
- Jill is a guru who knows everything there is to know about programming. She is a rock star developer.
- Joe is a regular software developer. He is no guru but he can definitely write solid code.
- Jim is the “weakest” link of our team. He tries very hard but often he does more harm than good.
What happens when a new guy called Jack joins to our team and starts making changes to the source code?
Because Jack knows the abilities of the other team members, the odds are that he makes assumptions about the quality of the code by using the author information. In other words, if Jack notices that the code is written by Jim, he automatically assumes that the code must be shitty (and so on).
This is dangerous because all developers can have bad days and all developers can write shitty code.
Jack probably has no problems fixing the code written by either Jim or Joe. After all, Jim is a moron and Joe is an average developer like himself.
What happens when he notices some weird stuff in the code written by Jill? Does he feel comfortable fixing it or does he assume that there must be reason for it because Jill wrote it? I would put my money on the latter option.
Getting rid of the author information is an easy way to solve this problem. Also, if you really need to know who wrote a specific piece of code, you can get this information from the version control system. Right?
Fourth, Sometimes a thing which sounds too good to be true is true. Calm down. I am not talking about ponzi schemes or multi-level marketing. I am talking about Hazelcast. If you have not heard about it, I recommend that you find out what it is.
It looks very interesting and easy to use, and it has very good testimonials as well. It would be very interesting to use Hazelcast in a real world software project. I hope that I get a chance to do so soon.
Also, If you a Spring developer, you can use Hazelcast as an implementation of the Spring 3.1 cache abstraction.
Fifth, If you don’t feel like coding, reading HackerNews will not help you to get the job done. The odds are that after you have read all interesting stories, you will move on to DZone. Although this can be fun, it is not very productive.
The next time when you feel like this, follow these steps:
- Divide the task into smaller tasks and write them down.
- Finish the first task on your list.
- Remove the task from your list and go back to step 2.
I have noticed that when I don’t feel like coding, the problem is that I cannot focus on a “big” task. Because I cannot focus, it is really hard to get started.
If I split this task into smaller actionable items, I can focus on one small task at the time, and I know exactly what I should do.
Also, I love the moment when I can remove a task from my list. The best part of this method is that the tasks are small. This means that I am removing items from my to-do list all the time!
What Did You Learn This Week?
Share your learning experiences or other comments on the comment section.