How We Work

Building Conscious Engineering Teams

noreply@blogger.com (razor_nl) — Tue, 31 Mar 2015 18:08:00 +0000

Work

noreply@blogger.com (razor_nl) — Sun, 28 Feb 2010 23:49:00 +0000

Your Brain at Work - video

noreply@blogger.com (razor_nl) — Fri, 04 Dec 2009 17:44:00 +0000

Let me quote the video's description:

In his new book "Your Brain at Work," coach David Rock depicts the story of two people over one day at the office, and what's happening in their brains that makes it so hard to focus and be productive. Not only does he explain why things go wrong, but how you can train your brain to improve thinking and performance at work. Based on interviews with 30 neuroscientists, he's developed strategies to help you work smart all day.

Interesting subjects being covered are: why managers screw up your job satisfaction; why smart people are better at managing their own productivity; where actual job satisfaction comes from.

Regarding that last one, it appears that our brains have built-in sensors for:

- certainty,
- status,
- fairness,
- autonomy,
- relatedness.

Whenever we experience a threat to one of these, we experience negative emotions, and vice versa. Remember, this is built into our brains. Very enlightening stuff.

I'm curious to know what mind-tricks or psychology/neurology topics you use or encounter when at work. I usually have a good self-monitoring system telling me when I'm being productive, or warning me when I need some down time.

private/personal time and the networked individual

noreply@blogger.com (razor_nl) — Thu, 12 Nov 2009 21:13:00 +0000

Coined as a talk about intimacy in the digital communication age, this presentation by Stefana Broadbent turns out to be more about how constant communication with people in your private and professional networks blurs the distinction between private and professional spheres.

The steadily emerging culture of networked individualism, enabled by the abundance of communication methods, is slowly changing the private/professional divide. Broadbent accurately describes how fixed times and rituals, extended periods away from (the location of) the private sphere have defined the working life. It appears even our schools are modeled in this fashion to prepare kids for their working lives to come.

This either/or proposition is now slowly eroding. Since communication technology evolved, means of communication have been eagerly adopted by networking individuals. Only when the communication channels (e-mail, instant messaging, texting) became less interruptive and more casual (as opposed to, say, the telephone), everyone jumped on it, and started blurring the divide.

This blurring of the work/private boundary goes both ways. Private time is invaded with work demands, and 'office time' is sometimes used for private matters. Why do we think this is so strange? I can't think of a reason other than our centuries long habituation and (I suspect) a tendency for group-think. You're either inside or outside the organization. You enter in the morning, leave in the evening.

Once the communication channels were unobtrusive enough to be used at the work place without the boss noticing, every one started to cross the divide, and reach out to their private network, which consists for the most part of other people at their workplaces, doing the same. So much for private/professional and inter-organizational boundaries.

A common, natural reaction from management was to forbid these boundary crossing activities and make sure every one was still 100% work focussed for 8 hours a day.

Interestingly, managers love the fact that they can now make work demands when you are in your 'very separated' private sphere, but this newfound 'flexibility' should go one way only (namely theirs), it appears.

What are your experiences, as a networked individual trying to cross the private/professional divide? How does your company handle it? Do you think it's important? Leave a comment, I would love to hear it.

Leadership and Vision

noreply@blogger.com (razor_nl) — Mon, 02 Nov 2009 14:57:00 +0000

Highly recommended video:

From the youtube page: "Jerry Porrass research interests are the characteristics of visionary companies in both the United States and Europe; the dynamics of planned organizational change process; organizational vision and its influence on the long-term behavior organizations; and leadership."

Most notable point for me was the speakers answer to a question from the audience, about what one could do if someone 'higher up' was screwing things up or being very counter productive. Paraphrasing: don't confront directly, you will lose. Just spend energy where you have influence. If you and your team under your influence spend enough time doing crazy stuff to counter the bad influence, in order to still produce some results, this waste of effort will get noticed higher up. Then, salvation will come.

Of course, in a democratic organization this sort of bad influence and the resulting waste of energy to counter it, would never happen in the first place.

Dan Pink on the surprising science of motivation

noreply@blogger.com (razor_nl) — Mon, 24 Aug 2009 22:24:00 +0000

Please, please, watch this. Career analyst Dan Pink examines the puzzle of motivation, starting with a fact that social scientists know but most managers don't: Traditional rewards aren't always as effective as we think. Listen for illuminating stories -- and maybe, a way forward.

we are the elite who can.

noreply@blogger.com (razor_nl) — Fri, 02 Jan 2009 22:50:00 +0000

Image by bitmask via FlickrI just ran across this from the Coding Horror blog. I'm glad to say all of my colleagues are within the apparently elite 1% who do know how to write code. Maybe I should challenge them with this task to make sure ;)

Notification for feed consumers

noreply@blogger.com (razor_nl) — Thu, 01 May 2008 23:39:00 +0000

The rss feed for this site has been changed to http://feeds.feedburner.com/howwework.

Please update your rss clients.

Automation for the people: Continuous Integration anti-patterns

noreply@blogger.com (razor_nl) — Tue, 08 Apr 2008 20:43:00 +0000

Image by Phillie Casablanca via FlickrAutomation for the people: Continuous Integration anti-patterns discusses some interesting no-no's in software development team practice.

Today I ran into one, namely 'infrequent check-ins' but it was hidden under a pile of branching/merging confusion.

I was discussing branching and merging strategies for the development teams with one of the team members. He explained how work was done for some time, apparently to his satisfaction. A project team would branch off a release branch at the point when a release was going in acceptance test. The team would work on that, fixing issues, and would never merge back into the trunk, except for some cherry-picked bugs.

So far, I don't object to this way of working, but I introduced the idea of personal branches, or an alternative, feature branches, where developers would create branches for every feature, work on that and then merge it back into the stream of the release where that feature belonged in. Wholesale merges, in other words.

This was out of the question. Merges were supposed to be controlled, high exception operations performed under high levels of scrutiny.

This encourages infrequent check-ins: it prevents developers from doing frequent check-ins while working on their own corner of the project. A developer shouldn't only check in when they want to add a major feature; Ideally one should check in after every few lines of code which prove ok. However if one pollutes the main source tree with every little commit, then, yes, this is impractical.

The solution however is not to delay or generally discourage merges. One should setup branching policy so that developers can check-in however often they want without bothering the main line.

Conclusion

Sometimes it takes some time to discover a bad practice in disguise. The no-no of 'Infrequent Checkins', and all the other anti-patterns too, can be disguised in many ways of 'practice' which seems perfectly reasonable by itself. Until you fully work through the consequences.

Btw, don't forget to read part 2 of the anti-patterns article.

The Selfish Class

noreply@blogger.com (razor_nl) — Wed, 26 Mar 2008 23:03:00 +0000

The Selfish Class

Another gem from the author(s) of 'The Big Ball Of Mud' (see links in the sidebar).

The basic question of the essay is what would a class need to have/do in order to promote its own re-use.

The Years of Experience Myth

noreply@blogger.com (razor_nl) — Thu, 28 Feb 2008 01:12:00 +0000

Coding Horror has an article on how to find good programmers, and how not to: The Years of Experience Myth

Image via WikipediaActually, when I went through my latest job hunting exercise (which ended quite happily), I had a recruiter who started out with counting the 'years of experience' per programming language that I had. Since I have been collecting them all (not really, but I like to diversify), I had at most 2 to 3 years max in each of them. This would make me slightly above junior level in any of those languages at most.

After a few discussions, I managed to convince him of two things: First, your missing the bigger picture of my capabilities this way, and second, programmers do not like to be recruited this way. It tells much more about the (lack of) capabilities of the recruiter than of the candidate.

Lucky for me (and him I suppose), the recruiter came around quickly, and found a great job for me. I forwarded the above article to him afterwards, since it so aptly confirms the point I was trying to make at the time.

How not to design space shuttles. Or software.

noreply@blogger.com (razor_nl) — Sun, 24 Feb 2008 18:54:00 +0000

Gustavo Duarte provides us with Richard Feynman, the Challenger Disaster, and Software Engineering, showing parallels between Space Shuttle engineering and software engineering. Very lucid, as to be expected of Mr. Feynman.

code quality

noreply@blogger.com (razor_nl) — Tue, 19 Feb 2008 21:45:00 +0000

See kids? Modularity is good!

noreply@blogger.com (razor_nl) — Tue, 29 Jan 2008 22:58:00 +0000

Here's a good one: we show that tightly coupled components have a higher probability of survival as a design evolves; in essence, they are “harder-to-kill.” We also find that tightly-coupled components are harder to maintain, in that they are more likely to experience surprise design changes unrelated to newly added or removed functionality. Finally, we show that tightly-coupled components are harder to augment, in that the mix of new components added in each version is significantly more modular than the legacy design. These results have important implications for managers, highlighting the impact of design decisions made today on both the evolution and maintainability of a design in subsequent years.

Basically they say that you don't want to mess around with objects that are hard to kill. I tend to agree.

Ok, now that I've actually read the article, it occurred to me that the central, hard to kill objects in most applications are the data objects. These are the payloads of data you pass around as arguments between your methods.

The key concepts of your business are represented by data objects, ie. customer, account, order, product etc. These objects are used by many of your processes, so data objects have a high visibility (good for survival, not good for adaptibility). Thinking long and hard about the definition of your data is thus a money saving tactic.

Image via WikipediaOk, maybe I go a little fast here. The href'd article also shows that in later releases, much of the maintenance effort (read: cost) is sinking into the legacy, hard to kill, hard to maintain, objects. I propose that data objects are a fair share of that. This implies that designing your data objects well can cut on maintenance costs later on in the project.

The actual technology that produces the data objects isn't under discussion here. I don't care if my CustomerObject comes out as a POJO, entity bean, or as a chunk of xml. The actual data and definition of a customer, that's what I need to know.

In this regard, the REST architecture fits nicely. Within this architecture, most of the design effort is concentrated on the data formats, or resource definition. In contrast, the operations on that data are simple, as in equivalent with HTTP commands (GET POST PUT etc). This way the design effort must be spent at defining meaningful resources and formats.

Another thing comes to mind. The XML folks have over time gained some experience in how to handle evolving specs for their formats. This knowledge is perfectly suitable to 'evolve' entity data objects into more modular forms , so that they do not become legacy (see again the pdf for how that's bad).

Maybe it's worthwhile to think about refactoring data, or designing data for modularity and adaptability?

How to Sneak Social Media into the Enterprise

noreply@blogger.com (razor_nl) — Thu, 10 Jan 2008 21:16:00 +0000

How to Sneak Social Media into the Enterprise

The issues organizations usually have with this style of working stem from the rise of networked individualism. This networked individualism is now just developing, but it exists within the current group- and locality-based organization of society (ie. enterprises). Where the links in the networked individual's network cross a group boundary, problems will arise (from the groups perspective) and counter-measures are taken to ensure group-think, thus crippling the networked individual's productivity.

In a group-based society you belong to many groups at once, but in some circumstances (such as when you're at work), you are to behave as if you are in one group only. I think that over time, the group strategy will become less attractive, as knowledge-workers of the networked-individual style will prove to be more productive than their inward looking, group-focused colleagues. The author of the linked article certainly proves my point.

My own belief is that linking to resources (including people) is much more efficient than copying and storing information. The corporate information network is already there and it's called the internet. Lots of expert systems are already at your disposal, they walk on two legs and may or may not work for the same company. In an always-on, high-bandwidth environment, it is probably more efficient to just ask your trusted expert-friends than to gather and hoard knowledge in a corporate cathedral.

Performance Appraisals considered harmful

noreply@blogger.com (razor_nl) — Wed, 09 Jan 2008 16:45:00 +0000

Abolishing Performance Appraisals makes a powerful case for removing this well intended yet ineffective ritual organizations have been requiring for decades. Coens and Jenkins provide solid reason why appraisals have to go, to be replaced with quality feedback mechanisms including coaching and support structures that enable employees to maximize their own potential.

(synopsis by reviewer Carlos Quintero.)

Although there is no 'cookbook' approach for designing an organization that does not need appraisals, in my opinion being democratic is a good start.

Btw, I'm reading the Dutch version.

Traci Fenton, WorldBlu CEO, on organizational democracy

noreply@blogger.com (razor_nl) — Tue, 08 Jan 2008 17:05:00 +0000

Traci Fenton on organizational democracy. The concept of organizational democracy as explained here comes very close to my own opinions about organization.

This brings to my mind Free speech versus bureaucracy, a chapter from Information liberation, challenging the corruptions of information power, by Brian Martin.

Telecommuting has mostly positive consequences for employees and employers, say researchers

noreply@blogger.com (razor_nl) — Fri, 04 Jan 2008 21:05:00 +0000

Flexible work arrangements give workers more control over their environment, which helps performance and overall job satisfaction.

Apparently that also benefits the company, as the results also contained "...that telecommuters reported more job satisfaction, less motivation to leave the company, less stress, improved work-family balance, and higher performance ratings by supervisors."

I've always wondered why the take-up of telecommuting arrangements has been so slow. One would expect it to at least alleviate the daily rush-hour traffic. Somehow the irony of going into office everyday (I work for an internet provider) escapes most people.

Social patterns in productive software development organizations

noreply@blogger.com (razor_nl) — Thu, 20 Dec 2007 21:06:00 +0000

This research paper came to my attention recently. It covers the dynamics of roles and the organization of work within software development teams. Some very interesting observations were made. For people in the software development trade most of them seem obvious, but it is nice to have some scientific backing. Now the only problem is to convince your manager to go away and let you do your job ;)

PDF

'going Bedouin' thoughts

noreply@blogger.com (razor_nl) — Sun, 28 May 2006 12:32:00 +0000

An interesting thought that finally has gotten a catchy name: Bedouin companies. Please read the article that coined the term, and this historical anecdote of what happened (a disaster) when a company actually 'went Bedouin'.

The idea is good, I think. The one problem I see is that it is probably not easy for a 'Byzantine' type company (the ones with the big main office) to become Bedouin. It is much easier to start out as Bedouin and stay that way when the company grows and ages.

Update: Apparently Jeremy Horn at the Product Guy blog agrees, opposing 'organic' vs 'manufactured' 'Virtual offices'.