Archive for the ‘work’ Category
Signals come from everywhere, they are tell us something about our environment. Whether it’s hot or cold, wet or dry, and painful or pleasant. These signals are rarely binary, there are gradients in the signals. And we have signals with which we aren’t dealing at that moment, which we’ll call noise in that instance. Feedback is also a signal, perhaps it causes a painful sensation or it causes a pleasant sensation. Whatever the sensation it causes that sensation too is another signal which we can choose to regard as noise.
You don’t demand ETA’s on shit you aren’t paying for. You don’t get angry when something doesn’t work quite right on an Alpha or Beta build of something you didn’t pay for. You don’t start shooting off at the mouth about how you are going to move to someone else’s free software if this developer doesn’t fix the software you didn’t pay for.
I was naturally in agreement with the spirit of what he said. And I think that he and these developers miss a number of simple facts: Read the rest of this entry »
It’s thought that programmers have a solitary existence, in hacker movies they are often depicted as being behind a screen in the dark working on their own. Even the popular media images of programmers that are loners. As any programmer knows this is far for the truth, collaboration mostly benefits development. Sharing tasks and bouncing ideas of other developers makes the end products better. Yet with the exception of discussions the actual development task is performed by one person behind one computer.
There are many studies which show that there are even better ways to work, collaboratively create and discuss. Taking all the benefits of working as a team and sharing knowledge reduced to one continuous process rather than incremental tasks. It’s called pair programming, and studies have shown pairs can deliver 127% of what they deliver working on their own.
I was inspired by Driving Technical Change to write this. Please read the following for context:
Expertise, even for the very experienced, is a fluid thing. With the exception of abandoned technology, every tool, technique, or product that you are trying to push is changing everyday. The producers are adding more features. The community is posting more commentary. Users discover bugs, and product teams fix them. Nothing is static. Therefore, even the most expert of experts is only as good as the last thing they read. There is no standing still as an expert. And yesterday’s expert is tomorrow’s dinosaur after as little as two years of not keeping up.
I think this is a sweeping generalization which I believe is wrong, and I know is wrong for me. I regularly go on sabbatical for 3-6 months where I don’t or hardy use a computer, with hardly I mean I checked my mail once after 3 months. In this time due to the fact that I’m traveling I don’t read computer books or magazines. Coming back after this time I notice one important thing, nothing has changed except the version numbers. New features have been added to old software, new design patterns have been thought up and new frameworks have been created, whole sections of the linux kernel have been rewritten. And with in a week I am at my expertise level, and a week later I have covered most of the important things I’ve missed.
People who follow changes live are often stuck in the noise of the present, which for an expert a timeline can often look like this:
- Somebody suggests or codes a feature
- Feature is discussed on a mailing list and in chat
- Feature is attacked for obvious weaknesses
- Feature is tested and updated
- Feature is implemented in the alpha
- Feature breaks when combined with other updates or breaks other features
- Mails/articles are written for and against the change
- Patches are exchanged and evaluated
- Feature undergoes further testing
- Feature reaches the beta
- Discussions on the direction of the software
- Possibly a branch is created
- Feature is updated in next beta
- Discussions on the feature
- Articles are written about the new features in the next release
- Feature is released
- Articles are written about the new feature
- Revisions of books on the software or framework are written which include the new feature
This can take anywhere up to 6 months for larger features or changes to large frameworks. Following the noise allows you to adapt to the change over a longer period of time, and allows you to experiment more with the feature. This same result can be reached by reading the articles which are published round the time the feature is live, with the exception of the generated noise. One of the advantages is that this noise can be used for reference material, when the noise is of good quality. And this example covers only one feature for one software package or framework.
Being caught up in the daily noise also has a bigger problem. In some cases I may not be a direct contributor to a software package or framework and this noise can reduce the time that I can spend learning other things from the new books or articles which cover the other areas in which I consider myself an expert.
Something which is also neglected in the statement above is that experts have often been their and seen that. CVS works similar to SVN, which with a context shift works similar to Git. Each solving a different problem, and with the knowledge of the problem being solved it is easy to apply previously learned unrelated knowledge to new software or a new framework.
A great book!
I often build nice tools for myself, often customize them to myself with no regard for what a general users wants or needs. This is because it’s for me, and not for another, before I decide whether I release this under GPL or try to sell it I always ask myself the following questions before I make it ready to ship:
- Is there really a problem?
- Does my audience have this problem?
- Is there a solution which is better for my audience?
Let me take you through my thought process so you might better understand what I mean.
Is there really a problem?
In the case of some solutions I create, like the Roxen CMS or the YouTube Unsubscribe scripts I wrote, there really is a problem for others and myself. This doesn’t mean that everybody has this problem, just that I have it and that others probably have it too. It a problem with an easy solution, and something which can be quickly put together and released.
With other things I create, such as my script to take the items I download with Juice and order them in bundles sorted by audio, video, document or other, there is a clear problem for me, and this might not be a problem for others or this might not be the solution for others.
Does my audience have this problem?
In the case of the YouTube scripts there was clearly a problem for others, this functionality was not available. For Roxen CMS it was a case of this making life easier. Looking even further back I wrote a script which added a mark (un)read button for GMail rather than going into a pulldown menu to mark (un)read, this was downloaded quite a number of times and offered something that Google was not offering at that time.
Is there a solution which is better for my audience?
This is always a question, the solution I create is often the best for me or the best which was available at the time. It doesn’t have to be a good solution for others at all, it might not even work for others because it is too customized to my user experience that it neglects the user experience of others.
Taking the case of the Juice script all the directories are hardcoded for my system, they might work for somebody else and they aren’t designed to. The current version doesn’t clean up after itself, which means there is quite some mess left after the scripts are run. It deletes everything it doesn’t know, so it doesn’t take into account things that my audience might want such as images.
Image source: arjin j
I was reading a Mashable item on productivity which contained some interesting things that I will turn into a slideshow on this week.
Do NOT check your e-mail for the first 45 minutes that you are in the office in the morning. […] There are never meetings at that time and most people are settling in and reading their e-mails, […] — Amanda Feifer O’Brien, Marketing Manager at Firmenich Inc.
Take the first 30 minutes to plan the rest of your day. By plan, I mean make a list of the important tasks that you need to have done today and stay focused on these items. […] Make a list of the things that you want to achieve that day and work from that list until it’s completed. — Rohan Hall, Founder and CEO of rSitez, Inc
This is an excellent way to start the day, I have been using the 43 Folders system to unplan the year, this is my scheduled backlog, and take the day folder out and add this to my daily TODO list – which I write on Post-its. While creating the initial Post-its I like to create Post-its which contain:
- Coffee Break (x4)
- Snack Break (x2)
- Mail Break (x2)
And interspace these in the timeline of the day.
On my whiteboard I arrange the Post-its in the following grid:
First I take the Not Urgent and Not Important and bin them, obviously there is no reason to do them or they would have been graded differently.
Next I estimate the time and importance needed for the Urgent and Important tasks, and split the longer items into shorter tasks. Then I start the tasks by solving some of the important short tasks first to set the tone of the day to task completion, then I process the remaining tasks in order of importance. I like to use timeboxes for each of the tasks based on my estimates.
Next I estimate and complete the Not Urgent and Important items and don’t move on to estimating and completing the Urgent and Not Important until I’m finished.
Image source: Dennis Hamilton
I find a 400 plus page manual of office policies and job descriptions for each position in the office slightly excessive, I know few people who read manuals like that back-to-back unless they are finding ways to make a company policy work in their favour, or a loophole. You’ve just given them 400 plus pages of potential loopholes, unless it’s written by a lawyer, then you have given them 400 plus pages of information which is impenetrable to them, and in which they will have to pay a lawyer to find the loophole which is almost certainly in there.
Even if the average employee could read, understand and recall 400 plus pages of information at 1 page a minute it would still take them 6 2/3 hours to read the manual. Do they get paid for these hours? What if it takes them slightly longer?
Employees are often asked to go above and beyond the call of duty, these job descriptions and policies are a disadvantage for the company also. I’ve seen companies give detailed job descriptions – including a specific location – and then have a policy which contradicts this by saying that location and duties are determined by the company. I’ve seen high-value producers leave because overanxious HR departments following policy without using judgement have send official warnings on first offense policy violations, they go to competitor companies were the working environment was less hostile.
Read more articles on Human Resources…
I’m not saying to have a 400 plus page manual which covers office policies and job descriptions isn’t helpful, it can be very valuable. Although I’ve found that companies who give their employees manuals which stretch to 400 pages are usually companies, and specifically HR departments, who need a way to exercise control which they do not have. Perhaps it is wise to look at the company structure and size, and regain the control by having control.
(Image source: stikone)