September 05, 2016 11:39 +0000  |  Employment Job Hunting 3

I suppose you could say that the process started years ago when I mused about applying to Mozilla. I was living in Amsterdam at that point and wanted a job where I could go into the office and have lunch with coworkers etc. so despite Andy's encouragement, I decided not to apply for a developer position there.

Years later another position opened up just as I was about to move to London, so I applied, got through a few rounds of interviews and then the position evaporated, changing to a junior-level role instead.

Later still another job opened for a developer tools role. I applied to that and ran aground on their new "HackerRank" coding test. These tests are terrible, but that's a rant for another time. Regardless, I bombed out on that application too.

Then a few months ago, Stephanie sent me a message telling me that her team had an opening for a senior Python developer. I applied not long after the role appeared on the site, along with Stephanie's recommendation. This time, I've managed to graduate past the terrible HackerRank test, and through all four rounds of interviews.

As I understand it, the verdict is supposed to come down tomorrow and I'm facing off against two other potentials. The anxiety around this whole thing is surprisingly crippling: this isn't just a job, it's Mozilla, the Good guys, a big important company that's on the front lines in the fight for the Open Web. I don't think I've ever wanted any job more than I want this one.

It's a long weekend in Canada & the US, so they won't be getting back to me 'till Tuesday, which means sometime between 8pm and 5am London time. I may not know anything until I wake up and check my phone on Wednesday morning. That's my last day at my current job (Cyan) for this week, since I took two days off to pack for our move to Cambridge, so this Wednesday is going to be messy, regardless of the Mozilla decision.


Well I didn't get it. The main guy over there had some very nice things to say about me in the "we don't want you" email, but the reality is that I will not be working for the Good Guys this time around either :-(

March 04, 2015 13:58 +0000  |  Employment Ripe NCC 0

My boss just sent this to me:

[List of Employee names and Me],

As agreed verbally, I'm requesting you to work on the weekend of 28-29 March, in order to attend the RIPE Atlas Hackaton. Your attendance at the evening socials is optional (and not recognised as extra hours).

According to the HR policy [link to policy on our intranet], you're entitled to compensation for this. Please let HR know if you prefer monetary or VAC days.

Cheers, [Boss' Name]

"Welcome to Europe" he said jokingly.

I just wanted to post this to stand in sharp contrast to how companies tend to work in Canada, ie:

You're working this weekend. No we're not paying you for it. If you're not ok with this, you're replaceable.

Back home, there's a lot of talk about "Work/life balance", but employers here actually understand what that means and practise it.

January 22, 2014 17:46 +0000  |  Employment Software Web Development 0

Every once in a while I hear people speaking with authority about what exactly agile software development is, and the funny thing is, they usually conflict with other statements with similar authority about agile. Often, this is coupled with negative comments about how agile is impractical because X, which is frustrating, because some of my most productive years were spent in a fully agile office environment.

So I thought that I'd write something about agile as well, if for no other reason than to hopefully point people in the direction of what I know to be a very efficient and practical means of getting stuff done. I don't want to claim that this is the One True Way of agile development though, as I'm not interested in having the kind of conversation where we re-classify everything for the sake of giving it a name. My team lead at the time, Mike Gauthier called this system agile, and that's good enough for me.

Talk Less, Code More

The goal behind agile is to have developers spend time doing what they love: rolling code, and to keep them out of meetings they want no part of to begin with. Instead developers have only 3 responsibilities over and above writing code throughout the sprint. I'll cover these in more detail below:

  • A Morning stand up meeting: Every day, 10min
  • Sprint meeting: 1hr
    • 30min to recap the last sprint
    • 30min to prepare the next one
  • Any additional initiative taken to talk to the client about what they want

Note what isn't in that list:

  • Requirements meetings
  • Proposals
  • Logging hours
  • Documentation

The idea behind agile is essentially: "Here's a task, go!". The key to making this work is to keep the tasks simple and concise, so that the result of the sprint is incremental. Read: easy to deploy, with no surprises.

The rapid pace of an agile project means that the usual slow processes of planning meetings and wiki documentation becomes an exercise in futility: the job is done before it's planned, and it's changed not long after it's documented.

Stand Up

It sounds like a pointless process, but it's probably the most powerful part of an agile system. The morning "stand up" meeting, or "scrum" is exactly what it sounds like: the entire team stands up in a corner of the room to answer 3 questions each:

  1. What'd you do yesterday?
  2. What're you expecting to do today?
  3. What happened yesterday that prevented you from doing what you needed to do?

Each developer should talk for no more than a few minutes, answering these questions point blank. It's the opportunity for the team lead to address whatever problems were mentioned (after the meeting), and for other developers to find out that their colleagues are waiting for them to finish something.

Note that this meeting is not for design discussions, or gripes etc. Rather, the purpose is to be a quick update on what's going on -- which is why you're supposed to stand up through the whole thing. The minute someone starts to look like they need to sit, that's your cue that the meeting has gone on too long.


Think of sprints as a deploy schedule, but short and seemingly insignificant in what they produce. While a typical software deploy schedule may last months or even years, consisting of massive upgrade paths and a long complex list of changes, sprints are typically 1-2 weeks long. You write the code, and it's live in a few days.

The big difference from other methods is that sprints are incremental, so while new features roll out bit by bit, bugs are fixed weekly with no having to maintain multiple branches for extended intervals.

Keeping the sprint short ensures 4 things:

  • The tasks are always short-term and easy to comprehend both for developers and clients
  • Clients see progress on a regular, predictable schedule
  • Releases are predictable, and easy to break new features into
  • Your team has a concrete and easy to understand goal to work toward

Code Debt

But what about those elaborate project charts with tasks designated to different developers, all colour coded by week, accounting for availability?

Gone. All of it. Throw it out. You now have a binder full of post-its, or if you're feeling all 21st century about it, a Jira task list. This bundle of tasks is your code debt and should not be organised as priorities are expected to change from sprint to sprint. At most the PM should keep a loose tally of priorities, so as to make the sprint planning meetings go smoother.

Chipping Away at that Debt

At the start of every sprint, you hold a meeting in which the project manager talks to the developers about what's most pressing in terms of bug fixes and new features. Importantly, this is a two-way conversation: the PM representing the needs of the client, and the developers representing their own limitations and the quality/maintainability of the code.

This sprint planning meeting is where you take stuff out of your code debt, break it into bite-sized chunks, and assign it to the current sprint. You need to keep the tasks small and easy to achieve in < 4hours. If it takes longer than that, it needs to be broken down. This has a couple big benefits:

  • Big jobs can be spread around, potentially finishing them faster
  • Knowledge sharing is easier as everyone has the opportunity to work on smaller portions of a greater whole.
  • It's an easy way to make big jobs suddenly feel possible.
  • Finishing a task results in a sense of accomplishment for the developers
  • Incremental change gives the client a sense that something is being done

No Ticket, No Work

Now that your sprint planning meeting has broken up a portion of your code debt into tasks, the team is presented with a white board with a simple grid layout:

|  Todo  |  Developers  |  Working  |  Finished  |  QA Complete  |
|        |  Daniel      |           |            |               |
|        +--------------+-----------+------------+---------------+
|        |  Aileen      |           |            |               |
|        +--------------+-----------+------------+---------------+
|        |  Charlie     |           |            |               |
|        +--------------+-----------+------------+---------------+
|        |  Aisha       |           |            |               |

That Todo column is where you put the amorphus blob of post-it notes, each one representing one of the aforementioned bite-sized tasks for this sprint. Note that while in this column, they aren't actually assigned to anyone; they're simply waiting for someone to take them and stick it onto their Working column.

Now, say that there are 30 tasks to complete before the end of the sprint. Aileen sits down at her desk and as she has nothing to do yet, she looks at the board and grabs the post-it about fixing a bug in email notifications. She moves the post-it from the Todo column into the Working column on her row, and opens her editor.

When the job's done, she moves it to Finished, at which point the QA team can now take a look, and when they're happy with the job, they move it to QA Complete. If however her change broke something, or if it's simply unsatisfactory, they move the post-it all the way back to the Todo column, where Charlie might grab it later that day, since Aileen has moved onto another ticket about the statistics engine.

In practise, developers will often gravitate toward tasks they're familiar with, and they'll often leave tickets that have been bounced-back by QA for the initial developer and this can be ok. However if ever one developer becomes a dominant force on a particular component, (s)he might be forbidden from working on it for a while, to make sure that the other developers have a chance to spend some time learning how that software works.

The most important part of this is that developers aren't supposed to do any work unless there's a ticket for them. This keeps people on-task toward completing the sprint on-time and as expected. If there's other work that deserves attention, this is best brought up at the next sprint planning meeting.


It's about at this point where people start with comments like "What if the server goes down? Are we expected to wait until the next sprint to fix it?". Obviously not. Emergencies or "directives from on high" are things that can't wait and by their nature they can't be part of the sprint plan. They're also rare, so breaking a working system to accommodate them is a little absurd.

The solution is what's called a "spike". A task injected into the Todo list, typically flagged to be done as soon as possible. Its presence in a sprint taints the sprint, so that it can be pointed to in the event of an overrun:

The server went down on Friday and Aisha had to burn half her day fixing it. As a result, we only finished 33 of our 36 tickets this sprint.

This is the sort of thing talked about in the post-sprint meeting, and if more action is needed (either to fully correct the problem or to avoid future cases) these tasks are added to the next sprint.

So, How'd it Go?

There's one other meeting of consequence. At the end of every sprint, you meet to talk about how the sprint fared: what went well, what didn't. In those 30 minutes, you talk about how awesome the QA team was, and how much it sucked when that module we thought would save us work turned out to create more than it solved. It's important to use this time to blow off steam and celebrate the accomplishments of the previous sprint and to take some time to figure out what could have gone better. It facilitates knowledge sharing more than anything else, and allows the PM and team lead to make better decisions in the future.


The one thing people freak out about most when I talk about this method is the lack of documentation. They conjure up nightmare scenarios where one of the developers is hit by a bus and "no one knows how their stuff works", or point out that new developers won't have anywhere to start. Both of these are non-issues though, so long as you stick to the process and don't write terrible code.

If any member of the team doesn't know how a component works enough to get in there and complete a task, then it's time to get that person working on one of those tasks. Knowledge transfer happens best through doing, which means making sure that every member of the team has her fingerprints on every part. To put it in real terms, if Daniel gets hit by a bus, the project can go on because Aileen, Charlie, and Aisha have all spent some time poking at the payment engine. Not one of them wrote the whole thing, but the understanding is there.

Of course this can only happen if the code is readable and adheres to established standards. Variable names should be in the common language of the team and be whole words, method calls should be given names that explain what they do, and class names should make sense as singular objects. If the code can't be understood by someone who's never seen it before, then it's broken by design. Making sure that everyone has an opportunity to interact with this code is the best way to ensure it's readability.

Be Rigid

Probably the hardest part of agile software development is sticking to the process. As simple as it is, it's just too easy to fix a bug that someone found that isn't in the sprint, or add a simple feature that the client mentioned earlier that day. If agile is going to work, this can't be allowed to happen, and a lot of people have a hard time with this.

What you have to remember is that while the process feels pointlessly rigid, it's there to protect the team and ensure that the client gets exactly what was promised on the schedule that was promised. Adding in bug fixes can potentially derail the schedule, or introduce bugs that shouldn't have been there in the first place. It teaches the client that she can have whatever she wants whenever she wants, and as it's not part of the agreed sprint, she may try to get away with not paying for it.

From the developer side, it's important to remember that we like lists. If we can look at the list of stuff to do and know that that's all that's ever going to be there for the whole sprint, this introduces a sense of calm, and knowing exactly what's expected.

To this end, it's important to reward a team that manages to complete its sprint ahead of schedule. If they get everything finished by Thursday, let them take Friday off. The project is exactly as far along as you expected, so why not? Similarly, if the team is routinely late in completing the sprint, overtime is justified since the entire team helped write the sprint schedule during the planning meeting.


What makes agile work is having a simple and concise plan to follow, that has been agreed upon by all parties. I've worked at companies that implement this system without involving the developers so the schedule is imposed by people who have no knowledge of what actually needs to be done. I've also worked at companies where the developers run the schedule, which is to say, there's barely any schedule at all and the results are products that "mostly work", according to whatever the developer at the time thought was appropriate. As with so many other things, the key is openness, honesty, and inclusion in the process for all sides.

Agile is a system that everyone understands and agrees to, but doesn't get in the way of actually getting stuff done. It protects all parties involved from undue stress, and unexpected results, and I can honestly say that it was (at least for me) the best system to work with.

September 21, 2013 00:08 +0000  |  Employment Netherlands 0

In Canada, we essentially have two systems that manage the relationship between employer and employee: unionised and exploitative. Both of these options suck and for different reasons.

  • Unions tend to foster a combative relationship with management and often result in both sides making unreasonable demands of the other. Strikes and lockouts are common, as are attempts to undermine the right of workers to organise, union-busting, etc.

  • Non-unionised workplaces are all-too-often exploitative, using the threat of being replaced to push employees into working additional hours for free, taking pay-cuts, or even breaking the law. Conditions are often unsafe, and the atmosphere filled with distrust and animosity.

In a lot of European countries however, a third-way has been adopted, so much so that when I talk about the concept of labour unions with other Europeans, many of them don't understand the purpose of such a system.

So, what the heck is an OR? It's the Dutch incarnation of this third-way, a staff-elected council that represents employees in dealings with management. Far from being a token voice, their position has legal standing to the point where many key decisions: office hours, pension, health insurance, require approval from the OR.

The relationship between management and the OR is typically more amicable than the one you usually see between a labour unions and management in large part because the staff have more options available to them than work stoppage. The council is kept small, and is composed of people from the company, rather than an external body like a union. This means that the people you're arguing with are the same people you might eat lunch with. The same goes for the people you represent.

The meeting minutes are distributed to all staff by email, and elections are held every few years. The number of members is dictated by the total number of employees in the company, and anyone who has been with the company for six months or more may stand for election.

OR's are legally required of any company that exceeds 80 employees.

I tell you first-hand that this is the way to manage the relationship between employer and employee. It's not perfect, but I've never seen a more functional relationship in an office environment... and that's after working with ten companies over 14years in 4 different cities in 2 countries.

February 11, 2011 22:19 +0000  |  Amsterdam Employment Job Hunting Moving Netherlands Unemployment 6

For those of you who follow my life on Twitter or Facebook, I apologise for taking so long to post the details of the recent changes to my employment status. Stuff's been kinda crazy these past few weeks, so I've had other priorities that I'll talk about in other posts.

So here's the full story: On January 18th, I responded to a job ad for a web developer at MarketSims that I found on an online job posting board, possibly monster, but frankly, I don't remember. The application included my usual fun-sounding cover letter and a PDF copy of my CV along with a link to this site.

That same night, I received a response asking about my preferences for CMSs and/or frameworks and we had some good dialogue about why one CMS might be chosen over another, and why I prefer frameworks in general etc. etc. We also talked about my salary expectations, volunteer work, and outside interests as well, all over email. He thanked me for the info and said he'd get back to me.

Then he got sick for about a week so I didn't hear from him for a while. When we reconnected on the 31st, we talked about doing a Skype interview and settled on a midnight gig on the evening of the 4th.

The interview was with the CEO, CTO, and COO and covered in greater detail what they're looking for. Basically, they're looking to unify the many sites they have into a single managed solution as well as build a portal site for people in their industry. We talked about options and preferences and I made no secret regarding my preferences for Python/Django -- something I was happy to hear was positively received. The interview was largely non-technical, and when it was finished, the CEO said that they'd like to talk about me privately for a while and get back to me... in about 20minutes. A little surprised, I said thank you and we ended the call.

About 15minutes later, the CTO called me back and offered me the job. I'll start March 1st.

The pay sounds good, though it's tough to tell when you don't really know the cost of living over there. Regardless, it works out to a lot of money in Canada, so that doesn't suck. There's lots of vacation time, as European standards more or less require it, and they're accessible by transit. The CTO may even be able to hook me up with some inexpensive temporary housing with some friends while I look for a place of my own once I know the neighbourhoods better.

All-in-all, things are looking pretty good, though I try not to get too excited. Contracts etc. don't get signed until I come in for my first day and somehow, all of this doesn't feel like it will be "real" until then. I'm definitely leaving though. I've already bought my flights:

Vancouver » Kelowna Feb 21
Kelowna » Vancouver Feb 23
Vancouver » Amsterdam Feb 23

If the temporary housing doesn't work out, I'll look into Couch Surfing, then hostels, then hotels, in that order. Obviously, that's a rough route to take, but I'm not sure how else to do it. I will however endeavour to blog the process, if for no other reason to chronicle how very painful this kind of thing is.

November 04, 2009 07:02 +0000  |  Employment Scrubby Work [at] Play 3

I'm tagging this one as "Employment" for lack of a better word, but frankly, that's not really accurate. My work life appears to be rapidly branching away from the employer/employee relationship and into running the show myself. The question is becoming one of "how much time do I have?" rather than "with whom can I find work?"

That's right, I'm bringing back the old-school "don't start a sentence with a preposition thing. You're just going to have to deal ;-)

The details: three months ago I was just working at Work [at] Play as a senior software developer, and for all the griping I do about the neighbourhood and the office, it's really a pretty cool place to work. The truth of it though is that I felt like I was stagnating, not doing anything useful with my life, and what's worse, I was rotting like this in Vancouver. I was ready to get the hell out of here at the drop of a hat -- to go anywhere really, just as long as it was sufficiently urban, interesting and wasn't here.

That all changed when Melanie forwarded an interesting "job" posting my way. A young, local entrepreneur was looking for a technical co-founder for a new company wanting to encourage business to do the Right thing by making it profitable to do so. To use an idea from Paul Hawken, our company would help other companies grow like trees, with deep roots, rather than like grass with no sustainable future. The details are complicated, and still a little secret, so I can't share them here, but the point is that I've signed on to make this thing happen. It may implode, but I don't think it will, and in the mean time, I'll have the opportunity to Use My Powers For Good... and that's all I've ever really wanted anyway.

But now things are getting crazy. Less than a week since I've entered into this partnership, I've been contacted by two separate parties wanting me to serve in a senior technical capacity for their enterprises as well. All three ideas sound promising, two of them are Good companies, the third, while run by a good, honest, person I trust, is more about the money and less about Making the World Better. All three are offering very little if any money to start.

The truth is, I can't do all three and keep my job at Work [at] Play. I probably can't even do two, though it'd be nice since one of the other two can pay a little. As it is, I've talked to the brass at my current employer and asked them to figure out a way that I might be able to work 4days/week for them so I can devote two days each week to my new partnership, and while they're currently mulling it over, I'm reasonably confident that they'll find that it's good for everyone if we can make it work.

But for now? things are CRAZY. I honestly don't know what my situation will be in a few weeks. And strangely enough... I like it this way. Who knew?

May 13, 2009 01:40 +0000  |  Employment Geek Stuff Linux 3

It happens, especially in recessions and when it does, there's often little or no warning. You come into work on a Friday, work through the day, and at the end of the day, as you're heading out of the office, the boss comes to you and says something to the effect of: "Sorry, but you're done here."

Not long after you manage to get over your panic attack, your boss drops another bomb: you're not allowed to access your computer again. All of your personal email and/or files that you have on there are going to be backed up into hard drive somewhere and gods know what the sysadmin is going to do with it.

Now one might argue that if you're putting personal stuff on a company computer, the company owns that stuff, and legally speaking, you might be right, but morally, it's your stuff that you access at work because work takes up the vast majority of your day. It only seems fair that if they're going to give you the boot with zero notice that you have a chance to keep your emails and IM conversations with friends and family private.

So, in case you've ever wondered what might be a good way to keep your data more-or-less safe in such situations, I thought that I would post a little how-to here.

Option One

Don't put personal information on your company computer. It will save you all kinds of hassles, even if it does make life at work considerably less bearable.

Option Two

If you're going to put personal information on your company computer anyway, the best way to secure it is to have your computer continuously check a remote source (under your control) for instructions. You can then leave the instructions blank until Something Bad happens. For example, on a Linux machine:

  1. Create a tiny script file (call it "remoterun" for the sake of this example) and put this in it:
          #!/usr/bin/env sh
          curl -s | sh
    Now make it executable.
  2. Log into the server hosting and place a file called instructions.txt in the document root. It can contain anything you want to execute on your machine. I recommend the deletion on your home directory (so long as there's no company data in there) and the removal of your personal account from the box. If you choose though, you can be a little more zealous and delete your music files, any background wallpapers you if you want. Just don't delete anything belonging to the company or they will be well within their rights to come and kick your ass in all kinds of unpleasant ways. Here's an example of a simple instructions file:
          # Delete my music
          rm -rf /opt/share/music
          # Delete my account
          userdel --force --remove daniel
          # Delete the remoterun script
          rm -f /path/to/remoterun
    This part is very important: Do not put anything in this file that you do not wish to run immediately. The above would nuke your personal data, so only put destructive instructions in the file when you actually want to delete stuff. Until then, you can just leave it blank.
  3. Now that you have an instructions file, you just need to make sure that your office computer runs the remoterun script every hour or so. That way, the machine will run your instructions within an hour of you setting them up on In Linux, you can do this with cron:
    # crontab -e
    That will allow you to edit the crontab for the current user (be root, it's best for this kind of thing). Now you just add the crontab line:
    00 * * * * /path/to/remoterun

That's all there is to it. Every hour, your office machine will connect to and execute whatever instructions.txt says. Windows users, I'm afraid you're on your own but the theory is the same.

Now remember kids, use your powers for Good, not Evil. I've provided the above so you can be a responsible person while protecting your private life from someone who shouldn't have access to it anyway. I hope that you will do the same.

March 23, 2009 23:33 +0000  |  Canada Employment The Economy Unemployment 0

Details of the Japan portion of my recent trip are coming, but I found this link today and thought that it'd be a good idea to get it circulating somewhat first.

The idea is called work sharing and it works like this: in tough times companies large and small can apply to have Canada's employment insurance program pay (all or or a portion of) an employee's salary for one day each week, the employee then takes that day off. It gives companies facing layoffs another option that allows them to retain talent while saving anywhere between 10% and 20% on salaries.

If you're interested, check out the details at Service Canada.

June 27, 2008 07:52 +0000  |  CCTV Drupal Employment Family The Toronto Public Space Committee Work [at] Play 0

I'm trying to post more here lately as it would seem that since moving to Vancouver, my posts have been more and more sparsely scattered about the month. To that end, here's a quickie post regarding my relatively good day:

I had my review today. Good news: they like my work, and they're giving me a raise (w00t!) The only somewhat negative thing the boss mentioned was how I didn't know enough about Drupal yet. I can understand her position really, I mean, a large portion of our legacy code is in that horrible framework, so it only makes sense that as a senior developer, I know my way around it. I guess I'll just have to take a deep breath, bash my head in with a crowbar, and work from there. ^_^

Anyway, aside from the good review, I found a new sandwich shop in the area that serves giganimous sandwiches, and then discovered some left over birthday cake in the office fridge. This, coupled with the fact that I got a big chunk of work done today (and documented!) made me happy with my current form of employment.

I also fielded a 1hour call with a University student out of Windsor, Ontario to give him some background on the TPSC's CCTV campaign back when I was running the show. That was a bit of nostalgic fun -- kinda like talking to the press, but you can be a little more candid since you know that you're not talking to the uninformed public, but rather a well-read academic.

And then, to top it all off, I came home to a clean apartment AND new groceries in the fridge! Butthead had been hard at work and it showed. Having a roomate might not be so bad after all ;-) He's making a lot of progress with his own life lately though. I'm really quite proud of him.

January 31, 2008 05:14 +0000  |  Drupal Employment Perl Reinvent Work [at] Play 8

Those of you who aren't privy to my less-than-public posts, you might wonder what the heck happened to Reinvent and why I'm suddenly talking about The Donat Group. Obviously, it's probably a Bad Idea to talk about the nuts and bolts of it all publically, but here's the gist in my generation's favourite format: point form.

  • Reinvent is a fun company with lots of smart people
  • It's also run by management that feels that expanding their business into Software patents makes for an acceptable business model.
  • I disagreed. I've worked for a lot of companies who did things I felt were Not Good, but there are a few things I won't do... supporting software patents is one of them.
  • So I went looking for a company whose morals where more in tune with my own and I found one in The Donat Group.
  • I handed in my resignation, offered to work 2weeks before I left and they declined. I guess the brass weren't happy with me.
  • I started at Donat today and they seem pretty cool. Very startup-like but with actual paying clients.
  • They like Drupal though, which from what I've seen, is really not good. My first impressions of Drupal is that it's a bunch of non-programmers pretending that they can write real software. Function and variable names bleeding into everything else, no objects, and horror of all horrors: their coding standard requires a two-space indent.

I made a work around for the back-assward indenting thing though. I call it undrupal. Basically it uses a regular expression to strip out the space-based indents and replace them with tabs. Then you can write your code in a sane environment, then use the same script to re-crazy it with spaces again.

Ok, so my first day didn't exactly have me neck-deep in super-advanced code, but hey, it's the first day. I'm really looking forward to this job though, the boss is pretty cool and his politics are more in line with my own, and even more fun is the fact that I'm now labled "Senior Developer" and I'll be able to actually head up new projects and such.

That's it for me now. If you want more details, just gimme a call.