Category: Software Development

Why I love my job

I decided I wanted to be a computer programmer from a very early age. This was a decision that changed briefly when I toyed with the idea of going into psychology, but ultimately – programming and coding is where it’s always been at for me.

The main draw for me isn’t just knowing that I am in control of a machine on some level. Let’s face it – all programmers are control freaks on some level, so it goes without saying. Mainly, it’s just how quickly it all keeps changing. When I first discovered programming. it was on my Dads old ZX Spectrum. I wrote out reams and reams of code on A3 sheets of yellow paper, before patiently typing it all in and watching my code run. We were short on tapes, so this really was the best method for me at the time.

Fast forward to college, and I started to learn Visual Basic 6. University introduced me to programming concepts, such as the Waterfall Model, Object Orientated programming.

The real world introduced me to Test Driven Development, WPF and .Net. The key thing here is that much of the knowledge I have gained – even over the last 10 years – very quickly becomes obsolete. I haven’t touched Visual Basic 6 for years, and the Waterfall Model is scoffed at in favour of Agile methodologies.

That is why I will always love my work. It’s constantly changing, I am constantly learning, and that keeps everything fresh as I get to put my mind to keeping up with the curve. This all stops me getting bored with doing the same old, same old.

I can hardly wait to see what the technology will advance to in the next 10 years.

The most aggravating compliment

Sorry folks. This is a dreaded women in STEM post. It’s sad that #ILookLikeAnEngineer is a thing. People still do not get it.

So, a true story.

A long time ago, in a job in my past, there was a week of BIG MEETINGS. It was a huge deal, with very important clients who we *had* to impress. The culture of the office was lax, and the usual code was ‘get in for some time, do all your work, and wear what you want’. For this week, we were asked to be in well on time for the BIG MEETINGS, come in suited and booted, and above all, behave.

So, I spent a week turning up to the office, wearing a nice skirt, blouse, and killer heels. Literally, killer. When the clients had gone for the day, I’d kick off said heels and start sticking plasters on all the bleeding bits, longing for my comfy trainers or boots. I kept my mouth shut, and smiled when spoken to. I didn’t really achieve much of my own programming work that week, in-spite of only having to attend a couple of the meetings, as the entire team was on tenterhooks with how said BIG MEETINGS were going. Things were going on that made it too difficult to concentrate.

I received three compliments that week. Take a guess which one infuriated me.

  1. Please don’t take this as harassment or anything, but you look stunning like that. I wish we could see it every day!
  2. I won’t sit next to you in meetings when you wear a skirt any more, as your legs are too distracting.
  3. I’ve been really impressed with your professionalism this week. Great work!

If you haven’t already guessed that the third compliment was the one that annoyed me, you still don’t get IT. So, I’ll explain further.

The week where I can honestly say that all I did was turn up, look pretty, and not share my professional opinion, is the one where I got complimented on being ‘professional’. This sent the message that I am only valued as a professional when I’m making an effort to look nice and keep my mouth shut. So for what reason had I been turning up and busting my arse all those years before?

I didn’t say anything, of course. I really do, even now, still get that the compliment was meant as just that – a compliment. It wouldn’t be right to give the complimenter a hard time over it. I do not believe that anything bad or insidious was meant by it. It was genuine, and not meant as a put down in any way. Normally, I’d be happy to hear it. But as a woman working in a male dominated field, where I have often felt that I’ve *needed* to shout out and dress down to be taken seriously, it really stung. It still does.

I subscribe to the saying ‘You don’t give offence, you *take* offence’. But before anyone shouts me down for this post, maybe try wearing those killer heels for a week in a similar situation, only to be hit with the reality of what counts higher up as ‘professional’, and tell me you wouldn’t be spitting fire about it to. This really does tie back to my earlier post. As much as I can look back on this incident, and know that logically, I took this in a way that was not intended, it just underscores that perception is an absolute bitch.

The Zone

The Zone is something that most programmers will know about. It’s that place of quiet in our head that allows us to focus all of our attention on one problem, to the exclusion of everything else. My Dad calls it ‘hyper focus’, which is also quite apt and probably more accurate.

I’m personally of two minds whether the ‘Zone’ is a good place to be or not. I can never determine how I go into it – all I know is that if I find something interesting enough, the rest of the world falls away. All that is left is my ‘item of interest’. People have been known to shout or throw things at me to get my attention when I’m in this place. A ceiling once fell in behind me while playing Sonic the Hedgehog when younger, and I never even noticed.

I’m not sure if the quality of my code gets any better while I’m in this place. Some claim that their code is the better for it. What I do know is that coming out of it, either due to someone else forcibly distracting me, or coming out of it naturally, is horrible. It feels like waking up after only 2 hours of sleep. Confusion reigns as I try to catch up on everything that may have happened while I was in the Zone. People have to repeat themselves a few times before I get what they were saying. It’s like emerging from a dark fog into a brightly lit room – you’re temporarily overloaded by all the things that you had not been noticing whilst in your own world of productivity. And then the overwhelming urge to go to the toilet, or eat/drink something. If I’ve ever gotten stuck in the Zone, I’ll often find I have been there for hours.

Some people have different methods to get into the Zone. Some need absolute quiet. Some need music. Personally, I find I just … get there. I habitually wear ear phones and listen to upbeat music whilst at work, but that’s mainly to drown out the noises of people around me so that I can concentrate when I’m not in the Zone. When I’m in the Zone, I don’t even hear the music. Or anything. Which is one of the reasons I find it kind of a scary place to be. I’ll end up in the zone through reading a book, playing a computer game, or doing work.

I actually try to avoid getting there these days. Which is actually easier said than done, given how easily I slip away to that place. I keep my usual Spotify playlist random (feel free to check it out here. Don’t judge me!). I try to make a conscious effort to take breaks every hour or so.

So, is the Zone a good or bad place to be? Honestly, my verdict is leaning more towards ‘bad’, given how awful I feel after coming out of it.

On the Job Training as Knowledge Gathering

This week, I am being trained on an application which I am to build the next version of. Initially, I thought it would be a bit of a waste of time. I’ll be writing the all new singing and dancing version on a completely different platform, so who cares about being trained in the old one?

Well, it turns out I should. Being in a training room with other people who are also learning it is providing me with invaluable information. So what if I know how the app is working under the hood after reading the code base for the last couple of weeks? I have pages of notes on things that need to change that may have made it into the next version without this kind of feedback. I am watching how users – new and old – are using the application in its current form. I’m experiencing some of the strange niggles first hand.

This post isn’t to down talk the application as it exists now – like anything these days, it has its great points to. What this is about is being aware that just watching your end users – be they trainers or newbies – use your application is like a gold mine of information on what could be better, what actually works, what they want to see more of, and what they want to see less of. They don’t care about what’s under the hood. They just want to make their working day more efficient.

Although it’s bound to be time consuming, I can’t help but think that having user groups together to play with an app well before release in an observable environment will do that app more good than any number of revisions to a product specification. I’m not talking beta testing here, as what I’m experiencing now is active feedback on an application where the new ideas are still being collated. It’s something I’m going to be trying to push for going forwards in my own processes. It’s not a new idea. I’ve just never thought of applying the idea to a training scenario before. An established application in a training environment is certainly a great candidate for this treatment.

Going by the information that I have noted down after just two days, observing a hands on training session group is providing more value to me as a software and UI developer than any mass emailed questionnaire ever could.

Developer, Love Thy QA.

I suck at testing things. Always have. I keep trying to be better at it, but I’m just flat out awful at it. I don’t have that twisty way of thinking that would cause me to try and use something in a way that doesn’t seem logical to me.

There have been a few times in my career where I have been in a position where I was expected to fully test something that I’d been heavily involved in. It is after these experiences that I am convinced of two truths in software development.

  1. You shouldn’t be testing your own code. You get caught in a ‘pattern blind’ trap, because you coded that thing from the ground up. You know exactly how it’s supposed to work, and it’s incredibly difficult to conceive anyone attempting to use it in a way that you have deemed stupid in your own head.
  2. A good QA is worth their weight in platinum. They care enough about the quality that they will make your application sit up and dance until they break it. And they’ll break your application in all sorts of exciting ways in which you could never imagine.

We’re in a world where deadlines seem to trump quality. This is really bad from a consumer perspective. To give an example – I no longer pre-order computer games, or even buy them on release day. I wait until the first patch comes out to fix all the issues with the game before I even think to throw money at it. This has happened with every single game I’ve been paying attention to for the last year.

As a developer, I want anything I work on to kick bottom. As myself, I know that inspite of my best efforts, a tester I am not. An aggressive QA person constantly bouncing something back to me, while demoralising, means that I have an extra set of eyes making sure that my app is going to kick arse.

A bad review can completely destroy customer confidence. Which is why, as a software developer, my alarm bells start ringing if I interview at a place where they proudly proclaim ‘We don’t have a QA team’. Those same bells start ringing when a team is pushing a tight deadline, and the first thing to be pushed back on the table (or sometimes off it all together!), is the QA.

Dropping QA should never be acceptable. Love your QA, because by doing what they do, they are covering your backside. Instead of dropping QA to meet a deadline, I think anyone who cares about your product would much prefer you to just push back the deadline instead.