DEV Community: Chris Doyle

Setting Meaningful Employee Goals

Chris Doyle — Tue, 09 Feb 2021 05:13:42 +0000

I've always struggled with employee performance coaching. I wanted to set clear employee goals and give direct feedback, but somehow I could never put all the pieces together at once. Feedback without goals felt like complaining, and goals without feedback felt like wishful thinking. This created a big tension for me as a caring, empathic manager.

Through years of trial and error (mostly error) managing people as a CTO, I've finally uncovered a concise set of principles that seamlessly combine employee goals and feedback!

In a previous post, I outlined how to prepare for feedback communication. In this post, we'll examine how to execute your feedback conversation and expand it into a meaningful discussion of employee goals.

ACE Your Employee Goals!

You'll approach the conversation in three phases:

Ask. Always start with a question. ALWAYS👏 start👏 with👏 a👏 question!👏

Connect. Guide the conversation by linking observations (not judgments) to their words.

Expect. Be clear about outcomes.

Plan for an hour. Half an hour isn't enough, and you'll get antsy after an hour. Don't rush it; if you run out of time, you can always schedule a follow-up.

And remember, employee goals are a collaboration. You're setting the stage, creating structure, and providing guardrails around the process. This gives the employee autonomy and support, while helping them arrive at goals that support the larger organization.

Ask: Create a Safe Atmosphere For Growth

Starting your feedback conversation with a question builds trust and rapport and cultivates a growth space. You need them to know you're interested in their thoughts and you're on their side, so engage in this discussion! Show you're listening. Ask clarifying questions, deepening questions. Seek the core of their ideas. Let the conversation flow for at least 5-10-15 minutes before starting to Connect; you want to give them time to get comfortable opening up.

While you're discussing their views on your topic area, look for hooks that correspond to your Observations - you'll use them to transition from Ask to Connect. You can always refer back to the hooks later, you don't have to jump on them immediately. Record especially relevant snippets verbatim, so you can Connect directly to their own words later (as a clarification, not a trap).

You're trying to map their mental space so you can frame your feedback using their own mental model. This deepens the relevance of your feedback and enables intrinsic, sustainable change.

Connect: Interpret Observations Together

Now that you're playing on a field they've created, use your observations to gently guide their thinking. You want to be like a potter at the wheel rather than a blacksmith at the forge. Allow the employee to influence your judgments as they offer their own data points. After all, this is a collaboration.

To help this phase feel natural but still keep things on the rails, I use four tactics:

Enhance when they say something I like. Agree with them, repeat what they said in my own words. Add observations that support their point.
Challenge ideas holding them back. Literally say "Can I challenge that?" and mention a relevant observation that encourages them to rethink their position.
Question again when they haven't yet led me into an area I want to talk about and the current thread has dead-ended or started circling.
Reframe if I want to bring my own perspective to the discussion. Combine a few hooks to triangulate a new idea for them. Since this explicitly puts me in the driver's seat, I use it sparingly (mostly when the first three are taking too long).

Some observations naturally land more forcefully than others. Deliver challenging observations tactfully by keeping them objective and impersonal. These are the most sensitive and difficult moments - you must remain on the employee's side as you help them process new information, while also standing firmly confident in your observations. The conversation may change the interpretation or importance of an observation, but the observation itself is yours: your thought, your perspective, based on your experience. Save your flexibility for supporting the employee's goals; rewriting the past doesn't help anyone.

Expect: Set Concrete Employee Goals

Alright, you've spent 30-45 minutes or more tilling the field; it's time to plant the seeds. Pivot the conversation to the future.

Take a break if you're coming up on the 1-hour mark. These are intense conversations, you'll both need a break, and the employee needs a chance to absorb everything. Better to end on a high note and schedule a follow-up than burn them out with a marathon session.

Approach this phase with a continuation of the ask-and-guide mentality, and shoot for two or three SMART goals. Since the first two phases focused on topics that you chose, the employee will naturally be thinking about goals in those areas! They're likely to suggest goals that both satisfy your expectations and feel achievable.

If not, you may need to escalate the directness and force of your guidance. Escalate carefully, and strive to remain objective and on their side. Ultimately you can force them to adopt a goal you set, but they won't get far without their own passion. The best goals are ones you both strongly believe are achievable and impactful. Any goals that you bring to the table need a killer pitch to achieve buy-in from the employee. Luckily, you have a detailed picture of how they see this topic that you can use to craft that pitch if necessary.

Do NOT allow the employee to set goals that don't align with the needs of the company! The employee wonders why they aren't promoted even though they achieved their goals, you wonder why the employee isn't effective, and everyone gets frustrated. They can set personal goals and do whatever they want on their own time, but performance at work needs to advance the interests of the company as well as the employee. Redirect with a yes-and: "Your idea is great; you also have a big opportunity at our company by doing XYZ and I want to see you get the biggest impact for your effort." A little open honesty goes a long way.

Bonus: Keep The Ball Rolling With Easier Feedback!

One more absolutely critical point:

WRITE. IT. ALL. DOWN.

Referring back to this conversation, their mental map, and specific outcomes they'll pursue, directly supports your daily coaching. You can relate specific scenarios to the bigger picture, discuss various options for a situation and how they might play out, and meaningfully celebrate wins in real-time. Connecting employee goals directly to real-world experiences amplifies your message over time.

Don't push your advantage! Celebrate with someone when they get a win through your suggestions. Even point out to them the wins they might not see. I know, you're excited to see your suggestions working, but hammering every win with a moral basically amounts to "I told you so" - or worse, assumes they can't connect the dots themselves.

When the next performance review cycle rolls around, being able to tie your new observations to concrete, specific, previously-agreed upon goals sets you up for another productive conversation.

You're Ready To Set Employee Goals!

Together, high-level goals and concrete feedback create the structured environment and sustained effort that propels employees toward their potential. It's hard to do well, but if you nail this process and you'll stand out in their pantheon of impactful mentors.

What struggles do YOU face setting employee goals? Tweet me @archslide and share your story!

Mastering Feedback Communication

Chris Doyle — Thu, 04 Feb 2021 23:27:41 +0000

I've always struggled with employee performance coaching, especially with communicating feedback. This created a big tension for me as a caring, empathic manager. I saw feedback as a critical part of my role, but whenever I gave corrective feedback I felt like I was scolding someone when I should be supporting them. Through years of trial and error (mostly error) managing people as a CTO, I've finally uncovered a concise set of principles that allow me to both fulfill my duty as a manager and feel good about it!

Effective feedback starts with intent. In this post, we'll discuss how to prepare for feedback communication. With careful reflection, you can create a meaningful feedback conversation that supports employee growth.

ACE Your Feedback Communication!

You'll approach the feedback communication conversation in three phases:

Ask. Always start with a question. ALWAYS👏 start👏 with👏 a👏 question!👏

Connect. Guide the conversation by linking observations (not judgments) to their words.

Expect. Be clear about outcomes.

To prepare, you'll create a list for each phase, likely bouncing among the three as you go.

Questions for the Ask phase
Observations for the Connect phase
Expectations for the Expect phase

Questions Set The Scene For Growth

Change begins with awareness and acceptance, and a belief that change is possible - aka a growth mindset.

Growth mindset is a safe, expansive, creative mindset. Criticism puts the employee in a defensive mindset: an unsafe, constrained, fall-back-on-existing-strengths mindset. It's critical to approach feedback from a growth perspective.<>

Starting your feedback conversation with a question builds trust and rapport and cultivates a growth space. Active listening shows the employee you care about them and their opinions, rather than telling them what to do or punishing them for some real or imaginary imperfection. Remember, criticism does not engender change. You may feel pressure to be firm, be direct, lay down the law - but opening with strong corrective statements like "you need to pick up the pace" only breeds fear and distrust.

Think about the topics you want to cover, then craft clear, open-ended questions to kick off a conversation in each area. Some questions you might start with:

For someone who's been stagnant:
- How do you feel about your growth?
- Have you been growing? On what dimensions?
For someone you want to see step up:
- What does leadership mean to you? Who do you see demonstrating leadership?
- What makes them exemplary?
For someone who needs to improve technically:
- What are the most important parts of the development process?
- What are the best ways to learn from others?
For someone who's been isolated:
- How do you want to show up on the team?
- What do you want to contribute?

Stick with the one or two most impactful opportunity areas. No one can change everything at once.

Try building momentum by linking these to recent changes. "Given our new strategy, how do you see yourself contributing over the next six months?". You're partnering with the employee to navigate a new situation together, instead of piling more pressure on them. A team change, process change, personal change - it's all fair game. Employee goals are as much about adapting to dynamic circumstances as they are about the employee's individual direction.

Observations Communicate Feedback Objectively

What is an observation? It's a data point. Not an accusation, not a judgment. In fact, observations remove judgment from the conversation by forcing you to evaluate your emotions and biases.

If you feel an employee works slowly, that's a judgment. But why do you feel that way? What actions have you observed that create this impression? Maybe they're missing deadlines, or they aren't pushing much code, or they're asking the same questions over and over. All these observations can have reasonable explanations that don't assuming a fundamental lack of ability (try thinking of some!). But until you Ask - truly, deeply, curiously Ask - you can't valid your assumptions (hint: they're probably wrong).

Before ACE, I would go into performance reviews armed with judgments. During the conversation, I would always discover new information about the situation. How could I not? The employee has a lot of info I don't have. This put me in an impossible position: deliver my judgment and feel like I was unfairly criticizing the employee, or not deliver it and feel like I hadn't addressed the problem. No matter what I chose, I left the conversation feeling like a bad manager.

An Observation remains the same in the face of additional data (data + data = more data). Its meaning invariably changes (interpretation + more data = new interpretation). A growth-minded employee readily, thankfully accepts new data as an opportunity to learn and accelerate. A criticized employee rebels against new data as they seek to reverse your preconceived judgment.

By reserving judgment, you can together decide what these mean. Since you haven't finalized a mental model of the person, you leave room to update it as they add their own observations.

Some ways to generate Observations:

Just think of some 😛 Seriously though, you likely have firsthand experience with this employee or you wouldn't be working with them on feedback and goals. Write down anything that's top of mind.
Think of how you feel about the employee; these are NOT observations. Think about the behaviors that make you feel this way; these ARE observations!
Incorporate observations you've heard from others about the employee (if and only if you think it's relevant)

And, some additional tips as you prepare for your feedback communication:

Rely on your experience! You know a lot of things and people want to hear what you think, even if it seems obvious to you. What table stakes are they doing well or poorly against? Don't assume they know it.
Rely on your position! Employees value your perspective; you're able to see things they can't (and vice versa).
You don't need a ton of observations to have a productive conversation
You do need to include some positive observations. Building up their confidence smooths the growth process ("belief in ability to change"), so plan how you're going to make them feel good about their strengths and contributions.

Expectations Bolster Impact

The rubber hits the road with expectations. What behavioral changes do you want to see from your employee, and why? Again, write them down in advance but be prepared to adjust on the fly.

Expectations should be grounded in the employee's role, and relate closely to the needs of the company. Across the board, they should be the same for everyone doing the same job. Yet, individuals will thrive with different goals based on their skills and interests, and as a manager you must find a win-win balance between generic role expectations and the unique strengths of the individual.

Expectations have little to do with Observations, either. Decoupling the two allows you to stand firm with your expectations regardless of how the Ask and Connect phases went.

For example: you want your employee to build a reputation as an expert, and you see an opportunity for them to create stronger relationships outside their team. You observe them hanging back in larger meetings, and thus not getting on the inter-team radar. During your feedback communication conversation, you learn they have a massive fear of public speaking. No problem! This new data doesn't change your expectation (stronger relationships), only your approach. Together you set a more appropriate goal on an easier avenue for them: casual one-on-one chats.

Some tips to generate expectations:

Consult internal assets: your career framework, the job description for the role, preveious performance evaluations
Think about company needs and company strategy, and how this employee fits into the bigger picture
If you could change one thing to turn this employee into the most amazing example of this role, what would it be?
What is the employee's biggest strength? How could they double down on it to help the company?
What is the employee most excited about? You'll see much more growth in an area they're naturally attuned to.
Reference the SMART framework to craft concrete goals together

You're Ready To Communicate Feedback!

Careful preparation alone changes the tone and impact of your feedback conversations. But wait, there's more: feedback and goals are two sides of the same coin. Feedback without goals is just complaining, and goals without feedback is wishful thinking! In Part 2, we'll discuss how to expand your feedback communication conversation into a meaningful discussion of employee goals.

Look for Part 2 in February 2021! Drop me a line if you want to get notified when it launches.

What are your go-to questions for easing into a tough topic with an employee? Tweet me @archslide and share your story.

Manager's Guide: How To Hire Web Developers

Chris Doyle — Fri, 08 Jan 2021 14:57:33 +0000

The brief euphoria of your newly opened headcount has transformed into a full panic: "how on earth will I hire a web developer for my team?" Don't worry - you can and you will successfully hire a great engineer and emerge a hero! It all starts with one little secret:

Commit.

I know, your instinct is to balance hiring with other priorities, aka half-ass it. Mine too. Unfortunately, that's a great way to drain your time and energy for a year with nothing to show for it. Instead, plan to spend a massive amount of time for eight weeks. We're talking at least 20-35% of your week, depending how much help you can get. "Won't that suck?" you ask. Yes, it will suck. But at the end you'll move on with your life as the manager of a larger, more capable team! I'll say it again because it's the difference between success and failure:

Commit, or fail.

It's scary to invest so much time, but below I'll share the comprehensive process that has allowed me to hire great web developers - not painlessly, but efficiently.

Attracting The Right Web Developers

Nailing your job description is crucial. The document itself is important, but the mental rigor behind the document underpins this entire process. Hiring web developers can be so hard that you feel you have to take anyone you can get; that's a myth. By starting with a clear idea of your ideal team member, and realistic expectations, you'll find the right person. So ask yourself:

What Skills Are You Truly Hiring For?

A fearless assessment of your needs will smooth every subsequent step.

Are you trying to hire web developers for a startup? Hiding your chaos might help you hire faster, but your team can't support a developer who thrives on structure and direction. That quick hire will turn into a nightmare of a performance management problem. Your goal is not to convince someone who isn't a fit - your goal is to find a developer who's already aligned.

If your hire will be expected to navigate an ambiguous role with no oversight, just say so.

Why Would A Developer Join Your Company?

Luckily, being transparent with candidates about your company is a strength, not a liability. You may think "this place is a mess, we don't even have a sprint process yet" is going to turn people away. And it will! But there are also plenty of developers searching for an opportunity to take a leadership role and help improve your development process. My career has focused on startups, and "leadership opportunity" has been part of every job I've ever posted.

What else makes your opportunity uniquely attractive to a web developer? Sure, you aren't Google/Facebook/Amazon/etc and you can't afford to compete with them on salary, but compensation isn't the only thing a candidate considers. Plenty of developers don't want to work at a big company - focus on what makes your role interesting and exciting! Being a key contributor on a small team, working on novel challenges, or learning a new tech stack are totally valid and compelling "unique selling propositions" for your candidates.

Alright, now that you understand who you need, let's go find them!

How To Find Great Web Developers

Buckle up, because this is the soul-crushing part. Once you start it's an all-out sprint to the finish line, so get your ducks in a row up front. If you're doing it right you won't have time to do anything but execute your plan.

Sourcing

VOLUME VOLUME VOLUME VOLUME VOLUME. The last search I conducted we started with over 1000 LinkedIn profiles and hired two people. A thousand sounds like a lot, but it's manageable if you tailor your process to the volume.

Your goal in this phase is to find hundreds of profiles who have a passing shot at being a fit, as quickly as humanly possible. An actual recruiter, a LinkedIn Recruiter license, or free tools like vanilla LinkedIn or AngelList can get you there. Use the search filters in whatever tool you're using to cast a wide net. LinkedIn Recruiter allows you to search by fields like role title or skill endorsements. Honestly these filters barely work, just do what you can.

Do not spend ANY time inspecting profiles, except for a few spot checks to see how you can improve your pool composition. Inspecting profiles at this stage will quickly descend into madness. The one thing that's going to give you encouragement in this phase is - say it with me - VOLUME.

When your pool reaches at least 200 profiles you can move on to the next step. Substantial batch size will improve your efficiency and build momentum. Momentum is essential for morale during hiring, especially once you start involving more of your team in the later phases.

Did I mention this process thrives on 📣📣 VOLUME?!?!?!!?! 📣📣

Narrowing The Field

Now you're going to analyze the profiles. But wait - there are hundreds! Go in with a strategy or you'll be here forever. Decide ahead of time on a small number of simple criteria. For example, in a recent search I was looking for a web developer with at least 6 years of experience and solid ruby/rails exposure. Look ONLY for these things when reading profiles. You'll quickly hone in on the fastest way to find the info and make a decision.

Since you're going to be doing so many of these, make sure you have a fast and reliable way to analyze, store your decision, and repeat. The speed will make or break you. At my best this year I analyzed about 80 profiles an hour on LinkedIn Recruiter. This is one of the most soul-crushing steps, it's so rote and monotonous and it just feels bad to be judging humans so mechanically. Psych yourself up, spend an hour or two plowing through it, and then give yourself a break. Too long and your brain will glaze over.

Many profiles will be in a gray area - don't worry about it, in those few cases the penalty for getting it wrong is minimal. You can always source more profiles, and the rest of your process will weed out anyone that you over-included.

Expect extensive drop-off in this step, 50-80% or more depending how well your tools let you tailor your initial pool.

Reaching Out

Once you have at least 30-60 profiles that meet your basic criteria, you can start reaching out. You only get a few sentences of attention, so make sure you're clear about the role and your unique selling proposition. Unless you're targeting specific people for a high level role like a Principal or VP, don't worry about customizing this outreach. We're still in a volume-based scenario here. Write the most interesting form letter you can, make sure you address everyone by the correct name, and just let it fly.

You probably won't send enough of these to run a true A/B test, but tune your message if you glean any insights as you go. For example, I had been telling people we're a Chicago company but initially hadn't clarified that the role was remote-friendly.

The goal of this phase is to schedule a 30-minute follow-up, so make sure to close your message with a strong call to action. Something simple like "Are you interested in a quick call to learn more?" is great. A yes/no question makes the response super easy.

I like this phase, because we get to start seeing some results! 👀

We've found that having an engineering leader reach out rather than a recruiter materially increases our response rates.

Interviewing Web Developers

We're finally going to start talking to people. You might modify this structure to fit your own circumstances, but as long as you hit the high points you'll be okay.

Initial Screen

A 30 minute call starts building a rapport with the candidate. This phase requires significant time and effort, because the previous phases are such inexact filters. But your goal is to hire, and that means balancing what works for you and what works for the candidate. A call is much more engaging than an email thread, so I usually move to a voice/video channel as fast as possible. I've had good luck spreading this work out so I don't have to personally make every single call.

When someone shows interest in your initial reach-out, you can reply: "Great! The next step is a call with Alan, he's open tomorrow 2pm-4pm, what works for you?"

You might see a small drop-off from people who expected to talk to you personally, but it's worth it to save your calendar from utter destruction.

In this call, pitch your role/company and see if there's mutual interest.

Do they actually have the technical experience you need?
Do they check one or two of your most important boxes? Any obvious red flags?
What's their timeline for making a move?
Discuss comp if you want ("what would it take for you to consider making a change" or "our salary range for this position starts at 140k" are good, "what are you making now" not so good and potentially illegal)
Answer their questions
Discover their motivation (key for later!). If you can't offer best-in-class salary you're going to have to appeal to them in a different way.

Technical Screen

One way or another you want to evaluate the candidate's technical ability. I'm not trying to resolve the many schools of thought on technical evaluation in this post. As a starting point I'll just say that at Ascent we currently offer either a take-home exercise plus a video chat to review it, or a live pairing exercise. The candidate can play to their strengths and needs, and we get a conversation about code either way.

This is when I start bringing another team member or two into the process. They can help evaluate code samples and conduct the review, and I usually ask them to review take-home responses without including any personally identifying information to reduce bias in our process.

On-Site / Full Loop

Now it's time for the whole team to get to know the candidate. By this point, you know a fair bit about the candidate, but your team does not. It's natural for the team to be skeptical, which can easily come across as cold or harsh for the candidate. Give your team an outline of what you know about the candidate so far. The candidate's motivation is especially useful here. And, gently remind the team to be warm and "sell" the candidate a bit. Whether or not you make an offer, you want every single candidate coming out of your process to be excited to work for you.

Choosing The Best Web Developer

Adopting a rubric is one of the most effective ways to improve your candidate evaluation. It should include the dimensions you want to evaluate, and examples of what constitutes strong or weak performance on those dimensions. The Medium engineering team has an excellent rubric I've used as a starting point. A rubric reduces bias in the hiring process by helping you evaluate candidates equally and objectively (to the extent any judgment of a human after three hours is objective).

A rubric has become one of my most valuable tools as a hiring manager.

With a rubric I feel like I've systematically evaluated a candidate, touching on each and every aspect I care about. Strengths and gaps become obvious, and the final outcome feels like a fully informed decision. Gone are the days of finger-in-the-wind vibe-based hires. Make sure your team understands the rubric and references it liberally in their feedback.

The final element of selecting the right web developer is gathering evidence-based feedback from your team. Rather than asking hypotheticals like "what are some important elements of teamwork", ask for a concrete example: "When is a time your team worked really well together? How did you contribute?" This ensures the candidate can walk the walk as well as they can talk the talk. Think back to some of your best and worst interviews, and you'll find that evidence-based answers made candidates seem much more grounded and capable, and when you come away thinking "they said all the right things" but still feeling wary or hollow it's often due to a lack of evidence. Don't just take their word for it - dig all the way to the core.

Use "STAR" questions to gather evidence. Ask about the Situation (original problem statement), Task (the candidate's responsibility within the situation), Action (what they did), Result (how it went). You'll quickly discover the difference between their knowledge and their experience.

Making The Offer

Finally, after 4-6 weeks and hundreds of person-hours, you found a developer you like! Amazing! Time to seal the deal. Here's how you're gonna make it happen:

Make the offer "in person" (video/phone is fine)
Ask for any remaining questions. Especially in a remote environment, the candidate will have zero opportunity for hallway/elevator/interstitial conversations where they can just get comfortable.
Tell them why you want them! If you can't make a very convincing pitch to the candidate about why THEY are right for YOUR team, you've severely missed the mark in previous steps. Everyone likes to feel special and seen; just try to reflect their best qualities back to them.
Remind them why working for you will address their motivation and advance their career. This dovetails closely into the previous item.
Present the full offer. Carefully explain non-cash aspects of their compensation: equity, benefits, etc. Most people won't care about every benefit, but many people care deeply about one or two. Make sure your offer fits into your salary bands properly or you're going to have big problems later.
Don't pressure them to commit, but get an initial indication of how they feel about the offer.
Let them have a reasonable (but not indefinite) amount of time to think it over. A week is standard.
Resist the urge to negotiate against yourself. If they don't jump at the offer, it doesn't mean they won't accept. If they want another 5k they'll ask for it. If they want another 500k, this was never going to work out in the first place.

Onboarding

We'll save this one for later. Right now, breathe a giant sigh of relief and do something nice for yourself, you deserve a break! Hiring web developers is one of the most challenging, draining aspects of engineering management. If you can do this, you can do anything.

What's your best tip for making it through the hiring process alive? Tweet me @archslide and share your story.

Time Travel - The True Power of Developers

Chris Doyle — Sat, 02 Jan 2021 04:29:16 +0000

In Abstraction is Art: Why All Programmers are Creatives, I described the central role abstractions play in technology and technical companies. This post builds on those ideas to discuss how innovation works in the medium of abstractions.

Progression: Advancing Abstractions

The tools we use both limit and advance our thinking. If I gave you a hammer and asked you to build a birdhouse, I’d probably get something like this:

But if I gave you scissors, you might build a birdhouse like this instead:

You could have found your own hammer and built a wooden birdhouse anyway, but the scissors put you in a certain mindset. In software our tools are abstractions (a specific type of idea) and the same concept applies.

In Orwell’s classic dystopian novel 1984 society is being oppressed under the watchful eye of Big Brother. Their subjugation is so complete that even thinking about rebelling against the government is a crime. They are no longer able to articulate revolt, communicate about revolt, plot revolt, or eventually even IMAGINE revolt; they are no longer able to revolt. Over time, the very concept of rebellion is lost.

To “unlock” this ability, they would need to awkwardly describe it using combinations of existing ideas until they solidify the concept, name the concept, and finally evangelize the concept and the names to the rest of the population. Only then would revolt become possible again.

Our Responsibility

When we accurately anticipate the future, our progress accelerates because each step is built on top of a previous enabling idea instead of starting from scratch each time.

As programmers we have the opportunity to build our own tools, our own abstractions, our own language – and this gives us tremendous power and responsibility. Every decision has a cascading effect, making certain things easier and certain things harder. We make dozens of decisions every day as we write code, and those decisions move us closer and further away from any given feature we might want to build in the future. Our requirements just said “birdhouse,” but once we make a birdhouse, is the business going to ask us to expand into bird apartments (probably easier in wood) or allow customers to request custom sizes (probably easier in fabric)?

We have to solve today’s problem while simultaneously anticipating tomorrow’s needs. There’s a careful balance between thinking ahead and overengineering, giving rise to terms like YAGNI (“you ain’t gonna need it”). But thinking and building are two different things – it’s always worth thinking a couple steps ahead so you don’t paint yourself into a corner. When we accurately anticipate the future, our progress accelerates because each step is built on top of a previous enabling idea instead of starting from scratch each time.

How do we get better at predicting the future? Context.

Context as Binoculars

If we’re doing our jobs right, we’re making decisions with the full awareness of a wide variety of contexts. The more information we can bring to bear in each decision, and the more deeply we can empathize with the stakeholders providing that information, the more accurately we can imagine futures that anticipate the needs of our constituents.

So what exactly are these “contexts” that are so important? There are a few that are fundamental. You have to have a really solid grasp of the technology you’re working with, and how the technical landscape is changing. Understanding the customer is paramount; they’re the ultimate arbiter of whether you’re creating value. It’s critical to understand your company’s business model and how it fits into the broader market. Ultimately anything that helps you understand your particular problem domain and solution space is going to serve you well. Side note: this is why diversity is critical. Someone brings the context they gained in a college CS program, someone else brings the context from their artistic background, and someone else brings the context from their time in sales or customer support.

Luckily, guessing the future is only half the picture. As developers, we can have a strong influence on how the future unfolds.

Progression is Vision

A house starts with a foundation, then the scaffolding of the walls, then the plumbing/electrical, then the drywall, then the plaster, then the paint, then the furniture. In the earliest stages we can barely see it’s going to become a house, but the architect has a plan. Over time we start to get a rough idea of the finished product, but there are still many questions to be answered. Eventually, we’re living in the space and trying to figure out how to position our couch around the weird angle in our living room wall.

When our abstractions come together into a larger whole, we’ve created a framework, a conceptual model. It stands under its own weight; it has internal consistency; it has structure and shape and boundaries, strengths and weaknesses, characteristics like any physical object. Rather than starting from scratch on every new problem, we instead think about which parts of our framework are relevant and how we can refine them to apply in this new situation. Maybe we repurpose a guest room into a nursery, or build a deck so we can grill and relax outside – our options aren’t always easy, but it’s hard to justify a new house for every new need so we find a way to make it work.

Because future questions are answered inside the framework, the framework sets the direction for future conversation long in advance. It frames the discussion before the discussion even begins. As developers, this is the power we possess: to set the stage of the future. If we’re careless or oblivious about this power we’ll be continually tripping over our feet; when we wield it with intention and foresight we can achieve any future we envision.

Abstraction Is Art - Why All Developers Are Creatives

Chris Doyle — Sat, 02 Jan 2021 04:26:26 +0000

Mind The Gap

Humans have always built on top of the work of those who came before us. Karl Benz was able to invent cars because he had the wheel and the combustion engine. Orville and Wilbur Wright were able to invent planes because they had gliders and bicycle chains. They were successful because they looked at the world around them and brought existing ideas together in a new way.

The technological acceleration we've seen in the last 50 years is driven by the same principle of building on previous work, with one important difference: our production costs have fallen to zero. Henry Ford had to build factories to realize his ideas. General Motors and Rolls Royce had to build concrete bunkers to test their jet engines in case they exploded. Programmers need only open their laptop and get to work. Without production costs, the cycle of innovation now happens at the speed of thought.

Almost.

There's still some friction in the cycle, and it's basically because computers are not smart. Fast? Yes: we can tell them "do x, do y, do z" and they'll do it in milliseconds - but they have no idea WHY. But we have our reasons, right? We ask them to add the numbers in a spreadsheet because those numbers represent our income and expenses, so the sum represents our profit. We ask them to send a paragraph of text to our friends because that paragraph represents a funny thing that happened at work.

WE know the whys, because the whys are part of our world. The computers don't know the whys, because the world of the computer is incredibly limited. Computers are still literally dealing with ones and zeroes, and could not be further away from our messy experience of hugs and giraffes and hot chocolate.

In order for computers to be useful in our rich and meaningful world, we need to bridge the gap somehow. As programmers, we need a way to keep our feet in both worlds at once. That bridge is abstraction.

What Is Abstraction?

Think of a car. Got one? I bet it has four wheels and an engine. "Car" is an abstraction, a generalized idea. As a society, we've communally decided that wheels and engines are important parts of all cars. Is it blue or red or black? Who cares. Color doesn't fundamentally change the thing we're talking about, whereas something with wheels and no engine might be a bicycle rather than a car. Since color is not important when we're talking about cars, it hasn't become part of the abstraction.

For a computer to handle our complex world, we have to simplify — and we simplify by just leaving stuff out. It's much easier to tell a computer about our Platonic ideal of a "car" - four wheels and an engine - instead of every single minor detail and variation in the actual cars in the actual world. As programmers we also know which properties of a car are useful for our particular task, and that’s how we choose what to include and what to leave out. If we’re running a race track, we might want our computers to know about top speeds and RPMs. If we’re running a rideshare company, our biggest concern is the number of seats.

We give the computer a limited view, but we ourselves still have a full world of knowledge. This duality is what makes programming possible; the same abstraction can be simple and "machine-readable" while also being emotional, subjective, and yes - artistic.

Art Is Abstraction Is Art

Artists are trying to represent a particular slice of the world through a specific perspective. In holding a mirror to society, they selectively include or exclude certain details and ideas to present an opinionated view. Even a photograph - an "exact replication" of the world - has an opinion by way of subject matter, framing, editing, and the context of its display. Art, then, is an abstraction. It's an idea, stripped of all its nonconsequential details to highlight its core.

Creating and experiencing art helps us understand ourselves. It allows us to experiment, to learn, to fail, to try another way. This boundless exploration extends beyond the physical world as well: we can delve into love, loss, or any aspect of the human experience without going through those events directly.

The same way a novel, poem, dance, or painting captures the world, so do abstractions. Perhaps the closest comparison is to storytelling. Stories are full of complex devices for manipulating ideas. Metaphor, allegory, fantasy. A story allows us to construct new realities through imagination. Stories are powerful because they connect with our deepest selves, and through the details we choose to include or omit, they have a point of view. Abstractions similarly afford us limitless opportunity to explore, build, learn, and communicate.

So What Is Programming?

Artists create sketches, drafts, studies, and yet the final work is not always as imagined. Artistic ideals are sometimes subverted for a paid commission. Programming is not always joyful or meaningful either, but programming is always an artistic endeavor. It's fully subjective, it's based in the realm of ideas, it's an act of creation, and it involves the creator holding an opinionated mirror up to the world.

Thinking of programming as a technical endeavor is correct but woefully insufficient. This is why so many of the best programmers I've worked with have significant artistic backgrounds, and why I always say anyone can learn to code.

As in any discipline, programmers stand on the shoulders of those who have come before us. In programming, those previous works are works of abstraction. The earliest programmers were truly writing programs with ones and zeroes. But someone abstracted those ones and zeroes into english characters, and abstracted those english characters into software instructions. Over the decades, countless thousands of developers have slowly advanced programming languages to the point where many programs do read somewhat like prose. They have created networking libraries, databases, web browsers, apps. Each of these abstractions is built on the abstractions before it, and the work of every programmer is to use existing abstractions and their own ingenuity to create new works.

Programming classes/books/blogs/etc usually focus directly on code, which isn’t entirely surprising - a group of potters would probably focus on clay, too. The code is what's sitting in front of us; it's obvious. Abstraction is less obvious, yet far more important. I will go so far as to say that abstraction, not code, is the fundamental medium of programming. And thus, while computers themselves might be governed by math and equations, programming computers is primarily a creative, subjective, artistic activity.