Be A Productive Web Developer When The Internet Is Down

Recently, I was met with a partial working day without internet. As a business owner with many clients, being a web developer, and as a general internet user with a mild tendency to enjoy checking technology blogs, this scenario had potential to be a scary thing let alone quite inconvenient. However, productivity rose substantially as I discovered that I could complete a lot of my tasks and online activities offline, breaking the grand illusion that I needed an internet connection to work and be productive. Another added plus was that I was now distraction free.

A brief outline of how I worked without internet includes simply this: drafting emails in CODA (my coding text editor) saving each to be distributed at a later time, preparing quotes – which I found very therapeutic and self – motivating discovering that all the expertise needed was either in house or vested within – , using books as information resources when necessary, and completing work using my local development environment rather than through an external web server and then committing the changes later on. Apart from that, I feel the time could be used wisely by strengthening client relationships through use of the telephone, or scheduling time with your business colleagues to work on floating demands or internal business processes. Perhaps work out a new process to follow as default for when the internet goes down for half the day.

Client Training or Formal Testing?

Late last year, I had a meeting with a client that we had geared up and planned as an early training meeting. Unfortunately, when I went through the training with the client on the day, we faced all sorts of problems including bugs, software errors and not to mention a delay on the server. Ultimately, this experience was costly and ended up leaving the client questioning us, and us feeling a lack of professionalism. During a later review of the meeting, we discovered that the meeting was actually very productive. The meeting had allowed us to uncover the errors that could only be properly found through the exploration in primary user scenario testing. We were also able to reevaluate our own management processes and discover that our project charter hadn’t properly considered some very important tasks. This allowed us to deliver a more refined product. We then decided that the meeting was important, and to keep it, but the trick was renaming and thus reframing the meeting context for the client so that expectations were properly met .

Instead of labelling the meeting an ‘Early Training Session’, we decided to label it a ‘Formal Testing Session’. Reframing the meeting context reframes the expectations of the client. As a Formal Testing Session, we’ll still be able to meet our goal which is Training the Client, and just as importantly, the client would be able to help us go through the project as an administrator, and iron out the bugs encountered in that particular and very important user scenario.