Working code, in the hands of customers, as quickly as possible, with as low defect rate as possible

This is my main working philosophy and the metric(s) I’m always trying to balance for myself, my team and our products.

Decision Making

I am data driven. If you don’t like a decision I’ve made, the simplest way to get me to reverse it is to show me compelling data. This does mean that I’m quite skeptical of most developer best practices due to a lack of data. Most of the practices I use come from evidence in the book Making Software: What Really Works, and Why We Believe It. While you can certainly criticize some of the experiments underlying these conclusions, it’s far better evidence than that blog post you read the other day.

Working Philosophy

I believe the work of computer programming requires long blocks of uninterrupted time to do a good job. Therefore I’ll try and keep mornings free for doing work and schedule meetings in the afternoons if possible.

If I am attending a meeting I’d prefer it start on time.

If I am hosting a meeting it will start on time.

Disagree and Commit

This is the principle that once the team has thought about a problem and decided on the way we’re going to solve it the discussion is over. We need to move forward and make progress, and while you may disagree with the team’s approach, we need you to commit to the plan and execute.

Priority over Dates

I would rather have a discussion of priorities than one about due dates.

While I’d never tell a retail or ecommerce company that “Christmas is an arbitrary deadline”, in other fields I have found that due dates are often arbitrary or determined by ulterior motives such as a lack of trust, wanting power or control, etc. For the lack of trust one though, I’d rather work to show that the team can be trusted to do all the work assigned.

I’ve found in the past that being transparent about our development process, and making work visualization easy has made due date conversations almost stop entirely as people gain trust in our team and our process.

Ownership

This is my kryptonite.

I can’t help but feel personally responsible for the success of the projects I am on. I tend to take on more work than I can actually handle, especially in the categories of “things nobody wants to do” because they are necessary for the project’s success. What this means in practice is that if we are dependent on another team and they are not delivering for whatever reason, and there is something I can do to get our project working even if its not the optimal solution – I prefer to do it myself until such time as the other team is ready. This leads to major burnout as it seems responsibility shrugs off some people like water off a duck, and seeks out those who, I suppose, don’t know any better and take on the burden. Maybe one day I’ll learn, but so far that has not been my experience. A positive side of this, though, is that I love talking to customers even when they’re grumpy. I want to understand fully their pain points as well as how this software is helping their business. I find it endlessly fascinating all the ways in which people make money.

Security

I am allergic to paranoia.

Just because someone can think of an attack vector doesn’t mean it is a valid concern. In fact, most of the things I see people doing in software because “security” are net-net negative in terms of the amount of effort/annoyance put in people’s way of getting stuff done (value generated) vs the value saved should the imaginary scenario actually happen.

Most programmers have 0 security training. I had mandatory security training while at Microsoft. I’m happy to tell you about it and make you as disillusioned as I am.

Among other things I will puncture your axiomatic beliefs in the following: Open Source software is NOT more secure than closed source.

Listen as I regal you with the tale of a room full of 1,000 of the best C++ programmers in the world who were shown a function and asked to spot the security vulnerability, sitting in utter silence as only a handful of people could pick it out. This happened multiple times that day.

Programming Philosophy

80% Rule

Through my 20+ year journey in software I have gone through many phases of my understanding of the field and what I think we should do about it as a result. Currently I believe in the 80% rule. Make things 80% as good as you know you can and move on. There are lots of reasons for this.

A small non-exhaustive set might include:

I have learned I’m bad at predicting the future, therefore I write code that solves the problem in front of me. I am confident that when a concrete use case comes for extensibility that I’ll be able to refactor that code to a new architecture/pattern if/when it is provably needed.

I believe that the quality of your overall programming skill improves faster with the quantity of products finished vs slow reasoned debate.

To illustrate this I love the following story of an art class teacher who broke his class into two groups:

Group A was told that their final grade would be based on the quality of their finished piece. Group B was told that they would be graded only on quantity. Group A proceeded to spend the first part of the semester meeting with all the team members to discuss what it meant for a sculpture or vase to be of good quality. They waited until the project was almost due to begin work. Meanwhile Group B just started making things. In the beginning Group B’s output was of very low quality, but as they continued to turn out things quickly they got more and more practice and in the end the final piece Group B produced was of higher quality than all the others, and… higher quality than that of Group A.
https://twitter.com/ID_AA_Carmack/status/572095052337446912?lang=en

Speed

“If a design is taking too long, then it is the wrong design”

This is by far the topic I get the most pushback from engineers about. So, I’ve written an entire blog post describing this for those who want more explanation: https://extroverteddeveloper.com/2020/02/17/2020-02-17-speed/

TLDR; I’m sorry but speed matters in the real world

Rule of 3

I will copy and paste a piece of code 2 times rather than make an abstraction. Once we have a 3rd concrete need for that same code, I then feel I have enough information/examples to improve the odds of creating a correct abstraction.

Design Patterns

I prefer simple functional programming inspired abstractions to complex OOP design patterns. I believed the opposite in 2006, but since then I’ve worked in several large code bases that made heavy use of patterns and they are basically impenetrable to read and debug. Design Patterns give you flexibility at run time at the expense of compiler enforced safety and readability.

I basically believe in getting engineers through this progression as fast as possible:

The Evolution of a Software Engineer

Quality

You HAVE to test your code prior to shipping it. That doesn’t necessarily mean you need to write automated testing, but somehow you need to know that your code actually works.

Testing makes permanent is my mental model for this. Often writing tests makes the code more solid and difficult to change. That’s exactly what you want when you’ve got evidence that your component is working the way it needs to and you don’t want it to break. That’s NOT what you want when you’re iterating/pivoting trying to find product market fit.

Outside of that I do however also find that automated tests help me know my code is working while coding and I pull them out when any of the following are true:

I need to do a bunch of manual setup in order to iterate on the function I’m writing, such as reading lines in from a file so I can see what the representation looks like in the debugger. If I need to do that I might as well take a few lines from the file and put them in a unit test I can run over and over again quickly.
The component I’m working on is fully specified such as implementing an IETF protocol like IMAP. https://datatracker.ietf.org/doc/html/rfc9051
The component I’m working on has functionality that is tricky to get correct, such as cache invalidation or keeping track of a lot of state

Ok, so you’ve got a project you don’t want to keep breaking. What kind of tests should you write?

unit tests > integration tests > e2e tests > manual testing

In other words, the total number of unit tests should greatly out pace the total number of integration test and the total number of e2e tests.

Management

1:1s

I love 1:1s. I think they’re a fantastic way to keep in touch with the concerns of the people on a team. I prefer the agenda of 1:1s to be controlled by the direct report. I prefer that 1:1s are NOT status updates.

Execution

Currently in my career I am still very focused on execution from all my time in startups. As such I have a lot of tools/techniques/processes available that can help us be productive, have a sense of team work and momentum and generally prevents things from getting dropped. These may not be appropriate for every team but they are in the toolbox if needed.

Managing Me

I am pretty independent and don’t feel like I need much help in order to identify and execute on work that needs to be done. This likely comes from years in startups which don’t have the best support structures, but also I just tend to build things on my own.

My primary VAK modality is Auditory – therefore I absorb information better from presentations and meetings than I do from text. But I won’t force that upon others, it’s just my preference.

James Wallace

Professional README

Share Your Profile