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 34.
What I Learned in Week 34
First, An email inbox is not a to-do list (this applies to mobile phone, social media, and other messaging tools). I was reading Making Ideas Happen by Scott Belsky when I noticed this sentence (page 61):
However, it becomes impossible nearly impossible to pursue long-term goals when you are guided solely by the most recent email in your inbox or call from a client.
If you are doing both maintenance and product development, you must know what it feels to get an email or phone call about an URGENT issue that must be solved ASAP. It is really easy to stop everything you are doing and start working on this issue. This is often a mistake.
Before dropping everything what you are doing and paying the fine for context switching, you should ask yourself this question:
Is this a catastrophe or just a minor annoyance?
Often you find out that the issue is not urgent at all, and you can fix it after you have finished your current task. Your first goal is to avoid context switching at all costs because humans are not good at it.
Second, Don’t dwell. Act! I have noticed that when I have to fix a problem or bug from my code, sometimes I start to worry that the fix might have unwanted implications to the other parts of the application. This approach has two problems:
- It eats a lot of energy (and can take a lot of time).
- It does not help me to fix the problem or bug.
It is clear that dwelling is fruitless and unproductive. However, because we are humans, some of us have a tendency to dwell anyway. I have noticed that I can avoid this by following these simple steps:
- Create a failing test case.
- Fix the problem. You know that you have fixed it when the failing test case passes.
- Run all tests.
- If all tests pass, you are done.
This works because it helps me to transform the problem (or bug) into actionable steps and trust that my test suite ensures that my fix doesn’t break anything. If you have no tests, read Working Effectively with Legacy Code by Michael Feathers.
Third, you can write parametrized tests with JUnit. Earlier I thought that using TestNG would be the only way to pass parameters to my test methods. This week I ran into a library called JUnitParams. If you want to write parametrized tests with JUnit, you should give JUnitParams a shot.
Fourth, Deploying to production should not be a big deal. I have noticed that some people think that a deployment to production environment is so important task that each deployment must be done on a scheduled date. Unfortunately, this leads into a situation where the production environment is not updated very often. There can be months (in some cases even years) between deployments.
Of course, no one wants to mess up the production environment. That is why we have to be prepared and plan each deployment very carefully. We have to ensure that we have covered every situation before we can do the update. Makes sense, right?
If someone breaks the production environment, it is a good thing. This means that your deployment process is flawed and you can fix it.
I did two deployments to production environment in this week. I had zero problems. I have had my doubts about continuous deployment but this week I realized that I never have problems when I deploy small changes (one feature, few bug fixes, and so on) to production environment.
I think that this has got something to do with the fact that small deployments don’t have as many moving parts as the big ones. That makes it easier to do multiple smaller deployments instead of one big deployment.
I have confession to make. I did those deployments manually. That is why I have to pay attention to moving parts. Of course, this is not the best way to do it because it leaves room for human errors. The good thing is that I can always make it better.
Maybe I am afraid that continuous deployment might work but I know that it is time to find it out.
Fifth, Creating dummy data can be easy and fun. I hate generating dummy data. It is boring and cumbersome. Sure, I can write scripts which do the heavy lifting for me but I still feel that I am wasting my time.
This week I ran into generatedata.com. It is a service which generates dummy data. All you have to do is to
- Specify the structure of the generated data.
- Select the preferred export format and specify how many rows you wan to generate.
- Hit the Generate button.
This service is a time saver! Check it out.
What Did You Learn This Week?
Share your learning experiences or other comments on the comment section.