This article is not only about technical writing. I would like to share my thought as a backend engineer, and the way to keep myself forward. I always believed in the idea that Creativity comes from Labours. Every time I work hard, I'm trying to solve any problems, ideas always come up like a tidal. And practice writing is a good way. I always believe that writing is good to make what you read become what you own. Writing code and writing articles are actually the same. Why not? My first programming teacher has told our class that just treat our computer as a baby, writing code is a process that you teaching the baby to do any work for you. So to make that code be understandable that the baby, you should deeply comprehend the ideas by yourself first. So if another engineer cannot understand what you are doing. That might be a serious problem. How can the baby know how to do things, if even a mature one cannot understand?
The gap between practice and theory
Everyone in this industry might have started from learning algorithms first. That’s a collection of perfect practices that have been passed on from generations. We learned them, captured the ideas behind those arts, and improved our ways of thinking. I have a love for those algorithms. But my previous efforts attending the professional coding competition at university have always been failed. I can’t solve the problems that raise inside the competition. But when I asked my friend who is great at the competition, to help me learn from those failures. They still can’t teach me about any of their skills. Is that some kind of mythology? Or the ways of his thinking can’t be adopted by me.
So far later, I asked my friends again. They now have a clearer thought about the industry, and I finally received my answers: At that time, they just practice and learn by heart. A person that always tries to understand solutions and reproduce the pattern that stimulates the real-life pattern will not be able to reproduce that because that is much from the mathematical space. There is some algorithms pattern that must be practice and learn by heart from time to time. And every time you encounter a problem, a sense that may tell you that problem is similar to a previous one if you practiced enough. Now, you just have to try to apply and may the problems been solved. Behind the scene, that build up a mathematical way of thinking inside his mind, like we have i and j is something that we have, and we program the computer to find a[i, j] from a lot of data with many abstractions. Attracted by that ideas, one day, I have left my job and try use one month to practice algorithms. And that really helps, after try memorizing and reproducing solutions, I have been able to produce solutions for a used-to-be-hard-to-me problem by myself.
The mathematical algorithm may help to solve a lot of hard problems. That builds up the small step of work but cannot be used to build up a full ecosystem. The real-world problems are not only about i and j, or we don’t have full the prerequisite come up at first. We are in the path of clearing that mist from time to time. No experiment environment anymore and everything else may become chaos soon. Not any single proven solution can be used to solve a problem from time to time anymore. As the prerequisite has been changed, the solution may be changed too. So real-life coding is actually an art of adapt changes.
What are a backend engineer's daily works?
So what are we backend engineers facing every day? Right now, I’m the person in charge of an internal supporting SAAS (software as a service) that allows the customer to connect with customer supports teams and get their supports as soon as possible. Not only the customer support teams but also we need to get closer to customers to collect more use cases as possible. We definitely do not have a clearer sight enough information from start point like competitive problems. Our real-world problems are hiding inside a large mist cloud and we reveal parts of it day by day. Working is to clearing the fogs between you and the end-user, between you and the solution, and between the problem and the solution.
Now that not only does the engineer need to do their best at work, but also they need to predict the future requirements, keeping the code and the architect clean. And now the work as a software architect should shine. Your experience turns into a prediction, that may be proven sooner or later. Experienced engineers know how to use their tools to create a product, but cover all the details of the product, and make them a masterpiece make you become a senior engineer.
Once I read a book about technical. The structure inside your code may soon reflect the organization’s ecosystem. Every problem you tried to solve is come from real life. And we developer should knows more about the industry we build products for, and transform the mathematical language to normal language, but always keep the accuracy and idempotent of our language. That the creation of ubiquitous language to solve the problem that from miscommunication of developers and different departments. And we engineering should learn to write a lot of things that can describe as exactly the work we are doing, and as easy to understand, so that we can share it to as many people as possible. The paperwork may become useful for us to communicate with many other departments and complete our jobs. The product proposal is needed to describe what your product is going on. The user story may describe what you needed for a feature to be fully completed and ready to deliver.
But besides that, in my observation, many engineers do hate the paperwork. Extra redundancy paperwork is added by boring managers just seem to slow down their job and make the job being more complicated than it seems to be. I also dislike the idea of a rigid process. So, that’s why I love to work in a startup environment rather than the enterprise one. That keeps me out of tons of processing bottlenecks. I understand that is good for an enterprise of that size. Despite it’s may slow down the working process, but it’s keeping the stability that is needed for the development.
Write for yourself
But keeping away from those ones, your technical writing is really useful in many ways. Your writing is a way to communicate with your colleague. You can share your ideas, and explain them to more people, and receive more viewpoints from them, and continuously improve your idea. And it is a way to communicate with yourself too. You can write about learned knowledge or an idea, or introduce a masterpiece that you have crafted recently. Everything may work and create well paintings that build up your colorful mind.
I always come up with many ideas as I coding, and I definitely love to write them down. First, it’s taking me to a brighter sight of these solutions. As the idea is written down in detail, we should have a clearer look at how to do it. Some people I have talked to only have the solution in their thought. They are gonna do nothing but to be a dreamer, and in most cases, I don’t see anything become true. Second, to be able to write a technical solution down, and cover all details, also means that you have a skill, that in our phrase, we usually called that eye-debugging. That may make a junior become a more experienced one. Because doing that means you have a deep understanding of the coding technique and are able to craft a lot of fancy things from scratch.
Third, using those details, you can compare all the solutions with each other. With all the details covered and numbered over the paper, we can all share the same thought. In abstraction, with some points over a space, you can imagine a lot of shapes that may be formed from them. But having more details like some lines and points, and we all share the engineering sense, the more coverage rate may we achieve.
Finally, without caring about your college, it’s also useful to make that practice yourself, because this is like self rubber duck debugging, were you trying to explain your things to a rubber duck. That’s may form a conversation, a communication bridge between you and your engineering self. From what you wrote down, you make a bridge between thought, that is how your versioned your ideas, and practice that improves your mindset a lot. Critical thinking writing is to write fact only, it’s a way to do more critical with myself at that time
