Tuesday, November 30, 2010

Where did software quality go ?

A while ago I met with an ex Technical Director of a very large game company here in Vancouver. I was working for a local company myself, and we met about a possible project between the two companies.

While going over the details we reviewed some legacy systems that they would be working with, the software quality was less than ideal.

The statement he made quite a few times that got me thinking was - "all software is messy and usually bad, and that's just the way it is".

To which I instantly thought :
 

“The constant assertion of belief is an indication of fear”

~ Jiddu Krishnamurti


I'm not sure if this was just his defeatist attitude, or one that had been fostered from coming from a corporate environment that was steeped in technical debt and that usually worked to the lowest common denominator.

Though it did make me think - as I don't accept that, at all, so why do so many others?

In my experience people who create technology typically attempt to do the best they can in the environment they are in, with the skills, information and support  they have. We all have bad days, and inexperience can trip up neophytes as they learn. Though the vast majority of developers I've worked with want to create quality, something to be proud of and to be seen on TechCrunch and the like.

So why does it "go wrong" so much?

Why is a lack of quality :

A) accepted as the norm (by a truth by constant assertion I believe)

B) supported by attempts to do a decent job signed off as "over engineering", "wasting time" and my favourite ........... "taking too long" (as if technical debt is cheap to work off)

---

I'm happy to say I've worked in both kinds of places - though sad to say the poor attitudes to the approach of creating software are still very prevalent.

Lots of places want the rewards of success of doing a quality job, so why are so many companies avidly avoiding actually doing a good job by choice? Partially senior management ignorance & lack of quality management, though mostly a short term view I think.

I was happy to see Mark Zuckerberg speaking a while ago about longer term view of technology - basically how so many failed dot coms were thinking build junk and sell it quick, and got what they deserved.

I also find that a large and worryingly growing section of business believe that "agile" is a one stop shop to assuring quality in software and that it will cure all ills - it wont. It is just a process, and therefore an organisational tool. It organises work flow and tries to support communication, but it isn't going to assure McLaren levels of quality.

You can apply all the tools (process or tech) you want, though if the mindset and approach is the same it's nothing more than a thin veneer.


I  think there is a collective answer to this, and one that developers themselves must be a part of, opposed to finger pointing at "the suits who just don't get it". If they don't "get it", then we have a responsibility to show how and why, as well as learn the bits we don't get in business.

---

Firstly I think that there is a lot of confusion as to what a prototype is and what it purpose is. If it's just to show mocked up functionality of put in front of a VC, then that's it's purpose. Not to be given to a development team the day after funding and told to "make it work". It was a tool to show concept to get money ..... then let it be that, just a prototype.

Defend against the "Oh it's built using agile we can just improve on it", if it was and architected correctly then fine, but if it was hacked together over a weekend to have some buttons that work, then that's what it is, a hack job. You take some UI or content, but be very aware that a demonstration on a laptop and serving tens of millions of users a day in a distributed scaled system manner are about as different an environment as you can get.


Having someone who understand architecture is vital, i.e. the most senior technical person. Look at the vast majority of successful tech companies leaders and their levels of technical knowledge, opposed to just business acumen.


Secondly I think a lot of developers know the difference in quality, though they don't communicate that though fear of reprisal and the demoralising put down of "Oh it's just a 5 min hack, put it in". Leaning how to manage that communication and finding a suitable process for change management is also vital.

I enjoy cowboy coding, when it's just me and for hobby projects, even then I follow some process ........ but when it's a company and/or team environment, the benefits and speed of quality far out weigh the midnight hacker mentality. Especially when capturing the logic of the solved challenge (i.e. design and code comments) and sharing that amongst the team, which is the essence of what developers should do (fire people who don't comment code and can't explain it 2 weeks later, seriously !!).

A business & sales mind (or any mind for that matter, we all do it) will see a "product" and make assumptions as to it's purpose, fitness for market and all manner of things. That needs to be clarified amongst all parties and especially understood by the product owner. Manage expectation and focus on clarity of communication.


Third is the quality of engineering, education and knowledge, or the lack there of. A piece over on supercoders.com.au covers this nicely, talking about Design Patterns and why there is a difference between a 3 week scripting course and a 4 year software engineering degree .... I've seen so many wheels reinvented, or problems misdiagnosed or not even seen that a band aid is applied (i.e. accruing technical debt) that it's shocking.

We need to do better, and to do so, we need to be better ........ we also have to prove why we should be building quality then speed, any by proof. That being quality software that you can build on opposed to spending the future "fixing". Self discipline comes into this as well - as does our professional approach - as that quality will make it's way into the project and software.

I'm not arguing for over engineering or huge out of control development cycles, quite the opposite. The main outcome of building quality software that I've seen is the (accelerating) speed at which new development can be performed. When you are spending 90% of your time build and 10% fixing well isolated and architecturally designed systems (and not the other way around), you build quality and faster.

Fourth would be process. There is a huge amount of knowledge and experience available on how to "do it", as with design patterns and code, it is with buisness and teams, don't reinvent the wheel. I see 37 signals selling books that people call revolutionary thinking ..... alas Tom DeMarco explained most of it decades ago in Peopleware. A lot of project measurements are quite out of date as it is, and the organisation as a whole has a responsibility to focusing on learning and self improvement, as much as the individual.

It's this thought to building quality foundations that agile usually throws out the window, much like the short term view of finance the western world has taken over the last 30 odd years ....... and how did that turn out.

----

So ultimately - quality leads to, more speed & less haste. Don't take your time but use your time wisely to build something of quality that is fit for purpose.













Sunday, November 28, 2010

Top 10 improvements for PHP developers

Craig Buckler's post over on sitepoint.com : Top 10 MySQL Mistakes Made By PHP Developers got me thinking. Are they really mistakes, and are the answers giving people all the options, or is there more that can be added?

So this post is and extension and part reply to that blog post.

Maybe the 10 points are just things we can improve on, in various ways depending on what it is we're doing. Or is it just shifting processing & logic from one area to another.

My caveat would be - that if every beginning PHP dev read the 10 points in Craig's blog and learnt; the dev world would be a better place. I'm thinking beyond the original points.

I'll just mirror the 10 points he makes, to give my 2c to the discussion :


1. Using MyISAM rather than InnoDB

I mostly agree with the premise of "Oh just use InnoDB", given what Facebook are doing with it, and the level of active development going on, it's a safe bet at the moment.

Though technically it's not a database engine, that's MySQL, it's a storage engine that's being talked about, and there a few of them, not just two.

There are a few out there. Just reading though a list to see what they are built for, and why, has to be a good idea (even if you just default back to InnoDB).

Reading about the current developments and options out there is always a good idea.

Given your designing a data store, how are you going to use the data? What is the use pattern, is it just an archive or an in memory look up, or something in between?

Why use just one? Can you log to one database using one storage engine and use the other for live data (data relations allowing).

Also given that Oracle owns MySQL now, is what you're doing compatible with other options like MariaDB if you have to move ?

What about using XtraDB or PBXT ?

Do you need full text search (supported in MyISAM) or can you use Sphinx or Lucene ?

Sure, for ~95% of people (including most of the things I'm doing now) InnoDB is fine, though keeping up with what is going on and making informed choices about technology is no bad thing.

Remember the main reasons for InnoDB over MyISAM, is row level locking and transactions. Choose data integrity over speed, and the speed argument has mostly gone away now anyway.

2. Using PHP's MySQL functions

I think this is assuming that you're putting SQL directly into your logic, i.e. Controller in the world of MVC. Yes, you should use the mysqli functions and weigh the costs of PDO and prepared statements

This also comes back to the idea of "where is the logic" in this  system, which I'll really go into in point 5.

Suffice to say, if you have PHP on one level (business logic) producing functionality, and MySQL on another level (data store) providing more functionality; can they both scale to meet each others needs ?

You can tune MySQL to some insane numbers, especially when you're on version 5.5 with lots of cores and against SSD like Fusion-I/O ...... though you can keep putting in web servers till you saturate the network with PHP.

Also, this all predisposes, you're running against one database, or even a master-slave pair for some kind of redundancy, or read-write balancing.

If we put aside the scaling of databases issue for a moment, and just be mindful of :
  • web servers running well encapsulated code = cheap & easy
  • scaling databases = not so cheap & a pain
The more you can get the dumb web servers to do, and take load of the database, the better. Just have a load balanced web farm and chuck more servers in it, or "use the cloud" etc.


3. Not sanitizing user input

Agree 100%, a no-brainer, and it should be point #1. When we built vBulletin 3 we enforced a single point of access for all user data, the $vbulletin->GPC array.

A single point of getting the incoming data, which was cleaned and checked, the gatekeeper as it were.

Personally I assume every piece of data coming in is malicious and the user is trying to break the system ........ does wonders for the stability of the code I write, though not so much for my trust in people and faith in humanity ........


4. Not using UTF-8

Again agree 100%.

Two things I would add are :

1) Ensuring you know what UTF-8 is, and why it's a good thing

http://en.wikipedia.org/wiki/UTF-8

2) The difference between the collation types of tables and their uses

http://stackoverflow.com/questions/2344118/utf-8-general-bin-unicode


5. Favouring PHP over SQL

Now this is where I disagree ......... a lot.

But not with the "don't do SQL in loops, and write good SQL" that's another no-brainer.

I cringe when I see SQL loops .... as I did on a recent project,it must be the digital equivalent of S&M with MySQL in a gimp suit and PHP with a riding crop ...... though I digress.


I'll use two (of many) examples, as to why "PHP over SQL".

1) Architecture, scaling and system design.

Firstly you are splitting the logic between SQL and PHP as to what is making the decisions with your data, what happens if you have to move away from SQL?

I'm not siding with the NoSQL gang and just looking for excuses, I'm ensuring that I'm giving myself choices and using a database as a data store first.

You can doing averaging in PHP near as well as you can in MySQL AVG() with good data structures.

Also you can point a fair few of web servers at one default set up database, but you can point a LOT of web servers at a very well tuned database when the PHP is doing more of the grunt work.

So more over all "work" is done, and it gives you more room before MySQL bottlenecks.

2) Using time - NOW().

When you have more machines and the system grows, PHP and MySQL are going to be using different system clocks for time() and NOW(). If any of these get out of sync, which time is correct ?

What happens if the data store (for writes) is on the end of a queue, i.e. JMS or WebSphere MQ, the time the data is processed is important, not when it's written.

Also if there are multiples of the same data with different time stamps, you can process them in order or enforce a kind of vector locking if needed.

Personally I usually store times as epoch and do any time calculations in PHP to make it easier, selecting on INT opposed to DATE. The actual year, month, day can be denormalised into columns if really necessary.

(An upcoming blog post about reporting on a shoe string does that)


6. Not optimizing your queries

Yes another good one, though a lot of over lap with #5.

Having very complicated SQL also supports my argument from #5, just don't do it.

Get the data in and out as fast and cleanly as possible, and do the rest in PHP.

If you're tying up your database with queries because you've tried to be "too clever" or were "showing off with your l33t SQL skillz" then next time have a think about clean software architecture, and what is workable and maintainable.

A short while ago I worked on a project with the worst SQL I've ever seen, even. Even an ex MySQL-AB consultant called it "A master piece ....... but from the dark side, they couldn't of made this worse if they tried; I don't think I could".

One of my favourite quotes.

I guess the original developers thought they were being rather cool and snazzy at the time, or more likely that it was a road crash of a development journey.

Though if it wasn't for some late nights be me and the gang, and throwing a lot of hardware at the problem (while we re-engineered it on the fly), it would of ended the project.

So bad SQL can be really bad.

15 way JOINs and 10 inner SELECTs means you have something wrong, not that you're doing well .........


7. Using the wrong data types

The opposite of what is said in the original supports what I'm saying, yes make MySQL a dumb data store if that is easier.


There are temptations to store INT for epoch as well as DATE or denormalized day, month, year INTs, though unless you're sure the data never changes or isn't supposed to, be very wary of this.

Again it's about where are you performing the logic. You can put a lot of the logic of what you assume or would of done in SQL, into a decent data layer written in PHP itself. i.e the Model in MVC.

Also writing up a decent data layer (access layer, abstraction, etc) or using an existing one, adds the ability to put in caching.

In a recent game back end I wrote, there are 9 SQL selects when the game stars and 2 each time a player turns up, and that's it. After that it's all INSERT and UPDATE, because of memcache.

Baring memcache going down (then the data layer just fails over to the database ..... and you're back to the PHP on MySQL S&M abuse scenario ! .......) or a restart all reads should be dealt with by cache.

Even if your data is on SSD not disk, there is no need for it (for reads that is, I understand the need for persistence in storage !).


8. Using * in SELECT queries

Very much so, I'd fire people for less .........


9. Under or over Indexing

This very much is relative to the app and how the data is used, though yes it is a balancing act. This takes time and reviewing the data use pattern, slow query log etc.

It can also be something of a dark art, and you can take a lot of time reading up on key buffer sizes and how they effect your query speed.

Though one good thing to think about for general learning, is index only scans.

Here is some reading from the world of PostgreSQL  :

http://rhaas.blogspot.com/2010/11/index-only-scans.html

Talk from the MySQL world :

http://mysqlha.blogspot.com/2010/11/how-are-index-only-scans-implemented-in.html


10. Forgetting to backup

Once again I disagree ....... not with backups, they are vital. Because they are needed for the one thing that I do advocate that is what is really important ........ proven restores!

--------------

Another top 10 list for programmers, that I like :


http://www.techradar.com/news/software/applications/10-mistakes-every-programmer-makes-909424

 --------------

As ever take care and think of what you're doing and why, not only how.

@JeremyHutchings

Saturday, November 27, 2010

Agile Agnostic : Which development method to use

I've been asked various questions lately that all could be summarised as :
  • "What do you prefer, waterfall or agile development, which is best ?"
I find these questions much the same as asking the length of a piece of string, or what does the colour blue taste like.

Nonsensical and out of context for the most part.


Firstly a development method, is just that, a method, a process, an organisational tool. And just like any tool there are suitable and unsuitable places, and ways of using it.

Using chisels as screwdrivers spring to mind.

Agile (or any other) method isn't a silver bullet to cure all software ills, or by any means a "radical" new way of doing things that will cure all bugs.

I think there are lots of different aspects to think about before answering the original question, though I'll go over the following ones.


Company culture & history

How does the organisation currently produce software, does it even do that in house ? Assuming there is a development team in house, what are the current methods being used ?

What are the discipline levels with the current development, how is version control, build management, documentation,target dates, etc all handled ?

Altering the way in which software is created within itself is going to involve being very aware of what is going on, what you are changing and why.

I was recently asked in an interview about my thoughts and experience with CMM (along with ITIL, which I hadn't heard of until then).

I answered along the lines of : CMM is typically seen as a heavy weight out of date system from the world of old school dev. Though it has a very valid premis which I like a lot :

  • You have to know where you are to know how to get to where you want to go.
It's the same as the difference between speed and velocity, velocity has a known direction.

So before changing or "improving" the current way of doing things, you must first know where you are. Even if that is CMM level -2 !


Team dynamics

Given that a development method is a process, it's a guide and limit to human behaviour. How is the team going to react to that ?

Sure you can take the stance of "You're paid to do as you're told, get on with it", though this isn't the military, and I tend to have more respect for people than that.

If you are attempting to improve something, in this case the out come of development, you should know what you're after. Be that :
  • Speed of development
  • Uniformity of work
  • Less bugs
  • Faster release cycle
Or more typically, a combination of the above.

For a method to be successful you have to state what you think it should achieve so you know if you're getting what you're after.

I've seen several teams where a certain method was introduced and things (i.e. quality) got very obviously worse.

So if you can identify what it is trying to be achieved, and then share that with the team, it will be much easier.

Identifying issues with the current process and not the people, while focusing everyone on a different outcome via a "better way" I've found gets much more support.

A shared vision and understanding of why there is change is far more likely to be adopted and succeed, than a dictatorial approach to "fixing people's mistakes".




Skills and experience of facilitators

Managing change in itself is a massive topic, just google "managing change"....

Tough attempting to influence a group of people to change their behaviour is no easy task. The all too familiar style of management will just "lay down the law", though this has a few main side effects :

  • Resentment
  • Short term wins over long term gains
  • No stickiness of change (once the influence is gone, the system reverts)
Knowledge of the method is just one part, self-awareness and knowledge of team dynamics is likely more important.

What to do with conflict, resistance, apathy ? Far more important than getting a time estimate on a chunk of work, or drawing a shiny new graph for "senior management".

Also talking of senior management, do they assume that agile means they get to change their mind completely every sprint without consequences ?



Architecture & Design

Basically, does the method take it into account ? My main criticism of agile (used in ignorance) is that upfront design and defining a starting point is avoided, as it doesn't seem "agile".

Then with a constant focus on the minutia of the code (i.e. what's happening in the next X weeks/days), architecture goes out the window. Typically followed by technical strategic planning, it's as if there is a rush from one end of a polarized spectrum to the other.

No method I've used or researched actually advocates that, though I've seen it assumed in practice and the rush to skip it very evident.

There is a caveat here though - some accomplished and experienced developers can typically go straight from mind concept to code within an architecture naturally. Though they are typically the top % of what they do and they are working on their own or with another (XP style).

The context I'm talking about is development groups within a business.

I've been in sunk-works environments where you are allowed/expected to do this at work, though it's sinfully rare.


My Answer

As it's just a tool, it all depends on the job at hand.

Though typically I find the best outcomes come from a blend of both. Take some of the initial aspects of waterfall to lay the foundations & vision of the project, identify the stakeholders and gather initial requirements.

Then move into wire-framing, investigate different technology, ensure the whole team has involvement and input from day one.

While all the pieces are coming together the call has to be made for "this is good enough", being that the picture is clear enough to begin the build. This is where the process typically turns into what most people think agile is.



Conclusion

I believe being wholly evangelical about a tool, be that a agile method, Ruby on Rail, Drupal, etc ......... or anything, compromises a project. you can't be objective if you believe there is one (and the same) answer for everything all the time.

The most adaptable and successful systems I've observed are typically blends, show flexibility, and are focused on getting the job done, not being right all the time!

@JeremyHutchings

Friday, November 5, 2010

Interviewing & Dating for the Techie : Playing the game

I’ve seen quite a few posts recently about interviewing, hiring & job hunting in IT, so I thought I’d share my views.

There seems to be quite a divide between companies that think they are the best, want to be, and ones that actually are. The latter are fun, passionate, free flowing places where everyone wants to work. The former seem to just pay lip service to the idea, while demanding their (actual and potential) employees pick up the slack of the organisation.

At least the ones wanting to be, know where they are, and are trying!

The flip side is there are a lot of job hunters, who aren’t realistic about their own abilities, or who haven’t really thought about what they are after.

I’ve been the interviewee and the interviewer a few times over my career, so like a lot of us I have dealt with both sides of the coin. A lot of time is spent sorting the suitable people from the unsuitable people. Just as there is sorting suitable organisations from unsuitable. I know how tiring and frustrating it is for both sides.

It cuts both ways for people, and organisations. Try to know where you really are on your side of the fence, when it comes to what you have to offer and what you can realistically partner with.

I liken it to dating as there are some fun analogies, as well as a lot of similarities. There is a good reason for that, because it's all about looking for, and starting healthy relationships with suitable people.

Personally I’m either hiring for, or negotiating contracts. So it’s a combined issue for me, as I’m in either one of the roles at various point in time. Either having the power, or doing the chasing. Or as well see, just assuming it's that way.

[analogy time] Depending on your cultural & social context, there is usually a pursuer and the pursued in typical dating...[/analogy time]

So what is the frustration both sides experience, and what can we do about it ?


What’s being looked for - All that glitters is not gold


What constitutes a suitable employee (I’ll talk about a company later) might be wholly technical, (as appears to be primarily for rethinkDB) though it’s always what is relevant. If you are hiring a C/C++/etc coder (or call yourself one) you sure as hell should be able to (create then) reverse a linked list in code in an interview, and get most of the code right.

That is  suitable to them, I’m sure they look at other areas (it’s just and example).

I know some excellent problem solvers, who could solve the problem in PHP. They  would use an array and a combination of array_push(), array_pop(), array_slice(), etc and foreach() for traversal. Though would figure out the syntax over time in C for the logic they know, if they had to.

[aside] Also, they would likely develop it much faster in PHP, it would be easier to read, support and understand, Though I digress into the “bigger picture” of what makes a software engineer and team member, over a hacker/coder/etc........ [/aside]

I’d do it in PHP or Java myself, though it’s what's is relevant & suitable.

What is relevant to people and organisations? What working challenges and environment is an individual looking for? What is an organisation looking to solve or get done, and in what manner?

I’m far more interested in getting the job done well. So when interviewing I’m assessing someone's ability to think about what the actual problem is, and what are the different approaches are. I don’t want to limit how they do it with leading questions, I want to see them in action being creative. So what if they don't have the specific skills now, if they are the right people they will learn them.

And being able to offer that learning is valuable, I'll take knowledge over money (sure once I have the bills paid !).

I’ve tripped up lots of people in interviews with questions that (most, I think) in any normal situation would of likely figure out. I think these kind of “solve-everything-in-5-mins” problems under pressure, has a lot more to do with the interviewers ego and bad technique. They have little to do with finding good problem solvers, who can develop solutions.

Doing this is much like asking on a date “So why are you better than my ex they were perfect and could do everything perfectly. Now explain to me why you’re perfect as well, while I judge you in a narrow way, opposed to learn about you”

I’ve been guilty of it, and I’ve experienced it in interviews with people who know no better, at least now I can see it for what it is.

There is a balance between skills in the work place, and more importantly in teams. Personally I rate the ability to communicate (ideas, questions, learning, etc) and the desire to learn very highly.

As with rock stars vs rock solid programmers what's the point of having an “uber l33t” coder who dose nothing but destroy the team, and therefore the product ...... and all because they can code a simple problem in 4 minutes, opposed to 8. You’ll get your Ning re-invent-the-wheel problem sorted out in record time. Though can that person communicate it, and then help the team learn and grow? Let alone have they ever looked after such a system in operations, or documented it for others that don’t speak regex naturally.

[aside] There is a lot to be said for putting developers on support to learn, before working on the code & systems. At vBulletin the original developers (including me) all did support, to keep us close to the customers and daily issues.[/aside]

As for a programmers who actually have a (holistic) systems view of what they are doing, opposed to myopic (albeit good) view of what they are doing in an IDE is worth an awful lot. It’s about multi functioning teams and well rounded people to me, I’ll take a slight hit on the technical front for someone who knows how the world works, and loves to learn about it.


Employees - Flirting with companies and measuring potential


Do you know what your goals are? Obvious answer #1 for a lot of people is “get a  job/contract and earn some money”.

Though that is the outcome, how about :

  • What does that job entail : more of the same and safe, or trying something new
  • What is the environment like : noisy office for 8 hours, or some flexible telecommuting
  • What is the reward associated with it (and why) : being realistic, and money is one part
  • What is the team like (personally I don’t like to work with people I can’t have a beer with)


So figure out what it is you want. Better to have a good idea and stick to it, as you don’t want to find out X months in that you’ve “just figured out” you want to telecommute 50% of the time.

[analogy time] You wanted a relationship with someone who you could travel with, and ended up dating a stay-at-home person[/analogy time]

So you’ve figured out what you want, though what about what you can offer?

Good relationships are all about give and take, in balance. Are you average (bad and relative term, I know) in the areas you like to work in, though you’re trying to get into top end teams. Confused and angry when getting turned down?

[analogy time]Constantly hitting on the super model with a PhD, who teaches the Dalai Lama how to be chilled, and getting turned down?[/analogy time]

When evaluating an employer position :

  • What are they really offering
  • What potential do they have
  • Where could you go with them
  • Do they really do what you want
  • Can you see yourself happy there
  • Remember, you are interviewing them as well


To expand on the last point. I’ve seen people overwhelmed in interviews, people either nervous or desperate for a job (and I sympathise with people experiencing hard times and need to pay bills).

Though remember this is how you appear to someone on your first meeting, and they are initially (consciously or not) assessing you on behaviour, more than your C.V./Resume.

[analogy time]Oh I met someone last night and they seemed so needy, they would be a total drain on me, not calling that one back![/analogy time]

vs.

[analogy time] Wow, they were so calm and confident without being pushy or arrogant, was interested in my and left me wanting to know more, I can’t wait to meet again [/analogy time]

Personally I used to be horrendous in interviews, due to seeing them the wrong way and thinking it was all on me. Then I built up some self-confidence, and realised I’m interviewing them as well. They are the ones who need things done, and I’m the one who can do them.

That and no one is perfect all the time, so don’t try to be, you'll fail. Admit your mistakes and explain what you learned. Say when you don’t know something, but explain how you would figure it out, or find out.

If you are genuine and it doesn't work out, at least you know it wasn’t for you.



Employers - Attracting, filtering and being honest


If you want happy, dynamic, creative and over all highly productive people, guess what, you have to know how to facilitate that, and have it as part of the DNA of your organisation.

You want X, you have to be X.

Good people know what they are worth and what value they have to organisations, you are being interviewed as well. Being abusive in interviews will get you people who are attracted to abusive relationships, i.e. the kind that are dysfunctional themselves (I’ve learnt enough about that training in counselling to see it in interviews):

  • "You have to own everything, even stuff you didn’t code”
  • “You will be happy for me to call you any time of the day because I want something done”
  • “If you’re hard enough to run with the dogs, I *might* throw you a bone”
  • “So what if you miss your anniversary, you’ll have more”


Also, what are you doing only advertising for people on Craigslist and expecting the best to throw themselves at your feet? You want open source contributes, and flexible people, how flexible are you, and how does your organisation support open source ?

If you have good people, then tend to know other good people as well. Though it’s not worth relying on just that wholly, or just recruiters, or just any one thing.

[analogy time] Standing and the bar looking down your nose at all the “potentials” who aren’t good enough for you, expecting them to come running and beg for your attention? [/analogy time]

How many people have snapped out of it, I woke up and thought : “Hang on, this is about more than money for me, I’m not going to take this **** any more”.

Good organisations & people know this, and look at themselves before others, first. Self awareness is key, be that with individuals or organisations. Especially when getting into relationships with others, know who you are and then be honest about it, it saves a lot of time and grief.

It’s starts before the interview, as it’s about the personality and culture of the organisation and what they do. Are they portraying that honestly and properly? I once heard “if you are going to be buff, be naked” sounds good to me.

[analogy time] Hmmm, no ...... I think I’ll leave this one ![/analogy time]

Get involved with the local developer community, and the good ones who are aware of themselves and organisations will find you out. Be open to good people, not limited rigid skill set list.

Do great people meet all the time and have healthy relationships, in sleazy pick up bars with one side being condescending to the other. Or do they more often meeting doing things they both love and share?

Don’t just put lists of arbitrary requirements on your web site that don’t really have a bearing on finding good problem solvers, you’re just copying the people you already have. There is a company here in Vancouver, that just list a huge range of Java technologies and says you must have 7 years in all of them (without exception) to even talk to them. I dare say they get what they ask for ....... narrowness. Suitable to them, maybe yes, though understanding how to find good people and attract developers, defiantly not.

[analogy time] You *must* be 6’5”, have {these} dimensions, blue eyes, and drive this type of car.[/analogy time]

[aside] I could be up to speed on what they do in a few months or so I’d think, I love playing with Java. Though wouldn’t bother to deal with them because of how they portray themselves. [/aside]

So you’ve finally met for the first date ....... err interview. Now given that I’m talking about technical people there is an element of assessing suitability the job, or course. Do they have enough knowledge of the domain you work in? What is their current skill set?

Both are valid, though not the whole picture.

You are not going to keep someone who is naturally creative and who loves to learn, by getting them to do what they have already done a hundred times. You will keep them (engaged) by allowing them to grow, and supporting them in the new role.

Interview for future potential, not just current limits. If you don’t, you are limiting both of you from the outset. You will loose the good people, as they will get frustrated. So think about their future as well as the organisations when talking.

[analogy time] Sit on the couch every night watching re-runs when you’re partner wants to go dancing (or do anything fun) for too long and see what happens ......[/analogy time]

Just as the individuals have to be honest about where they are and what they offer, so do the organisations. Or the frustration of the miss-match will separate the two, once the illusion is up.

Don’t bother to ask contrived questions in an interview either. Or ones where you are looking for a specific answer, as you are just limiting everyone from the outset again. Make it relevant to what you do, then you’ll actually get an answer that will gauge their passion of the topic.

Passion can be positive or negative, as long as it’s there. Apathy is something I avoid. I can talk about event driven systems, OO, state based machines, brewing beer, caches, network latency and how to scale things till the cows come home. On the flip side I can tear a certain CMS that is commonly misused, apart, all day and back it up as to why.

If a person can’t get excited about a topic that is core and relevant to the company then it’s a warning flag. Even if they can’t explain the exact details there and then, given passion they’ll put in the hours to learn. It’s the mindset it’s the passion, if they don’t have it move on.

[analogy time] Hey, do you like sailing, it’s really important to me, what do you think? ....... Meh, it’s OK I suppose, boats and things.[/analogy time]

Also if it took your organisation a team and weeks to figure out a suitable answer to a question you are asking in an interview, don’t expect a perfect one in 5 minuets in an interview situation.  It’s about how the persons mind works, how they explore and work though issues, not the specific thing you ask them. Also if they falter and then you give your answer expecting them to say it’s brilliant, so you feel good, it’s a fair sign you’re there for your ego, not to interview properly.

Three final easy points :

  • Have a process and explain it up front, and explain what and why
  • Always contact people you’re talking to let them know if it’s a no, it’s called courtesy
  • Don’t do the talking, let them

While I agree with most of points Joel makes, I think he is missing the point about what is relevant today for most people. Not 10-15 years ago when everyone had to learn C to accomplish anything,  and some people laughed at Java in it’s infancy. That is wholly focusing on implementation of logic. I look for the understanding of logic itself, and how it is applied and used in real world contexts. A programming language (mostly) is just a tool, solving the riddle is the prize.

I do it in PHP, you do it in ASP; meh, we both go to the bar !

I appreciate the power that comes from understanding how everything works down to the CPU and assembler level, as I studied it throughout my life since I was 9, and at university for years. Though I don’t expect every developer to know all of it, all of the time.

We (developers) tend to get rather good at what we do in the moment, I might not know Erlang now, though give me a challenge and some time.  It’s the ability to learn and adapt to get a problem solved, that I look for.

[aside] Though as with all things, that we (bloggers) see subjects from a different point of view is good, it should ideally make us all better![/aside]

One point of rethinkDB’s that I do disagree with, is that unless a candidate is intimidating, they are worthless. Utter nonsense and smacks wholly of a ego driven development & environment to me.

Overwhelmingly impressed by someone yes, intimidated no.

If you are taking your ego into an interview and feeling intimidated, or someone is using that technique in an interview, something is wrong.

It’s about exploring and learning about each other, not trying to over power each other.

Do you really want that same person in the office every day explaining to the rest of the team why their Kung Foo is so weak and how they should all bow down? ....... you might, though that’s no place I, or anyone I know who is any good would want to work.

I’ll take strength in quite confidence, over arrogance any day.

Aaron Swartz seems to understand what’s important, and has some good ideas on the matter.


Together


A good thing to remember is that “best” isn’t always “highest profile company” or “most money”.

Best is about the match between the person and the organisation, and the team within it , that they are working with.


End Points


Interviews (and dates usually for that matter) are usually uncomfortable for at least one side, and a lot of great people don’t perform well under that kind of pressure. I remember my early years of dating & interviewing ....... harrowing! So trying to bully a interviewee or BS a interviewer isn’t going to do either side any favours.

Though if the meeting can get onto something that one or both parties are passionate about, then all the better. That is for the interviewer to try and make happen.

I agree a lot with Andrew over on Supercoders.com.au, passion is massively important, I’d never want to be in a relationship with out it, personal or professional. To be self actualizing and a developer that gets into Flow/The Zone/Hack mode often, you have to be authentic and present in what you are doing.

You can’t fake the funk, as the saying goes.

Though I do have to watch so I don't get consumed by it. When I’m not in a healthy relationship, employees (and bad partners) are very prone to exploiting it when it’s one way.

Make sure things progress at a suitable pace.

Also passion is something you have to keep alive and grow together with, keep up the challenges, finding new heights and making sure both sides are getting their needs met.

On that note, may you all live happily ever after !

---
Till next time, take care of yourselves
@JeremyHutchings