Come on kids, tidy up your room! Pick up those Lego pieces.

Whenever I tell this to my kids and come back 5 minutes later, I go crazy because the floor is still covered by socks, pencils and basically any other toy which is not a Lego.

What did I say? Tidy up your room! Why didn´t you pick up all that mess?!?

I guess right now you imagine the answer, even though you don´t have kids:

You didn't say that! You told us to just pick up the Legos!

As a father, tech lead, and developer I am always surprised and upset when after "giving an instruction" the outcome is not what I expected.
I immediately start to wonder where I failed in my communication. Most of the time it is indeed because of that.

Like with a program it could be a matter of syntax or a misunderstanding about the API, with people it could be that the message was not clear ( too specific or too generic), the context was not properly defined, the language/ vocabulary not shared, and so on.

But this is true up to a certain point.
Exactly because I am not talking to a robot, which might take what I say literally, I expect other people to understand the context and do whatever is possible to make sense out of it.

True, I gave an instruction that was too broad and generic "Tidy up", and another one that was too specific: "Pick up the Lego pieces!". My fault. But among two misleading instructions, they decided to follow the one that required less effort on their side. Those lazy cheeky brats!

Last week, in my train of thought, chain of googling and compulsive clicking on every link I see, while writing about Good Quality Code I ended up on this post of Coding Horror where he says:

I have a hard time criticizing the few developers who care enough to gold-plate their code in the first place.

and links another very interesting post that explains further the difference between two kinds of people: Big heads & Little heads (taken from an Israeli Army example from this guy).

I ended up reading about the Work-To-Rule and Italian Strike, when you basically slow down productivity, by well, simply following strictly, literally every possible rule your organization has.

All this made me think about the difference among developers and why some of them are - even without huge differences in their skill set - below average and some of them could be described as 10X developers.

I already talk about what in my opinion makes a 10x developer. But I think this also makes the distinction between PinHeads and 10Devs much clearer.

On one end you have someone whose goal is solving a problem. When they have a task or goal, and run into an obstacle, they proactively try to find solutions, they overcome the obstacle often with creativity by going around or right through it, or reframing the context, the original problem. (Way too many times I saw problems simply disappear or become easier or quicker to solve because the root cause (or the solution that was chosen to fix it) was suddenly another one.) Check the Rule of 5 Whys

On the other end, you have someone who stops at the first excuse. As soon as they find a justifiable reason to stop looking for a solution, they consider their job done:

• First try, the bug is not reproducible: Ticket closed. Eventually, QA will open a new one, and some other dev will be assigned to it.

• UI crashes because the backend sends wrong data? Ticked closed and a new one for backend is opened. It does not matter if maybe is our UI that sends invalid data, that causes the backend to return an error. If that is the case, the backend developer will open a new ticket asking frontend to send valid data, and hopefully, that ticket will be assigned to another developer.

• The bug can be fixed with a quick workaround? Let´s commit that tiny change, without asking yourself if that could have a bigger impact on other parts of the application, or further down the line, in the backend or in the future. If it will, another bug will be reported. And not necessarily the correlation with this change immediately found.

• The Task description is generic or implementation details misleading. Send back the ticket and wait for the product owner to start other long sessions of meetings and discussions about requirements instead of contacting the stakeholder/reporter with a quick slack message.

You might find this behavior lazy, unprofessional, and plain stupid, but unfortunately, there is a lot of people ( not just developers) that work and live with this attitude, which is not necessarily malicious.
Since this is the reality, being smart, broad-minded, creative, proactive, being able (having the courage and humility) to ask questions ( or ask for help) when in doubt or when stuck, can really make the difference in your career.

As I said many times, there is no magic in those mythical creatures called 10X developers, most of the times are simply quite skilled developers who take initiative and do what is desired, not what is requested ( plus a good dose of soft skills to handle it)

Disclaimer: I am not, in any way saying that some colleagues - or my kids ;-) - are stupid! Just pointing out the difference of attitude I saw among developers, over many years, in many different companies. And teaching this right attitude is one of my main goals as a father, and tech lead.