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
-Elon Musk
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 try and optimize the following metric: Working code, in the hands of customers, with as low defect rate as possible, as quickly as possible.
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
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.
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.