DaedTech

Stories about Software

By

Mistakes Dev Managers Make

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at the site.  If you like this post, head on over, and check out more at the site.

Managing a team of software developers is a tall order. This is doubly true when the line management includes both org chart duties (career development, HR administrivia, etc) and responsibility for the team’s performance when it comes to shipping. In this case, you’re being asked to understand their day to day performance well enough to evaluate their performance and drive improvement, in spite of the fact that what they do is utterly opaque to you. It’s like being asked to simultaneously coach a team and referee the game for a sport whose rules you don’t know. As I said, a tall order.

I’ll grant that, if you’re a manager, you may have been technical at some point, perhaps even recently. Or maybe not, but you’ve been around it long enough to pick up a lot of concepts, at least in the abstract. But in neither case, if you were asked what, exactly, Alice coded up yesterday, would you be able to answer. Whether it’s due to total lack of experience, being “rusty” from not having programmed in a number of years, or simply being unable to keep up with what 8 other people are doing, their work is opaque to you.

As with coaching/refereeing the game that you don’t understand, you can pick up on their body language and gestures. If all members of the team appear disgusted with one of their mates, that one probably did something bad. You’re not totally without context clues and levers to pull, but it wouldn’t be hard at all for them to put one over on you, if they were so inclined. You’re navigating a pretty tough obstacle course.

And so it becomes pretty easy to make mistakes. It’s also pretty understandable, given the lay of the land. I’ll take you through a few of the more common ones that I tend to see, and offer some thoughts on what you can do instead.

Micromanagement

The opacity of the development team’s labor creates a situation in which it’s easy to feel as though you don’t have control.  And a perfectly natural impulse in such a situation is to overcompensate and try to exert as much control as possible.  The overwhelming majority of folks that micromanage don’t think to themselves, “I want to be an insufferable control freak,” but rather something along the lines of, “I just need to get really involved for now while we’re facing this deadline, and then I’ll back off when things settle down.”

GrabbingTheWheel

Read More

By

Killer CEO Interview Questions

I’d like to have a little fun for this Friday post.  I’m sitting on a plane, where I paid for wifi to take care of a few late in the day items.  Those took less time than I was expecting, so instead of the cross-post I was planning, I’m going to do this post.

Someone on twitter linked to this article, and Rands had previously linked to it, so I thought it must be worth a read.  It’s titled, “We got 10 CEOs to tell us their one killer interview question for new hires,” so I immediately thought, “Rands… why?!”  Off the cuff, it seemed like a standard Buzzfeed piece, filled with typical interview mythology where we’re asked to assume that something is profound because Warren Buffet asked it, or something.

As I read through it, though, something struck me.  Most articles like this are written by corporate pragmatists, for corporate pragmatists.  As such, they are ispo facto not interesting from a realpolitik perspective.  They are, to draw on Gervais Principle lexicon, gametalk.  “‘What’s your greatest weakness,’ should be answered with, ‘well, try to find a way to describe a strength as if it were a weakness!'”  Thanks for that insight, Dale Carnegie!

But as I read the article, it dawned on me that there were potentially non-zero stakes, and that these were actually questions that opportunists might gamely pose to other opportunists.  In other words, this isn’t “CEO says that these are questions grunts should be prepared to answer when asked by grunt-managers.”  Instead, it’s, “this is something I would ask a C-level person because I would find the answer interesting.”  (And finding the answer interesting might be entirely orthogonal to a hiring decision).

FriendlyBoss

So here are the questions, along with what I’d posit as the right answer from any self-respecting opportunist (answers in normal print, commentary in italics).

Read More

By

We’re Not Beasts, So Let’s Not Act Like It

If I were in the kind of blogger that sought readers via click gimmicks, I might title this post, “In Business, You’re Either a Partner or an Asset.”  Actually, on reading that, it still wouldn’t exactly be juicy click bait, but it’d at least be less nuanced and more provocative than my actual point here.  Maybe.

On Cats and Humans

Rather than get to the point, I’ll lead with a parable of sorts.  Let’s say that I were an aspiring entrepreneur in the death market, and that I were interested in “niche-ing down.”  I wanted to start an extermination business, and, specifically, a mouse extermination business.  You’ve got mice?  Call Erik — the mouse-killer.

Toward this end, I establish two distinct service products.  The first is that I’ll dispatch a mouse-removal expert to your house to take a more-or-less scientific approach to mouse removal.  This person will wander around your house, doing whatever it is that exterminators normally do, dispatching poison and such.  This will cost you $100 per hour.  The second service product is that I’ll rent you a cat for $15 per day.  The cat will wander around your house, doing whatever it is that cats normally do, which presumably includes chasing and sometimes killing mice.

The difference in price is significant, but it also makes sense.  The exterminator, while onsite, will focus in laser fashion on your mouse problem.  He’s basically a consultant, dedicated to helping you with your mouse problem.  His time is valuable.

The cat, on the other hand, will do whatever it wants.  It will arrive onsite and most likely take a nap.  It will then wake up, meow for food, wander around the house, purr and put its anus near your face, spend a weird amount of time sniffing a couch cushion, and then, maybe, take an interest in the scrabbling sound in your wall that represents the mouse problem.  Or, maybe it won’t.  Maybe you’ll just have to wait until tomorrow or the next day.  Eventually, the cat will be sufficiently interested to do something about the mice, but that’s clearly going to proceed according to the cat’s calendar and not yours.

CattButt

Read More

By

The Architect Title Over-Specialization

Sometimes in the month or so after New Years, things pop into my head as “micro-resolutions.” Basically, it’s stuff that I ought to start doing that doesn’t rise to the level of importance of altering my life. One such thing is balancing the sorts of posts that I make here. I want to start getting a little more even between how-to/coding, “life of a programmer” posts, and answering reader questions. Toward that end, here’s a reader question.

You’ve mentioned the fact that you don’t like the title “architect”. I agree with you because architect has different meanings for different organizations.

I have [seen] that it can involve writing code, designing UML diagrams or just write Word documents.

Don’t you think that a developer should be [a] programmer who is also an architect and a problem solver?

In my career, I’ve held all of these job titles, so it is with some degree of admitted hypocrisy that I offer my honest opinion.  This is certainly a subject that I’ve covered in the past, and covered from a variety of angles.  It’s no secret that I don’t put a lot of stock into job titles in general.  But I don’t know that I’ve ever, specifically, held forth on the difference between architects and developers, either in terms of what I perceive it to be or what I think that it should be.  The question here, as I read it a little between the lines, might be rephrased as, “shouldn’t every developer wear the architect hat” or, perhaps, “shouldn’t architecture be any developer’s responsibility?”

Simply put, my answer to that is, “yes.”

Yes, every developer should be a programmer should be an architect and problem solver.  Yes, every developer should wear the architect hat.  Yes, all developers should take responsibility for ‘architecture.’  Now, with that out of the way, I’d like to dissect the architect-programmer distinction a bit.  And in this dissection, I think we’ll get to why there’s so much of the fuzziness alluded to in the reader question around what the term actual means.

Consider programmer/software engineer versus architect as a study in contrasts (I used this post by Simon Brown as a research point for what people perceive to be the differences between architects and developers).

  • Focus scope: programmers focus on details while architects focus on “the big picture.”
  • Leadership: programmers are led and architects lead.
  • Seniority: architects have been doing it longer than programmers.
  • Cachet: architects are important visionaries while programmers do relative grunt work.
  • Tech Selection: architects choose while programmers live with the choices.
  • Skill: architects are more technically skilled than programmers.
  • Code: architects write less code on average than developers.
  • Organizational interaction: architects deal more with “the business” in meetings than programmers.
  • Pay: architects make more than programmers.
  • Value (status): see the last bullet and understand that an architect is more valuable than a programmer.

This is how the industry at large perceives this distinction.  Architects are more tenured, important, valuable technical people that are in high demand, but often too important to do the thing that earned them their stripes (writing code).  It’s confusing and even contradictory, and this intrinsic role-fuzziness is what leads to the lack of standard across the board.  It’s why architects in some organization churn out UML diagrams while architects in others are indistinguishable from software developers except by job title.

AwardsPodium

Read More

By

A Players Don’t Hire A Players — They Partner with A Players

There have been a few strands of thought dangling lazily in my mind for a while now.  Over the last year or two, they’ve threatened, on occasion, to become blog posts, but it never quite worked out.  But today enough of them came together to make the resultant rant semi-coherent, as opposed to incoherent.  So, as they say, there’s no time like the present.

Tonight, someone on social media linked to this post about hiring.  It started off by saying that a record is being set for the increase in hiring software developer in the coming six months.  It then went on to describe variance in the assembly line hiring processes of tech titans such as Google, Facebook, Microsoft, and, quizzically, Yahoo, among others.  I was hard pressed to divine a thesis from the piece, but it talked about the hoops through which one must jump to work for these places, how long the interview process takes, and how people feel about the interview process.  If I had to summarize the byline, it’d be, “tech companies, more desperate than ever to hire, still pretending to be in a position of strength.”  Let’s put a pin in that, though.

Last night, someone on social media linked to something that led me to this bit of corporate boilerplate masquerading as an enthusiastic blog post on medium.  If I had to give this one a byline, it’d be, “we’re like totally awesome and we like, love people that are, like totally awesome, and like 10x productivity and like Steve Jobs, and like awesomely awesome awesomeness!”  I mean, for God’s sake, it says “great over good” in the first 25 words, as if it were penned by Bill Lumbergh himself.  “Umm. yeah… one of our corporate values is greatness… so, if you could just go ahead and come in on Sunday, that’d be greeeeeaaaaat.”

Lumbergh

“A Players” and Who They Hire

It then goes on to reference the 10x developer canard and says that to be an order of magnitude more productive than others requires having standards, being curious, and realizing that anything is possible with the introduction of caveats.  (As an aside, the first two things merit an eye-roll, but the last one is pretty insightful, in my opinion).  It’s a standard snoozefest from some mediocre company’s “careers” page, lacking only the highly ethnically diverse stock photos.  And then, there’s the Steve Jobs quote.

Read More