Are We Just Processes in a Data Flow Diagram?

Reading
Donald Latumahina's post on inputs reminded me about data flow diagrams. Donald argues that inputs determine outputs, which is similar to the rule that states that a process can not be a source of data, but rather only transform inputs into outputs.

Have bad inputs, and you get bad outputs. The logic seems reasonable enough at first glance, but can our minds really be simplified to a single process on a sheet of paper?

Commenting Code

Commenting code is something that all programmers, especially the students and newbies, are constantly reminded to do.

But how do you best go about it, and more importantly, how do you know when to add comments? Steve C McConnell says a good place to start is with good code:

Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?' Improve the code and then document it to make it even clearer.

The worst code i've seen would not have been helped by adding comments. The code itself needed to be drastically changed.

Code which has a logical structure and meets the requirements of Obejct Orientated design can often be worked out. It is when the programmer him or herself does not know what the class is meant to be doing that problems arise.

So sort out the code and comments will naturally follow.

UK Internet Millionaires Move Down Rich List

11 of this years 15 millionaires who made their money via the internet have moved down the list.
What does this mean for those of us who want to join them?

Empowerment - Nobel or Patronising?

Empowerment goes to the heart of good governance, good democracy and good business. Being a leader is not about getting someone to do a task but making them want to so they do it without asking.

Lisa Haneberg has something different to say about that:

Saying you want to create a work environment where people do their best work and then failing to collaborate with employees (notice I did not say empower, which is generally a fake term and patronizing) about projects and decisions that affect their work - that's management on the cheap.

Apparently empowering people is 'patronizing'. Having experience in politics, I know this to be far from the case.

She does however touch on an issue that many free thinkers and leaders forget; that not everyone shares our vision. I have seen many people lose their control with employees, who are often earning the minimum wage, for not going above the call of duty.

You must not forget that whilst you have invested everything into a project; belief, time and money all for a greater spiritual or financial return, those you have brought in won't have. After all, why should you work your butt off for a low wage, or if viewed differently, low Return On Investment? Empowerment, a term used often in politics, is superficially thought about meaning 'how' to get people active and involved.

If you dig deeper, it is however about something different; the 'why' should people get involved.

Solve this latter question and the former will follow suit. As entrepreneurs, team leaders and blue sky dreamers, you must think about the 'why'.

• Why should people believe in your idea as much as you do?
  
• Why should people work their buts off for you?
  
• Why should people work harder the ruder you are?
  

If you can empower people, you can do one of the key things required of you as leader and rainmaker; motivate. Help people share you vision by focusing on the why, and the how and if's will follow.

Leading, Not Managing

Leading a team can be hard work. My father always said that when leading a team you had to be able to do what they did, and take on the extra responsibilities that come with leading a team in 'extra time'.

As a child and then teenager, this marred with my own views of being a leader that came from watching many macho films. I had always wanted to be an officer in the British Army, and was well suited to it. Not incredibly intelligent, but active, fit, a desire for action with a smattering of backbone and dislike for the mundane and average meant I was well suited to it. The only reason I did not sign up was due to having grown a conscience - would I be happy with fighting other peoples wars?

This article is not and debate on the merits and place of an army in a democratic society. But leading at the time did seem to me like doing what others could do, but for longer, better, and harder.

As someone who wanted to be an officer I believed you had to lead from the front. That meant being able to run faster, lift more weight, work for longer and just do more work better.

That all holds true, and went some way to gaining a lot of respect from older colleagues in the cadets.

However leading is more than just doing more work. It is more than managing. It is about people. Leading and managing often get confused. In the article manager or leader the distinction is made clear.

Selection of those who work with and around you is important. Unfortunately there will always be people who are happy to live the nine to five, work to live not live to work live life style. You need to make sure you can get the best possible team around you.

However once that is done, are you doing the best you can to keep people motivated? Getting bogged down in the nitty gritty of programming, something that is enjoyable and invigorating, could be detracting from your true responsibilities.

Your job may not be about running faster, but making sure other people do.

Getting To The Top - Programming or People?

What is interesting about this article , from Aleksey Shevchenko, aimed at application developers on how to succeed at job interviews?

People skills are number one. This is not say that technical ability or business knowledge is not a pre-requisite. It isn't possible to be a doctor without having detailed knowledge of medicine, or a mechanic without knowing the internal working of a car. The same goes for programmers.

But who gets to the top of their profession, and how do they do it? Is it by being factually/technically correct but obtuse and arrogant, or by merging your technical skills with an awareness and understanding of how other people operate?

You guessed it... Become an excellent programmer, but don't forget those other 'softer', but no less important, skills.