Refactored scope

I am taking a break from the server code to give me sometime to think about how I want to resolve some of the issues that Rob N. @ Bivio software pointed out to me. In the interim, I’ve moved back to the making games theme.
(continue reading…)

I’ve been busy with professional contractination work, which is a word I just made up to describe the chaos that goes on while being vetted for a new client. “Do you know PHP5?”, “What is class inheritence?”, “What’s the difference between include and require?”, etc. I wish I could make a indexed video of me answering these questions but I don’t think that would work for some reason. Still its just par for the course and I really don’t blame the client or the client’s gatekeeper asking because I’ve been on the other side of the fence, vetting out people and its a miserable task.

My resume shows 5 years of contract work and I’ve got half a dozen references ranging from developer peer’s to team managers and c-letter people…but from what I’ve seen none of that matters. Out of respect for all involved, I won’t be mentioning names, employer, or anything specific. Last thing I want is to kill someone’s career or tarnish a client’s reputation. That said, I’ve seen some pretty terrible “Senior” developers. What I mean by terrible has little to do with how they solve problems, but the fact that they don’t solve problems.

One recent case, I worked with a “Sr.” developer that proclaimed themselves “Team lead”, “Chief Architect”, and “Dev. manager” which was surprising because I finished three different projects on time and tested for production use in the time that this individual struggled with one project. Speaking to the CTO of the company I got to look at the person’s resume and it all made sense. They had been in the industry for 4-5 years as well, but 3 and a half of those years was as a “junior” developer in a fairly large team. Then they jumped or got booted and fell into my client’s company and became the defacto “Senior” developer because there was no one else. I think two things fed this person’s loose grip on their reality. In very large company’s, I’ve noticed that junior developers are not to be seen or heard and instead are programmers. They aren’t given opportunities to grow through mistakes and failures because that’s not what they are there for. Then the other side is that without peer review from competent peers… its easy to imagine your poop smells like roses.

Another case was a peer that got signed to the same company as me, both as contract to hire. One unique thing about this situation was that I knew NOTHING about the language or technology being used. The only saving grace is that the team leads had re-implemented a better/saner version of a framework pattern I had designed a few years ago. So of course I struggled in the first week and somewhat into the second week, but fortunately the language in use was imperative object oriented so everything eventually clicked for me. I won’t lie and say I was a super star, but I did my best to pull the line and help the team meet its goals. Meanwhile the other contract made a lot of mistakes: it’s generally a bad thing to hit on the female staff at work, if the product lead takes the time out to give you advice… its probably cause your fucking up, and lastly do not alienate your peers. Healthy dev. teams are like Survivor… if you become the weakest link and cause others to work harder to cover your ass, you will find yourself out of a job.

What I am getting at is that, in both cases it would be tough to figure out if someone can actually do the work needed for an employer. Their resume might look amazing or their credentials impeccable, but neither really mean much. The subject of vetting out good candidates has been covered over and over across the web and print…so I will keep my advice simple. If you have a small team or no team, go with established recruiting firms that will incur penalties to themselves if they recommend a dud ( generally 5-10 business days covered ) or if you do have a team, get them involved in the last stage interviews and see if this person fits in. I am sorry, I know this would seem to eliminate anyone who has text anxiety or social disorders… but time after time Geeks & Nerds recognize their own.

I freely admit I am probably over thinking the problem for the moment, but there is some doubts that maybe I am not. The problem is my concern of overloading Pymetheus with non-command & control messages, specifically low priority stuff like a chat scenario between user A & B. A types “Hey B, how’s it going?” which currently would need to descend down to a chat handler, run through some sort of sanitizer, then interface to auth.realm.UserRegistry to find the specific user, and then push a message to this person.

Its not really so bad to do this and in a lot of ways, it makes sense. All the information and constructs to accomplish the task is there, but it would need to be immediately refactor’d out at the first opportunity for one single reason: scalability. If Pymetheus suddenly starts taking on more and more trivial tasks, one day I am going to wake up and have this monolithic super process that does everything and has a memory profile similar to a swamp.

The ideal solution in my mind is:
User A & B connects and should be granted Chat privileges, accounts are created or activated on a xmmp server alongside pymetheus which returns connection credentials to Pymetheus which passes this back to each User. A & B now connect to the xmpp server and can chat away to their hearts content. Alongside some of the weirder xmmp sub-protocols this solves a whole slew of things that must be implemented ( presence, offline messaging, event notification, etc ).