Meet Brad Martin, Developer Expert for NativeScript

Brad Martin, Developer Expert for NativeScript, talks about his experience creating a consumer-facing app while providing realistic estimates of work.

Brad Martin, well-known for his winning NativeScript plugin contributions, is a Developer Expert for NativeScript hailing from Tennessee.

This post is part of a series featuring our Developer Experts, community members who represent the best of our products. Read about our other featured experts here and meet more DEs here.

What’s your background, professionally?

I have an Associates in Information Tech. from VolState Community College and have been programming for threeyears.

Where are you based and why?

I'm based in Gallatin, Tennessee, just outside of Nashville. The company I work for is located here, it's convenient to the busy Nashville scene for going out but it's enough distance from the city life that it's great for raising a family. My wife and I have three boys under seven so the area just works for us. Great schools and one of the safest cities in the state from various reports in recent years. 

With whom are you working?

I work for Nastek National as Director of Development.

What project are you working on now?

We just launched a revamped Cordova app converted to a NativeScript app (Android | iOS) so I've been spending the majority of my time on that. The other time I'm improving and adding to our .NET C# Web API that we use for the mobile app and the other apps we have such as Quickbooks Connectors, web apps, etc.

What’s the most interesting project you’ve done recently?

This NativeScript app has been the most interesting recent project. I've learned an incredible amount of TypeScript in the months developing the app. Early on with NativeScript I was more focused on learning how NativeScript works and making plugins, but I never actually was on the consumer side of NS making apps. So it's been great to actually enjoy the framework for what it is and make a fast application for Android and iOS that uses MapBox also. That was fun getting it to work with what we needed. We built the backend on our API using a different party for specific routing functionality for our industry and then had to feed that back into the Mapbox portion of the app. It was time consuming but we've had amazing feedback from our users that they're loving the map and the new update we pushed out.

Which of our products do you use and why?

I use NativeScript and am starting to work on bringing some Kendo UI components into a web app at work. I've just been a fan of NativeScript from early on. I loved the fact that plain JS just worked and I didn't need to learn anything new because we all know how that is going now with new frameworks coming out all the time. The other big selling point early on for me was how amazing the core team was willing to help me when I would encounter errors, and 99% of the time those errors were just my fault in not fully understanding the framework although as it was early on (some some were valid bugs of course). Oh boy has NativeScript come a long way in a year!

What are some challenges you are encountering now in your work?

My biggest challenge right now is time management with the various projects going on. I sometimes overwhelm myself and I stress out at times more than I actually should. Once the weekend rolls around, that usually fades away with some rest and family time :).

What’s the biggest software pain point, in your opinion, in the mind of your partners/clients?

For me the biggest pain point with software is setting realistic expectations and understanding estimates from everyone involved, including developers, management and end users. Giving estimates is never fun. For me I always provide estimates with ideal working conditions and most developers know that ideal conditions are never met when you're actually trying to develop something. I probably shouldn't give estimates this way but when asked in a meeting without time to properly outline the project and what is involved the estimate is never going to be very accurate. This puts a strain on myself, the developer, and the others involved when they don't know to anticipate bad things happening along the way of the project.

The other part of this pain point is having to provide estimates to those without knowledge of the development process and workflow. For instance if you have to work on an older application that needs to be compiled in between changes to debug it, that's going to take much more time than working on a new project that has hot reloading or something you can just refresh in a browser. There are ways to improve this I'm sure but for me that's the big pain point with development.