Stories about Software


Use These 7 Tricks to Win Meetings and Get Promoted

Rest assured, there is a list of tricks that you can use in meetings later in this post.  But, before you get to the buzzfeed portion, please indulge me for a few paragraphs that will help determine whether you’re the sort of person that really wants to take this advice.

A while back, I took some material from my in-progress book and turned it into a post in which I offered a different set of names for the MacLeod hierarchy.  For the sake of expediency, here’s the pyramid I created with those terms.


In any company that scales beyond just a few people and starts to include overhead roles, it becomes nearly impossible to assess the impact of any individual on the company’s revenue (if anyone’s interested in hearing me expand on that assertion, let me know, and I’ll add a draft for that).  But we don’t let that stop us from manufacturing performance evaluations to the best of our abilities.  Interestingly enough, performance evaluations of opportunists at the very top and of line level pragmatists at the very bottom tend to be the most straightforward.

Top level opportunists (C-suite folks) are evaluated in the same way as head football coaches.  Company does well?  Accolades and bonuses.  Company does poorly?  Golden parachutes.  It’s not as though C*Os are singly responsible for all aspects of performance, but they are the one neck for shareholders or board members to choke.

Line level pragmatists are folks responsible for cranking out widgets, so they tend to be evaluated with metrics, such as “widgets per hour.”  Speciously, we assume that moar widgets == moar revenue == moar good, and thus are content to conduct evaluations of widgeteer performance with reductionist proxies.  At least, we do that for widgeteers not on the middle management (idealist) “track.”  When they get on that track, we evaluate them differently, as I’ll describe a little later. Read More


Ship Something for Yourself, Even if you Only Earn A Dollar

On the heels of the product kata post, I’m going to double down on the “ship something for money” advice.

There’s no time to lose. Valuable, profitable seconds of your life are ticking by, and you’re missing out. Surely you’re aware of the concept of compound interest? In case you’re not, suffice it to say that long-term investment depends a lot more on when you invest than how much. The same is true with you using the Internet to earn yourself some money.


Okay, at this point I probably sound a bit like a huckster. I get that. The sense of urgency might have been just a wee bit for dramatic effect, but I think the underlying message is nevertheless valid. You really ought to acquire for yourself the experience of making money via the Internet. I’m not trying to convince you to quit your job and earn your living this way, and I’m not even trying to convince you to attempt to make serious money. All I’m trying to do is encouraging you to make something.

What should you make? You could go any number of routes. You could start a blog and put advertising on it or use affiliate links. Writing a book or making videos for youtube would count. You could hook up with a content creation outfit, like Pluralsight, and do it that way. Building apps and selling them either standalone or through an app store is probably an option that appeals uniquely to software developers. Or you could always build a web-based product or start a company, if you really want to go all in.

If I’m not peddling a get rich quick scheme and I’m not even suggesting that you try to get rich, it’s certainly fair to wonder what my angle is. Why am I so eager to offer this advice? My reasoning is multi-faceted.

Opens Up New Possibilities

The most likely outcome to you starting a blog and advertising or building a little mobile app and selling it is that you’ll put in a lot of time and effort and get a little bit of profit back out. Hey, if you thought I was a huckster at first, hopefully I’m bringing it back from the ledge a little here by telling you that you’re pretty unlikely to get rich quick. The reality is that you’re almost certainly not going to retire from your first foray into entrepreneurship.

This type of bootstrapping is modest in aim and scope, for the most part. But it is an opportunity. And, it’s one with virtually no barriers to entry and not much limit to the possibilities if it takes off. Look at Life Hacker.

You probably won’t be Life Hacker, but maybe your blog/site/app/channel will become a fun hobby for you – a hobby that brings in a few hundred or maybe even a thousand dollars per month. And, over the long haul, it will also help you get your name and information out there to pry open the door to some networking and consulting opportunities as well. You’d be surprised at how many things come up when you just put yourself out there: job offers, consulting opportunities, speaking invitations, and more.

Introduces a New Earning Model

Most white collar workers spend an entire career working 40 (okay, who are we kidding, 45+) hours per week in exchanged for a fixed number of dollars. Wage labor is clearly the dominant model for income in our society, since traditional entrepreneurship tends to be a high risk venture. It’s all well and good for hungry kids just starting out on their career path, but a harder sell for folks with families and mortgages.

Building something small in your spare time with the aim of earning a little money, however, is not high risk. It’s the kind of thing you can do instead of watching a few TV shows. And, while the stakes may be small, the lessons learned aren’t. You’ll develop a sense of what it’s like to earn in a model where income is decoupled from time, which can be a valuable skill that you may use in your day job or, at some point, to start your own venture.

And There’s More

I originally wrote this post for the Infragistics blog.  Here it is on their site.  To read the second part of the post, check it out on their site here.


Using NDepend to Make You a Better Programmer

This is another post that I originally wrote for the NDepend blog. If you haven’t yet, go check out the NDepend blog and sign up for the RSS feed. It’s relatively new, but we’ll have a lot of good content there for you.

If you’re a software developer, particularly of the newly minted variety, the concept of static analysis might not seem approachable.  It sounds academic.  It sounds architect-y.  It sounds complicated.  I’ve seen this reaction from a lot of people in my career and I think that’s too bad.

If you delve into its complex depths, static analysis can be any and all of these things, but with the developers I mentor and coach, I like to introduce it as a game that makes you better at what you do.  You can use static analysis to give yourself feedback about your code that is both fast and anonymous, allowing you to improve via trial and error, rather than by soliciting feedback from people much more tenured than you and sometimes wincing as they lay into you a little.  And, perhaps best of all, you can calibrate the quality of your code with the broader development world, rather than just pleasing the guy who has hung around your company long enough to default his way into the “tech lead” role.

NDepend Rules

Take a look at some of the feedback that NDepend offers about your code.  “That method is too big” isn’t particularly intimidating, is it?  I mean, you might wonder at what you could do to compact a method, but it’s not some kind of esoteric rule written in gibberish.  You run NDepend on your code and you can see that there is some number of methods that the broader development community considers to be “too big.”

From there, you can start looking at ways to write smaller methods and to refactor some of your current ones to sneak in under the warning number.  This is the essence of gamification — you change the way you write code to get rid of the warnings.  You get better.  And it’s gratifying.

As you do this, another interesting thing starts to happen.  You start noticing that other developers continue to write large methods and when you run NDepend on their code, they light up the console with errors, whereas you do not with your code.  And so, you can have conversations with them that start with, “you know, this static analysis tool I’ve been using wants us to have smaller methods, and I’ve been working a lot on that, if you ever want a hand.”

You gain a reputation as being knowledgeable.  Before you know it, you can cite widely accepted static analysis rules and the design goals they imply.  You know these rules, and, via gamification, you have experience molding code to comply with them.  Even in cases where you might wind up overruled by the local team lead or architect, it’s no longer a simple matter of that person saying, “because I said so,” and just ending the conversation.  They have to engage with you and present cogent counter-arguments to your points.  You’re participating in important discussions in ways that you never have before.

If it sounds like I’m speaking from experience, I am.  Throughout my career, I’ve been relentless about figuring out ways to improve my craft, always trying to be a better programmer.  Early on, I was unsatisfied with a lot of arguments among developers around me that I knew boiled down to nothing more than personal preference, so I went out in search of empirical methods and broader knowledge, and that search brought me to static analysis.  I read about data and science behind particular choices in approaching software, and I schooled myself to adopt the approaches that had brought the best results.

Somewhere along that journey, I discovered NDepend and its effect on my approach to writing code was profound.  My methods shrank and became less complicated.  My architectural and design skills improved as I made it a point to avoid dependency cycles and needless coupling.  I boosted unit test coverage and learned well established language practices.  It was not long before people routinely asked me for design advice and code reviews.  And from there, it wasn’t long before I occupied actual lead and architect roles.

So, if you want to improve your craft and nudge your career along, don’t pass on static analysis, and don’t pass on NDepend.  NDepend is not just a tool for architects; it’s a tool for creating architects from the ranks of developers.  You’ll up your game, improve your craft, and even have some fun doing it.


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!”


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


Signs Craftsmanship May Be For You

One of the things I’ve spent a good bit of time doing over the last year or so is called “Craftsmanship Coaching.” This involves going into teams and helping them adopt practices that will allow them to produce software more reliably and efficiently. Examples include writing automated unit and acceptance tests, setting up continuous integration and deployment, writing cleaner, more modular code, etc. At its core though, this is really the time-honored practice of gap analysis. You go in, you see where things could be better, and you help make them better.

Using the word “craftsmanship” to describe the writing of software is powerful from a marketing perspective. Beyond just a set of practices revolving around XP and writing “good code,” it conjures up an image of people who care about the practice of writing software to the point of regarding it as an art form with its own sort of aesthetic. While run-of-the-mill 9–5ers will crank out code and say things like, “if it ain’t broke, don’t fix it,” software craft-people will presumably agonize over the smallest details, perfecting their code for the love of the game.


The drawback with using a term like “software craftsmanship” is the intense subjectivity and confusion of what exactly it entails. One person’s “well crafted code” might be another’s spaghetti, not to mention that subjective terms tend to get diluted by people wanting, merited or not, to be in the club. To understand what I mean, consider the practice of scheduling a daily status meeting, calling it “daily Scrum,” and declaring a shop to be “agile.”

How then are software developers who are not associated with the software craftsmanship movement to know whether they should want in or not? How are they even to know what it is? And if they don’t easily know, how are overhead decision makers like managers to have any clue at all? Well, let’s momentarily forget about the idea of software craftsmanship and return to the theme of gap analysis. In the rest of this post, I’ll describe signs that you could stand to benefit from some of the practices that I help clients with. If you notice your team experiencing these things, the good news is that you can definitely simplify your life if you pursue improvements.

Similar Features Take Longer and Longer to Implement

Remember a simpler time when adding a page to your site took a few hours, or maybe a day, max? Now, it’s a week or two. Of course, that makes sense because now you have to remember to implement all of the security stuff, and there’s the validation library for all of the input controls. And that’s just off the top. Let’s not forget the logging utility that requires careful edits to each method, and then there’s the checklist your team put together some time back that you have to go through before officially promoting the page. Everyone has to think about localization, checking the color scheme in every browser, and so on and so forth. So it’s inevitable that things will slow down, right?

Well, no, it’s not inevitable at all. Complexity will accrue in a project as time drifts by, but it can be neutralized with carefully considered design approaches. The examples that I mentioned, such as security and logging, can be implemented in such a way within your application that they do not add significant overhead at all to your development effort. Whatever the particulars, there are ways to structure your application so that you don’t experience significant slowdown.

Simple Functionality Requests Are Anything But Simple

  • “Hey, can you change the font on the submit button?”
  • “Not without rewriting the whole presentation layer!”
  • “I don’t understand. That doesn’t seem like it should be hard to do.”
  • “Well, look, it is, okay? Software is complicated.”

Have you ever participated in or been privy to a conversation like this? There’s something wrong here. Simple-seeming things being really hard is a smell. Cosmetic changes, turning off logging, adding a new field to a web page, and other things that strike non-technical users as simple changes should be simple, generally speaking.

While clearly not a universal rule, if a vast gulf routinely appears between what common sense says should be simple and how hard it turns out to be, there is an opportunity for improvement.

Until Next Time

I originally wrote this post for the Infragistics blog and you can find the original here. There is also a second part to this post, as well.