This post is from my new digs at The Runtime, cross-posted here for your edification. I’ll continue here for the foreseeable future, so no need to jigger your subscription if you don’t want to.

I thought I’d take a shot at introducing myself here as suggested by Jay and maybe dispel any pretense at being a thinker, heady or no. Frankly, it’s probably long past time that I put together some kind of background post about myself if only to give those who disagree with me a way to discount my arguments out of hand.

I suspect this’ll be long as I do go on sometimes. You can skip to a recent, similar post if you only want the heart of my current situation.

Street Cred

I’ve been playing with computers in one way or another since my fifth grade class acquired a then-new PET computer (I recognize the CBM Model 4032 from that link as the one we had). I think it had 8k RAM and we saved and loaded our programs using cassette tapes. I bought my own used Atari 800XL from hard-earned savings as a young teen and have owned a personal computer of some sort continually ever since (frankly, the Atari made it all the way to my Sophomore year of college when PC-envy finally became overwhelming).

It didn’t occur to me to take computers seriously as a career until after I graduated college, though. That’s right, I went through college working in the computer center and making money on the side setting up personal computers and local networks for small-companies and individuals without realizing that I could actually major in them. The one intro to programming class I took (which I remember was Pascal-based) was so easy (if only from familiarity and years of being a computer geek) that I treated it as a study hall.

After graduation, I discovered that my computer skills were worth more on the market than anything I’d actually studied so that’s what I did. This was the mid 1990s so mildly talented lighting fixtures could find programming jobs. Kind of like the mid 2000s, really.

Jacking a Career

I started my actual, salaried career working for a couple of vertical market software vendors who dominated their respective niches by using Pick (which had it all over those stuffy relational databases for the ability to map real-world information). It was with Pick Basic that I discovered the true meaning of Spaghetti Code. With great power comes great responsibility and with great responsibility comes the opportunity to make very large mistakes (none of them mine, of course).

Which means that Visual Basic 6 was an upgrade in sophistication for me. Fortunately, I learn fast—my single greatest career asset. When Visual Studio and the .Net framework came around, I was all over that in turn.

I started my own company with a very talented developer and friend in early 2000 serving the Multi-level Marketing vertical market providing independent compensation programming. If you’ve ever been in one of those presentations where they describe how you can earn money from the sales of people you recruit and they mention "levels" or "generations" you’ve pretty much seen the the design documents I was given. Ever wonder how those were programmed? I did, too. I’ll just say here that walking a tree with money on the line is an addictive form of adrenaline.

It’s a small and competitive niche, though, so it was only really viable while the market was booming. Also, it turns out that I had a lot to learn about marketing and sales.

Developer In Da House

Since then, I’ve been an in-house developer and/or development manager for various small to medium-sized companies. I’ve learned enough about how businesses operate to be a good interface to upper management (I can speak all the relevant dialects including accounting, sales, management, and operations) and I work in the trenches enough to not have completely lost the respect of actual developers.

My current position is with a small reading-glasses wholesaler where I am the development department. We’re relatively top-heavy in the IT department than you would think we need, but that’s because the company’s value-add in the marketplace is our ability to orchestrate complex vendor interactions (with up to 120 day lead-times) to provide a flexible product-line at a high-enough volume to satisfy our retailers.

I also contribute to a couple of open source and volunteer projects, the most notable being Subtext. I feel guilty about bringing that one up, though, because it’s been months since I’ve done anything helpful there.

My Hood

Since my in-house projects are small and self-contained, I tend not to use many formal development processes. My users are all within fifty feet of me and I’ve trained them not to hesitate in letting me know when something goes wrong or when they think of a better way to do something. If you’re doing things right in the first place, this isn’t really as disruptive as you’d think. My longest project in the last two years has taken less than a month to go from the start of development to deployment. Some of that is because I am just that good, but a lot of it is that we’re not doing anything that complex. It’s a sweet-spot, I admit.

All of which makes any formal development process so much overkill.

Flashing it Hardcore

I’ve been around long enough to have seen silver bullets come and go. It has gotten to the point where the only dogma that I’ll tolerate is anti-dogma. I am a Microsoft fanboi, but that doesn’t mean I don’t explore other technologies and ideas. I’m not into didacticism of any flavor.

I do have a core set of practices that I tend to use. They each have two criteria:

• I understand how they work.
• I’ve used them and verified that they work as expected.

There’s nothing like real-life to expose flawed base assumptions or principles.

As you can see, this tends to make me a process skeptic. I love iterative development because I’ve used it and seen that it works. I like Agile as an idea and implementation of iterative development, but I’ve never actually seen it in action so I try to keep my discussions of it on a theoretical level.

I’ve been known to create and maintain the occasional unit test, but I’ve found that even that can be overkill on many of my projects. Test Driven Development is interesting and all but I can’t really see myself using it. It’d be a pain to retrain my way of thinking and I’m not convinced that the payoff is there (and yeah, I’ve heard the testimonials). I’m not going to move to an experiment until I understand how the payoff is supposed to come. And with TDD, I just don’t see it.

This attitude is what keeps getting me in trouble with the Dependency Injection crowd. I’ve worked out a specific, relatively narrow set of circumstances where it can be useful, but as I found out when I actually tried to implement it, those circumstances turn out to be extremely rare in an already well-architected solution.

Busting Out

Skepticism aside, software development fascinates me and I truly cannot leave new stuff alone. I echoed a sentiment by Jay Kimble recently that says essentially that claims of universal applicability are always wrong. But there’s a flip side I want to acknowledge as well: every process, tool, or technology is useful somewhere.

What that means for me is that every popular tool or technique deserves a fair hearing and an attempt at understanding to see if there is something there that I can use. Rejecting something new merely because it is popular is no better than adopting it for the same reason. I admit that this is a weird blend of skepticism and optimism. That said it turns out that, while uncomfortable, it’s really useful for growth as a developer and maintaining the ability to jump into new situations and still find yourself in familiar territory.

Software development is fun and I can’t seem to be able to leave it alone. Fortunately, it’s a useful addiction—not unlike, say, air. And if you’ve stuck with me this far, you’re obviously interested in it yourself (or you’re my wife who reads every post if only because she knows I’ll eventually ask her what she thought of it). I hope you’ll stick around and join the conversation if so moved, even if only to tell me where you think that I am wrong.

I was thinking today about something I learned the hard way and how I wish someone had taught me what to look for earlier in my career. Then it occurred to me that perhaps I could perform that service for others.

He Hates Me!

Have you ever found yourself in a situation where someone important where you work doesn’t seem to like you very much? I have. In fact, at my first real programming job (programming in Pick of all things) my manager’s boss obviously had a hard time with me. I would hear from my manager that her boss was concerned that I wasn’t "cutting it" and that I should make sure I highlight my accomplishments when we interacted. And there were definitely a couple of times when he cut me pretty short shrift.

Since then, I’ve been in other situations where someone important seems to have prejudged me in some way that is, at the least, inaccurate, and at worst potentially career limiting.

That experience left me insecure enough that I went looking for a new job.  I knew I was better than the raise I wasn’t getting and programmers were very scarce then. I found a position that paid better and where I had more responsibility (though still programming in Pick). This turned out to be a good move because it let me leave on good terms with the company I was at.

Going Detective

Since there was such a pronounced disconnect between what I considered reality and the perception of others at the company, I decided to dig a little. After a couple of months, I approached some of the insiders there. I asked them what their perception of my work had been, if or when it had changed, and what they thought of me leaving as I did. This turned out to be an instructive exercise.

Long story short, it seems that my manager, the one that I thought was on my side and happy with my work, had been denigrating me in meetings with her superiors. A project couldn’t be completed in the desired timeframe, for example, not because the project was complex but because I couldn’t handle the requirements.

Here’s the Scoop

Since this happened, I’ve seen subtler indications of the same pattern. The thing I eventually came to realize is that work relationships, unlike pretty much any other, start off in the black. When someone hires you for a job, they do so with the conviction that you can do the work required. Any manager or company grand poobah that you interact with will be prejudiced in your favor initially as a result. The instinct is to validate the hire decision.

Relationships with company managers start off without all the typical prejudices we deal with in more social circles—not because managers are nicer, fairer people but because they worked those prejudices out before hiring you (or trusting others to hire you for them). Indeed, your immediate supervisor’s attitude should be the default attitude towards you for all company higher ups.

Which is why, when someone you don’t work with treats you differently than your immediate supervisor does, it should send up a major red flag. They are almost certainly getting feedback that you aren’t privy to. Finding out what that feedback is and where it is coming from could be vital to your career. Expending a little effort and/or political capital can head off major pain headed your way.

What I’m saying is that a negative attitude has to be generated. It is not innate. It comes from somewhere and had to overcome an initial positive bias in order to become strong enough for you to perceive.

Caveats and Addendum

Any one of the following could probably be its own post but here are some things to keep in mind.

• I’m not saying that you should go looking for indications that people hate you. Insecurity breeds reasons to be insecure. If the disconnect manifests, though, be aware that the fault probably isn’t in your professional conduct and no amount of "trying harder" is going to be useful.
• When you screw up (and you will screw up), expect to see that show up in the attitude of your manager and possibly in higher ups (depending on the severity and scope of your screw up). If, over time, you cannot reaffirm the good sense your manager had to hire you in the first place, it’s probably a good time to look for a new job. If, over time, you cannot regain that good attitude in higher ups, it probably means your manager isn’t communicating well. How you handle that depends on the manager. My tendency, however, is to nudge my manager to repair the damage for me because I’m in no position to do so myself. Just letting it go is a bad idea because your manager is letting bad impressions accumulate.
• When you come into a company, you enter as part of a group. There will be prejudices between groups so expect to see that manifest. Marketing managers aren’t going to like programmers. Adjust accordingly.
• Oh, and there is a very small possibility that you are simply a jerk. If every new job ends up with you experiencing prejudice, misunderstandings, and outright betrayal, you might want to take a closer look at that pattern. Close inspection will reveal that the common denominator in all those situations is you...

First post exclusively on the new, IT-focused blog. Cool.

We've had a lot of turn-over at my current place of employ lately. We've lost most of the Operations team and all of the Accounting team in the last couple of months. It's not hard to see why: those departments are caustic and frustrating. In contemplating the turn-over, I realized that I really like working in IT.

It's not just the technology. I like working with the people in IT. Sure, we have our share of jerks and anti-social Neanderthals, but even they are at least interesting.

Maybe I've been able to call the shots for too long. For the most part, I've been able to be choosy with the places I work and who I work for. That means I've been able to avoid the obviously dysfunctional organizations, or, as with my time at XanGo, I was in a position where I could keep the dysfunctional from entering the departments I worked in.

The best part of working in IT, though, is being able to issue the challenge "Show me." when someone makes some claim that I find dubious. In the end, it all comes down to something measurable. Fads, snake oil, silver bullets, and grand new things happen all the time here (as they do anywhere) but eventually every one of them hits the brutal wall of reality. The way things are in IT, reality's pushback comes sooner than later.

Developers hate it when someone changes the requirements in the middle of a development project. What few have realized yet is that they've gone and changed the requirements to be a developer right in the middle of our careers.

An Unnecessary, But Illustrative, Story

The summer of 1994 found me in Mesa, Arizona, new-minted diploma in hand, getting ready for my first real job. A couple days before I was to report for the new position, I received news that the job that I had pulled my wife and baby daughter into the gods-forsaken desert for had, well, been eliminated. Not a happy piece of news to receive. Since my parents lived there in Mesa we ended up taking refuge in the familial homestead. I love my parents, don't get me wrong, but this was not a celebrated event—by any of us.

This was apparently all the impetus that my dad needed to leave the largish firm he worked for as the main estate attorney. He asked me to help him automate the documents he used to create trusts and wills. For money. This was the start of my transition from an English B.A. to a computer programmer. Who knew you could make money with computers?!?

The Point

My dad found that having much of the drudge work in creating those documents automated allowed him to concentrate on larger aspects of estate law. He was able to grapple with the greater context and put things together in a way he hadn't been able to before. This change in focus helped both his practice and his clients because he was able to provide better service at a cheaper cost and still make more money himself.

So here's what this has to do with software development: advances in tools, design patterns, and technologies have created the same shift for software developers that my dad realized as an attorney. While the occasional Luddite might quail at the thought of leaving vi for an IDE with built-in debugger support, most developers are happy to move away from the drudge work that has preoccupied us for so long (as with any boost in efficiency the expected new leisure has yet to show up).

In fact, what we find now is that developers are expected to take on more and more responsibility. This is a good thing overall because increased responsibility == increased value (and hence, generally, salary). This can be a bad thing, however, if software developers neglect some of the new skills that we need in order to handle these responsibilities well.

This is what lies at the heart of recent calls for developers to learn "soft" skills and develop better communication. That's because, unless you work in some back-water in the benighted hinterlands, the days of the cave-troll coder are over. A developer can no longer count on being isolated from users, managers, or <shudder> marketing weasels.

What Everybody Seems to be Missing

All of this is well and good and recognized by those who are paying attention. But it's not enough.

I like to compare business software development with practicing business law because they are both logical disciplines that have to support the human decision-making processes that are inherent in running a business. There's one large difference between the two that I think is important—lawyers are taught the fundamentals of business as a part of their law degree. They don't have an MBA or anything, but they do attend classes explaining typical business structures and basic accounting principles. That's because doing so helps them both with their interface to the business and in their ability to deliver work that properly supports the companies they work for or with.

Well, software developers are increasingly in a similar relationship with the companies they work for. I'm fortunate in my English degree because I'm reasonably well set up in the whole soft/communication skills area. What I'm finding lately, though, is that the courses I took in Business, Economics and Accounting (I never did figure out what I wanted to major in) are becoming crucial to my ability to do my job as a software developer. Understanding double-book accounting and GAAP help me understand the needs of the finance guys. Understanding supply-chain and basic inventory control helps me understand the operations folks.

I'm not talking here about becoming an expert in business. What I'm saying is that developers need to take the time to make sure that they understand the reasons behind the weird and wacky things that other business units are doing (and requesting that we automate).

And it wouldn't hurt to take a formal class or two.

Too often, the software developer going over the current supply-chain configuration with an operations manager will jump to conclusions, or worse, offer "helpful" suggestions about how things can be done more logically. More often than not, we come across as isolated from the realities that the current configuration was created to overcome. Or worse, we come across as judgmental jerks.

It's a drag having to learn so much that was originally considered outside of our discipline. Unless you're a hardware or other highly-specialized developer, however, it's going to turn out to be the kind of thing that sets the competent apart from the competence-challenged.

Steve Harman had a post back at the beginning of the month about stuff you'd tell a young developer. It's a reaction to a similar piece by Jeremy Allison. It's an interesting topic, so I thought I'd waste a few pixels on it myself.

If it's not what you love, don't do it

I wouldn't generalize this to other fields, but for software development, I think this is a good thing to keep in mind. A lot has been made in the past by career counselors and other gurus about "finding your bliss" or similar nonsense. I think that's mostly a crock. You can be a good doctor, mechanic, or professor without liking what you do. Sure, those who love what they do will tend to excel at it and rise to the top of their field, but you have to ask yourself how much better off people at the top of a field are vs. those who are merely good enough.

That said, I think software development is somewhat unique as a career. Software development advances incredibly fast and keeping up with new technologies and ways of doing things takes a non-trivial amount of effort. You have to paddle hard just to stay even and that means experimenting and learning on your own. You could probably do fine if you have Arnold Schwarzenegger level drive, but short of that, loving what you do is about the only way to get you where you need to be.

Reputation is important

People who have been around the block know that the difference between developers can be extreme. Top developers are 5 to 20 times more productive than their peers. Given some of the complete incompetents I've known, I suspect that there's really no upper limit on that number.

Unfortunately, both Jeremy and Steve use this point to jump into the virtues of Open Source software. Open source contributions can enhance your reputation, but that has nothing to do with people being able to look at your code—it's more about working with other developers who can then form their own opinions of you as a developer. That's helpful, but limited.

A good reputation is someone talking about how well you did a job for them. It's your name coming up when someone asks "do you know any good developers?" A good reputation is more important than mere code sample availability and the wider your reputation can penetrate the better off you are.

How important is reputation? Let me put it this way: I haven't gotten a job from anyone who didn't know somebody I'd worked with since 1997. Your reputation and your skills are your only true security in this field.

Never stop asking why

The vast majority of people in any field are content to learn what they have to do to get the job done. Top-tier people are the ones who are asking pesky, even impertinent, questions all the time. Jeremy puts this under the heading of "Learn the architecture of the machine" but that's too limiting. Learn as much as you possibly can about why and how things come together to get the job done.

There's two parts to this, really. The first is that you don't stop just because you got something working. Find out why iterating backwards through an array fixed your bug. Look for the best event to use for control loading rather than just the first one you found that happens to work. Learning how to parse technical documents, navigate help files, and put a concise Google query together are key skills you'll need to master.

The second part of this is harder: if you don't know something people are talking about, ask. This becomes harder to do over time because you start believing your own hype. It's easy to believe that inner voice that's saying you can bluff your way through this conversation and look up anything important later. The thing is, the really bright people, the ones you most want to impress, aren't going to be fooled. I've also found that top technologists enjoy getting intelligent questions almost as much as they love answering them. Note the qualifier there and spend the mental effort to make your questions intelligent, though.

Your employer is more important than the community

This goes directly counter to both Jeremy and Steve and I'm going to tank any chance I have with digg or reddit, but it needs to be said.

Jeremy looks like he's coming from that staunch anti-corporation Slashdot tradition that talks in moral terms about the beauty of open source software and the depravity of Microsoft. Reality check: it is not a common goal of open source developers to create "the greatest, most beautiful work of art that all of you can create together." That's certainly not why I contribute to open source projects.

Open source developers are no more virtuous than corporate developers. While you may program for fun and the satisfaction of a job well done, the choice of project you work on is inherently a selfish one. Always. Whether you program for a paycheck, community recognition, or because you need working blog software that you can tweak when you want to your choice is based on internal needs, not virtues.

If they're both selfish, shouldn't I be saying that they're equally important? I don't think so and it's not just because a company will help support your family. The reason your company is more important is that your company has to compete in the market place. It has no choice. Because a company has to charge money for its products or services, the company is forced to provide things that other people want badly enough to part with their hard-earned cash. In practical terms, it means that a company has a reality check that can't be ignored because sooner or later they're going to have to go out there and prove themselves in the marketplace. While the tech bubble bursting was tremendously painful when it happened, imagine the crap pile we would have if it didn't burst. Ever.

In addition, companies force you, the developer, to do work that you don't want to do. Developers hate that, which is perfectly understandable. Being forced to work with unreasonable managers, clueless users, and hopelessly disconnected marketing weenies is a drag. If you're good, though, it's also a rich source of opportunities to tackle things that you might never have thought needed tackling. And it forces you to justify your dogma of choice to a group of supremely skeptical, self-confident people who have the welfare of their families on the line. Yeah, that's not fun, but it means that you'll have to learn to understand and articulate things you just know are true. With the added bonus that you'll find that they sometimes aren't so true after all.

Finally, be wary of advice from old timers

Not me, of course. My advice is nigh infallible. Just ask me, I'll tell you. If you go awry following my advice, it's probably because of errors in implementation.

Okay, maybe not. I've blogged about recent errors I've made, so I have to assume there will be others. Be careful about who you listen to. Be aware that everybody has their own hobby horses and pet peeves and it's a human trait to cram those prejudices into everything (particularly advice). Also be aware that internet communities trend towards consensus as much as any other human community does. Consensus is dangerous and will tend to mask assumptions and pitfalls. Develop a well-honed BS filter and use it liberally.

While you're at it, the sooner you learn to pass your own ideas and theories through a well-developed skepticism the better off you'll be.