DaedTech

Stories about Software

By

Who Accepts Your Team’s Academy Awards?

I was listening to the Smart Passive Income podcast the other night. Yeah, I wasn’t kidding. I’m really trying to figure out how to do this stuff. Anyway, it was an episode with “User Stories” in the title, so I was intrigued. What I actually thought to myself was, “I’m a lot more inclined to hear stories about passive income than about Scrum, but this could be interesting!” And, it actually was interesting. I mean that earnestly. The episode was about Pat commissioning an IOS app for his podcast, so anyone making a living in our industry would be somewhat intrigued.

The episode started, and I listened. Admittedly, beyond Pat, I don’t exactly know who the players are, but I can tell you what I inferred as I was jogging (I frequently listen to podcasts when I jog). The interview started, and Pat was talking to someone that seemed to have a project-manager-y role. Pat asked about the app, and the guest talked about communication, interactions, and the concepts of “user story” and “product backlog.” He didn’t actually label this process Scrum until much, much later in the interview, and I get that – he’s talking to a huge audience of potential clients, so it’s a lot more compelling to describe Scrum as if it were something he thought of than it is to say, “oh yeah, we do Scrum – go google it!”

LeaderSpeaker

I don’t begrudge him that in the slightest. It’s a savvy approach. But it did strike me as interesting that this conversation about an app started with and centered around communication and planning. The technical decisions, data, and general nuts and bolts were all saved for later, delegated to a programmer underling, and framed as details that were definitely less relevant. In the development of this app, the important thing was the project manager, who he talked to, and when he talked to them. The development of the app was a distant second.

My reaction to this, as I jogged, was sad familiarity. I didn’t think, “how dare that project manager steal the show!” I thought, “oh, naturally, that’s a project manager stealing the show – that’s more or less their job. Developer code, not know talk human. Project manager harness, make use developer, real brains operation!”

Read More

By

Are Your Meetings Worth Attending?

“Remember, kids, your projects are due a week from Monday, so you’d better get started if you haven’t already.”

This imminently relatable phrase, or one like it, is probably the first exposure to nagging that most of us had outside of the home. Oh sure, Mom and Dad had nagged us for years to clean our rooms, say please and thank you, and wear jackets. But our teachers introduced us to business nagging. I’m using the term “business nagging” to characterize the general practice of nudging people to do things for common professional effort.

CodeReview

If you fast forward to your adult life, business nagging morphs into things like, “don’t forget to sign off on your hours in payroll,” and, “everyone must update their email signatures to use the company’s official font by next week.” The subject matter becomes more adult in nature, but the tone and implications do not. When you hear these phrases, you’re transported back in time to junior high, when you needed to rely on a teacher to help prevent your general incompetence at life from creating unfavorable situations for yourself.

There’s a subtle problem with business nagging growing up alongside of us. As children, we actually are pretty incompetent at looking out for own interests. Left to our own devices, we’ll procrastinate on the school project and then pull an all-nighter ahead of turning in something that earns us a C minus. But as we grow to adulthood, we learn these lessons firsthand and wind up being generally decent at looking out for ourselves. We tend not to need nagging nearly as often to do things that will benefit us, so being nagged to do things that will benefit us winds up becoming largely superfluous.

And that leaves the most common form of business nagging: being nagged to do things that offer no obvious benefit to the recipient of the nagging. Signing off on your hours in payroll doesn’t benefit you directly (except, perhaps, by removing the artificial threat not to compensate you for the work you’ve done). Changing your email signature doesn’t benefit you directly. According to someone with some degree of power somewhere in the organization, you doing these things will benefit the company. Presumably, if the company benefits, so do you, somehow. But there is as much vagueness in that equation as there are “somes” in the previous sentence. From where you’re sitting, it’s just bureaucratic procedure having only one tangible benefit—getting the administrator of the business nagging to go away and leave you alone.

This was a post I originally wrote for Infragistics. Click here to read the rest.

By

Appeasers, Crusaders, and Why Meetings Usually Suck

I think this is about to get weird, but bear with me, if you’re so inclined.  This is going to be another one of those posts in which I try to explain myself by way of a vague apology for my abnormality.  But maybe if enough of you are similarly abnormal, it’ll gain a little steam.  I’d like to talk today about my odd, intuitive approach to disagreements over the rightness of opinions or beliefs. (For epistemological purposes, consider anything that you’d think of as a “fact” to fall into the belief category.)

So, let’s say that Alice and Bob are sitting on a bench, and Alice proclaims that blue is the best color.  Bob might agree that Alice is right.  He might disagree with her on the basis that red is actually the best color, or he might disagree with her on the basis that this is a purely subjective consideration, so the idea of a “best” color is absurd.  In short, Bob thinks that Alice is wrong.

Perception of rightness affects different people differently, it appears to me.  There are a lot of people out there for whom rightness is extremely important, and the idea that someone might be wrong and not corrected offends them deeply (as shown here, ably, by xkcd).  I am not one of those people.  I might be baited into the occasional back and forth online (or in any asynchronous form) when someone directly accuses me of wrongness, but that’s pretty much it.  I almost never seek out people to correct general wrongness, and I certainly don’t do it in person — with the exception of very close friends and family, and only then in casual conversation.  By and large, other people being wrong about things doesn’t matter to me.  If I’m sitting in the bar, having a beer, and some drunk is yammering political opinions that get increasingly moronic with each boilermaker, I have an innate gift for quietly enjoying the free spectacle.

But there are situations that require cooperation, often professional ones.  Working with another person, there may be some debate or disagreement over the course of action that ought to be taken, and, in such cases, the moment happens when I’m convinced that someone is wrong, and they’re equally convinced that I’m wrong.  The first thing that I do is evaluate whether or not the wrongness negatively impacts me.  If not…meh, whatever. Read More

By

8 Career Tips That Don’t Require Competence

A few weeks ago, I posted my spin on the MacLeod Hierarchy and promised to follow up with a post addressing the kind of vacuous, non-strategic career advice that is often given in Buzzfeed sorts of formats.  I started, then, to type this post, but realized that a bridge of sorts was needed.  So I indulged a digression wherein I described the corporate idealist that typically solicits and follows this sort of advice.  (That post also became pretty popular, with a number of requests to pre-order my upcoming book, which you can now check out here on leanpub).  Now, having described the corporate idealist and his willingness to overwork in exchange for useless status tokens, I can go on to be clearer about why so much of the career advice that you tend to hear is so, well, frankly, dumb.

I started to write this just from anecdotal experience, including various comical, ham-fisted self promotion attempts that I’ve watched over the years.  But then I thought it’d make more sense to go out, do some research, and synthesize my experience with actual advice offered in these “Linkbait for Idealist” articles.  This is a list of the ones that I read as reference material.  (As an aside, I also stumbled across a few that offered fairly sensible, decent advice for how to advance meaningfully, so it is actually possible to find advice that isn’t silly)

KingOfSmallKingdom

Read More

By

Clean Communication

Do you remember your early days of software development in a team setting? If you do, and you’re anything like me, you’ll have awkward memories of trying too hard. Eager to show that you were ready for a seat at the big kids’ table, you’d dive into new assignments with the sort of over-eager attitude that made the grizzled veterans around you roll their eyes knowingly and, perhaps, smile faintly indulgent smiles.

It was time for you to shine. Adding a new radio button option to an existing series of options was the perfect chance for you to show that you knew what the Composite Pattern was. And, why use any of the collection types in the standard library when you could roll your own and use a method header comment to prove, mathematically, that it sorted itself in O(n log n)? Any unimaginative clod could write code that did what the users needed it to do, but it took a visionary, like you or me from days past, to write code that mostly did what users needed it to do while showcasing lessons from all 4 years of your undergraduate programs. Each feature that you delivered was a chance to add to your own personal portfolio at the company.

scan0002

Read More

By

The Tech Lead Role: Lessons from Ancient Rome

 

Julius Caesar, Mark Antony, and Cassius walk into a bar, and the bartender asks them what they’ll have. “3 beers!” Caesar proclaims. “2 beers,” whispers Cassius.

 

Because I’m not a historian, I have the luxury of making spurious historical arguments that suit my purpose. I can even bring in Star Wars if I want to. For those of you only passingly familiar with the story of Caesar, he was the pivotal, popular, and controversial figure around which the Roman Republic became the Roman Empire. He was also the obvious inspiration for the scene in which Chancellor Palpatine becomes Emperor Palpatine, causing Padme to remark, “so this is how liberty dies… with thunderous applause.” Caesar was a popular and extraordinary general that imposed his will on the increasingly ineffectual Roman Republic, essentially replacing it with a more unified and centralized imperial government. That is, until his friends in the bar assassinated him in the name of “liberty.”

Caligula Read More

By

Lifting the Curse of Knowledge

As most of you know, one of the biggest anti-patterns when you’re instantiating program slots is to forget to set CanRemoveOverride to true. But what you probably didn’t know was that the SlotConfig is — Just kidding. I lifted this from a post I wrote almost 3 years ago about legacy code I was working with then. I have little more idea than you do what any of that means.

Read More

By

Is This Problem Worth Solving?

I’ve done a little bit of work lately on a utility that reads from log files that are generated over the course of a month. Probably about 98% of the time, users would only be interested in this month’s file and last month’s file. How should I handle this?

At different points in my career, I’d have answered this question differently. Early on, my answer would have been to ignore the sentence about “98% of the time” and just implement a solution wherein the user had to pick which file or files he wanted. For a lot of my career, I would have written the utility to read this month and last month’s files by default and to take an optional command line parameter to specify a different file to read (“sensible defaults”). These days, my inclination is more toward just writing it to read this month’s and last month’s file, shipping it, and seeing if anyone complains — seeing if that 2% is really 2% or if, maybe, it’s actually 0%.

Part of this evolution in me was the evolution of the software industry itself. When I started out doing a lot of C and C++ in the Linux/Unix worlds, gigantic documents and users’ manuals were the norm. If you were a programmer, it was your responsibility to write massive, sprawling APIs and if you used someone’s code, it was your responsibility to use those massive APIs and read those gigantic manuals. So, who cares what percentage of time a user might do what? You just write everything that could ever possibly happen into your code and then tell everyone to go read the manual.

Then things started to get a little more “agile” and YAGNI started to prevail. On top of that, the user became more of a first class citizen, so “let’s default to the most common path” became the attractive thing to do and “RTFM” went the way of the dodo. The iconic example would be a mid 2000’s Windows or web application that would give you a sensible experience and then offer a dizzying array of features in some “Advanced Settings” window.

The next step was born with the release of the iPhone when it started to become acceptable and then normal to write dead simple things that didn’t purport to do everything. Apple’s lead here was, “this is the app, this is what it does, take it or leave it.” The “advanced settings” window was replaced by “we’ll tell you what settings you want,” which requires no window.

This shifting environment over the last 15 years informed my perspective but wasn’t entirely responsible for it. I’d say what was responsible for the shift were two realizations. First, I realized, “a ‘business spec’ isn’t nearly as important as understanding your users, their goals, and how they will use what you give them.” It became important to understand that one particular use case was so dominant that making it a pleasant experience at the cost of making another experience less pleasant was clearly worthwhile. The second realization came years later, when I learned that your users do, frequently, want you to tell them how to use your stuff.

Some of this opinion arose from spending good bits of time in a consulting capacity, where pointing out problems and offering a handful of solutions typically results in, “well, you’re the expert — which one should I do?” You hear that enough and you start saying instead, “here’s a problem I’ve noticed and here’s how I’ve had success in the past fixing this problem.” It makes sense when you think about it. Imagine having someone out to fix your HVAC system and he offers you 4 possible solutions. You might ask a bit about cost/benefit and pros/cons, but what you’ll probably wind up saying is, “so…. what would you do and/or what should I do?”

TerrifiedOfFurnace

There’s an elegance to coding up what a user will do 98% of the time and just shipping that, crude as it sounds. As I mentioned, it will confirm whether your “98%” estimate was actually accurate. But, more importantly, you’ll get a solution for 98% of the problem to market pretty quickly, letting the customer realize the overwhelming majority of ROI right away. On top of that, you’ll also not spend a bunch of money chasing the 2% case up front before knowing for sure what the impact of not having it will be. And finally, you add the possibility for a money-saving work-around. If the utility always reads this month’s and last month’s files, and we need to read one from a year ago… rather than writing a bunch of code for that… why not just rename the file from a year ago and run it? That’ll cost your client 10 seconds per occurrence (and these occurrences are rare, remember) rather than hundreds or thousands of dollars in billable work as you handle all sorts of edge cases around date/time validation, command line args, etc.

I always wince a little when I offer anecdotes of the form, “when I was younger, I had position X but I’ve come to have position Y” because it introduces a subtle fallacy of “when you get wiser like me, you’ll see that you’re wrong and I’m right.” But in this case, the point wasn’t to discredit my old ways of thinking, per se, but rather to explain how past experiences have guided the change in my approach. I’ve actually stumbled a fair bit into this, rather than arrived here with a lot of careful deliberation. You see, there were a lot of times that I completely whiffed on considering the 2% case at all and just shipped, realizing to my horror only after the fact that I’d forgotten something. Bracing for getting reamed as soon as someone figured out that I’d overlooked the 2% case, I battened down the hatches and prepared to face the fire only to face… absolutely nothing. No one noticed or cared, and the time spent on the 2% would have been a total waste.

So next time you find yourself thinking about how to handle some bizarre edge case or unlikely scenario, pull back and ask yourself whether handling that is worth delaying the normal cases or not. Ask yourself if your user can live with a gap in the edge case or work-around it. And really, ask yourself what the ROI for implementation looks like. This last exercise, more so than learning any particular framework, language or library, is what distinguishes a problem solver from a code slinger.

By

Be the We

There’s a moment at a job that you’ve probably never thought about specifically, but it’s a knee point of sorts. Think of arriving at a new gig that you take somewhere, fresh out of the interview process, pumped about the new opportunity and the 10% pay bump you’ve negotiated for yourself, and generally rarin’ to go. You’ve come out of an interview process in which you’ve presented a pretty rosy picture of yourself and so have they, so everything’s awesome.

Then you arrive for your first day with your passport to prove citizenship and your lofty expectations and, after a period of getting settled, you get down to work and see what’s going on. Maybe it’s a walk through the code base or your first standup meeting where it happens. Maybe it’s a department meeting. I don’t know. But somewhere, it happens. You see something pretty crazy that calls into question all of the awesome things you thought about your new Shangri La. Maybe the company is using Visual Source Safe for source control. Maybe “daily standup” is a manager sitting while 30 direct reports spend 2 hours furnishing status updates. If you think hard, I’m sure you can remember the first “these people are insane” moment that you had at any given company. But that’s not the moment that I’m posting about; that’s just a baseline moment to which we’ll return shortly.

That first WTF moment probably isn’t the last and, to some degree, this is inevitable since not everyone will do things in quite the same way. You respond to these early moments by asking questions of the people there: “so, what’s the backstory behind that 12,000 line singleton class” or maybe “why do you guys put up with code commits taking 3 hours?” And, what’s more, you probably make the case to remedy some of these things and, perhaps even have some success. You fight strategic battles but you don’t (and can’t) win them all, and at some point you and the company adapt to each other like an ice cube in a warm glass of water becoming coolish water. You change some things and get used to others.

And then the moment in question comes. It sneaks up on you when a new hire comes on board, looks at the code commit process you’ve trimmed from 3 hours to 2 hours and says, “what’s wrong with you guys that commits take 2 hours?” The moment happens when you say, “that’s not me, man — you should have seen what these goofballs were doing before I got here. Don’t lump me in with them.” Tell me this has never happened to you, I dare you. You wince and say, “it was like that when I got here!”

As one of my favorite movie characters (I make the distinction because I have no idea if the actual man said things like this) Doc Holliday said in Tombstone, “apparently, my hypocrisy knows no bounds.” I mention this because I’m about to advise against this in a “do as I say and not as I’ve done” sense. Over the course of my career, I’ve tended to disengage (and eventually leave) from situations that I found to be degenerate, rather than battling endlessly to correct them. This led to a tendency to keep myself at arm’s length from a group if I didn’t like things that were happening.

DocHolliday

What I’ve come to understand is that there is no “me and them” except in the realm of your (and my) hollow excuses. As soon as you sign on with that company, there’s only “we.” I’ve learned the hard way that accepting this immediately results in better outcomes in the same way as the “fail fast” mantra. The best outcome is that you get there, ask questions about “why does our build take so long and how can we fix it,” and you start chipping away, making real progress that you can take pride in. Your investment of your own reputation in the endeavor provides strong motivation. Another decent outcome is that you can’t make progress and are forced more quickly to ask yourself, “do I want to be part of a ‘we’ that operates this way — do I want my name on this?” If the answer to that is “no” and there’s no sign of improvement, it’s better to exit stage left as soon as you can than to sit around, making sure everyone knows that you don’t actually think much of your group.

Really, that’s a terrible outcome for as long as it continues. You’re unhappy and you look like an excuse-offering malcontent. Your peers resent you because they perceive (probably correctly) that you’re bashing their previous work or throwing them under the bus. It’s a bad situation all the way around, and it can be avoided, I’ve learned over time, by getting to “we” as quickly as possible.

So when transitioning to a new job, assignment, team, or whatever, start talking immediately about what “we” do. It will align you with your group, generate earlier feedback for you on whether it’s a good fit or not, and probably bias you over the long haul to evaluating mutual compatibility more carefully up front.

By

The Dominant Leader Fallacy

There’s nothing quite like the pressure of assuming organizational leadership for the first time in a professional capacity. And, seriously, I mean in a professional capacity — I’m not talking about being voted captain of the freshman basketball team or student government something. Non-professional leadership scenarios are akin to poker games played at the kids’ table for chips only in that they’re artificial scenarios designed to build character by simulating the real thing. In these scenarios, a wrong decision can cost you a soda machine in the cafeteria whereas in a professional capacity wrong decisions can alter careers and livelihoods (and, in higher pressure gigs than I’ve ever had, sometimes even human lives).

I can’t speak across the board, but I can speak to organizational leadership against the backdrop of knowledge work (and in this case, I mean official leadership, as opposed to ad-hoc or thought leadership). In this field, you often have a good bit of “paying your dues” before you’re deemed ready for leadership. Sadly, the gatekeeper factors here are often duration of tenure or having been a leader before (the entry level Catch-22 all over again, wherein you need leadership experience to be given a leadership role and a leadership role to gain leadership experience). Thus, the waiting period might be years or even decades, in some cases, so if you’re ambitious, you’re probably chomping at your bit for a long time before it comes. And then it comes…

…and you’d better not screw it up! The very people that gave you the nod have you on quite the short leash, and they’re ready to yank you off the stage with a cane should you show the slightest hint of weakness. Whatever you do, never admit to ignorance of any sort. If it’s an acronym you’ve never heard or a technology you haven’t used, grit your teeth, fake your way through it and study up until 4 in the morning so that you can stay perfect in everyone’s eyes. And don’t think that this only applies to your superiors. Those you’re leading are also waiting for any excuse to dethrone you and lay their own claim, so don’t sleep on them, either.

TimeLearning

Heh. I don’t know that I ever thought these things, consciously, but I certainly did to some degree on a subconscious level. And, while I’ve never been the sort to try to bluff at having knowledge I don’t, the part about staying up ’til 4 AM studying was (and still kind of is) definitely my style. I didn’t want to blow the whole leadership thing, so I broke my back trying to be perfect. But these days… not so much. I now break my back trying to do other things.

At some point, I figured out that trying to know more than 5 or 10 or however many people doesn’t scale very well and, even if it did, would winning knowledge trivia duels be the best use of your time as a leader? Maybe if you’re running a gang or a pack of wolves this makes sense — your cred is tied up in your ability to dominate any challengers. But I like to think that we have a bit more organizational sophistication in our approach. In knowledge worker professions, the best use of a leader’s time is removing obstacles that are stopping the team from excelling and figuring out how to create an environment that gives rise to good ideas.

If you’re a leader and you don’t know some finer point of the language that your team is using or you’re less familiar with a deployment tool than someone on your team, don’t hide that fact — embrace it! You’ve found a skill and there’s probably a need. Good leaders play match-maker in these situations. “Hey, you seem like you really know your Python and I know there’s some nasty code over in that particular module, so maybe you could get it sorted where the rest of us failed.” If you think back to the best leaders/bosses/managers/whatevers that you had in your career, did you appreciate them because they were better at everything than you were? Or did you maybe appreciate them because they got out of your way, trusted you, and guided the team toward playing to your strengths?

So if you’re new to leadership, relax and take a deep breath. You’re not playing a game of “king of the hill” and the team members aren’t adversaries looking for a crack in your armor. You’re playing a team sport and you’re more like the coach — they expect you to put them in a position to succeed rather than to push them out of the way and single-handedly win the game for them. So go in, cop to what you don’t know, and solicit volunteers for people to get the job done and maybe even teach you a thing or two along the way. Leadership is a matter of trust — not dominance.

Acknowledgements | Contact | About | Social Media