August 2020 : Sixro

Show Your Work! Book Review

Recently I read a book called Show Your Work!: 10 Ways to Share Your Creativity and Get Discovered by Austin Kleon.
My blog is about the things I like the most such as software design, technology, self-improvement, …
The reason I started again writing my blog is the messages found in this book, so I want to share with you some highlights I took from it…

Following I share parts of the book I found really interesting.

Genius? No thanks: Scenius

There are a lot of destructive myths about creativity, but one of the most dangerous is the “lone genius” myth: An individual with superhuman talents appears out of nowhere at certain points in history, free of influences or precedent, with a direct connection to God or The Muse.
Chapter 1. You Don’t Have To Be A Genius

There’s a healthier way of thinking about creativity that the musician Brian Eno refers to as “scenius”. Under this model, great ideas are often birthed by a group of creative individuals […] who make up an “ecology of talent”. If you look back closely at history, many of the people who we think of as lone geniuses were actually part of “a whole scene of people who were supporting each other, looking at each other’s work, copying from each other, stealing ideas, and contributing ideas”.
Chapter 1. You Don’t Have To Be A Genius

Here the idea of Scenius was really meaningful to me.
I’m the one used to think that some ideas I have are not so important to be shared.
But if you think to the meaning behind “Scenius”, those ideas can matter to someone in this world. It is important to share them, like an amateur would do it.

Amateurs are not afraid to make mistakes or look ridiculous in public. They’re in love, so they don’t hesitate to do work that others think of as silly or just plain stupid.
Chapter 1. You Don’t Have To Be A Genius

The world is changing at such a rapid rate that it’s turning us all into amateurs. Even for professionals, the best way to flourish is to retain an amateur’s spirit and embrace uncertainty and the unknown.
Chapter 1. You Don’t Have To Be A Genius

You have to find your voice.

We’re always being told find your voice. When I was younger, I never really knew what this meant. I used to worry a lot about voice, wondering if I had my own. But now I realize that the only way to find your voice is to use it. It’s hardwired, built into you. Talk about the things you love. Your voice will follow.
Chapter 1. You Don’t Have To Be A Genius

It’s not about Perfection

Don’t worry about everything you post being perfect. Science fiction writer Theodore Sturgeon once said that 90 percent of everything is crap. The same is true of our own work. The trouble is, we don’t always know what’s good and what sucks. That’s why it’s important to get things in front of others and see how they react.
Chapter 3. Share something small every day

I don’t have much to say about this sentence.
It is just a reminder to me… to my “if it’s not perfect it’s not worth it” brain.

Find Inspiration

“Dumpster diving” is one of the jobs of the artist – finding the treasure in other people’s trash, sifting through the debris of our culture, paying attention to the stuff that everyone else is ignoring, and taking inspiration from the stuff that people have tossed aside for whatever reason.
Chapter 4. Open up your cabinet of curiosities

Reading other blogs and books is what I do.
Lots of what I write is inspired by them or things I tried and worked (or did not worked).
Sometimes I don’t remember where I read something, but when I do, it is important to credit the work of the others.
Austin reminds this to us…

Crediting work in our copy-&-paste age of reblogs and retweets can seem like a futile effort, but it’s worth it, and it’s the right thing to do.
Chapter 4. Open up your cabinet of curiosities

Tell a story

Most story structures can be traced back to myths and fairy tales. Emma Coats, a former storyboard artist at Pixar, outlined the basic structure of a fairy tale as a kind of Mad Lib that you can fill in with your own elements: “Once upon a time, therewas __________. Every day, __________. One day, __________. Because of that __________. Because of that __________. Until finally, __________.”
Pick your favorite story and try to fill in the blanks. It’s striking how often it works.
Chapter 5. Tell good stories

This is how I wrote Once upon a time… in Objectsland.

Teach something you learned

The minute you learn something, turn around and teach it to others. Share you reading list. Point to helpful reference materials. Create some tutorials and post them online. Use pictures, words, and video. Take people step-by-step through part of your process.
Chapter 6. Teach what you know

This sentence drove me to start writing about things I know about projects I worked on or about teams I worked with in the past years.
And again…

When you teach someone how to do your work, you are, in effect, generating more interest in your work. People feel closer to your work becaure you’re letting them in on what you know.
Chapter 6. Teach what you know

Learn, learn, learn…

You can’t be content with mastery; you have to push yourself to become a student again. “Anyone who isn’t embarassed of who they were last year probably isn’t learning enough” writes author Alain de Botton
Chapter 10. Stick around

Thanks Austin.

Few words on the 4th element of Simple Design

Suggestions to young men

Few days ago I made an interview.
The interviewer (Tommaso Torti) asked me if I have suggestions to give to young men starting a new career in software development.
Just as a recap, I mentioned:

find a company with high skilled software developers
changing job frequently: for example every 2 years
after few experiences, remain a little bit longer (5 years?) to find how good your design decisions have been in the long term
read classics: not only about software design… I mean also The Mythical Man-Month by Fred Brooks, Peopleware by Tom DeMarco, etc…

A missing point

But I forgot to mention one of the most important point.
In my opinion, to become a real expert in Software Development (not only OOP), you have to spend a lot of time on the 4th element of Simple Design: minimal methods, classes and modules (also known as “fewest elements”).

I know it sounds silly: “ehi man, I am already writing the minimal methods, classes and modules!”
Maybe! But, maybe not!
How do I know?
2 reasons:

I have seen code written by lots of people. Expert people. Very often, I could have written the same code with half of the objects/methods/modules maintaining (or even increasing) the readability of the entire code base
I found people able to write the same code I wrote, with a reduced number of objects/methods/etc…

So yes, it is a virtuous “mechanism” that once established creates an “obsessive” research on “how to write less, keeping high readability”.

What happens in reality is that, Object Oriented Programmers are focused mainly on SOLID principles, on the first 3 elements of Simple Design and don’t give any attention to reduce the things they write.
This is the reason I wanted to say few words on the 4th element.

A story

I have a story to share with you.
In my company, we had a coding exercise as an entry test for every applicant: Sales Taxes (you can find my solution at that link).
As an interviewer, I have seen lots of solutions and I can tell you that the majority of applicants created a solution with more than 30 objects. Some of them, reached more than 50 objects. I remember one guy proposing a solution with more than 80 objects.
Few people used 10 objects or less.
I haven’t seen all solutions, so I am talking just about what I have seen.

Another aspect: some developers wrote a solution with lots of objects that could adhere perfectly to SOLID principles and to the first 3 elements of Simple Design. Other developers wrote with fewer elements, but with procedural code.
I can tell you this: I accepted solutions wrote by the latter more often than by the former.
The reason is that, it is very difficult to train yourself on writing less. I think it is almost impossible to train on production software without a mentor helping you, unless you are naturally “obsessed” on this topic.

It is all about “simplicity”

There is another reason I think the 4th element is important.
If you are an object oriented programmer, you are naturally inclined to organize “things” (objects, methods, etc…).
But, as mentioned in The Laws of Simplicity by John Maeda, there are a lot of other ways to create simplicity and the first one is called “REDUCE”.

How to improve

Assuming that you want to train yourself anyway without a mentor, I can share some “exercises” you can do in your daily job or in some pet project you have:

try to start with just one module: you can add more modules later. If you really need them (and probably they will be created with a different idea behind them)
try not to duplicate your domain objects due to your adapters.
For example when you have a domain object and then you have another DTO for the REST adapter, one for the persistence, another one to call your supplier, etc…
If you really need this solution, try to avoid at least a hierarchy of mappers to create those objects from domain ones and vice versa: put factory methods in those objects instead
Anyway, did you try with just data mappers and Maps? Sometimes, the idea that you need another object lies only in your mind…
Did you try using reflection with some project convention?
try to count the objects (or methods) you are creating for a new feature.
Put a label near each one: NEEDED, MAYBE, USELESS
– USELESS: you should delete them immediately
– MAYBE: “maybe” you can do something to make them USELESS
– NEEDED: maybe you can think again… once more… are you sure? If you really think they are NEEDED, leave them alone
avoid “extract method” to have then just a private method containing one call to a collaborator. It does not increase readability at all! Change the name of your collaborator instead (or of the method name called)
pay attention to Parameter Objects. The idea that you need a Parameter Object when you have more than n parameters is the most stupid thing I have ever read (if you think this call discount(Product, Price, MarketStrategy, Report) is less readable than discount(DiscountRequest) you’ll be in trouble reading my blog). Besides, Parameter Objects often hide domain objects in the primitives used (I wrote a story about this: check Once upon a time… in Objectsland).

If you want to share another training exercise, please write a comment below.

I hope you’ll find interesting to spend some time on this aspect of software design.