The 7 Duties of Great Software Professionals. Really?

There are two reasons I am not a fan of this talk. First, once you saw Anthony Robbins' motivational speech you don't want to see anybody else. He is simply the best!

The second reason is that in this speech the author offers some challenges to developers, he suggest that setting and achieving professional goals is the way a developer should follow to become great.

Well, goals are very popular and well known self-motivation tools, but they sucks. Why?

Setting the Goals

Being driven by goals is endless race from one goal to the next one, and then when your first excitement is behind you, you may wonder: What was actually for?

As Paweł explains (in Polish) achieveing a goal is a desire of more dopamine in our brain. Every time you achieve a goal, you get a reward a in form of dopamine self-injection.

Unfortunately training yourself in achieving goals causes you get more dopamine b-e-f-o-r-e achieving and after that you get just only teeny-tiny injection. You feel not so good as you expected, so you want more dopamine. What you do then? Set next goal.

Desire of goals means constant staring at the difference between your current state (before ticking a goal off) and future state (after getting it done). This difference is Dis-Satisfaction.

However the delta form the structure above is called a resource needed to get the goal done, in fact this is the difference between two emotional states, two dopamine levels. This difference is felt as some discomfort.

The race form a goal to another one is driven by Dis-Satisfaction and the only way to avoid this feeling is more and more dopamine, more and more achieving.

Mindfulness

So let stop for a moment and try to see things as they are...
Mindfulness is a concept moment-by-moment awarness when you try to liberate yourself form the desire of achieving.

Following the mindfulness way you accept reality as it is and observe your relation to this reality. Obviously as human beings we need goals and we need achieve things. Starting it with awareness you achieve goals if needed, but you do it being awaken from the dopamine dream.

Hmmm...it was a little bit off-topic, but who cares...;)

DDD from a Non-Java/C# Developer Perspective

During 4Developers I met some friends who are PHP and Perl developers. They were very interested in what kind of value Domain Driven Design may bring to them.

They found the topic very confusing because in their opinion speakers were strongly focused on Java and Object-Oriented programming. Those developers made connection between DDD and OO-programing especially in Java and C#. I think it's kind of misunderstanding.

Let's see some examples of what domain expert could say (credits to Sławek):

Domain expert says:

When a piece of art is viewed as a thumbnail by a customer, one is able to show interests in this piece of by adding it to the LightBox.

The system should generate the offer from the reservation.

An offer contains just only available products with current prices.

A customer is not obliged to accept the offer. One is able to accept or reject it as well.

and so forth...

So we have some domain scenarios in a very unstructured form as were expressed by the expert.

To build the right software we model a domain base on expert knowledge and domain scenarios.

And here I wanna to put strict distinction: the goal is to model the domain but using building blocks given by DDD community is just a way to achieve this goal in the Object-Oriented world.

In my opinion pure DDD modeling should be based on Domain-Specific Languages when we have language to directly express what the expert says and how the domain works. This programing style is even easier to apply with some script and loosely typed languages.

So, if you are non Java/C#/OO professional, please be sure you may get benefits with using DDD. You don't need building blocks in the form they are currently presented, because they are implementation of DDD in Object-Oriented context. The core is to model the domain and maintain pure isolated model in a form suitable to the technology you use.

The Paraphrase Pattern

This article is part of my work on Conversation Patterns for Software Professionals

---

During a conversation with a stakeholder one gives you heap of chunks related to the issue. First you are unaware of language a stakeholder use, terms and their meanings and rules playing behind these elements of Ubiquitous Language. You will discover all this stuff during conversation asking right questions.

Read more about Paraphrase Pattern on http://conversation-patterns.com