Authoring and sharing a package is a relatively simple activity these days. Systems like GitHub and npm make it easy for an author to share and publish their work. This is a great thing; it is a wonderful time to be a developer and involved in a developer community.

However, there is a cost to sharing and releasing one’s code that is often unwritten and overlooked. Authors may feel like they are sharing their grand ideas with the world, but they often fail to understand the expectations that go along with publishing a package. Likewise, users think that they can just download a package in an all-you-can-eat buffet of open source software, never realizing that the very success of the package they are downloading requires them to participate in the community of that package. Both sides have responsibilities in the situation and for either side to ignore those responsibilities is a recipe for failure.

Several months ago the JavaScript community dealt with this very problem. A highly respected package author, had shared a package (event-stream) he wrote for fun and it got very popular. As is the case, popularity came with more requests for support and bug fixes. In short order requests became demands, and the author’s time and interest lagged. All the while, very few users where willing to step up and help. So when someone did step up and help, the author accepted and turned over the repository. Shortly thereafter malicious code was introduced into the package and everyone who relied on the package became an potential victim.

In many ways event-stream was a kind of “perfect storm” event that may be unlikely to occur again. Yet, the event-stream saga is a very real example of the cost of publishing code for others to use. Some would blame the author for not providing a better notification that he was handing the package off to someone else. Others would blame the users for not supporting the package either financially or through participation. Still others would point out that this is a professional community and as a professional one is required to know and understand how their software works and the systems it relies upon work. Yet, no matter how we throw the blame around, the reality is everyone paid the price for the failure, and everyone (the author, the users, and the greater community) is culpable.

A dependency, a package, is more than software; it is a relationship. Like all relationships, it comes with a set of expectations between the parties involved: party A in a relationship expects certain things of party B, and in turn party B expects certain things of party A. When either side fails to live up to those expectations that is when the relationship degrades and fails and people get frustrated, hurt, and betrayed.

Consider what one expects when downloading a software package:

• Function: The user of a package expects that when a package is given X, it will return Y. This is the expectation by the user that a package will work and that it will meet their needs. Occasionally a package fails to work or meet the needs of the user, at which point they uninstall it and the relationship is over.
• Constraint: The user of a package expects that a package is constrained to doing only what it is intended and described to do and nothing more. That is, the user expects a package to not do other things whether malicious or not.
• Support: The user of a package expects the author of a package to provide some level of support. This includes well written documentation, responsive bug fixes, avenues of communication, and the addition of new features.
• Notification: The user of a package expects to be informed when the package changes, how it changes, and why those changes were introduced. Notification allows the author to communicate with the users directly.

But what a lot of people overlook is the other side of the relationship having its own expectations:

• Feedback: The author of a package expects that the user of a package will report issues with the package. One can never predict all of the edge cases where code may have problems. The author is dependent on the user providing the details about where those edges are and where they fail.
• Reciprocity: The author of a package expects that the user of a package will help maintain and grow the package. This is a critical part of the open source equation: that everyone shares in the maintenance and growth of the package for the betterment of all. Without this participation most packages languish and die.
• License: The author of a package expects that the user of the package will use that package in accordance with the licensing terms. The license is an expression of the legal wishes of the author, but the author lacks little ability to enforce such things. Instead, the author relies upon the relationship with the user to encourage these legal wishes.

When any one of these expectations from either side is broken the relationship is strained. Some times that strain can be minor and survivable, but often it can be completely destructive. In the case of the event-stream story from above, the users failed to fulfill the Reciprocity expectation which in turn caused a snowball effect causing other expectations to fail, which eventually led to critical failure of the entire package.

So how does one address these problems? How do the authors and users of a package prevent failures from occurring in the future? How does one ensure that the participants in our communities get what they need to not just survive but thrive as part of the community?

It begins by recognizing that there is still much work to be done on the systems in use and how the community uses those systems. Now, many of the tools at the disposal of package authors are geared toward providing and maintaining some of the expectations outlined above. GitHub, for example, can be said to be helpful in some of these expectations, but lacking (whether intentionally or not) in many of them. Certainly it enables the Support, Feedback, and Reciprocity expectations, but there is still much room for improvement.

While stronger more supportive systems and tools will help address some of the community problems, one must also be willing to examine and address the individual and community aspects as well. In many ways, the current situation in which the community finds itself is a function of getting better tools without considering the social engineering those tools also require. So any solution must also examine the people involved.

The authors need to to understand that releasing software is not a “fire and forget” situation and that the users have expectations of the package and its author. There must be a realization that by sharing code with the world, one is creating a community that requires nurturing to grow and thrive. When we publish our code with GitHub it is no accident that you immediately get an Issues tab and a Wiki tab. These are the author’s tools to build a community. And as the author one must be ready to accept that they are the leader of this community. That means meeting the expectations of that community to the best of your ability: maintaining the software, ensuring it is safe to use, supporting it as needed, and updating your users about changes.

However, nobody is suggesting that sharing code automatically dictates a lifetime of servitude. Authors must have the tools and community support necessary to lead within the confines of their time commitments. Part of nurturing and enabling a community is knowing how to ask for and accept help when it gets overwhelming and how to apprise your community about the situation.

Yet the author is not alone in this package relationship: the users bear an even greater obligation to the relationship. Every time a user downloads a new package and does not find some way to participate that user is helping to contribute to that package’s failure. It sounds harsh, but one cannot continue to treat open source software as a free ride and expect to suffer zero consequences.

The manner in which a user contributes back to an open source project comes down to two possible actions: time or money. A user can donate time by helping to improve and grow the project: opening detailed issues reports, submitting pull requests which fix bugs or add features, improving documentation, offering support to newer users, helping to lead the project, all of these activities take time from the user and give it to the author to help in the project. Time is the most critical thing an author needs to maintain a project. However, if time cannot be found or is prohibited or prevented by one’s employer, consider donating money or asking the company to step up and donate money. This can be tricky for some projects as questions about who gets the money, taxes, etc come into play. However, if there is an avenue to donate, please use it. If not consider asking the project to add one. Also, for some projects it is possible to buy advanced licenses or support agreements and this can be considered as method of getting money into the project.

Ultimately a package is only as strong as both the author and its users make it. It is incumbent upon both sides of the author/user relationship to commit to their expectations. Anything less is setting oneself up for failure. The event-stream incident is a lesson from which current and future packages can learn. The users share as much, maybe even more, culpability as the author does. An unwillingness to see that is an indicator of a willingness to fail again. And the big failure of event-stream is not that malicious code got injected, it is that no one will learn from it.

Supporting materials and further reading:

https://medium.com/@cnorthwood/todays-javascript-trash-fire-and-pile-on-f3efcf8ac8c7

https://www.zdnet.com/article/hacker-backdoors-popular-javascript-library-to-steal-bitcoin-funds/

https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a

https://changelog.com/podcast/326

Generally I avoid recruiting people on behalf of my company, but they have recently asked me to hire a person to work directly for me and to hopefully even replace me in the future.  And, quite frankly, I’m tired of interviewing people brought to me by the company recruiter who have no understanding of what is really involved in writing code.  So, I wrote this way more interesting sounding job description and now I’m looking to find someone to fill it.  Are you that person? Know someone whom is that person? Let me know with a quick email sent to vstijob/at/arei/dot/net.

Are you an up and coming hot shot Web Developer who somehow ended up working on government contracts?  Are you horrified by the state of technology that the government contract you are working on has saddled you with using? Do you wish that your project would stop supporting browsers that are 11 years old and move into the future? Do you want to move beyond writing JSPs, Web Services, and XML? Are you ready to give into the dark gibbering madness that comes with embracing technologies like JavaScript, CSS3, JSON, and NodeJS? Are you ready to awesome-ify your career?

VSTI, A SAS Company, is looking to hire a Junior to Mid-Level Web Developer/Engineer and we want it to be you. Well, we want it to be you if…

• You have a good basic understanding of JavaScript and are ready to learn a lot more.  And by ‘basic understanding’ we mean that you know what a closure is and how to write one in JavaScript, but you really want to understand why this makes JavaScript so powerful and all the really cool things you can do now that you know what a closure is.  We’re not looking for a JavaScript expert, but someone who wants to become a JavaScript expert.
• You know more about HTML/CSS than just how to write tags and believe that 90% of HTML should be written using only DIV tags and some amazing CSS. In fact, you should be able to tell the difference between block and inline elements at a glance.
• You find the possibility to use cutting edge technologies like NodeJS and ElasticSearch to be darkly enticing. In fact, just the act of us mentioning that you could work with those technologies makes you giggle like a mad scientist.  After the giggling has died down you decide to go read the documentation just for fun.
• You have a serious passion for technology and want to learn more, a lot more.  Ideally, you wish you could learn everything through some sort of cybernetic implant process, but you realize that you still haven’t invented that yet and the only way to learn is to read and to get first-hand experience.

Here’s the obligatory job posting details…

• You must be willing to work in Ellicott City, MD on a daily basis.  No telework is possible.
• You must have an up to date TS/SCI Full Scope Polygraph clearance.
• You must have a solid understanding of JavaScript, CSS, and HTML.
• You must be willing to be figuratively thrown into the fire.
• You must be passionate about learning new stuff.
• You must desire to become an expert in Web Technologies.
• You might also have an understanding of any of the following… Java, Groovy, Ant, Grails, more than one JavaScript frameworks (like jQuery or Prototype), Agile/Scrum/Kanban, CSS Resets, SVN, Hudson, CSS3, Rally, Apache Tomcat, or Git.
• If you have a Github account, a blog, or an active twitter account that will help your cause greatly.
• You might also be competent with some art software like Adobe Fireworks or GIMP, but it’s not a requirement.

In return for all of this VSTI, A SAS Company, will provide you with the following…

• A very competitive salary.
• Amazing benefits that you not likely to get elsewhere.
• Small company feel, Large company resources.
• An amazing chance to learn and grow your skills.
• Patriotic pride in what you do (since this is a government contract after all).
• The opportunity to be part of a team where your opinion is valued and taken into consideration.
• The possibility of free beer if you like that sort of thing.

So, if any of this sounds cool to you then you should apply for a job.  We’re interviewing now and we’re looking to hire very quickly.

So, I have, from time to time, been asked to interview various candidates, despite not having much say in the hiring process in general.   Mostly, I’m asked because my employers want me to tell them if the candidate is technically competent or not.  But for me, technically competency is only half of the picture.  I want competent, but I also want passionate, and that, is by far the hard trait to find. Passion is the difference between merely writing code and breathing code, the difference between a cog and a creator, the difference between collecting a pay check and committed to the future.

To that end I have developed a series of questions that helps me narrow the pool some.  These are questions aimed at gauging beyond competency, but the passion one brings to the team.  Without passion, you are just a robot and robots are a dime a dozen… (especially in government contracting).

So, here are my top five interview questions for finding the kind of people with which I want to work.  These are all related to software development, but I’m sure you can adapt these questions to whatever industry you work in. I don’t really have an opinion on your industry, so you are on your own.

Question 1). Describe the coding you do outside of work.

The answer a candidate has for this isn’t nearly as relevant as the fact that they have an answer for this.  A candidate who is not programming outside of their work structure is, generally speaking, not in love with what they do. If you don’t love what you do you might as well not be doing it, you are certainly not worth my time of investing in you.  I will give some credit to someone who describes what they would like to be doing outside of work, but they cannot find the time because of family.  I know families take up a butt load of time, so I respect that.  Often times when I am interviewing this question is asked obliquely in the form of “What’s your Github account.”  It’s the same thing really, although this will also let prospective employers view your work directly as well.

Question 2). Tell me what websites/sources you regularly read in order to stay current in your field?

This is a great question to separate the amateurs from the experts.  If you are not reading multiple regular sources to stay relevant in your field you might as well retire. Every field and industry has sources devoted to keeping you up to date in your field, follow at least three and stay on top of it.  When a candidate fails to answer this question I pretty much stop right there.  This is even more true for technology people than others, but can be applicable in other fields.  For example, my fiancee Jennifer is in Acoustics and she regularly reads science journals to stay on top of her field.  Technology just makes it easier as there are thousands of sources.

Question 3). “I see that you list Library X on your resume.  How would you change X and make it better?”

This is one of those dual purpose questions… You can answer this technically, but any answer you give will also show whether or not you have passion to make things better.  I can judge both by your answer here.  The worst possible answer though is “I really love the way X does this and wouldn’t change it at all.”  If you don’t want to change X you probably aren’t using X very much.  Actually, there is a worse answer than that and that is the answer where you fumble around trying to find an answer which tells me you lied on your resume.  Fail.

Question 4). “Who are some of the movers and shakers in your field that you like and why do you disagree with them?”

Again, this question goes to whether or not the candidate is staying current.  But more importantly, it delves into the candidates opinions and ultimately, passionate people have strong opinions.  You might not agree with them, but you cannot fault their passion and commitment to a point of view.  The follow on questions from this one can really be intense as well and give an interviewer a great chance at delving into the prospective employees views.  Don’t miss out on the chances this question can open up.

Question 5). “What’s the worst thing you’ve ever written and why?”

A great question that challenges the interviewee to examine their own work and then defend it.  This can be followed up with all kinds of interesting question to get at problems or desires, success and failures.  Passionate people not only recognize their failures, they have loads to say about how they would change things.  A person who doesn’t think they have improvements to make on their own work, is one I don’t want to work with.  Continually striving to better oneself is a must.

So there are my five questions.  As with all Interview questions, these are incredibly leading question which allow for a great deal of follow on and discussion.  And they are meant to be that way.  A single interview question isn’t an end, but a beginning to a discussion.  Ultimately, these question do not guarantee that you are going to find the perfect person.  Rather, they serve as a guide to allow you to delve into the depths of what really excites a person about the work that they do and the work you envision for them.

And there isn’t a score here for questions they got right.  All of these questions lead to discussions that will reveal the characteristics that I am trying to get at, namely whether or not the interviewee is passionate about their work.  Each interview is obviously different and have to be judge differently.  In the end it really comes down to a gut decision.  The hope here, however, is that these questions can lead you to better gut decisions.

The goal here is to determine a persons passion, their excitement for their job, because a person who lacks that kind of edge is really not worth the time.

Yes, it’s true. Dependency Management Pisses Me Off. Jason van Zyl over at Sonatype needs to be kicked in the groin… repeatedly. (Sorry, I don’t really know Jason and it’s not nice to say such things, but I wanted to really hammer home the point. Jason, I apologize to your testicles.) Seriously, when did we become so amazingly lazy that saving a JAR file into our SVN repositories became a big deal?

Now, I don’t want you to just think I’m some raving lunatic out there on his soap box shouting into the wind despite the accuracy of this picture; I want to at least pretend that you are not going to scream “TL;DR” and actually read the damn posting, so here is why Dependency Management pisses me off. Feel free to reply back to me on Twitter (@areinet) and I will engage you in some spirited debate. And I promise I won’t hurt your testicles in the process.

1). Dependency Management adds unnecessary complexity. Are we not just talking about saving some files into our SVN repository after all? Why is that so hard? And who on earth thinks that writing and changing a pom.xml file is actually easier than this? Also, there are people who would say that you shouldn’t be committing built objects into SVN (or whatever) and that we shouldn’t waste disk space. To these people I say this: Disk space is cheap. Seriously, the going rate for a HD is around 9gb per $1 USD. I assure you, no matter how many JAR files your project needs this is incredibly cheap.

2). Dependency Management puts someone else in your build loop. When I build a project, I want to rely on as few people as possible to fuck things up. Yet Dependency Management injects a completely incalculable third party into your system, and that’s just for one dependency. Sure, that dependency is always there, but with external dependencies, your are practically begging for your build to break because John Bozo three countries away from you removed six bytes of code from that one project you were relying on. Now, of course, you shouldn’t be using LATEST in your dependencies, but I really don’t want to rely on the fact that our build people are smart enough to realize this. If I just committed the version I wanted to the repository, none of these problems happen.

3). Licenses Change. When your build person goes out there and changes a version number, do you think they actually read a license file? Let’s assume for the sake of reality that people are incredibly lazy… now, do you want to take the risk that so and so actually read the license? And that the license didn’t change? Seriously, it would take me about six seconds to change the license on some sub-project you use and then commit it. And suddenly the sub-project owns all of your IP simply because you used them. Now, the legality of that is a debate for other scholars than I, but it could certainly cause a mess. The only thing stopping a sub-project from doing this,is the hassle of suing your ass into oblivion… And we all know that people are getting more and more litigious every day.

4). The Internet is, by it’s nature, unreliable. Do you really want to rely on the fact that the internet providers upstream from you are not going to screw something up right when your absolutely must deliver build has to get run? Seriously, the more people that have input into a process, the more likely that process is to get derailed. I do not want to think that my ability to deliver is dependent on whether or not Anonymous is going to cause a world-wide outage in protest over SOPA (which sucks by the way). Sure, you can run a mirror of x repository and spend your time maintaining that as well, but wouldn’t you rather spend time, oh I don’t know, outside? With a girl? playing WOW? Doing anything else?

So the point here is this and this is the TL;DR for you lazy people as well… Dependency management adds both complexity and unpredictability to your systems and this is not a good thing. A Build process is about Rigor, and Dependency Management is antithetical to rigor. By using a Dependency Management solution you are willingly signing up for problems and extra work. Who wants that? When given the choice between that and just storing the files I need into my repository, I will choose the latter every time.

Now, I do think some dependency systems are way better than others. The node.js NPM system is amazingly clean, but it’s still begging for the problems I outline above. So, maybe not that awesome. It is easy to use though, wish Maven were half that easy.

So, that’s it. That’s why every time my coworker comes in and raves about how awesome Maven is I just point at his crotch and start laughing. I mean, really, Maven? Awesome? You got to be an idiot to think that. (My apologies to my coworkers.)

Lately, I’ve been asking myself if my current work role is really the best use of my talents.  But shortly into wondering about the answer to this question, I had formed an even more important question: What exactly do I consider the best use of my talents.  So, here, for better or worse, is where I think the best use of my talents lies…

First and foremost, I’m a hacker type through and through.  A work day in which I am not writing code is a terrible day for me.  A work day in which I write a little code is a terrible day for me.  A workday where I am heads down, balls to the wall buried in code and completely oblivious to the passage of time.  Ding!  Awesome day.  What’s even better about those kind of days is that when I’m in the zone like that (Interface Designers call it “Flow”) I am disgustingly prolific. I mean oodles and oodles of code being churned out.  That’s a win for not just me, but the company for which I am working.

Next, I am a very creative person.  This means I get strength and energy from creative outlets.  I am not going to be your go to guy to write that piece of software for which you have painstakingly provide pages and pages of detailed specification.  No, I’m the kind of guy you come up to and say, “Hey, I had a friggin awesome idea, can you whip something together for me to test the idea out?”  I will take your crazy ass idea and run with it.  Now, the result here can be mockups or it can be straight to code, I’m comfortable either way, although I think I’m more productive in code, but whatever.  Just give me an idea that I can contribute to and put my own spin on and I will exceed your most wild expectations.

Also, I love writing reusable components and libraries.  Recently Jacob Thornton an engineer at Twitter (@fat) shared a tweet at JSConf 2012 that I really found interesting.  He tweeted, “new interview question: you have 45 minutes to write JQuery from scratch. get as far as you can. start from wherever you’d like.”  I absolutely loved this question, not just because I think it would really separate the wheat from the chaff as it were, but also because I would love that challenge.  Ultimately @fat concluded that anyone trying to answer that question would be screwed because there’s so much depth to JQuery, but I would absolutely love to try.  I could spend a lifetime reanswering this question over and over and over, getting it more and more perfect each time.  I have been fortunate in my career that the work I am asked to do more often than not has limitations that prevent us from using certain libraries.  I get to go in, study those libraries and then recode them for my project.  It’s quite enjoyable and amazing enriching.

Finally, I love sharing my knowledge with others and learning their ideas and knowledge as well.  Mentoring to me can be quite a lot of fun and there is nothing better, IMHO, than a willing and eager student/peer that wants to learn or wants to debate.  I love that sort of thing.  The caveat, though, is that these activities must not take away from the above two activities.  I like mentoring some of the time, but when it becomes a full time job, when I start managing, that’s where I lose interest.  Surprisingly, I am extremely good at managing and have had a number of management position in the past, but ultimately, I have no interest in doing it in the future.

So, all that said, my ideal job is Hacker and Evangelist of Prototype Libraries. Now, I know that’s probably not a real job (if you think differently, please send me an email!), but that’s what I would ideally like to be doing. And it’s pretty cool that I’ve figured it out.  I now have a benchmark by which I can hold up two jobs and ask, “How much does each of these jobs approach the ideal for which I have set myself.”  That’s the job I’m more likely to take, that’s the job I want.

So, current job, how much do you think you live up to my ideal?

Let me be blunt: When you email me to tell me all about how you have positions and could I just call you to find out more details… ya, that just pisses me off.

I am a busy individual. I have a really good job. If you want to have any hope of luring me away from that really good job, you have to be (or offer) better. And I’m not talking about money here. I’m talking about better understanding, better service, and better opportunity. You have to understand that in our industry (software) there are more positions out there than there is talent; you have to understand that I have no interest in talking to you about the same boring job every other recruiter is pitching; you have to understand that YOU are trying to use me to make money and therefore have to provide ACTUAL VALUE to me.

Let’s take a recent example… I got an email from a recruiter telling me that his company had available positions in Infrastructure, Software Development, Integration, Engineering, and Information Assurance, and if I would like I could call him for the details… DELETED. That’s right, straight to the trash can with that email. Why? Because everyone has positions in Infrastructure, Software Development, Integration, Engineering, and Information Assurance available. Oh, and also because I’m not going to waste time talking to you about a generic job posting.

So how about a better example… Well, one recruiter piqued my interest with the generic sounding descriptions, so I emailed back and I share with you what I wrote:

Dear XYZ, I am very intrigued by the positions you listed.  I would love to hear more about the specific position you have in mind for me.  Could you email me some details and I will let you know if I am interested?  I’m very busy right now, so email is the best way for us to communicate, if you don’t mind.

The answer I got back was:

Dear Glenn, you can reach me at xxx-xxx-xxxx.  I’d really like to talk to you about this opportunity.

Okay, for starters, spell my friggin name correctly.  You misspell my name, automatic trash bin for you. Secondly, I’m not going to call you until I am convinced you can provide me value.  You’ve already failed to understand that people are busy and it doesn’t look good for our relationship. Finally, actually take the time to READ the email I sent you.  The fact that I sent you one at all, considering how many recruiter emails I see during the course of the day is amazing.  You should hang on my every word.  Seriously.  I would estimate that I pretty much delete outright 95% of the emails I get from recruiters, and the other 5% gets deleted after one email exchange.  That’s pretty sad.  You can do better.

So how, as a recruiter, does one actually do better?  I’ve wrote you a list.  (Now consider this… I am willing to spend 30 minutes more writing a list about how to do better than I am willing to spend responding to your lame emails.)

1). Actually read my resume and have the technical ability to understand it.

Yes, I list Java on my resume just like everyone else. But, if you actually took the time to read my resume you would see that I don’t actually list java in a job for the last 5 years, but rather there’s a lot of talk about JavaScript.  Now, which type of technology job do you think I am looking for? The one from five years ago which is slowly dying or the one that i have been working in for the last five years that’s hot as shit right now?

2). Stop trying to appeal to the morons.

A lot of recruiters just go by keywords and the mass mailing approach to getting clients.  Maybe this works for some, but it will never work with me nor anyone whom considers themselves my peers.  Believe me,  I can find a crappy, middle of the road job by myself, I don’t need you.  What I need you for is to find me that one job that is way over and above what I can find myself. All your offering me is, to quote Hamlet, “Words, words, words.” I want the dream job, not the boring average job. Which leads me to my next point…

3). A job that is described in keywords is not a job in which I am interested.

Jobs descriptions are marketing tools.  If you want to sound like Budweiser and says “We taste just like everyone else!” then bully for you, but I am still not drinking it.  Why would I when I can consume an experience like Heavy Seas Loose Cannon or Boulder Vanilla Porter.  Spice it up and really try to sell it… without using the same damn terms everyone else is using. Be creative… I know, TV has killed all creative instinct in you, but surely you must remember something from being a child.  Try it out.

4). Take the time to be right.

Grammar and spelling mistake = Deleted.  No exceptions.  If you cannot be bothered to wordsmith simple emails, I cannot be bothered to read them, and I’m certainly not going to trust you to be accurate when representing me to a customer.

5). Listen.

If I tell you in an email that I am really busy, try listening to me and working with me through email.  Stop trying to get me on the phone.  And worse yet, do not send me your form to fill out.  I’m not applying to a job at Burger King.

6). DO NOT copy and paste a job description.

Google may be the best thing you ever found for finding leads, but it’s also your enemy when it comes to job descriptions.  I am willing to bet that I can find the company hiring directly and circumvent you (not that I ever had) just by using Google and the cut and paste you just did of the job description.  Yes, it might take a little longer to recreate the job description and worse yet you might have to actually understand technology to do this, but it shows me that you are actually trying.

Now, I know many of you recruiters have reasons why you do what you do and I really want to believe it’s not just because you are lazy.  So let me try and answer some of your concerns.  (I’ll add to this if you email me some constructive feedback.)

I need to reach as many people as I can  – Go watch the first 10 minutes of Jerry McGuire.  Now, watch it again and this time try listening.

The only way I have to understand you is your keywords – That’s great.  Use keywords to find me, by all means, but then take the ten extra minute to actually read what you found.  Bonus points if you actually look at any other part of my blog while you are there.  Actually take the time to try to UNDERSTAND me.

I don’t have time to read through all the resumes I see – Make the time.  Quality not quantity, if you think different than I salute your mediocrity.

Staying on top of Technology is hard – Yes, yes it is.  Yet, some of us manage to do it just fine.  Twitter can be your best friend here.

Company X wants its job listed as Y – So what?  Eventually sure, share that with me… but for initial contact, sell it.

I can’t afford to spend all my time on you – Then I cannot afford to spend time on you.  Remember, you only make money by me changing jobs, which is a ridiculously hard thing to get people to do.

Quality is nice, but Quantity pays the bills – But quality builds reputations.  Take for example where I live… there is nothing but chain restaurants here with a few notable exceptions and I have never been known to espouse the amazing food I just had at a chain restaurant.  With a few notable exceptions. Even then, it’s the quality I’m espousing… not the quantity. If you want to be the kind of recruiter that people tell their friends to go to, then quality is a must.

When it gets right down to it, I just want a recruiter whom I not only trust, but that I know I can return to if I need to.  Someone who understands my SPECIFIC needs and desires in the workplace and doesn’t just want to represent me because of the money, but because he or she is actually helping me succeed.  In twenty plus years I have only met two recruiters who meet those goals.  And I keep in touch with both of them.

Lately I’ve been the subject of what I call developer drift.

Developer Drift is the process by which an unchallenged developer slowly moves from one project to the next. The project may be in house or external or something completely fabricated by the developer’s mind, but it basically means a developer is less interested in the current project than the project over the horizon. It’s the “Grass is always greener” truism made concrete in software engineering.

For me, this has taken the form of the fact that our customer wants really boring user interfaces which I can crank out like they are nothing. Problem is, I almost never crank them out, because they are meaningless and I never feel challenged/creative by them. (For me challenged=creative.) So I take forever to implement them and tend to make a lot of excuses on why this is taking so long. I feel justified in why it takes so long in the fact that when I am challenged, I really do crank out the code at an extraordinary rate which borders on the obscene when compared to average developers. I’m very prolific when I want to be.

The same thing was true when I was back in college studying English Literature. I could crank out a paper that I found interesting in no time flat, but assign me something that was pedantic and I’d sooner rip my own teeth out with a spoon (“because it will hurt more”).

So the real question I’m trying to find an answer to is “How do you deal with developer drift?” How do you stop people from losing interest when they are bored because the project has become boring? A project I used to work on is suffering from this very problem… they want to keep the team together, but the more boring stuff they do, the less likely they are to be able to keep the team together? Is there a way for this project to challenge it’s developers at the same time as doing boring things? Would contests or “feats of skill” help keep things from getting stale? Or should they just accept this as the life cycle of the developer, assume that people are going to drift away, and prepare for the next generation?

You tell me… how does your project deal with developer drift?

So, I’m due to have yet another annual review this week. If you read my earlier post “Deciphering What your Annual Review Means” you might recall I’m not really that excited by annual reviews or their results.

But, in preparation today I went out and did a little math. According to the Consumer Price Index (CPI-U) which measures how much things costs for the average person, the costs of things has increased an average 2.8% every year for the last 10 years. That means, any merit increase I see that is less than 2.8% means I’m losing money. And a raise of 3% means I’ll see .2% more money a paycheck! Hold me back I’m going on a spending spree. (That was sarcasm in case you missed it.)

Honestly, I expect 4% though and I’ll have to start lining up some interviews after the holidays.

Google announced yesterday a new offering called Google Wave.  There is an excellent article at TechChrunch that gives a complete overview.  All I can say is: THIS IS HUGE PEOPLE. The concept of Google Wave, the underlying idea is exactly the right step that the web and the internet needs to take. It’s a combination of Email, Instant Messaging, Twitter, Transparency, Collaboration, Wiki, Media sharing, and so much more.  Oh, and it’s an Open API and Open Source to boot.

If you’ve ever talked tech with me in the last three years and we’ve had the discussion about what is next in technology, then we’ve had a very similar discussion about the concepts behind Google Wave.  I’m not claiming Google has once again stolen my idea, but what I will claim is that there clearly is a need for this type of product that I saw and google saw and others saw as well.

Two things in particular I want to call your attention to that make Google Wave a huge idea:

1). Adhoc groups… What adhoc grouping really does for you is to let people create internet groups as easily as they create real world groups.  Think of it this way… when you walk into your work place break room and two other people walk in and the three of you start talking, you have created a group.  It’s fast in the real world, why can it not be like that in the internet world? For most of the internet when you want to form a group and start working together there’s a fairly large investment in creating the meta systems the group needs: setting up a mailing list, setting up forums, setting up a media store, setting up a user database, etc etc.  It’s a pain in the ass really, and it make setting up a group fairly non-trivial.  To some degree, Yahoo Groups and Google Groups automates a lot of that, but then you still have to go through the effort of getting people to join etc.

What Google Wave does is to make group creation simple and almost instantaneous.  Basically, you create a group by dragging a bunch of contacts together and off you go.  You can immediately begin discussion, expand the group, whatever.  Additionally, if you need other tools for that group like a map or a document or some other thing, you can add a widget or a robot to participate in that  group and boom, you have more functionality to fill the groups need.

2) The second feature that is huge for me is transparency.  Transparency is the notion behind Twitter in that you broadcast snippets of your activities out to the world and everyone can see what you are doing.  This is the beginning of transparency though.  To take it further you need to automate transparency such that as you do things, they automatically are published.  Of course, this brings up privacy concerns, but I think there are simple ways to solve this.

I know that Wave has some level of transparency, but it’s still to early to tell how much.  I suspect that even if this is an opt in version of transparency, like Twitter, that soon there will be robots and widgets (the extensions to Wave) that will automate a lot of this functionality.

The point is, though, that transparecny can be a huge social tool… but more importantly it could be a huge business tool.  And the company that sees this is going to get a huge edge over the company that does not.

Anyways, that’s my thoughts on Google Wave.  You should efinately check it out.

Lately I’ve been having a lot of conversations with people about what environmental factors go into creating the perfect work/space environment for a person.  This in part may have been introduced by Eric Spiegel over at Datamation posting a couple of articles recently asking Where’s Your Coding Happy Place and Finding The Coding Zone: Your Perfect Trifecta.  In the articles he discusses where is the best place for him to code and what external stimuli facilitates that.

In User Interface design there is a concept called Flow.  Flow represents that “in the zone” state about which Spiegel talks.  It is this perfect state of unity with ones work.  It’s a wonderful place to be and when we can achieve it we are at our most productive and do our best work. The problem with Flow or “being in the zone” is that it is amazingly easy to interrupt.  A ringing phone, a coworker asking a question, or piece of email can all break you ot of your Flow and completely disrupt the brialliant work you’ve been doing.  And once Flow is interrupted it is fairly hard to recover again.

Breaking flow is really easy to do and there are a number of pieces written about things that do this.  Just about any kind of interruption or distraction will do it.  In a User Interface, for example, a popup dialog box or an animated paper clip can be enough to completely destroy the user’s Flow.  It’s considered bad UI Design to create activities that break flow.

What is much harder to quantify is what exactly does it take to achieve flow?  This is ultimately the question that Spiegel is asking in his article about “The Coding Zone.” A lot of people go about achieving Flow in different ways: turn off the phone, close the email application, close the door, blast the music, have food and drinks at hand, turn the light on, turn the lights off, work at 3am in the morning, whatever it takes.  And a lot of people know what it takes for them to find Flow.

For me, Flow is about comfort and ignoring the rest of the world.

First and foremost I need to be comfortable.  A good chair, appropriate lighting, keyboard perfectly position in relation to seat.  All these things factor into comfort for me.  In particular, lighting is very important.  I’m one of those “likes to program in a cave of darkness” person.  Unfortunately, I’m also one of those people forced to work in a cubicle with overhead florescent lights.  I have managed to convince my fellow cube mates to keep the overhead lights off and rely on the personal cubicle light, but sometimes this takes a little arm twisting.

As to ignoring the rest of the world, well that’s fairly easy: turn up the music so you don’t hear outside sounds, don’t answer the phone (unplug it if necessary), and turn off the interrupting applications.  I’m pretty adepts at just ignoring the Instant Messages, Emails and Phone Calls that cross my desk.  I’ve also minimized the interruptions that they present… for example, email plays a simple low volume sound for me, but nothing else.  It lets me know it’s there, but does not draw me away from what I am doing.

Flow allows us to work at our highest, most efficient levels.  So why do our employers fail to set us up to achieve flow?  Instead of helping us to find our “zone” they do everything in the power to surround us with distractions.  In my workplace I have to dress a certain way, I have to be there at a certain time, I have to work in a cubicle listening the the minutia of my coworkers.  None of these things is helping me find my Flow.  In fact, all of these things are actively hindering me from doing my best work.

Let me repeat that: My company is actively hindering me from doing my best work.

Kind of scary when you think about it.  You would think that for a company, quality is the most important thing.  Yet from the actions of most companies, that’s hardly apparent.  In my workplace, quality is second to how the company appears to the outside world.  Perhaps that’s the nature of business, but it really just speaks to a lack of quality.  That makes me sad.

So, let me leave you with a question… but instead of asking how you find the best Flow like Spiegel does, I’m going to ask you this: Is your company intersted in quality or something else? Do they encourage flow, or do they discourage it?  Do they Flow?

Why am I never amazed when a software engineer wants to add complexity?  By this I am talking about all these abstraction layers of tools and frameworks and engines.  These tools/frameworks/engines are supposedly designed to save developers time, but really just add complexity to the stack and in the end don’t end up saving time at all.   Now, instead of just knowing programming language X I need to know Programing Language X and Abstraction Layer Y. How is working in two technologies easier than working in one?

I know some will argue that “Well you only really need to work in Abstraction Layer Y.”  Except that is never just the case.  Abstraction Layer Y is great until you have to do something that is outside the basic cases of Abstraction Layer Y.  Then you have to go back to working in Programming Language X.  Suddenly you’re working in both.

Don’t believe me?  Consider the case of Google Web Toolkit (GWT)… GWT lets you write web pages in GWT’s Java Toolkit.  It removes the need to work in HTML and Javascript and CSS.  Except, well, CSS is still use to provide your sites look and feel.  Oh, and you still use HTML inside the GWT code.  Oh, and you want to do something a little more complex than what GWT offers? Looks like you’re going to have to embed Javascript into your GWT code as well. So, instead of just having to work with HTML, CSS, and Javascript, now I have to work with HTML, CSS, Javascript and GWT.

Seriously, it’s basic math.  X + Y > X where Y is greater than 0. Yet time and again engineers are all gung ho about Abstraction Layer Y and I suspect it’s for one reason: Fear.  They’re afraid that they will have to do work, they’re afraid that their incompetence will be visible, they’re afraid that their value to the company will be realized. Fear is an extremely strong emotion and it can lead to panic, chaos and distrust.  But underneath it all is pure cowardice.  Cowardice to get things done, cowardice to admit your shortcomings, and cowardice to realize your own mediocrity.

And the worst kind of cowards are the ones that want to do trade studies.  Let us spend all of the budget and time for the project on comparing Abstraction X to Abstraction Y to Abstraction Z before we choose one.  Don’t worry though, we’ll have plenty of time and money after we run out of time and money to build the software.  Shouldn’t take more than two weeks, right?  The engineers that want to do this are the ones with the most to fear.  I believe that they would rather do trade studies than write code.  If you don’t want to write code, if you don’t LOVE to write code, you’re not a software engineer… you’re middle management.  You need to realize your fate and go work for the federal government wasting tax payer resources.

So, is there ever a case where Abstraction Layer Y makes sense? Probably, but it’s far, far less frequently than one might imagine.  Sometimes an abstraction layer can actually achieve the nirvanic state that it set out to do.  It’s kind of this sweet spot between being overly simple and overly bloated.  And I suspect that of the thousands of Abstraction Layer Y’s out there, only 1 or 2 have actually succeeded in finding that spot.

And yes, this is a little bit of a rant against Abstraction Layers… but it’s not a rant against the people who write Abstraction Layers.  The people who write Abstraction Layers are freaking genius.  Basically they have identified the fears of software engineers and are exploiting it to make money or recognition or whatever their particular motivation is.  This is brilliant in my opinion and I seriously need to start working at one of these companies.

To conclude: Abstraction Layer Y sucks and is a waste of time.  Just write the code yourself.  It’s not that hard.  If you think it is that hard, you need to quit your job now and go manage the fast food restaurant you were always destined to manage.

So, being a Java guy I’m fairly religious to Sun as a company.  I invested in their stock a while back (for good or bad) and thus I always kind of keep an eye on the company.  Recently I came across a series of video blogs by Jonathan Schwartz, the CEO of Sun.  The one I want to share with you is his second video blog.  The blog talks about the Sun view of the technological market place, and how giving brands away for free (like Java and MySQL and others) drives adoption, which in turn can drive revenue. Now, I’m no corporate financial officer, just a code monkey, but I found the blog well thought out and I thought I would share it with you.

My own company is currently working on a new project with the goal of productizing it.  We’re still in the early development of this product and haven’t had the discussion about how to sell it to consumers yet.  However, as I go about building the User Interface for this site I cannot help but keep thinking to myself (even prior to reading Jonathan’s blog) that the value of the site can only be realized by driving users to the site (or as Schwartz put it: building adoption).  In order to achieve this, the site would need to be largely free to the masses and make its revenue either through some ancillary stream or by charging only for some specific “higher role” usage.  As I designed the front end and go about coding it, I keep telling myself that the site is meant to be used by millions of people freely and must scale accordingly.

Like I said, I’m not the business guy, just a code monkey, but I really can see this notion of giving something away and finding revenue beyond just usage.  I like to think of it as the Field of Dreams model… In the movie Ray, the main character, is told to “Build it and they will come” which is much like the philosophy Schwartz is espousing.  The existence of the Field of Dreams brings the people, and there is surely revenue to be made after the fact: selling popcorn or something; the method is not as important as getting the people, driving adoption.  If you have the people, selling them something they want beyond what you are offering should be easy.

Anyway, if you’d like to read/watch the video blog I am talking about, you can find it here: http://blogs.sun.com/jonathan/date/20090306

If you’d like to read/watch the entire video blog series (there are four of them), you can  find it here: http://blogs.sun.com/jonathan/date/20090302

If you’d like to follow Jonathan Schwartz’s blog, you can find it here: http://blogs.sun.com/jonathan/