Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Re: Cut yourself some slack!

swatts
Active Participant

Hello Would-be slackers,

I used to work really hard! 80 hours a week, all brain time, my mind would be busy (felt fast and noisy in my head). I was amazingly productive for a while, until I wasn't! I was also "productive", I wasn't very creative, I had no spare capacity for that.

I think this is what a lot of employees demand of their staff, it's a taught behaviour from school, college and university ....... and LinkedIn....

 

So in LinkedIn fashion here's my morning regime (for public consumption)

 

5:30 am for an ice shower

5:45 10k run, I like to use this time to listen to business or self-help podcasts

6:00 another ice shower and time for 30 minutes of meditation

6:15 start work

8:00 I eat a raw rabbit that I hunted during my run

8:15 work

9:00 interact with family (these times are so important to me)

9:02 work

12:30 Lunch and 150 crunches, I like to call it Lunch n Crunch, sometimes I like to Brunch and Crunch too. But never Brunch and Lunch!

13:00 work

18:00 tea (English for dinner)

18:30 Interact with family

18:32 work

2am journal

3:am bed, where I only dream of the successes I've had

 

Obviously that's nonsense...

 

I get up at 8, work until I'm bored or hungry, finish work at 5 and interact with my family a lot. The reason why is because the LinkedIn work-ethic will kill you and your ability to think... and thinking is actually important.

 

Ideas and the pursuit of ideas come from a quiet brain and time to execute.

 

I've written about it before, but if you allow your brain to run too hot for too long, there will be a reaction. And it can be life-changing.

 

But there are also sound business reasons to cut yourself and people who work with you some slack.... 

 

I have a theory on business management …

If you deliberately understaff a job, the assigned staff will work harder to achieve the tasks (because people like to complete their tasks). So there is a policy to deliberately understaff roles to the point of having zero spare capacity. Our management therefore, has achieved 100% efficiency, what a brilliant manager!

 

I spent a lot of time in production management and in my work life trying to achieve this ridiculous goal. 

 

To counter this here's some fairly candid, internal SSDC numbers - (illustration only, our rates are going up!)

 

If we earnt our standard hourly rate for 48 weeks of the year and 40 hours a week we would earn..

 

Based on an hourly rate of $100/hour and firm fixed price work.

 

2 people x 48 x 40 x 100 = $384,000 a year.

 

Let's compare that to our recent average earnings for the last 3 years - $224000 (before tax and expenses)

 

Our efficiency is therefore 224/384 = 58%

 

This number is important, you can view it as being terribly inefficient. But we're under no illusion that what we charge is what we earn. And that is because we spend 42% of our time on ourselves and our customers. We can afford free support, we can investigate new technologies, we have time to strategize. Currently our customer base is 100% returning customers and we're not actively looking for new customers and this can be attributed to our inefficiency.

 

Our inefficiency also allows us to run our business without much boring logging of hours, we can view a project as a thing that needs completion, not some hours that need to be kept to. This makes it a far happier process and fits with our way of working nicely. It also allows us to cut our customers some slack, we have never gone back to a customer to renegotiate an agreed price in all the years I've been doing this.

 

Obviously, this is only a sample of 1 (SSDC) and specifically about a partnership with experience people, but I have talked to other Partners that have a similar customer retention rate and their efficiency rate is remarkably similar.

 

Anyways cut yourself some slack, that spare capacity is important

 

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments
Thoric
Trusted Enthusiast

I feel freed. Thanks for adding value to the 'inefficiencies' for which one can so readily punish themselves.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Taggart
Active Participant

You should always build some slack into the system.

 

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
joerg.hampel
Active Participant

I can confirm that slacking seems to work, as our numbers are similar. We have an "efficiency" rate - ratio of billable time vs. total time - of just above 60%, and the vast majority of our work comes from happy longterm customers.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


mbremer
Member

Been think about this recently. Watch this video where he talks about crunch culture in the game development industry. Seems a lot crazier than what I'm going through right now, but definitely parallels my experiences.

swatts
Active Participant

What a great video, sums up my rage nicely when I see people coerced into this behaviour.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Intaris
Proven Zealot

My son (who is now 18) has gotten big into fitness and building muscle.

 

One of the biggest things he has had to learn is respecting recovery time. Over-training a muscle can have disastrous results, injury, inflammation, you name it. He has learned to "take time" to relax. Sleep. Nowadays, people have come to realise that sleep is one of the most important parts of training. After that comes diet. Everyone thinks "lifting heavy" or "time at the gym" is on top spot. It isn't. It's maybe at position 3 or 4 on the list.

 

There's a lot going on in our bodies (and our lives) that needs to be respected, recovery is incredibly important because results are obtained over long periods, not short intervals. Patience and discipline are key. And contrary to what many say, discipline includes LEARNING TO SLOW DOWN. As counter-intuitive as it initially feels (one could say as humans we're programmed to be action engines 😉 ), it yields the best long term results. By far.

 

Our line of work is no different. Same biology, same stresses. And on that note, another recommendation of one of my favourite Authors. The book "Why Zebras don't get ulcers" by Robert Sapolsky is a neuroendocrinilogists explanation as to why chronic stress is probably the number one completely avoidable source of ailment in today's society.

swatts
Active Participant

I have just ordered it...

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Intaris
Proven Zealot

Here's part of his conclusion of that book (After chapters full of physiology and science explaining how all the different parts of our body are interconnected via hormones and how hormones are affected by not only the world, but our own mental approach to it). Science background is of benefit when reading the book, but it's written in a very approachable way.

-------------------------------------------------------------

Sometimes, coping with stress consists of blowing down walls. But sometimes it consists of being a blade of grass, buffeted and bent by the wind but still standing when the wind is long gone. Stress is not everywhere. Every twinge of dysfunction in our bodies is not a manifestation of stress-related disease. It is true that the real world is full of bad things that we can finesse away by altering our outlook and psychological makeup, but it is also full of awful things that cannot be eliminated by a change in attitude, no matter how heroically, fervently, complexly, or ritualistically we may wish. Once we are actually sick with the illness, the fantasy of which keeps us anxiously awake at two in the morning, the things that will save us have little to do with the content of this book. Once we have that cardiac arrest, once a tumor has metastasized, once our brain has been badly deprived of oxygen, little about our psychological outlook is likely to help. We have entered the realm where someone else--a highly trained physician--must use the most high-tech of appropriate medical interventions.

These caveats must be emphasized repeatedly in teaching what cures to seek and what attributions to make when confronted with many diseases. But amid this caution, there remains a whole realm of health and disease that is sensitive to the quality of our minds--our thoughts and emotions and behaviors. And sometimes whether or not we become sick with the diseases that frighten us at two in the morning will reflect this realm of the mind. It is here that we must turn from the physicians and their ability to clean up the mess afterward and recognize our own capacity to prevent some of these problems beforehand in the small steps with which we live our everyday lives.

Perhaps I'm beginning to sound like your grandmother, advising you to be happy and not to worry so much. This advice may sound platitudinous, trivial, or both. But change the way even a rat perceives its world, and you dramatically alter the likelihood of its getting a disease. These ideas are no mere truisms. They are powerful, potentially liberating forces to be harnessed. As a physiologist who has studied stress for many years, I clearly see that the physiology of the system is often no more decisive than the psychology. We return to the catalogue at the beginning of the first chapter, the things we all find stressful--traffic jams, money worries, overwork, the anxieties of relationships. Few of them are "real" in the sense that that zebra or that lion would understand. In our privileged lives, we are uniquely smart enough to have invented these stressors and uniquely foolish enough to have let them, too often, dominate our lives. Surely we have the potential to be uniquely wise enough to banish their stressful hold.

-----------------------------------------------------------------

 

The lesson is: We must start taking care of ourselves WHILE WE STILL FEEL GOOD. Contrary to the "I can push a bit harder" mentality of our day, constantly looking for balance and spending time and effort identifying our places/people which make the statement "Stress is not everywhere" true for us is incredibly important. Do it as if your life depends on it, because it might. Find what works for you and be unapologetic about it.

 

I will freely admit, I was not ready for this message 15 years ago. I could have read this book and gotten nothing from it. Age (and kids) has taught me a lot and I now recognise what he writes to be so true. The very things I would have scoffed at years ago have become so dear to me.

swatts
Active Participant

And a note to managers, burning out your most valuable resources is NOT efficient.

 

I've been doing this type of work for 40 years and I still love it - I have about 80,000 hours of experience! So even a slow learner like me can be be described as having mastery over a subject. My intention is to work another 20 years (at least)

 

And as Shane says... this takes discipline, the discipline not to be consumed by the thing you love, or bullied into working on projects where the under-resourcing is deliberate (pressure=profit)

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Dhakkan
Member

Nice posts!

 

These whimsical thoughts popped in... The billable:slack ratios posted are so close to the Golden Ratio! Pursuant to Intaris' post, using the slack percentage against 24 hrs even gives us a ballpark of recommended sleep/nap time. Coincidence? 🙂

 

swatts
Active Participant

At some point we should do a presentation on this subject matey!!

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

joerg.hampel
Active Participant

Wow, what a conversation. Thanks Intaris and Dhakkan 🙂




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Jacobson-ni
NI Employee (retired)

My group rarely has billable hours but we aim for 65% of our time going towards all of our planned customer facing activities.

 

I wouldn't be too surprised if the developers we have working on customer projects are working at closer to 90% efficiency but I would attribute that to the fact that a lot of the efficiency losses that someone like Steve would encounter would just be another person's job at a large company.

Matt J | National Instruments | CLA
joerg.hampel
Active Participant

We do not analyse efficiency rates of individuals, Matt, but I agree that different roles have different percentages. I wouldn't want to see my number compared to my colleagues'.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Taggart
Active Participant

That's why it is important to measure outcomes (value delivered) not outputs (hours).

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Jacobson-ni
NI Employee (retired)

At my level/role time is more of an input anyway. If you're not getting paid for your time then it's a cost so you have to look at how much value you generated against how much time you spent to get that value.

 

Also our "non-customer" time isn't just all wasted meeting time so we can't just say that bigger number means better employee.

Matt J | National Instruments | CLA
joerg.hampel
Active Participant

> Also our "non-customer" time isn't just all wasted meeting time

 

I was talking about paid time vs. unpaid time. I'm not saying that we're wasting one third of our time. Also, I'm not evaluating my employees (or myself) - we're trying to keep track of how our projects go.

 

But this statement alone goes to show how difficult it is to evaluate the performance/outcome/value.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


joerg.hampel
Active Participant

> That's why it is important to measure outcomes (value delivered) not outputs (hours).

 

Sam, while I agree that outcome is important, I cannot operate without taking hours into account. Time is what my employees owe me, legally. 

 

- I can say "hey, we finished early, you can punch out, I'll give you paid time off".

- I cannot say "you are taking longer than expected, you'll have to work through the night without clocking the extra hours, you're not getting paid for taking longer".

 

Our estimates are based on how long it will take us to get something done, measured in hours, days, weeks. We estimate the cost and the date of delivery. We have very few customers who accept an agile-like way of working for them. Most need a fixed price for a fixed outcome to be even able to place a purchase order.

 

In order to plan accordingly, I *have* to know how long something will take. Then, during the implementation phase, we keep track of the time we estimated vs. the time we spent (and an estimate of how far along we are, i.e. does the amount of time spent match the amount of work done). This helps us understand whether we're on track or maybe have fallen behind. And that, finally, tells me if I need to act.

 

Like I said: We're analysing our projects, not our people.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Ozfarmboy
Active Participant

We're about 63-65%.  How enlightening!

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

joerg.hampel
Active Participant

Chris, how do you arrive at that number?




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Ozfarmboy
Active Participant

How many spare hours do you have Joerg?! 😉

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Ajay_MV
Active Participant

This is so much true I sense this even from my very first customer.

 

--

Thanks

Ajay

https://makkal.co

--
Ajay MV


Ajay_MV
Active Participant

Off-topic. I was trying to subscribe to @swatts blog which has amazing articles. It's hard to find provided latest changes ni.com forum designs. remember you have to go to the top thread of blogs in order to subscribe. Finally subscribe button is hidden under Blog options

 

Ajay_MV_0-1680193649149.png

 

--

Thanks

Ajay

https://makkal.co

--
Ajay MV


swatts
Active Participant

Thanks Ajay, 

I really appreciate it.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

wiebe@CARYA
Knight of NI

I just recently start learning that it's quite effective to stop working on time.

 

I'm very much inclined not only to keep pushing myself if things don't go well, but also to keep working when I'm on a role.

 

When you're on a high, or 'in the zone', don't just keep going. Stop, and get maximum enjoyment of that high by relaxing. Or continue, run the risk of getting stuck eventually and even if you don't, pay the price the next day.

Intaris
Proven Zealot

The thing about being "In the zone" is that I really enjoy the productivity that comes from it. So much so that it has a significant effect on my well-being after such a productive "burst".

I have learned (due to having quite a lot of flexibility from my job) to offset staying late when being highly productive by starting later the next day. I'll go to a bakery, get a coffee and something else to start the day more slowly.

Or I'll leave earlier and get some things done I need to handle. This way, the balance is maintained.

 

As long as my overall productivity is good, it seems to work out well.

 

For me, it's more the opposite of what Wiebe says. I need to concentrate and call it quite when things are NOT working instead of being just stubborn and trying to grind it out. When things aren't working, I feel my mood deteriorate, and I take that home with me. Stepping away, breathing and returning the next day seems to be the best choice, but it's a hard thing for me to do personally.

 

It might be an issue that my kids are older now, they're independent. There were certainly times where getting home on time was a much more important thing for me. Now, not so much. It's interesting how these things change over time.

swatts
Active Participant

Which brings me to a convo I had a couple of days ago about separating productivity from hours...

My view is that hours worked are mostly a rubbish metric, compared to line items completed.

 

Which again brings us back to slack, what is preferable? having your employees hours 100% accounted for (efficient?) or getting the work done reliably and to time, but maybe the workers time is not 100% accounted for. 

 

So hours worked are about the only tool we have to estimate a price, but we should maybe think then about contingency.. which is management-speak for inefficiency...

 

Contingency should include - support, mentoring, training, being mentored, process improvement, refactoring (accountancy, sales, marketing - if you run your own business).. All of these are part of the job...

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

wiebe@CARYA
Knight of NI

I take very poor care of myself when I'm in the zone, although productivity is great. If I'd keep working when I'm in the zone, I'll probably commit karoshi 😁.

 

But I don't stop at 5 if I don't have to (often I do) either, I just try to avoid 16 hour days (nowadays).

swatts
Active Participant

It's taken me years to shake the habit of 9-5 and feeling guilty if I haven't done my full 40-50 hours in a week..

It's actually ridiculous how conditioned I am.

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

joerg.hampel
Active Participant

My biggest problem is going to bed at a reasonable time. I suffer from migraine, and not getting enough sleep is a 100% guarantee for a migraine episode sooner or later.

 

Sometimes it's work that keeps me up, but more often it's other interesting (maybe work-related) stuff, and sometimes it's simply binging a series on one of the streaming services. 

 

There seems to be a relation between the hours I work (or rather how late I quit work) and when I eventually find the bed. Perhaps, I subconsciously require a few hours of me time - the later those start, the longer the day. So leaving work on time usually results in me going to bed at reasonable times and so avoiding the dreaded headache 🙂




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


joerg.hampel
Active Participant

> My view is that hours worked are mostly a rubbish metric, compared to line items completed.

> Which again brings us back to slack, what is preferable? having your employees hours 100% accounted for (efficient?) or getting the work done reliably and to time, but maybe the workers time is not 100% accounted for. 

 

Legally, my employees owe me time and (pretty much) nothing else. I can tell them to call it a day if the work is done but I *cannot* make them stay longer (without paying overtime) if problems occur. Which is a good thing from the point of view of the employed population!

 

Put differently: A salary is in most cases paid for time spent - a fixed amount of money for a fixed amount of hours. So inherently, there is no way to leave time (hours) out of the equation and not factor it in at some point.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


swatts
Active Participant

Yeah, my position is not terribly realistic, but it's quite an interesting discussion point.

I'm also not saying you shouldn't contract your people to 40 hours a week or similar, it's the allocation of "useful" work to that time.

I wonder how many companies have time boxes for mentoring as an example...

 

A lot of companies allocate 100% of an engineers time to projects, which is also unrealistic!

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

joerg.hampel
Active Participant

> A lot of companies allocate 100% of an engineers time to projects, which is also unrealistic!

 
Gotcha. We've discussed this so many times, I do know what your position on this is, and I agree. Just pointing out the obvious for the readership here.
 
Coming back to slacking, as mentioned above, we linger somewhere around 60% "productive/efficient/billable/useful" time... and I know that because we diligently track our hours 😛



DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


wiebe@CARYA
Knight of NI

It's a problem.

 

Some 20 years ago I read a study that people are most productive when working 32 hours a week. Not most productive per hour, most productive.

 

AFAIK some country standards are 50-60. 

 

The norm here for engineers is 40 hours (ex overtime).

 

I'd love to work 32 hours per week (the ratio change is dramatic 2/5>3/4 or 40%>75%), and have my employees work 32 hours per week. For the same rewards.

 

Theoretically, you'd have happier people, and production would be the same.

 

However, indeed a good portion of the workload is based on hours.

 

You'd have to convince customers (that pay per hour) to pay 25% more per hour, while the result is they have to pay only 20% less hours. This is actually the exact same total, but I'm sure sales won't see it like that, and  happiness in general isn't a factor. Or cheat, and charge an hour for every 45 minutes worked, but relations based on thrust work better in general.

Dhakkan
Member

Hi Steve,

 

Time for a new article? 'Cut your Team some slack!😀

 

For such slack to work, there needs to be a healthy balance of give-and-take, i.e. trust between all stakeholders that sincere effort was exercised for a given value of output. This concept goes kaput when such checks and balances (pun intended) are done solely via currency, while disregarding the intangibles.

 

The management must always remember that not all time spent is billable. BUT, it may be recorded for future business insights, whatever they may be.

 

The individual must realize that not ALL of the time spent on the task is worth recording. Extreme example: pondering about the task while commuting. However, ALL of the time spent adds to one's experience, (unless corporate fiefdom comes up with a legal way to erase one's memory engrams prior to the individual's exit from employment).

 

danijobe
Member

I absolutely love this fake schedule. "I eat a raw rabbit that I hunted during my run" and 2 minutes of family time. What a beautiful satire of "grind" culture. 

 

This is the whole thing right - we have been conditioned to glamorize "the grind" and it doesn't work for ourselves or for our employees or even for the bottom line of the organization. I see this a lot in American culture, and it's been a huge shift for me personally moving to the Netherlands and now Sweden where work-life balance is prioritized more in the culture. I still see those "rise and grind" implicit messages in our culture but I'm learning to recognize them and ignore them.

At the end of the day, we are humans who work because 1. we have to in order to pay for our lives and 2. we enjoy the work we do. Where are our priorities and what is our goal, do we need to maximize profit? Or do we want to maximize quality of life, which means a balance between having enough money and also having time to enjoy the multitudes of things we enjoy. I find personally measuring my economics in more metrics than just how much money did I make is more valuable. I also like to include metrics like did I feel good? Did I have enough time to do things I enjoy? Did I feel rested? 

 

I am similar to @intaris, I get hyperfocused at times and I like to roll with it while the hyperfocus is around, which means sometimes I will work late and enjoy that, but when it is done I have to take it easier on other days to balance it out. I also have learned to make sure I am replenishing my rest in other ways, making sure I get plenty of creative time, and active time, and social time with people I love.

swatts
Active Participant

Dani, once again you prove that the comments is where the gold is!


 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

swatts
Active Participant

Real-life is always funnier than fiction!!!

swatts_0-1693042902114.jpeg

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile