DaedTech

Stories about Software

Mar
6

By

The Grating Fallacy of “Idea Guys”

Category: The Life of a Programmer Tags: , | 2 Comments

If you’ve been following this blog for a while, you might have seen me engage in talk about the MacLeod Hierarchy from time to time in the comments with various posters. We’re referring to a concept where the denizens of a corporate organization fall into one of three categories: Losers, Clueless, and Sociopaths. It’s explained in delightful detail in one my favorite blog series of all time, but I’ll give you the tl;dr version here of what defines these groups, so that I can use the terms more easily in this post. I’m quoting this synopsis from Michael O. Church’s follow up analysis of the subject, which I also highly recommend. The names are inherently pejorative, which was probably a stylistic choice when picking them; none of these is inherently bad to be, from a moral or human standpoint (though one might argue that Clueless is the most embarrassing).

Losers

    • , who recognize that low-level employment is a losing deal, and therefore commit the minimum effort not to get fired.

Clueless

    • , who work as hard as they can but fail to understand the organization’s true nature and needs, and are destined for middle management.

Sociopaths

    , who capture the surplus value generated by the Losers and Clueless. Destined for upper management.

At this point, I’ll forgive you if you’re just now returning to my blog after a lot of reading. If you’re a fan of corporate realpolitik, those are extremely engrossing series. I bring up these terms here to use as labels when it comes to people who are self styled “idea guys” (or gals, but I’m just going to use the male version for brevity for the rest of the post). I’m going to posit that there are generally two flavors of idea guy: the Loser version and the Clueless version. There is no Sociopath “idea guy” at all, but I’ll talk about that last.

What do I mean, exactly, when I say “idea guys?” Well, I’m not being as literal as saying “people who have ideas,” which would, frankly, be pretty obtuse. Everyone has ideas all day, every day. I’m referring to people who think that their essential value is wrapped up in their ideas, and specifically in ideas that they imagine to be unique. They see themselves as original, innovative and, ironically, people who “think outside the box” (ironic in the sense that someone would describe their originality using what has to be one of the top 10 most overused cliches of all time in the corporate world). Indeed, given their talent for creativity, they see an ideal division of labor in which they kick their feet up and drop pearls of their brilliance for lesser beings to gather and turn into mundane things such as execution, operations, construction, selling, and other ‘boring details’.

I Coulda Made Facebook

The Loser “idea guy” is the “coulda been a contender” archetype. If he’s a techie, he probably talks about what a bad programmer Mark Zuckerburg is and how he got lucky by being in the right place at the right time. The Loser could have just as easily written Facebook, and he has all kinds of other ideas like that too, if he could just catch a break. He might alternate between these types of lamentations and hitting up people for partnerships on ventures where he trades the killer idea for the execution part: “hey, I’ve got this idea for a phone app, and I just need someone to do the programming and all of those details.” MacLeod Losers generally strike a deal where they exchange autonomy for bare minimum effort, so execution isn’t their forte — they’d like to hit the “I’ve got an idea” lottery where they dream something up and everyone else takes care of the details of making sure their bank accounts grow by several zeroes.

We Need to Have a Facebook!

The Clueless “idea guy” is, frankly, a lot more comical (unless you’re reporting to him, in which case he’s borderline insufferable). In contrast to his Loser brethren with illusions of Facebook clones or cures for cancer, this fellow has rather small ideas that take the form of middling corporate strategy. He is a master of bikeshedding over what color the new logo for the Alpha project should be or whether the new promo materials should go out to 25 pilot customers or 30. Actually changing the color of the logo or mailing out the materials? Pff. That’s below his paygrade, newbie — he’s an idea guy who shows up 10 minutes late to meetings, makes the ‘important’ decisions, orders everyone around for a while, and promptly forgets about the whole thing.

Whereas the Loser “idea guy” views his schemes as a way to escape gentle wage slavery, the Clueless version is delighting in playing a part afforded to him by his status with the company, which is basically itself a function of waiting one’s turn. Future Clueless comes to the company, puts up with mid level managers ordering him to do menial tasks and showing up late to his meetings, and, like someone participating in any hazing ritual, relishes the day he’ll get to do it to someone else. “Idea guy” is perfect because it involves being “too important” to follow through on anything, personally, or even extend common courtesy and respect. It’s a vehicle for enjoying a position that allows for ordering people around and reminding everyone that people in overhead positions say jump, and they have to ask “how high?”

While it’s certainly possible to encounter a Clueless with ambitious ideas (perhaps a pet project of redoing the company website to look like Apple’s or something), they’re pretty uncommon, which makes sense when you think about it. After all, part of the fundamental condition of a Clueless is enough cognitive dissonance to believe that his position was obtained through merit rather than running out the clock, and trying to push a big idea to the players in the office above him is to be threatened with rejection and possibly even ridicule, so why bother? Micromanaging and demanding the removal of ducks is a much safer strategy for pleasant reinforcement of his position of power.

I’ll Create a Bubble and Sell This Company to Facebook

So what about the Sociopath “idea guy?” As I said, I don’t think this exists. It’s not that sociopaths don’t have ideas. I might argue that they’re the only ones that have ideas of significance in the corporation (losers may have excellent ideas, but they go nowhere without a sociopath sponsor and spin). But they certainly aren’t “idea guys.” Reason being that sociopaths know what matters. To re-appropriate a famous line Vince Lombardi would say to his Packers teams, Socipaths know that “execution isn’t everything; it’s the only thing.”

A Sociopath doesn’t really assign any pride to ideas, opting instead to evaluate them on merit and implement them when doing so is advantageous. If his ends are better served by letting you take the credit for his ideas, the Sociopath will do that. Alternatively, if his ends are better served by ripping off someone’s idea and doing that, he’ll do that too. No matter what the source of the idea, it’s simply a means to an end. It’s not his baby, and it’s not to be jealously guarded, since ideas are a dime a dozen, and there will be others.

Ideas, like paper or computers or projectors, are simply tools that aid in execution or even, perhaps, inspiration for improved execution. A Sociopath is a doer in every sense — a consummate pragmatist.

Winning the Race of Achievement

If idea guys come from the ranks of Losers and Clueless but it’s only the Sociopaths that capture and capitalize on excess value created, doesn’t this mean, cynically, that people who have great ideas are never the ones that profit? Well, no, I’d argue. Sociopaths have plenty of ideas — they just aren’t “idea guys.” Ideas are commonplace across all organizational strata and across all of life. Sociopaths are simply too pragmatic and busy to create some kind of trumped up persona centered around the remarkably ordinary phenomenon of having ideas; they’re not interested in dressing up as Edison or Einstein and turning their life into some kind of extended Halloween.

Pulling back from the MacLeod categorization, it’s sufficient to say that what turns the motor of the world is commitment, work, dedication, execution, and frankly a bit of luck (though I’d argue for the adage that luck is largely a measure of time and being prepared). Sure, ideas are a part of that, but so are oxygen and conversations. They’re such ubiquitous parts of all that we do that they’re not worth focusing on or even mentioning.

In Macbeth, the title character issues a fatalistic soliloquy that describes life as “a tale, told by an idiot, full of sound and fury, signifying nothing.” This sentiment captures the impact in a group or meeting by a self-styled “idea guy,” particularly of the Clueless variety. He charges in, makes a lot of bold claims, proclamations, and predictions, and then toddles on out, altering the landscape not at all.

If you want to make your impact felt, I’d say there’s another quote that’s appropriate, popularized in American culture by Teddy Roosevelt: “walk softly and carry a big stick.” Don’t declare yourself victorious at the starting line because you dreamed up some kind of idea. Assume that ideas, even great ones, are nothing but your entry fee to the race, expected of every runner. Let them be your grit and inspiration as you labor your way through the course. But realize that the actual, boring mechanics of running — the execution — is what wins you the race rather than whatever inspirational poster saying occurs to you as you plod along.

Mar
5

By

There’s No Excuse

Category: Language Agnostic Tags: | 10 Comments

If you have a long, error-prone process, automate it. This is the essential underpinning of what we all do for a living and informs our day to day routines. Whether we’re making innovative new consumer applications, games, line of business applications, or anything else, we look at other people’s lives and say, “we can make that automatic.” “Don’t use a pen and paper for your todo list when there’s GTasks.” “Don’t play risk with a board and dice when you can do it online (or play an Elder Scrolls game instead).” “Don’t key all that nonsense in by hand.”

And yet, far too often we fail to automate our own lives and work. I wonder if there’s some kind of cognitive blindspot we have. When other people mindlessly perform laborious tasks, we jump in and point out how dumb what they’re doing is and how we can sell them something that will rock their world. But when we mindlessly perform laborious tasks (data entry, copy and paste programming, etc) we don’t think twice or, if we do, we assure ourselves that it’s too complicated or not worth automating or something.

I was going through some old documentation the other day to look up what was needed to add another instance of a feature to a legacy application. What it boiled to was something along the lines of “we have an application that sells computers and we want to add a new kind of PCI card to the configurable options.” Remarkably, this involved hand-adding things to all sorts of different meta data tables in a database, along with updating some stored procedures. The application, generally speaking, was smart enough to do the rest without code changes, even including GUI updates, so that was a win. But hand-adding things to tables was… annoying.

If only there were something that would let people add things to the database without using the query explorer tool and doing it by hand… something where you could write instructions in some kind of “language,” if you will, and translate these instructions into something visual and easy to understand so that people could add meta-data more simply. Hmmm.

Wait, I’ve got it! How about instead of a document explaining how to add a bunch of records to the database, you write an administrative function into your GUI that automates it? What a victory! You get the meta-data added and your new PCI option, and you also remove the possibility that you’ll mangle or forget one of the entries and leave the system in a poor state. This is really the only option. It’s not an either-or kind of situation. Hand-adding things to your database is facepalm.

What’s the moral of this story? To me, it’s this: if you have a giant document detailing manual steps for programmers to follow to get something done, what you really have is a spec/user story for your next development cycle. Automate all the things, and then burn those documents at a cathartic, gleeful camp fire. You can turn your onerous processes into roasted marshmallows.

Feb
27

By

Introducing “You Asked For It”

Category: You Asked For It |

Believe it or not, it turns out that I actually get a pretty decent amount of emails (and growing) asking for advice in various forms or making requests for posts about various subjects. Typically, I answer and/or correspond as time allows and am fortunate to have a number of interesting conversations in this fashion. It’s a cool way to meet fellow techies, and it’s really quite flattering to be asked for advice.

I was thinking that I might turn these kinds of exchanges into posts when applicable, with posts corresponding to batches of shorter questions or individualized for bigger ones. Historically, I’ve regarded direct correspondence as just that, but I’m going to start seeing if people would be amenable to me posting responses here and then doing so, if they’re good with it. No worries if you’re not — I don’t mind email correspondence, and you’re still obviously free to write. I’ve even updated the contact page to have my direct email address instead of just the general LLC’s contact.

And, if you have post requests, email isn’t the only venue for you. Feel free to ask in the comments, on twitter, or anywhere else you find me. Feel free to make requests for content specifying that you’d prefer to remain anonymous or that you’d prefer to be identified as the question asker. I’ll be putting these posts into a new category, “You Asked For It” once I start making them. I don’t anticipate this being overly common, but look for them now and again. And, since I’ll be doing this, please continue to send questions and requests! It’s fun for me to answer them and if it helps you, all the better.

I’m off to the Pluralsight Author Summit for a long weekend, so enjoy your own weekend, and also, enjoy this illustrator’s choice drawing of a turtle-lady sipping a daiquiri.

TurtleLady

Feb
25

By

Define An API By Consuming It

Category: .NET Tags: , | 5 Comments

Lately I’ve been working on a project that uses a layered architecture with DDD principles. There’s a repository layer and, below that, lies the purity of the domain modeling. Above that is an API service layer and then various flavors of presentation, as needed. One of the toughest thing to explain to people who are new to some of these concepts is “what should the service layer do?” Go ahead and try it yourself, or even look it up somewhere. Things like data access, domain, repository and presentation layers all have easily explained and understood purposes. The API service layer kind of winds up being the junk drawer of your architecture; “well, it doesn’t really belong in the domain logic and it’s not a presentation concern, so I guess we’ll stick it in the service layer.”

This seems to happen because it’s pretty hard for a lot of people to understand the concept of an API of which their team is both creator and consumer. I addressed this some time back in a post I wrote about building good abstractions and this post is sort of an actual field study instead of a contrived example. How do we know what makes sense to have in the application’s service layer? Well, write all of your presentation layer code assuming that you have magic boxes behind interfaces that cater to your every whim. If you do this, unless you have a pure forms-over-data CRUD app, you’ll find that your presentation layer wants different things than your repositories provide, and this is going to define your service level API.

Take a look at this relatively simple example that I dreamed up, based loosely on a stripped down version of something I’ve been doing:

public class EmployeeController : Controller
{
    private ISomeServiceIllDefineLater _service;

    public EmployeeController(ISomeServiceIllDefineLater service)
    {
        _service = service;
    }

    public ActionResult Index()
    {
        return View(_service.GetAllEmployees());
    }

    public ActionResult Index(string departmentName)
    {
        var employees = _service.GetEmployeesByDepartmentName(departmentName);
        return View(employees);
    }

    [HttpPost]
    public ActionResult Create(Employee employeeToCreate)
    {
        _service.Create(employeeToCreate);
        _service.DispatchWelcomeEmail(employeeToCreate);
        return RedirectToAction("Employees", "Index");
    }

}

One thing you’ll notice straightaway is that my controller is pretty stripped down. It really just worries about the arguments to the HTTP methods, a terse summary of what to do, and then what to return or where to redirect. The only things that will make this more complex as time goes on are GUI related things — enriching the model, adding more actions, altering the user’s workflow, etc. This makes unit testing/TDD a breeze and it keeps unpleasantness such as “how to send an email” or “where do we get employees” elsewhere. But, most importantly, it also defines an API.

Right here I’m thinking in the purest terms. I want to show my users a list of employees and I want to let them filter by department. I also want to be able to add a new employee. So, let’s see, I’m going to need some means of getting employees and some means of creating a new one. Oh, and the requirement says I need to send a welcome email in most circumstances (times I wouldn’t based on an elided GUI setting), so I’ll need something that does that too.

Now, you’re probably noticing a serious potential flaw with this approach, which is that having a service that sends emails and fetches customers seems as though it will violate the Single Responsibility Principle. You’re completely right. It will (would). But we’re not done here by any means. We’re not defining what a service will do, but rather what our controller won’t do (as well as what it will do). Once we’re done with the controller, we can move on to figuring out appropriate ways to divvy up the behavior of the service or services that this will become.

Here’s another thing I like about this approach. I’m in the habit of defining a “Types” assembly in which I put the interfaces that the layers use to talk to one another. So, the Presentation layer doesn’t actually know about any concrete implementations in the Service layer because it doesn’t even have a reference to that assembly. I use an IoC container, and I get to do this because of it:

public class EmployeeController : Controller
{
    private ISomeServiceIllDefineLater _service;

    public EmployeeController(ISomeServiceIllDefineLater service)
    {
        _service = service;
    }

    public ActionResult Index()
    {
        return View(_service.GetAllEmployees());
    }

    public ActionResult Index(string departmentName)
    {
        var employees = _service.GetEmployeesByDepartmentName(departmentName);
        return View(employees);
    }

    [HttpPost]
    public ActionResult Create(Employee employeeToCreate)
    {
        _service.Create(employeeToCreate);
        _service.DispatchWelcomeEmail(employeeToCreate);
        return RedirectToAction("Employees", "Index");
    }

}

public class DummyService : ISomeServiceIllDefineLater
{
    public void Create(Employee employeeToCreate)
    {
            
    }
    public void DispatchWelcomeEmail(Employee employeeToCreate)
    {
            
    }
    public IEnumerable GetEmployeesByDepartmentName(string departmentName)
    {
        return Enumerable.Repeat(new Employee(), 12);
    }
    public IEnumerable GetAllEmployees()
    {
        return Enumerable.Repeat(new Employee(), 100);
    }
}

Right there in the controller’s source file, below it, I stick a dummy implementation of the service and I wire up the IoC to use it. This is really handy because it lets me simulate, in memory, the way the application will behave assuming we later define real, actual service implementations. So I can use TDD to define the behavior of the controllers, but then I can also use this dummy service to define the layout, appearance, and flow of the views using actual, plausible data. And all of this without worrying about data access or anything else for the time being. I’m bifurcating the application and separating (to a large degree) the fulfillment of user stories from the nitty gritty technical details. And, perhaps most importantly, I’m defining what the service API should be.

I like having that dummy class there. It creates a warning for me in Code Rush (multiple classes in the same source file) that nags at me not to forget to delete it when I’m done. I can modify the GUI behavior right from the controller. As I add methods to the service while going along with my TDD for the controller, it’s easy enough to add implementers here as needed to compile. I consider this a win on my many fronts.

And when I’m done with the presentation layer and satisfied, I can now look at the single service I’ve defined and say to myself things like “should this be more than one class?” or “is some of this functionality already implemented?” I’ve nailed the presentation layer and I’m ready to do the same with the service layer, knowing exactly what kind of API my ‘client’ wants.

Feb
21

By

Why Social Situations Exhaust Introverts: A Programmer’s Take

Category: The Life of a Programmer Tags: | 43 Comments

I’m going to apologize in advance if this winds up being a long post.  But it’s a topic that requires a great deal of introspection, and I find that attempting to explain myself is one of the hardest things to abbreviate.

Over the years, I’ve read a bit about the topic of introversion versus extroversion and, being in an industry in which introversion is often assumed, I’ve also seen a number of memes about it. This one is probably my favorite, if for no other reason than seeing the poor introvert hissing like a cat at some invasive extrovert.

Introverts and Extroverts Get Energy in Opposite Ways

This comic provides a memorable graphical explanation of what other sources such as wikipedia explain more dryly: that extroverts draw energy from social interactions and that introverts spend or use up energy during those same interactions.

On the whole, I find this explanation pretty satisfying as it more or less explains my life and experience. I’m the classic example of “not all introverts are shy or socially awkward.” I am competent in social situations and even fine with things like public speaking — it’s just that, after a long evening of spending time with people, I tend to get home and think, “wow, finally…”

I’m not a huge fan of the vague and sort of hand-wavy idea of “mental energy” and it seems likely to me that there’s a more concrete physiological explanation involving adrenaline and dopamine or something.  But the effect on me, personally, is undeniable.

The thing I’d like to explore is how and why these interactions are taxing to me. Maybe you’ll find that my explanation resonates with you. Maybe I’m just a lone weirdo.

Read More

« Older Posts
Newer Posts »