Michael’s Handy Guide to Leaving Your First Job

Those of you who know me will be aware that, at the end of last year, I left the first job I got after I graduated.  I had been in that job almost exactly 6 ½ years and leaving it was more difficult than I imagined it would be.  But the people who are in the strongest position to provide a sounding board on your reasoning are often your colleagues, though they’re often the last people with whom you really want to bring the topic up.  I’ve written down some of my experiences in the hopes that it might aid some people.

First things first, know why you want to leave.  Write it down, make it more than a vague idea in your head.  They might seem like really strong reasons until you write it down.  They might even be fixable within your current company; so while I’m not attempting to necessarily talk you out of leaving, if you’re already happy except for one or two things, maybe leaving isn’t a great idea.

Secondly, and probably more importantly, know why you stayed as long as you did.  Maybe you don’t know how to answer that question – I certainly didn’t.  It was my first job since I graduated university and everything I knew about the working conditions of the industry were from that job or what Some Guy On The Internet said.  Although I can give you my reasons, now that I’m on the other side and have had that thrown into stark reality for me.

  • I liked that what I was doing was being, for the most part, used for good.  We made two-way radios, the network equipment for them and software to support their maintenance.  We made good radios; good enough to be used by emergency services the world over.  They, by and large, were not sold to military organisations and usually were used to make the world a little bit better.  These radios were even used by the emergency organisations who helped deal with the major earthquake in our city in February 2011.  Our products were helping products.
  • It was technically challenging with a wider variety than one would normally expect from a single company.  During my stay at the company I worked on hardware drivers, embedded software, fake embedded environment targeting desktop linux, distributed build automation software, desktop application in .NET right through to the whole vertical of a modern Web Application (SQL, .NET, HTML + Javascript).  And in the couple of months leading up to my departure I was working at almost all of those layers simultaneously, trying to integrate them.  There are not many companies, I would wager, in the whole world where that variety is possible.
  • Great people – my immediate team in particular.  There were some exceptions to that, but I don’t want to go into them here, particularly as this is the thing that is least under your control and there will be people you don’t get on with most places you go.

So now you have it in your head that you do want to leave and know why, it’s time to start looking for new work.  Knowing what you desire in a company will help you look.  Maybe you’re lucky enough to already have heard about a job through the grapevine – that’s probably your best option in terms of interviews.  You get to casually talk to the person who mentioned it without feeling like you’re going to scare them off offering you the job.  I know this is technically true of more traditional interviews, but the mindset is certainly different.  The most interesting jobs are found that way, too, usually.

Whatever you think you know, your interview skills probably suck.  Or are only good for a different time in your career, where maybe you cared more about a job in the right industry rather than the right job for you in particular.  Take any interview you can get, to begin with.  I had applied for a job at a company I liked, but maybe the job wouldn’t be so interesting.  I went along to that interview and gave the best interview I’ve given in my life (including the one which eventually landed me the job I’m at now).  I didn’t end up working for that company, but that confidence boost really helped.

Again, I want to stress you want to know what you want in a company.  Don’t settle for “We do Agile”, how do they do Agile.  Do they do any of the XP processes?  Exactly what did they mean by the different technologies they use?  How long have they been doing it?  Do the words they are using mean the same thing as you think they do?  Are they willing to give you a bit of a tour of the application or working environment?  Are you able to sit down with them to do some coding?  What god-awful enterprise software will you have to use on a daily basis?  Are they willing to shell out an extra $50 for a nice keyboard?  You know how during normal conversations where the phrase “what is this, an interrogation?” gets uttered as a defense… well interviews are an interrogation.

So presuming you’ve now landed the job of your dreams, be aware that the notice period of your old job will be more difficult than you realise.  On the day I handed in my resignation, I totally ran out of emotional energy.  Telling people that you’re leaving and having that look in their eye that they’re feeling a little bit abandoned is kind of like telling a puppy off.  It’s best for everyone if you do it, but it doesn’t make it any less difficult.  So at the end of the day when someone with whom I would normally be happy to have a laugh with said with her tongue firmly planted in her cheek “what a dick”, I had no response.  Thankfully she was able to read the situation and possibly cottoned on to the fact that I’d spent the last wee while just trying not to cry.

And as was also said to me: “There is no good time to leave, so don’t feel guilty about it”.

My semi-last day was pretty bad.  It wasn’t my last day per se, but I left at the end of the year, so some people finished up for the year earlier than my last day.  I hadn’t considered that as a possibility and so I wasn’t prepared to say goodbye to some of those people yet.  I took a couple of quiet walks on that day in an attempt to hold it together enough to continue getting the jobs I wanted done before I left.  I certainly stretched the definition of holding it together.

So you’re starting the new job.  All going well, you’ll get your hand held for the first week or so and you’ll start working and getting stuff done.

But for me, all did not go well.  My first week was awful.  I felt like I was having a week-long anxiety attack and nearly couldn’t bring myself to actually go to work on the Friday.  Everything had changed – the amount of traffic I needed to wade through just to turn up in the mornings, what I could have for lunch, the people, the work, the process, the god-awful enterprise software, the operating system version and even the keyboard.  I had picked up a fairly easy-looking task to do that week, but I had somehow expanded the scope of the story to make future work easier.  In a normal situation, I would have said this was a good thing to do, but one’s first week on the job is not a normal situation.  I had taken a job with a fairly large pay increase to spend a week doing what should have been a relatively small piece of work.  Just get something reasonable done and get it checked in.  Make it feel like you’re actually contributing, rather than some fraud who can’t tie his own shoe laces.  That extra work is paying off now, but it wasn’t a fair trade-off, when my emotional well-being is considered as part of the equation.

So really, what I wanted to say was that actually, leaving your first job is going to be much harder than imagined, but in part, it is worth it for the learning experience alone.  After throwing myself out of the situation where I was surrounded by the people who taught me the ABCs (or maybe the S.O.L.I.D’s) of software development I was suddenly able to see more clearly some of the intrinsic features of their code, and the features of the environment in which I worked which I find either different or missing in the new one.  Also, don’t change every other major feature in your life at the same time, or you won’t have the energy to produce even a simple blog post and will dither on it for roughly a month longer than it really deserves.

 

Advertisement

Serious Feminism

This is what a feminist looks like

This is what a feminist looks like

So much of what the word feminist conjures up for most people is totally wrong.  Feminism is not about hating or even disparaging men.  Feminism is not about treating women as superior beings, it is quite simply about equality.  I’m not someone who believes that men are inherently evil and are the plague that needs stamping out, but rather that women and men should be able to co-exist and be cherished for their differences, not excluded or diminished for them. One thing that the more astute of you will have noticed is that I’m a man and yet I call myself something which is predominantly known by the general public as the exclusive reserve of those without a Y Chromosome.  This is not only wrong, but indeed part of the problem. The word feminist is purely descriptive.  As Aziz Ansari recently said:

“So, I feel like if you do believe that, if you believe that men and women have equal rights, if someone asks if you’re feminist, you have to say yes because that is how words work,” he says, joking, “You can’t be like, ‘Oh yeah I’m a doctor that primarily does diseases of the skin.’ Oh, so you’re a dermatologist? ‘Oh no, that’s way too aggressive of a word! No no not at all not at all.’”

There are some who thing that it’s only weak mean who announce themselves as feminists.  I can tell you that this is also not true.  Many men with similar viewpoints to mine will try to avoid this awkwardness by watering down their position to only call themselves ‘feminist allies’, furthering the myth that only women can be true feminists.  It stakes a strong person to stand up for what they believe in, regardless of who they are, so no, I don’t buy it that only weak men are feminists.

Two of the women I have dated shared with me that they were raped.  Neither of them said anything to any authority figure – particularly not their parents, with one of them saying that she believed this revelation would make her father think he had failed as a parent, because of the actions of someone else entirely when she was walking home from school.  So I can absolutely believe that the estimates of unreported sexual assaults are correct, if not conservative.  The number of women I have dated is not much higher than that, which makes it a frightening percentage of the women I’ve known intimately who’ve experience such horrific circumstances.  I thought that maybe it was because I generally try not to be an asshole towards women that I had attracted a disproportionate number of women who had experienced sexual assault.  That was, until I read the posts to the #yesallwomen hashtag.  That was when I learned that it was actually not just incredibly common, but actually that #yesallwomen have experienced something of the like. This.  This is why I am a feminist.

I have often struggled during my life, I have to fight anxiety and depression nearly constantly (a fight that I am proud to say, I’m winning) but really, I have gone through life on easy mode.  I am a straight, white, middle-class male with no religious affiliations.  In short, no one persecutes me just for being me.  Therefore, if I have struggled with life, even though half the world automatically gives me an advantage, based on nothing but my genetics, how do women deal with such things?

The current trend for posting placards as to why you don’t need feminism make me sad for all kinds of reasons.  But firstly, I am happy that the women posting have the ability and nerve to publicly voice their opinions, even if I don’t agree with many of them and nor do I think many include much research or understanding.  They seem to be based on the misconception that feminism and having healthy relationships with males are incompatible.  Whereas to me, that’s entirely what feminism is, it’s about having healthy relationships with everyone.  Treat everyone equally and it’ll all work out in the end, right?

Right now, given that this is a software blog, I bet you’re wondering where the software content is, right?  Actually, you’ve probably already guessed.  There is an overwhelming imbalance of gender in software.  It’s not because males are inherently better at it, but because we, as the wider software community tend to discourage women from being part of our club.  We do this in a bunch of different ways, some of which are subconscious, but a large number aren’t.  I don’t want to list them, because it can all be summed up by Wil Wheaton’s philosophy of “Don’t be a dick” and actually, things will work themselves out.

But more importantly, the events involving @SeriousPony and how she and her children were targeted just because she was a prominent woman in an overly-male industry.  I wouldn’t be able to do it justice if I attempted to recount the events here, but they are truly shocking and terrible.  She suggested she would remove the post soon, but I recommend reading it here, if it’s still around.  I’m not even outraged at her treatment, I’ve gone way beyond that and have shifted squarely into total despair for all of humanity, if even a small portion of it is capable of such endeavours. So yes, I am a feminist and I think you should be too.  Not all women are equals… yet.

My Expertise

When I was one I had just begun
When I was two I was nearly new

When I was three I was hardly me
When I was four I was not much more

When I was five I was just alive
But now I am six, I’m as clever as clever;

So I think I’ll be six now for ever and ever.

 — A. A. Milne[1]

I’m fast approaching six years as a professional software engineer.  A quick back of the envelope calculation suggests that this means I’ve worked 11,820 hours, and have been becoming a software engineer for four years prior — back at the start of 2004 was when I first started university.  According to Malcolm Gladwell’s definition I should be an expert by now.

Read more of this post

Agile Infrastructure

By now, you’ve probably figured out that agile is this new-agey style of software development. But agile is far more than just group hugs and stand-ups. By that I mean, agile is more than a project management system. Agile is a way of managing change and being able to respond quickly to it, whilst delivering as much value to the customer as possible.

How do we achieve that? It certainly isn’t possible just because we’ve planned our sprints. Agile goes all the way down to the code base (or starts at the code base, depending on how you look at it).

Read more of this post

BDD, the A-Ha Moment

I’ve been professionally writing software for almost six years now, aware that testing was something that ought to be done as part of one’s job, but it was only in the past couple of weeks that I really had a solid moment really bringing home to me why Behaviour Driven Development really works.

After a sharp awakening that I just wasn’t doing my job properly (I had checked in some code that only sort-of worked, and had no automated tests verifying to what extent it was broken), I was picking up a new task.  This piece of work was something I had done before.  Not something like it, this exact thing, in a quick hack demonstration model that we threw away, with this being one of the changes we decided to keep.  I knew what to do – I had to delete a bunch of code and it would still work.  I was removing a decision from the user which wasn’t necessary with the improved workflow of the new version.

Partly because I wanted to improve my work ethic to what constitutes basic professionalism in my team, but mainly I was a little angry with myself and exasperated with the person who had shown me in stark reality how I was falling short of my job description.  He is the Tech Lead on the project, and I decided to challenge him – I didn’t know how I could possibly test for a lack of a user interaction without some horribly farcical test.  So I asked his advice on how one might go about TDD’ing a removal of code.  To his credit, after a couple of minutes’ thought, he came back to me and said that the user interaction missing wasn’t something we should be testing, but the decision was still being made – in code.  He and I both knew that our previous version was a race to get something out the door and we had fallen into some of the classic traps, dumping logic directly in with the UI code in the name of speed.  UI code is notorious for wanting to do extra things, like starting an event loop, which is not conducive to automated testing.  We therefore did not have such things around this particular logic.

The Tech Lead said that the best thing to do was to wrap some tests around the logic that would remain; we were removing one of the four possible outcomes and the other three still needed to work.  Then, while we were looking at the code to see how to get started, it quickly became obvious that without the decision dialog in the way, we were free to move this logic to a more appropriate layer.  But where exactly?

I started writing some tests to see that this decision would be made and found it much more difficult than it should have been.  This made me revisit the decision of where I thought it should end up and moved my testing to a different layer.  This too was a dead end.  I think it was only three, but it might have been more attempts at fitting it at the right level.  Still, these were two minute forays at most.  Each test setup showing very quickly the problems at each layer and they were all completely revertable because I hadn’t changed any real code yet!  Then I found it.  The layer at which it all fitted.  Writing the tests became easy and I could do it piece-meal as I slowly removed unwanted code and then moved the method to its rightful position.

I already knew the code worked – we had manually tested it quite thoroughly, so actually asserting correctness wasn’t even at the top of my list of objectives for writing a test.  Although I wasn’t conscious of it at the time, I was writing the test purely so it would guide my design.  This is why the title of the post says BDD, but I referred to TDD earlier.  BDD is the aim to remove the conscious thought of testing for correctness and moving towards asserting that the functionality exists.  In short, it’s a good way of doing TDD properly.

In the end, I spent around an hour in a single session doing something quite straight-forward, which would have taken a similar amount of time had I not let the testing guide my design.  Except that I left the code in a better state, architecturally and didn’t revisit it because I missed something with my human-based testing.

I mention this as my a-ha moment, because it really solidified for me what BDD was all about.  It’s not about having those green ticks appear on your screen, it’s about really becoming the first client of the service you’re writing.  The practice run before unleashing it on real code.  And subsequently I have found the mental battle to test-drive my design (was that pun also intended by the creators of TDD?) has completely melted away.