Did you hear the one about the bank that hired a naval architect?

Sorry but there’s no punch line to this one.

It’s just a story.

This is the story about how I became an IT professional in Finance. It’s not that I believe it is a story that you need to know, it’s just that once people learn that I actually graduated from university with a Bachelor degree in Engineering (Naval Architecture), they always ask how I made the ‘leap’.

Baby steps and a lot of initiative are the answer.

No, really. If I have manage to pique your interest, please read on…

Read more of this post

The virtual day

For much of my professional life, I have had to complete weekly time sheets – not just ones that are used by HR to track my attendance, but ones that are used to manage project budgets and allow me to indicate which projects I have been working on the related tasks. When you are only committed to one project or task, life can’t get any easier as 100% of your time is attributable to  that one project or task. Things get a little trickier when you need to need to start accounting for all of your time and splitting it across various tasks or projects.

Read more of this post

Social networking for corporate climbers

The only reason that IT professionals hate Facebook is because they didn’t think of it first! Don’t get me wrong because whilst I don’t have a Facebook account, I don’t hate Facebook; it certainly has it’s place for keeping you in touch with friends and sharing your experiences with each other, but like most tools, it needs to be used for the right purpose.

Just like using a chisel to turn a screw is a disaster waiting to happen, collaborating or networking with future employers on Facebook is not the right way to go about selling yourself to a prospective employer. A future employer does not need to know that you loved last nights casserole or that you, Lindsey Lohan and Justin Beiber should hook up. They especially don’t want to see pictures of you from last Friday night at a sleazy nightclub slobbering all over some guy/girl and/or passed out drunk on the curb.

LinkedIn is the screwdriver you need – the tool you need to sell yourself online to prospective employers and employment agencies alike without all the extra personal baggage of who you hang out and what you did last Saturday or how many credits you have on farm-ville.

If you approach LinkedIn as your online CV and keep it up to date with as much detail as possible about what your roles and responsibilities were in each role, the calls will come. You even get to build a network of associates that can vouch for your skills and provide recommendations.

More and more these days, recruiters are relying heavily on tools like LinkedIn and the associated recommendations and connections to headhunt suitable candidates that match their clients requirements.

Additionally, tools like twitter and WordPress blogs are also valuable tools in selling your skills online. You don’t need to be looking for a job with every blog you write – just share your knowledge and hopefully someone will see that the knowledge you possess is worth paying for. Twitter is a great way to tell people about your new blogs, or share small tidbits of information as you come across them. This highlights that you are well read and keep up with current affairs, technology, etc.

Ultimately, its not always a build it and they will come scenario. Gradually as you build up your profile, and add more and more connections – typically past and present work colleagues, your network will grow. Be sure to give as much detail as you are comfortable with (and legally permitted) regarding your roles and responsibilities. Remember your employment contract may not permit you to publish or talk about the particulars of projects that you might be working on. Take for instance the HP executive who recently inadvertently announced the company’s new cloud strategy.

Keywords will help recruiters narrow down you as the candidate they are looking for. In IT, terms like SDLC, delivery, governance, service management, risks, performance testing, if applicable, will highlight you as experiences in operational service management and skills in governing risk and performance. You get the drift…so what are you waiting for?


Connecting with Museum Visitors Online and on Site with Technology

I am a relative new comer to the Maritime Museum circle, not because of my age, but because I only recently became a member of a maritime museum. My involvement in maritime museums and writing this paper has allowed me to share two of my greatest passions – Boats and Technology. I am qualified as a Naval Architect having a Bachelors Degree in Engineering (Naval Architecture), but sadly I now work in IT building and managing large corporate web and software projects. I have been working in IT for nearly 14 years now and have been using the web since it first came out back in 1996. I’ve finally found an outlet where I can give something back to the Maritime community and I am currently working on re-designing several Maritime Museum websites.

So, I am here today to talk to you about connecting with visitors – both on-site and on-line. I’m going to briefly look at why we need to connect with people and then I will go onto various ways we can use our technology and history to make these connections. Read more of this post

Hibernate makes Developers Lazy-er

The beauty of Object Relational Mapping or ORM tools like Hibernate is that it allows developers  to write less code by focusing on an object oriented approach to programming rather than a more intensive data table centric approach.  This consequently reduces the amount of SQL coding performed by the developer and this experience, over time,  can negatively influence the developer when modelling the database structure.

Database skills are essential for almost all developers these days with enterprise solutions being designed with data at their core. I believe that whilst the developer remains ‘abstracted’ from the data, they become more complacent in the data model which is likely to result later in poor performance and capacity bottlenecks.

There are plenty of articles and opinions on where business logic should reside within a multi-tiered architecture – in the User Interface, the Middle Tier, the back end or even in the database. There is a case for each of these and all of them as well. Hibernate, or ORM tools suggest the Data Layer should be simply that – data only, and any business logic should be further up in the architecture.

As a consequence,  and from my own experience, I have seen web solutions that make thousands of database calls to load a single web page due to a lack of appreciation of the data model, and a reliance on ORM tools to do the grunt work and gather the required data. For example, row by row iterative queries might perform adequately for a single user in a development or test environment, but what happens when you go live and there are now thousands more records and hundreds of users?

When does the developer stop to continue production data volumes and performance? In many of these cases, and again from my own experience, a simple database index is all that is required to resolve performance issues, but why aren’t developers thinking about the data? because Hibernate is abstracting them too much from the data and developers are losing touch.

It is amazing how many developers know SQL but not Transact SQL (i.e.  how to write Stored procedures).  Cursors used to be “de rigueur” but were not as efficient as hash-tables or temporary tables for iterative data processes. Now the whole process seems to be migrating into the code with technologies like JPA in JAVA and LINQ in Microsoft languages.

Now it is important to highlight that laziness can be seen as a positive attribute in developers. A lazy developer does not want to do things twice and write more code than is necessary so they look for smarter solutions and tools to help get the job done faster. It is just my opinion that some of those tools and techniques are moving developers away from some of the core fundamentals of software development to the detriment of performance.