Personal blog

Category: Soft skills (Page 1 of 2)

Don’t automate everything. Go Elon instead.

If you “automate everything” you end up with cargo-cult of your process.

What you should do instead is employing Elon’s 5 steps protocol (“the Algorithm”) that consists of in order:

  1. Question (requirements)
  2. Delete
  3. Simplify / Optimize
  4. Accelerate (cycle time) 
  5. Automate

Always. In. That. Order.

If you automate something that meets unnecessary requirements – you’re doing it wrong.

If you automate something that shouldn’t even exist – you’re doing it wrong.

If you automate something before you try and simplify it real hard – you’re doing it wrong.

If you automate something prior to accelerating it’s cycle time – you’re doing it wrong.

Every such automation helps cultivate current pathology.

Possibly the most common error of a smart engineer is to optimise a thing that should not exist,


What a waste it is to automate “everything”!

Automate aggressively but first own the progress and make sure you automate the right thing.

Making sense is overrated

Test first? How do I test something that is not yet written? And before all, why? It makes no sense.

Try it a few times and you’ll see how powerful it is!

Open–closed principle? The more I close my code to modification, the more closed it gets for extention. You can’t have both. It makes no sense.

Only until you realize that it’s actually possible – with interfaces or other dependency inversion techniques.

The best code comment is the one that never existed? Comments are the only thing that allows me to navigate my messy code. You want me to stop writing them? It makes no sense.

Yes, stop writing comments and delete all of them. But only after you clean up the code to the extent that comments are not needed. There are ways to do it.

Continue reading

Consistency in Programming – 10 Symptoms [CliftonStrengths #5]

There it is. 5th and the last theme. “Crave for clear rules”, as the official description says.

What kind of rules could it be that I crave? What challenges can the rules bring?

Consistency as a programmer – 10 symptoms

1. Process is good

Processes have negative connotations. They are on the right side of the agile manifesto. And I claim myself agile. How come?

To me, a process doesn’t have to mean a big and slow corporate machine. Process is a visible extract of how we do things in our team. Visible! That’s the missing part of almost every “process” I ever saw.

Process is a communication tool.

Processes can and should be automated. But first, they need to be visible.

And yes, individuals and interactions can trump processes. These situations should lead to improving the process. Not to anarchy!

2. Communication rules

Continue reading

Ideation in Programming – 10 Symptoms [CliftonStrengths #4]

My favorite talent, if I may choose one!

Ideation as a programmer – 10 symptoms

1 . No monopoly on solutions

When picturing your code in terms of product and user stories, it doesn’t really matter how you solve people’s problems.

Too often programmers are married to the idea that all they do is code. We can solve problems otherwise!

Most of the time it ends up being code, but even then there are many, many possible solutions.

2. Idea review

Continue reading

Developer in Programming – 10 Symptoms [CliftonStrengths #3]

Out of my 5 CliftonStrengths talents, it’s time for the third one – Developer.

Cool name for a programmer, isn’t it?

Developer as a programmer – 10 symptoms

1. Awareness

I know of the Curse of knowledge.

I know people learn differently. YouTube videos, documentation, books, courses, learning by doing… All of that can be a legit source to learn from. Depends on who is a student.

That said, I have a very strong candidate for the best way of learning & teaching programming. Which is…

Continue reading

Individualization in Programming – 10 Symptoms [CliftonStrengths #2]

In the previous post, I showed the Responsibility talent in examples. Now it’s time for my second top talent – Individualization.

Individualization as a programmer – 10 symptoms

1. Start with “why”

Before going into “what should we do”, you need to answer “what’s the goal”?

The problem and common misunderstanding are simple. Different people have different goals. I find it hard to start suggesting solutions before I know your pain.

2. Understanding business

Continue reading

Responsibility in Programming – 10 Symptoms [CliftonStrengths #1]

CliftonStrengths is a 177-question assessment, resulting in 5 out of 34 themes (talents) that best describe your personality. It got popular because often the descriptions of the theme and the advice they give you after the assessment are extremely accurate and helpful.

Here are my top 5 CliftonStrengths themes.

  1. Responsibility – this post
  2. Individualizationread more
  3. Developerread more
  4. Ideationread more
  5. Consistencyread more
Continue reading

Communication benchmark – number of questions

If you want to be a good communicator, you should practice communication. This requires feedback and questions from your recipients make great feedback. You don’t have to ask anybody for anything extra – questions happen anyway.

You write something -> by the hardness of communication, you aren’t sure if it’s clear or not -> somebody is indeed unclear on something -> they ask for clarification -> you answer, then you improve for future

How to use questions as feedback?

Continue reading

Send that link

In writing, whenever you’re referring to something that has URL, send that link.

Whenever you’re discussing Jira task, send that link.

Whenever mentioning a document, send that link.

Whenever referring to particular Slack discussion, send that link.

This will allow other people to immediately jump into details (if they need so). That in turn will reduce communication noise (typically in the form of annoying ping-pong messages).

If you think that the link won’t be helpful, because they know what you’re referring to – think twice. You’re in the loop, they might not. Also, it’s not a bad idea to lower your expectations, when communicating in IT. Have you ever been surprised by the fact that something obvious for you turned out to be not obvious at all for others?

If you think that they can check the details on their own if they want – think twice. Unless you’re pair-programming, they are working on something else. Their own tasks, tickets, context. They might need to find Jira it their bookmarks, search for the ticket name, make sure it’s yours – each operation taking 10 sec or so. If they are unlucky, this might be not the end – they might need more accesses, or more details.

You, on the other hand, have this thing in your browser. For you it’s cmd+l, cmd+c, cmd+v. For them it might be minutes turning into “ah fuck it, I don’t need to answer you now”.

If you think it will add to “spamming” in messages – think twice. This should not be the concern here. If you can save someone else’s minutes of their work, it means that the link was useful. It’s not spam at all, if somebody needs it. There might be a deeper problem with not distinguishing useful messages from real spam, but it’s another story. The bottom line is that link is never spam, when it supports foregoing discussion.

If the link turns out to not be useful – fine. I will argue that, in total, the habit of sending links will save much time, even if only a tenth of them are useful. The cost is too low and the potential benefits are too high.

« Older posts

© 2024 Bartosz Krajka

Theme by Anders NorenUp ↑