Thinkable about reuse

Read Nick Maliks post about "The culture of art vs. the culture of engineering".

Images That Changed The World?

I found this blog post about "Images That Changed The World?” The first thing that hit me is the cruelty we humans possess. And these images don’t even cover some of all cruelty there is. But I think it’s important not to forget and to be reminded of all terrible things there is sometimes.

I often think about the quote “The road to Hell is paved with good intentions” and I hope that humans aren’t evil by soul. For the victims it doesn’t matter if the perpetrator is evil or not but it is hard thinking that so many humans are evil by heart.

Motivation...

Robert Scoble is writing about how his boss at Microsoft used to play this video (see below) to the team members when needed. When the results weren’t good enough and when the team spirit is low all teams need something for inspiration.




I think the need for motivational activities are underestimated in the IT business. Why shouldn’t we need that? I haven’t heard many speeches or seen much of these activities at all. No, we need more team building activities and inspiring “coaches”. The project manager and the lead developer must motivate and coach the team members. My friend Micke Deurell once said that the project manager should be like a shepherd, keeping the herd together, happy and safe from the outside danger. Not that I’m resemble the project team with a bunch of sheep but I think you got the picture.

So inspire each other and if you are a project manager, an architect or a lead developer, inspire your team, the team delivery is depending on you.

Help.... we're doing it again

Help!!! We are doing the same mistake all over again.... A couple of years ago most companies didn't offer developers a good career possibility. There was a profession called developer, system developer or programmer and that's it. The companies I worked for had a maximum salary a developer could get and many colleagues reached that limit before they were 30 years old. To do a career or to make more money they had to switch career. They had to take a position as leader (with responsibility over personnel) or become project manager. Hmmm. That sounds good. They got a new administrative job because they were a really good developer. That makes sense. They got a passionate interest in writing code but now they writing word documents and attend meetings all day.

And now we’re doing the same mistake again. All good developers should become architects. Good developers (many of them with just experience of one or a couple of projects and no architecture training…) should suddenly become architects because they are good developers…. Most architects stops writing code. Why? How will they be able to be experts in developer- and technical issues and take decisions about these questions if they don’t know the technique? What architecture should we use for this project? How should we implement this? How does this work? Should we use.... Etc. The technique they once knew would be obsolete one day. You must keep up the learning. One architecture will be the best or even function for all projects. The non coding architects would be obsolete pretty soon them self. Sure you can read articles, read blog posts and attend Microsoft Live once a year to keep your knowledge up to date. But to be able to really build good IT-systems you need more and deeper knowledge then you can get from articles.

No, create possible careers opportunities for developers, senior developer, expert etc.
We need good developers and not just architects in the projects. One project I participated in had three architects and one developer (me). That was a good project team. And I have seen small projects with just one or two developers having one full time architect.

Top ten lists

When I searched for more information about the commandments in the previous post I found this great post by Jeff Atwood called "top 6 list of programming top 10 lists". Number one is obviously a favourite.

• "Complex problems require complex solutions".
• Make hard problem look easy. Don't make easy problems look hard
• Keep things simple.
• Add value all the time.
• Learn to say no.
• If everything is equally important, then nothing is important.
• Don’t over-think a problem.
• Some people are assholes.

Many truth in the lists. Everything sounds so obvious when you read this but in real life...

The Ten Commandments of Egoless Programming

I found a really great article about "The post is about The Ten Commandments of Egoless Programming" by Lamont Adams. Read the article. The ten commandments originally came from a book by Jerry Weinberg called The Psychology of Computer Programming. The commandments are:

1. Understand and accept that you will make mistakes.
2. You are not your code.
3. No matter how much "karate" you know, someone else will always know more.
4. Don't rewrite code without consultation.
5. Treat people who know less than you with respect, deference, and patience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position.
8. Fight for what you believe, but gracefully accept defeat.
9. Don't be "the guy in the room."
10. Critique code instead of people—be kind to the coder, not to the code.