• 开源镜像
  • 开源沙龙
  • 媛宝
  • 猿帅
  • 注册
  • 登录
  • 息壤开源生活方式平台
  • 加入我们

开源日报

  • 开源日报第571期:《接受挑战 JavaScript30》

    7 10 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《接受挑战 JavaScript30》
    今日推荐英文原文:《Programmers: Make Yourself Replaceable》

    今日推荐开源项目:《接受挑战 JavaScript30》传送门:GitHub链接
    推荐理由:国庆要结束啦,准备好接着回到爆肝的日子中了吗?如果不知道回到日常的工作学习中要干点啥来填充自由活动时间的话,这个项目就是个好主意。这个项目是用纯粹的 JS 来实现一些玩意儿的挑战,借助这些挑战来达到学习框架背后知识的目的。有工具用自然不是坏事,但是这样一些知识就被工具所掩盖了起来,将这些被掩盖的知识重新发掘出来,就是这个项目希望倡导的。
    今日推荐英文原文:《Programmers: Make Yourself Replaceable》作者:Malcolm Laing
    原文链接:https://medium.com/better-programming/programmers-make-yourself-replaceable-1b08a94bf5
    推荐理由:让你的技能等级在世界上所有人中难以替代——而不是只在公司里

    Programmers: Make Yourself Replaceable

    Why making yourself replaceable will lead to a better career

    My first internship after studying computer science at college was a disaster. They didn’t use any form of version control. We had no local development environments — we all ran our code on the same staging server. If one person crashed the app, it would crash it for everyone. The application was an undocumented spaghetti code disaster.

    There was only one person able to work with this application. They were irreplaceable — without them, nothing would get done. Tasks that would take the rest of us days took them hours.

    Here are some of the factors that made them irreplaceable:
    • The undocumented framework made it difficult to onboard new team members.
    • Having no local development environment made people work less effectively.
    • Not using version control made it easier to introduce bugs and made code reviews impossible.
    • Information hoarding led to large knowledge silos.
    But why is this a bad thing? Shouldn’t we strive to be indispensable? Seth Godin wrote the bestselling book “Linchpin: Are You Indispensable?” In it, he argues that Linchpins, or indispensable people, are the backbone of the workforce. He compels you to hoard knowledge and relationships to make yourself irreplaceable.

    This is something that we have heard our entire lives. People joke about how we should make code so obscure that only we can understand it, to ensure job stability. Why would you want to be replaced?

    Why You Don’t Want to Be Irreplaceable

    1. Your skills become less marketable

    If you spend years working with an obscure codebase, your skills become less relevant. You aren’t working with popular open-source frameworks. You might even work with a programming language that’s becoming less and less popular.

    Companies want to hire people who have relevant experience. Experience developing features in a homemade framework isn’t relevant. Why hire someone who has only worked with jQuery, when I can hire someone who has two years of React experience?

    Working with the same tools as potential employers increases your marketability.

    2. Your work relationships will sour

    Maintaining good relationships with your colleagues is hard when you hoard information. An irreplaceable programmer will often bend or break the rules that others follow. They often see themselves as above their colleagues. They are often difficult to work with and only want to do things their way. They won’t listen to feedback.

    To go back to the example from my former internship, the programmer in question saw himself as above the rest of us. He would show up late and leave early. When you asked him for help, he would prefer to code for you instead of explaining his solution. He was terrible at onboarding new teammates.

    Management noticed but chose to look the other way because of how vital he was to the organization. The rest of us felt like second-class employees, and morale suffered.

    Instead of hoarding information, share it. Instead of coding for your teammates, pair-program. Instead of making up your own rules, follow them. This will make you more liked. It will allow you to not only teach your coworkers but learn from them.

    3. It makes it harder to step away

    If you have made yourself irreplaceable, then it’s hard to take sick days and vacations. If you don’t share knowledge about your part of the application, then nobody can help you. If there’s a problem, then you will be stuck fixing it. And if you aren’t available when disaster strikes, then the blame will fall on your shoulders.

    4. It stops your career growth

    If you are irreplaceable in your current position, why would your boss ever give you a promotion?

    Let’s go for a more concrete example. John has worked for ten years at the same company as a PHP engineer. When John started at the company, they had one product. It was a poorly documented monolith that was very difficult to work with. John worked hard and made himself an expert in working with the monolith.

    Over the past ten years, the company evolved and created new and exciting products. They started using more modern technologies and frameworks.

    John’s coworkers got the opportunity to work with those more modern products, but not John. John’s supervisor knew he would be difficult to replace if they moved him off his project.

    Some of John’s coworkers got promoted, others left the company for new jobs at higher pay. But John stayed behind. When he finally starting looking for a new job, he found it hard. In the last ten years, the industry had evolved. It had left him behind.

    5. Believing you are irreplaceable gives you a false sense of security

    We work hardest when we are working for something. If we know we are irreplaceable, we tend to become complacent. We start taking longer lunches. Arriving later, and leaving earlier.

    Even if you are irreplaceable, there are many ways you can still lose your job. What if the company goes bankrupt? Or the product you are working on loses market share? Or if your company decides to outsource its development to a low-cost area?

    Face it, there’s no such thing as true job security. Instead of investing in your job, you should invest in yourself. Develop your interpersonal skills by working together with your colleagues. Learn new skills and work with market-leading technology.

    Prepare yourself, and when you do lose your job, you will have no trouble finding a new one.

    How To Make Yourself Replaceable

    1. Practice inner source

    Use best practices from open source in your closed-source software. Try the following:
    • Write a README file with examples and explanations.
    • Add a CONTRIBUTING file with information about conventions and a code style guide.
    • Create a pull request template to make it easier for teammates to contribute.
    • Set up a strong CI pipeline. Make sure your tests and linters run on every pull request.
    • Use a code formatter like prettier to stop nitpicking about formatting.

    2. Share your knowledge and learn together

    When you finish working on a feature, share what you learned. Set up lunch-and-learns and outline the problems you faced coming to your solution. Encourage your teammates to do the same. Create a Slack channel where people can post and discuss blog posts. When starting new projects, push to use new and different technologies.

    Leave comments throughout your pull requests explaining why you made these changes. This makes it a lot easier for your reviewers to understand where you are coming from and why you made these changes. If you are having lots of back and forth over a pull request, call them up. Go through your changes together

    3. Share the keys to the castle

    Don’t let only one or two team members have access to the production environment. Encourage everyone to take responsibility. Rotate developer on-call responsibilities. Teach new team members how to use application-monitoring and error-tracking tools. Make everyone on the team a stakeholder.

    It’s demoralizing when only one or two people are trusted with access to production. It also leads to people thinking why should they care about production issues if they aren’t trusted to fix them? Empowering your team to make fixes on production will lead them to feel more responsible.

    4. Never stop learning

    Introduce new tools and new practices to your workflow. Learn new technologies and frameworks. Identify pain points, and come up with solutions.

    At my current position, I noticed that we would often introduce visual regressions. When making pull requests, it was difficult to check every component to see if they had changed. Testing manually took time and was prone to errors. Designers would get upset when these visual regressions made it to production.

    So I did some research on different types of visual testing. I introduced visual regression testing. Now this testing setup makes it harder to break our component library.

    It also makes me more replaceable — these tests make it easier for other developers to work with my code.

    Making yourself replaceable makes it easier to take time off. It can help you develop better relationships with your colleagues. It makes you more attractive on the job market and even opens you up to promotions.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第570期:《家国梦 JiaGuoMengCalculator》

    6 10 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《家国梦 JiaGuoMengCalculator》
    今日推荐英文原文:《10 Signs You’ve Got a Stupid Idea》

    今日推荐开源项目:《家国梦 JiaGuoMengCalculator》传送门:GitHub链接
    推荐理由:《家国梦》是由人民日报和腾讯游戏共同创作的公益手游。游戏以中国建国70周年作为主旋律,号召玩家为中国,为家乡的建设,贡献力量……看看介绍,感觉这是一个不算太复杂的游戏。但是如果把所学的知识和这个看似不复杂的手游混合在一起的话会怎么样呢?这个项目是一个计算在游戏中建筑最优配置的计算器,也就是把算法的知识和这个游戏结合的成果。虽然看起来大有种杀鸡用宰牛刀的感觉,但是最起码你拥有了一个驳倒“读书有啥用,拿去买菜吗?”的完美理由了——谁说知识不能用在打游戏上的?
    今日推荐英文原文:《10 Signs You’ve Got a Stupid Idea》作者:Jessica Wildfire
    原文链接:https://medium.com/swlh/10-signs-youve-got-a-stupid-idea-b585049f6774
    推荐理由:总有些时候我们需要一个灵感来推进任务——但是很明显有的灵感只是犯蠢的想法

    10 Signs You’ve Got a Stupid Idea

    We all have them. Learn how to spot them on sight.

    Even geniuses have terrible ideas. They’re just good at spotting them. They know what a good ideal feels like.

    A good idea makes you go hell yeah.

    A good idea won’t usually make you rich or famous. It might not meet with a ton of praise. But you don’t regret it, either. It’s hard to know when you’ve got a truly stupid idea, and when you’re just doubting yourself.

    Hard, but not impossible.

    Recently, I spent 7 hours on a stupid idea. Then I made a fresh pot of coffee and stared out the kitchen window for a while. When I came back to my idea, I found myself whispering, “Holy shit… this is terrible.” So I deleted the whole thing and wrote this instead.

    I’m coming off fresh from a stupid idea, with firsthand knowledge of what it feels like from start to finish:

    You feel like it’s utterly brilliant

    The idea feels like a masterpiece waiting to happen. You haven’t even started working on it, and yet you just know somehow. Yeah, right. When you catch yourself marveling at the light bulb above your head, it’s time to take a break. You’re not thinking clearly.

    You’re obsessed with its originality

    Nobody has ever thought of this before, right? You’ll be the first. In truth, nobody’s ever the first to come up with an idea. Not anymore. Humans have lived too long. Every idea just adds a little something. The novelty of an idea doesn’t matter as much as the quality of execution.

    You focus on the bells and whistles

    The idea should be enough. It doesn’t need special features or gimmicks. If it does, you’ve got a stupid idea.

    You can’t wait to show it to someone

    That’s because you feel insecure about your brilliant idea, and you want external validation right away. You don’t just want someone else to nod and go “cool.” You want them to react like a cartoon.

    It forms out of desperation

    You’re probably deep in the swamp of failure. You’re not feeling great about yourself. You’re looking for any reason to feel better. This means you’re more likely to overestimate the quality of your ideas. When you’re not starving, you know how to toss back the little fish.

    You feel an urge to get it done now

    Part of you sees what’s going on, and it tries to get you to slow down and think. Your better self doesn’t want you throwing away ten hours on an idea with no merit. Ironically, this puts the rest of your brain into overdrive. It doubles down on your bad idea, and tries to get as much work in as possible before you wise up. We become strangely fixated on bringing our stupid ideas to their rotten fruition.

    It’s completely unfeasible

    That’s the part that tantalizes you. It looks really hard, perhaps even impossible, and right now you want the distraction of a challenge. You might lack the skill set to bring your idea into being, but that won’t stop you. You’ll find a shortcut somehow.

    You care more about the idea than anything

    The best ideas add value to other people’s lives. When you skip over this part, that’s a red hot sign that you should stop and relax. You’ve started caring more about the idea, and the attention it will bring you, than what you’re actually bringing to the table.

    You start fearing that it will fail

    What if nobody cares about your brilliant idea? You’ve invested all this time and energy. If it doesn’t vomit rainbows, you’ll be devastated. That means you probably know it’s going to fail. Not only that, you’re starting to see why — and just can’t admit it to yourself. A good idea will get better through criticism. A stupid idea completely falls apart.

    It’s actually torturing you

    A good idea should feel good. You shouldn’t be sweating too much over it. You should be approaching it with a calm, patient attitude. It’s hard, but the good kind of hard — not the kind that makes you agitated, swinging back and forth between euphoria and panic attacks.

    Sometimes a good idea is just a cool little idea. It doesn’t take long to implement — and you don’t expect much. These ideas might excite people more than you expected, but not less.

    You know you should be doing something else

    Your utterly brilliant idea could just be a distraction from parts of your life that you’re neglecting. That little voice in your head keeps saying, “Are you sure this is worth your time?” The little voice doesn’t doubt you, just this idea. It feels like you could be doing something more worthwhile, like taking a shower. Have you smelled yourself?

    Stop waiting for the next brilliant idea

    We spend so much time trying not to give up. But sometimes you do yourself the biggest favor by stepping back from those brilliant ideas. They’re just stupid ideas wearing a cool suit. It’s okay, you can give up on a stupid idea without giving up on yourself.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第569期:《猫也看不懂 meow》

    5 10 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《猫也看不懂 meow》
    今日推荐英文原文:《The One Missing Skill for Developers》

    今日推荐开源项目:《猫也看不懂 meow》传送门:GitHub链接
    推荐理由:众所周知,人类和动物之间一直缺少一种用于沟通的语言。这个项目可以让猫来使用你的编辑器,同时猫打出的文字将会变成猫语显示在屏幕上,这将是人与猫交流沟通的一大进步。唯一的缺陷就是,现在人类无法破译这种语言——而且,猫也看不懂它到底打了啥出来。


    今日推荐英文原文:《The One Missing Skill for Developers》作者:DEV.BIZ.OPS
    原文链接:https://medium.com/swlh/the-one-missing-skill-for-developers-9406aaad1855
    推荐理由:项目完工之后,兴许下一个问题就是如何获得收益了

    The One Missing Skill for Developers

    Should developers learn how to “sell”?

    One of the most memorable lines of any movie in recent years was from an early 90’s cult classic based on a Pulitzer winning play:
    “Put that coffee down! Closer is for closers only.”
    Even if you have never watched Glengarry Glen Ross, chances are that you have heard this quote. His nearly seven minute profanity laced monologue has become legendary for its brutal depiction of the sales world and a must watch for anyone in sales. It painted a bleak picture of sales that lives on in the minds of many even today.

    No one likes salespeople. I don’t have any data to back up that assertion, but let’s just say that no child ever said “I want to be a salesperson when I grow up”. Other than politicians and ambulance chasing lawyers, there is no more reviled a profession.

    Yet we all need salespeople. Without salespeople, there are no companies, because it is only through selling that revenue comes in to fund all the things a company produces. I often have to remind startup founders I advise of this fact. They somehow believe people will just find and automagically buy their super awesome product without any humans.

    I cannot blame founders for thinking sales just happen. They are often coders and think everything is something to be engineered, including the process of selling. At the low-end of the market for commodity goods, e-commerce and chatbots have remove direct sales from the equation, but anything that is remotely complex or customized needs salespeople.

    Developers do not typically have a good grasp of what salespeople do or how to actually sell. They view sales & marketing as something to shun and not relevant to them or their careers. However Jeff Atwood shared an interesting take on this topic of selling:

    All that brilliant code is totally irrelevant until:
    • people understand what you’re doing
    • people become interested in what you’re doing
    • people get excited about what you’re doing
    Jeff calls this marketing, but that is mistaking the goal of marketing versus sales. Marketing is an outward motion to reach many people to generate awareness. Sales is about one-on one conversations with individuals to influence a decision to change or take action.

    Regardless of the semantics, Jeff is spot on about this one skill being something every developer should know. Yet it is not ever talked about or encouraged because of the emphasis towards hard programming skills. The other skill every software engineer has is the ability to solve problems which involves surfacing and executing on ideas.

    Let’s say you have a novel idea to save your company money by improving the speed of code deployments which in turn will accelerate product delivery. Perhaps you have it all worked out and now want to get approval to move forward with this brilliant idea. How do you get started?

    Well first you might want to let you manager know. Because your manager is beholden to upper management, you will need your manager’s approval to present the idea. As this will entail both money and resources in other departments, you will need to talk to finance and leaders from the other departments. And because you might need to bring in an outside technology, now you need to reach out to vendor management and legal. Then information security needs to vet the technology for vulnerabilities and compliance needs to ensure that the vendor adheres to certain standards. Ultimately, the executives need to approve your idea from among multiple competing and equally compelling initiatives

    How would you go about getting support across all of these groups? Most engineers would reply that they need a business case. Yes, that is certainly true and you need to clearly convey the benefits and the financial justification. But what you really need to do before you share anything is you need to influence the thinking of all the various people you will engage.

    Influencing, relationship building, storytelling, speaking to value are all components of what a professional salesperson does. The difference is that you are inside the organization and you do not have “sales” in your title. Even though you may vehemently deny you are “selling”, the fact is that everyone has to sell as some point, whether selling yourself for a job, selling an idea inside a company, or selling your idea of the “perfect” vacation with your significant other.

    To be successful in any profession, you need to have sales skills. Whenever you want to enable some change in your organization, you need to leverage these skills to influence and build support for your idea. If you ever wondered how some people rise to leadership roles whereas equally capable people do not, it comes down to the ability to sell.

    Even on your team, you need to advocate for your ideas, especially when competing ideas are introduced. During code reviews and standups, there are going to be times you need to make the case as to why your code is best. As Jeff shares:
    You probably spent too much time building your code and not enough time as an advocate of your code. Did you explain to people what your code does, why it’s cool and important? Did you offer reasons why your code is going to make their lives better, at least in some small way?
    Selling is not something that feels natural or obvious for anyone. Sales is learned, much like coding skills. Like coding, the more people practice, the more competent they become. Two books that I have recommended to help non-salespeople understand sales are “To Sell Is Human” by Daniel Pink and “Influence” by Robert Cialdini. The first provides practical tactics anyone can use and the second delves into the science of how influence actually works.

    Coding skills are table stakes for developers these days. Jeff agrees:
    To truly become a better programmer, you have to cultivate passion for everything else that goes on around the programming.
    One of those things in the bucket of “everything else” is selling skills. The real differentiator for long-term career and professional success is convincing others why your ideas matter and being more influential.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第568期:《准则 senior-engineer-checklist》

    4 10 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《准则 senior-engineer-checklist》
    今日推荐英文原文:《There’s No Such Thing as User Error》

    今日推荐开源项目:《准则 senior-engineer-checklist》传送门:GitHub链接
    推荐理由:一个为软件工程师准备的准则清单。清单上的内容包括管理与技术等在工作中可见的各方面,可以作为日常行动的指导来获得更大的收益——不管是对自身还是对整个团队。不过更具体的实施方式就需要根据实际情况自己选择了,这些准则提供的是做事的大致方式与成果,而不是细致入微的实现细节。

    今日推荐英文原文:《There’s No Such Thing as User Error》作者:Ryan Nehring
    原文链接:https://medium.com/@ryannehring/theres-no-such-thing-as-user-error-76b564454234
    推荐理由:软件就像积木塔,而有些用户就像熊孩子——这就意味着你需要做好充足的准备来从熊孩子手里保护积木塔

    There’s No Such Thing as User Error

    Make your applications invincible

    The name of the first programmer to ever code a popup window telling a user that they had made an error is undoubtedly lost to history, but the impact of that one simple choice resonates even today. That early coder, faced with the difficulty of building software set a dangerous and counter-productive precedent we as a community have internalized to our detriment.

    It created an adversarial dichotomy between developer and user, based on the false assumption that such a thing as a “user error” exists. It does not.

    There is no such thing as a user error. There are only interactions that we developers have not adequately anticipated and designed for. How do we correct this?

    Avoid Tunnel Vision

    Step 1 of the programmers’ process involves defining our problem set. What does this application need to achieve? We define the necessary functionality, the implicit data structures, the communication layers, and the user interface. Unfortunately, we do this in a vacuum.

    We get so focused on how to achieve the desired result that we fail to account for the journey the user undergoes to get there. This is understandable as quite often we’re facing an immensely difficult task and finding even 1 adequate solution can be daunting, but this kind of singular approach is a recipe for myriad possible failure states. We must learn to account for unexpected user choices or our code won’t know how to handle them when they happen, and they always happen.

    Appropriately Restrict User Input

    If you’ve ever uttered the sentence “No, you’re not supposed to do that…” when showing a user your application, you’ve failed them. If a user isn’t supposed to do something, then your code should stop them from being able to do it. The responsibility for effective interaction rests solely on the developer.

    Web forms present an excellent example of this in practice. Does the data you collect need to be in a specific format? Enforce that as the user fills it out. Give users hints in placeholder text or labels about the way you need their information, then write validation code that checks and enforces their entries to match it. Email addresses, dates, and phone numbers all present opportunities for a user to exercise their own judgment in format, and often that won’t match what your code wants.

    Test With Real Users

    We’re programmers, and as such we understandably think like programmers. Most of the rest of the world does not. In my experience, the majority of testing that happens to code is done by the person writing it. Although understandable, it is an amazingly ineffective way to objectively test software. You already know how your code is supposed to work, and you already know how you’d solve the problem at hand so inevitably your interactions with your application will reflect that.

    Having colleagues test your code is marginally better, but still a hollow facsimile of how an actual person will use your software as they are also programmers with an entire knowledge set the average user will not have.

    It can be intimidating and even heartbreaking, but having even 1 real user test your application will provide far more useful information than all of your own testing combined. You may learn something you’re very proud of does not work well for the user, or that your UI is cluttered and confusing to them; this moment sucks, but it’s worth it, I promise you.

    Effective development requires a willingness to confront some brutal truths. Things you take for granted will render users lost and frustrated when trying to navigate your app. Carefully considered choices you’ve made about user interfaces will turn out to be completely wrong in practice; that’s just part of the game.

    Pride can and does kill in development. If your honest goal is to build the best, most effective solutions possible for your users, then you must subjugate your assumptions and listen to them. You have to imagine the things they’re not saying, and build solutions in advance. You will fail in some of these aspects.

    The beauty of development is that you can always fix these shortcomings. Software has versions for a reason and you can revise and enhance as you learn what works best. The best developers always do.

    Eliminate the idea of a “user error” from your memory. Replace it with a willingness to understand your user and you will build things that people love and use. You’ll never anticipate every potential problem before it arises, but hey, thats what version 2.0 is for.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
←上一页
1 … 116 117 118 119 120 … 262
下一页→

Proudly powered by WordPress