<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Josh Claxton on Medium]]></title>
        <description><![CDATA[Stories by Josh Claxton on Medium]]></description>
        <link>https://medium.com/@joshclaxton?source=rss-143830800bac------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/1*qIlYiR3tWkTu0zR_4wBNfQ.png</url>
            <title>Stories by Josh Claxton on Medium</title>
            <link>https://medium.com/@joshclaxton?source=rss-143830800bac------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Sat, 16 May 2026 18:07:20 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@joshclaxton/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[My Method for Practicing Soft Skills]]></title>
            <link>https://medium.com/@joshclaxton/my-method-for-practicing-soft-skills-eb488703f9d?source=rss-143830800bac------2</link>
            <guid isPermaLink="false">https://medium.com/p/eb488703f9d</guid>
            <dc:creator><![CDATA[Josh Claxton]]></dc:creator>
            <pubDate>Sun, 18 Jul 2021 04:11:56 GMT</pubDate>
            <atom:updated>2021-07-27T02:07:10.451Z</atom:updated>
            <content:encoded><![CDATA[<p><a href="https://www.joshclax.com/tag/career/">Career</a></p><p>So you want to learn soft skills now, but don’t know where to start. Thankfully, you don’t have to start over. The same learning techniques that apply to hard skills, apply to soft skills. It’s important to think of soft skills just like anything else you want to learn. What works for me is…</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*8l4s9nLf7d-uHn-m.jpg" /></figure><p><em>Yea it’s a </em><a href="https://en.wikipedia.org/wiki/Grogu"><em>Mandalorian </em></a><em>reference…sorry not sorry.</em></p><p>I once knew a young software developer who was just getting his start in the industry (in fact, he had barely worked at all), only recently started living in a big city, and was a bit of a social outcast. Showing up to his interview in torn jeans and a faded short-sleeve button-up, he brought no copies of his resume to share and did his best to say as few words as possible. It was obvious he was out of his element. Despite this, he was given the benefit of the doubt and hired on as an intern while kindly educated about first impressions.</p><p>Thinking he learned his lesson, he showed up for his first day of work wearing a full suit with his paperwork ready to go. Safe to say, not only was he the <em>only intern </em>wearing a suit, but he was the <em>only employee </em>wearing a suit in the 120 °F Phoenix Summer. At this point, he knew he stood out — not something he wanted — but he also couldn’t take his suit jacket off. (It may be a dry heat, but there was nothing dry about his undershirt.)</p><p>Over the next few weeks of work, he found comfortable yet professional attire and spent his days coding away. One task after another. Check! Check! Done! He received feedback that his technical skills were awesome and that he (jokingly) needed to “slow down before the senior devs are out of a job”. On the other hand, he also heard he needed to “smile” and talk to people more. The technical feedback was appreciated, but the latter? <em>Who cared about this foo foo stuff? He wanted to be a programmer so he could work alone and focus on puzzles. He was hired to code, not to be friendly!</em></p><p>If it wasn’t plainly obvious, this intern was me. Nearly a decade later, I vividly remember this feedback as a fundamental turning point in my career and my first introduction to the concept of soft skills and hard skills. Without soft skills, I never would have achieved all I have in my career. My hard skills ultimately come second.</p><p>Indeed does a great job, so I’ll hand it over to them.</p><blockquote><em>Hard skills are technical knowledge or training that you gained through any life experience, including in your career or education. (</em><a href="https://www.indeed.com/career-advice/resumes-cover-letters/soft-skills"><em>Indeed</em></a><em>)</em></blockquote><p>Conversely,</p><blockquote><em>Soft skills are personal habits and traits that shape how you work, on your own and with others. (</em><a href="https://www.indeed.com/career-advice/resumes-cover-letters/soft-skills"><em>Indeed</em></a><em>)</em></blockquote><p>For example, some of my hard skills as an intern were in programming (C#, Java) and design patterns, while my soft skills were in problem-solving and a desire to learn. The hard skills I lacked were an understanding of databases and networks, while soft skills I lacked were friendliness, communication, and teamwork.</p><p>At first, I disagreed with the need for these skills. I should be judged on my hard skills and output! Sure, this is true, but what I came to understand is that soft skills augmented my hard skills. Through teamwork and communication, I could more quickly and fully improve my hard skills. Communication, empathy, and vulnerability also led to strong professional and personal relationships, which opened up new career opportunities and life experiences, which in turn tested/grew my hard skills.</p><blockquote><em>Hard skills and soft skills complement and feed back into each other.</em></blockquote><p>Okay, so soft skills aren’t easy, especially if they don’t come naturally to you. I’m (sorry for) looking at you, my fellow introverts and social-anxiety-riddled folks. Whereas hard skills can be practiced alone and in dense sessions (i.e. I can write a lot of code in my room alone for hours), it’s not so for soft skills. They are more abstract and often require practicing in real-life situations (testing in prod, anyone?). Most soft skills require interaction with other people, which means failure has direct, immediate, and sometimes long-term consequences. If you think “cup half-full”, though, it also means success has direct, immediate, and sometimes long-term benefits too! Either way, it’s important to learn from every experience as they are less plentiful than hard skill learning opportunities.</p><p>Cool, so you want to learn soft skills now, but don’t know where to start. Thankfully, you don’t have to start over. The same learning techniques that apply to hard skills, apply to soft skills. It’s important to think of soft skills just like anything else you want to learn.</p><p>What works for me is to simply write the thing I <em>don’t want to do</em> on the left side and draw an arrow to the thing I <em>want to do instead</em> on the right side. I place it on my desktop/sticky/whiteboard so it’s in my face all day long (can’t forget it). Critically, I only pick a couple of things to work on at once, otherwise, I’ll get overwhelmed. After completing one, I’ll remove it and add another.</p><p>Here is an example of one I did as an intern. I still remember the sticky notes I wrote for these, clear as day. (I even held onto them for several years as a sort of completion trophy.)</p><p>By describing behavior I want to change and offering an easy/immediate solution for it, I can quickly identify the problem <em>at the moment </em>and brainlessly apply the fix! Furthermore, I mostly follow <a href="https://www.indeed.com/career-advice/career-development/smart-goals">SMART goals</a> by choosing specific, attainable, and relevant goals. However, I don’t set a timeline because the entire point is to practice every day (sometimes for months) until it becomes a habit (this is how I measure it).</p><blockquote><em>The key is that you know what you want to do and practice it until it becomes a habit.</em></blockquote><p>Here’s what I’m working on today, as someone who is moving from an individual contributor to a leadership role. I have to be ready (at any point) to explain high-level concepts to those above me, my peers, and individual contributors while not having the time to do the individual work myself. While this is new to me, my learning method is still the same.</p><p><strong>Bonus</strong>: You might notice I also wrote the words: Frame, Advocate, Illustrate, and Inquire in the margin. These are known as the <a href="https://endeavour.consulting/2019/12/05/communicating-clearly-the-four-parts-of-speech/">Four Parts of Speech</a> and are incredibly useful for <strong>practicing effective communication</strong>. This is something I haven’t succeeded in turning into a habit over all the years, but instead, need to be actively reminded to employ. (It’s okay if a skill doesn’t become a habit. Sometimes you just have to keep practicing.)</p><p><em>Originally published at </em><a href="https://www.joshclax.com/my-method-for-practicing-soft-skills/"><em>https://www.joshclax.com</em></a><em> on July 18, 2021.</em></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=eb488703f9d" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Save Time with Design Time REST APIs]]></title>
            <link>https://medium.com/@joshclaxton/save-time-with-design-time-rest-apis-65f8426dbf8e?source=rss-143830800bac------2</link>
            <guid isPermaLink="false">https://medium.com/p/65f8426dbf8e</guid>
            <category><![CDATA[rest]]></category>
            <category><![CDATA[rest-api]]></category>
            <category><![CDATA[time-design]]></category>
            <category><![CDATA[api]]></category>
            <dc:creator><![CDATA[Josh Claxton]]></dc:creator>
            <pubDate>Sun, 07 Jan 2018 01:46:01 GMT</pubDate>
            <atom:updated>2018-01-10T20:16:52.054Z</atom:updated>
            <content:encoded><![CDATA[<p>We’ve all been guilty of thinking we know what’s best for somebody else, whether it’s our political opinion on abortion or suggesting that others really shouldn’t watch that new <em>Star Wars</em> movie. We do this all the time when we design software, particularly with APIs. We will get the requirements for an API, craft an outline of what it should look like, then start coding it. We end up with this absolutely beautiful and clean REST API that no one could possibly say anything bad about. When it comes time to release our masterpiece, the users (other developers) <strong>hate it</strong>.</p><h3>But why?</h3><p>We set ourselves up for failure from the get go when we assume that other developers are just like us. Sure, that developer who will consume our API has a similar skill set to us (maybe they are even our clone!), but the way they need to use this API could be totally different from how we imagined them using it. Maybe they are working with legacy software? Maybe the requirements changed on them, but we never got that update? Maybe they just came up with an alternative design for their app that we never considered?</p><h3>Where we failed</h3><p>Maybe we were so confident in ourselves that we just coded the API immediately. By the time we finally showed the API to the other developers, we had already spent several days on it only to find out it didn’t fit their needs. Whoops. Now we spend a couple more days making the changes they need only for them request even <strong>more</strong> changes. This repeats and we incur the cost of our time, the other developers’ time, as well as the opportunity cost.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/381/0*eIi1nITVeuZGKZ3A.PNG" /></figure><p>Maybe we were a bit smarter and decided we should design our API on whiteboard/paper at first. Now we <em>think</em> we have a solid foundation, but we still don’t know if the user will actually like what we designed. We’re back in the situation where we were before; code, feedback, code, feedback, and so on. We’re still wasting just as many resources as before; possibly even more because we spent that extra time designing something they didn’t even want!</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/627/0*-4Zr4LymRlsFrmYI.PNG" /></figure><h3>How we can improve</h3><p>Instead, we should design and seek feedback immediately. Sure, we could discuss the whiteboard/paper design with our developer users, but as I’ve stressed, they don’t know what they want until they have something real to play with. Let’s give them a <strong>mock API</strong> to implement against. Instead of spending a lot of time coding up the solution against databases and working out complicated business logic, simply provide the interfaces, routes, and mock data. We can whip out a mock API in a small fraction of the time it would take to build a fully integrated solution.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/611/0*vedRsGR7c2Tf4d50.PNG" /></figure><p>Now we have a lot of flexibility we didn’t have before. Our beta of the API is out within hours instead of days, meaning the developer users can immediately play with it and give feedback. Just as important, we can make the changes they request even faster. We can iterate through several designs in a single day instead of a few designs over several days/weeks. We’ll land on a better solution in less time.</p><p>We also get the (important) side effect of being able to develop in parallel once the mock API design is finalized. Our users can code against the mock API while we build the business logic in background.</p><p>You certainly could roll the API in your favorite framework and manually write the mock data, but there are better options.</p><p>My favorite is <a href="https://swaggerhub.com/">SwaggerHub</a>. Here you use the Swagger/OpenAPI spec to declare the interfaces, routes (URI, Verbs, HTTP Responses), and behavior you want your API to have. It’s fairly intuitive and you can check out the <a href="https://app.swaggerhub.com/help/tutorials/getting-started">Getting Started With SwaggerHub</a> guide.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*QIObA-ZE88G_PT2R.PNG" /></figure><p>After you design it, you can download a skeleton project for your favorite server (aspnet-core, Node, Go, etc.) and client (Angular, Ruby, C# MVC, etc.). Let SwaggerHub write the boiler plate code for you.</p><p>You may argue: “However, I had to spend time writing that Swagger/OpenAPI document!”. Here’s where it gets good: each time you need to make changes, just modify the Swagger/OpenAPI design and redownload the new project. Bam, easy!</p><h3>Wrap it up</h3><p>The key here is to spend less time coding and more time designing and receiving feedback. We already know that’s what we should do, but we don’t always know <strong>how</strong> to do that. Hopefully this can help speed up your API development.</p><p><em>Originally published at </em><a href="http://www.joshclax.com/save-time-with-design-time-rest-apis/"><em>www.joshclax.com</em></a><em> on January 7, 2018.</em></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=65f8426dbf8e" width="1" height="1" alt="">]]></content:encoded>
        </item>
    </channel>
</rss>