Engineer’s Spirit #31~#40
Introduction
If you are interested in the experiences of Bill Gates, Thomas Edison, or Soichiro Honda as an engineer, you can easily find the information by searching the web. However, there must be many other engineers in the world who have made endless efforts in addition to such well-known engineers. And each of them must have a unique and precious experience.
If you wanted to know more about the experiences of these engineers, how would you go about finding out about them? When I thought about the answer to this question, I could not find an easy way to get that information.
Imagine this.
If you are a newcomer to the world of engineering, don’t you think that if you can hear in advance about the most successful and most unsuccessful experiences of engineers who have had a variety of careers, you will be able to make great use of them in your own career?
If you are a young engineer in the middle of your growth, don’t you want to learn from your predecessors to further improve your skills and accelerate your work in the future?
If you are a veteran engineer, wouldn’t you like to take some time to compare your past experiences and appreciate your own efforts and those of other engineers, even if only indirectly?
I had a strong desire to learn about the most successful and most unsuccessful experiences of “unknown” engineers who were not readily available in the search results.
In this book, we have interviewed engineers (with their permission) about their successes and failures in all kinds of technical fields, from newcomers to veterans, to create a collection of useful information that we can share with you.
In addition to paying the engineers for their experiences and efforts, we also interviewed them with our own money, and ordered the work of a designer to ensure that we do not treat their soulful experiences carelessly. In order to pay respect to the engineers as well as to avoid treating the soulful experience carelessly, we ordered a designer to help us with the binding and design.
I hope this will be of some help to you in your career.
October 01, 2021
KASATA
Engineer’s Spirit #1~#10
Engineer’s Spirit#11~#20
Engineer’s Spirit #21~#30
Engineer’s Spirit #31~#40
Engineer’s Spirit #41~#53
#Experience Report 31
Male, Company employee, Manufacturing, Engineering, Electrical, 15 years
Q1. What type of work do you do?
We provide services ranging from new development to maintenance and operation of production facilities for automobile parts manufacturing plants. In addition, we maintain and manage the air conditioning, water supply and drainage systems in the plant. With the cooperation of our partner companies, we are working to ensure stable production at the plant.
Recently, I have been participating in the maintenance of windows servers and the management of network infrastructure, which has taken me away from the shop floor. Even so, I believe that the workplace is the starting point of the manufacturing industry, so I try to visit the workplace as much as possible, talk with the young guys and girls, and work on the entire factory to ensure a safe and secure workplace where everyone can work comfortably.
Especially recently, I have been trying to motivate new employees to work with the same spirit.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
Failed BusinessIn developing an articulated robot, I neglected the mechanical elements. I threw away the mechanical design work to our partner company, and immersed myself in the development of electrical circuits and control programs. Thinking about accurate and high-speed motion. From the power supply to the axis output of the servomotor, I used my nerves more than ever before and worked steadily on the production. The finished equipment was ready for evaluation as planned, but it turned out that it did not have the accuracy we were aiming for. This was not apparent during the test operation, but became apparent as we went through the test items. The real cause was that the accumulation of tolerances of the component parts became the worst condition when a specific posture was taken, but without looking at the mechanical drawing, the reducer was replaced with a more accurate one, which resulted in higher costs.
The true cause of the problem was discovered when we had a meeting with the partner company’s machine supervisor to find a cost reduction plan and discussed relaxing the tolerances in order to lower the unit price of purchased processed parts. At the timing of the meeting with the partner company, we did not correctly communicate the mechanical specifications we wanted in numerical values. In the background, we were too proud to think that control was an important factor in the characteristics of the equipment. Fortunately, thanks to the advice of an experienced mechanic, we were able to achieve the initial cost estimate before mass production.
Because of this experience, we now consult with our mechanical engineer first when we have a new project, and then ask our partner companies for help after we have properly communicated our objectives and necessary requirements.
Q3. What is the one thing you are really glad you did?
This is a good thing I did when I was a rookie, practicing servo motor control using PLC pulse train control (using an industrial controller and servo motors (special motors with excellent response) to move objects to precise positions). At that time, there was no positioning control using servo motors or stepping motors, and the mainstream was control using electric cylinders (I use this term to avoid specific product names).
We had no objection to the use of electric cylinders because most of our current projects meet the requirements with them and the cost is reasonably low. In the first place, we can’t do anything difficult. . .
One day, I was ordered by my manager to dispose of the old servo motors. I knew the name of it, but I had never used it before, so I told my manager that I wanted to try it out and he agreed. After that, I started struggling with the manual in my hand (this kind of manual is difficult to understand, so I struggled a lot). After about half a month, I was able to do what I wanted, so I disposed of it as planned.
About four years later, we had a problem. The new project had a complicated mechanism that could not be arranged with an electric cylinder, so we were forced to use a servo motor. Even the veterans were reluctant, but I can do it! I can do it! I can do it!” I asked my superiors directly and was given the responsibility. After that, I finished my work. I was able to finish my work and establish my position in the workplace.
If I hadn’t tried then, I wouldn’t be here now, and the warmth of my superiors at the time was an important factor, of course, but it was a good experience.
#Experience Report 32
Male, company employee, system-related programmer, 7 years
Q1. What type of work do you do?
Please tell us briefly about your business. I was in charge of the production system of “production instructions”, which are the production instructions in the production process. At that time, I was in charge of the production system for “production instructions”, which are the production instructions in the production process. I was in charge of the production system for the “production instructions,” which are the production instructions for the production process. The orders were received from sales offices all over the country and were identified by order codes, such as “type of shutter, length, height, color, electric or manual,” etc. The instructions were then calculated backward from the delivery date and sent to the site. The program is created on an off-line computer using a programming language such as COBOL. The part related to the creation of these programs was singled out. In addition to off-line computers, we have also set up a cost accounting system using Visual Basic for financial and accounting cost accounting on PCs.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
The biggest mistake I made was that I only worked as a programmer. In today’s world, I think the biggest failure is that I did not get a job that allows me to see the entire system, such as infrastructure and system construction. There are a lot of programmers out there. In that sense, they are inadequate as engineers who will build the information society of the future. As a result, it is impossible to make a living (or work) as a programmer alone in the future. In my case, I changed my job to a clerical position at a so-called manufacturing company, not purely as a programmer, but also because I could use a PC for information work. I learned various things so that I could be active in white-collar positions such as general affairs, human resources, and accounting at a manufacturing company. I think that being a programmer was just a fad. It was a mistake to fall in love with it. No matter how I look at it, it is not ideal to spend the rest of my life typing away at a screen as a “programmer” until I retire. I think this job change was a good turning point for me. I am now able to take advantage of my past experience in information processing and carry on my work as an office worker.
Q3. What is the one thing you are really glad you did?
I am glad that I had at least a basic understanding of information operations in my job as a programmer. I am glad that I was able to learn at least the basics of information operation as a programmer. Today, there are engineers who can see the entire system, such as infrastructure and system construction, but even if you don’t go that far, you can still “keep up with the conversation” to some extent. Although the skills of programmers alone are not at the same level as those of modern engineers, it is possible to work in sync with them. In that sense, I think that having lived as a programmer in the information society has helped me in some small way. I have learned that the most important thing to live (and work) in the future is not to say “that’s all I can do”. In my case, I was able to change jobs at a good turning point. I would like to continue working on various things so that I can be active in white-collar jobs such as general affairs, human resources, and accounting by using my PC for information work. As the times change, the content of work changes. In this sense, monochromatic work is not good, and we need to be diverse. In this sense, it is necessary to challenge various things and expand the range of work you can do.
#Experience Report 33
Male, Company employee, Application development engineer (mainly back-end and server-side), 15 years
Q1. What type of work do you do?
I have had many opportunities to work with major companies in the past, so I often use my experience to participate in projects as an SES (System Engineering Service) for major companies. Until the other day, I was working on the development of a mobile system for a railroad company related to reservations. Since that project was about to be released, I stepped down from my position and am now participating as a member of a national project, although I cannot disclose the project name. My job is to develop both applications that run on Windows devices and web services that communicate with them. Since I am working as a full stack engineer, I am required to have a wide range of knowledge such as DB knowledge, file system knowledge, and infrastructure knowledge in addition to development knowledge.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
Production data loss (loss of data that is actually running as a service) is the biggest failure I have ever experienced. I was not directly involved in the development of the service, so I was not held responsible for it, but it was developed by my team, and it became a big problem because of the loss of insurance-related customer information data. The problem did not stop at the field level, but escalated to the board level because it was not just a few pieces of customer information that disappeared, but a file containing a list of customer data in the cloud. The cause of the problem was a glitch, but it was completely overlooked because the program that the glitch went through behaved completely differently from the test.
Since then, we have been testing the file transfer programs to make sure that the system as a whole is safe in the event that an error occurs in all the programs. Even if a backup disappears, another backup generation is managed. In addition, there are some sites where people get used to the release process and don’t read the procedure manual or give cues, but in my case, mistakes are more likely to happen when you get used to it, so I go back to the beginning and read the procedure manual every time. So I go back to the beginning and read the procedures over and over again. Even if what is written in the procedures is exactly the same, I always check to see if there are any flaws in the procedures.
Q3. What is the one thing you are really glad you did?
One good thing about being an engineer is that I try to praise the members of the team instead of blaming them when a defect occurs during the test. I myself grew up in a black company where I was abused, and now I have changed jobs. At that time, if I produced a bug in a test, I was called “poor quality” or “bug maker”. This would lower my motivation and I would try to fix the problem secretly to cover it up before it was discovered. Since it was only a few minutes of work, there was no way to know the extent of the impact, and it became a negative spiral that created more defects.
That’s why I will never let this happen to me. In the first place, I believe that testing is not to “confirm that things work properly” but to “make sure that bugs are found”, so I make sure that the members can comfortably report “I found this many bugs here”. In response to such bugs, I also say, “Well, I want you to test it from this point of view and see if there are any other bugs.” In fact, sometimes it is a design problem, so I can review the design document and create a brushed-up version.
Furthermore, in the team I am in now, bugs were considered bad, but since I joined the team, we have been able to collaborate and spread bug information horizontally, review similar programs more thoroughly, and communicate more actively as a team. The quality of our work has definitely improved. In addition, when a bug is pointed out by a customer, we always say “Thank you for pointing out the bug” and thank the customer for finding the bug for us, instead of just apologizing.
#Experience Report 34
Male, Company Employee, Production Engineering 7 years
Q1. What type of work do you do?
Planning based on manufacturing drawings and issuing work instructions. I also troubleshoot problems during manufacturing and improve manufacturing efficiency. Making improvements is my main job, and I am constantly learning how to reduce flow time and man-hours while ensuring quality. It is necessary to incorporate new elemental technologies and to become familiar with new equipment and tools. The production engineers are often consulted by the shop floor and also receive quotations for new orders from the sales staff, so they are busy with complicated tasks every day.
Aside from production engineering, I also work as a member of the quality secretariat, establishing and maintaining internal standards, conducting regular audits as an internal auditor, and patrolling as a member of the safety and health committee. I also manage my subordinates (attendance management, performance evaluation, work management) and the budget of the department.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
I was transferred from the manufacturing floor to the production engineer, but each of us had completely different feelings and thoughts. Since each of us did not have a good grasp of each other’s work, we found out after the transfer that our attitude toward the production engineers was not good.
Specifically, when I was on the shop floor, the most important thing was the production schedule (of course, quality was important), and I used to make unreasonable requests to the production engineers (such as early resolution of troubleshooting problems, issuing temporary work instructions, etc.) in order to keep the delivery date. However, when I became a production engineer, I learned that in order to issue work instructions, I had to show the technical basis before planning the work. Now that I have become a production engineer, I order my workers not to make unreasonable requests, but I am having a hard time persuading them to do so because there is a contradiction with what I used to do when I was in the field. For this reason, he makes it a point to share his experience with his subordinates when instructing them. I also make an effort to convey to the workers what is necessary in terms of production technology and what is determined by the standard. At the same time, I make sure that I and my subordinates are well aware of standards and public standards, and I have started to proactively implement internal standards. In addition, I am promoting the establishment of departmental standards to eliminate ambiguous work.
Q3. What is the one thing you are really glad you did?
Since I have been reading up on internal and public standards, I am now able to show compliance and have a dialogue even when there is a conflict of opinion. I started to do this because of the mistake I mentioned in the previous section, but since I started to do this (even as a quality office staff member), I have been receiving more questions not only from my subordinates and colleagues, but also from my superiors. It’s hard because it means more work, but even in the case of an emergency such as the Corona incident, I think I will have less trouble because I won’t have to work. Also, since I have started to read documents more carefully, I think my ability to create my own standards has improved. As a result, I think that my ability to correct documents prepared by my subordinates has also improved.
In terms of the manufacturing industry, I am currently working as a production engineer, and I think it was very good that I was transferred to a production engineer after experiencing the field. Because of this experience, I have gained the awareness that everything I do, no matter what it is, is ultimately connected to the company’s goals. Because of this, I think I am able to communicate better with people in other departments than before. I used to be uncomfortable dealing with external audits, but now I don’t mind it so much anymore, and I think this is because of the same reason. (This is just my own opinion).
#Experience Report 35
Female, company employee, information and communication industry, embedded software engineer, 7 years
Q1. What type of work do you do?
The final delivery destination is the automobile manufacturer. We are engaged in contract and in-house product development of software to control automobile parts. Based on the requirements of the development requester, we are responsible for the entire process from overall design of the software to manufacturing, inspection, and shipping. As for project management, we carry out operational tasks from planning (amount estimation, factor piling, factor adjustment, schedule creation, quality control planning, etc.) to schedule management, etc. As we are developing embedded software, the main development language is C. In designing, we will use development tools specified by the client. We also support model-based development according to customer instructions. During verification, we use MILS and HILS to confirm quality standards.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
One of the most memorable mistakes I made after entering the workforce was not being able to establish an appropriate relationship of trust with a junior colleague whom I supervised as an OJT instructor for the first time. At the time, I was in my third year of working, and I felt a strong sense of responsibility because it was the first time I was in charge of a direct junior colleague. The junior colleague was a first-year female employee who had a strong sense of responsibility and was like a mood maker for her peers, although she had some concerns about her technical skills. That year, there were 10 of us who were assigned to the same department as the junior colleague, which was quite a large number, and I could see that the atmosphere of the department changed completely as the newcomer was assigned. In a good way, I felt that the workplace became more lively and relaxed. “As an OJT, I had to do something about it,” I thought, feeling an unnecessary sense of responsibility all by myself. I heard comments from my seniors around me such as, “It’s not a good atmosphere,” and “It looks like he’s just playing around,” which made me feel even more compelled to do something about it. As a first-time employee, I didn’t know how to communicate well, so I just paid attention to the problems from time to time and pretended not to see most of them. One day, as the entire department was working late into the night to complete a project, two or three newcomers came to the seat of a classmate who hadn’t finished work and chatted in a loud voice that echoed across the floor for about two hours. “Why are you behaving like this when your seniors are working so hard until so late?” “How can you leave your own work unattended and just chat?” I was so angry, but I thought there was nothing I could do about it, so I continued working without saying anything. When I finished work in the middle of the night, I decided that I should “instruct” my junior colleague on how to behave, so the next morning I left home and went to the office close to the first train. I decided to write an e-mail to my juniors who were chatting loudly. My anger had subsided after one night, but I didn’t have the courage to tell them verbally in person, so I sent them an e-mail stating that I wanted them to “read the atmosphere of the project and act accordingly. As it turned out, after that e-mail, the junior members of the team started to ignore most of my comments and e-mails, and there was no reply to the e-mail I sent.
The above experience is still a painful memory for me to recall, but there are two problems I have. The first was that I took on everything by myself and could not consult anyone. I don’t think the atmosphere of the department or the project was something that a young person in his third year could manage. It was a matter that should have been considered as a whole after involving senior staff and superiors and sharing the problems at that point. Secondly, I was not able to build a relationship of trust with my junior colleagues. Even though this is their first year in the workforce, they are already adults and have their own ego, thoughts, and actions. As I was not able to accept my junior colleagues as they were and acknowledge their existence, I was not in a position to “mentor” them.
I still haven’t been able to repair my relationship with those junior staff, but I have learned a great lesson. When you have a problem, consult with as many people as possible as soon as possible to increase the number of people you can talk to about the problem. In addition, the first thing to do is to build a relationship of mutual trust by accepting all people as they are as human beings. It may seem obvious, but it was an experience that taught me something important as a member of society.
Q3. What is the one thing you are really glad you did?
My company is basically built on a business model similar to that of a staffing agency. The business is based on assigning people with the skills required by the client to work for the client at a fixed monthly rate. Therefore, it is more common to be called into a project at the halfway point and have the contract terminated at the halfway point than to start a project at the same time. Because of this way of working, it is easy to have a situation where you don’t feel attached to what you are developing.
I think the thing I am most proud of in my working life so far is that I was able to put all my energy into the projects I was involved in and put my heart into what I was developing. No matter how short-term the job was, I worked with the intention of dying to see the entire architecture (mechanism) of what I was developing. Some people may say that I was overdoing it, but I am proud to say that thanks to this, I became an engineer who can discuss the various architectures and their merits and demerits. I believe that how you grow as an engineer in the business model of man-month business is how you increase the number of drawers you have.
#Experience Report 36
Male, part-time, management, System Engineer, programmer, about 12 years
Q1. What type of work do you do?
Please give us a brief description of your work. Initially, I developed and maintained a system to manage the company’s business performance, etc., programmed and tested a tax system (real estate acquisition tax and other tax systems) for a local government (Saga Prefecture), maintained and handled bugs in a tax system (real estate acquisition tax system) for a local government (Kumamoto Prefecture), programmed and tested an in-train sales system for JR Kyushu (instructed newcomers from other companies on how to program and test the system), and basically designed a sales system for an electric power company (instructed each person in charge (sales office) on how to program and test the system). Program development and testing of JR Kyushu’s in-car sales system (instructing newcomers from other companies on procedures for creating programs and testing methods); basic design of an electric power company’s sales system (meetings with each person in charge (sales office), input screens, output forms, etc., compiling various opinions, etc.); design and programming of a Co-Op Mutual Aid delivery system. I also designed and programmed the home delivery system for a coop mutual aid company, programmed the logistical support system for Mitsubishi Heavy Industries, and worked on a contract with Fujitsu Minamikyushu System Engineering Co.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
For about two months, we analyzed the system, considered changes and new mechanisms, and carefully and meticulously prepared various details such as program modifications, specifications for the new program, test outline, test data creation, and verification of results. However, due to a programming error in a single line (instruction), the actual test was postponed until six months later, and the company suffered a loss because it was not able to improve the efficiency of operations, unify work procedures, and simplify work processes that the system was supposed to bring about. I went back to the basics of spinach (reporting, communicating, and consulting) and took measures to deal with even the smallest questions so that everyone in the project could share the same information and work with the same vector. I also made sure to check all the important points with my own eyes to make sure that the project was being carried out properly. By checking the important parts of the project, we can respond faster and make fewer mistakes when problems occur. Also, it is difficult to create a new system or improve the efficiency of operations if you are not more familiar with the business than the people in charge of each department. One of the most important things is to develop business knowledge and make it your own.
Q3. What is the one thing you are really glad you did?
When I graduated from high school in the latter half of the 1980s, large computers were the mainstream, with large computers installed in the computer room, magnetic tape devices, and large magnetic disk devices, and the room temperature was 5°C to 10°C all year round. I joined the company at a time when we were using 8-inch floppy disks (storage media), which today’s young people don’t know. It was there that I came across a programming language called COBOL, which was developed in 1959 for office processing. Its name comes from “Common Business Oriented Language”. I believe that COBOL was the predominant program language at that time. What I’m really glad I did as a programmer. If you are a high school or vocational school graduate, you will probably be working as a programmer for about five years, especially from your first year of employment. That’s why you need to understand structured programming. It has been mathematically proven that when you get down to it, a program can be constructed with only three things: conjunction (sequential), selection (judgment, if statement, etc.), and iteration (loop, for statement, etc.). I believe that we need to make this a part of our understanding. I’m really glad I did this as a system engineer (System Engineer). The work of a system engineer (System Engineer) is broad and includes basic design, system design, program design, etc. It requires negotiation skills, communication skills, management skills, judgment skills, leadership skills, and business knowledge. Negotiation skills are the ability to facilitate discussions between people who do not have the same interests. It is one of the most important skills when talking with customers and clients about business contents and systems. Judgment” is the ability to recognize and evaluate things correctly. It is also said to be a matter of potential and ability. Judgment is also one of the abilities that are very necessary and tested in the process of building a system. Although I will not go into it this time, “leadership,” “control,” “communication,” and “business knowledge” are all abilities that cannot be ignored. I think you should think about it at least once.
#Experience Report 37
Male, Company Employee, System Engineer 35 years
Q1. What type of work do you do?
Our company’s business is surveying. We actually survey mountains, rice fields, houses, etc., and analyze the positional information by computer, and convert it into map information. I am in charge of analyzing the data, but I also design, produce, and test the processing system for the map data from the local government. I am in charge of data analysis, but I also design, manufacture, and test the processing system for the map data from the local government. Generally, you have heard of GPS, which is a system for measuring location information, and we use this device to convert location information into data. There are two methods of surveying: one is to measure the location of a reference point by a person, and the other is to acquire location information using a GPS-equipped drone. In both cases, the location information is one point at a time, so it is necessary to connect the points and collect the lines into a line to make a surface. The result is then converted into CAD data.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
I don’t have any major failures in my current job, but this is a story about when I was in charge of a manufacturing management system. When a company that makes metal parts manufactures them in a factory, a manufacturing plan is first created, and based on the plan, materials are ordered, sub-parts are made, and when the sub-parts are complete, the parts (products) are manufactured. Since these products are diverse and must be produced according to the daily plan, it is necessary to manage the inventory without fail, since production will stop if the inventory of materials and sub-parts runs out. The company had been using an excel-based inventory management system, but because the inventory count and daily production plan were entered manually, the inventory count often did not match. I decided to build a system to automatically calculate the number of stocks and the number of products to be manufactured. I extracted the data from the production planning system that was already in operation, and created a system (inventory status management system) that could calculate the inventory shortage from the planned number and the inventory number, and calculate the shortage on a daily basis. The problem occurred six months after the delivery of the inventory status management system. We were told over the phone that the inventory forecast was completely different, so we immediately obtained the data and checked it, but there was nothing wrong with the system. I suggested that we take a look at the situation for one month, but the inventory forecast did not match the next month either. The next month, the inventory forecast did not match. So we checked the system change history and found that the system had recently been added to another department’s system. Basically, it was an addition, so the inventory status management system was not affected. However, it coincided with the time when the failure started, so we checked the delivery history and delivery program, and found that part of the system was outdated. We replaced some of them with the latest ones, and the problem was fixed.
Q3. What is the one thing you are really glad you did?
When I first became a System Engineer, computers were not widely used, and the way System Engineer worked was different from what it is today. I would go to the client’s office with the sales staff and ask them to explain what they were doing and take notes. If I had any questions, I would ask them and leave a memo. While creating the program based on the memo, the person in charge of the program would decide on the details. In those days, this was the way most System Engineers worked, as there were few problems. However, there were times when we had to change the entire system due to a failure after delivery. So I proposed to create a specification document, but everyone was against it. The reason they gave was that it would take too much time and it would not be profitable. I tried to convince them that it would really take extra time to create the specifications, but in the end they could not agree. So I wrote the specifications myself, programmed it myself, tested it, and delivered it. It certainly took longer to deliver the system than other staff, but there were far fewer problems afterwards. As a result, we were able to demonstrate that the time spent on the final system was less. Seeing these results, some people started to agree with us and started to write specifications. Even now, there are people who disregard specifications, but I believe that in the long run, it takes less time to complete a project by creating specifications.
#Experience Report 38
Female, company employee, major SIer,
system development for customers, 20 years
Q1. What type of work do you do?
I joined the company in 1991, at the height of the bubble economy. At that time, I started by developing programs in the UNX C language. After that, I did programming for client server systems such as Access, Excel, and Power Builder in Visual Basic. I also worked as a project leader for several people and managed subcontractors. I also worked on expanding sales of our own hardware and software, preparing presentation materials, quotations, proposals, and orders. I participated in the PMO of a large-scale national project and received an internal award. After that, I left the field work and transferred to the staff department within the company. This department promotes orders from overseas software vendors. I focused on how to promote ordering from overseas.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
When I first joined the company, programming, environment building, and other “so-so engineering” jobs were the work of full-time employees. At the time I joined the company, we were still able to get paid a lot of money by our customers for such work. With the bursting of the bubble economy and technological innovation, there were fewer customers willing to pay high prices for jobs like programming and environment building. Not only for system engineers, but also for general office workers, the number of part-time jobs that can be released cheaply and easily has been increasing. As a full-time employee, my position changed to “doing the work that non-regular employees cannot do. The industry used to have a lot of long hours of overtime work, but it has changed to an era where the content of the work is evaluated more than the overtime hours. In other words, jobs that could be done by non-regulars, such as programming and environment building, could not be evaluated as full-time jobs, and the industry changed to an era where non-regulars with lower unit prices were taking away the jobs. The biggest mistake I made was that I liked technology, and I liked to read and study about it. When I had a meeting with my supervisor, he scolded me for taking a subcontractor’s job with a high salary. I was very shocked. After that, I made it a point to be a full-time employee of the company before being an engineer, and started to focus on staff work rather than working on the front line as an engineer.
Q3. What is the one thing you are really glad you did?
In my mind, my ideal was to find a job that I wanted to do and study hard to develop my skills. However, working as a company employee was a different story. You can learn as much as you want about technology by reading books or paying to attend seminars. Women, in particular, are not very good at “salaried life skills. Men talk about their jobs whenever they have time, but women talk about their children, so they don’t have the opportunity to learn the “salaryman way of life. What I found helpful was a comic book and an evening newspaper for businessmen that my husband bought. As I casually read them, I realized that this is how men and businessmen think, and it was like solving a puzzle. For example, women get angry at the lack of equality, saying that it is unfair, but men think that they deserve to be blessed with what they have bought through competition. Men tend to think that people who can do managerial jobs are superior and get paid more money, while women tend to think that people with high skills should get higher salaries. Learning the difference in these ways of thinking gave me a sense of accomplishment as I understood how to behave in a company-like manner to gain recognition and increase my bonus. By proactively participating in leadership and communication work as well as technical work, I was able to increase my company’s assessment and my bonus.
#Experience Report 39
Male, Company employee, System engineer, 2 years
Q1. What type of work do you do?
Please tell us briefly about your work. This is a customer-resident type of work where I go to the customer and provide technical support. I mainly work on system operation, maintenance, and development under contract for each project from customers. Sometimes we also undertake contract development, and sometimes we develop and build the systems requested by our customers in-house. If there is a problem with the system, I try to find out what caused the error, and if it needs to be fixed, I try to improve the system to make it better. The system is mainly composed of VB. NET, and system development is done by programming. After development, the system is tested to make sure there are no problems before delivery.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
About a year ago, I had a job handling measurement equipment for road construction, and I had to give a lecture on how to use the equipment in front of customers. The job was not particularly difficult, and all I had to do was to import data from the measuring equipment into a computer, access a page for viewing, and teach the customer how to operate it. However, on the same day, when I tried to import the past recorded data from the receiver to the PC, the PC did not recognize the receiver and could not read it no matter how many times I tried. As it turned out, it was simply because the USB connection to the Virus Buster was trapped and the connection was blocked, but as a newcomer, I was in such a hurry to think about the atmosphere at the construction site and the customers who were waiting for me later that I didn’t notice it at all. As a result, we took a lot of time to acquire the data and had to go to the customer’s place late. Fortunately, the customer was able to understand our explanation and was satisfied with the operation explanation, so we were able to avoid the problem. The customer at that time had a good personality, and I was really glad that he didn’t seem to mind that much. However, I think that some people may have complained about the content. The reason for this was that we had prepared in advance, but due to company circumstances, we had to change the laptop we were going to bring right before the event. I realized once again how important it is to prepare carefully in advance, not just in case something goes wrong, so now I make sure to prepare thoroughly in advance, especially when I go in front of customers. I try to be prepared for any possible situation that may arise, so that I can avoid any shortfalls.
Q3. What is the one thing you are really glad you did?
At our company, we prepare a monthly report that reviews our monthly operations. Basically, the content of the report is checked by those in higher positions, but since the data is stored where everyone can view it, I made sure to look at the report for everyone for the sake of study. I was curious about how other employees summarized their work, and I was also confused about how to write my own, so I thought that doing this would help me improve my business skills. I actually learned a lot, and I think I gained a lot of different perspectives. I was able to discover a perspective on business that I had never paid much attention to before, and it has broadened my approach to work. It has helped me to catch information from a broader perspective. Also, by looking back at my work for the month, I was able to notice the things that I needed to reflect on and work on improving, and by re-summarizing, I was able to genuinely improve my writing summary skills. What was interesting was that there were some reports that were just the same as the previous one, copied from the previous one, or without any particular content. I have learned to refer to the good points of those who are very good at summarizing and incorporate them into my own skills, and to keep in mind not to use those who are not good at it as an example, so that I can constantly improve my own work and enhance my skills.
#Experience Report 40
Male, Company employee, Trading company,
System Engineer and programmer 6 years
Q1. What type of work do you do?
Software development of our own packaged products [Software content] In shield construction work at civil engineering worksites (construction work to create a path for tunnels by rotating a cutter attached to the end of a cylindrical machine called a shield machine, in the image of a mole moving through the ground), we collect measurement data attached to the shield machine (position information, speed information, underground soil pressure information, etc.) at the ground office. The data from the measuring equipment (position, speed, soil pressure, etc.) attached to the shield machine is collected at the ground office. The collected data is converted into a 3D model, and the software visualizes the actual construction site in an image close to the real world. Development environment] — OS: Windows — Language: Ruby, HTML, JavaScript, CSS — DB: SQLite [Development work] — Basic design, detailed design, coding, testing, release, operation/maintenance.
Q2. Please tell us about the biggest failure you had in your engineering career and What was the biggest failure in your engineering career and how did it change your behavior?
The biggest failure] During software development, we had a meeting to promote our software to other companies. The day before the meeting, we were modifying a function and found a mistake in the data linkage. The mistake was coded as if it was working on the surface, but the day before the meeting, the boss confirmed that the wrong function had actually been implemented. Since it was around 11:00 p.m. the day before and there was no time to fix it, we discussed how to cover it up in the meeting. I realized that I should report honestly to my supervisor even if I couldn’t improve the function in time. I realized that I should have reported honestly to my boss even if I couldn’t finish the functional modification in time. This was the reason why I and others were in a tight spot. After the failure, I started to report and consult with my supervisor when I had a tight deadline or an irregularity at the very last minute. In this way, I was able to find a way out or solve problems that I thought I could not do by myself. Development work can take a turn for the better if you consult with others, not alone. I have become more conscious of involving others instead of keeping things to myself.
Q3. What is the one thing you are really glad you did?
In the development process, there is something called “code review”.
First of all, “code” is the characters that are typed on a computer to create software. When you hear the word “programming,” you probably have an image of typing a lot of English-like characters on a computer. That’s exactly what it is, and the letters that are being typed are called “code”.
“Review” means to have someone else look at what you have created (in this case, the code) and give you an opinion. For example, a family member or a friend might look at a sentence you wrote in your notebook and say, “The wording is not quite right, is it? If it is a familiar thing, it refers to the time when your family or friends look at the text you have written and give you their opinions, suggestions, and evaluations, such as, “I don’t understand this part, so you should write it like this to make it easier to understand.
“Code reviews are important to get hints on how to write readable and high quality code by reviewing the code you have written.
Even if you are confident in the code you have written, there are often things that others find strange, or that are wrong and unreadable. By listening to the opinions and changing the way the code is written, it becomes easier to read and the software becomes more stable.
There is no harm in doing a code review. In fact, it will improve the quality of your software. It is an action that you should definitely take.
Engineer’s Spirit #1~#10
Engineer’s Spirit#11~#20
Engineer’s Spirit #21~#30
Engineer’s Spirit #31~#40
Engineer’s Spirit #41~#53
