The Four Quality Katas of a Code Craftsman

I recently had the opportunity at a conference to ramen up with Lance Gleason of Polyglot. Of the many things we discussed in 3hrs, it came down to this:

“A really good developer implicitly cares about the quality of their work.”

Forget what you’ve previously read, the blah blah, the pious statements, the bullshit for a moment. Consider these four reasons, practices if you will, that explain the statement above.

1. Write code that makes sense next week

I can’t reason about things that don’t fit in my head. So please write code that fits in my head, even if it already fits in yours. I say that understanding how big my own head is sometimes, and maybe that applies to you too. When we do this, code is easy to reason AND collaborate about, and it turns out that’s severely important to our craft.

Also keep in mind that the amount of work you have to do next week will make you forget what you did this week. I love to forget about things, it helps me prioritize life. I wish the same for you. All code is an expression of intent, and when it contains bugs, we have to fix them. That means what we do today has to be simple enough to waste no time fixing when we revisit it in the future.

2. Write code that contributes to a purposeful existence

Life quickly becomes meaningless when you’re working on meaningless stuff. Figure out what matters most in your life, make that your goal, and write code that contributes to that goal. Don’t become a programmer for the money because you’ll quickly learn to hate the programmers around you because we can be prickly unless you understand why we are what we are.

Personal scrutiny is a blessing and a curse. Self doubt, imposter syndrome, and uncertainty are all signs that you still have a soul, so don’t worry if you see them while you write code. So when you see them on your journey with code or when someone points something out, you have no obligation to accept them verbatim; but you should receive it just as you should receive compliments, consider it, then if it makes sense work it into your code.

Be ethical enough to say “I will not build this” every time your conscience tells you that your product isn’t going in a direction. Every time. Why? Because there is no soul in software other than what we as humans imbue into the process. Businesses are paper. You are craftsman. Be that.

3. Write code that entices others to collaborate

Who likes to toil away in obscurity on something no one else cares about? Exactly, so find projects that others also care deeply about, enough to contribute to, then go to it hard. Said the opposite way, you know if you’re working on something valuable when others are so interested in it that they also want to invest their time in it.

Don’t write negative comments over someone else’s work. Just don’t. Establish a dialog that helps you understand why they did what they did. Then if you still don’t agree, be clear about the obstacles you see in the current approach and find which ones are imperative to resolve. Be okay with things that aren’t perfect so long as there’s a way to revisit them later.

You know you’re doing it right when you leave no code behind that others are afraid to question. This is a characteristic of mature engineering, the self-evident latitude in your work for future ideas to improve what you have crafted.

4. Write code that anticipates change

Everything changes. Flexible code enables us to correct mistakes when we realize them in the future. Smaller code is easier to understand and fix.

Be clear about your surface area. The more you know about the limits of code, the easier it is to build code that uses it properly. If it’s a function or method, naming and sufficient typing clarifies it’s purpose and limits. If it’s a REST API, a machine-readable descriptor with examples helps people integrate this into other code more accurately.

Constraints and dependencies also communicate the flexibility of a system. If you know that the code your writing shouldn’t be used in specific circumstances, document those in a way that is easier for others to consume. Isolate dependencies when they are insufficiently abstract such that you can’t write code that ‘fits in your head’. Vet external software that you don’t own, yes, open source libraries to ensure they meet licensing, security, and performance requirements.

Don’t just talk about quality, practice it.

Quality isn’t something you ‘build in’ afterwards, it’s desirable characteristics exhibited by your work. There are many ways to accomplish this, but all take practice and focus, trial and error. Exercise teaches us to reason about why we do what we do, not just what we’re doing. True software craftsmanship produces sensible, purposeful, collaborative, flexible code.

AnDevCon: Espresso Is Awesome, But Where Are It’s Edges?

For my presentation at AnDevCon SF 2016, I focused on how Espresso represents a fundamental change in how approach the process of shipping software that provably works on a mobile ecosystem that is constantly changing.

The feedback was overwhelmingly good, many people who stopped by the Perfecto booth before or after our talk came to me to discuss topics I raised. In other words, it did what I wanted, which was to provide value and strike up conversation about how to improve the Android UI testing process.

If you’re pressed for time, my slides can be found below or at:
bit.ly/espresso-edges-andevcon

Looking forward to Codestock 2017

As we were preparing for a webinar yesterday, a co-worker, @nicksanjines, mentioned a TN local developer event: Codestock

Side note: Nick has a great set of examples on Jenkins, Android Studio, and Calabash at thedieseldeveloper.com

Not only have I been looking for an excuse to get down there in 2017, this looks like a very legit event. Consider Jared Smith, organizer of HackUTK and security researcher. That’s one of dozens of speakers at an event that attracted 900 devs.

Just like Abstractions.io this past year, I am ready for my mind to be blown.

Gluecon 2016: Melody Meckfessel on Serverless Technology

I had the opportunity to attend Melody Meckfessel’s presentation at Gluecon 2016 last week. As someone with years of experience at Google, when she speak, smart people listen.

[paraphrased from notes]

We should all be optimistic about open source and serverless technologies. Kubernetes, an example of how to evolve your service, a means to an end, housing processes internally, making management easier for developers to deploy and scale horizontally, to update gracefully without causing downtime. One of the themes in the future of cloud-based computing is that is increasingly open source which makes it easier for developers to influence and contribute the software stack as it’s evolving. Our focus is switching to managing applications and not machines.

“…the future of cloud-based computing…is increasingly open source which makes it easier for developers to influence and contribute the software stack as it’s evolving.”


(photo credit: @rockchick322004)

Serverless means caring about the code, embedded in all cloud platforms. In App Engine, you run code snippets and only get charged for your app or service as it scales up or down. With container engine, you run containers but don’t specify the machine it runs on. In the future, we’re not going to be thinking or talking about VMs. What does it mean for us developers? It will enable us to compose and create our software dynamically. As one of the most creative and competitive markets, software puts us in the same room and presents us with the same challenge: how to make things better, faster.

Melody tells a story about a project she was working on where they were using a new piece of hardware. They were having trouble scaling during peak load, holiday traffic being really important to their particular customer. They were constantly scrambling and for the first 6-9 months, she spent her time on primarily DevOps related work. This was frustrating because she wanted to work on features, seeing the potential of what she could do, and she could never quite get to that.

As developers, we are constantly raising the bar on the tools we use to release, and correspondingly our users’ expectations increase. Also as developers, we have the ability to create magic for users, predicting what they want, putting things in context, and launching the next great engaging thing. In a serverless future, developers will be focused on code, which means that PaaS (platform as a service) will have to evolve to integrate the components it’s not doing today. To do that, developers will need to shift Ops work from themselves more to cloud providers, being able to pick and choose different providers. Developers come to a platform with a specific language that they’re productive in, so this is a place where PaaS providers will have to support a variety of runtimes and interpreters. App Engine is the hint and glimmer of creating an entirely new developer experience.

“In a serverless future, developers will be focused on code…will need to shift Ops work from themselves more to cloud providers.”

What does a serverless future mean for the developer experience?

We will spend more of our time coding and have more and more choice. Right now, we’re in a world where we still have to deal with hardware, but as that changes, we’ll spend more of our time building value in our products and services and leave the infrastructure costs to providers and the business. If we want to do that, developers need to make it very easy to integrate with machine learning frameworks and provide analytics. Again, to do this, we need to free up our time: hence NoOps. If we’re spending all out time on ops, we’re not going to get to a world where we can customize and tailor our applications for users in the ways they want and expect. This is why NoOps is going to continue to go mainstream.

If we’re spending all out time on ops, we’re not going to get to a world where we can customize and tailor our applications for users in the ways they want and expect.

Think about if you’re a startup. If you’re writing code snippets, you may not need to think about storage. You don’t need to worry about security because the cloud providers will take care of that for you. Some wifi and laptops, and that’s your infrastructure. You’ll have machine-oriented frameworks to allow that app to be really amazing. This idea that you can go from prototype to production-ready to then scale it to the whole planet. Examples of really disruptive technology because they were enabled to do so by cloud resources.

To get there, we’re going to have to automate away the configuration and management and the overhead. We still have to do this automation. We have work to do there.

Multi-cloud in NoOps is a reality.

People are using mixed and multiple levels of on-prem IT and hybrid cloud; the problem is that the operational tools are siloed in this model though. This makes it very hard to operate these services. As developers, we should expect unifying management…and we should get it. Kubernetes is an example, just another way for teams to deploy faster. Interestingly, we’re seeing enterprises use Docker and Kubernetes on-prem; the effect of this is that it will make their apps and services cloud-ready. When they are faced with having to migrate to the cloud, it will be easy to do it.

“…we’re seeing enterprises use Docker and Kubernetes on-prem…it will make their apps and services cloud-ready”

Once you’re deployed like this though across multiple clouds and service providers, you’ll need to have an easy way to collect logs and perform analysis; StackDriver is an example of this. It’s this single-pane-of-glass view that enables developers to find and fix issues fast, to see what’s happening with workloads, and to monitor more effectively. Debugging and diagnosing isn’t going to go away, but with better services like Spinnaker and App Engine, we’ll be able to manage it more effectively.

Spinnaker providers continuous delivery functionality, tractability throughout our deployment process, it’s open source. As a collaboration with Netflix, Melody’s team worked hard on this. It was a case of being more open about the software stack we’re using and multiple companies coming together. We don’t all need to go build our own thing, especially when we share so many common problems.

Debugging and diagnosis

The problem is that there’s all this information across all these sources and it’s hard to make sense of it. It’s usually in a time-critical situation and we have to push out a quick fix as soon as we can. Part of streamlining that developer and debugging experience in the future cloud is having the tools at our disposal. These are things like being able to trace through a complex application for a performance issue, going back through the last 3 releases and see where the slow-down started, or production debuggers where you can inspect your service that’s running in the cloud and go to any point in the code to look through variable and see what’s happening. Error reporting as well needs to be easier, as errors can be spread across multiple logs, it’s hard to see the impact of the errors you’re seeing. Errors aren’t going away, so we need to be able to handle them effectively. We want to reduce the effort it takes to resolve these errors, we want to speed up the iteration cycles for finding and fixing the errors, and provide better system transparency.

“The faster we can bring the insight from these motions back in to our source code and hence optimize, those are all benefits that we are passing through to users, making us all happier.”

In the NoOps, serverless future, not everything will be open source, but we will expect that 3rd party providers should work well with all the cloud platforms. Meledy’s team is currently working on an open source version of their build system called Basil. Right after their work on Spinnaker in collaboration with Netflix, they’re looking for other opportunities to work with others on open source tools.

What does the world look like 5-10 years from now?

We’re not talking about VMs anymore. We’re benefiting from accelerated hardware development. We’re seeing integration of data into apps and compute so that we can have better insight into how to make applications better. It’s easier for machine learning to be embedded in apps so that developers can create that magical software that users expect. We don’t have to talk about DevOps anymore. We will have more time to innovate. In an open cloud, you have more opportunity to influence and contribute to how things evolve. Like thinking back on how there used to be pay phones and there aren’t anymore, the future of development is wide open, no one knows what it will look like. But contributions towards the future cloud are a big part of that future and everyone’s invited.

More resources:

Kindness: What Makes a Great Technical Team

How do you quantify what makes a great working environment, a good team, and work worth doing? An important piece for me is kindness.

Kindness is Human

At the risk of speaking to some stereotypes here, kindness is incredibly important in teams where members often lack patience and social skills. It doesn’t have to hinder honesty, expedience, or effectiveness. In fact, showing a small amount of kindness in your daily interactions reminds the people you often work most closely with on otherwise dry, tactical topics that there’s more to work than just code or tech. It reminds people that both you and they are human, not software-delivering carbon units.

Kindness is Engaging

When you show a little kindness, maybe a bit of sympathy about how frustrating a specific framework or project is to the team, it allows people the opportunity to open up if they want to. By sharing a short, discrete moment where you’ve felt the same excitement or frustration for a technology, you’d be surprised how often it elicits candid conversations that you’d otherwise not have during normal sprints or reviews. It gives people the cue that it’s okay to be themselves a little.

Kindness is Strategic

Looking for a promotion? Counter to kissing ass with a boss, expressing a little kindness to everyone you work with signals to intelligent management that you pay attention to social cues and understand how to play well with others.

Again, the level of kindness you show shouldn’t detract from your efficiency or ability to be straightforward at work; it should enhance your efficiency by proactively smoothing the interactions you have with co-workers, partners, and other non-technical folks.

Kindness is Admirable

Everyone has bad days. It’s how we deal with them that signals to others how professional, reasonable, and capable you are when you get down to business. And let’s be honest…technology is a revolving door. The relationships you make at one organization can indefinitely benefit future positions you may hold. Just as honesty and effectiveness are qualities people remember, being unkind never gets you on the list of people that others want to carry with them to the next gig.

More reading:

Developer Experience is the UX of Your API

For software developers, APIs are a really logical choice for delivering how something should work on multiple platforms, acting as a sort of a common “language” between projects, systems, and teams.

Who really ‘uses’ an API?

Developers are the real ‘users’ of APIs. Sure everyone is the downstream recipient of the value of an API, but most of that doesn’t happen unless an API satisfies its first audience: developers. They need to understand how it works, how to incorporate it into what they’re designing, often designing APIs themselves. When something’s hard to understand on an API, they’re the ones that feel the pain, not the end user of the app.

You might stretch the definition of an API ‘user’ to encompass ‘anyone who benefits from the API’, but it’s really the developers who are adopting the API, proliferating it to others, and ultimately orchestrating the user’s interaction with your API, like digital gatekeepers. Benefactors and users are important to differentiate between as a business; one represents the volume of your business, the other represents your adoption curve.

Developers love something that just makes sense to them, and a well-designed API along with great documentation the best ‘UI’ an API can have.

dx-over-ux-equals-api

But APIs don’t have a UI!

APIs lacks a User Interface (UI) in the traditional sense, that is until you go back to your definition of who you mean by ‘user’ when you say ‘User Interface’. If the ‘user’ is a developer that interacts with code and APIs as their primary language, then you leave the UI up to them, but there is still an ‘interface’ to your API as a product.

Traditional ‘UI’ focuses on treating the ‘user’ component in terms of human sensory input and direct manipulation. APIs being purely digital products, they are primarily something you interact with conceptually and socially.

The social element of APIs is huge. By definition, by building an API, you are describing functionality in terms of what ‘your’ system can do for something else. APIs infer interaction, collaboration, and inclusion.

The role of UI and APIs in the User Experience

User interface (UI) is heavy work in terms of software; people slave over the perfect font, color scheme, and behavioral appropriateness of UI, only to find that the project is hard to maintain, change, or integrate with afterwards. Instead of thinking about how things look, good designers also consider how things behave.

User Experience (UX) design is a field that accommodates these considerations while also maintaining a keen eye on the consumer’s actual use, psychological reasoning, and emotional reactions to how a technology works. Yes, we need awesome UI, but only as a result of thinking about the human experience driving the functionality of the software, and only after we get the technical premises correct for the business requirements.

What Makes for a Great Developer Experience?

Developer Experience (DX) is the UX of APIs, but what lessons in great UI design can we apply to DX? What elements of great DX are unique to this non-traditional view of UX/DX?

If I had to boil it down, a minimum-viable API developer experience in order of importance consists of:

  • Documentation, both human-readable and machine-readable
    Hand-crafted API documentation is adorable, but most developers expect an M2M format like Swagger these days. A wise man once said: “he who hand-codes what he could have generated automatically using M2M descriptor is not spending that time making his API better”.
  • Minimize number of exceptions, not the exceptions themselves
    I get it. You’re special. We’re all special like snowflakes. Yay for us. Sad for users of your API. You may have some CRUD operational endpoints on your API, but more than likely you have domain-specific activities that require some explanation. Explain when you deviate from the most obvious, and try to keep things as simple as possible. Be sure to call out any exceptions to your own (internal consistency) rules like naming and type/structure differences between operations. And for the love of whatever, document why you decided to do so.
  • Test the new developer on-boarding process, constantly
    Proving that your DX is what you need it to be must be done regularly. Use hackathons, free account sign-up, metrics, and feedback to make sure that there are no broken elements of the on-boarding chain. If pricing is untenable, you might want to have the business owners focus on that for a bit instead of quarreling over design or feature specifics. Like a reliable disaster-recovery plan, a great DX only comes from putting your expectations through their paces.
  • Be personable, real, and transparent as possible
    Developers are people. Against the perception from non-technical people, they aren’t antisocial, they just hate bullshit and like to be passionate about really technical stuff. If your documentation, website copy, and support process reflect genuine concern for helping them solve their problem (and of course you do that too), you’ll be our their friend for life, or at least until you have a major outage.

Who Else Says Developer Experience is Essential to A Great API?

If you ask Jesse Noller, you’ll get an earful about documentation and transparency, and I agree. Documentation is the first thing a developer will reach for when working with your API. That doesn’t mean your efforts in DX should end there. You should also consider how other aspects like performance, authorization, and pricing play in to a developer’s decision to implement and evangelize use of your API over another throughout their team and career.

More reading: