The Point is To Do What is Desired, Not What is Requested

As a software creator I have learned many lessons over the years. The one I learned early on from my mentors and practice daily, is to do what is desired, not simply what is requested. This means understanding what the customer, your boss, the company is after and making sure you deliver that. This is how you delight and deliver results that are valued repeatedly. This requires curiosity, understanding, empathy, flexibility and execution. Many people blame lack of time, people or money. The resource a “rosh gadol” person has is resourcefulness.

Ultimately, fulfilling the other person’s desire is what they expect and when they don’t get what they desire there’s no value created. The explicit instruction they give can help, but completing the instruction is just a step on a journey, not the desired location.

I was reading Joel on Software’s post on “rosh gadol” and thought, this describes exactly the expectations I have of outstanding software creators and other professionals. You instantly recognize a “rosh gadol” person when you work with one. This is how you become sought after, whether you are a business or individual professional.

Tamir Nitzan explains, “For instance, someone might be told to clean the barrel of their rifle. A “rosh katan” will strictly clean the barrel, perhaps leaving it useless because the trigger mechanism has sand in it, whereas a “rosh gadol” will clean the entire rifle and lubricate it so it’s ready for use and doesn’t rust. Another example: you tell a soldier to “go notify so-and-so that we will be ready for inspection at 1600”. By 1700 you’re curious, so you ask him “did you notify?”. His answer might be “well I called his office and left a message”. A “rosh gadol” would likely say: “I called his office but got his voice mail, so I left a message. I called back an hour later but still got voice mail, so I called his cell phone and left a message there too. I tried him again an hour after that and he assured me he will be here by 1600. I called him again 20 minutes ago and he said he was on his way but stuck in traffic” (a real “rosh gadol” would have notified his C.O. of all this without being asked of course).

The Philosophy of World Class Commercial Software Devs

What’s the difference between software developers that are great and those that are ordinary? One of the things that I have noticed and tried to emulate, as if some of these great software developers and other problem solvers were my coaches, is to have an understanding and philosophy behind the code. This is one reason I think I always gravitated toward learning a new technology or coding technique by having a project to use it in. I wanted to apply a new technique as quickly as I could.

Feynman is a famous physicist that has a great video from long ago on the difference between knowing and understanding. A lot of developers are at the stage where they know what to do. They “can” solve a problem using X technique. To get to the next level, they might know 3 or 4 techniques of solving the problem. Then there’s a level beyond this that doesn’t just respond to a problem with a range of solutions, but brings understanding to the table.

What I have observed world class software developers do differently when making commercial software is they have a philosophy that helps frame their toolbox and communication. One part of the philosophy is world class software developers design the problem and solution.

A second part of what makes world class software developers different is they ask two sets of questions, instead of the one most common set of questions. The common thing to do is be given a problem or task and you start right away by breaking it down in to parts, working on each part and then integrating the parts back in to a whole. The uncommon world class thing to do is first ask two questions, instead of one. Ask “what are the parts?”, but also ask “what is this a part of?” You need to manage up as much as you manage down. Taking a US car apart will show you that it is built for the driver to sit on the left side. But the car won’t tell you why the driver is sitting on the left. Ordinary engineers need to build the driver seat and steering wheel on the left to sell their car in the US, but they don’t need to know why. World class engineers need to know why and with that understanding they can approach making a car in a different way. That different understanding might lead to the same result in some cases and different results in others. Don’t deny the problem solver their ability to make sense of things and understand things. Unfortunately, this is what a lot of management and compliant software developers do when they regulate engineers to the “back-offices” so they can be worked without interuption. They don’t want to be interrupted by the customer as John Seddon would say.

A third part of what makes world class software developers different is they see events where other people see nouns/attributes. An example of this is where one person sees a thing or focuses on the main interaction and the world class software developer sees a lifecycle. He might understand you don’t just start moving things around in the system, but you have to first enter things in to the system and when the system becomes too full or noisy you might need to remove items. Adding, moving and removing items would be an example of a lifecycle. I’ve personally seen many times where a large project started with certain assumptions and one or two parts of a lifecycle were completely overlooked by everyone on the project. Take the time and do the rigorous work to understand the lifecycle of things. Otherwise you might have a super productive way of editing items, but have to insert them through a completely ad-hoc way you develop at the last minute, which makes your whole system horrible.

There’s more differences, but those are three obvious ones I’ve seen over the years.

Watch the Feynman video below and see how he describes the concept for physicists, but it just as readily applies to software developers and software entrepreneurs.

 

Are APIs Semantics?

There is a blog post Thinking Outside-In: How APIs Fulfill the Original Promise of Service Oriented Architecture by Anders Jensen-Waud. A comment on LinkedIn referencing this article asked if “APIs by themselves begin to address semantic interoperability?” I don’t think so and my reason for thinking semantics is not defined in the API itself is as follows.

I have been creating APIs for hospitals for years and have found an API by itself doesn’t make something more likely to be semantically interoperable. I have found it’s more important to get the community that builds and uses the APIs to use the same vocabulary with the same context and out of that understanding APIs can be developed that are semantically congruent. Without those people sharing understanding then they each go off and develop their parts and after they have developed each part they come back to integrate it with the whole and found that even though they used the same property names or class structure, they used them with different intentions. For example, this really happened once. One team of API creators inside a company started with the same product goal as a second team in the same company, to track locations of things on a map. They each knew that they were going to use polygon data structures and each point in the polygon was going to have a X and Y property. Three months after each building their components, they came together to integrate their parts and they didn’t work, because they operated with different assumptions. One team’s processing logic used Cartesian points where the X,Y origin is in the bottom-left and the other team used Raster points, where the origin is in the top-left. No one identified semantics as a deliverable, because the teams ionly thought the code/API was the deliverable. The semantics should have also been a deliverable and occurred before the production of an API.

The insight I want to share is that semantics is a shared context and understanding. APIs and code itself are just symbolic processing. The symbols themselves do not inherently carry the meaning, but the common understanding among people can use the symbols in the same way.

Employing AI

I plan on writing two blog posts in the coming days.

  1. Hiring My First AI Resource/Employee
  2. Managing a team of AI Resources/Employees

These are not about employing people, but employing AI agents for different business responsibilities. This is an area that I think will grow more relevant as our digital assistants get smarter and more manageable.

First, we employee individual assistants, like Cortana on Windows. I use this assistant to add appointments to my calendar or check the whether. I also use Buffer to schedule tweets for my business. Buffer will let me manually schedule a time or “pick the best time” to send my tweet, based on its own intelligence.

I use MailChimp to send email newsletters for my business. It has similar smarts to Buffer and can tell me the quality of the individuals I am emailing, compared to their interactions with other newsletters also sent through the service.

Now that I’m relying on these AI agents, it’s time for me to raise this abstraction layer up a level and apply intention to managing them individually and as a team. Ultimately, I don’t want my AI agents to be silos of activity, but I want Cortana to interact with Buffer and MailChimp and coordinate Twitter and MailChimp activity. I want these services to monitor my Google Analytics to know when one of the tweets or email newsletters is increasing traffic to my site beyond the original newsletter links being clicked. How can I generate a positive feedback loop?

How We Really Experience Work Emotionally

There’s different ways we experience meetings. One default way, if you don’t do anything else, is you leave with a set of emotions about what happened at the meeting. More so than a checklist of desired outcomes, how-to instruction and explanations of why, in 30 days you will only have the memory of how you felt about the meeting, not a true analytical understanding of what the substance was.

Many businesses operate on fluff, instead of on shared data. I’m not just talking about business intelligence, spreadsheets or that kind of data. I’m also talking about everyday data that we should be responsible for generating, like notes, meeting minutes, audio or video recordings and more. You do not want to operate your business on emotional memories.

The reason this is important to understand is because there are tools and disciplines available to better understand past meetings. Some technologies that are available are video or audio recorders, written notes and minutes and diagrams. Without the discipline of writing down what happens at a meeting, you will have no way to validate or invalidate the substance of the decisions. That means there can be no feedback loop in to better decision making at future meetings.

Instead, you will have executives, engineers, managers and others each individually remembering how they felt at the time of the meeting.

The executive might be feeling, “We’re on schedule.”

The engineer might be feeling, “There are two contradictory objectives that will cause a problem when I implement what is being asked of me.”

The manager might be feeling, “There are more problems and unrealistic expectations than I know how to objectively manage, so I will retreat from interacting with the team about problems and only focus on solutions. I don’t feel like hearing about one more problem.”

The feeling the executive has a memory of does not include a list of specific components, their interactions and exactly what is on schedule. Is the technical deliverable on schedule? Is the value proposition delivery on schedule?

The feeling the engineer has a memory of does not include the list of specific contradictions.

The feeling the manager has a memory of does not want to understand problems, so they will feel better. This means focusing on solutions, maybe working on making things better, but has abdicated the decision making of knowing what things to work on is more important than only optimizing the current work.

A productive learning organization should build a system whereby these people operating it do not just rely on these emotional memories, but have tangible data constantly available at their fingertips to work on. That data can be notes, document shares and multimedia recordings.

The Ultimate Resource is Resourcefulness

The ultimate resource is resourcefulness, not time, money or anything else. If you have the commitment, determination and decisiveness to do something then you can find the people to help you, the money you need and we all get the same amount of time in a day. People that are resourceful can get the other resources they need to achieve what they are determined to ship. The determining factor for success is you, your emotional states and the energy you use to solve problems.

When we fail, the critical factors within our control is not a lack of money, lack of time, lack of technology or lack of any other resource. When we fail the critical factor is how we were not resourceful with what we were given, how we were not determined to get the other resources we needed in an urgent manner and our emotional state attracting help or secluding us. To be resourceful, you have to manage your emotional states. If you are defensive, a negative presence and shutting down at the moment when the energy needs to be stepped up and decisions need to be quickened, then you’re not going to have what you need to succeed.

How Tos for Life, Success and Effective Action

JD Meier’s Sources of Insight blog has a great How To section that links to deep articles on how to change habits, how to think like Bill Gates, how to change any goal and much more. It’s worth bookmarking and referencing when you want to work on yourself. I always remember what Jim Rohn said, “Work harder on yourself than you do on your job.”

Here is a short list of everything available in the comprehensive list: