A passion for programming. Chapter 20. Telepath

About transfer

This is the translation of Chapter 20 of The Passionate Programmer: Creating a Remarkable Career in Software Development . Its author, Chad Fowler, is a talented Ruby developer, a renowned speaker at conferences dedicated to Ruby and IT in general. Former saxophonist, and now - CTO 6Wunderkinder.

Crowdsourcing translation of the book is conducted on github , join.

Chapter 20. Telepath

I worked with a guy named Rao. Rao hails from the southern state of India, Andhra Pradesh, but he lived in the US and worked with us. Rao could write any code, whatever you asked him. If you needed low-level system programming - this is to him, if high-level application, he could do almost anything.

However, what made Rao truly amazing was that he did it before you asked for it. He had this supernatural ability to predict what you were going to ask him to do, even before you thought about it. It was akin to magic. I think I even accused him once of cheating, but there was no possibility of cheating. I would say: “Rao, I was thinking about changing the way the controller was encapsulated in our application framework [1]. If we change it a bit, then it will be possible to use it not only for web applications. What do you think?". “I did it last week,” he would say, “This is in the version control system. Look. ”With Rao, it was always like this. So often that the only way to make it all a coincidence, as if Rao did everything that could be imagined with each piece of code that our team worked on.
')
At that time I was in charge of the application architecture team [2]. Among other things, we developed and accompanied frameworks for use in company applications. My colleagues spent a lot of time discussing how we want to see software development to improve the company. We also discussed the role of key infrastructure components in these improvements.

That's where Rao's tricks turned out to be useful. He did not speak much during these conversations, but he did not disconnect from them. He listened carefully. And, revealing the secret that no magician does, he later told me that he did only what I already said that I wanted to do it. I just talked about it so subtly that even I could not imagine what I said. We could wait until the coffee was brewed, and I could tell how great it would be if our code had additional flexibility. If I talked about this often enough or pronounced quite convincingly, even if I didn’t include it in my to-do list, Rao could fill in the breaks in “real work,” looking for the possibility of introducing one of these things. If it was easy (and cheap) he could do it in a hurry and check.

Foresight relates not only to your managers, but also to customers. If they give you the right hints, you can add the functionality that they were about to ask you for, or they could if they thought it was possible. If you always do what the customers ask for, then they are just satisfied. However, if you are doing more than they ask for, or have already done something in advance, you will hit them - this is if your telepathy ability is correct.

This mind-reading trick is not entirely safe. It's like a tightrope that you avoid walking without a safety net. The main risks (with expected mitigation) are as follows:

• you spend company funds doing work that no one asked you about. What if you are wrong? Start small. Make only assumptions about filling pauses in your current job, so the impact of changes is minimal. If you want, do it in your free time.
• every time you add code to the system, there is a very big chance that the code will become less flexible for changes. Avoid assumptions if this can lead to a decrease or limit on what the system can perform [3]. When the impact of change is large enough, business decisions are needed. And in this case, only developers rarely influence the decision.
• You can change the functionality of the system, as requested by your customers, so that the solution will suddenly become less useful or desirable for the customer. Beware of guessing, especially when it comes to user interfaces.

Managing people and projects is hard work. People who can move the project in the right direction, without a pointer, are highly valued by their often overworked managers and customers. Thoughtful thinking, if done correctly, makes people rely on you - a great recipe for career development. This skill is worth learning and development.

Act!

1. Karl Brophey, an early reviewer of this book, suggests that for your next project or system you are developing, make notes about what you are thinking of what managers or customers want to ask. Be creative. Try to look at the system from their point of view. After compiling a list of not-so-obvious functions, think about how to most effectively implement each.
2. When you hit the project or the task of improving the system, follow the progress. How many of your guesses really asked to develop? When your functions were implemented, did you have the opportunity to use these ideas to brainstorm? [4]

---

[1] I would say, "Rao, I've been thinking about changing the controller on our application framework."
[2] At the time, I was leading my product application architecture team.
[3]
[4] What were your guessed features?

---

What is the best way to translate the word feature?

And did anyone meet such rao?