Embedded Engineer 가 되기 위해서 좋은 책들을 검색해 보았는데, 가장 실질적인 조언을 준다고 생각되는 책(So, You Wanna Be an Embedded Engineer)을 찾았고 그 중 마음에 드는 부분을 번역 해 보았습니다.
한국에서 출간되지 않아 영문책을 구매했기 때문에 전체 내용을 제대로 봤다고 생각되지 않지만.. 아래 내용 Practical Skills You'll Want to Acquire (당신이 얻고싶은 실질적인 기술들) 은 심플하면서 이해가 잘 됩니다.
---
Regardless of how far you eventually intend to specialize, there is a small core of baseline skills that will benefit you greatly in any sector of embedded engineering. Some of these skills are taught explicitly in college, some of them are mentioned peripherally but not examined in any great detail, and the remainder are acquired and honed exclusively through practical experience.
당신이 전문가가 될지 고민하는것과 상관 없이, 임베디드 엔지니어링의 어느 분야를 공부할 것인지에 상관없이 기본이면서도 가장 중요한 부분이 있습니다. 일부분은 대학교에서 명시적으로 알려주기도 하고, 다른 일부분은 대략 주제는 알게되지만 자세하게 이야기 되지 않습니다, 그리고 나머지는 실질적인 경험으로만 단련될 수 있습니다.
I hope the fact that you're reading this book — and presumably somebody paid to buy it — helps to demonstrate that one of the most important skills you can acquire is to learn the lost art of effective reading and writing in the apparently dead language known as English. Most engineers will probably not author full-length books, but any good engineer will write many thousands of words of technical documents in their careers, including the following:
저는 당신이 이 책을 읽음으로서 — 아마 돈을 내고 샀을 텐데 — 영어로 배우고 쓴다는 것이 중요하다는 것을 배울 수 있었으면 합니다.(의역) 많은 엔지니어들이 책을 쓰지는 않지만 실질적으로 많은 기술에 대한 문서를 작성합니다. 아래 내용들을 포함하여,
• Product specifications, explaining to marketing and the people who write your product manuals exactly what the product will do
• 제품 설명서, 제품을 쓸 사람에게 이 제품이 어떻게 동작할 것이라는 것을 명확하게 설명
• Protocol specifications, explaining to other engineers how to talk to your product
• 통신 규약 설명서, 다른 엔지니어에게 제품과 이야기를 나눌 수 있는지 설명
• White papers, describing to other engineers what you've been working on and useful discoveries you've made
• 논문, 다른 엔지니어들에게 당신이 무엇을 했고 어떠한 유용한 발견을을 했는지 자세하게 설명
• Patent disclosures
• 특허 공유
• Instructions to subordinates
• 같이 일하는 사람들(특히 경험이 없는)에게 지시
• Articles for technical journals (Being published in this way can substantially improve your visibility within an organization — think raises and promotions.)
• 기술 저널에 글 쓰기(이런곳에 글이 실린다는 건 소속된 회사에서 상당한 존재감을 나타낼 수 있음 — 유명해지거나 승진 등)
• Debugging information, communicating with vendors, quality assurance
technicians and engineering colleagues to solve complex problems
• 디버깅 정보, 협력사와 논의 하거나, QA부서 인원 그리고 같은 일을 하는 엔지니어들과 복잡한 문제를 푸는 것)
• Justifications (dare I say it) for taking a specific course of action (When things get out of control and the recriminations start to fly, the one with the best paper trail usually wins.)
• 어떤 일을 해야함을 타당한 이유를 들며 설명할 수 있는 것
Most engineering students — in fact, I can generalize wildly and say most science students — regard language skills as a mere waste of time, required by an idiotic college bureaucracy. Unfortunately for these students, it has been my experience — very rarely contradicted — that engineers who can write intelligible and concise documents are precisely the same engineers whose specifications are complete and easy to understand, whose code is well-structured and simple to read, and who have little difficulty communicating effectively with co-workers.
엔지니어 공부를 하는 학생들은 — 일반적으로 이야기해서 과학을 하는 학생들은 — 언어 공부는 시간낭비라고 생각한다, 관료적인 것이라고 생각합니다. 불행하게도 그런 학생들에게 이야기 하고 싶은 것은, 내 경험을 미루어 보아 — 대부분은 — 이해하기 쉽고, 간결하게 문서를 작성하고 코드가 잘 구조화된 사람들은 동료들과 소통하는데 덜 어려움을 겪습니다.
You'll note that the BSEE breakdown I gave in Section 2.1 only shows six credits of English. This is more or less representative of the average BSEE degree; you can add a little more writing and speaking experience in the liberal arts electives, but no matter how you wiggle your course schedule, a bachelor's degree in engineering is only going to give you the barest possible taste of formally taught language skills.
제 2.1 절에서 언급 한 BSEE 내역은 영어관련 6 학점 만 보여줍니다. 이것은 BSEE의 평균적인 정도를 나타내는 것입니다. 당신은 교양 선택 과목에서 약간의 쓰기와 말하기의 경험을 추가 할 수 있지만 코스의 일정을 어떻게 바꾸어도 공학 학사는 정식적인 언어 능력의 일부만을 경험할 수 있습니다.
You need to practice this. Voracious reading — not just technical books, but fiction and nonfiction by good authors — is essential; reserve time for it in your week (hints: the bath is a great place to relax and read, and Project Gutenberg has numerous free electronic texts you can download to your PDA and read anywhere) . Practice writing wherever you can; before I was ever published, I honed my skills largely in banter — technical and otherwise — on Usenet and, previously, Fidonet. Good language skills can float a competent engineer significantly above their colleagues.
당신은 더욱 열심히 책을 읽어야 합니다. — 단순히 기술 책이 아니라 좋은 작가의 소설과 논픽션 — 필수적입니다. 한 주마다 그것을 위한 시간을 마련 하십시오 (힌트 : 목욕시간은 읽을 수있는 완벽한 시간입니다 그리고, Project Gutenberg는 많은 책을 PDA에 다운로드할 수 있게 해 주었습니다. ). 시간 있을 때마다 쓰세요. 내가 첫 책을 출판하기 전에, 기술적으로도 그렇지 않아도 Usenet 및 이전 Fidonet에서 나의 능력을 크게 손질했습니다. 뛰어난 언어 능력은 유능한 엔지니어를 동료들과 선명하게 구별지을 수 있게 해줍니다.
Another essential skill set on which you will not touch significantly in formal education is PCB layout and an understanding of DFM (design for manufacturing) concepts. Both of these are specialties in their own right, but from the perspective of the embedded engineer, they're closely related and can be learned at the same time. Although a design engineer in a company of even modest size probably won't spend any significant time working on layouts, there's a great deal of practical value in understanding at least the basics of what is involved in the processes of designing, laying out, and populating (stuffing) PCBs.
정규 교육에서 배우기 힘든 또 하나의 필수 기술은 PCB 레이아웃 및 DFM (제조를위한 설계) 개념의 이해입니다. 모두 임베디드 엔지니어의 전문 분야이며, 임베디드 엔지니어의 관점에서 보면, 그들은 밀접하게 관련되어 있으며, 동시에 배울 수 있습니다. 아마 적당한 크기의 회사의 설계 엔지니어는 아마 레이아웃 작업에 많은 시간을 할애하지 않지만, 적어도, 디자인, 레이아웃 및 프로세스의 프로세스에 관련되는 기초를 이해하는 데에서 PCB를 채우기 (포장 포함)
I'm not counting people for whom English is a second language in this statement. Wherever I write "English" in this section, you can substitute "the engineer's native language." It's language skill, not specifically English skill, that I'm talking about. However, if only because the majority of scientific and technical publications are in English, it would be prudent to study this language if you don't speak it natively.
저는 영어가 제 2 언어 인 사람을 말하고 싶은것은 아니지만, 이 섹션에서는 '영어'라고 쓴 경우, "엔지니어 모국어 '를 의미한다고 할 수 있습니다. 내가 말하고있는 영어 실력이 아니라 언어 능력입니다. 그러나 과학 기술 잡지의 대부분이 영어로 쓰여져 있는 사실을 생각해 보면 영어를 공부해야 하는것이 당연합니다.
A pre-Internet worldwide network of bulletin board systems; my system was ZWSBBS, 3:634/396.
Fidonet still exists (though greatly shrunken since my days there) and is connected to the Internet at various points — see <http://www.fidonet.org/> for more information.
인터넷 전의 세계적인 네트워크는 BBS(bulletin board systems) 이었습니다. 저의 경우 ZWSBBS, 3:634/396를 사용 했습니다.
Fidonet은 여전히 존재하며 (많이 그 크기가 줄었지만) 다양한 경로로 인터넷과도 연결되어 있습니다. . 자세한 내용은 <http://www.fidonet.org/>를 참조하십시오.
If you work at a large company, you'll have opportunities to talk to the manufacturing engineers and PCB layout artists and glean a lot of useful wisdom; you should seize these opportunities when available. You don't necessarily need to annoy people with incessant questions; merely listening carefully at design reviews will greatly improve your understanding of the issues. There's a very large body of succulent information tidbits that seem intuitively obvious once you hear them, but which you might never think of yourself;
대기업에서 일하는 경우, 제조 엔지니어와 PCB 레이아웃 아티스트와 이야기를하고 많은 유익한 지혜를 모으는 기회가 있습니다. 이 기회를 잘 활용해야 합니다. 끊임없이 질문하면서 괴롭히라는 것은 아닙니다. 설계 검토 회의 시에 신중하게 듣는 것만으로 중요한 부분에 대한 이해가 크게 향상됩니다. 듣기만 해도 직관적으로 이해되는 다량의 정보들이지만 혼자 일했다면 절대 얻지 못할 것입니다.
for example, the need to keep ceramic surface-mount capacitors away from the edges of PCBs to avoid cracking them during depanelization; ensuring that you leave sufficient clearance around a surface-mounted microcontroller to allow use of a test clip; understanding how components drift or self- align on their pads when they go through the infrared reflow oven; and so on.
예를 들어, PCB를 자를 때(depanelization) 세라믹 표면 실장 커패시터를 PCB의 가장자리에서 멀리 떨어지게 유지해야 커패시터가 부서지는(cracking) 되는 것을 막을 수 있습니다. 테스트 클립을 사용(연결)할 수 있도록 표면 장착형 마이크로 컨트롤러 주변에 충분한 여유 공간을 확보하십시오. 적외선 reflow 오븐을 통과 할 때 패드에서 부품이 어떻게 이동 및 자체 정렬되는지 이해 등등
You'll also need a lot of practical software debugging experience. A good starting point for this is simply your college courses — if you work at the computer science and other programming-related course work with sufficient assiduity, you'll have a reasonable start on the methodology of software debugging by the time you graduate. However, one issue for which school will leave you almost completely unprepared is how to jump in at the deep end and start maintaining someone else's large code project.
실용적인 소프트웨어 디버깅 경험이 많이 필요할 것입니다. 이 과정을 시작하기에 좋은 출발점은 단순히 대학 과정입니다. 컴퓨터 과학 및 기타 프로그래밍 관련 과정을 충분히 조화롭게 공부하면 졸업 할 때까지 소프트웨어 디버깅 방법론을 합리적으로 시작할 수 있습니다. 그러나 학교에서 거의 준비가 안되는 문제 중 하나는 다른 사람의 대규모 코드 프로젝트의 심층적 인 상황에 뛰어 들어 유지보수를 해보는 것입니다.
It is practically guaranteed that your first job (and every subsequent job, for that matter) is going to involve maintaining some legacy code. You can be very lucky and find code that is accurately documented and well-commented, or you can encounter code (as I have) that contains no comments at all and is structured in such a complex and bizarre fashion that adding or removing a single comment line can cause the compiler to abort with an internal error. The most useful learning technique I have found for this is to take an open-source project and add specific simple functionality to it. For instance, you might set yourself the goal of modifying the IDE driver in the Linux kernel so that it turns on a
첫 번째 직업 (및 모든 후속 직업)에는 기존 코드를 유지 관리하는 것이 사실상 확률적으로 당연할 것입니다. 정확하게 문서화되고 잘 주석 처리 된 코드를 보는 것은 운이 정말 좋은 것이며, 개인적인 나의 경험처럼 주석이 전혀없는 거나 하나의 주석을 추가하거나 제거하하면 예상하지 못한 컴파일 에러가 생기거나 내부 에러가 생기는 코드를 보게 될 수도 있습니다. 내가 찾은 가장 유용한 학습 기술은 오픈 소스 프로젝트를 가져 와 간단한 기능을 추가해 보는 것입니다. 예를 들어 리눅스 커널의 IDE driver를 수정하는 것을 목표로 할 수도 있습니다.
A general disadvantage of learning in the school context is that you know that the problem you've been assigned has a solution, you know that you have been given the skills and the time to find that solution, and you can make inferences (from where your class is up to in the curriculum) as to which specific skills are likely to be relevant to the problem. Real-world problems don't have any of these guarantees or hints; you're on your own with a clock (and budget) steadily ticking away and management breathing down your neck. Enjoy your time at school; these are the easiest problems you will ever be asked to solve.
학교 학습의 일반적인 단점은 당신이 할당 된 문제에 해결책이 있다는 것을 알고, 기술과 그 해결책을 찾을 수 있는 시간을 얻었고, 추론을 할 수 있다는 것을 알고 있다는 것입니다.(당신의 수업은 커리큘럼이 짜져 있으니..) 어떤 특정 기술이 문제와 관련이 있을지 결정합니다. 현실 세계에서는 이러한 보장이나 힌트가 없습니다. 시간은 가지만 (그리고 돈도 없어지고) 경영진이 당신 바로 뒤에 지켜보고 있습니다.. 학교에서 즐거운 시간 보내십시오. 학교에서의 과제들은 당신이 풀어야 할 가장 쉬운 것들입니다.
red LED whenever a write operation is requested from the application layer, or a green LED for read operations. A more challenging project might be to take an open-source operating system, such as NetBSD or eCos, and port it to a new board. In any case, the goal is to understand enough of the existing code to know where to insert your changes and modify the code as nonintrusively as possible to avoid creating bugs.
쓰기 작업이 응용 프로그램 계층에서 요청 될 때마다 빨간색 LED 또는 읽기 작업에 녹색 LED가 표시됩니다. 더 어려운 프로젝트는 NetBSD 또는 eCos와 같은 오픈 소스 운영 체제를 사용하여 새 보드에 포팅하는 것입니다. 어쨌든, 목표는 기존 코드를 충분히 이해하여 변경 사항을 삽입 할 곳을 파악하고 가능하면 코드를 수정하여 버그를 만들지 않도록하는 것입니다.
Finally, most embedded engineers are going to need at least rudimentary laboratory skills. This includes being able to solder up prototypes and operate an oscilloscope, signal generator, and spectrum analyzer. The introduction you'll receive in college is probably adequate grounding in this; you'll gain much greater facility with experience, of course. In this day and age, it's also very useful to be able to work with surface-mount components. You can practice this very inexpensively on any junked piece of hardware — an old PC motherboard, a DVD player, or any similar board with lots of parts on it.
마지막으로, 많은 임베디드 엔지니어들은 기본적인 연구소 기술을 익혀야 합니다. 그것들에는 프로토타입을 직접 납땜해서 만들 수 있다거나, 오실로스콥을 작동시키고, 시그널 생성기를 만지고, 스펙트럼 분석기를 쓸 수 있는 것들 입니다. 당신이 대학에서 받게 될 소개는 이것에서 적절한 접지 일 것입니다; 물론 훨씬 더 큰 편의 시설을 경험하게 될 것입니다. 이 시대에는 표면 실장 부품으로 작업하는 것이 매우 유용합니다 - 오래된 PC 마더 보드, DVD 플레이어 또는 그 위에 많은 부품이있는 유사한 보드를 사용 하는 것
I'm sure you've noted the recurring theme here: even if you learn some skills theoretically at school, I'm exhorting you to find opportunities to keep working at example problems requiring those skills in real life. Furthermore, a lot of what you need to know can only be acquired through dealing with actual problems. Engineering is a practical discipline. Steep yourself in homebrew projects to keep your skills fresh and ready for action; you're also demonstrating self-motivation to future employers.
당신은 지금까지 반복된 내용을 알았을 겁니다: 만약 학교에서 이론적으로 어떤 기술을 익혔을 지라도, 그 내용들을 실제 상황에서 볼 수 있는 기회를 찾기를 바랍니다. 많은 것들이 실제 경험을 통해서만 알 수 있습니다. 엔지니어링은 실질것인 것입니다. 신 기술에 적응하고 바로 실행할 수 있도록 하려면 자신을 숙성시키기 위해 노력을 해야 합니다. 당신은 미래 고용자들에게 어필을 하는 것입니다.
