Stories about Software


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.


Promote Yourself to Manager so that You Can Keep Writing Code

A while back, I announced some changes to DaedTech with idea of moving toward a passive income model. In the time between then and now, I’ve spent a good bit of time learning about techniques for earning passive income, and I’ve learned that I’m really, really bad at it. For example, I’m often asked for recommendations, and I respond by supplying them, as most decent humans would. This is wrong. What I should do is have a page on my site with all of my recommended and favorite tools and the page should link to them via affiliate links. I provide the same recommendations and earn a bit of money. Win-win.

Well, I’ve been halfheartedly working on this page for a bit. Believe it or not, the most difficult part of this is seeking out and obtaining the affiliate links. So, my page of recommendations remains a work in progress. And I was making progress tonight, securing affiliate links, when inspiration struck for a blog post about one particular affiliate. Most of the affiliates that I’ve identified are productivity tools, editors, and other techie goodies, but this one is different. This one represents an entirely different way of thinking for techies.

As a free agent, content creator, and product creator, I have a lot of metaphorical juggling balls in the air, and I’ve had to become hyper-productive and downright ruthless when it comes eliminating unnecessary activities. I don’t watch TV, I don’t go out much, I don’t take any days off of working, even on vacation, and I don’t really even follow the news anymore. Pretty much every conceivable bit of waste has been excised from my life, and I do a lot of work on an hourly or value basis. This has resulted in a whole new world of ROI calculations appearing before me — it’s worth paying premiums to save myself time so that I can spend that time earning more money than I spend.


Read More


Let’s Put Some Dignity Back into Job Seeking

Alphabet Soup

I’ve seen a lot of resumes of late, so I can’t be sure where I saw this, exactly. I suppose it doesn’t really matter. This one resume really stood out to me, though, because it was perhaps the most self-aware talisman of the ceaseless employment quest that I’d ever seen. Specifically, one part of it was the self-aware part, and that came right at the end, under the simple heading “technologies.”

If you opened the PDF file of the resume, scanned down past heading info, work experience, and education, there was this bolded heading of “technologies,” followed immediately by a colon and then a comma-delimited list of stuff. It had programming languages, frameworks, design patterns, concepts, and acronyms. Oh, there were acronyms as far as the eye could see, I tell ya – the streets were paved with ‘em. (Well, they filled out the rest of the page, anyway).

It practically screamed, “this seems stupid, but someone told me to do this, so here-ya-go.” I’ve seen this before (and even done a version of it myself), but it was always organized somehow into categories or something to make it seem like manicured, useful information. This resume abandoned even that thin pretense.

Obviously, I didn’t look through this section in any great detail. I think neither I nor the resume’s owner would have considered it important to evaluate why he’d hastily typed “UML” in between some of those other things. It didn’t matter to either of us what was in that section, and, truth be told, I’d be surprised if he even knew everything that was in there.

I contemplated this idly for a bit, and then it occurred to me how similar this felt to the obligatory job description where a company lists 25 technologies under “requirements” and then another 15 under “nice to have.” UML is probably nice for everyone to have. Both job seeker and company probably list it and neither one probably knows it, making all parties better off even with a bit of mutual fibbing.

Applicants list things they don’t know because companies claim needs that they don’t have, and, in the end, the only one who profits from this artificially large surface area is the recruitment industry as a whole. The more turnover and churn, the more placements and paydays. The way the whole thing works is actually pretty reminiscent of a low quality dating website. Everyone on it lists every one of their virtues in excruciating detail, omits every one of their weaknesses, and exudes ludicrous pickiness in what they seek. Matches are only made when lies are told, and disappointment is inevitable. When people inevitably get tired of failure and settle for a mate, it’s random rather than directed.


Gah.  How depressing.  Let’s not do that anymore.  Let’s look for mutual fit instead of blind prospect maximizing on both sides.  We don’t want hundreds of potential employers or candidates.  We want a single one that’s well suited.

Read More


Office Politics 101 for Recovering Idealists

In writing my book, I find that I wind up with these thoughts, paragraphs and mini-essays that may or may not find their way into the book. I’m adding to Leanpub sequentially, but writing relevant things as they occur to me, so there are bits floating around, waiting to have a home. I’m going to appropriate one of those bits today, as a blog post, since this is on the fringe of “maybe it will fit, maybe not.”

You almost certainly play the game of office politics, whether you do so deliberately or not. If there are more than two people involved in something, there are politics, so if you work for a company or project of more than two people, you’re involved. Saying, “I stay out of office politics and just work,” is like saying, “I don’t vote or follow elections, so I’m not really involved in laws and policies.” You can certainly opt out of participation in the process, but you can’t opt out of the consequences of that process.

Becoming good at office politics is a messy endeavor, involving a lot of intuition, trial and error, and real life, career consequences. It’s also unpleasant for a lot of people. But if you take away one piece of advice on how to navigate the minefield, let it be this: stop giving away information for free because information is leverage. Read More


It’s a Large Batch Life for Us

It’s a large batch life for us!
‘stead of feedback we just wait!
‘stead of options we trust fate!

— Little Orphan Annie…sort of.

Before I talk about “large batch life,” I’d like to take a moment to share with you a bemused chuckle at really poorly done verbal tribalism.  Rather than try to explain in the general sense, I’ll offer an example: an out of touch father trying to determine if his kids are doing drugs by saying, “so, dudes, are any of your friend-bros on the pot?”  He’s attempting (and failing) to crack their linguistic code to gain credibility. The kids, presumably, have a tribe with its own invisible speakeasy, and Dad is trying to get in.

There are tons of tribes, and you’re a member of many.  When you say, “pull request,” in casual conversation, you’re indicating that you’re part of the tribe that puts open source code on Github.  When you tell people to “put it on my calendar,” you’re indicating that you’re part of office culture. There’s nothing particularly notable or bemusing about that — it’s simply the mechanics of human communication.  Where things start to get awkward is when Dad enters the mix in the form of a recruiter or hard-charging project manager and wants to establish cred in that world without really having any: “Hey dudebros, can I pull request a phone interview with you?”


Read More


My Candidate Description

If you’re a regular reader of this blog, I’m treating you to a strange post. Consider this experimental art of a fashion, I suppose. Odd as it sounds, this isn’t addressed to you, though I encourage you to read it, hope that you enjoy it, and suggest that you consider doing a version of it yourself. You’ll see why shortly.

If you’re a recruiter, you’re reading this because I sent you this link in response to an email, a message through social media, a message through SO Careers, or something else similar. Let me first say that I thank you for coming here and taking the time to read this. I mean this sincerely; as a blogger who pays attention to various forms of analytics, I’m aware of how many people drop off from a call to action, so I’ve already lost a good chunk of people to whom this is sent. The fact that you’re here and reading means that you aren’t dialing for dollars in volume the way so many of your colleagues with an “URGENT REQUIREMENT FOR A JAVA DEVELOPER IN TEST” seem to do.

Now, I realize that what I’m doing here may come off as a bit flippant or cocky, but I assure you earnestly that this is NOT my intention. As you are no doubt aware, I receive a nearly endless stream of contacts from people looking for software developers, software architects, dev managers, etc. This post, for me, is mainly about time savings. But it’s also a polite but insistent suggestion that we stop playing by old rules that no longer make sense. Gone are the days of a company putting out a job description and waiting for the “lucky” applicants to prove that they’re good enough. You know it, and I know you know it because I’ve spent a lot of time in your situation over the last few years, desperately trying to hire developers in an economy that saw all promising candidates disappear in the two days between a phone screen and a “let’s bring them in for a chat.” It’s harder for companies to find developers than vice-versa, no matter how many free cans of soda and ping pong tables your clients or you are offering.

So what I’m posting here is my candidate description that will serve as pre-screening for inquiries about my availability for work. Assuming your company or the company on whose behalf you are searching seems like a good match for my description and meets the must-have requirements, I may be amenable to further discussion over the phone. I say may because I’m quite happy with my current work situation and have almost more contract work than I can handle, so I simply don’t have much spare time.

Candidate Description

I am an experienced programmer, software architect, team leader, CIO, coach, and technologist that enjoys working with a wide variety of programming languages, frameworks, and tools. The majority of my recent development experience has focused on the .NET framework, though over the years I have worked with C++, Java, and a number of other languages. Projects range from low-level driver and kernel module programming all the way up to user interface design. Types of applications run the gamut from home automation to rigorous code analysis to line of business applications. My more recent work focuses more heavily on software craftsmanship coaching aimed at developers and IT management consulting aimed at IT managers and other positions at the periphery of software teams.

My passion for working with technology extends beyond the workplace and into my work under the umbrella of my LLC. I do various types of traditional consulting projects, but I also produce software-related content for public consumption. I create developer training videos for Pluralsight aimed at intermediate to advanced programmers. Beyond that, I am also an author and active technical blogger.

Must-Have Requirements for a Candidate Company

  • Must be open to B2B contract work (unless you’re looking for a dev manager or CTO, in which case, I’d prefer a conversation first about why you’re staffing that role and potential alternate solutions)
  • Must be open to considering initial arrangements of less than 40 hours per week.
  • Must actively practice or encourage clean coding practices (CI, TDD, SOLID, continuous refactoring, etc.) or else want to bring me in with a mandate to get your team doing these things.
  • Remote work arrangement possibilities are a non-negotiable necessity for development work, though occasional travel for site visits is fine (for programming, a bit more flexible for coaching).
  • I will not consider W2, exempt arrangement for software development.  Not even for a number that you think will make me swoon as if I’ve been told I’m the prettiest belle at the ball.  Contracting a must.
  • Provided I give reasonable notice, time off or with other clients must not be an issue for you.
  • Position must allow creative control of software work product.
  • For interviews, no brain-teaser-oriented interviews or algorithm-centric interviews (see “The Riddler” and the “Knuth Fanatic” from this excellent video about interviewing anti-patterns).  I strongly prefer code reviews and evaluation of my public code samples and am just not interested in discussing why manhole covers are round or in reliving college coursework from 15 years ago.
  • Regardless of language and framework, access to the latest bits is critical for me.
  • If you’re McDonald’s and you’re hiring me to build you a recipe database, I will sign an NDA agreeing not to distribute your recipe to your competitors.  Anything more strict and/or that restricts my ability to do freelance projects in any way at all is an immediate deal breaker.


  • I enjoy working on .NET technologies and in the connected (mobile or web) spaces.  I’ll happily code away in any language, but C#/.NET is my favorite these days.
  • No expense is spared on software development tools, and I can have my favorite text editors, productivity add-ins, etc.
  • I have the opportunity to contribute to company blog or public thought leadership in general.
  • I’d love working for a developer tools company or one that specializes in software development and surrounding expertise. If there’s developer evangelism in-role, even better.

Thanks Again

If you’re still reading, thanks again for taking the time and paying attention all the way through.  I know this seems strange, but I appreciate you humoring me, and I believe that this will save a lot of time in the long run for me and for you.  As I often tell people that I’m coaching, “it’s almost always better to fail fast and obviously,” so better you shake your head and move on to the next candidate rather than have you, me, and a phone screener all waste time only to have it come out after an hour of conversation that I’m not interested in signing an NDA and starting a W2 gig.

Readers, to address you once again, I suggest you do something like this as well.  Don’t settle; the market is too good.  And don’t let people on the hiring side convince you that you should be lucky to have a job.  I’ve tried hiring people who do what you do, offering generous salaries and a score of 10 or 11 on the Joel Test, and it was really, really hard.  Don’t settle for the first thing that comes along. Make your list, be patient, and be picky.  It will pay off.


Don’t Learn to Code — Learn to Automate

Does anyone remember a few years ago, when the mayor of New York decided to learn to program? It was a heady time, because it wasn’t just him. I remember these surreal commercials where Miami Heat forward Chris Bosh was encouraging children to learn to code for the good of humanity or something. There was this sudden, overwhelming sentiment that humanity should abandon the folly of any non-programming pursuit and learn them some Ruby or whatever. Andy Warhol, were he alive in 2012, no doubt would have said, “in the future, everyone will write code for 15 minutes.”

Jeff Atwood wrote an interesting rebuttal to this zeitgeist, entitled, “Please Don’t Learn to Code.” The covers a good bit of ground and makes some interesting points, but the overarching thesis seems to be, “avoid thinking of writing code as the goal and learn to solve problems.” I think this is an excellent, philosophical point, but I’d like to add a bit of nuance.

I’ve written in the past about how important I think that it is to be a problem solver, to the point where I wrote a post about liking the title “problem solver.” So please don’t think I disagree with his take that a lot of programmers get too hung up with the particulars of code. I don’t — I think that’s a very common issue. But, at the same time, I think the mayor of New York and Chris Bosh and others have a point that Jeff doesn’t really address, per se. Specifically, the world is getting dramatically more technical, which means that a lot of pursuits are being automated out of existence, while other pursuits require an increasing degree of technical savvy. My fiancee, a professional copy editor, is finding aspects of her job to be easier if she knows a bit of HTML and CSS.

So while I wince alongside Jeff at the thought of people randomly learning programming languages because they think it’ll make them rich or because they want to be a person that writes lots of code, I don’t think we can simply say, “stay out unless you’re serious and willing to spend years getting good.” The rapidly evolving technical landscape has created this black hole of technical savvy that’s sucking in even people well past the event horizon.

The advice that I’d offer on this subject creates a pretty fine distinction. I don’t think that everyone needs to learn to code by any stretch. What I think that everyone needs to start learning about and understanding is how to automate. Or, if not how to do it themselves, at least how to recognize things that could be automated and have meaningful discussions about whether the effort is worth it or not. Read More


Career Advancement for the Low Price of Your Soul

When I was a kid, I remember my little brother watching Disney films pretty much constantly from the ages of probably 1 to 6 or so. As a result, I have an embarrassingly encyclopedic memory of the plots and songs of the movies from that specific time window. Probably at the epicenter of this Disney knowledge for me was the film, “The Little Mermaid” and I can remember that crazed chef chasing Sebastian the crab around and still giggle to this day. But of all of the songs in that movie, there’s only one that makes me think of the corporate world. I’ll come back to that.

Claw Back, Disney Style

There are a few standard perks in corporate America (and, I’m sure the world, though I’m only familiar with hiring in the USA). Health insurance is pretty much table stakes for serious employment these days, and with a decent employer contribution to boot. Paid time off is certainly up there, along with holidays and general human decency, one would hope.  There’s another tier that includes 401K contributions or some other retirement provision, perhaps a pension of some kind, things like life and disability insurance, and so on.  And, then, you start getting into a land more exotic where employers offer weird, unexpected stuff like “take your dog to work day” or sabbaticals or something.  One that usually shows up in this slightly more exotic realm is some concept of tuition reimbursement for employees that seek degrees or want to acquire skills through classes, certifications, etc.

This perk is a classic win-win situation.  The company invests in the career development of an employee and, in exchange, reaps the benefit of the employee’s learning and added skills.  The employee becomes more valuable to the organization by virtue of new knowledge and skills and, all other things being equal, will wind up earning more money over the course of a career.  What could be better than this arrangement?  Employees donate their spare time to improving themselves for their companies and companies donate money to the cause.  Sounds like a pretty good exchange of consideration.

And the company, really, just wants to help.  Advancing one’s skill set and education isn’t cheap, and there are so, so many poor unfortunates that just can’t afford it.  You know what?  I’ll let Ursula from the aforementioned Little Mermaid explain.

Poor unfortunate souls,
In pain, in need!
This one longing for more skills
That one wants a new degree
And do I help them?
Yes, indeed!


Read More

Acknowledgements | Contact | About | Social Media