iTranslated by AI
I Fully Understood How Systems Engineers Work
About This Article
This article is a written version of the presentation I gave at "Engineers' 'I Completely Understand' Talk #64" held by the "Easy Easy" community.
Recording of "Engineers' 'I Completely Understand' Talk #64"
Presentation Slides
Also, due to the concept of the event "Engineers' 'I Completely Understand' Talk," which is to loosely present things that people "somewhat understood," there may be content that is not strictly accurate.
While I have taken sufficient care regarding the content, please keep this in mind while reading.
Introduction
I'm Sawanomura.
I usually work as a frontend engineer(?) at a startup company in Tokyo that deals in the secondary brand market.
(I also handle backend tasks, SEO, customer support, design, and video editing...)
In this article, I would like to talk about the way of working as an engineer that I have felt after working for one year as a new graduate.
This is intended as advice for those who don't yet understand how to work as an engineer, such as first-year graduates, on "what kind of mindset might make work easier to approach."
I feel that by putting these things into practice myself, I have been able to approach my work more comfortably than before.
While there may still be some rough edges, I hope this serves as a reference for your future work.
First, Grasp the Big Picture
I believe the most important thing for finishing a task is to grasp the big picture.
This is because if you don't grasp the big picture, your speed of understanding will slow down.
If you try to understand the details after grasping the whole, you will understand what is happening more easily because you know the general flow of the matter.
Conversely, if you try to understand from the details, you cannot grasp what is being done until you have understood the majority of it.
For example, when trying to read code for the first time, if you grasp that "this file does this kind of thing" before looking at the details, you can read while making predictions like, "this process is probably used here."
This speeds up your understanding of the whole.
On the other hand, if you read starting from the details, you begin with a state of "not knowing what it's doing" for code you've never seen before.
You only understand "maybe this file is doing this?" after grasping the majority of the code.
In some cases, you might even end up having to read it all over again from the beginning.
Similarly, the same can be said when modifying an internal company app.
When a request comes from the front lines saying "we want this part modified," if you don't understand the overall business workflow, you won't know where to make changes without interfering with other parts.
In the company where I currently work, documentation doesn't exist for most repositories, so I always start by creating documentation whenever I modify code.
However, I don't create everything by hand myself; I have VSCode's Copilot generate the documentation and read that before making modifications.
Example of creating documentation
Ideally, I'd like the person who wrote the code to create the documentation, but since it's a startup, "releasing for now" is the default.
(Understanding the code is a struggle every time...)
As you can see, grasping the big picture is more important than anything else.
How quickly a job can be finished depends on the preparation done before even tackling the main subject.
Utilize the Expertise of Knowledgeable People
To generate value or grow, make a point of actively checking not only your own interests but also information shared by your seniors. This is because people more senior than you generally have more knowledge and experience, providing you with perspectives and insights you might lack.
High-density advice distilled from years of experience is meaningful beyond measure. Seniors working beside you likely have a deeper understanding of the company's culture and history. By adding your own acquired knowledge and experience to that, it becomes possible to create new value.
This doesn't have to be restricted to people within your company. Looking at the broader "engineer" category, there are many individuals sharing beneficial information. By following such people on X (Twitter), note, or YouTube, or by attending engineering study sessions and hearing them speak, you can gain a wealth of knowledge and experience.
A trait of those who succeed in their work is "asking questions about everything and making it their own." In the engineering world, there's a tradition of "Googling it before asking," which can make it hard to ask even small questions. This is where following the information shared by influential figures comes in handy to make it your own asset.
For example, I'm a member of Mr. Hoshikage's membership on note. His "Hoshikage News Memo," which is updated almost daily, is personally extremely useful. It allows me to catch up on IT information I didn't know quickly and easily, even when I'm short on time. It also provides a glimpse into what someone who has served as a CTO keeps in mind during their daily work, which is very helpful.
Here are some people I follow or reference who I particularly recommend:
In this way, try to absorb insights from those with expertise, not just from things you are already interested in. Instead of looking down on them for being "high-level," you will ultimately benefit more by doing even one thing that contributes to your growth.
Broaden Your Horizons in External Communities
To gain new perspectives, get to know engineers outside your company, not just those within. If you only belong to the same community, your thinking can become rigid.
By participating in study sessions and networking events, you can gain knowledge from angles different from your own company. It's a great opportunity to learn things useful for both daily work and private life. I use connpass, a study session platform for engineers.
In my case, I also participate in these sessions to make acquaintances. When working as an engineer, there are many times when I stay at home all day on holidays just to study, so it's hard to make friends (at least in my case...).
I've recently started attending study sessions and meetups more frequently, and I often find myself thinking, "I had no idea this service existed" or "I should try this next time." For example, what prompted me to start posting articles on Zenn was the first Zenncafe. Being able to speak directly with famous contributors who regularly post on Zenn gave me the motivation that I couldn't just stay without writing any articles.
Also, don't just be passive; take the initiative. For example, go talk to people yourself or study beforehand so you can keep up with the content of the session. Don't just sit there doing nothing at networking events; go and say, "Would you like to chat?" (I'm saying this very much to myself as well...). It's a waste to have the opportunity to interact with people from various backgrounds and not go talk to anyone.
For example, if it's a React meetup, make at least one app beforehand. It can serve as a conversation starter when interacting with other participants, and without some knowledge, you won't be able to follow the conversation at all. This is another way to avoid being passive.
Participating in various study sessions and meetups in this way will surely change your actions and mindset. Absorb the insights that only those individuals can offer, grow, and gain a multifaceted perspective.
For Beginners, Output is the Key to Growth
To internalize what you have learned, actively output your findings.
This is because you only realize whether you truly understand something or not after you try to output it.
If you try to output while not fully understanding, you will inevitably get stuck at the points you don't understand.
For example, if you leave things vague while writing code, you'll likely think, "I want to write this logic, but how do I do it again?"
Similarly, when writing an article, you'll think, "This explanation is weak and I want to fix it, but how should I write it?"
In this way, what you don't understand becomes clear.
By re-studying and reinforcing those weak points, you gradually deepen your understanding.
Regarding methods of outputting, such as writing and running code, I recommend writing articles in particular.
Because you verbalize your actual experiences to write an article, the content sticks in your head more easily. (I feel it's similar to the "Teddy Bear" effect/rubber duck debugging.)
For instance, I wrote two articles as part of my studies for the Fundamental Information Technology Engineer Examination.
I wrote these entirely to organize my own knowledge and didn't really expect anyone to read them.
However, no "Masakari" [1] came my way, and by organizing the ambiguous parts, I was able to solidify my knowledge.
I think beginners with limited engineering knowledge are overly cautious of "Masakari."
When I was about to write my first article, I was also very wary of whether a "Masakari" would come flying at me.
In the end, as I mentioned before, no "Masakari" came at all.
Instead of not writing because you think "someone might criticize me," putting it out there for now is more beneficial for you.
There are other benefits to outputting while you are a beginner.
By outputting what you were thinking at that time, you leave a record of "what was happening then" that you can look back on later.
As mentioned in the book "Concrete and Abstract," "those who can see the abstract side (above) can see the concrete side (below), but those who can only see the concrete side (below) cannot see the abstract side (above)."
This means that "even if a person at a higher level acts at that level, a person at a lower level cannot understand it."
For example, when I learned about object-oriented programming at university, I didn't understand it at all even when it was explained as "an object-oriented class is like a taiyaki mold." Because the explanations were abstract, involving things like "taiyaki" or "blueprints," there weren't many concrete examples of where it would actually be effective. However, if you keep records and feelings from when you were a beginner, it becomes easier to understand the beginner's perspective. Once you understand that perspective, it becomes easier to think about what points to reinforce and how to explain them based on your subsequent experience.
In this way, by outputting, you can clarify what you are "lacking" and improve both your current and future self.
Tell yourself "this is for my own growth" and output actively without fearing the "Masakari."
Finally
I have talked about the way of working as an engineer based on my empirical rules from working for one year as a new graduate.
- First, grasping the big picture improves work efficiency.
- The insights of knowledgeable people lead to your own growth.
- Gain new perspectives by participating in external communities.
- Solidify your knowledge by outputting because you are a beginner.
I believe that just putting these four things into practice will make your experience working as an engineer much better.
If you ever feel that your work as an engineer isn't going well, I hope you find these methods helpful.
-
"Masakari" (Battle-axe): A term used in the Japanese tech community for aggressive technical corrections or criticism. ↩︎
Discussion
LT登壇＆ご紹介ありがとうございます！
具体と抽象の話はとても大事なことですね〜😌
こちらこそありがとうございました！
具体と抽象って意外と仕事で重要なんだなって思いました