Joe Conley Tagged startups

Orwell's Rules for Writing (Software)

Fri, 26 Feb 2021 00:00:00 +0000

I’m in the middle of reading Churchill and Orwell: A Fight for Freedom and so far really enjoying the parallels drawn between two of history’s most important figures. Both had military experiences which informed their worldviews, both suffered serious career setbacks, and both keenly saw the threat of totalitarianism for what it was and worked tirelessly to prevent its spread.

About midway through the book the author enumerates Orwell’s six rules for writing. Examples follow of Churchill having similar thoughts on the brevity, economics, and power of language. So I thought I’d help translate these ideas for any software engineer who might care to listen:

1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.

Never use common variable names like data. That’s not very meaningful, all of this stuff is data! Metaphors and simile don’t tend to be useful unless the ideas are truly core to your abstraction.

2. Never use a long word where a short one will do.

Be thoughtful when you name things. Variables, functions, and classes should have the shortest and most meaningful names possible. You’re building a mental world from scratch, and the language you choose defines how everyone else will think.

Conversely, unless your indexing over a list, single-letter variables are probably too short. Seeing variables a through z littered about code without any context or meaning is plain mean. In my early days of engineering, I heard stories about a paranoid contractor who intentionally used obscure naming to make his code impossible to read, thus making him “indispensable”. Fool of a Took! It didn’t work, and I think both Orwell and Churchill would agree there’s a special rung in Hell reserved both for people who waste good scotch and engineers who use language to such evil ends.

3. If it is possible to cut a word out, always cut it out.

Prefer functional methods and languages where possible, i.e. choose Scala over Java. This can dramatically reduce lines of code, and help you think at a higher level of abstraction that is generally a positive trait for folks who live and create worlds of abstraction most of the day. Yes imperative code might seem easier to write but if you have to do anything at scale you need tools like this in your toolbelt.

4. Never use the passive where you can use the active.

Have clear separations of concerns in how you architect systems. If a single method does a dozen different tasks, refactor it. This empowers your objects to have clear and distinct jobs and focus on doing them well. This allows to build high-performing systems at scale if you can reliably compose modules that do what they’re supposed to do.

5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.

When you talk to the business folks, speak in simple terms. Trust me, they know you’re smart, you don’t need to show off. Speaking in plain English helps you show that you’re more than a code monkey, and helps them learn more about software and feel empowered about the product.

6. Break any of these rules sooner than say anything outright barbarous.

If your startup’s MVP needs to work for tomorrow’s demo, then yes by all means write your imperative for-loops and mutate state to your heart’s content. But be mindful when the exception starts to become the rule.

Hire Joel Embiid

Fri, 15 Jan 2021 00:00:00 +0000

Startups are a team sport. The players you choose to work with have such an outsized impact on the team (for good or ill) that you really have to have “A” players at every position. But it’s not enough to just say “go hire all-stars”. There’s very specific attributes you need to look for, and that I found this week watching Joel Embiid lead the Sixers to a gritty overtime win.

Joel Embiid is the embodiment of the Sixers philosophy in hiring (AKA drafting) championed by Sam Hinkie. He has grown to become a dominant force in the league, consistently ranking at the top in scoring and defense. But when you see him play it’s clear he’s not just your typical all-star. He has a unique blend of skills that serves as a powerful model for early-stage startup hiring.

Eye for Talent

Source: https://www.youtube.com/watch?v=faZY6W3toh0

Pictures speak volumes. Beyond his pure physical growth, Embiid is improving his game every year. He’s consistently added different nuances to his offense. This year he’s improved his recognition and passing out of double teams (helps to have shooters to pass to, thanks Daryl!). This eye towards growth has translated into success on the court.

Startup hiring is about finding young talent that you can grow into high performers. It’s probably the trickiest, most challenging, and arguably the most fun aspect of hiring. Like Billy Beane trying to find inefficiencies in the market, it’s rewarding to not only identify talent early but help them grow as a significant part of a team trying to build something from nothing.

What’s even more poignant about startups is you have to get it right fast! Pro teams get a new draft class every year, and can make up for mistakes like this or this or even this (though I’m still rooting for him). Startups don’t have that luxury. The window for getting the timing right can be so small, and can literally mean life or death, that you have to be brutally efficient when it comes to hiring.

Wears Many Hats

Here’s the line for Embiid from Tuesday night:

Source: https://www.espn.com/nba/boxscore?gameId=401267317

Excellent scoring, great defense, made all 13 of his free throws, just all-around dominance. This is a big man who can be top 5 in scoring and defense, is strong from the foul line so you can’t resort to hack-a-Shaq, and is a good enough shooter to force defenses to respect his presence beyond the arc. At one point on Tuesday he had three guys trying to defend him to no avail, I mean how do you stop a force like that?

Point being, it’s very difficult to build startups with specialists. You are going to pivot at some point, and the cost of having high turnover to constantly mix and match narrow puzzle pieces is too inefficient. Seek generalists early, then once you’ve established traction think about more specialized roles. Generalists cost too much you say? Then be generous with the equity upside. Give them real skin in the game, and then give them room to operate.

Pure Will

The most impressive feat in Tuesday’s win was in the third quarter, Embiid dropped 22 points in 8 minutes. He literally decided to take over the game, got the ball almost every trip down the court, and willed the team to victory. Talent is one thing, but having that pure strength of will is rare and really fun to watch.

Find me a team of folks who have that same will to not only push through on execution but also the honest determination to understand what’s true and the vision to navigate, and I’ll bet on them every day of the week. It takes a special strength of character to survive the inevitable ups and downs of startup life.

Culture Matters

I’ve been a Philly sports fan all my life, and Embiid has to be near the top as far as local popularity goes. He’s outspoken, goofy, works hard and wants to win. Similar to Allen Iverson, he gives it his all, and expects his teammates to do the same.

It’s cliche to say that culture matters in startups, but it’s important to note that it starts from the top. Leaders set the culture, either consciously or otherwise. Now more than ever, it’s important to take care of your team, understand their challenges on and off the field, and build an environment that supports them in every way shape and form. Who wouldn’t want to work for a team with a culture of excellence?

Trust the Process and Have Fun!!!

Lastly and most importantly, we’re on this earth a short while. Let’s have fun and play hard!

What is a CTO?

Tue, 01 Sep 2020 00:00:00 +0000

I’ve spent a lot of time thinking about what a CTO is. It’s important to really think through this role as it can have such a huge impact on companies both large and small. You can search the web for “startup CTO vs. big company CTO”, “CTO vs. VP Engineering”, etc., but those debates miss the point. What matters is understanding the function of a CTO in your organization. And I assert that a CTO is an executive who serves the business through the deployment of technology.

That’s it! The details of implementation will vary widely based on company, industry, and the strengths and weaknesses of the individual CTO. But at its heart, this role requires a leader who has a strong fundamental understanding of technology and how to use it to support a business.

What, then, is technology? It’s easy to assume that things just “get better” over time. We’ve emerged from the cave and tilled the earth, dammed the streams, and harnessed the power of the sun as we march towards greater standard of living. However, none of these advancements were inevitable. Progress depends on us inventing the future.

This topic is more important than ever. It’s hard to argue that software is eating the world, and as a result, every company is now becoming software. Technology advancement has accelerated change in every walk of life. Powered by trends of cheap computing power and new techniques to analyze data, this wave of extracting value from data is overhauling every and any domain it gets its hands on.

Is this wave of technological progress “good”? Any type of significant change can and will cause issues like job displacement, but I believe that as technology helps automate mundane labor, it should create opportunities for human beings to focus on higher-level, more creative work. This underscores the importance of having strong, thoughtful education for everyone young and old.

Given the speed and complexity of these trends, it’s important to have someone who understands technology at a sufficiently deep level (software, hardware, whatever). I’ve found the best CTO’s form strong opinions about their technology choices, yet dispassionately remain open to searching for the best solution. They rely on tried-and-true systems rather than chase what’s trendy. They push hard for excellence, but balance that with sensitivity to solving the customer’s problem in a cost-effective way.

It’s also important to note that a CTO is an executive. I think the toughest thing for a newly-dubbed CTO to learn is how to scale not just code but an entire organization. As a lead engineer or architect, your choices are mostly constrained to scaling infrastructure or analyzing data. Once that “C” shows up in your title, however, your biggest challenges tend to be people-problems. Which seats on the bus do I fill first? Can I grow this junior resource into a contributor, or do we need to move on? Can I make peace between two warring factions? You’re definitely moving “up the stack” here, and it requires a wholly different skillset than what got you here.

Personally, I value the opportunities I’ve had to serve as CTO because I know that I can have a meaningful impact on a company. I know my decisions will have consequences, and I relish the challenge to move the needle where I can. Most of all I enjoy aligning a team towards a common goal. By its nature, technology strives to improve how we live our lives, and to serve as the steward for its application is a privilege.

I’ve also been blessed to have found an informal network of mentors who I rely on regularly when facing tough decisions. I’m hoping I can start to do the same.

At the end of the day, it’s just really cool to helping spearhead the deployment of technology for an organization. I’m a huge Elon Musk fan for a lot of reasons, but his quote about why he went into engineering really spoke to me:

Just really cool to think about engineering in terms of building new things which enable really smart people to keep making progress and ultimately improve our collective consciousness. It’s inspiring to think we’re all trying to play a part to create a better future. It’s why I pivoted from a pure mathematics career to one grounded in technology. Because it’s “what’s next”

Shape Up or Ship Out!

Wed, 29 Jul 2020 00:00:00 +0000

Have you worked on a software team that consistently shipped high-quality work on-time? I’ve seen companies large and small have plenty of difficult delivering software. Either things break in production, or things don’t ship on time, or worst-case both.

And in most cases, the antidote was supposedly to “be more agile”. Planning poker, Fiobancci story pointing, backlog grooming, and all of the other well-trodden ceremony should make these issues disappear. And to be fair, I’ve seen these things “work”, but only to a certain extent, and usually over the short-run. I’ve tried them myself with mixed results, and an underlying apprehension I could never put my finger on. Did software engineers pick this profession out of a love of project estimation and ticket management tooling? Does any of this feel like a natural way to treat human beings?

And so it is with this undercurrent of dissatisfaction that I recently found Shape Up by Ryan Singer. It’s a refreshing take on how to craft software. The book is a perfect size to read, and has a great blend of thoughtful ideas paired with practical advice from the trenches of a well-known and successful product company, Basecamp.

This book hit a lot of notes for me, but the biggest idea was how work is shaped and handed off to the development team. Projects aren’t chopped up into tickets, doled out and estimated. The product strategy team defines a project with CLEAR BOUNDARIES and a FIXED TIMELINE, and lets the development team work through the details and manage themselves, with clear checkpoints along the way. This allows developers to use their brains to come up with their own implementation ideas, frees up the product team to stay focused on high-level strategy, and doesn’t require a middle-manager (i.e. Scrum Master) for communication.

This is the essence of management that delegates without abdicating responsibility. Shaping creates guardrails to allow a team to grow and experiment without hand-holding, trusting but verifying that the project’s thoughtful criteria will be met. I think these ideas would be borderline radical in most companies I’ve seen.

Why does any of this matter? Because I believe technology companies can be agents of change. Crafting tools that help automate and streamline rote tasks so human beings can focus more on human work should be the ultimate goal of most technology offerings.

In that same spirit, how do we as technology leaders ensure that the builders of technology are allowed to do more human work? By giving them more responsibility in an environment where they feel safe. I think the true measure of success for any company is not just revenue growth or user adoption but how did your team grow professionally and personally? Otherwise, what’s the point in winning?

In addition to managing teams, I think the concept of shaping and fixed deadlines helps us manage ourselves too. Rather than keeping an iron-clad todo list, think at a higher level what you’d like to accomplish for a given week or month, make sure you focus on achieving the core “functionality”, and then DELIVER. Keeping a blanket list can trick your brain into thinking all tasks are created equal and MUST be done. Being more thoughtful about time constraints and scope helps to reframe and reorient your mind, and start building your shipping muscles.

This speaks to another key point that Singer, Clayton Christensen in Competing Against Luck , and even Peter Thiel have all talked about. Namely, a lot of the time the key to solving a problem is how to frame the question. Whether it’s deciding what features to build into a product, how to build out your organization, or how to spend your life, the way we frame the question helps guide us to the answer.

Ultimately, finding humane ways to ship software will be an ongoing challenge for leaders and contributors alike. Amid the rise of automated coding tools like GPT-3, there will be a need for thoughtful, effective leadership that understands what questions to ask and what tools to build.

So Shape Up, or ship out!

The Real Secret of Monkey Island - Innovation

Wed, 10 Feb 2016 00:00:00 +0000

One of my favorite games growing up was the Monkey Island series by LucasArts, a swashbuckling, point-and-click adventure game full of challenging puzzles, funny witticisms, and (of course) monkeys. I had been so used to mindless, side-scrolling console games like Super Mario Bros. that finding this mutli-dimensional experience was eye-opening. The possibilities seemed endless! It’s hard to believe this game is already 25 years old, yet the gameplay and cultural references still hold up.

The high level of interactivity with the environment is a hallmark of LucasArts games. Hovering over areas on the screen will prompt you to look at certain items or talk to certain people, gathering information to achieve your goals (like trying to become a pirate). You’re also encouraged to explore every corner of the universe as information from one area will help solve puzzles in another area. You’re also forced to think more expansively about the items in your inventory and improvise where necessary. At one point you’re asked to produce a helmet. Luckily, a cooking pot works just as well in a pinch. Moreover, you can also combine items to create something wholly new. For example, you’ll often need to create potions in the series by acquiring and combining several ingredients.

You’ll soon find that while playing these games, you’ll be developing a very specific set of skills, like problem-solving and persistence. If you’re ever stuck on a puzzle and aren’t sure what to do next, you will inevitably try every combination of inventory items to generate some new ideas or talk to everyone in all possible permutations to garner new information. This speaks to the notion of the adjacent possible, the idea that one can review all of the current possibilities and constraints of a specific topic and determine the immediate first-order steps to take. In his book Where Good Ideas Come From, Steven Johnson describes this process as a “map in which the present can reinvent itself” capturing “both the limits and the creative potential of change and innovation.” He cites the example of Apollo 13, where a team of engineers had to improvise and build a carbon dioxide filter using only the available inventory on the lunar module. This spirit of curiosity and experimentation permeates the entire Monkey Island series.

The act of tinkering with commonplace items can give the player a sense of reawakening, turning the mundane into the novel. This hearkens to Tolkien’s idea of Recovery, “seeing things as we were meant to see them”. The poetic language in The Lord of the Rings enchants the reader, bringing meals, journeys, and nature to life. This explains why stories like his tend to be re-read. While our daily routines force our environment to become “blurred by familiarity”, these adventures help us regain “a clear view”.

The ability to connect different experiences in Monkey Island also brings to mind Einstein’s idea of combinatorial play which Einstein deemed “the essential feature in productive thought”. Combining and recombining ideas tends to reveal unknown connections. This creative state of play happens before any logical construction occurs. As my old Trivium professor used to say, “Pooka doesn’t do windows”. In other words, the process of inspiration and actually connecting the dots are different. Playing the Monkey Island series certainly brings that idea to the forefront.

The Monkey Island series is an enjoyable ride, both thought-provoking and funny. It also helps the player develop skills necessary for creativity and innovation. The series stands in stark contrast with the popular games of today, which overwhelm with cinematic spectacle but usually fall short on engaging the whole person. I’m looking forward to re-playing the series with my son.