Blog

I Wasted Days Because I Refused to Ask for Help

This week I have been working on a how-to article providing the step-by-step of building a Spring Boot starter. After reading through the documentation on the subject, I decided to start to put together my code example. A simple example of creating a starter to handle security configuration within an organization. Below is a live shot of me struggling with Spring Boot’s auto-configuration:

Person struggling to climb over fence instead of opening a gate

Like many developers, struggling with technology isn’t exactly an uncommon event as here is another occurrence from only last month:

After pounding my head on this auto-configuration issue, looking at the documentation, looking at other code examples, I eventually realized I needed help, so I “phoned a friend”:  Screen Shot 2019-12-19 at 8.42.07 AM

If you look at the timestamps, within a minute my colleague Ozzy Osbourne, yes that’s his real name, provided me with my answer. Like is so often the case, the problem was a trivial syntax issue, I incorrectly named a file spring.fractories instead of spring.factories.

Scope the Problem and Find an Expert

person saying they are an expertAsking for help is important, but there are better and worse ways of asking for it. In my case when I asked for help, I went to a slack channel devoted to Spring experts. I also knew the problem was with auto configuration. This gave my colleagues the information they needed to know where to look in my code. I scoped the problem, and turned to the people who knew the area well, leading to its rapid resolution.

Because IBM is a huge organization, I am fortunate in having many experts to turn to when I have a question. This is very different from my previous experience; most organizations I have worked at have numbered, in total, in the hundreds or low thousands, with the technical staff only a subset of that. If you work at a smaller organization where the number of “experts” you can turn to is limited I would recommend engaging in your local meetups to expand your network. I have gotten to many developers in my area, Kansas City, this way, which I have turned to for help on more than a few occasions.

Note: If you are a Java developer in the Kansas City area be sure to check out the Kansas City JUG.

Regardless when asking for helping either inside or outside of your organization you should be conscientious of those you are asking for help from. Everyone has their own priorities, so it’s important to scope a problem down as much as reasonably possible and also provide useful background information. This helps you as you don’t have to spend time re-treading tried solutions or chasing down red-herrings.

Pay it Forward

Humans operate on concepts of trust, reciprocity, and mutual respect. As you ask for help, it’s important to be mindful that you are asking someone else to take time out of their day to help you with something. When you scope a problem before asking for help, it shows a sign of respect to who you asked for help that you made a real attempt to resolve the issue yourself first (i.e. you value their time).

As you ask for help, you should also be attentive to others when they need help. I may not be in a position soon to repay my colleague directly by helping him with an issue, but I can still repay some of that goodwill by helping the next person who might ask a question in the Spring experts channel, or some other area I have expertise in.

Conclusion

Most of all what I hope you take from this article is it is ok to ask for help. Like many developers early in my career I was at times overly cautious about asking for help. I was afraid that by asking questions I might be revealing my ignorance and/or that I didn’t know what I was doing (see: imposter syndrome). It is something that every developer needs to works to get over. Even after a dozen years as a professional developer I still have been tripped up by a simple spelling mistake that cost me hours. Next time you find yourself spinning your wheels, scope the problem and find an expert.

Reflections on One Year in as a Developer Advocate

I recently completed a three part series looking back over my first year as a developer advocate. Links and summary of each article in the series is below.

Reflections on One Year in as a Developer Advocate; Content

Creating content is where you will be spending much of your day-to-day as a developer advocate. Content can take many forms, presentations, blog articles, documentation, etc. In this entry in the series we look at the goals, concerns, and difficulties, of developing content.

Read more…

Reflections on One Year in as a Developer Advocate; Travel

For many entering developer advocacy they will see a significant increase in the amount of travel they will do. When you are traveling a couple dozen or more times a year, you will want to re-evaluate your priorities and preparations before and during a trip. I share some of my experience over the past year to make work travel a bit more enjoyable.

Read more…

Reflections on One Year in as a Developer Advocate; Advocating for Developers

What is developer advocacy? As Emily Freeman said, it’s more than just speaking good. In this article I reflect on what it means to advocate for developers, and how my view has evolved over the past year.

Read more…

 

 

Reflections on One Year in as a Developer Advocate; Advocating for Developers

In my opinion, someone in developer relations serves as an advocate for the tech community within their company.

-Emily Freeman

For the final entry in my series looking back over my first year as a developer advocate we will look at what it means to advocate for developers. I would like to thank Emily Freeman for her blog article. Her article, particularly the quote above, led me to re-evaluate my role as a developer advocate. Initially I felt my role was to advocate for my organization (IBM), to developers. From reading Emily’s article, I appreciated that my position really has two roles; advocating for my organization, but also advocating within my organization on behalf of developers. In this article we will look at what each of these roles mean.

Speaking Developerish

Developer advocacy is in some ways a new field. While its roots go back over a decade, the field has seen a surge in popularity in recent years which has transformed how it is viewed. Going from a niche role, to a critical element in how organizations develop their products and services.

Developer advocates are critical because we can connect with developers in terms they relate to and provide information they need. I feel this is at times overly romanticized, suggesting developers are somehow “above” traditional marketing. Closer to reality is that often such marketing is tailored towards a different audience; managers and executives. Developers might care generally about licensing, costs associated with using a product, or if support contracts are available, but often aren’t interested in the details as that goes into decision making that is beyond their role. Developers are interested in how a product will improve their workflows or solve a problem they are facing. For that they need technical information; blog articles, hands-on tutorials, that step through what problem a product is attempting to solve and how to use it.

Developer advocates are able to answer these questions because they have an engineering background. Advocates have experienced those emergency pushes to production, worked with difficult to use or poorly documented products, or spent days reading through logs and code trying to find the root cause of a bug. While every developer’s story is unique, we all have shared experiences and advocates can draw on that experience to create content, deliver presentations, and talk with other developers using terms and language they are comfortable with.

For many hoping to enter the developer advocacy field, our first interaction with a developer advocate was from watching them give a presentation at a conference or meetup group. As Emily, from the title of her article says, developer advocacy is more than the art of speaking good, however presentations are important for two key things; informing developers of new tools or features and as an opportunity for connecting with the development community.

Community Engagement

Much in the way that, broadly defined, problem solving is central to the success of being a developer, a willingness to engage with the developer community is central to the success of a developer advocate. Building and maintaining connections is the means by which advocates can receive feedback on products their organization supports and how they can improve them going into the future. However the developer community isn’t just external, but internal as well.

Returning to Emily’s article, while developer advocacy is often thought to be an external facing role, the internal facing side is critical as well. When we receive feedback, we need to know who to channel that feedback towards. Here my experience might differ somewhat from many developer advocates. IBM, at about 400K employees, is roughly the size of a small city, this along with being a truly global organization, the “I” does after-all stand for International, means I will be in an endless cycle of learning of new teams and names. Still no matter the size of your organization, there are going to be teams and people you will need to know, don’t neglect the building of internal connections as you work to build your external ones.

A Canary in a Coal Mine Coding in Anger

Getting feedback from external developers is great. It is however a somewhat lengthy and infrequent feedback cycle. Agile, TDD, Continuous Delivery, these were concepts created to shorten the feedback cycle for development. Shorter feedback cycles lead to not only faster improvement, but the rapid iterative nature leads often to a higher quality product. As a developer advocate the way we can shorten the feedback cycle is by ourselves actively using the products our organization supports.

Sam makes a great point that you should actively use the documentation your organization produced when using your organization’s products. This is after all how you would want external users to engage with a product your organization supports. While a popular product will have its own share of blogs and other content on the web explaining how to use it, the documentation your organization produces should be seen as the best source for how to use a product. This can only happen though if that documentation is “tested”, i.e. actively used and then improved upon.

However I would also view Sam’s advice through the prism of a specific activity for developer advocates to perform from time to time. As I mentioned in the first article in the series developer advocates are often stretched pretty thin, so you should actively seek help within your organization. This helps not only to reduce your workload, but reinforce the internal connections you will need to build, and also as a form of feedback in and of itself. While working on some recent workshops while looking for help on how to use the products I would be using in the workshop, I was also able to give feedback on how they might be improved going forward.

Conclusion

It has been quite an experience looking back on my first year as a developer advocate. Outside of when I first started my career as a professional developer, where it took a couple of years before felt like I hit my stride, switching roles to developer advocate has also been a steep learning curve. When I went from developer role to developer role, it felt like I could hit my stride within a couple months of joining a new organization, as a developer advocate I feel like I am only just now hitting my stride a year in. While there is still a lot for me to learn and I look forward to doing some more articles looking back on two years of developer advocacy, I feel like I now have a much better idea on the road forward.

If you are thinking of entering, or just entered the role of developer advocacy I hope these articles have provided some insight on the work, life, and responsibilities of what it is to be a developer advocate. If you want to hear more, my DMs are always open on twitter @BillyKorando.

Spring Cloud Contract, Completing the Consumer Driven Contracts Story

A new release of Spring Cloud, Hoxton, is gathering steam. Part of Milestone 2 release is a feature I have been looking forward to for Spring Cloud Contract (SCC), the ability to generate stubs directly off of contracts. In this article we are going to take a look at what this means and how to use this new feature.

Consumer Driven Contracts in a Polyglot World

Last year SCC implemented the functionality that allowed clients to write contracts without having to be familiar with the Java tech stack. This was done by supporting a YAML DSL for defining contracts and providing two Docker images, one that could consume contracts and validates a service is meeting the contracts and the other that can consume stubs so it could act as a mock of the service the contracts were written for. For more information on this, check out this blog article by Marcin Grzejszczak.

A common approach in many Java shops is to have a backend written in Java (i.e. the producer service), but the frontend UI (i.e. the consumer) written in JavaScript. By removing the reliance on Java specific technologies when writing contracts, this made writing contracts more accessible to frontend developers. By allowing the consumers to write the contracts you are able to do a work flow called Consumer Driven Contract Development. The consumers write a contract, telling a producer what they need in a format that can be validated programmatically, and then a producer developer can write, or update, the producer service to meet the requirements of the contract.

Consumer Driven Contract Development is a desirable development paradigm because it is a “pull” rather than “push” concept. Instead of producers “guessing” what a consumer might need, you allow the consumers to define the behavior they need from the producer. This helps to producers avoid building APIs consumers don’t need, or building APIs that are difficult for consumers to, well, consume.

We Keep Waiting on the Service to Change

While SCC’s changes allowed consumers to write contracts with technologies they were more familiar with, the consumer driven contract story was still a bit hollow. SCC had a Docker images that could act as a mock of the service, however it relied upon the availability of stubs. These stubs were only generated after the contracts were validated against the producer service confirming the producer service fulfilled the contracts.

A developer building a consumer could write a contract, but until the producer service actually implemented the behavior defined in the contract, the consumer wouldn’t be able to use the mock service. This could stall development on the consumer side for days or even longer depending on the workload and priorities of the developers of the producer service. If we are going to have consumer driven contracts, we need to allow consumers to be able to develop independently of producers. The contracts are still there, and since both parties are developing based on the contract, they should still arrive at the same point.

Running a Mock Service from Contracts

With the M2 Spring Hoxton release, SCC added the functionality to run a mock service directly from contracts. I have been presenting this year about Spring Cloud Contract, and how it can be used to do Collaborative Contract Driven Development, here is my presentation from Spring I/O in Barcelona back in May. I’m happy that now with the ability to run the mock service directly from contracts, this better completes the story in my presentation.

I have created a GitHub project for demonstrating how to use Spring Cloud Contract. The project has a repo for the producer, client (consumer), and a repo for the contracts. If you clone the client repo, you can see SCC’s new functionality in action by executing the run-produce-service-mock-no-stubs.sh script. The script contains the following:

docker run --rm \
-e "STUBRUNNER_IDS=com.ibm.developer:produce-service:+:stubs:9876" \
-e "STUBRUNNER_REPOSITORY_ROOT=git://https://github.com/wkorando/produce-contracts.git" \
-e "STUBRUNNER_STUBS_MODE=REMOTE" \
-e "STUBRUNNER_GENERATE_STUBS=TRUE" \
-p "8083:8083" \
-p "9876:9876" \
springcloud/spring-cloud-contract-stub-runner:2.2.0.BUILD-SNAPSHOT

This script is running a docker image and passing in some environment variables. Let’s take a look at some of the key values being passed in:

  • ​​​​​STUBRUNNER_REPOSITORY_ROOT This is telling the Docker image where the contracts reside
  • STUBRUNNER_STUBS_MODE This is telling the docker image the contracts are in a remote location (in this case a GitHub repo)
  • STUBRUNNER_GENERATE_STUBS This is variable that was added that tells the Docker image to build stubs directly off the contracts we sent
  • -p "9876:9876" This is telling the Docker image to have the mock service running on port 9876

Executing the script will have a mock service running on http://localhost:9876. If you look at the documentation that we generate from the contracts, you can see some of what the mock service is capable of doing. If you call the url http://localhost:9876/api/v1/produce you will get back a JSON list of produce items. You can also see how this works when working with a real UI by cloning this repository and running <span class="s1">npm run start:contract.

Conclusion

The GA release of Spring Cloud Hoxton should be available later this fall. The ability to generate stubs straight from contracts is a significant step forward in completing the Consumer Driven story. It’s a feature I have been looking forward to since I first started with with Spring Cloud Contract a few years back. If you are attending Spring One Platform next week and are interested in learning more about contract driven development, be sure to swing by my presentation on Thursday Collaborative Contract Driven Development.

Reflections on One Year in as a Developer Advocate; Travel

In the second part of my series on of my first year as a developer advocate I will take a look at one of the big privileges and hassles of developer advocacy; travel. Let’s take a look at some ways to make travel less stressful and more enjoyable.

Dealing with Security

Airport security is something everyone hates about air travel, particularly if you are a US citizen, or traveling in the US often. Long lines, having to pull apart your carefully packed bag, and taking off your shoes is frustrating. Going through customs can be a difficult experience as well as lines can become extremely long if several flights arrive at the same time.

A way to make dealing with security much easier is to get TSA Pre-check, and if you will be traveling in and out of the US often, Global Entry (note TSA Pre-check comes with Global Entry).  For a $85 fee, or $100 if you get Global Entry, and filling out a form you will be able to go through the TSA Pre-check line which means you don’t have to remove large electronics, nor liquids from your bag, and can keep your shoes on. TSA Pre-check lines are also typically shorter and unsurprisingly move faster than normal security. TSA Pre-check/Global Entry are easily some of the best money spent when it comes to making travel more enjoyable (or at least less aggravating).

A couple more notes when it comes to international travel. Even non-US citizens/residents can apply for Global Entry and TSA Pre-Check. Several countries also have similar systems to Global Entry*, depending on where your organization may be sending you, it may be worth it to apply for one of those programs as well. Many of these programs are also similarly available to non-citizens.

Benefits to Loyalty

When traveling only a few times a year, if you were like me, you’d prioritized cost and convenience over brand when booking flights or hotels. At this level of travel it makes sense to prioritize those factors as you will likely not accrue enough frequent flyer miles or hotel nights to get many benefits from being a member of a loyalty program, but when you are making dozens of trips a year you might want to reconsider your priorities around how you book travel.

Your primary air carrier or hotel provider might be chosen for you by your organization. However if you do get to choose, you will want to do some research. There are three major air alliances: Star, SkyTeam, OneWorld, if you live near an airport that is a hub to an airline that is part of one of those alliances that will probably be your best choice. You will get more flight options as we as more direct flights. Considerations might be where you are flying to. If you are like me and you home airport is a “spoke“, then research to see which airline best suits your needs. For hotels, the three biggest super chains are: Marriott, Hilton, and IHG. Marriott probably has the best coverage of the three, but often they all have presence in the same markets. If you are traveling outside of North America/Europe your hotel chain choices might change a bit.

With both airlines and hotels, initially the benefits of loyalty seem pretty minimal. Slightly earlier boarding and free bottled water aren’t exactly significant benefits, but persistence can start to payoff. Getting to the second, third, and above loyalty tiers start to provide pretty significant benefits. For airlines this can mean upgrades to higher classes, much earlier boarding (which is good if you have a carry-on), and more flexibility when it comes to re-arranging travel plans. For hotels you can get upgraded to a nicer room, more flexibility with checkout, and free breakfast. In both cases you can also start to accrue a large number of loyalty points which can be used for vacations, upgrades, or bringing your significant other with you on a trip.

A tradeoff to getting to the highest tiers of loyalty can mean occasional inconvenience. Your primary air carrier might not always offer the most convenient flights, your primary hotel chain might not always be the closest to a conference venue. On a recent trip to Oslo, I stayed at a hotel that was a 30 minute bus ride both ways each day, but it was also a long stay so I earned some much needed nights. It’s a balancing act, sometimes it might make sense to to take the more inconvenient flight or hotel, other times not.

Pack a “Go Bag”

I can be a bit forgetful at times. I have forgotten noise cancelling headphones, sunglasses, and a few other items here and there. While it’s a bit annoying to forget these things, I never forgotten anything too important because I always have it pre-packed in my “go bag”. My go bag includes all the toiletries I need, under garments, exercise clothes (more on that in a little), adapters, and a number of other important essentials.

Building a “go bag” will require a bit of an investment as it will mean buying duplicates of a number of items you typically only need “one”, but it’s money well spent. When I am preparing for a trip I typically on need pack a few pairs of pants and shirts. Not only does this only take a few minutes, but is also way less stressful. I’m not thinking if I packed enough socks, underwear or if I remembered a toothbrush and toothpaste? My go bag has about 80% of what I need, which means only having to worry about the last 20%.

Staying Healthy

Travel is hard on your body. There is the jet lag, airports and airplanes are the breeding ground for germs (I once saw a parent change a baby on the tray table in a plane), and being away from home can make it hard to maintain healthy routines. So let’s look at how to stay healthy while you travel.

mobile_pharamacy.png

Allergies, headaches, colds, stomach/digestive problems, they are inevitably going to happen. Being prepared is important, so I bought a pill case that has medicine for handling some of the common concerns. This has come in handy for me a number of times, I have also been able to help friends and colleagues who were dealing with a headache or upset stomach. It’s small and convenient. Though, in some of that earned wisdom, I would recommend getting larger pill case to carry a larger amount/variety of medicine.

In the previous section on the “go bag” I mention I always have exercise clothes packed and ready to go. This was a lesson learned after forgetting exercise shoes, or shorts, or shirts. I have had trips were I have been gone for several days to even weeks, and I can start to feel it in my body when I have gone that long with out any real activity. Exercise is important element to a healthy lifestyle and I would recommend exercising in the morning as you have more control over your schedule at that time. If exercising isn’t an option, find opportunities to walk. Travel is one of the privileges of being a developer advocate, take the opportunity and advantage by walking around and visiting some of the scenic locations of the places you are visiting.

Finally try to make healthy choices when eating while traveling. When it comes to weight the saying goes, it’s ounces in the gym and pounds in the kitchen. It’s not always easy, but eating fruit for breakfast, limiting the number of drinks you have at social (or avoiding drinking or the social hour altogether), can make a difference, especially in the aggregate. The social activities are definitely another perk of being a developer advocate, but be careful to not over indulge.

Trying to Be Green(er)

In a world that is starting to feel the effects of climate change, I am definitely conscious that my recent career change to developer advocacy has enormously increased my carbon footprint. There is no way around that a round trip from the US to Europe creates roughly 1 ton of CO2 per passenger. So what are some ways we can be responsible global citizens in our careers?

A very direct way would be buying carbon offsets. Here is a recent article answering some questions if you are interested in that area. Another advantage of buying carbon offsets is that is artificially increases the cost of travel for you. If you are spending hundreds of dollars purchasing carbon offsets, you might reconsider some trips, or trying to find ways to combine them.

On the subject of combining trips, while it doesn’t reduce carbon emissions, one can be more “efficient” with those emissions. As Roy’s tweet above suggests, flying across the world for a single talk isn’t very environmentally conscious. If you are having to make that trip, try reaching out to user groups in the nearby area. When submitting to a conference, see if there are other conferences nearby that can be included in the same trip. Try reaching out to the client facing members of your organization to see if there are any of your clients in the area, or if an event of some kind can be organized. Flying around the world to give a single presentation can feel wasteful, flying around the world to give two, three, four, or more presentations can start to feel more sensible.

Travel Self-Care

Travel can be very taxing, so it’s important to consider self-care when traveling. If you are crossing many time zones, adding an extra day to the start of the travel to allow you time to acclimate to the new timezone can be helpful. Additionally setting clear boundaries with your organization making sure you have enough time at home for recovery and spending time with friends and family can also be important.

There can be a feeling that taking this extra time is “selfish”, but it makes good sense even from the perspective of your organization. If you are severely sleep deprived when giving a presentation, running a workshop, or helping out with booth duties, you’re not going to be delivering quality work. Additionally if you are feeling overly stressed or run down because you don’t have time to recover from travel, that’s going to lead to burnout and/or inability to produce content/prepare for future travel.

Sometimes pushing for this additional time or cost associated with travel will require self-advocacy toward management, but appreciate that your well-being is important for both yourself and your organization.

Some Final Tips

  • If you are in a city for only a single night, stay at an airport hotel. Airport hotels will typically have a free shuttle service and because they are closer you also can sleep in later and generally worry less about making it to the airport in time.
  • Pack an umbrella. It’s lighter, smaller, and better at keeping you dry than a raincoat, you can also just keep it in your backpack so it’s always handy. My umbrella has saved me a number of times when inclement weather suddenly showed up.
  • Airport lounge access can make long layovers a bit more enjoyable. Membership fees are often several hundred dollars, check to see if your organization would cover membership, if not most airlines let you use points in-lieu of money.
  • Loyalty programs often rollover by the calendar year. While you will maintain your same status level into the new year, you will start again at 0 for building up frequent flyer miles and hotel nights for status. As you get towards the end of the year, check to make sure you aren’t going to miss out on reaching a desired status level tier, otherwise it will have to wait until probably late next year before you reach it.
  • There is no real disadvantage to being member to multiple loyalty programs, so it’s a good idea to join all of them so at least you can accumulate points and status when you aren’t able to fly/stay with your primary.
  • Be sure to carry credit cards from multiple carriers, particularly Master Card and Visa. Also having a bank card with you is helpful as some countries strongly favor bank cards or so you can withdraw cash if needed (and not incur huge fees).

Conclusion

Travel can be fun, it can also be a hassle. You do enough travel and you inevitably run have some bad experiences. There are ways though of making those bad experiences less bad and also reducing some of the stress around travel. Joining programs to make it easier to go through security, pre-packing some of your luggage, and taking advantage of loyalty programs can help to reduce some of the stress around travel and also make it a bit more enjoyable.