4 posts tagged “software development”

At work, I've been trying to find some good programmers to join the team.  We have a sort of ambiguous opening, as we have several positions to fill in the future so we're casting the net wide and hoping to find some really good candidates that fit those positions.  It is very difficult to find well rounded developers who can do backend development, as well as front-end development or other aspects of the job that are required.

Given that is a normal constraint, it's a good idea to partition your team into what they do well and what they enjoy doing.  A very important part of this is personality and temperament.  For example, there are certain aspects of personality that I look for in any person that I may work with, or have some business transaction with.  Some of these are very odd, but they are details that I notice.  Here's my list:

• Do they spell check their emails and IMs?
  This is really important for me.  Whether they use in-line spell check or have impeccable spelling performance, or post-spell-check is irrelevant.  It isn't about some pedantic desire to see correctly spelled words, it means that they've taken the time to employ technology to help them do things right.  Well, unless they're impeccably good spellers.  In which case they're nuts, but I hope I can figure that out from the rest of the email.
  
• What does the interior of their car look like?
  There's two types of messes: negligent clutter and filth.  Negligent clutter accumulates because of a busy schedule, but it has a manageable level and won't pose a health risk.  If you look in a car and there is an old drink and quite possibly old food then there is a problem.  Minimum standard of living, I think.  Cars tend to be more accessible than houses.  If I look at my office, I have a horrible clutter problem.  Most of the papers and other things on my desk are, however, relevant.  I just don't have any sort of order to managing things I'm actively working on so it gets thrown on my desk.  Once a month, I get fed up with it and clear out the clutter.  Very rarely will I have, say, a coffee cup that is from yesterday.
• Manicure.
  I don't mean this in the sense of having polished nails, but I do mean it in the sense that there is a sense of personal maintenance.  If someone can't be trouble to take the time to keep their fingernails trimmed, can I really have faith they'll take the time to do maintenance on things that are less trivial?
• Accurate expression and articulation
  I grew up in a very rural environment, with a veritable dearth of linguistic sophistication.  In other words, until recently, I spoke very simply.  There were a lot of words I knew, and I knew I knew them, but had no idea how to pronounce them.  Certain annunciations were particularly challenging, and I worked to overcome them.  That's not really what I mean though.  What I mean is using the wrong word and the wrong time, or an inappropriate expression.  If you attempt to use "denigrate" make sure that you know what it means and use it in context.  I've found that people who can do this are typically motivated to improve themselves, and by correlation, improve their environments.
  
• The outspoken critic: pro or con?
  There is such a thing about being too agreeable.  While some candidates come across so bullish that you wonder if work is ever actually done, or just assertive banter talking about how to do it, other candidates can be too accommodating.  The notion of an employee so devoid of passion that they'll never tell me I'm being stupid is frightening, but many people are like that.  In fact, more are like that than my other statement of being too passionate.  Then again, I've worked in places that the warm-fuzzies are paramount, and even just questioning a directive meant I was "disrespectful" so I think this goes with the culture of the company.  If you value the friendly nature and an amiable workplace, don't join a high energy company.  Don't even try.  I've learned my lesson on that going both directions, where any dissent was viewed as troublesome and the opposite end where if you failed to speak up you obviously weren't passionate about your job and would never rise above being treated as a useless grunt.
• Don't Revolutionize the Revolutionaries
  Most companies feel they're doing a good job of innovating, or at the very least, performing in the market segment and want to improve in some documented plan.  Unless the position open is for revolutionizing their business practices, a candidate shouldn't describe grand architecture changes that they happen to find valuable.  Recently I had a candidate tell me that we should begin porting all the core pieces of the site into C, for speed improvements.  That's a huge undertaking, and isn't feasible for so many different ways.  Don't do that.
  

In conclusion, above all, if someone offers a candidate an explanation as to why we're not moving forward with a candidate it means that I'm opening dialog to explain the reason why we aren't picking a candidate.  It doesn't mean that candidate should be snide and sarcastic about how good they are, and the company is making a huuuuuuuge mistake by not hiring said person.

Really, if someone does that they're just reinforcing that the employer made the safe choice to move on.

These are my interview notes, or at least how to get on my good side.

Today I just pushed a new package to CPAN that introduces a "Graphics" helper.  The general idea of the package is to install into any Catalyst application a batch of ready-made images that are useful.  The only thing it currently has is an AJAX activity indicator, but I'm currently seeking other images to include.

If you have any ideas for new images to be included in this package, please let me know!  I'm "jshirley" on IRC, or you can comment here and my email is always open.

Keep an eye out for some screencasts, coming soon!

Inspired by a recent memo sent by Yahoo! VP Brad Garlinghouse, I propose naming a very popular development methodology "Peanut Butter".  This isn't a methodology that you want to use, mind you.  It is the way that spaghetti code is created (All hail the FSM) and developers spirits are lost, sometimes forever and you get burnout in the industry.  Really, every company I have ever worked at or consulted with has used this method.  I've used this method (many more times than I'd like to admit).

Really, development with this methodology happens exactly like Mr. Garlinghouse states:

I've heard our strategy described as spreading peanut butter across the myriad opportunities that continue to evolve in the online world. The result: a thin layer of investment spread across everything we do and thus we focus on nothing in particular.

Peanut butter development is an approach to spend as little resources as possible on any single given problem.  

If you think of the points made in the memo (I urge you to read it) they all hold true almost all the way down the chain to every aspect of work.  It is a fractal of bad habits that permeate from the lower levels all the way up, or the other direction if you prefer to look at it that way.

Here are two of the most catching points in bold (you know, like those textbooks that mercifully list everything you need to know for the test in bold):

While developing software, this is also a problem.  Too many people fail the "ownership" test, and by this I meant they refuse to own the product, only the cog they specifically built.  Ownership means you own the product, whatever that may be.  If you ship a product, you fractionally own it but your responsibility are for the whole.  Nothing destroys my hope in a developer than hearing "I didn't write that code" and refusing to help fix something.

Accountability is also a mixed bag.  How much accountability can you hold a developer to when the industry, tools and end user simply doesn't share the sentiment for?  If I chastise a developer for poor quality work, chances are they'll just go find a new job that allows them to slip under the bar of lower expectations.  How many developers, or people in general, actually take pride in the quality and craftsmanship of their work today?  Sadly, few.  The reason?  A decline in accountability in the professional sector.  The solution?  Shove the egg very forcibly back in the chicken.

If you look at companies that truly cater to the best and brightest, this isn't an issue with them.  Accountability happens, and the person is rewarded for it.  Why can't we do this in every company?  The sad answer is that there is simply too much incompetence and insecurity for that to be a reality.  There is a finite amount of talent at the top of the pool, so you must deal with what you have. 

Automated accountability is the only answer I can think of that works through most of the edge cases.  Test cases that email failures very publicly throughout the organization.  Highlight the person or group who did the last commit of related code.  Public code review cycles that allow everybody to see code reviews go through.  In my opinion, doing this is the best way to weed out the people who are simply looking for the job with lowest expectations of themselves, as they're names will constantly come up.  This doesn't solve the problem, it just gets the low hanging fruit and allows developers who exceed at not accepting accountability to identify themselves.

So, back to peanut butter.  The problems with peanut butter development is that eventually, everything will be sticky, crusty and hard to work with.  It is somewhat permanent, and takes monumental effort to undo what was a very simple application of a solution.  A peanut butter solution is a binding solution, that doesn't allow any flexibility or extensibility.  The only way to revisit and solve the underlying problem is to throw out whatever you put the peanut butter on and begin again, hopefully you can at least see the original idea beneath the peanut butter, but you probably can't.  It is unrecognizable to the original form, and thus, unusable.

Peanut Butter begets Spaghetti, and really, just imagine a peanut butter and spaghetti sandwich.  That's what developers are making, and then they complain when they have to eat it.  The problem isn't just with the developers, though.  It also lies with managers who are always pushing for the fastest and leanest solution, quickest time to market and best ROI.

Sometimes that's fine, and works great.  Most times it doesn't, and it is a good manager who understands the difference between the moments.

Recently I was tasked with ... repeating myself.  Over and over again.  To be specific, 33 times.  While doing so, the mantra of good software development was repeating over and over in my brain.  Resonating further down, in places wholly and completely uncomfortable.

There are always going to be cases were you must repeat yourself, unless you impose strict guidelines when you begin the development process and adhere to them.  Unfortunately, getting agreement on these matters is an exercise leading to the same type of frustration you'll get when your car breaks down and you open the hood, only to realize you don't know what the hell you are doing.  It's as simple as that, really.  I just don't think it is possible to get two developers together, at random, and have them have an understanding of what the other is doing.

Certainly the more two or more people work together, the alpha geek steps forward and other developers will silently adhere to principles passed down.  A good alpha geek will take feedback from below, and, dare I say, a synergy is formed.  The problem is that this usually happens several months into a project, typically when the long tail is beating mercilessly upside the head and now the group has to live with code that wasn't designed with the same confluence that now exists.

And thus, you end up having to repeat yourself because the project must go on, and it typically isn't an option to refactor the previous code so instead there are two copies of the same code, only one doesn't suck.

I think that's how it works anyway, I'm getting back to my copy and pasting...