General Musing

blaze your trail

Archive for the ‘work’ Category

Recognizing Signals #scrum #xp #agile #lifehack

leave a comment »

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.

Read the rest of this entry »

Advertisements

Written by Daniël W. Crompton (webhat)

January 4, 2012 at 2:24 pm

Posted in lifehacks, programming, work

Tagged with , , ,

Painful Facts For Developers #programming #foss

with one comment

I recently saw a note from the Tech Journalist Russell Holly who calls on the Scumbags of the Internet to stop making demands of developers from whom they get their free software:

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 »

Written by Daniël W. Crompton (webhat)

December 18, 2011 at 3:44 pm

Continuing Our Solitary Existence #xp #agile #scrum #programming

leave a comment »

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.

Read the rest of this entry »

Written by Daniël W. Crompton (webhat)

July 21, 2011 at 5:40 pm

Posted in business, programming, risk, work

Tagged with , , ,

Today’s Noise, Tomorrow’s Dinosaur #programming #business

leave a comment »

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:

  1. Somebody suggests or codes a feature
  2. Feature is discussed on a mailing list and in chat
  3. Feature is attacked for obvious weaknesses
  4. Feature is tested and updated
  5. Feature is implemented in the alpha
  6. Feature breaks when combined with other updates or breaks other features
  7. Mails/articles are written for and against the change
  8. Patches are exchanged and evaluated
  9. Feature undergoes further testing
  10. Feature reaches the beta
  11. Discussions on the direction of the software
  12. Possibly a branch is created
  13. Feature is updated in next beta
  14. Discussions on the feature
  15. Articles are written about the new features in the next release
  16. Feature is released
  17. Articles are written about the new feature
  18. 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!

Written by Daniël W. Crompton (webhat)

January 16, 2011 at 9:23 am

Creating a Solution for Everybody? #business

leave a comment »

Problem

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 or the 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 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 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

Written by Daniël W. Crompton (webhat)

January 12, 2011 at 4:36 pm

Inspired by Productivity #lifehacks #mashable

leave a comment »

Productivity

I was reading a Mashable item on productivity[1] 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:

  • Lunch
  • 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.

  1. 37 Productivity Tips for Working From Anywhere

Image source: Dennis Hamilton

Written by Daniël W. Crompton (webhat)

December 11, 2010 at 8:29 pm

Company Policy or People #hr

with one comment

Looking through the lens of HR

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

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)

Written by Daniël W. Crompton (webhat)

October 6, 2010 at 11:42 am

Posted in business, risk, work

Tagged with , , , , , ,

%d bloggers like this: