Tag Archives: process

I’m a Jack of all Trades and its OK

I thought I’d get back into writing and fulfilling a promise made at an enthusiastic Paul Boag workshop back in April (yes, Paul, I know…) by writing a short post about being a Jack of all Trades and how I feel this is sometimes wrongly devalued within the web industry.

I’ve had many different roles in my career from Junior Developer to Lead System Designer or Solutions Consultant to Community Manager. I’ve not got the typical experience of a “web guy” as I’ve spent the best part of 15 years in large enterprises and have not been one of the cool kids in one of the many fantastic agencies that exist – yes, that is envy. Each role that I’ve held has required a different set of skills at a given point of time meaning that I’ve had to be somewhat of a “Knowledge Chameleon” (I’m bagsying that!) and adapt to my environment. Whether it be knowledge of a proprietary system or understanding of the latest web standard, I’ve always had a “Just In Time (JIT)” education approach – JIT the term itself being learned from my days as a Java developer. Whilst this sounds a little fly by the seat of your pants, I’ve always made it work and made sure that I’ve understood what the experts are doing in a given space to guide my own practices and standards for the benefit of the customer.

So why am I writing this almost-on-the-verge-of-a-rant post? Well, I read all too often that Jack-of-all-Trade types aren’t as valuable as specialists. The most recent netmag contained an interview with the well respected Sarah Parmenter and the advice given once again for those starting out was along the lines of ‘be the best [insert specific skill here] in [insert a geographic area]’. Whilst I have tonnes of respect for Sarah and others who have said similar things in the past and am certainly not looking for a fight, I don’t completely agree.

I personally enjoy the fact that I have good appreciation about good design and typographic principles, good knowledge about HTML & CSS & UX best-practices, solid JavaScript knowledge, sound ability with several server side languages along with very good knowledge of enterprise back-end systems like Salesforce and I know what makes a good CMS.

“Big wow” [with rolling eyes] you may think to what may come across as a bit of an Ego-w*nk… and I would tend to agree. The value is not the skills themselves but rather how knowledge across domains allows for a ‘just right’ and appropriate solution to be proposed to a client regardless of the project size. In one project, I may have the luxury to oversee how the proposed solution is executed and brought together using what knowledge I have to liaise and discuss challenges with experts in each discipline. In another, I may be Mr. Hands On and Chief Get Things Done Officer who has to execute against his own plan. This flexibility is something I absolutely love and I feel it provides great value to my clients and gives me an edge over the competition for a given size of customer.

All that said, I am my biggest critic and would be first to recognise where I am weaker in some areas and stronger in others and am very open and honest about handing things over if they can be done better. Whilst I selfishly find closing the knowledge gap exciting because I sense an improvement in those weaker areas with every project I undertake, I do agree in part with the web gurus whose views I’ve taken exception to – focus is important. That focus or speciality level within a discipline however, has a context.

A case in point may be around my weaker design skills. A customer may have a limited budget initially and may need to have a site built out for a specific business need. I could come along and do a good job with the view that if things take off for the customer, there may be budget in the future to get a design rock-star to come in and take things to the next level to help increase conversions or another goal. Therefore, my job would be to future-proof and facilitate this potential future task by creating the site using well structured semantic HTML and well organised CSS (I like the SMACSS approach personally) and decisions within the front and back-end should be made with this context in mind.

This surely has value for customers who may want to spend incrementally, which also fits perfectly with an open and agile approach that many of enjoy as standard nowadays.

Given this, whilst I completely agree that you should use the best tool for the job and use the best person for a given job where the various constraints permit, I also think that the Jack-of-all-Trade types should be given a little more encouragement as it is most often those types of people who get things off the ground and get things done.

I have to admit to an exception here that may in some way contradict what I’m saying in that although I’m a passionate JOAT (brilliant, I’m basgying that too), I do suffer from the Cobbler’s Children Syndrome, which is why I’ve still not ‘got things done’ with my new site to show the projects I’ve worked on since leaving the slow and politics filled corporate world recently so you’ll have to forgive that indiscretion.

Oh well, I’m still a Jack of all Trades for my clients and get things done so I think its OK. 

 

 

 

What do you think? Do you agree or disagree? What is your experience?

Let me know in the comments.

The Importance of Architecture

I get the feeling every now and then, that software products or solutions sometimes fluctuate too much towards one end or the other in the technology-business scale (or bottom up – top down).

Now, although I’m a technologist, I favour a bias toward the business end as any technology should surely serve a purpose and should not be built because it can be built.  I have seen this challenge play out several times in my career as I have witnessed technologically motivated people build ‘cool’ apps or tools with weak consideration of how it fits the business need.  Therefore, I normally strongly argue that any software development process must be top down.

I should clarify this – When I say must, I actually mean: should predominantly be.  This is because, good foresight from someone who understands the technology and appreciates enough of the business domain knowledge often facilitates the better and more successful solutions/products/tools.  How many times have you heard people talk about getting software developers exposed to the everyday business challenges?  A lot, right?  Whilst I agree in the sentiment of this, I do not agree as passionately as some as I believe it is not an individual developer’s responsibility to ensure a solution fits a need.  Instead I believe that it is the responsibility of the process to ensure that a requirement is created by those with the business domain knowledge and translated successfully along the software development journey between those who handle it, each understanding the part that means something to them.

Process itself, is something that I could discuss in a series of posts on its own so I will end that particular point here.  However, the relevance of mentioning process is that it shares that same slot of being an unsung hero of importance alongside architecture.

Getting the right architecture in place facilitates the evolution of a software offering in the right direction.  Architecture is just the broader blueprint for complex systems as what idioms can be for a specific coding problem.

Having a good understanding of architecture and how the various pieces can fit into it can allow an organisation to best structure their teams for success.  Comparing similar offerings with perceived overlap on an architectural basis allows for rational judgement of where best to combine efforts.  Such comparisons can be easily made through applying the age-old Model View Controller (MVC) pattern across systems to further disect the roles of many product teams or systems.  Such architectural understanding, which can be focused or abstracted to the right level coupled with business knowledge provides that critical bottom up part, enabling and preparing organisations for the road ahead.