DaedTech

Stories about Software

Jun
21

By

It’s a Large Batch Life for Us

Category: The Life of a Programmer Tags: , | 6 Comments

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

RetirementAnnie

Read More

Jun
16

By

Delegating is Not Just for Managers

Category: The Life of a Programmer Tags: , |

I remember most the tiredness that would come and stick around through the next day. After late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle. After late nights of futility, it was a taunting adversary that wouldn’t go away. But whatever came, there was always tiredness.

I have a personality quirk that probably explains whatever success I’ve enjoyed as well as my frequent tiredness. I am a relentless DIY-er and inveterate tinkerer. In my life I’ve figured out and become serviceable at things ranging from home improvement to cooking to technology. This relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career. On a long timeline, I’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.

Delegating

And so, throughout my career, I’ve labored on things long after I should have gone to bed. I’ve gotten 3 hours of sleep because I refused to go to bed before hacking some Linux driver to work with a wireless networking USB dongle that I had. I’ve stayed up late doing passion projects, tracking down bugs, and everything in between. And wheels, oh, how I’ve re-invented them. It’s not so much that I suffered from “Not Invented Here” syndrome, but that I wanted the practice, satisfaction, and knowledge that accompanied doing it myself. I did these things for the same reason that I learned to cook or fix things around the house: I could pay someone else, but why do that when I’m sure I could figure it out myself?

Read More

Jun
14

By

My Candidate Description

Category: The Life of a Programmer Tags: | 7 Comments

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.

Nice-to-Haves

  • 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.

May
21

By

Are Your Meetings Worth Attending?

Category: The Life of a Programmer Tags: |

“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.

May
15

By

Appeasers, Crusaders, and Why Meetings Usually Suck

Category: The Life of a Programmer Tags: , | 7 Comments

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

« Older Posts
Newer Posts »