How to Remote Debug Node.js

Finding and fixing bugs is not always easy, especially if someone else wrote the code!

I know that engineers in general have NIH syndrome, but I am one that doesn’t share that view. Technology is an enabler, meaning it’s not an end goal, it is there to provide a service (or at least that is how it is most of the time).

As such, we must sometimes make fixes to our code, or to other people’s code, and that requires debugging. I’ve seen many people use console.log/logger/printf – heck, sometimes they even suggested that I do it that way. But as much as I enjoy waterboarding myself, I’d much rather use a debugger whenever I can. Debugging a node.js project isn’t complex, it just requires a little bit of setup, after which you can debug a local app or even a remote production/staging/test environment.

The first step is to run node.js with the special debug flag and the optional port:


node --debug <-- run node with debugging on port 5858

node --debug=4455 <-- runs node with debugging on port 4455 (you change the port)

node --debug-brk <-- run node with debugging and will break on first statement

If you’re using gulp/nodemon etc, be sure to include those flags in a separate task and/or pass the relevant params to your node app.

// Nodemon task
gulp.task('remote_debug', function () {
return plugins.nodemon({
script: 'server.js',
nodeArgs: ['--harmony', '--debug=5577'],
ext: 'js,html',
});
});

Then you can launch your app, or do it via the task, and your node.js app is running and allowing any debugger to connect to it.

You can use any node.js you choose. I personally use phpstorm/webstorm. While it’s not a perfect product and has some issues, I’ve had very successful debugging sessions with it, and I’ll try and outline how to set that up.

First install webstorm/phpstorm. Both IDEs are great and very similar, except Phpstorm also allows you to edit and work on PHP files, whereas Webstorm mainly concentrates on JS files and web files.

After the install, launch the app and go into the plugin:

Go to File->Settings and in that screen click on the plugins menu item.

plugins_screen

The click on the “Install JetBrains plugin…” button and in the new window either scroll down or search in the top search box for NodeJS plugin.

Once the install is finished, you should have NodeJS installed and you can go ahead and open your projects directory in the IDE. (File->Open Directory, obvious I know, but still… 😉 )

In the last step we need to configure the remote config for our node project.

Click on Run -> Edit Configurations… Menu.

And Click on the + button and select Node.js Remote Debug.

node_remote_debug_new_config

Then in the main window just setup the server address and port (this can be used to debug a remote machine or a local machine)
And you’re all setup to start debugging your server!

node_debug_local

Then click ok, select the configuration from the top right-hand side menu and click on the little bug icon button:

remote_debug_launch

At this stage you’re up and running. If you look at the bottom debug tab you should see you’re connected and then you can put a breakpoint anywhere in your code and solve any bug you come across like a hero (at least in theory! 🙂 ).

***** Important note *****

While Phpstorm/Webstorm is wonderful, I’ve had some issues with debugging performance. This issue relates to some settings in the software so to ensure you do not get frustrated waiting for the first breakpoint to hit, I would suggest you configure Phpstorm/Webstorm as follows:

1) Click on help -> “Find Action” (ctrl + shift + a)
2) In the searchbox type: Registry.
3) Then start typing (or scroll down) and find
js.debugger.v8.use.any.breakpoint – turn off

Happy Hunting!

What is the secret to successful remote software engineering?

My recent experience is that many companies insist on having engineers on site. When they hear “remote” or “not in the office” many people have a very negative perception. They either believe it’s cheap labor or they believe they require people to come into the office each day in order to get good results. While I do understand the bad experience many companies have, this is not always the case. Many are highly successful with distributed remote engineers, or even a remote team. While there are many places with highly talented engineers all over the world I see again and again companies that insist on hiring people only from the local eco-system. And it’s true that there are certain skills that only exist in Silicon Valley / Tel Aviv / NYC and other places where people have successfully built large companies, however a large percent of the work can still be done in a different place where the talent is more loyal, at a lower cost, while not sacrificing the skill-set of the people. It’s very difficult and expensive to hire engineers in SF or NYC or TLV, and as there are so many offers for talented engineers there, retention becomes just as hard as recruiting.

I’ve been highly successful at finding and retaining talent world-wide. I’ve also been working with companies for around 6 years, remotely. Either personally for my own start-up or providing development services for companies. I’d like to share my thoughts on what are the secrets to making such an environment flourish.

My experience with remote teams

Today my time is split between the US, Israel and Eastern Europe. I’ve been working for the past 6 years or so in and with remote environments and teams. I’ve used remote teams to build a complex password manager running on multiple web and mobile platforms, and in 4 years it has reached over 70,000 paying customers. I’ve also been successful at building products for US companies with teams in Eastern Europe and getting results using the latest front-end and back-end technologies.

Working in a remote team as an individual

When I first started out, I had doubts: how does this remote thing even work, if at all? While I’d heard of companies doing it, up until then I was used to waking up in the morning and going into an office. At the time I’d just started working with my new co-founder, with his company that has sold over 3 million dollars of mobile software products, and has worked with over 20 developers from all around the world. I was fascinated by this. Slowly but surely I saw the way he works with them and why he was so successful in doing so. It actually took me a lot of effort to get him to start meeting regularly (as we lived 2 blocks away) and we ended up meeting once every 3-4 weeks in person. We worked night and day and would communicate via skype, email and other methods. We built an amazing product together and got some great offers for partnerships and acquisitions.

Working with a mixture of remote and local teams

For the past 2 years I’ve been working with US-based companies, where most of my development work is done either by me, or by using teams of people in Eastern Europe & the US. I’ve built products and I know that there is a clear difference between a remote single contributor and a remote team. Remote teams are very similar to regular teams, except you might have other people in other countries as your co-developers, product managers, or product owners, and you must manage this process. There are many similarities to being in a remote team and being a remote single contributor. I am not going to go over the differences as I want to focus on the core elements of working with remote teams / single contributors and what is common to making any remote environment work.

The secrets to making remote work

Finding good engineers is hard, no doubt. However using good engineers remotely requires the remote team or remote lead person on that team to have additional skills in order to make it work.

  1. Be Proactive & Driven – This is the single most important quality for any remote engineer / remote team manager. The reason is that when someone is sitting in the office, you can instantly see if someone is not engaged, or stuck. You can just tap him on the shoulder and ask what’s up buddy? Is there anything I can do to help? What are you working on? etc. In remote teams that is not possible, so you need to ensure the person on the other side, and possibly in the other time-zone, is proactive. He will get on call at strange local times, he will email you that something isn’t working. He will flag that he finished his tasks and needs more work, or even let you know that while you’ve planned it before, seems he is finishing early. He will be the type of person tapping himself on the shoulder and not requiring anyone to chase him. EVER! This type of person will make or break your remote / outsource / not in the office work environment.
  2. Resourceful – Resourcefulness goes hand in hand with being pro-active. When working in a remote team, many times you will be faced with integration issues. Integration issues are the ones that take up a lot of time. The back-end RESTAPI that is suppose to return X returns Y. Break. Your mobile app / front-end app cannot read / write the data and the work cannot continue, or perhaps it can? While the proactive perosn would raise the issue, a resourceful one would also find a creative way to continue his work. For example, many times I will create mock data / a mock server when I can’t get the back-end to work. This can mean the difference between 24-48 hours delay in the work, to zero down time, or just 1-2 hours to fix a bug. A resourceful person will find an alternate path to continue his work, create solution to a problem or just move to another task. Resourcefulness is highly important for any engineer, but in remote teams it is vital as it can be the difference between making the remote team work, and reaching the conclusion that remote teams do not work.
  3. Understand Product – Finding a good engineer that can also understand product is very difficult. However when working remotely this not only becomes a nice to have, it becomes vital. Understanding product means thinking in terms of user experience, and what is the easiest and most intuitive way to use the application. Many talented engineers can produce great code per requirements or spec, but do not think in terms of what the user needs. When this happens in house, the product lead can very quickly do a course adjustment: “Hey, I thought that would work, but on second thought let’s scratch that and move this button over here.” With remote teams these iterations might take more time, and so it’s important to have someone you trust that would adjust the course himself. Someone who would understand what the “real requirements are” or what the functional requirements are, and build the right usability for the user. Even if not perfect, then the product person would have a much smaller adjustment to make. Understanding product is not simple, but once you find the right person that can do that, you’re setting yourself up for success with remote teams / engineers.
  4. Result Oriented – Most people hate micromanagement, and while sometimes management does need to intervene in the remote environment, this becomes almost impossible. That is why in remote environments, your engineer / lead must be result oriented. He is not focused on completing a feature, or getting his “workload” ticked off. He should be focused on making sure your business goals are achieved, and that his part is playing it’s role in the global scheme of things. A result oriented person would ask about your business deadlines, when do things need to be done by, and why. This means that person is not about just counting the hours worked, but about making sure he is helping you get to where you need to be.

TimeZone Issues

I’ve worked with teams in many time-zones, and when I meet new customers they always raise that concern. I would like to use the end of this post to crush any time-zone concerns people have. Is having developers in different time-zones a challenge? Sure it is! Does it mean it won’t work? Not necessarily. If you’ve found a good engineer or engineers, that have the list of skills I’ve mentioned, you won’t be suffering from time-zone issues. These types of people, with these skills, are leaders. They will work at many times that overlap with your hours, they will be answering emails at 2am in the morning their time, they will jump on call at strange hours as they commit to your success. Furthermore, how many times do you really need to talk to your engineer 8 hours a day? Most of the time you’d rather not do that, as if you are, you might be hurting your own performance at the same time…

I’m a big believer in remote teams and when done right they are a wonderful asset. The right team / person can build you amazing software that works very well. It’s all of matter of understanding how to work it, and what to look for. I hope this helps and feel free to contact me if you have any questions about creating a successful remote software team.