本文共 16373 字，大约阅读时间需要 54 分钟。
电子工程师自学成才pdf
In this post, I will share my experiences and give advice now that I am six months into my first job as a self-taught software engineer.
在这篇文章中，我将成为一名自学成才的软件工程师，距离我的第一份工作已经六个月了，我将分享我的经验并提供建议。
Note that this post will not be focused on how to get a software engineering job. Check out my previous post, for more information on that.
请注意，本文将不集中于如何获得软件工程工作。 查看我以前的文章以获取有关此信息的更多信息。
Note also that this is just one data point regarding my experiences with one company!
另请注意，这只是关于我在一家公司的经历的一个数据点！
I remember when I was looking for a job and was absorbing a ton of reading materials regarding the tech industry, learning programming, and success stories, my main focus was finding out how to get a job. But I was always a little curious what it was like once you actually got the job. The purpose of this post is to try to answer some of those questions.
我记得当我在找工作并吸收了大量有关技术行业，学习编程和成功案例的阅读材料时，我的主要重点是找到如何找到工作。 但是，我总是很好奇，一旦你真正找到工作，那会是什么样子。 这篇文章的目的是试图回答其中的一些问题。
What was the first day, first week, first month like? Are there skills to learn that might not help for the interview but would help once you started working? Even if I get a job, how would I know that I’ll be able to do it and do it well?
第一天，第一周，第一个月是什么样的？ 是否有一些学习技巧可能对面试没有帮助，但是一旦您开始工作就会有所帮助？ 即使我找到一份工作，我怎么会知道自己能够做得很好呢？
I work as a software engineer at a company called Human API in San Mateo, CA. It is a healthcare tech startup with ~35 employees that focuses mainly on the user-centered exchange of healthcare data. I was hired as a software engineer focusing on the front end, using technologies such as React, Redux, and Sass.
我在加利福尼亚州圣马特奥的一家名为Human API的公司担任软件工程师。 这是一家拥有约35名员工的医疗技术初创公司，主要专注于以用户为中心的医疗数据交换。 我被聘为使用前端，React，Redux和Sass等技术的前端软件工程师。
The first day was pretty surreal. I had dreamed about working as a software engineer for a while, and it kind of still felt like a dream on the first day. There was an ice breaker treasure hunt for me to do that involved talking with everyone in the office.
第一天真是超现实。 我曾梦想过担任软件工程师一段时间，但第一天仍然感觉像是在做梦。 我需要进行一次破冰船寻宝活动，其中涉及与办公室中的每个人交谈。
I was given a “New Hire Success Plan” that included things such as:
我获得了“新员工成功计划”，其中包括以下内容：
But mostly, as you might expect, the first day involved getting my laptop set up with the proper environment.
但是，正如您可能期望的那样，大多数情况下，第一天涉及为我的笔记本电脑设置适当的环境。
The first week was mostly more of the same. Still getting all of my accounts set up correctly, finishing reading through onboarding documents, etc.
第一周大体相同。 仍然正确设置我的所有帐户，完成阅读入职文档等。
It felt so weird coding during the day on a weekday! I was also still getting used to the typical Bay Area startup perks. My tech lead kept calling me the “React expert” because I was hired as the main frontend person on that particular team. I’m not sure if that’s what he thought I was or if he was just trying to set the bar high. In any case, I tried to roll with it.
在一个工作日的白天感觉很奇怪！ 我也仍然习惯于典型的湾区创业项目。 我的技术主管一直称我为“React专家”，因为我被聘为该特定团队的主要前端人员。 我不确定这是否就是他的想法，还是他只是想将标准设置得很高。 无论如何，我都尝试使用它。
I was also learning about the agile process. We had daily 15 min “stand up” meetings where everyone would stand and talk about what they were working on, and if their work was “blocked” by anyone.
我也在学习敏捷过程。 我们每天有15分钟的“站起来”会议，每个人都可以站起来谈论他们在做什么，以及他们的工作是否被任何人“阻止”。
That was something I was semi-worried about when I was applying to jobs:
当我申请工作时，我对此感到半担心：
Is it bad if I don’t know agile, scrum, velocity, product increment, sprint, retro…?
如果我不知道敏捷，混乱，速度，产品增量，冲刺，复古……会很糟糕吗？
In my opinion, you don’t need to know what any of those things mean before you start your job. It might help in an interview because the interviewer might subconsciously think you are more credible if you do, but in reality, you could learn it in less than a day on the job.
我认为，在开始工作之前，您不需要了解任何这些含义。 这可能对面试有所帮助，因为面试官可能会下意识地认为这样做会更可信，但实际上，您可以在工作中不到一天的时间里学到它。
By this point I was doing some real development and actually contributing to the team. I was learning how to work with the designer, product management, and other software engineers. I started working from home on occasion which was awesome. I found that working from home occasionally made me way more productive in general. No one seemed to care when you came into the office or when you left which was a stark difference from my previous company. I also had WAY fewer meetings than I did in my previous job.
至此，我正在做一些实际的开发，并为团队做出了实际贡献。 我正在学习如何与设计师，产品管理和其他软件工程师一起工作。 有时候，我从家里开始工作。 我发现在家工作有时会使我的工作效率提高。 当您进入办公室或离开时，似乎没人在乎，这与我以前的公司有明显的不同。 与以前的工作相比，我的会议要少得多。
I hadn’t used Sass before, so I watched some videos and read some docs. It’s pretty similar to CSS, so that wasn’t a big deal. The project I was working on was fairly new, so there wasn’t a strict, standardized git workflow. Honestly, at that stage of the product, it was surprisingly similar to the way I would develop my portfolio projects. There was another thing I was semi-worried about…
我以前没有使用过Sass，所以我看了一些视频并阅读了一些文档。 它与CSS非常相似，因此没什么大不了的。 我正在从事的项目是一个相当新的项目，因此没有严格的标准化git工作流程。 老实说，在产品的那个阶段，它出奇地类似于我开发投资组合项目的方式。 我还有半件事担心……
Do I know git enough? What if there is some complicated git workflow, and I mess everything up?
我足够了解git吗？ 如果有一些复杂的git工作流程，而我搞砸了怎么办？
I do think it is valuable to get some experience using git on a team. Join a local meetup and make a project, go to a hackathon, contribute to open source. Get familiar with pull, push, merge, rebase. Go through the pain of dealing with merge conflicts. Do some reading on best practices for git workflows.
我确实认为在团队中使用git的经验很有价值。 加入当地的聚会，进行项目，参加黑客马拉松，为开源做贡献。 熟悉拉，推，合并，变基。 经历处理合并冲突的痛苦。 阅读有关git工作流程的最佳做法的一些信息。
You could learn on the job, but you’ll be far more effective if you come in having experience with common git workflows.
您可以在工作中学习，但是如果您有使用常见git工作流程的经验，将会更加有效。
Another thing I ran into a lot during the first month was trying to find out what I should do when I got stuck. Should I ask someone or struggle through it?
在第一个月中，我遇到了很多事情，就是试图找出被卡住时应该怎么做。 我应该问一个人还是奋斗呢？
One of the things I was really looking forward to about getting paid to code was having other people around who are smarter and know more than I do, so that I could get help when I was stuck.
我真正希望获得代码报酬的一件事是让其他人变得更聪明，比我了解更多，以便在遇到困难时能得到帮助。
When you are learning on your own, you don’t have that luxury, and you have to decide whether you should keep banging your head against the wall in front of you or look for a new wall to bang your head against.
当您自己学习时，您没有那么奢侈，您必须决定是否应该继续将头撞在面前的墙壁上，还是要寻找新的墙壁来撞在头上。
And then I realized…teaching myself how to code gave me a valuable skill. It is a skill to know how long to bang your head against the wall before moving on, finding a workaround or asking someone else. If you always had a room of mentors around to help you with every problem, you would never be forced to go through the painful struggle of deciding what to do next when you are stuck.
然后，我意识到……学习如何编码给了我宝贵的技能。 在继续前进，找到解决方法或询问其他人之前，先知道将头撞在墙上多长时间是一种技巧。 如果您周围总是有很多辅导员可以帮助您解决所有问题，那么您将永远不会被迫经历痛苦的挣扎，即在遇到困难时决定下一步该怎么做。
Your mindset should NOT be…
您的心态不应该是……
Wow, look at this! I have a room of software engineers who can help me!
哇，看看这个！ 我有一间可以帮助我的软件工程师！
or this…
或这个…
It should be more like…
应该更像是……
I am going to make an active effort to figure this out on my own, and if I need to ask for help, I will tell that person what I tried to do that didn’t work.
我将做出自己的积极努力，如果需要帮助，我会告诉该人我试图做的事没有用。
By now I have become comfortable with the code, my team, and the company in general. We have had a company picnic, an event at a brewery after a product release, a game night where everyone brought their favorite video games to play, we had the world cup playing at the office, and many more social events. There have been multiple stressful product increment demos as well.
到目前为止，我已经对代码，我的团队以及整个公司都感到满意了。 我们进行了公司野餐，产品发布后在啤酒厂举行的活动，游戏之夜，每个人都带来了自己喜欢的视频游戏，我们在办公室里玩了世界杯，还有许多社交活动。 也有多个压力大的产品增量演示。
I have learned from a lot of smart people, tried to be vocal within the company, sharing my opinions about how I think we should do certain things. I have been on the other side of technical interviews, been involved with multiple product releases. I also started to get more involved with the backend as that is ultimately what I enjoy the most.
我从很多聪明的人那里学到了东西，试图在公司内部发声，分享我对我认为我们应该如何做某些事情的看法。 我曾在技术面试的另一端，参与过多个产品发布。 我也开始更多地参与后端，因为这最终是我最喜欢的。
Estimating how long it takes to add features/fix bugs is extremely difficult and it feels like I’m not getting better at it.
估计添加功能/修复错误需要花费多长时间，这非常困难，而且感觉好像我并没有对此有所改善。
I think the most difficult and challenging (yet also fun and rewarding) part of the job is design and architecture. When there is a feature to add, there are a number of ways to do it that instantly pop into my head, but figuring out the best way to do it given the time constraints is very difficult.
我认为工作中最困难和最具挑战性的部分(也是乐趣和收获)是设计和建筑。 当有一个功能要添加时，有很多方法可以立即添加到我的脑海中，但是在有时间限制的情况下，找出最好的方法是非常困难的。
Sometimes certain feature additions require many discussions with many people and other times you just have to make a decision yourself even if you can’t think of a good solution because it isn’t worth the time. Then you look at your code 3 months later like:
有时，某些功能的添加需要与许多人进行多次讨论，而有时您甚至必须自己做一个决定，即使您因为时间不足而无法想到一个好的解决方案。 然后，三个月后，您将看到自己的代码，如下所示：
In this section, I’ve included frequently asked questions that new starters may have.
在本节中，我包含了新手可能会遇到的常见问题。
I have been putting all this effort into learning how to program…How will I know that I will like working as a software engineer?
我一直在努力学习如何编程……我如何知道自己想成为一名软件工程师？
If you like learning to code, then I think you will like working as a software engineer. That doesn’t mean that all software engineering jobs are great, or that you will love them all. Even if you get a great software engineering job, that doesn’t mean that you will always love every aspect of it.
如果您喜欢学习编码，那么我想您会喜欢担任软件工程师。 这并不意味着所有软件工程工作都很棒，或者您会喜欢它们全部。 即使您从事出色的软件工程工作，这也不意味着您将永远喜欢它的每个方面。
But if you like building new things, refactoring ugly code, finally fixing a bug that has been bugging you for awhile, you should be good. If you enjoy the struggle of learning to code, then I think software engineering is for you.
但是，如果您喜欢构建新事物，重构丑陋的代码，最终修复已经困扰您一段时间的错误，那么您应该很好。 如果您喜欢学习编码的过程，那么我认为软件工程适合您。
Even if I get a job, how can I know that I’ll be able to do it and do it well?
即使我找到一份工作，我怎么能知道自己能够做得很好呢？
For some reason, I always thought that there was this massive difference between someone who was getting paid to code and me (someone who was not getting paid to code). So naturally, this question popped into my head a lot.
出于某种原因，我一直认为在获得代码报酬的人与我(没有获得代码报酬的人)之间存在巨大差异。 因此，这个问题自然而然地浮现在我的脑海。
I agree with the cliche advice, “If they hired you, then you are ready to do the job”. I am a firm believer in taking things one step at a time. If you don’t have a job, focus on how to get a job. Once you get a job, then you can focus on doing what you need to do to succeed at that job.
我同意陈词滥调的建议，“如果他们雇用了您，那么您就准备好了。” 我坚信一次迈出一步。 如果您没有工作，请着重于如何找到工作。 一旦找到一份工作，您就可以专注于完成该工作所需要做的事情。
If you are simultaneously worried about getting a job AND your hypothetical performance at the hypothetical job, then you will be adding unnecessary stress and worry to your life.
如果您同时担心获得一份工作以及您在假设的工作中的假设表现，那么您将给生活增加不必要的压力和担忧。
Are there skills to learn that might not help for the interview but would help once you started working?
是否有一些学习技巧可能对面试没有帮助，但是一旦您开始工作就会有所帮助？
I will reiterate and say that my main answer to this question is not to worry about your hypothetical job until it is no longer hypothetical.
我要重申并说，我对这个问题的主要回答是不要再为假设的工作担心，除非它不再是假设的。
However, if you won’t take no for an answer, then I would recommend what I mentioned earlier. Try to work on a project with a team and choose a best practice git workflow.
但是，如果您不会拒绝，那么我建议您前面提到的内容。 尝试与团队一起进行项目，然后选择最佳实践git工作流程。
I’m sure you can find plenty of articles about it if you google “common git workflows”. I don’t have a whole lot of additional advice here other than basic soft skill stuff. Try to get along with your team and everyone in the company from day 1.
如果您使用Google的“常用git工作流程”，我敢肯定您会找到很多关于它的文章。 除了基本的软技能知识外，我这里没有很多其他建议。 从第一天开始，尝试与您的团队和公司中的每个人融洽相处。
What is the main difference between building a project on your own and working on a team at a startup?
自行构建项目与在启动团队工作之间的主要区别是什么？
It really depends on how mature the product is that you are working on. Most of the differences come with working on a big product that will be used by a lot of people. Here are a few things that you may have not thought about when building your side projects versus working on a production level app in a startup:
这实际上取决于您正在开发的产品的成熟程度。 大多数差异来自开发将被许多人使用的大型产品。 在构建辅助项目与在初创公司中使用生产级应用程序时，您可能没有想到以下几点：
Security - Certainly this isn’t something you have to worry about with your own side projects if you don’t want to. When you are working on a product that is used by many people, web security is extremely important. I wrote that explains web security basics such as CSP, HTTPS, CORS, etc.
安全性-当然，如果您不想这样做，则不必为自己的辅助项目担心。 当您使用被许多人使用的产品时，网络安全至关重要。 我写其中介绍了Web安全基础知识，例如CSP，HTTPS，CORS等。
Browser compatibility - You might have to support versions of IE which means you might not be able to use all the fancy latest CSS and might run into some JS problems. With this, comes cross-browser testing which is its own beast.
浏览器兼容性 -您可能必须支持IE版本，这意味着您可能无法使用所有最新CSS，并且可能会遇到一些JS问题。 随之而来的是跨浏览器测试，这是它自己的野兽。
Analytics - You might use something like Google Analytics or Mixpanel to get an understanding of conversion and product usage.
分析 -您可以使用Google Analytics(分析)或Mixpanel之类的工具来了解转化和产品使用情况。
Testing - You certainly don’t have to deal with writing tests in your own projects if you don’t want to. However, testing is essential to writing good code. When learning to code, the longer you wait to start writing tests, the harder it is to make it a habit.
测试 -如果您不想这样做，您当然不必在自己的项目中编写测试。 但是，测试对于编写好的代码至关重要。 在学习编码时，等待开始编写测试的时间越长，养成习惯的难度就越大。
Blockers - You might rely on someone to build something before you can build your feature. So you might have to think about ways to work around this. If you are a frontend engineer and the API isn’t quite ready yet, you might have to make a mock API so that you aren’t blocked from working on the UI.
阻止程序 -您可能需要依靠某人来构建某些东西，然后才能构建您的功能。 因此，您可能必须考虑解决此问题的方法。 如果您是前端工程师，但API尚未准备就绪，则可能必须制作一个模拟API，以免您无法使用UI。
Maintainability - Certainly you want to write good code for your side projects, but the stakes aren’t too high. You probably won’t be maintaining it in a year from now, so who cares if it has no comments and is in one massive file right? When you are on a team, you want a low barrier to contribution. That is, when a new person joins, you want them to be able to read the docs, see the code, and be able to start contributing quickly. If the code is difficult to understand and read, then it will not only take longer for someone to make contributions, but it will also be harder to add features without adding a considerable amount of tech debt.
可维护性 -当然，您希望为辅助项目编写良好的代码，但是风险并不高。 您可能一年后就不会对其进行维护，那么谁在乎它是否没有评论并且保存在一个大文件中呢？ 在团队中时，您希望自己的贡献障碍很小。 也就是说，当一个新人加入时，您希望他们能够阅读文档，查看代码并能够快速开始贡献。 如果该代码难以理解和阅读，那么不仅有人会花费更长的时间做出贡献，而且在不增加大量技术债务的情况下添加功能也将变得更加困难。
As I have said multiple times, I don’t think knowing all of this stuff is important before you get a software engineering job. I do think there is value in knowing about it, whether that is because you don’t know if you will like working as a software engineer, or if you just like knowing what to expect.
正如我多次说过的，我认为在获得软件工程职位之前了解所有这些知识并不重要。 我确实认为了解它是有价值的，这是因为您不知道自己是否愿意担任软件工程师，或者只是想知道期望什么。
Also, unfortunately, there are certain interviewers that will ask you some of this stuff. Maybe because they don’t know any better, maybe because they are hiring for a more senior position. It is my opinion that these things can all be learned on the job if you have a solid foundation.
同样，不幸的是，有些采访者会问你一些问题。 也许是因为他们没有更好的了解，也许是因为他们正在招聘更高的职位。 我认为，只要您有扎实的基础，就可以在工作中学到所有这些东西。
Good luck!
祝好运！
翻译自:
电子工程师自学成才pdf
转载地址：http://abwzd.baihongyu.com/