Stories about Software


Avoiding the Dreaded Experience Tuples

I went to monster.com today and discovered that it still exists.  I’m actually kind of chuckling as I type this, and for that I apologize.  I realize that I’m in a pretty fortunate position not to have to be looking for work in such a way, so I’m not trying to make light of anyone’s situation.  But, in all seriousness, if you’re a non-entry level developer and you’re perusing monster, you have much better options (and if you honestly think you don’t, drop me an email, and I’ll see what I can do to help you find work).

Anyway, I wasn’t looking at monster in the hopes of landing a Junior Full Stack Ninja role, but because of a reader question.  Here’s the question.

How do you successfully compete against experience while interviewing? Do you leverage education? Open Source involvement? What should I fall back on?

I recently tried to make the argument that experience may not be a good thing and rather an open mind is better since experience tends to bring along bad habits that are not correctable where an open mind is willing to adapt to the corporate policies/procedures that a company has. Needless to say, I wasn’t very successful and honestly it probably came off like I was being a smart ass. I just can’t stand people wanting 3-5 years of experience. Like 2.5 is not good enough, it really needs to be 3? If 2.5 is fine, why not 2? Why is that .5 so much greater than just 2? It seriously feels like I am 6 again telling everyone that I am 6 and 4 months old, not 6. I am so much older than 6…

(By the way, you can submit questions on the sidebar at the right, under “Ask Erik,” if you want to get my take on something — and please do!)

First of all, I love the way this is phrased.  It’s poignant as it makes the frustration palpable, and it aptly exposes the absurdity of this candidate-employer matching approach.  But beyond just liking the way this conundrum is described, I think it raises an important topic.

The reason this question prompted me to head over to monster.com is because I formed a hypothesis.  I hypothesized that if I went to a generic job site and did a search for a programmer gig, the very first one I found would consist of boilerplate (years, tech) tuples.  I’ll call these “experience tuples.”  Monster has top mindshare in my head under “generic job site,” so I cross my fingers that it still existed, typed in the URL, and was pleasantly surprised.  I then typed, “C# Software Engineer” and clicked on the very first link.  Here’s what I saw.

Read More


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