Practical thinking

I was first paid for some webdev related work in 2006. Since then, I’ve seen a lot of projects, played my role in several development teams, and worked closely with a few brilliant software engineers. Looking back and reflecting now, I think I have always been a mediocre developer, intuitively picking random opportunities and handling them well enough. In attempts to learn from better developers I was watching them and trying to copy their behaviour. I noticed a few things that they all do regardless of their specific role, seniority or tech stack. One of them is what I call practical thinking.

As you grow in your career, you’ll experience a lot of teachable moments, a lot of lessons in how things should or should not be. These can be “best practices,” or scars caused by mistakes. This unconscious buildup can cloud our thinking and reduce our creativity. When we close our minds and stop learning, we start to lose the most valuable skill for maintaining and growing a successful technical career. Technology is always changing around us, so we must continually experience that change.

Fournier, Camille. The Manager’s Path.

When I grew up, I suddenly realised that adults don’t think enough. Many of us are prisoners of our habits and habits of our relatives. We tend to overvalue our life experience and social status. We tend to avoid or replace thinking work with copy & paste from previous experience. It becomes more and more attractive as you become older. Don’t get hooked: stay curious and thoughtful.

The problem with applying this piece of advice in practice is that a developer can’t just sit down and think while their time tracker is running. First of all, it is not always encouraged by employers who imagine developers writing code 40hr/week. Secondly, it’s hard to switch our brain in thinking mode when we need a brilliant idea for your current task. Finally, popular web developer courses and learning materials often skip this bit and offer tools-focused rather than thinking-focused exercises.

What I noticed in behaviours of great developers is that they find a moment to think outside the box and apply results of their thought process to reality. This is what I call practical thinking.

Because of the habit of practical thinking, they generate more ideas, and observe promising ideas deeper. They ask more questions, and get more insights. They notice potential issues before they became a catastrophe. They see opportunities for themselves and potential in talented team mates.

Sounds great, and works great too, after some practice.

🤬 Start from pain points

When I face an uncomfortably annoying problem, I try to think about it from different angles and write down my thoughts. It doesn’t solve the problem magically, but it helps me understand different aspects of it much better. It’s easier to start building a habit of practical thinking from very uncomfortable problems because they are already scratching you on the background of your mind. You will want to resolve them.

🎨 Visualise your thinking process

Bullet list, mind map, whiteboard, colored pencils - find visualisation technique that works for you best. Human built-in RAM is very small for manipulating large controversial data sets. So use swap!

🤖 Automate

When you work on a boring task, think how it could be automated. In a worst-case scenario you’ll figure out that the task is actually hard to automate, but at least it will become less boring.

📆 Actively participate

When you are sitting on a meeting without being actively involved, ask yourself why. Did you come prepared for this meeting? Are other attendees feeling the same? How it could be improved? I know some teams dropped daily stand-ups because all attendees agreed on another way to share their status.

🎓 Share your knowledge and learn from others

When you are not satisfied by your team mate’s work, check if you can help them to improve. Is there hidden knowledge about the project that you can share? Are you open to alternative solutions that your peer proposes? Was a bug introduced because of code obscurity? How to improve it so that other developers will not repeat that mistake?

I listed just a few examples. You will find yours and develop your own style of practical thinking. Good luck with it!

Be prepared that your boss may not like that you think too much about something that is outside of your current tasks list. It’s senior leadership problem to re-focus employees on a company mission and give them just enough autonomy and responsibility, and this problem is not simple. Help your boss find the right problem for you to solve if you picked not the best one.

One final note. The more thinking you do as part of your job, the less chance you have of being replaced by robots.