DEV Community: DaedTech

The Renaissance of the Problem Domain as a First-Class Concern

Erik Dietrich — Thu, 30 May 2019 03:03:01 +0000

Hey, look at that — I’m writing a blog post again! Seriously, apologies for the lull, but, hey, life happens.

Enough of that, though. Let’s dive into some realio-trulio, software related content.

I Read an Interesting (Horrifying) Tale This Morning

Lately, instead of starting my day blearily looking at my phone and the emails that have trickled in while I slept, I’ve been starting each day with unstructured reading and chatting. I randomly read my feed, talk to people on Slack, watch a Youtube video, or take some research flight of fancy.

Anything goes as long as it’s:

Not completely mindless
Not directly related to work I’ll do

I can’t recommend this practice enough, especially for the self-employed set. It stimulates creativity and sort of gets all of the things that normally distract me out of the way.

But I digress. The real point of this mini-anecdote is to say that I read a blog post from Uncle Bob Martin this morning. It’s a compelling read, as his posts generally are, and it talks about the recent Boeing crashes.

Here’s something that jumped out at me, though, somewhat oblique to the narrative, and relatively mundane in an otherwise pretty grim tale.

Rather, programmers must [have] intimate knowledge of the domain they are programming in. If you are writing code for aviation, you’d better know a lot about the culture, disciplines, and practices of aviation.

And then, this, at the end:

We have to know the business domains we are coding for.

Huh.

The Fraught Relationship Between “Craft” and Domain Knowledge

This begs the question: are these “done-right” Boeing engineers programmers that happen to have aviation expertise, or are they aviation professionals that happen to program? If you find yourself saying, “both,” I’ll treat you to a witticism that I like from the agile world, designed as kryptonite to the project manager that proclaims all user stories top priority:

If everything is a priority, then nothing is, so I’ll choose for you.

And so it goes here. If you say that these Boeing software engineers should be both “programmer” and “aviation professional,” first and foremost, they’ll choose for you. And, which do you think they’ll choose. My guess is the “programmer” since, when they leave their jobs at Boeing in somewhere between 9 and 27 months to go program at a startup or whatever, they will cease to be “aviation professionals.”

Now, a big part of this story is, obviously, the domain transience of today’s software developer. But another part is the focus on “craft.”

My opinion on the craft guild metaphor is no secret to long time readers. We’ve taken it too far.

Software is neither a craft in the practical or the ontological sense. We don’t build software so that our customers might enjoy the aesthetic qualities of code well written, nor do we form local labor cartels for collective bargaining and go sleep in software engineers’ attics at age 11 that we might learn from them.

Software-as-a-craft is really a vibe. It says, “I care about the quality of the code that I write.”

And caring about that is inarguably a good thing. But a hanger-on to that vibe tends to come in the form of “I care about the quality of the code that I write first and foremost above other concerns.”

Other concerns like, say, what problem domain you’re working in.

“I can do excellent work in any industry or domain, if I abide by clean code principles and care about my work.”

The Bigger Picture: Are We Categorizing Software Work in a Fundamentally Flawed Way?

Of course, a focus on craft is just one source of this attitude — the first one that came to mind (doubtless because I was reading Uncle Bob’s blog).

It can also happen with hacker culture or the startup scene.

“Whatever, man, airplanes or air conditioners, jetting websites or betting websites, I just sling teh codez.”

Regardless of our attitude toward writing the software, our relationship with it defines how we identify in the corporate world. We are software {engineers,developers,whatevers} first, and everything else secondarily.

This was, no doubt, more reasonable decades ago when professional software people numbered far fewer. But now, there are something like 20 million software developers, so segmentation naturally had to emerge.

But what does this look like? Well:

React developer
Embedded engineer
Full-stack web developer
.NET programmer

Rather than:

Aviation programmer
E-commerce programmer
Sports gambling programmer

As a collective industry (whose justifiability I might increasingly debate), we haven’t specialized by customer, domain, vertical, or anything else externally understandable. Instead, we took our navel-gazing focus on the discipline itself, and doubled down on it over and over again, by specializing in our own tools.

This inside baseball form of specialization is so ill-suited — so opaque — that an entire industry (recruiting) has emerged to do nothing but help laypeople understand what we do. Don’t quite believe it? Imagine telling your grandparents that you’re a “react developer” and then imagine if that conversation wouldn’t go better if you’d brought a recruiter along to translate.

But Other Disciplines Stretch Across Domains!

At this point, I imagine you might have a predictable and understandable counterpoint. By implication, I’m demanding that software development, as a vocation, behave differently than, say architects, mechanical engineers, or even human resources. Aren’t we just following those well-worn tracks toward a pattern?

Well, yes. And that’s the crux of the problem, because software development is unprecedented.

Have any of those other vocations grown exponentially in a short amount of time?
Do any of them utterly dominate modern commerce?
Are they so intensely generalized with so few educational/certification barriers to entry?

I could go on, but hopefully you get the idea. We’re applying historical precedent to the unprecedented, and I think it’s time that we revisit whether that makes sense.

Architects design buildings, so you could sub-group them by the sorts of buildings they design. But sub-dividing them by who eventually occupies the building doesn’t make sense, and subdividing them by what sorts of software and what kinds of pencils they use is utterly ridiculous.

And, if you start to look at disciplines that have withstood the test of time, you’ll see that they balance the discipline with the beneficiary. For instance, all lawyers pursue common education and certification, but they then market and categorize their services in the language of their clients:

Divorce attorneys help people get divorced.
Criminal defense attorneys help people mount criminal defenses.
Patent attorneys help — alright, you get the idea.

Notice that they don’t bill themselves as “Plessy v Ferguson Attorney” and then leave it to you to figure out whether that means they can help you with a racial profiling civil rights case.

I’d Like to See a Rise in Picking a Problem Domain

If you were hoping that I had some grand plan to remedy all of this, then I’m going to disappoint you. I’m aiming more for “food for thought” with all of this. I don’t have the script for redefining software specialties, nor a sufficiently large soapbox that it would work if I did.

But I will say that I’d like to see a de-emphasis on specialty by programming skills/tools/techs, and a renaissance of a focus on domain. Like Uncle Bob, I think this would make for better software, more fit for purpose.

But I also think it would help usher in the Developer Hegemony vision.

One of the reason that software developers are such afterthoughts in the software development decisions companies make is that those companies heap 7 layers of management atop us. Why? Because we can’t be bothered to learn domains, drifting instead from codebase to codebase, utterly abdicating purpose and context to those earning more money.

Programming is so dominant — so ubiquitous now — that I think a better model might be the iconic “proficient with Microsoft Excel.” In other words, there aren’t really people that go from company to company saying, “whatever man, I just do Excel.” Instead, they just quietly use Excel to make them better at their actual job.

As I’ve tried to describe with this idea of the “efficiencer”, the real, core value prop of software development is time savings through automation. Imagine how efficient we might become in that if we picked a vertical/domain and learned it, focused on it, and became expert in it, rather than just wandering around tweaking ORMs for different companies.

We’d get better at niching and specializing, and we’d elevate ourselves into important decision making roles. And, to Uncle Bob’s point, this increased agency might just position us to impact the world for the better in powerful and gravely important ways.

The post The Renaissance of the Problem Domain as a First-Class Concern appeared first on DaedTech.

Software Career Anti-Patterns: Career Development by Coincidence

Erik Dietrich — Tue, 02 Apr 2019 22:46:59 +0000

It’s been a while since I’ve posted a hot take. And, to be fair, this is probably a lukewarm take, at best. I’m taking a slightly aged tweet, and I’m going to react to it in a slightly oblique way.

Here’s the tweet.

// Detect dark theme var iframe = document.getElementById('tweet-1110363543147155461-163'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1110363543147155461&theme=dark" }

I do have opinions on this tweet, and I’ll get to those momentarily. But, as I go through this post, I’m actually going to relate it more to a different facet of the programming world. Specifically, I think this has an tangential-but-important tie-in with how we tend to fetishize skill in the tech world, in spite of it being not that important in the scheme of things.

But let’s put a pin in that.

Conference Speaking is an Content Marketing Activity

If you’ve followed this blog for a while, you might have seen me write about this exact topic. I titled the post, “Conference Speaking Isn’t Good for Your Career Until You Make it Good,” and that title serves nicely as a spoiler for the content.

My premise is somewhat softer than Brianne’s, in that I neither discount speaking outright, nor do I make an _ad hominem _implication that youth and naivete govern speakers’ decision-making. My take is less that conference speaking is pointless and more that people tend to do it quite inefficiently.

In a professional context, conference speaking is a marketing activity and, more specifically, a _content __marketing _activity. You deliver value for free (in most cases) with the idea that investing your time and effort this way will pay off later. Other activities, including ones that Brianne mention also fall into this bucket.

Writing blog posts
Building FOSS utilities
Starting a Youtube channel
Building a social media following

And Conference Speaking is Uniquely Prone to Content Marketing Inefficiency

Now, as someone who spent years creating content inefficiently, I have plenty of perspective here. I wrote a blog like a journal, instead of an asset, and it led to all kinds of opportunities and new careers. So, I did it, and it worked, albeit less efficiently than it could have.

So against this backdrop, I’ll offer my own spin on Brianne’s comments, which I think make sense. When you miss the point with blog posts, software, social media, videos, etc, you can always rework that content into more efficient forms. You can’t do that with speaking, which is ephemeral.

In other words, while all forms of content marketing activities are prone to these inefficiencies, conference speaking makes it uniquely hard to course correct later.

Probably the biggest source of inefficiency for us in the software world is the preoccupation with impressing our peers instead of speaking to our buyers. In the throes of this preoccupation, we generate all sorts of content aimed at a sub-optimal audience and delivered in a sub-optimal way. To efficiently help our careers, we’d measure our content not in terms of software developers following us on Twitter, but in terms of dollars of salary offered to us by dev managers and VPs.

And, when we eventually discover this truth, we have a much easier time re-tuning old blog posts and videos than we do going back in time and speaking to different audiences.

The Reactions to Brianne’s Tweet Tell an Interesting Story

So far, I think you’d find yourself hard pressed to argue with my point, since I present it in something of a mercenary way. I’m ultimately measuring everything (as is Brianne, I think) in dollars and cents and eliding the personal development benefits.

In fact, let’s now look at some of those. Here are some (paraphrased) counter points in the Twitter thread.

It’s rewarding to advocate for something you’re passionate about and to give something to the community.
You can build confidence by speaking to large groups of people.
Speaking helps you cultivate and improve a variety of non-technical skills, such as teaching, organization and, well, speaking.
You learn a great deal about the subject matter of your talk.
With the other speakers and the audience, you network, make friends, and form human connections.

These cover a bit of ground, but there is a fairly heavy emphasis on personal development. You reap a lot of intangible benefits from giving talks, many of which have to do with making you a better person in some capacity.

Career Development by Coincidence

And now we get into the meat of what’s troubling me and why I started writing this post. Brianne made a pragmatic, efficiency-driven argument. And the lion’s share of the response wasn’t to refute her point, per se, but rather to come back with “efficiency isn’t everything.”

As I mentioned earlier, we in the programming world seem to assume that if we just sharpen miscellaneous skills that we have, the corporate world will take care of us. “I’ll get better at mentoring, asynchronous programming, and public speaking, and that’ll pay off for me professionally… somehow… eventually.”

This sort of attitude reminds me of an iconic concept in the programming world: programming by coincidence. Programming by coincidence happens when we get in the habit of saying, “I don’t really know why that works, but I’m glad it does, so let’s move on.”

Career development happens in a similar way. You plug along, improving whatever skills you feel like improving in a given month or year, and trust that fate will take care of you.

Not All Skills Help Your Career Equally, or Even at All

I saw Brianne’s tweet and the responses last week, and it wasn’t until today that I understood what about the debate had bothered me. And, truly, it’s this concept of career development by coincidence. Viewed through that lens, here’s how I see the discussion.

Brianne: If you take a data-driven, business-like look at your own career, you’ll see that speaking isn’t a very efficient strategy.

Popular Response: I disagree. I speak and I like my career, so my strategy must be working.

Is public speaking a valuable skill for a programmer? Is mentoring? How about power point? The answer to all of these is “probably, to some degree.”

But is a mastery of any of them going to make a difference to your salary and org chart position? That gets a lot harder to say.

The most direct counter-examples in the discussion thread are ones of immediate opportunities. People talk about getting a “break” as a result of a talk: landing a new client or job. And, while those are clearly wins, what’s less clear is:

Does, say, landing a client, actually move your career needle?
And does it even bring ROI from the time spent prepping the talk?

Now, to be clear, I’m not saying the the answer to any of this is “no.”

I’m just saying that, absent specific metrics, we can’t really say “yes,” either. And, if you’re going to be engaging in marketing activity for the sake of improving your situation, you should want a path to “yes” as surely as a SaaS company measuring conversions from a landing page.

De-emphasize Building Skills and Emphasize Driving Outcomes

“Skills” are largely internal concerns, personal to the individual. They scratch our itch for mastery and allow us to mark developmental progress through life.

But they don’t matter all that much to clients or even employers. Oh, sure those entities will ask about or demand skills, but in the same way you ‘demand’ skill from your tax prep company or accountant.

You don’t really _care about their skills. You care about _your outcomes that you perceive to depend on those skills.

And you certainly don’t care about how well your tax preparer crochets or how accomplished a pool player your mechanic is. Some skills are totally irrelevant to outcomes you’re supposed to provide, meaning developing them has legitimately zero commercial interest. Commerce isn’t an RPG where any marginal skill development makes your overall character stronger.

Skill development requires two things to benefit your career:

Relevance to the outcomes you deliver.
Consistent, measurable ability to improve those same outcomes as you develop it.

But since these things are both outcome-focused, why not just cut out the middle man and focus on outcomes?

If you want to write/blog/speak/whatever as a hobby because you enjoy the feeling of improvement and creation, then, by all means, do that. I have for years on this blog. But if you want those same activities to be demonstrably good for your career, you need to have a plan beyond the universe rewarding you for leveling up.

So start with outcomes, work your way back to the activities, and make sure you can measure your progress. Anything else is career development by coincidence.

The post Software Career Anti-Patterns: Career Development by Coincidence appeared first on DaedTech.

Should You Take a 100% Pair Programming Job?

Erik Dietrich — Wed, 20 Mar 2019 04:28:42 +0000

Pair programming. Understanding of this topic may vary among the readership.

Some of you might have the vague notion that it means two programmers working together… or something. Others of you might have a more solid grasp of particulars and a vocabulary that includes terms like “driver-navigator” and “expert-novice.” And, a few may even understand the full origin story of pair programming as a core plank of the eXtreme Programming (XP) approach.

Hey, Look, a Pair Programming Reader Question

I’ll soon return to that origin story. But first, let’s look at why I’m talking about this at all. I’m actually gearing up to answer a reader question:

I was interviewed by a company that [does] full pair programming. I hate the idea of spending all my day with somebody looking at me writing code. What do you think about it?

So to clarify a little here, we’re talking about a company that subscribes, full stop, to the XP rule that “all production code is pair programmed.” For all intents and purposes, this means that dev teams pair program 100% of the time as a rule.

Should you take a job at such a company?

It’s honestly hard for me to say for any given person since my advice would be so very tailored to your individual personality and preferences. So rather than immediately give a thumbs up or down, I thought maybe I’d explore the topic of pair programming more broadly.

Since my publication of Developer Hegemony and subsequent departure from a traveling consulting/training life, I’ve made this blog increasingly one about software developer empowerment. Today, I’d like to look at the subject of that pair programming through that relatively uncommon lens.

I want to examine not whether pair programming is a Good Thing (TM), but whether it’s a good thing for you , as a software developer.

Understanding my Pairing Biases, Such as They Are

Before I do that, I should acknowledge past work along these lines and writing on the subject. Frankly, it’s all been pretty pairing-positive.

I did a course for Pluralsight in which I helped software developers make the business case for pair programming to skeptical management.
I’ve written how-to/explainer posts professionally, like this one for Stackify, about pair programming.
And I’ve participated in pairing a lot over the years in situations ranging from the ad hoc to the formal.

But, on the flip side, I’m also a pretty textbook introvert. This leads me to regard pair programming personally in the same way I do open office plans: fun, tiring, and not how I feel most productive.

And this leads me to a relatively bemused point of view: able to make the case that pair programming benefits the team/company perhaps more than the individual, at least for some individuals. This is important to consider for the remainder of the post.

I say this because I’m going to argue that there are actually a number of reasons to be leery of this work situation, notwithstanding its effectiveness.

XP and the Origin of Pairing as a Popular Practice

But first, let’s return to the pairing and XP origin story. I wasn’t there, of course, so I won’t offer narrative details or editorializing, per se. But it sure looks like a handful of prominent developer-consultant types (who would later sign the so-called agile manifesto) came together and said, more or less, emphasis mine:

Hey, if things like code review and test-first approaches are good things in programming , let’s take them to the *extreme * and see what happens.

And it turned out that what happened was good. It went well enough that it generated early wiki pages, articles, books, etc. And the rest, as they say, is history.

Now, of course, this inspired an industry of emulation. We, as a working society, love nothing more than to attempt to reproduce things that went well for others. And, why not. This is one of the most fundamental ways to learn and grow.

But it also bears consideration that the XP rules were opt-in for the developer-consultants authoring them — “hey, what if we did X, let’s try it and see what happens.” But those opt-in rules will be mandatory for you, the workaday dev, 2 decades later, as you debate whether or not to go work at this company.

The Case Against 100% Pair Programming as Desirable for You, a Developer

With the backdrop securely in place, let’s get to the meat of it. I’ll go into my reasoning for why you might want to pump the brakes on accepting such an offer.

Please note that this only applies to people skeptical of 100% pairing. I’m not talking about a company where developers sometimes pair, which is, frankly, probably 90% of companies with more than one developer. And if you really like pairing, then, by all means, take the job. The approach has a ton of upside, and you like it, so go nuts.

The case that I’m making here is orthogonal to the efficacy of the practice, and understand that I’m not weighing in on whether or not teams should adopt 100% pairing policies.

1. The Throwback Emphasis on Physical Presence

Let’s start with something easy to grok. A lot of the practices and philosophies of the 1990s movement toward “agile” are meat-space focused, which makes sense for an era of fax machines and Citrix, or whatever. You sit in open office plan bullpens, write things on physical note cards that you stick to a wall, have daily stand-ups, and sit next to someone at a desk all day, every day.

In 1999, sure. But in 2019… really?

If you go get yourself a seat at any enterprise agile transformation, you’ll see an emphasis on change. In some cases, it’s change toward the modern: ditch the dress code, install Jenkins, do DevOps, etc. But, in some cases, it goes the throwback route: get out of the project management tool, use a dry erase board, and get everyone into the same room.

And so we see “throwback as progress” when it comes to development approaches. Now, I’m a fully remote worker and fully remote business owner, and have been for years. So I’m obviously biased, and I’m not going to lobby for remote over physical presence in this venue. (I’ll just say that it’s hard to imagine ever going back.)

But I will point out that a 100% pairing team/company is disproportionately likely to have rigid policy around butts-in-seats. If you’re pairing 100% of the time, it’s hard to justify risking a flaky remote collaboration tool. And it’s also hard to justify any kind of flex hours.

So you’re probably looking at a job where you need to be in your chair from 8:30 to 5:00, ready to interact socially, or else you’re letting your team down.

2. A 100% Pairing Mandate is Ipso Facto Micromanagement

Switching gears a little, let’s talk agency (or lack thereof). All of our devs pair 100% of the time is a formalized micromanagement policy.

Over the years and in my coaching/consulting travels, I’ve dealt with constant chafing between managers and developers on the subject of unit tests. I hear things about management not letting developers write automated tests. And I hear things about management wanting to see unit test coverage.

I advise management to knock it off. They shouldn’t be meddling in developers’ unit tests any more than they should be in how frequently they compile their code or check Stack Overflow. How the developers work should be up to those developers.

So how is the decision to pair or not any different?

There’s a particular irony here, given that agile methodologies tout flat structures and self-organizing teams. There was, of course, no hypocrisy when Kent Beck et. al. created the methodology because they were self-organizing when they laid out these rules. But you’re not self-organizing when you join a “pairing mandatory as official policy” company.

So understand that you’re joining a company that micromanages how you create software.

3. You’re Joining a Company Where Extrovert is the “Correct” Personality Type

Let’s get something out of the way. No matter how many talks I see on “pairing for introverts” or whatever, pairing is decidedly not for introverts. Honestly titled, those talks would be “Slightly Mitigating Your Inevitable Exhaustion and Burn-Out.”

But you don’t see this kind of honesty. And the reason you don’t is because of the extrovert ideal that Susan Cain defines in her excellent book on introversion. With the rise of the salesman persona, extroversion became the “correct” personality.

Think about school growing up. If you didn’t like the idea of group work or if you wanted to read a book at recess, the teacher felt a need to “correct” your behavior so that you wouldn’t earn the “anti-social” label.

This carries on into the workplace. If public speaking, group work, schmoozing, and small talk make you uncomfortable, the world tells you that you need to fix yourself to get ahead. “Here are 5 helpful tips that will cure you of that backward impulse to like solitude.”

Not all companies are equal in terms of embracing the extrovert ideal. And you can safely bet that a company demanding 100% pairing is outstripping the competition when it comes to trying to fix your broken introvert personality.

4. The Company is Playing Not to Lose

I’ll get more into the benefits of pairing for the company in the next section, but a big part of that benefit involves keeping developers focused and relatively mistake-free. The flip side of that is that you don’t have bursts of individual creativity and inspiration uniquely afforded by blind alleys and “unproductive” digressions.

Take the iconic (though apparently debated) example of Google’s 20% time. The essential premise is “we believe enough in our employees that we’ll give them a day each week to work on whatever they want, however they want, and trust that their undirected efforts will somehow pay off in seismic gains.”

That’s playing to win. It’s the equivalent of a football team up 14 in the 4th quarter and throwing downfield anyway. 100% mandatory pairing, on the other hand, is kneeling on the ball and then punting in that metaphor — playing not to lose.

A policy like this indicates that the company is primarily interested in predictable velocity out of the development staff, rather than brilliant ideas or game-changing developments. And there’s nothing at all wrong with that — it’s perfectly rational. The expected value of predictable, error-minimized work is going to be higher than the expected value of blind alleys with the hope of game-changers.

I’m mentioning this only so that you understand what you’re likely getting yourself into: a company that wants you to plug away predictably and unremarkably for 8 hours a day.

5. Subordinate Status Signaling

I’ll close with an argument that’s somewhat challenging to capture in just a few hundred words. I expanded on it at length in Developer Hegemony, but I’ll Cliff’s Notes it here.

Developers in mandatory pairing arrangements give off more of an air of juniority/subordinacy than their peers who are free to work as they please. To understand what I mean, consider three undeniable benefits of pairing as far as the business is concerned.

Collective code ownership spreads knowledge around the team and lowers “bus factor.”
Pairing means constant code review, which means fewer escaped defects and design issues.
Developers in pairing situations won’t face as many distractions and interruptions.

All good stuff, right? But now, let’s look at it through a dispassionate, corporate valuation lens. Here’s the CFO looking at you.

Pairing makes individual developer resources more fungible.
It helps overcome the inherent sloppiness of software developers.
It prevents developers from engaging their natural tendency to goldbrick.

And, once the CFO is done with her stroll through the open office bullpen, do you think she heads back to her table and pair-CFOs with her pair-CFO?

Of course not — that’s not something leaders do. She heads back to her office and works alone. In fact, this is not something even scrum masters, project managers and analysts do. It’s something that only developers do because only developers need accounta-bili-buddies.

Of course, nobody is saying this stuff, or probably even consciously thinking it. It’s just the subtle vibe that will permeate the organization. And it will tend to make leadership less inclined to listen to developers and to make technical positions “stickier” for anyone interested in lateral transitions or moving into leadership. At least it will until you can find a way to extract yourself from giving off subordination signals.

The Case for 100% Pair Programming as Desirable for You, a Developer

This section is going to be comically short and sweet. For me to make the case against 100% pairing took an awful lot of explanation. To make the case for it is easy.

Ask yourself this:

Do you enjoy pair programming and the thought of doing it all the time?

If the answer is yes, then go for it. Highly collaborative dev teams are effective, and this approach is good for the company. If it’s also good for you, then you’re signing up for an “everybody wins” kind of situation.

Mandated pairing has a number of subtle downsides for your individual career (and some not-so subtle, if you’re an introvert). But it also has some huge upsides for you, including:

Really, really quick learning if you’re new and working with more experienced folks.
Experience early and often as a mentor/coach, potentially leading to nice consultative career opportunities.
A crash course in office politics and navigating others’ personalities.
A hard to replicate sense of camaraderie with your team when it goes well.
Higher likelihood of making friend-associates that will last the duration of your career.

And, of course, you’re ideologically aligned with your company and its interests. And I can’t think of any circumstance where that’s a bad thing (provided you don’t go idealist and lose sight of your own interests).

So, Should You Take the Job or Not?

Normally, any article that weighs the pros and cons of something cops out in the conclusion with “so, as you can see, it depends and it’s up to you.” I’m not going to do that here, because what’s the fun in that?

Given the framing of this reader question, I would suggest to this reader that you probably should not take this job.

I’m an introvert, and I’m not a huge fan of group work. But I did find that each time I took a gig that was more collaborative than I was used to, I wound up enjoying the collaborative situation more than I thought I would. Not only was it not a nightmare, but a more open office plan or more pairing on the job actually proved enjoyable.

But it also tended to prove not sustainable, either. I’d work all day collaboratively and then work extra hours after everyone left because all of the collaboration didn’t feel like real work. Eventually, I’d tire, not from the long hours, but from the constant collaboration. And I’d move on or maneuver to a different project or role.

My point is this. You’ll probably enjoy the pairing more than you’d think. But given your gut proclivity, it will also probably wear on you.

There are a lot of companies out there with a lot of different philosophies. I’d find one that hews closer to your your own.

The post Should You Take a 100% Pair Programming Job? appeared first on DaedTech.