开源日报 - Page 178 of 262

2019年2月11日：开源日报第333期

11 2 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《新的力量 public-apis》
今日推荐英文原文：《How to choose a programming language?》

今日推荐开源项目：《新的力量 public-apis》传送门：GitHub链接
推荐理由：在开发软件的时候兴许会需要一些特殊的功能，比如说发一张猫的图片之类的，在不是用于自己学习而是以做出成果为优先的时候，兴许借用现成的会更加节省时间一些。这个项目就是一些可以用在软件开发中的 api，比如各种动物图片和日程表这些，兴许这里面有一些正好是在开发中用得上的。
今日推荐英文原文：《How to choose a programming language?》作者：Kamil Lelonek
原文链接：https://blog.lelonek.me/how-to-choose-a-programming-language-7805da7ec588
推荐理由：决定选择什么编程语言的各种因素
How to choose a programming language?
If you are here, there’s a big chance that, during your career, you’ve been wondering at least once what language you should pick. Or maybe you’ve been even thinking about it before actually starting your programming life. It’s good to have you here then.

I personally do that often (maybe even too much) and I don’t only think about it but I try many different technologies in practice with better or worse results.

Over the last couple of years, I used the following languages:
- Bash
- IBM RPG
- Java
- Scala
- C#
- C++
- Ruby
- JavaScript, CoffeeScript
- Clojure
- Objective-C
- Elixir
- GO
And by using I don’t mean just going through some tutorials but, at least, working for a full year commercially and building one production project.

If I considered some pet-applications, student projects, bootcamps, and workshops, I could count in even more:
- Pascal
- PHP
- Swift
- Kotlin
- Groovy
- Python
- TypeScript
- Crystal
- OCaml
- MATLAB
- Visual Basic
- Solidity
Having said that, I believe I can present my opinion regarding picking a new programming language and the most important aspects worth to consider.

Moreover, according to CliftonStrengths assessment, I’m pretty good at analyses so I feel even more competent in that area:

I’ll give you a checklist, a set of questions to be asked by yourself about any new technology you want to start learning.
Adoption
- What kind of companies use it?
- In what areas it is being used exactly?
- What is its general purpose?
You have to consider what field is a particular technology used in. Maybe this is mostly automotive (e.g. C++), ML/AI (Python), low-level and server-related things (GO), web applications (Ruby), enterprise projects (Java/C#) and so on.

You need to think what your interests are, whether you want to work in startups, small software houses, big corporations, fin-techs or governmental organizations and find suitable technologies there.

If you see that, for example, .NET is mostly used in corporate areas, but you prefer small companies, you may want to consider Ruby instead.
Community

Developers

Have you ever wondered how many developers of a particular technology are out there? Are there many people using Rust or F#? Have you ever thought why it matters? Let me explain — to get support from others.

From what I see, lots of programmers, in case of encountering any kind of problem, usually reach to StackOverflow or look for answers on various blogs. And that all wouldn’t ever be possible if there were only a few developers of a particular technology. They would probably have different problems and not many of them would share that on the web.

The more programmers there are, the more problems are encountered and the more solutions are posted in the Internet. If you are using some well-known language you may haven’t even experienced such an issue. Give some exotic technology a try and you will immediately start struggling with errors you don’t understand, can’t fix on your own and no one can help you.
Recruitment

I know this aspect is rarely considered by developers, especially when you are a beginner, but you have to keep it in mind when you think about your product and company in general.

Sometimes you may be in the role of CTO, tech- or team lead and your responsibilities are to pick tools, technologies and recruit new people to your project. It’s obvious that when you choose some fancy language (e.g. Elm), you may have troubles in finding experienced people to join you.

The situation might be similar when you are looking for a new job and the only skills you have are some unknown and not so popular technologies. You may find it problematic to shuffle job offers and find that one which will satisfy you.
Supporters

Creator
- Who exactly is the creator?
- How does the creator commit to the community?
- Is the creator opinionated?
It’s also an important aspect of technology. Its creator may take an active part in the community but he may also withdraw from it.

Consider Elixir for example. José Valim, the co-founder & creator of Elixir lang is really involved in the development of the language. He replies as much as he can on GitHub, he gives his feedback on Elixir forum and he attends even small meetups and local conferences to engage and encourage people to use Elixir.

Back in 2012, when I was programming in Scala, Martin Odersky, a designer of Scala language, was rarely seen in some small communities, not to mention programmers meetings. Of course, he was giving some talks from time to time, and it wasn’t like he completely separated himself from the developers, but it looked like there was a big distance between him and all the programmers using Scala. Fortunately, from what I know from my colleagues, things have changed and now it’s much better in this field.

When you look at Ruby on Rails, you will see a quite opinionated but very charismatic leader. He likes to express subjective statements.
Company
- What is the main company that supports the language?
- What are the changes that the language will “die” soon?
- How much money is put into the language?
- How dynamic is its evolution?
Sometimes, it might be important to consider what company supports a particular language. Is it Google who advocates GO? Or maybe Facebook that stands behind React? Rust is backed by Mozilla, C# comes from Microsoft and Swift is developed by Apple. On the other hand, Clojure and Python are said to be community-driven which may bring their own pros and cons.

It’s important to think about how much money is provided to support language expansion. If you are sure that Oracle will be evolving Java year after year, you don’t have to worry about your future, market needs and availability of job offers. If you see that Angular will be released every 6 months, you can feel safe that new features will appear frequently and you will be able to schedule required upgrades.

That’s why you have to think about this aspect as well which is not that obvious at the very beginning and requires some research then.
Libraries
- How many libraries are available out there?
- What are the integrations provided by different services?
If you, for example, consider Ruby or JavaScript, you can be almost 100% sure that every tool has some integrations with these languages. You don’t have to worry about writing your own tools or wrappers around some APIs. You will find all, even official, libraries to integrate with Twitter, Twillio, GitHub, Dropbox and so on. If you, however, choose Elixir, for example, you may have troubles with finding well-maintained community libraries, to say nothing of official ones. It’s better now than it was like 4 years ago, but it’s still an issue sometimes and it needs to be verified definitely.

So if you plan to build a tool that will heavily rely on external APIs and combine multiple integrations, you may want to consider some less exotic technologies to do so. Mind you, your goal is to build products and deliver business features, not to develop other libraries or integrations (unless this is your actual business of course).
Salary
- Are the programmers of this language well paid?
- What is the market demand for this technology?
- Is there a high competition among developers?
How is it currently?
Cobol now is a well-paid technology but have you considered why exactly? Is it because it’s very promising, super popular and widely adopted or it’s just old but many systems rely on it and there are no specialists?

This is always worth considering how much you will be paid using a specific language. You may like Elm very much, but after some research, and hopefully not diving into it too deeply, it will turn out that no one is willing to pay you for it a lot.

Trends
Sometimes, the language is not well-paid yet, but considering market demands, the trend is promising. Have a look at Rust for example.

If you strongly believe that some language will grow rapidly in the future, you may invest in it your time right now, and once it becomes popular, you will be an expert already. It brings a risk of course because the technology may not be adopted well but imagine what will happen otherwise. You will have an experience that nobody will have and you will be able to work as an expert. It’s just a matter of following trends and making wise choices now for your future.
Complexity

It’s a pretty individual thing but still, it’s worth considering to check how you like the syntax of a language. How error handling is done there, how much code you need to achieve concurrency or parallelizm, how quickly you can read and understand others code.

Consider Ruby or Python for example, which are languages that every english-speaking person can easily understand. Have a look at C-based languages and you may struggle to grasp what exactly is happening there. Java and C# are also pretty verbose while Clojure, on the other hand, might be sometimes overcomplicated.

Of course, with time, you start understanding any syntax more and more, but still, you may feel more confident with Elixir rather than GO in some cases. From what I observe, the more low-level a language is, the more flexibility and tolerance developers have. The more abstraction it allows, the more declarative it becomes.
Tooling

Except having libraries available, there’s is an important part around the language which are available tools to support development. They may include different builders, compilers, static analyzers, formatters, testing and deployment tools.

Think for a while how hard it is to bootstrap a single project, write some code, test it and deploy to production. How much time it takes to release a new application version after linting your codebase. How simple it is to migrate your database, download and upgrade dependencies or build a single executable package.

After a while, you probably have a set of scripts that do the job but think about juniors or newcomers. Will they be able to do all of these things as easily as you? Are these features provided by a language itself or each developer has to prepare their own tooling? The syntax is one thing but at the end of the day, you have to expose your application to the world. How much will it cost you?
Summary
As you can see, there are a lot of things to consider. If your time is limited and expensive you may want to think twice what you will spend it on.

The set of questions, you’ve just read, will definitely help you to make the right choice and be satisfied with your decision.

Let me know whether you’ve recently chosen a new technology, how have you analyzed it, and how happy you are with the selection you made.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月3日：开源日报第332期

3 2 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。顺带一提，从明天起开源日报栏目就开始暂时休息了，回归时间为 2 月 11 日，希望大家也能整理心情，过个愉快的年。
今日推荐开源项目：《简单动画 animated-burgers》
今日推荐英文原文：《How to Feel Less Overwhelmed as a Developer》

今日推荐开源项目：《简单动画 animated-burgers》传送门：GitHub链接
推荐理由：一些关于通过点击将三条线转换为箭头之类的简单风格的动画，看起来的效果相当简单。它最大的特点是可以有选择性的引入你需要的动画而不是我全都要.jpg。在你的 React app 上同样可以使用它们，虽然看起来它们都很小，但是没准在页面的某个地方正需要这样一个箭头。
今日推荐英文原文：《How to Feel Less Overwhelmed as a Developer》作者：Julia Haigh
原文链接：https://medium.com/@juliahaigh/how-to-feel-less-overwhelmed-as-a-developer-79bc816709de
推荐理由：作为开发人员在遇上问题时应该怎么办
How to Feel Less Overwhelmed as a Developer
There’s a lot going on in the developer world. No matter whether you’re a complete beginner or a seasoned expert, it just never seems to stop. Here are some ideas on how to handle it all.

I’ve done my best to make this article concise & skimmable, in the hope that it may be helpful without adding too much to the chaos. It’s divided up into 4 sections: Mindset, Learning, Social Pressure, and Toolset. Let’s go.
Mindset
It all starts in the mind. Feeling overwhelmed is a response to too much going on at once, being over-stimulated and unable to process everything. You need to refocus, and reprioritise.
Understand the problem
This is the first step of any problem-solving technique. Why is it you feel overwhelmed? What’s the root cause? Is it too much to learn? Too much to keep up with? Too much responsibility at work? Peer pressure? Too many expectations of yourself?

It can help to sit down with a pen & paper and map out the problems you’re dealing with. It will help you to find your biggest issues, so you know what you need to learn to handle the most.
Recognise that you can’t do everything
You can’t do everything — that’s why we have teams. It’s impossible to be an expert in everything. Every area of engineering is a whole subject in itself, from AI to DevOps to CSS. Similarly, writing tutorials, open source contributions, side projects, all take time. Everything takes time.
Know that there’s no “right” way
There are good ways to do things, and there are bad ways, but in real life there’s no “correct” way. It’s not right vs. wrong, but more a vague sort of best fit. Even with code. Especially with code.
Figure out your goal
What do you actually want to achieve? Do you want to be the world’s foremost expert on containerisation, or do you want to be really good at your job, then go home and spend time with your family? Maybe you want to find your niche? You don’t have to live your life by everyone else’s standards, and knowing what you really want helps you to set your boundaries, focus your ambition, and recognise what’s not really relevant to you.
Learning
As developers, most of our knowledge comes from self-teaching — but it’s a fairly new approach to learning for most of us. It’s very different to formal education. Most importantly, you’re not expected to memorise everything. Understanding the scope of the topic, and knowing where to look for the right information is far more important. Familiarity comes with practice & experience.
Structure your learning
One of the biggest roadblocks with self-teaching is knowing what to learn — knowing where to start, what’s important, and how much there is to cover. Nobody is setting a curriculum for you, so it’s crucial to define some structure for yourself. It’ll lessen the cognitive load to have it all out in the open, and give you a boost to tick things off later. Doing some exploratory research can help you get a handle on everything; try these:
- Developer roadmaps, like Kamran Ahmed’s. It’s still overwhelming, but it gives you some visual structure, and puts everything into context. Remember, no one knows everything on it.
- Make a list of what you don’t know, and add to it every time you hear something you’re unfamiliar with. You’ll see the same things crop up over and over.
- Online courses, and course outlines — even if you’re not a beginner. You don’t have to do the course, but you can still learn from what topics they cover.
- Textbooks. Maybe obvious, but less popular now. Books may often be out of date, but they can still give you a heads-up on subject scope.
- Browse job adverts to see what skills they’re looking for at the companies you want to work at. This way, you can see what’s actually in demand, and you know you’re on the right path for your career as well. If you’ve not heard of something, that’s great — add it to your list, and move on.
Establish your core resources
There’s a lot of content out there, and not all of it is useful and accurate. Remember how easy it is to publish an article. The most valuable posts will mostly be the ones you find when you need them, the ones which deal with the exact issue you’re searching for. Aside from those, it’s a good idea to find your core resources — the key websites and experts you can rely on again and again. There are a few main types:
- Documentation. The docs are always going to be the most accurate and up-to-date information that you need, even if they’re not that readable.
- References & learning resources. These are the websites that make a huge effort to present all the real-life best practice information, in as practical and as useful a format as possible.
- Experts. These are the people and blogs that know their niche inside out, and who write articles about new and better ways to do things. You’ll find them because their names crop up time and time again, they’re always top of your search results, or because they seem to have written a bunch of the articles you refer to a lot. If you’re new to an area, a lot of blog posts will be too in-depth and just confuse you more, but over time they’ll empower you to explore new ideas.
Once you have your favourites, you’ll find you rarely need to look elsewhere. It’s good to get out of your bubble occasionally of course, but do it when you’ve got a handle on everything, not when you’re trying to figure it all out. When you’re overwhelmed it can feel like chaos out there, while when you’re comfortable it will seem like a lot of it covers the same stuff.
Schedule time for learning
Dedicate some time every week to exploring and learning. It doesn’t have to be a big thing, just have a look at a couple of the items on your list to get familiar with them. An hour of studying can make a world of difference.
- Use Pocket to save articles for later, instead of keeping them in tabs, or trying to read them mid-flow. You can tag them as you like, which will help you with focused reading later.
- Sometimes just googling stuff and figuring out definitions is a huge step, and helps some things to click in your mind. Sometimes things that seem like a big deal turn out to be quite small.
- Focus on one thing at a time. Don’t try to tackle everything at once, just spend half an hour studying one specific topic, and understand it properly.
- Review your core resources. Maybe there’s an update to one of the frameworks you use, or you find some useful functionality you didn’t know about.
- Mess around with new things. You don’t have to do a course or use something on the job to get the gist of it, just do it for fun. Poke it a bit. If you’ve never worked with NoSQL, clone a MongoDB/Mongoose seed project and have a play around. That’s three things in one go.
Doing something routinely can make it something to look forward to. Your commute becomes your reading hour, Sunday night becomes your Sunday night experiment. Plus, you’ll get a dopamine boost from achieving something.
Social Pressure
There’s an awful lot of noise out there, especially online, and it’s incredibly easy to feel like you’re doing everything wrong. You’re not, you just need more perspective.
A lot of people write bad code
Just like a lot of people are bad writers, bad singers, or bad at maths. Startups with $2m seed funding can have bad code. People who work for Google can write bad code. Even great companies and great developers write bad code. All we can do is keep practicing, and keep learning.
People only talk about the good stuff
No one talks about the fact that they were up til 2am trying to fix a simple bug, or the fact that in their day job they’re stuck working on legacy code. They talk about their side projects, and the latest shiny thing they tried. Social media makes it seem like everyone’s working their dream job, but actually a lot of people are working long hours to tight deadlines, and leaving the office well into the evening.
People have different priorities
Some people see development as their main interest, and some people have other priorities, and other things in their lives. Some people live for the newest tech, some people are dead set on their side hustle, and some people just want to be popular on social media. You don’t have to keep up with people who spend every spare minute reading the latest blog posts. Let them sum it up for you.
Articles are deceptive
People like to write articles about what’s possible, not what’s common practice. Most stuff you don’t need on a day-to-day basis. Just because it’s cool or impressive doesn’t mean it’s useful, or that you need to be able to do it.
Job adverts exaggerate
Job adverts seem to have endless lists of requirements, but they’re written with the perfect candidate in mind. A lot of what’s listed you will need, but the rest is often just fantasy. Some of it you’ll learn on the job, some of it they want to use but aren’t in practice, and some of it is just part of their 5-year roadmap.
Make sure your managers are informed
Sometimes your managers aren’t aware of the level of work involved in things. Maybe they’re not technical, or maybe their knowledge is out of date, but often they don’t realise that you can’t just “add a dropdown”, that actually it’s a custom select component with autocomplete functionality, and it needs two new API routes.
Toolset
Coding’s just part of it, and having a good set of tools will help you to work smarter, and to better-manage your workload.
Spend time on core skills
Skills like problem solving, critical thinking & testing are like power-ups for developers. Dedicating a little time to learning how to approach problems in a methodical and systematic way will save you countless hours going round in circles. And they’re helpful in every area of life.
Use proper project management tools
Plan your projects. Manage your tasks. Track your bugs. Use git for version control. These tools all exist for a reason, and they help you keep track of everything that’s going on. You’re not supposed to store everything in your tiny human brain.
Minimise duplicate work
There are things you do a lot, and some of them you can cut out to make things easier.
- Use a good code editor. Features like autocomplete and tooltip definitions help you to get on with coding without hopping around the codebase trying to figure out what’s going on.
- Use snippets. A good code editor will let you set up snippets with shortcuts, but sometimes it’s just good to keep things in a a file that you can copy and paste. If you find yourself googling the same thing all the time, put it in your snippets file with a comment describing it, so you can find it easily.
- Keep track of reasoning. Often you’ll find yourself working through some code trying to figure out why you designed it that way. It’s a lot of cognitive overhead to repeatedly try and understand the same thing, and documenting your code well will help you save time & energy.
Fresh air, exercise, and conversation
Sitting in a room staring at a screen for 10 hours straight isn’t healthy. You can get too caught up in imaginary problems and lose sight of the big picture. It’s important to get out of your own head, as well as to keep your body and brain healthy. Go outside. Pet a dog. Let your eyes readjust. Talk to someone who doesn’t know what HTML is.
Ask for help
The people in your community want to support you. That’s why they write articles, build open source projects, and ask if you need anything from the shop. Ask for good resources, pointers, or support with your workload. Usually they’ll be glad to help.

Hopefully there’s been at least one idea here that’s helped you feel that life’s a bit more manageable. But I’ll leave you with one more.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月2日：开源日报第331期

2 2 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《新年初战 interview》
今日推荐英文原文：《A guide to tackling huge codebases》

今日推荐开源项目：《新年初战 interview》传送门：GitHub链接
推荐理由：项目作者的亲身面试经历，包括各种各样的细节和面试问题，如果希望感受一下真实面试是什么样的问法的话可以来看一看。当然了，看完之后发现自己还需要更加努力的话，就在新的一年里打起精神来努力学习刷经验吧。
今日推荐英文原文：《A guide to tackling huge codebases》作者：Cyril Pillai
原文链接：https://blog.gojekengineering.com/a-guide-to-tackling-huge-codebases-326977406abf
推荐理由：兴许有一天当你加入别的项目的时候，你也会看到巨大的代码库
A guide to tackling huge codebases
I recently joined GOJEK as a Product Engineer as part of the GO-LOGISTICS team. I’ve been doing Android Development for over four years, but when I first ‘git pulled’ GoHost (the monorepo for the Android consumer app), I was intimidated by the codebase. I have worked with codebases that had four to five contributors, but this was a different beast altogether.

80+ modules, 20+ active contributors, ~20 mins for a clean build, and different coding styles/architectures in different modules. Product modules are owned by the respective teams and thus they have the liberty to choose what works best for them.

On an unrelated note, codebases are the stuff of folklore at GOJEK. When we launched our app in 2015, all our backend services depended on a legacy codebase named after a South Park character, Stan Marsh. As GOJEK grew, Stan Marsh buckled under the strain. We eventually pulled all its functionality into discrete microservices. Nevertheless, the legacy of Stan Marsh lives on.

I was lucky enough to have access to some of the developers who oversaw the transition from Stan Marsh, and gained a lot of insights. This post pens down my learnings from the last few months on how to deal with huge codebases.
You can’t understand everything

This is the hardest thing of all.

All of the previous codebases I’ve worked on/owned had one thing in common — I knew everything, about everything. The legacy ones I inherited took some time and effort but eventually I used to get well-versed with the entire system.

I tried that approach here and failed miserably. Initially, I was responsible for a single module (GO-SEND product) out of the 80+ modules. These modules included other products (GO-RIDE, GO-FOOD, GO-TIX etc.), libraries/utilities, SDKs for the products, and product agnostic core/platform code.

After a few days of diving in the ocean of code and sinking every time, I got frustrated and talked to my Mobile Lead about this.

Talking to him made me realise that no one in the entire org knows everything about the system.

The key takeaway here is to understand the parts you own or would work on, and be oblivious to other moving parts. Changes are being made to the codebase on an hourly basis, and it’s humanly impossible to keep track of everything.
Get familiar with the architecture of the codebase
Now, when I say be oblivious, I don’t mean everything. It’s a mandatory process to dive into the ocean and sink, but you need to know when to stop. Try to familiarise yourself with the skeleton of the codebase. Read code from modules that make up the core of the system (platform code that is independent of the products), and understand how your module interacts with that code. Dig into SDKs and internal libraries that abstract certain third party dependencies, so that the product modules aren’t affected by future changes.
Have a specific goal in mind before you dive
It’s important to have a reason to dive into the ocean, and to have a well-defined task to finish and get out (because time ticks ?). If you don’t have any task, ask your team members to assign you something. It’s better to get up from the chair feeling good about completing something. Definitely beats getting lost in the gigantic world of programming constructs.
Read code thoroughly, don’t break anything
Let’s acknowledge that we developers can be a bit narcissistic about code. We love writing code but reading it bores us to death. Even if we trick our minds into reading someone else’s code, there is usually an urge to rewrite it. The best thing to do here is to be objective and follow one of GOJEK’s guiding principles:
“Every decision is correct at the time it is made”
Spend ample time reading the code and critically evaluate the consequences your changes might have before proceeding.
Follow the coding style of the file you are editing
This is to ensure that your changes don’t look out of place, and are aligned with the surrounding environment. It’s super important to maintain consistency no matter how outdated something feels.

Assume you need to change the filtering condition in a file:

What!! This class is still using RxJava 1.0. ?

Option 1
```
• I'll just update the filter condition as per the new requirement.
```
Option 2
```
• But, RxJava 2.0 has been around for such a long time.
• Let me upgrade it to the latest version.
——— after 3 hours ———
• I've modified a bunch of files and there's still a lot more to refactor.
——— git reverts everything ———
• GOTO Option 1.
```
Talk to other devs
Rockstar developer / coding ninja / 10Xer / one man army / everyone is inferior to me / I like working alone / others are stupid.

If you relate to anyone of the above things, you need to change. Can you build systems single handedly? Yes. But to make scalable solutions and improve yourself, it’s important to throw your ego out of the window. Be liberal and collaborate with others.

Coincidentally, this also helps in dealing with huge codebases. Talk to other developers who have worked on the piece of code you’re concerned with. To get more context, ask about the rationale behind the decisions made and the implications new changes would have. Be open to suggestions on the way you should approach the problem.
Improve it
- Make the codebase a bit stronger than it previously was by making sure that changes you make are supported by tests.
- Refactor wherever NECESSARY.
- Document decisions/assumptions/hacks to make sure the information is present somewhere (apart from the head of an engineer).
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月1日：开源日报第330期

1 2 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《技术负责人 techlead》
今日推荐英文原文：《Being Agile — a Human Perspective》

今日推荐开源项目：《技术负责人 techlead》传送门：GitHub链接
推荐理由：如何成为 Tech Lead。这个项目是作者参加了 Tech Lead 的培训之后写下的经验，Tech Lead，通俗的讲，即一个团队中负责解决技术难题，指引方向和写代码这三方面的那个人。回想一下自己在项目中的经历，如果你遇上了不懂的问题，你觉得谁可能会知道解决的方法？那个人很可能就担当了团队中的 Tech Lead —— 他同时作为了榜样和技术专家。总而言之，如果你想要更多的了解 Tech Lead，不妨来看看这个项目。
今日推荐英文原文：《Being Agile — a Human Perspective》作者：Vandana Adulkar
原文链接：https://medium.com/@adulkarvs/being-agile-a-human-perspective-7b3746931e0d
推荐理由：从人类的视角看待敏捷开发
Being Agile — a Human Perspective
My journey in software development has been through the terrains of MS-DOS to High Sierra, conversing in COBOL, JavaScript and many more along the way. As I learned to traverse the path and create wonders originating from the human mind, I encountered roadblocks just like other travelers on this path.

In 2001, seventeen of my fellow travelers on this journey came together in Utah to discuss and overcome hitches to smooth ride of software development and coined a manifesto. Agile was born. It heralded an express way to the pot of gold of valuable software at the end of the rainbow of methodologies. Obviously, I want the gold and thought of equipping myself with the challenges to create a game plan. My exploration has lead me to conclude that beneath the buzz of technology, methodology and terminology the key to being Agile is to remember to be Human.

So what is Agile? Essentially, Agile is a set of principles and practices for software development that emphasize: · Individuals and interactions over processes and tools · Working software over comprehensive documentation · Customer collaboration over contract negotiation · Responding to change over following a plan1 Why does it matter to be Agile? In my experience and understanding, to deliver software that matters, which caters to a need and is thereby valuable to the customer. But isn’t that the objective of any project that is worth building? Absolutely! I haven’t come across teams having discussions on how to produce something which is practically useless. Yet, even though starting with right intentions, processes and tools many projects inevitably ran into roadblocks and software crisis with waterfall model commonly used for the development.

As per the waterfall model the development moves in linear manner from gathering requirements up front, planning and designing the software, working out specifications, building and testing the code, implementing the solution and maintaining it. However, due to long turnaround time, lack of collaborations and communications among customer and team members, and inability to incorporate changes, the software delivered at the end is often not valuable to the customer. Agile manifesto addresses these challenges and delineates 12 principles to guide software development which when followed promises highly productive teams and customer satisfaction.

So where is the catch? Implementing the practices without having the perspective of the underlying principles leads to doing things better but following old patterns and adding new detrimental side effects. Grasping the principles is about developing a right mindset. Thereby, the crux of being agile is having a right mindset and a mindset lives in the mind, which is part of each instance of a human being. When individual minds of the team members align towards a common goal it leads to successful implementation of the agile methodologies.

In my experience, the major challenges to developing right mindset distill down to fear of change, lack of communication and missing the whole by being centered in the parts. The 12 agile principles work around these challenges however it is difficult to implement these principles unless the individual stakeholders (team members including customers involved as team members) address the underlying perceptions.

Fear of change, is at the root of the challenge as our brains are wired to resist change. Change is inevitable and change often translates as some trouble. We are wired to stay away from trouble so unless it is demonstrated in a tangible manner that going agile would eventually mean less trouble for the individual there would be resistance to the change. A solution that has worked for me has been to educate on what is down the road, illustrating the benefits, bringing in the culture of trust to collaborate. For example, using daily stand ups, one of the agile practices, to actually get picture of where the project is moving and voicing road blocks instead of blaming, micromanaging or checking on team members.

Once trust is built, it opens up readiness for communication, as each member feels heard, valued and contributing to the whole. Even though there may be openness for communication, the success depends on understanding the paradigm each person is coming from. Visual interactions foster empathy and seeing other’s perspectives. Principles fostering constant communication bring in clarity early on and prevent from treading wrong paths.

Communication and collaboration lead to seeing the larger picture and understanding the context of each individual contribution to the whole. The synergy is greater than the sum of individual parts geared towards valuable outcome. Clicking the puzzle pieces together and creating the whole picture instead of being individually correct. For example, a developer in the team my pass all the tests and have bug free implementation but if the code is not addressing a required feature than it would not be contributing to the overall outcome value.

A human perception to being agile is rightly summarized by Jim Highsmith as quoted in Learning Agile: Understanding Scrum, XP, Lean, and Kanban:

“Without concrete practices, principles are sterile; but without principles, practices have no life, no character, no heart. Great products arise from great teams — teams who are principled, who have character, who have heart, who have persistence, and who have courage.”

Character, persistence and courage are all human qualities. We are intelligent beings, creators of technologies and methodologies and maybe it would be worth pondering that reaching the pot of gold at end of practices and methodology would be being rooted in core human qualities and being human.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/