DEV Community: Amish Shah

Explore IntelliJ IDEA Tools to Debug Multithreaded Java apps

Amish Shah — Tue, 04 Aug 2020 14:07:45 +0000

Debugging concurrency issues or race conditions in your code is usually difficult. This post should give you a good start to debug multithreaded Java applications.

We will learn through an example. Here, I have written a multithreaded program to calculate this math problem:
100! + 100000!

Here is what is happening in the above code: We initialize, name, and start two threads - 'Thread 1' (to calculate 100!) and 'Thread 2' (to calculate 100000!). Then in the main() method, we call thread1.join() so that the main thread won't execute further until 'Thread 1' returns. Similarly, we call thread2.join() Use of Thread.join() method ensures that sum (on line 25) is not calculated until both the threads return, that is, addition is performed only after we get the factorials of 100 and 100000.

Let us explore the IntelliJ IDEA (v. 2019.2.2 (CE)) tools that I often use while debugging a multithreaded app.

Frames and Thread panes

The Debug tool window has Frame pane which consists of a drop down. It focuses on the thread which is currently paused because of the breakpoint and shows the call stack of that thread. In the image below, the breakpoint is in the main() method and the Frame is showing us the call stack for the main thread.

If you want to check call stack of other threads, you can select them from the drop down.

Thread pane shows all the threads that are currently active. Referring to the code above, I have added a breakpoint at thread1.join()(on line 18). When the app pauses at that breakpoint, we should see at least three threads - 'main', 'Thread 1' and 'Thread 2' in this pane (check screenshot below). You can double click on each thread to observe their call stacks.

Selective debugging

Assume that I am troubleshooting a bug in this program and I need to pause execution only for 'Thread 2' as soon as it starts running. This suggests that I need to add a breakpoint on the first line of FactorialCalculatingThread's run() method (line 39). But we will run into a problem - all the threads that encounter the breakpoint will be suspended. This includes 'Thread 1' and 'Thread 2' for our app. I don't want both the threads to pause. Can you think of any other approach?

We can use conditional breakpoint feature. Let us see how. After adding a breakpoint, right-click on it, check 'Suspend' and select 'Thread'. Then we add the condition as shown in the screenshot below. This condition ensures that the debugger would pause the current thread only if that thread's name is 'Thread 2':

Now, debug the program. When the app pauses, only 'Thread 2' is suspended. You can confirm that 'Thread 1' was executed and didn't get suspended through the following steps:

1.In the console, you can verify through the logs that 'Thread 1' ran and exited.

2.In the Threads pane, you can check that there is no 'Thread 1'

The way to configure conditional breakpoints may be different in different IDE versions. But the key idea is to be aware of these features and use them.

Happy debugging!

Follow me on Twitter @amish1502

References:

Is the Coding Interview Preparation Advice Working for You?

Amish Shah — Fri, 31 Jul 2020 17:26:51 +0000

Each one of us has different levels of technical competence, coding background, problem solving skills, preparation time in hand, etc. Coding interview preparation strategies or guidelines by our peers might not always be directly applicable to us.

I prepared for interviews following the strategies recommended by my friends yet couldn’t clear them. I realized, what worked for them needn’t necessarily work for me. I needed something to gauge whether the strategies are working for me and help me realize areas of improvement. After considering my technical competence, available prep time and keenly observing my preparation methods, I developed and experimented with an iterative process to learn whether I am progressing in the right direction and making corrections quickly. I used this process during interview preparation for Amazon and got an offer. I can attribute a significant part of my success to this process.

Iterative Process To Ingest And Evaluate Strategies

Goal Setting Phase

Keep a collection of all the good interview tips, strategies, approaches, techniques and advice that you would have collected. From here onward I will refer to this collection as ‘pointers’. Select one or a few pointers that you think are helpful and worthy. Form a goal to master it. If needed, breakdown a pointer into smaller chunks for your goal.

A goal should be small, doable, timebox-ed and have qualitative or quantitative benchmarks. It is important to consider your in-hand preparation time, programming fundamentals and problem solving skills for setting a benchmark.

Initially, it will be difficult. But you will become better at it gradually, as you assess yourself acutely.

(I will write how I used this model for interview preparation in italics. Focus on how I incorporated the pointer in the process rather than the pointer itself.)

When I was preparing for an interview, I had asked a friend who got into a tech giant for interview tips. He gave me two important pointers. (1) Aim to solve a medium difficulty level problem on Leetcode (an online platform to prepare for coding interview) in 25 minutes. (2) Make sure your code covers all the edge cases.
At that time, my average time to solve a Leetcode medium problem was ~ 45 minutes. I had a good idea about fundamentals of data structures and algorithms, had solved many easy problems and a handful of medium problems on Leetcode.
Considering this, I thought to set a goal — for the next 7 days, of all the medium questions I attempt, I will solve at least 50% of them within 35 minutes. Also, I will ensure 100% coverage, that is, all the test cases must be covered by my solution.

Practice Phase

Once you have a goal set, in this phase, you are incorporating the selected pointer and solving a set of problems from different sources like Leetcode, Topcoder, GeeksForGeeks, etc. Don’t modify your goal midway just because you had a bad day at practice. Unless you have realized that the goal is highly unrealistic at the beginning of your practice phase, don’t change it.

Pen down any mistakes you make for each question. Keep in mind your goal before you sit down for preparation.

With the preparation time I had, I used to solve about 4 medium problems everyday. I used to note the mistakes and solving time for each problem attempted.

Evaluation Phase

This phase is important because you want to know your mistakes before you make them in actual interviews. Once the allotted time is over, be unbiased and evaluate yourself.

Look through your past notes. Try to get an idea whether you are improving because of the selected pointer. Ask yourself: Are you more confident? What are the areas that need improvement?

Depending on the selected pointer, the best way to check whether you improved is to get feedback after a mock interview. If that is not possible, record yourself while solving a problem and evaluate.

If you find any major areas of improvement, benchmark them and include them in the current goal. Timebox this goal and use it for the next iteration. Continue the cycle until you meet all the benchmarks for that goal or you are satisfied with the progress. Only then, select a new pointer and set a goal. Practice. Evaluate. Repeat.

After practicing for 7 days, I reviewed all my notes. I analyzed that I solved only 35% of the problems in less than 35 minutes. I didn’t reach my goal of 50%. Also, I observed that I forgot input validations in many solutions. For the next cycle, I updated my goal to not miss any input validations and to practice for 5 more days. After 5 days, I noticed that I hardly missed any input validations. Of all the problems, 40% were solved in 35 minutes. Though I still didn’t reach the goal of 50%, I was satisfied with my progress and was confident that I will improve as I practice more. Then, I pulled in a new pointer, set a new goal and repeated this cycle.

Key observations

In the example, you can see that I came up with an area of improvement (missing input validation) and included it in the goal for the second cycle. This was a significant area of improvement which was just applicable for me. It was not in the pointer given by my friend. Similarly, you need to figure out what YOU need to improve upon and meticulously work towards it. A peer’s pointer is just a direction, you need to deal with the road bumps on your path.
Time box your practice for an optimal period. If you plan a small period, the results won’t be reliable. If you set a long period, it might be too late to know that the pointer was ineffective.
It is important to remember to not repeat the old mistakes after learning something new. For each problem solved, I used to mention a small note for all the mistakes made. When I used to re-solve old problems (which I highly recommend), I checked if I committed the same mistakes. If I repeated a lot of them, I ensured that I set my next goal with criteria/benchmarks to resolve them. It kept the quality of my preparation consistent before adopting a new pointer.
In my case, I was satisfied and confident with 40% result. As I saw substantial progress, I took up a new pointer and formed a goal to master it.

Cover Image Credit: Andrew Neel from Unsplash

We don’t have to universally agree upon this process. This is just a means (not a protocol) to help you assess if the pointers are adding value to your preparation. You can make your own process that works for you. All the best!

Tips For New Software Engineer Hires For Smoother Onboarding

Amish Shah — Wed, 29 Jul 2020 10:39:41 +0000

As a new hire, initial weeks in a company are challenging. I still remember my first month as a full-time Software Engineer. They gave me a bunch of training materials and wikis, tagged me in unfamiliar email conversations, and included me in meetings which I couldn't follow. Heaps of questions like "Am I working too slow on this task?", "Should I spend time understanding every detail of this wiki?", "Is it okay if I ask this question to my mentor?" cornered me. I suffered from lack of confidence and doubted my ability to work which affected my productivity. Over the years, I got many opportunities to mentor new hires. As I interacted with them, I came to know that many of them also experienced degrees of diffidence and anxiety in the onboarding phase. So, if you are a new hire, the following prescriptions may hopefully make onboarding easier, smoother, and more relaxing for you and your team.

Mentor - a wonderful being!

Generally, you would be assigned a mentor who will help you onboard. Let us say your mentor's name is Ava. She is (or should be) allotted some bandwidth to provide answers to your questions and support for troubleshooting. So, feel free to reach out to her.

In your first one-on-one with Ava, you should ask her to explain a high-level (actually, a very high-level) architecture of the service owned by your team, important downstream and upstream services, and customers.

I believe it is necessary to know about these subjects at the onset so that you get a better insight into future team conversations. During one of my onboardings into a new team, my mentor got too excited and started giving me intricate details of the architecture. If this happens with you, don't get overwhelmed. Listen patiently and grasp the gist of it. It is okay to not understand everything, and it is okay to admit that. In case you are not assigned an onboarding mentor, you can ask a teammate to brief you.

Some teams may share with you written documentation of the services they own. If it is high-level, then read it thoroughly, else do a cursory read and mark it for future reference. For any information thrown your way, unless advised, you shouldn't spend a lot of time to understand the details. Cross the bridge when you come to it. You can refer to the documentation in detail when you work on a task related to it.

Although Ava is your go-to person, you can ask questions to other teammates (which you'd have to, in case you are not assigned an onboarding mentor). It is a good way to break the ice with them.

Wikis, documents, instruction links - Bookmark 'em all 📌!

This point may sound trivial, but it is important. You will be given links to onboarding wikis and instructions for setup. Bookmark them right away so that you can quickly find them in the future. It is probable that you will refer to these wikis frequently during initial development/troubleshooting.

Side-note: Technologies and configurations keep on changing. Parts of the setup wiki you are referring to might be obsolete or incorrect. Make corrections if needed and show ownership!

Ask questions the right way

The objective here is to make sure you get answers quickly, causing the least disturbance to your respondent. At work, everyone is busy and in a big hurry. If you frequently ask Ava things that you could easily find on Google, Stack Overflow or even internal wiki pages, I am sure she would roll her eyes.

Before asking her about any error/issue, search for solutions to fix them on Q&A portals.

Understand that answering questions can be taxing. If you ask Ava a question, she must pause her work, answer your question, and resume back. The effort to rebuild the train of thoughts after resuming work is what I refer to as Context Switch Tax (CST) paid by her to help you. This is paid every time you ask a question. It may sound extremely organized but prepare a list of all the questions and then ask them. Hence, Ava will pay CST a single time. I have received positive feedback for following this approach to ask questions.

Let us jump into what I believe a technical question should comprise of:

Problem statement with the necessary context for your reader

Your question in a direct way

Your research or the approaches you tried

Example: "Hi Ava, I am trying to import project Alpha in IntelliJ. I am using IntelliJ version 17.5. Once I import the project, I get compile errors. Do you know what would be the issue? I changed the project SDK to JDK 11. But, it didn't seem to make a difference."

I recommend to mention your research or approaches because:

You show that you can investigate independently.
Ava will research approaches other than the ones you shared and this would save both of you some time.

Take feedback to know where you stand

It feels satisfactory to receive some feedback to ensure that you are delivering quality results in time. Even if the feedback is not positive, at least you know that you need to improve. The sooner you know that, the better.

In the fourth week or after your first task is completed, I recommend you ask Ava for feedback and incorporate it.

Sometimes, mentors might say that it is too soon to provide any feedback, which should be fine too. Be confident and give your best! 🤘🏽

Handle the meeting madness

Depending on the team culture, you might end up attending a lot of meetings. In each meeting, there is an assortment of information circulated, which is hard to process in the early stages of your job. As soon as the meeting begins, you will likely have a hard time following the yap-yap in the room. You may get confused and exhausted by the time it is half done. Or, if you are me, you will start daydreaming. Here are some pointers to get involved and gain the best out of team meetings:

1) Brainstorm or Review meeting:

The agenda of this type of meeting is to review a design or brainstorm ideas to solve a specific problem.

Before the meeting, if you get a chance, ask the organizer for the agenda. Spend a few minutes understanding it using internal wikis for reference or ask the organizer to give some context.

Usually, in the opening remarks, the driver of the meeting introduces the to-be-discussed-subject and purpose of the meeting. If you don't understand them, ask the driver to give you some more background in layman terms.

The intention behind this is two-fold. Firstly, you are registering the subject and driver of the meeting in your mind. In the future, you can reach out to the driver for any questions regarding the subject discussed. Secondly, participants become aware that a new joinee is in the room. The generous ones will try to make their points in simpler terms so that you can understand.

After the introduction, understand as much as you can for the rest of the meeting. You must observe that your participation and understanding of the meeting conversations improves over the weeks.

2) Project Planning meetings:

If you don't have prior work experience, it is possibly the first time you are involved in planning meetings.

Don't be shy to ask questions about how your team performs task breakdown, scoping, and estimation in these meetings.

In the first few months, your scoping and work effort estimates may be grossly incorrect and it is alright if that happens. Don't get demotivated and continue participating in the discussions. You will get better at it with experience as you get to know your projects and architecture better.

I hope this post provided you with some useful advice to overcome the challenges at the start of your new gig. All the best!

Cover Photo Credit: Simon Abrams on Unsplash
Body Image Credit: Campaign Creators on Unsplash