I'll be there (for you) ...

Table of Contents

I am very excited and happy to announce that you can hear my talk at two Agile conferences in Europe:

Agilia Conference 2014 in Brno (I’ll be speaking on 25th March)
http://agiliaconference.com/2014/en

and

Optional Conference 2014 in Budapest (I’ll be speaking there on 8th April)
http://www.optionalconference.org/

Talk Title: Structured Soft Skills (not only) for Technical Leaders

You are not a born leader. You haven’t been prepared to be one but you were chosen to be. And then everything changed. Now you should be a good communicator, negotiator, mediator, facilitator, motivator. You have heard that you should be a servant leader, should prefer collaboration over contract negotiation, people over processes but … you think: “What the heck should I exactly do?” Most of the leadership hints are general, fuzzy and unstructured. If it sounds familiar to you, this is a talk for you.

We will talk about fundamental soft skills in a structured way. You will see a lot of schemas, diagrams, algorithms, dependencies you weren’t aware of before. This way the misty soft world will become familiar and easier to understand for left-brainers (people loving to think in an analytical way).

What We Will Talk About?

How to resolve tough (conflict) situations.
How to find a problem solution.
How to conduct effective meetings in a way nobody told you about earlier.

Who Will Benefit From This?

Technical leaders, team leaders, any other kind of leaders dealing with software development.
Leaders and all technical folks interested in developing their soft skills.
Technical guys (developers, testers, UX designers) at least having a clue that soft skills might be really important in their work.

I am excited and a little bit stressed as these will be my first talks in English.
Keep your fingers crossed and come if you can.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

A Manifesto Against Developers

I hate you because:

You focus on the features of your IDE instead of the features your client/user needs.
You consider typing at the keyboard as thinking.
You waste countless hours manually testing your code.
You spend more time struggling with frameworks than delivering value to end users.
You code for hours without asking yourself, “What am I really doing?”
You naively believe that technologies and tools will solve your problems.
You naively believe that a good algorithm is more important than a good understanding of requirements.
You naively believe that your intuition is enough for writing good code.
You naively believe that you can manage the complexity of the system piece you’re working on.
You agree to unrealistic deadlines.
You write poor code and rationalize it with various excuses (because there is no time).
In your head, you create code snippets without really knowing what needs to be done.
You guess what needs to be done rather than clarifying.
You mindlessly follow the technology you use.
You don’t understand the tools and technologies you use.
You isolate yourself in your piece of code, breaking contact with the world.
You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Antipattern: Adrenaline Junkie

Understanding Project Pressure and Tension

I constantly wonder why situations arise where pressure and tension are generated in projects. One reason is that most projects are simply complex—you have to coordinate several, sometimes dozens of people, anticipate and plan in advance what will happen, and determine what resources will be needed. As a species, we’re not very good at detailed long-term planning (see: David Rock – Your Brain at Work).

Code Cleanliness: More Than Just Refactoring Part 1

Initially, my intention was to create an article about refactoring. However, the more I pondered the subject, the clearer it became that I would not be writing solely about refactoring. It’s about something much more significant—conveying a vast amount of knowledge, essentially experience, related to code creation. Code that not only works or is well-designed but is most importantly easy to read. When we achieve this skill, we stand on the threshold of professionalism. Programming professionalism.

I'll be there (for you) ...