For The Perfect Programmer

There’s nothing to read here for you. Really, nothing at all.

You are a perfect programmer. Your code is the best you’ve ever seen. We all bow to your wisdom and awesomeness.

There’s nothing more for you to learn. There’s nothing left to practice. There’s nothing left to read, no conference that can teach you things, no community that can advance your skills.

There’s nothing for you in this blog post.

Continue reading “For The Perfect Programmer”

Being a keynote speaker

I wasn’t born a good speaker. I didn’t even start public speaking until very late. And the beginning was rough.

My first attempts at public speaking were very scary experiences. I literally couldn’t speak for the first 5 minutes. Luckily, Maria had a trick upon her sleeve:  she would pair speak with me and always go first. This way, my panic vanished and I could start babbling something on the stage.

Fortunately, after a lot of public speaking in communities and at conferences, I got over my stage fright. I think the turning moment was Agile Lean Europe Bucharest, in 2013. I pushed myself towards doing all the public speaking I could: a normal talk, taking over a cancelled speaker’s session and a lightning talk. After this experience, public speaking doesn’t scary me any more.

It was time for me to face the next challenge: being a keynote speaker.

Continue reading “Being a keynote speaker”

Applying the design principle of “white space” to code

I’m very interested in applying general design principles to software design. I am convinced that software design is just design applied to a specific material: code. Since design as a discipline is thousands of years old (the pyramids were designed) while software as we know it today is only a few decades old, I find it obvious that there’s a lot to learn from it.

Part of my exploration was to understand more about the design principles other designers use. One very common principle is the “white space” or “negative space”.

Continue reading “Applying the design principle of “white space” to code”

I am a designer who happens to use code

There are many ways to look at programming. Some people do it to make a living. Others want to see things working fast and hack it away. Others believe in building a profession from programming and thus seek practices and submit themselves to challenges that expand their views.

It’s very easy to pass judgement on some of these attitudes. I will not do that.  People need to live, to support their families, to feel good while working. If anything, we should be happy that we, programmers, have opportunities other people don’t.

Instead, I will present my view on programming. A view shaped by a 40 years love story and a few key events. A view that I feel is shared by a very small minority of the community. I am encouraged to present this view by tweets from the recent DDD Europe conference.

Here’s my view:

I am a designer who happens to use code

Learning from other designers

I am a designer because I build upon the tradition, the practices, the techniques and the principles of design, a discipline that’s thousands of years old. I do this by reading, analysing and adapting techniques used by other designers.

Continue reading “I am a designer who happens to use code”

An Attempt At Clarifying The “Software Design” Vocabulary

The teaser

“Design” is an overloaded term that causes confusion in software development. It has at least three meanings: design as result (as in “the design of the application is easy to change”), design as process (as in “I designed it using Test driven development”) and design as aesthetics (as in “I love this design”).

A clear vocabulary is the sign of a mature profession. Therefore, as an effort to advance our profession, I propose fixing the confusion using a more precise set of terms. You’ll find a glossary at the end of this blog post.

Continue reading “An Attempt At Clarifying The “Software Design” Vocabulary”