初级开发人员的缺点
重点 (Top highlight)
重点 (Top highlight)
Junior developers are one of the biggest assets to any software company. After 5–10 years time, these young guys are the ones who decide where the company is heading to in the future. Therefore, turning them into great individual contributors is a win-win for both those developers and the company. Based on my past experiences at work, here’s my advice for you to become a successful 𝐉𝐮𝐧𝐢𝐨𝐫 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫 and have a rocking career ahead! 😎
初级开发人员是任何软件公司的最大资产之一。 经过5-10年的时间，这些年轻人决定了公司未来的发展方向。 因此，将他们变成杰出的个人贡献者对于这些开发人员和公司都是双赢的。 根据我过去的工作经验，为您提供建议，成为一名成功的𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫并拥有令人𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫憬的职业！ 😎
＃1 —了解产品 (#1 — Understand the product)
The best chefs in the world love to make people happy by bringing their taste buds to life. To do that, these chefs must first develop good taste buds themselves and pay attention to every detail of the food end-to-end — from collecting supplies to serving the final dish to the table. If you ever wanted to become great at building software, you must invest the same level of energy on your business too.
世界上最好的厨师都喜欢通过使味蕾栩栩如生来使人们开心。 为此，这些厨师必须首先培养自己的好味蕾，并端到端地注意食物的每个细节-从收集食材到为菜品上桌。 如果您想在构建软件方面变得出色，那么您也必须在业务上投入相同水平的精力。
Business case: All the great developers are well aware of the business problem that their product is intended to address, how it was started as a software project, its target persona, competition, benefits, costs, monetization model, timescales, risks, product roadmap, and literally every bit of information to get the high-level justification for the existence of that project.
业务案例 ：所有出色的开发人员都清楚其产品要解决的业务问题，软件项目的启动方式，目标角色，竞争，收益，成本，货币化模型，时间表，风险，产品路线图，以及从字面上获取的所有信息，以获取该项目存在的高级依据。
High-level architecture, Component diagram, Responsibilities of each component, and Communication flow: Ideally, every developer must be able to draw the diagrams of their product, name its components, briefly explain their responsibilities, communication flows, and thought process behind the important design decisions (e.g. why the team chose React.js over Angular for the frontends).
高级体系结构，组件图，每个组件的职责和通信流程 ：理想情况下，每个开发人员都必须能够 绘制产品图，命名其组件，简要解释其职责，沟通流程以及重要设计决策背后的思考过程 (例如， 为什么团队选择Angular而不是Angular作为React的前端 )。
◼ Since developers are the ground level evangelists of every new feature, without adequate product knowledge, they won’t be able to contribute to granular-level decision making. Finally, as a result, those bad little decisions will affect the end product too.
◼因为 开发人员是每项新功能的基本传播者 ，如果没有足够的产品知识，他们将无法为精细的决策做出贡献。 最后，结果，那些糟糕的小决定也会影响最终产品。
◼ If it’s a very new project, try to involve in the initial project planning meetings with your team (just express your interest to the senior members so they will definitely be generous to reserve a seat for you).
◼如果这是一个非常新的项目，请尝试与您的团队参加最初的项目计划会议(向高级成员表达您的兴趣，这样他们一定会很乐意为您保留席位)。
◼ Not having a business and architectural understanding will limit junior developers for just coding and significantly lower their growth opportunities in other areas. Therefore, learning both the business and high-level design within the first few weeks will definitely be rewarding for a better future.
◼ 没有业务和架构方面的了解将限制初级开发人员仅进行编码，并大大降低他们在其他领域的增长机会 。 因此，在头几周内同时学习业务和高级设计肯定会给美好的未来带来回报。
◼ Software teams usually have their own developer onboarding processes based on their company culture (e.g. sharing developer training tutorials, directing to a product wiki, conducting knowledge transferring sessions etc.). Do not miss those resources and sessions + make sure you study them thoroughly!
◼软件团队通常根据他们的公司文化有自己的开发人员入职流程(例如，共享开发人员培训教程，定向到产品Wiki，进行知识转移会议等)。 不要错过这些资源和会议，并确保您对其进行了彻底的学习！
◼ If the developer onboarding process does not cover the above topics, make sure you get support from your senior colleagues and get all your doubts clarified. Ideally, by the end of your first month, you will be able to give an elevator pitch on your product to your college friends + be confident in writing a full-page technical analysis on your product (including diagrams and brief justifications).
◼如果开发人员的入职过程不涉及上述主题，请确保您得到高级同事的支持，并澄清了所有疑问。 理想情况下，在第一个月末，您将能够向大学朋友介绍产品的电梯信息，并且有信心对产品进行整页的技术分析(包括图表和简要说明) 。
＃2 —了解工具集 (#2 — Understand the toolset)
Every world-class musician has his own hand-picked instruments fine-tuned for the best performance. When his instruments go out of the tune, he knows how to quickly fix them and get back to his usual rhythm, even on stage, in front of a huge audience. That’s the level of spirit you must develop with your technology toolset over time. Like musical instruments becoming a part of their body for musicians over time, you must have the same sensitivity towards the technologies and tools you use.
每个世界级的音乐家都有自己精心挑选的乐器，以达到最佳演奏效果。 当他的乐器不合时宜时，他知道如何快速修复它们，并在众多观众面前，甚至在舞台上，回到他通常的节奏。 随着时间的推移，这就是您必须使用技术工具集开发的精神水平。 就像乐器随着时间的流逝成为音乐家身体的一部分一样，您必须对使用的技术和工具具有相同的敏感性。
Know your technologies: Make sure you get a high-level understanding of all the product components + master the programming languages, frameworks, and developer tools that you will be assigned in the near future. The rule of thumb is, before starting the development, always follow some online courses to refresh your fundamentals and over time dive into the depth of your frequently-used technologies.
了解您的技术 ：确保您对所有产品组件都有全面的了解，并且熟练掌握 编程语言，框架和开发人员工具 您将在不久的将来被分配。 经验法则是，在开始开发之前，请务必遵循一些在线课程来 刷新您的基础知识 和 随着时间的流逝深入 您常用的技术。
Set up your laptop for serious development: A properly set-up laptop will save a lot of time and pains for you. This process includes setting up language & frameworks, build tools, package managers, IDEs, SSH clients, database drivers, time-saving shortcuts, custom scripts, and many more. For a detailed breakdown, you can check the below blog post of mine.
设置笔记本电脑以进行认真的开发 ：正确设置笔记本电脑将为您节省很多时间和痛苦。 此过程包括设置语言和框架，构建工具，程序包管理器，IDE，SSH客户端，数据库驱动程序，节省时间的快捷方式，自定义脚本等。 有关详细的细分，您可以查看下面的我的博客文章 。
＃3 —了解一些DevOps (#3 — Understand some DevOps)
If you are not a full-stack developer (e.g. say you’re a frontend developer), you may definitely be uncomfortable with this idea. However, knowing how to build your code and deploy will be a great value-addition (so that you can demonstrate it to colleagues, or even the client). When you become self-sufficient with both development and DevOps tasks, you can have control over the end-to-end delivery of your code and can be great assistance to the DevOps lead in your team too.
如果您不是全栈开发人员(例如，说您是前端开发人员)，那么您肯定会对这种想法感到不舒服。 但是，知道如何构建和部署代码将是一个巨大的附加值(以便您可以向同事甚至客户进行演示)。 当您完成开发和DevOps任务的自给自足时，就可以控制代码的端到端交付 并可以为您团队中的DevOps主管提供很大的帮助。
Test your component locally: I always have trust issues with developers who come up with the excuses like “I don’t know how to run this locally” or “I have no way to test this locally because X system is unreachable”. Ideally, at a very minimum, you must write unit tests and component tests (mock the external system’s behaviour if necessary) and be confident that all your code works before integrating with the main system.
在本地测试您的组件 ：开发人员总是会遇到诸如“ 我不知道如何在本地运行 ”或“ 由于X系统无法访问而无法在本地测试 ” 这样的借口的开发人员之间的信任问题。 理想情况下，至少 编写单元测试和组件测试 (如有必要，请模拟外部系统的行为)，并确保所有代码在与主系统集成之前都能正常工作。
Study your build scripts and learn to run CI pipelines: Most companies have home-grown CI/CD procedures, but their underlying concepts are not so different. For instance, if we consider a single component, its build steps may include, setting up the environment and build parameters, fresh installing the pre-defined package versions, compiling the code, running the unit tests, building the final binaries, moving them to a deployment environment, and integrating with the main system. Every time you make a change locally and push to a central code repository, understand that your code goes through this whole process. You can confirm it by checking build scripts and CI pipeline logs too. Once you understand this flow, you can spot bugs and unexpected behaviours easily, before even your DevOps or QA engineers find out.
研究您的构建脚本并学习运行CI管道 ：大多数公司都有自己开发的CI / CD程序，但是它们的基本概念并没有什么不同。 例如，如果我们考虑一个组件，则其构建步骤可能包括设置环境和构建参数，重新安装预定义的软件包版本，编译代码，运行单元测试，构建最终的二进制文件，将它们移至部署环境，并与主系统集成。 每次在本地进行更改并推送到中央代码存储库时，请了解您的代码会经过整个过程。 您也可以通过检查构建脚本和CI管道日志来确认它。 一旦了解了这种流程，您甚至可以在DevOps或QA工程师发现之前轻松发现错误和意外行为。
Manually deploy a product release to a remote environment: This is a very advanced expectation, but not so difficult to achieve if you are a full-stack developer. First, seek your DevOps lead’s support and he will show you how to do a full release manually + support you if you run into any issue. Being able to do a manual product release will definitely make you a great resource to your team and you probably will receive opportunities to visit on-site and even join application support engineers.
手动将产品发行版部署到远程环境 ：这是一个非常高级的期望，但是如果您是一个全栈开发人员，那么实现起来并不是那么困难。 首先，请寻求您的DevOps主管的支持，他将向您展示如何手动发布完整版本，并在遇到任何问题时为您提供支持。 能够进行手动产品发布肯定会让您成为团队的宝贵资源 你可能会 获得机会访问现场，甚至加入应用程序支持工程师 。
◼ In a world where ~70% of the organizations are now using the cloud (source: Gartner) and software engineers spend nearly 50% of their total time on integrations, not knowing the fundamentals of DevOps can be a very expensive risk to take. By learning those lessons right at the beginning of your career will transform you into a better developer while making you an attractive hire for new opportunities in the future.
◼ 在当今约有70％的组织正在使用云的世界中(来源： 加特纳 )，并且软件工程师将其总时间的近50％用于集成，因为他们不了解DevOps的基础知识可能会承担非常昂贵的风险。 通过在职业生涯初期学习这些课程，可以将您转变为更好的开发人员，同时使您成为将来获得新机遇的诱人职位。
＃4 —像技术员一样在线搜索和学习 (#4 — Search & learn online like a techie)
Developers highly depend on online knowledge sources like software docs, how-to guides, tech blogs, dev forums, issue trackers, video courses, and many more. Being a power user who understands how to make use of those online platforms and advanced features will help you increase your productivity and have access to all the latest knowledge available out there.
开发人员高度依赖在线知识资源，例如软件文档，操作指南，技术博客，开发者论坛，问题跟踪器，视频课程等。 成为了解如何利用这些在线平台和高级功能的高级用户，将帮助您 提高生产力 并可以访问所有可用的最新知识 。
Be curious and maintain a learning mindset: Curiosity is the key to innovation and it will turn you into a great problem-solver. As professionals, you must maintain a learning mindset and keep your knowledge and skills up-to-date with rapidly-changing technology trends.
保持好奇心并保持学习心态 ：好奇心是创新的关键，它将使您成为一个解决问题的好人。 作为专业人员，您必须保持学习心态， 使您的知识和技能保持最新 技术趋势日新月异。
Search using correct keywords, phrases, filters: If you google something, be specific in your search query. (e.g. If your Javascript app gives you an NPM integrity error when installing NPM packages, instead of using a vague query like “npm install not working”, just copy the full error message and search with double-quotation marks like "
npm ERR! code EINTEGRITY" "integrity checksum failed when using sha512" "but got sha512"). This helps your search engine to find exact matches to your query and significantly increases the chances of getting it right at the first few results. Also, make sure you mention the tool/technology at the beginning of the search query (e.g. “java read multi-dimensional array” is a better search query than “how to read a multi-dimensional array using Java”). When you search on an old or unpopular topic, make sure you use the search settings and filter the results by the date and find the latest resources.使用正确的关键字，词组，过滤器进行搜索 ：如果您用Google搜索， 具体在您的搜索查询中。 (例如，如果您的Javascript应用在安装NPM软件包时给您NPM完整性错误，而不是使用诸如“ npm install not working”之类的模糊查询，只需复制完整的错误消息并使用“
npm ERR! code EINTEGRITY" "integrity checksum failed when using sha512" "but got sha512")双引号进行搜索npm ERR! code EINTEGRITY" "integrity checksum failed when using sha512" "but got sha512")。 这可以帮助您的搜索引擎找到与查询完全匹配的内容，并大大增加了在前几个结果中正确进行查询的机会。 另外，请确保在搜索查询的开头提到工具/技术(例如，“ java读取多维数组”比“如何使用Java读取多维数组”更好)。 当您搜索旧主题或不受欢迎的主题时，请确保使用搜索设置和 按日期过滤结果并找到最新资源 。Prioritize trusted sources: When you search an error message or a how-to guide, make sure you prioritize results coming from trusted sources. For instance, always read the StackOverflow and GitHub threads first and if you can’t find a proper answer there, go to the blog posts, tech forums, and other search results.
优先考虑可信赖的来源 ：搜索错误消息或操作指南时，请确保优先考虑可信赖来源的结果。 例如，总是 首先阅读StackOverflow和GitHub线程 如果您在此处找不到合适的答案，请转至博客文章，技术论坛和其他搜索结果。
◼ There was a time that software engineering meant studying a great set of books on a few technologies, becoming an expert at them, and boom! You could build a great software product. But now things have become much more complex and a single product involves a large variety of technologies and mastering each and every area would take a lot of time and effort, hence ineffective and impractical. Therefore, always master your fundamentals, learn the primarily-using technologies, and make up your mind flexible enough to explore what comes along the way. There’s no shame in Googling. In fact, finding something confidently online is a very useful skill today!
◼曾经有一段时间，软件工程意味着学习大量有关几种技术的书籍，成为这些领域的专家，然后蒸蒸日上！ 您可以构建出色的软件产品。 但是现在事情变得更加复杂，并且一个产品涉及多种技术，并且掌握每个领域都将花费大量时间和精力，因此无效且不切实际。 因此， 始终掌握您的基础知识，学习主要使用的技术，并下定决心足够灵活地探索前进的道路 。 在谷歌搜索中不丢人。 实际上，如今在网上自信地找到东西是一项非常有用的技能！
＃5 —简短而甜蜜地沟通 (#5 — Communicate short & sweetly)
All the best architects that I have met in my life are great communicators too. They are very comfortable at handling their ideas and the language around technical topics, people matters, and general discussions. You should master that art too.
我一生中遇到的所有最好的建筑师都是伟大的传播者。 他们非常乐于处理他们的想法以及围绕技术主题，人员问题和一般性讨论的语言。 您也应该掌握这种艺术。
Learn the names and superpowers of your teammates: Ideally, you must know everyone in your team by their name, assigned job role, and areas of expertise. When you have that information, you will know whom to consult when you need support. Also, it would be great if you can become a go-to-person in some area and make it your superpower so that you also can give back to the team.
了解队友的姓名和超级能力 ：理想情况下，您必须了解团队中的每个人的姓名，分配的工作角色和专业领域。 获得这些信息后，您将在需要支持时知道向谁咨询。 另外，如果可以的话 成为某个领域的专家，并使其成为您的超级大国 这样您还可以回馈团队。
Pay attention to details: Insetivity to small details is an expensive mistake that most developers make in the early days of their careers. For instance, when taking requirements from a BA or getting technical instructions from your supervisors, make sure you actively listen, clarify doubts, and even take notes on small details, so that you won’t forget them later. Paying attention to details, reiterating the story as you understood, and getting the confirmation to it at the end will help you significantly reduce the rework efforts too.
注意细节 ：对微小细节的僵化是大多数开发人员在职业生涯初期犯下的代价高昂的错误。 例如，当从广管局获得要求或从主管那里获得技术指导时，请确保您 积极倾听 ， 澄清疑问 ， 乃至 做笔记 小细节，这样您以后就不会忘记它们。 注意细节 重复您所理解的故事 ，最后得到确认将对您有很大帮助 减少返工 太。
Short and clear communication is preferred: There’s absolutely no need to write lengthy paragraphs in your daily emails, Slack messages, or even JIRA comments. If you respect the time of your colleagues, please be very specific and use the minimum number of words in communication. Also, one-liners, listed items, abbreviations, bolding, underlining, highlighting, and various such formatting are a great way to convey your message without wasting your colleagues’ time.
简短而清晰的交流是首选 ：绝对不需要在日常电子邮件，Slack消息甚至JIRA评论中写冗长的段落。 如果您尊重同事的时间，请非常具体，并在交流中使用最少的单词。 同样，单行，列出的项目，缩写词，粗体，下划线，突出显示以及各种此类格式也是一种在不浪费同事时间的情况下传达您的信息的好方法。
Go visual: If you want to explain a complex topic or conditional workflow, just draw it in a white paper or a whiteboard, take a photo and attach to your message. If you need to add notes, put a number on the drawing and explain later. If it’s supposed to share with outside readers, use a professional diagramming tool like diagrams.net.
视觉化 ：如果您想解释一个复杂的主题或有条件的工作流程，只需 画在白板纸或白板上，拍照并附加到您的留言上 。 如果需要添加注释，请在图形上添加数字，并在以后进行说明。 如果应该与外部读者共享，请使用诸如diagrams.net之类的专业图表工具。
＃6 —策略性地寻求帮助 (#6 — Ask for help strategically)
Junior developers are always blessed with the support and guidance of everyone in the team. But you should never take it for granted. Ideally, when you seek support, always plan it and apply some mannerism while respecting everyone’s time and intentions to support.
初级开发人员总是很高兴得到团队中每个人的支持和指导。 但是，您永远不应将其视为理所当然。 理想情况下，当您寻求支持时，请务必计划好它并运用一些举止态度，同时尊重每个人的时间和支持意愿。
In-written vs. verbal: If it’s not an urgent matter, make sure you drop a message or email before visiting the cubicle of your colleagues. Most importantly, before mentioning your requirements, be polite and inquire whether it is a good time to talk to him and if he accepts, say you need support to get the X task done. When it’s an urgent need, first mention that it’s urgent because, without that information, he may choose to respond at leisure and things will go south by the time you guys get together.
书面还是口头 ：如果不是紧急情况，请确保在访问同事隔间之前放下消息或电子邮件。 最重要的是，在提及您的要求之前，要礼貌和 询问是否是聊天的好时机 对他，如果他接受，说您需要支持才能完成X任务。 当有紧急需求时，首先要提到它是紧急的 因为如果没有这些信息，他可能会选择在闲暇时做出回应，而当你们在一起时，事情就会变得漫无目的。
Find a convenient time: Some developers prefer to do the most important tasks in the morning and keep the afternoon time for exploring stuff and meetings. Some prefer the opposite of it. Understand your colleagues’ preferences and follow them. If it’s something that takes a lot of time, divide it into subtasks and reach him only when you run into issues.
找一个方便的时间 ：一些开发人员更喜欢在早上执行最重要的任务，而在下午保留一些时间来探索事物和会议。 有些人则相反。 了解同事的偏好并关注 他们。 如果要花很多时间 将其分为子任务 并在遇到问题时与他联系。
Get some directions and try out on your own: If you don’t understand how to achieve a task, go ask for directions for it first. For instance, if you’re assigned to connect your product backend to a database, your colleagues will instruct you to first install a database client library, then make a connection to the database, and finally test the database operations. This will involve you installing database drivers, creating separate database user roles for access, setting up some network configs, and writing tests to check the database connection and operations, which normally will take some time. Therefore, based on the instructions you received, complete those tasks beforehand, and only if you still run into issues, bring your laptop to your colleagues, and seek support. The biggest advantage of this approach is, by the time, you seek support, you already have spent some solid hours burying your head into the issue and reading many resources online, which would be a great learning experience for you. Also, you can easily answer the questions asked by your colleagues and even share your initial experiences and opinions, which will help them to dig deeper into the issue.
获取一些指导，然后自己尝试 ：如果您不了解如何完成任务，请先询问其指导。 例如，如果您被分配将您的产品后端连接到数据库，则您的同事将指示您首先安装数据库客户端库，然后建立与数据库的连接，最后测试数据库操作。 这将涉及到您安装数据库驱动程序，创建单独的数据库用户角色进行访问，设置一些网络配置以及编写测试以检查数据库连接和操作，这通常需要一些时间。 因此， 根据收到的说明，事先完成这些任务 ，并且只有在您仍然遇到问题时，才将笔记本电脑带给同事并寻求支持。 这种方法的最大优点是， 到那时，当您寻求支持时，您已经花了一些时间将精力投入到该问题中，并在线阅读了许多资源，这对您来说将是一个很好的学习体验。 此外，您可以轻松地回答同事提出的问题，甚至分享您的初步经验和观点，这将有助于他们更深入地研究问题。
Code reviews are your friend: Senior developers can only spend a limited time on helping you and it is not practical for them to spoonfeed everything to junior developers from scratch. But once you get something working and demonstratable, they can easily review your progress and share better feedback with you. By doing that, you have already proved that you are capable of doing something and that attitude is tested by most senior developers when interacting with you.
代码审查是您的朋友 ：高级开发人员只能在有限的时间里为您提供帮助，而他们将所有内容从头开始馈给初级开发人员也不切实际。 但 一旦您的工作可行且可以证明，他们可以轻松地查看您的进度并分享更好的反馈 和你。 通过这样做，您已经证明自己有能力做某事，并且大多数高级开发人员在与您进行交互时都测试了这种态度。
Request support and time as the last resort: When you’re stuck at something, take advice from your supervisors and express the need for spending some extended hours. In general, senior engineers and supervisors are very understanding of these situations and will suggest you better options and even buy some extra time, guidance, and senior resources for you to do the needful and complete the task.
寻求支持和时间是万不得已的方法 ：当您遇到困难时，请听取主管的建议， 表示需要花费一些时间 。 通常，高级工程师和主管对这些情况非常了解，会为您提供更好的选择，甚至会花一些额外的时间，指导和高级资源来帮助您完成有需要的任务。
＃7-报告有关上下文的问题 (#7 — Report issues with context)
Not including the context when reporting issues is a huge turnoff for most developers. If you ever report an issue to a developer, make sure you collect the required information to build an adequate context and organize your findings constructively. A good issue report (or ticket in the agile world) will usually include the steps to recreate (if it’s a one-time issue, explain what you were doing at that time), release versions, timestamps, environment details, logs extracted, screenshots, etc. For instance, if a button is not working or login functionality seems broke, take screenshots capturing the full-screen including the web UI, browser console, network tabs, complete URL, time, and date shown in your taskbar, etc. If it’s a backend application, take the application logs without losing the timestamp and other relevant information. These little generous acts will greatly help the component developers to easily understand the root cause, most of the time by just looking at it.
对于大多数开发人员来说，报告问题时不包括上下文是一个很大的障碍。 如果您曾经向开发人员报告问题，请确保您收集了必要的信息以建立适当的环境并建设性地组织您的发现。 一个好的问题报告(或敏捷世界中的问题单)通常将包括重新创建的步骤(如果是一次性问题，请说明您当时的行为)，发行版本，时间戳，环境详细信息，提取的日志，屏幕截图等 例如，如果某个按钮不起作用或登录功能似乎中断， 截取全屏截图 包括Web UI，浏览器控制台，网络标签，任务栏中显示的完整URL，时间和日期等。如果是后端应用程序， 获取应用程序日志而不会丢失时间戳 和其他相关信息。 这些小小的慷慨的举动将极大地帮助组件开发人员轻松地了解根本原因，而在大多数情况下，只需查看一下根本原因即可。
＃8-记录您的学习 (#8 — Document your learnings)
Make notes: You can search for things online or seek your colleagues’ support for many times as you want. But that is not practical and over time it will leave a bad outlook on you in the team. Therefore, always take notes on new things you learn and the frequent commands you use. I personally recommend you maintaining a private Git repository and keep your notes in markdown language, but alternatively, you can use tools like Evernote or any note-taking apps too. The benefit of a Git repo is, you can keep track of history and if you accidentally delete a line, your IDE will suddenly highlight it and show you the diff too.
做笔记 ：您可以根据需要在网上搜索内容或寻求同事的支持。 但这是不切实际的，随着时间的流逝，团队中的前景将会变差。 因此，总是 记下您学到的新知识和常用命令 。 我个人建议您维护一个私有的Git存储库，并以markdown语言保存笔记，但是，您也可以使用Evernote之类的工具或任何笔记应用程序。 Git仓库的好处是，您可以跟踪历史记录，如果不小心删除了一行，IDE也会突然突出显示它并向您显示差异。
Record experiment results, present them constructively & drive your decisions by data and visuals: Senior developers and managers love analyzing data and visuals that help them understand deep insights. It’s a great way for you to be objective when discussing complex and subjective topics. For instance, if you do a tool comparison, rather than merely saying that X is better than Y, you must be able to do some experiments, bring some data into the table, and build a strong judgment, just like any other professional would do. Here’re such attempts of mine some years back when I was an intern.
记录实验结果，以建设性的方式展示它们并通过数据和视觉效果做出决策 ：高级开发人员和管理人员喜欢分析数据和视觉效果，以帮助他们理解深刻的见解。 这是您的绝佳方式 在讨论复杂和主观的话题时要客观 。 例如，如果您进行工具比较，而不仅仅是说X优于Y，那么您必须能够 做一些实验，将一些数据带入表中，并做出有力的判断 ，就像其他专业人员一样。 这是几年前我当实习生时的尝试。
＃9 —对工作中的事件没有精神React (#9 — No mental reactions to events at work)
While it is true that you love your job and your company values your loyalty and contribution in return, it does not mean that you have to have a reaction to every event at work. In fact, having mental reactions to events at work is one of the unhealthiest practices and an easy way to get stressed or burnt out. Therefore, you must definitely get rid of it soon and learn to maintain a calm mindset from the early days of your career.
虽然您热爱自己的工作，并且公司重视您的忠诚和贡献，这确实是回报，但这并不意味着您必须对工作中的每个事件都做出React。 实际上，对工作中的事件产生精神React是最不健康的做法之一，也是缓解压力或倦怠的一种简便方法。 因此，您一定要尽快摆脱它，并学会 保持冷静的心态 从您职业生涯的早期开始。
Do not get fearful or panic: Experiencing fear or panic towards new challenges is totally fine, and it makes you very human. But you don’t have to be like that. When your supervisor or senior engineers assign you a task, they must have already calculated the risks involved in it and even have a Plan B on the back of their mind (just in case if you screw things up along the way). When you have a challenging task, just clear out your mind and do what you are supposed to do. If you are unsure of something, always seek support and approval to go ahead.
不要感到恐惧或惊慌 ：对新挑战感到恐惧或惊慌完全可以，这会让您非常人性化。 但是您不必那样。 当您的主管或高级工程师为您分配任务时，他们必须已经计算出了其中的风险，甚至还计划B计划(以防万一，您一路搞砸了) 。 当您完成一项具有挑战性的任务时，只需清除您的思想并做应该做的事情。 如果不确定某件事，请始终寻求支持和批准以继续前进。
Pro Tip: If you do something risky (e.g. database config change), always take backups, draft the steps and commands you are planning to use, share it with your colleagues, get their approval, and finally execute them. In that way, you position your work in a very safe position and everyone will come forward to help you.
专家提示：如果您冒险(例如更改数据库配置)， 始终备份，草拟要使用的步骤和命令，与同事共享，获得他们的批准， 最后执行它们。 这样，您就可以将工作定位在非常安全的位置，每个人都将为您提供帮助。
Do not become over-thankful: The lengthy thank you emails and messages are the worst of all. In fact, most seasoned developers do not even expect thank-you emails. The rule of thumb is, if someone goes beyond his job to help you, then give them some nice appreciation or a shout-out. In other cases, just be nice and thank them in a one-liner and move on with your work. However, if you ever get a chance to help them back, never miss such opportunities.
不要过度感谢 ：冗长的感谢电子邮件和消息是最糟糕的。 实际上，大多数经验丰富的开发人员甚至都不会收到感谢邮件。 经验法则是，如果某人超出工作范围来帮助您，则给他们一些赞赏或大喊大叫。 在其他情况下，请保持友善，并以单行的形式感谢他们，然后继续您的工作。 但是，如果您有机会帮助他们，请不要错过这样的机会。
Never make things personal: People have different viewpoints and sometimes based on their exposure, they may take different approaches to work that can lead to even chaos. In such scenarios, instead of quickly responding or taking it personally, be fully open for criticism or the heated arguments and listen to every fact very carefully. In such scenarios, making things personal won’t do any good to you. The nicest way to handle such things would be to put your ego aside, let the time calm things down, be honest to you, and do what it takes to make the greater good win in the best interest of everyone. If you are not sure what to do, seek the advice of your mentor or colleagues too.
永远不要让事情变得私密 ：人们有不同的观点，有时根据他们的接触程度，他们可能会采取不同的工作方式，甚至可能导致混乱。 在这种情况下， 而不是Swift做出回应或将其视为个人观点，而应完全公开接受批评或激烈的辩论，并非常认真地倾听每个事实。 。 在这种情况下，将事情变成个人化不会对您有任何好处。 处理此类问题的最好方法是 抛开自我，让时间平静下来，对您诚实，并尽最大努力争取每个人的最大利益 。 如果您不确定该怎么做， 向您的导师咨询 还是同事。
Be open-minded: You must be ready to listen to your teammates and adjust your initial opinions when you uncover new details. If you think your idea must precede, justify it constructively to your team and be thankful for everyone who shared their insights and motivated you by all means.
胸襟开阔 ：您必须准备好倾听您的队友和 发现新细节时调整您的初步意见 。 如果您认为自己的想法必须先行，请为您的团队建设性地提出正当理由，并感谢所有分享见解并以各种方式激励您的人。
＃10 —尽可能帮助所有人 (#10 — Help everyone, whenever possible)
The USA’s highest-performing military organization — Navy SEALs aren’t made up of the strongest, toughest, or smartest candidates. According to Simon Sinek, those who make it through the selection process of Navy SEALs are the ones who can find the energy to help the person next to them, even when they are completely exhausted. The best software teams maintain that same spirit.
美国表现最佳的军事组织-海军海豹突击队不是由最强大，最强悍或最聪明的候选人组成。 根据西蒙·西内克 ( Simon Sinek)的说法，那些通过海军海豹突击队的甄选过程做到这一点的人，即使在筋疲力尽的情况下，也能找到帮助旁人的能量。 最好的软件团队保持同样的精神。
Be the first one to offer help: Not everyone is comfortable at asking help. But if you notice someone struggling, instead of looking away, offer your help and see whether you can make their life easy. It’s a great way to give back to the community and it will make you a great human being too.
成为第一个提供帮助的人 ：并不是每个人都愿意寻求帮助。 但是如果您发现有人在挣扎， 而不是移开视线，提供您的帮助 看看是否可以使他们的生活变得轻松。 这是一个很棒的方法 回馈社会 它也会使你成为一个伟大的人。
Don’t promise what you can’t deliver: If it’s certain that you don’t have what it takes to get a job done or simply you cannot meet the deadlines, be open about it and express your progress. By doing that, you are helping your project managers and supervisors to better organize the team resources, release schedules, and many such timelines.
不要承诺您无法交付的东西 ：如果可以确定您没有完成工作所需要的东西，或者根本无法按时完成任务，请公开表示自己的进展。 这样，您可以帮助您的项目经理和主管更好地组织团队资源，发布时间表以及许多此类时间表。
If you don’t know it, but still want to help, clearly mention it: Sometimes you may come forward to make your colleague’s life easy or save his time by helping. However, if such attempts involve risk or you are a complete newbie in that area, clearly mention it. Even though your intention is to help, sometimes things can go south.
如果您不了解它，但仍然希望获得帮助，请明确指出 ：有时您可能会挺身而出，让同事的生活变得轻松或通过帮助节省他的时间。 但是，如果这样的尝试涉及风险，或者您是该领域的新手，请明确提及。 即使您打算提供帮助，有时情况也会有所发展。
If you mess things up, be open about it: Once you’ve accepted your flaws, no one can use them against you again. Therefore, if you make a mistake, instead of hiding it from the team, share all the information and steps you followed with your colleagues and help them to help you.
如果您搞砸了，请公开一下 ： 一旦您接受了自己的缺点，没有人可以再次使用它们来对付您。 因此，如果您犯了一个错误，不要将其隐藏在团队中，而应与同事共享您所遵循的所有信息和步骤，并帮助他们为您提供帮助。
Work for free: During the early days of your career, working for free is a great way to gain more experience and build a portfolio and story under your name. In the beginning, you can reach out to your teammates and ask for some quick work, or else find where your managers and teammates spend the most time and try to help them progress fast letting them focus on more serious issues. Once you help everyone often, it would open up many opportunities for your growth too.
免费工作 ：在职业生涯的早期， 免费工作是获得更多经验并以您的名字建立作品集和故事的好方法。 一开始，您可以 与您的队友联系并要求快速工作 ， 要不然 找到您的经理和队友在哪里花费最多的时间，并尝试帮助他们快速进步，让他们专注于更严重的问题 。 一旦您经常为每个人提供帮助，它也会为您的成长打开很多机会。
Make it a learning opportunity: Always consider this process as a learning experience, not a mere job. Statistically speaking, having enough failures or hardships will prepare you for a nearer success always. Therefore without getting demotivated by short-term events at work, focus on your long-term career goals, make everything a lesson to your life, and stay positive.
使其成为学习机会 ：始终将这一过程视为学习经历，而不是单纯的工作。 从统计学上讲，拥有足够的失败或困苦总是会为您取得更接近的成功做好准备。 因此，不要因工作中的短期事件而灰心，专注于您的长期职业目标，使一切成为生活的教训，并保持积极向上。
结论 (Conclusion)
If you completed reading all the above suggestions, it’s time to take action on them too. I hope you will enjoy your time as a junior software developer and always share your experiences with the community when you grow in your career (trust me, it’s really satisfying). Wishing you the best of luck for a great future ahead! 👨💻👩💻
如果您已阅读完上述所有建议，那么也该对它们采取行动了。 我希望您会喜欢在初级软件开发人员中度过的时光，并在您的职业发展过程中始终与社区分享您的经验(相信我，这真的很令人满意)。 祝您好运，祝未来美好！ 👨💻👩💻
初级开发人员的缺点
806
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
