Mark Heckler

Introducing Mark Heckler

Mark Heckler is a Java Champion, published author, conference speaker, and Spring developer and advocate for Pivotal. He develops innovative, production-ready software at velocity for the cloud and Internet of Things (IoT) applications. Mark has worked with key players in the manufacturing, retail, medical, scientific, telecom, and financial industries and various public sector organizations to develop and deliver critical capabilities on time and on budget. Mark is an open-source software (OSS) contributor and the author/curator of a developer-focused blog (https://www.thehecklers.com). Find Mark on Twitter: @mkheck.

Geertjan Wielenga: When did you realize that you were a developer advocate? Did you set out to do this job?

Becoming a developer advocate

Mark Heckler: This is one of those career fields that it seems you can slide into almost by accident, but I guess it's not really an accident. It does feel a bit more serendipitous than following a carefully plotted path.

There's an old stereotype that those of us who really like to live in the code may not necessarily have the most refined interpersonal skills. It's important to remember, though, that tech is a wide field and categorizations are not overly useful beyond a certain point. There are many of us who love to code and we enjoy the challenge, the thrill, and the intellectual stimulation that coding gives us very viscerally. Then there are people who also really enjoy talking with others and sharing what they do. They really want to be out there mingling and growing from their experiences.

I got into this role by doing a lot of coding and starting to share what I was doing with others. At the micro-level, you have your colleagues. You can say, "Hey, take a look at this." You could tell them that you found an article that was interesting or you found a technique that might also be useful for them. You might then be asked to give a little lunchtime training session or to mentor some junior developers. There are so many ways to start sharing that it almost seems that it just happens.

At some point, you might give a presentation to a local user group or to another group within your company. After that, you might consider attending a conference, but think, "I really don't have much to say; I don't have much to add. What can I bring that anybody would be that interested in?"

Further down the line, you're talking with someone and they say, "You really should present that. That sounds like it would be really useful." Somebody else can see value in your idea.

"You may end up learning more than you shared."

—Mark Heckler

You think, "Probably nobody will show up. I probably won't even get accepted, but sure, I'll throw a talk idea out there." Then you do get accepted. It might be such a stressful event and so different to anything you've ever done before that you might just decide it's not for you. On the other hand, you may find that you got some good feedback and had some positive discussions with people afterwards. You may end up learning more than you shared. To me, that's a huge positive.

Geertjan Wielenga: 20 years ago, there were computers and there were programmers, but this whole developer advocacy role wasn't there. Something must have happened in the meantime. What do you think that was?

Mark Heckler: I think there has been a rise of companies that have more options, more libraries, more framework components, more packaged software, more pieces that you can use in your bespoke or custom software, and so on.

There is now a more heavy-handed marketing push. A little bit of marketing and some kind of presales stuff is good. All of us working in coding and engineering roles can accept that, until it gets to be a deafening roar.

Sometimes, you make contact about a product that you're interested in using and ask for more information. The person on the other end of the line says, "I'm in sales, so I don't know about that." At that point, it becomes a very frustrating relationship. Developer advocates bridge that gap. Typically, most of us are either actively coding or have actively coded.

We know how to apply the tools that we talk about. We can bring the here-are-the-benefits-to-you side of it. We can also bring the here's-how-to-implement-it side of it. That, to me, is invaluable.

When I was just doing development work and not doing advocacy at all, I highly prized the opportunity to talk to somebody who could actually address why I might or might not want to use a product, how best to leverage it, and licensing constraints. I think developer advocacy came into being because the marketing suddenly became much bigger, which necessitated this new role.

Geertjan Wielenga: In your case, there was a point where you were an engineer. How did that transition actually happen to becoming a developer advocate?

From engineering to advocacy

Mark Heckler: Initially, I was doing full-time engineering work and then presenting on the side. I was occasionally taking a few days here and there to travel to present at events and conferences. I think many people realized that I had this public-facing level of activities that I was doing. I was out there enough that they felt I was either doing this full-time or maybe should be.

"I was offered a full-time gig doing, essentially, what I was already doing in my spare time."

—Mark Heckler

A good friend of mine reached out and said, "I know you're doing this anyway, so how would you like to make this your official role?" That sounded pretty great, so I interviewed and I was offered a full-time gig doing, essentially, what I was already doing in my spare time.

Geertjan Wielenga: Did you study software engineering or something completely different?

Mark Heckler: Actually, I studied mathematics, computer science, and, interestingly enough, some business. I even got an MBA.

I know that sometimes surprises people, but the value that we produce in software isn't inherently in the software: it's in what it allows us to do as a company for our customers/users/stakeholders. That provides meaning and utility. I felt that an MBA would be something that would help me to understand and get my head around that better.

There are many different types of coursework in any study program, but I tended to gravitate towards the economics and finance topics. Those areas are not entirely dissimilar from engineering: you have numerical discipline in terms of the calculation of formulas and assessing various different variables that go into making a particular outcome. I found it really fascinating.

Geertjan Wielenga: Isn't that economics background something that you have been using in a presentation that you've been giving lately?

Mark Heckler: Yes, it is! I toyed with the idea of doing that for several years. I finally got around to doing it. The title is something like "This Stuff Is Cool, but How Do I Get My Company to Do It?" The idea is that we, in our industry, tend to go to a conference and hear something, or read something in a trade journal, and think, "This is exactly what we need to do in our company!"

The problem is that it's very hard for us to quantify that and justify a new approach. When we go to leadership, we will get questions coming back to us about the value and the cost. These are very logical questions, but we don't have great responses. We might just say, "We should do this because this is the future! This is the way development is going to go!"

My talk is about learning how to assess things financially. I discuss applying financial formulas and assigning values. It's about taking qualitative measures and turning them into quantitative measures, which is very uncomfortable, very imprecise, and far more clinical than the real world allows. Yet, we have to start somewhere.

Geertjan Wielenga: Can you give one concrete example of how you can apply this approach?

Mark Heckler: If you were able to go from a release cycle of once per year to once per month, what would that mean for your particular organization? Once per month means 12 releases per year. Could you roll out more functionality faster? Well, obviously you could. You're going to release at least a portion of that functionality in one month's time versus 12 months' time.

The next chunk will be in two months' time versus 12 months' time. A very proven fact is that this increases fidelity.

In many cases, you're working with somebody who in 12 months' time may not even be your subject matter expert. The requirements might shift or the person might leave the company.

If you fulfill some of that functionality within four weeks, the chances of requirements drift are much lower. If you do somehow miss the mark, you've missed it on this much functionality versus that much functionality. So, it's much easier to correct. Those are very understandable concepts.

"I always tell people to never try to make a bad idea look good."

—Mark Heckler

When someone asks you how to quantify an idea, that's when you start getting into some numbers. For example, if we're 80% closer on our requirements, if we don't have X amount of rework, how many person months does that equate to? How much do we pay each person on average? When you apply actual numbers to all of those measures, you begin to see this rather convincing picture emerge. Although, it's only convincing if it's a good idea. I always tell people to never try to make a bad idea look good.

All of the predictions are based on assumptions, so these assumptions need to be based on facts. Better assumptions going in means more accurate results coming out, which gives everybody a much more accurate basis upon which to discuss changes.

These conversations help to bridge that divide. The financial types hold the purse strings and so often in this field, we see them as the enemy. But, let's face it, if they didn't make sure everything ran right in our organization, the organization wouldn't still be there. The more we all work together, the better off we all will be.

Geertjan Wielenga: On the subject of organizations, what kind of organization pays you to go around the world to talk about the economics of software development?

Mark Heckler: A very forward-thinking organization! I think it makes sense for an organization to put people out there to say, "Here are tools you may find useful."

Geertjan Wielenga: Could you be speaking on this topic and working for any company out there?

Mark Heckler: Yes, this is something that applies universally. At any time, you have to compete for resources. Even externally to our field, any organization has only X amount of money that it can spend on software upgrades and further reach for existing systems. Those are all competing concerns. I think that topic has pretty broad applicability.

Geertjan Wielenga: What are some of the other topics that you talk about in your role?

Mark's talk topics

Mark Heckler: I talk about how to solve problems better. Most of that revolves around using Spring or different components that may be considered within the framework, like Spring Data, Spring Boot, or Spring Cloud.

Geertjan Wielenga: What kind of reaction do you get to the economics talk and also to your Spring talks?

Mark Heckler: The economics talk is a little bit of an outlier. You have people who are looking for something very specific, like a better way to communicate with their management, finance teams, or business units. I get a really good response from them. For the Spring-based talks, there are many problems that are out there that, regardless of their industry, people are trying to solve: better communication, less latency, and more scalability.

The Spring talks fit really well with those topics, so I get good feedback.

Geertjan Wielenga: Are there other activities that are part of your role as a developer advocate?

Mark Heckler: Every organization does things a little bit differently, but one of the aspects that really attracted me to Pivotal was that you're not just asked to be in front of people at events or at conferences: you also have the opportunity to give workshops with customers and organizations that are actively and wholeheartedly using your software stack.

This is where you really get the trial by fire in terms of your tooling. Just because something isn't in 90% of use cases, it doesn't mean that it's not still very valid. Maybe you didn't foresee something happening, but it makes a lot of sense when you meet with customers. That's when you have your assumptions checked. You think, "Wow, that's actually brilliant. Let's try to work this out and make this a little easier for more people."

"If you don't have that variety, you're leaving a huge amount of knowledge and feedback on the table."

—Mark Heckler

Not all companies allow you to speak to people in that way, which is a shame. Some developer advocates just want to write articles and publish them, or they only want to speak in front of small or large groups. But if you don't have that variety, you're leaving a huge amount of knowledge and feedback on the table, and it's being wasted.

Geertjan Wielenga: Do you also do blogging and social media in your role?

Mark Heckler: I don't do as much blogging as I would like. I need to do more of that because I do enjoy writing. But I tweet all the time and far more often than maybe I should. I live on Twitter. Using Twitter is easier. You can dash something off when you're running to catch an airplane, which is pretty useful. It's harder to blog when you're running to a terminal. But I think each different tool has its place.

Diversity in tasks

Geertjan Wielenga: Would you say that it's the diversity of activities that really appeals to people going into developer advocacy?

Mark Heckler: Yes, and it's interesting that you bring that up. To give a really offbeat example, I ordered a keyboard not that long ago and crowdfunded it. It's a great developer keyboard and the construction is superb.

The problem is that the wrist pads that go on it do not detach easily. I literally have to screw them on or off. It's an always-on or always-off design, which means that traveling and portability is pretty much out the window. The keyboard is also unique in terms of its key configuration layout. You have a special key to do this and a special key to do that, which you don't see on any other keyboard.

My first thought at the time was that if you're a developer who sits for eight hours a day in one chair, in one location, this keyboard would be pretty awesome. Even though it's an oddball configuration, you could fully leverage that to really do some neat stuff.

But if you're somebody who tends to do many different things in a day, hopping from machine to machine, and location to location, that is a disaster. It's a great keyboard for certain use cases and a horrible keyboard for others. That's really what our job is: a nice role for some people who really like the constant interruption, but one that certainly involves a lot of change. You're in a field that's constantly changing.

Geertjan Wielenga: The flip side of that is burnout. Do you have any tips or insights into how to avoid getting burnout from all the different tasks, activities, and deadlines?

Mark Heckler: What's the old saying? Physician, heal thyself. I think much of it comes down to knowing what you need and what will help you to maintain your little island of sanity in the midst of the chaos.

Everybody has a different answer for what they need. For me, I have always eaten, slept, and breathed tech. I've always loved to code. There were a few years when I toned it down.

I took more time away in the evenings and on weekends. I still do that; there are times when I will step away and just have an unplugged day. The truth is that I enjoy this, so, to me, anytime I unplug has the potential to be as stressful or more stressful than when I'm plugged in.

I do think it's important to have different interests and different things that excite you, but if you do thrive on just staying always in the code, then spend time on that. A love of tech could even involve keeping up with the latest cellphones. There's a new range of iPhones coming out. That's pretty exciting to some folks.

It may not interest others at all. But if that's something that excites you, even if it's not strictly in the developer advocate arena, that's valid.

You can also do something fun to recharge. It might be reading fiction or going out on long hikes in the wilderness. Whatever helps you to step away and come back fresh is great.

I think that stress happens regardless of your role or your field. If you're an accountant or a marketing person, for example, you're always going to have those political whirlwinds around you in your company. You're just trying to block that out, so you can get your job done and make a positive contribution.

"This is a very creative discipline. It's still a discipline, but you're creating something that wasn't there moments ago."

—Mark Heckler

I love to point out to people who aren't in our field, or who are just starting out in our field, that this is a very creative discipline. It's still a discipline, but you're creating something that wasn't there moments ago. This is something that many people find incredibly rewarding.

Geertjan Wielenga: Now that we've talked about all these different highs, what would you see as being some of the lows of this position? What are some things to be aware of before entering this field?

Negative aspects of advocacy

Mark Heckler: I think you hit the big one with burnout. That's not necessarily burnout in terms of just having to get away because you can't take this anymore: it could also be in terms of the pace.

There are 27 things you could be doing at any one point in time. It could be seen as both a positive and a negative that there are 27 things you need to be doing. I always tell people in our field that the good news is you'll never be bored. The bad news is you'll never catch up. I think if you let that loom over you, then it can really bother you.

Plenty of folks love the "Inbox Zero" idea. I'm not a huge devotee because I feel that then you're just obsessed with a number that may or may not be good or bad, depending on the context. Right now, the inbox that I have open is at 2,943 unread emails. Frankly, some of those emails are ones that have rolled in when I've been traveling. I probably glanced at them and decided that they're not important.

If having unread emails is the kind of thing that gets to you, then this role is not for you. You can never catch up on every possible thing. You can never clean off your task list entirely.

If that unsettles you, it will just add to your stress levels and your hatred of all things. If you can embrace developer advocacy as a role that's constantly challenging you, giving you new things to look at, consider, do, and learn, you may never catch up, but you'll never be bored either.

Geertjan Wielenga: Would you say that there is a place in this profession for people who are more introverted?

Mark Heckler: Yes, sometimes you do need to wall off and be alone with your thoughts. Then there will be other times when it makes far more sense to work with others to try to achieve a goal. No single key unlocks every door.

Geertjan Wielenga: One of the downsides of working in developer advocacy is that you're constantly chasing the next shiny thing, but often, your customers are perfectly happy using whatever the tech was three versions ago. How do you get that balance between constantly telling people to get the latest thing and accepting that they could be perfectly happy where they are now?

Mark Heckler: In any field, you have people who are really good at their job and people who are just okay at their job. One of the marks of a good developer advocate is not constantly pushing things that people don't need.

Let's imagine we have a very stable piece of software that may have been created 10 years ago, but it's constantly being updated. It's not being updated because we want to try to push out the old: it's being updated because developers are saying, "Hey, we really need this capability. Why doesn't it do this?"

When you actually build that capability in, that's the point where a developer advocate can come in and say, "Look, you were talking about how you really needed this kind of routing or this kind of rate limiting. It's in there now. When you get a chance to update, try it. Let us know what you think."

This is one of the things that open source really helps with. Many times, your customers or your users will submit a pull request to say, "We want this in there. We think that this should be done this way. Accept our code." So, they're actually driving some of the changes.

There's value in showing the new stuff because it solves problems that haven't already been solved. You've added some capability that has been requested by one customer or maybe by several. So, if you do your job right, you're not constantly making your users feel bad for where they are with your tooling. You're just showing them that there are capabilities that they can more fully leverage.

Geertjan Wielenga: What do you do when the direction of the company you work for conflicts with your own vision or your own sense of what's right?

Mark Heckler: I will have to say that I haven't run into this. I guess everybody's barometer is a little bit different. For me, if I felt that I was working for an organization that didn't have its customers' best interests at heart, I would leave.

Geertjan Wielenga: How strongly would you have to disagree with your company before quitting? That would be an extreme step.

Quitting your job

Mark Heckler: There is a guy who is the vice president at a company in my home area. One thing that he wrote was published on Medium a few months ago.

It was a bit of career advice he got early on in his career: "If you see something wrong in your organization and you can't change your organization, then move to a different organization."

I do think that you're right and quitting your job is a drastic step. But if you see something wrong, you have a responsibility to yourself, if nothing else. Even if that issue is something very small and you think that it probably only bothers you, you have to raise that issue.

"Sometimes, companies do get things wrong and you have the chance to fix them."

—Mark Heckler

You should say, "This looks a little funny to me. Let's talk about this. Can you explain to me why this is a good thing?" You raise the question and you raise the issue. Sometimes, companies do get things wrong and you have the chance to fix them. Occasionally, the company just has the wrong perception and that gets adjusted. But if the policy is really wrong and it's taking advantage of customers, or somehow abusing public trust, at that point you have to make a decision.

You have to think, "Do I feel comfortable being complicit?" If you don't feel comfortable with the choices that the company is making, you need to move on.

That's a good idea just for your own sanity, as well as because you want to do right by others. In the worst-case scenario, you have to just disassociate yourself.

Geertjan Wielenga: This particular question is especially relevant to developer advocates because we tend to be the public face of the company, especially for developers, who are critical people. If you are on stage on a Monday morning after some decision was made over the weekend that everyone knows about, you're the one figure that anyone can actually see from that company. What do you do when the inevitable questions are put to you?

Mark Heckler: If you work for a much larger company than I do currently, there are likely far more opportunities for one group within your company to do something that maybe every other group in the company disagrees with.

There will be many times in those situations when you will go out on stage and you don't have an answer for difficult questions. At that point, I always believe honesty is the best policy. Your best answer could be to say, "I found out about this at the same time you did: two days ago. But you can bet I'm going to be looking into this. I want to know how it affects me, how it affects you, and how it affects those of us who are trying to just deploy better software faster."

Geertjan Wielenga: How do you deal with the weaker features of the tech that you promote? Do you ignore them and only focus on the strengths? If you're doing a demo and you know that there's a bug at some stage, do you skirt past it carefully?

Do you say that there's something wrong, but it will be fixed in the next release? How do you deal with these kinds of situations?

Mark Heckler: I'm not as polished and skilled as some people are. Usually, what I do is swerve right into the bug by accident! That said, I have, all kidding aside, literally discovered regressions in front of a crowded room. It just happens. When it comes to software, as much as you can test and have rigorous procedures in place, you're going to occasionally have something slip through.

Coming back to your strong points and weak points question, there are going to be certain things that a particular component does really well and other things that it either ignores or that are out of its scope. Maybe it's a potential future enhancement. Maybe people aren't even sure if that change really belongs in there. I usually try to point everything out that I'm aware of.

If, as developer advocates, we don't point weaknesses out, I don't think we gain credibility, but, more importantly than that, I don't think we help anybody by hiding them. We can't just think, "I hope they don't notice this until they're in too deep and they can't rewrite." That's crazy. We've all fallen into that situation completely by accident. It's not a comfortable feeling. So, you certainly don't want to have fallen into that because somebody suckered you into it.

Geertjan Wielenga: At the same time, you don't want to go out of your way to expose all the bugs that you're aware of. You're not going to do a tour through all the bugs of your product live on stage. How do you strike that balance?

Honesty about bugs

Mark Heckler: I will say that at Pivotal, we have well-developed components that very sharp people have poured years of effort and development into. So, the rough edges aren't usually as much of a problem.

When it comes to new projects, we have Project Riff and Knative. Things like that are being spun up and created early on. In those cases, you pretty much expect there to be a few edges that poke out and surprise you. When you do run into those issues, it makes sense to just say, "If you're using this in this use case, you might want to reconsider until this particular thing gets fleshed out better."

"I don't think you do anybody any favors by not telling them when there are gaps."

—Mark Heckler

These projects are still in early development. Obviously, you want to put your best foot forwards, but ultimately, I don't think you do anybody any favors by not telling them when there are gaps, or particular issues that are being addressed, or issues that may not be being addressed depending on particular priorities.

Geertjan Wielenga: It seems to me that many people might think that being a developer advocate means knowing absolutely everything about the tech. They might be worried that if they don't know everything, there's a good chance that somebody in the audience is going to ask a question that exposes that.

The fear of being in a room of 500 people when someone asks an unexpected question can be a blocker for people who are interested in moving into developer advocacy. What's your response to that?

Mark Heckler: There's always the possibility that you will get asked a question that you can't answer, but then there's always that possibility in life. That could happen when you're talking to your spouse or your boss. You won't know the answer to every question, but so what? I think all of us, especially developer advocates, but really anybody in our field, get into this line of work because we're curious people. The idea that we can know everything about anything is an absolute fallacy to begin with. We don't know everything and that isn't possible, but we still like the idea of trying.

"If somebody asks you a question that you don't know the answer to, that's a positive."

—Mark Heckler

This is something that I've told my kids for years: "Today is the least informed you'll ever be. Tomorrow you'll know more than you did today and the next day you'll know more than you did the day before." That's a good thing. If somebody asks you a question that you don't know the answer to, that's a positive because it gives you a chance to learn something new and to share that.

I look at Spring and it's huge, with a vast number of components, products, and tools. Nobody could know everything about all of that. Luckily, I've got great team members.

I can say, "I don't understand this particular thing. Can you explain it to me?" We are all a team and this is truly a team sport.

Geertjan Wielenga: With all that in mind, then, if you're up on stage at the end of your session and someone asks a question that you don't know the answer to, what do you say?

Mark Heckler: I just ask them to ping me and follow up with me. I want to get them the right answer. If I know the general concept, I say, "Here's what I would do in this case, but let me get you a more specific example."

Maybe somebody is asking about securing something, but they're using a security mechanism you're not personally familiar with. You could reply, "Let me connect you with somebody who can actually answer your particular question."

Geertjan Wielenga: I think that often, the assumption is that if you don't know the whole answer, you don't know anything. Would you agree?

Handling unexpected questions

Mark Heckler: Yes, but everybody who's been in this field for any length of time has had somebody ask a question that initially seemed to have a very easy answer. In that situation, you think that you know the answer from start to finish and you're so proud of yourself. You give the answer, then they reply, "Yeah, but we're using X."

You think, "Oh my gosh, I didn't know anyone was using X for that!" Again, assumptions are your enemy.

You should never, even when you think you have the full answer, give your answer right away. There may be unique constraints that invalidate everything you thought you were providing of value. It's a good idea to learn more and get the full scoop before you actually prescribe something that will solve the pain area.

Geertjan Wielenga: Let's say that someone reading this discussion thinks that this is an interesting career path to follow. What traits or skills do they need to have?

Mark Heckler: You need a love of learning, you need a curiosity about how to make things do things, and you need to know how to code. I say you need to learn to code because that's my background, but, obviously, this is a broad field. So, if there's something that you particularly enjoy in this field, pursue that. Once you start down the path of enjoying something and sharing it, you're already well on the way to becoming a developer advocate. That could be either officially or unofficially in some capacity. In many cases, developer advocacy just happens as natural professional growth in our field. It's all about sharing knowledge.

Geertjan Wielenga: Thank you, Mark Heckler.