开源日报 - Page 183 of 262

2019年1月15日：开源日报第313期

15 1 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《灵性的操作 CSS-Inspiration》
今日推荐英文原文：《7 tips to ace your tech job interview》

今日推荐开源项目：《灵性的操作 CSS-Inspiration》传送门：GitHub链接
推荐理由：一些使用 CSS 来完成某些课题的方法合集。这个项目展示了各种 CSS 的使用方法，包括各种布局方法和各种投影方法等等，意在让读者从中想到一些关于 CSS 的新使用方法，如果想要为自己的个人网页加上一些新的效果的话，可以在这个项目中找到一些方案或者灵感。

今日推荐英文原文：《7 tips to ace your tech job interview》作者：Jessica Repka
原文链接：https://opensource.com/article/19/1/job-interviewing-tips
推荐理由：在新的一年里找工作的面试指南
7 tips to ace your tech job interview
I’ve found myself looking for jobs more often than I’d like. For the most part, it’s been due to company buy-outs, but other times it’s been due to less-than-adequate working conditions. Recently, I’ve spent time on the other side of the fence, interviewing people. The following tips are based on events from my job interviews and what I’ve seen in person while interviewing others. Use these strategies to stand out from the crowd (in a positive way) at your next job interview.

Do your research
Before walking into the door for an interview, it’s helpful to know the company and its line of services. Someone is going to ask, and most likely you will be interviewing for a position directly involved in providing or building those services. Make sure you know about both the company and the position’s requirements so you understand where the job fits into the company overall. You’ll probably be asked to answer something about this within the interview’s first three questions.

Dress for the job you want, not the one you have
Even though I’ve heard this quote countless times, it will always ring true. Presenting yourself in front of other people matters in many situations, none more important than a job interview. Never show up in jeans, a t-shirt, and flip-flops and messy hair. It doesn’t matter if that’s what your interviewer looks like or if you have been told that it’s a relaxed environment. On the flipside, don’t show up in an evening gown or tux—it’s not a wedding or a night out. Be dressed for business. For men, a nice pair of slacks, a button-down shirt, and a sports jacket or blazer (I’d choose blazer) is appropriate. Women, you can’t go wrong with a nice power suit or a business-style dress with a coordinating jacket. Always make sure you are well-groomed, brush your teeth, and do not use overwhelming perfume or aftershave/cologne.

The truth about your résumé
Recently, I’ve found more than one person who put information on their résumé they couldn’t explain when asked a basic question about it. An example would be listing Docker on your résumé but not being able to answer something as simple as, “You have Docker experience listed here; can you tell me what CMD in the dockerfile means?” This has happened, and it always ends with a difficult talk with the recruiter afterward. Anyone can understand a small amount of fluff on the résumé, but if you cannot answer a basic question about your experience, it shouldn’t be there.

It’s OK to say no
In interviews, there will always be questions relating to the job description and requirements that aren’t on your résumé. It’s ok to say, “No, unfortunately, I have not had the chance to work with this yet.” If you are not willing to learn that skill, this position may not be for you, and that is OK. If you are willing to learn, then make sure to say, “No, unfortunately, I have not had the chance to work with this yet. But I’m always willing to expand my experience.”

Most of the time you are asked, “Are you willing to learn or be trained to use this technology?” it’s sufficient simply to say, “Yes I am.” In case they follow up by asking, “What’s your best form of learning?” be ready with your answer. My answer is always the same—books and documentation—but you may learn a different way, which you can state if the subject comes up.

Awkward silences and answering questions
Answering questions can always be a little rough. I have anxiety, so I understand how hard it is, and most other interviewers understand, too. But you don’t want to entertain or amuse the interviewer for the wrong reasons. To that end, here are some do’s and don’ts for things to say in an interview. (Again, these are all based on my real-life experiences.)
- If you need a whiteboard to explain an answer, say so after the interviewer asks the question by politely asking, “May I draw this out for you on a whiteboard?”
- Never allow a very long, awkward silence after you answer a question. If you count to five (in your head) and nothing is said, ask, “Do I need to explain further?” or “Do you have another question for me?”
- After you answer a question, don’t ask, “Was that right?” And, if you did get the correct answer, don’t proceed to say, “Yes, I got it!” while fist-bumping the sky.
- Never tell the interviewer that you’re only taking the job to pay your bills.
- Never tell the interviewer you don’t really plan on working very hard.
Off-topic questions
Occasionally, interviewers will ask off-topic or non-work-related questions. It’s OK, this isn’t a quiz; in most cases, they are just trying to get a feel for your personality. Below is a list of questions I’ve answered or asked.
- What hobbies do you have?
- What is your favorite color?
- What do you do for fun?
- Do you do any volunteer work?
- Do you have any pets?
- Which do you prefer, the art museum or the science museum?
Sometimes the purpose of these questions is just to make you feel comfortable, other times it’s just to get to know you better. I find them entertaining because I can always fire them back at the interviewer when it’s my turn to ask questions.

Returning fire: Asking questions of your interviewer
You’ve reached the end of the interview—congrats, you made it this far! And the interviewer says, “Are there any questions you have for us?” Limit your questions to around five, eight at the very most. Professionalism does not go out the door at this point; while you could ask whatever you like, there are always lines you shouldn’t cross.
Questions you can and should ask:
- What is the atmosphere like with the team I’d be working with?
- What is the dress code?
- What types of projects would I be working on?
- How many team members would I be working with?
- What hobbies do you have?
- Do you like working for this company?
- Do you like the technology you work with?
- How long has the company been using these tools, software, or technology?
Questions you should never ask:
- What pay would I receive?
- What holidays or vacation time should I expect?
- What are the benefits like?
- How hard is this job really?
- Is this a 9-to-5, or could I work fewer hours?
Asking too many questions can be unsettling to the interviewer. Asking inappropriate questions can get you a bad reputation with recruiters or other companies. People do talk, and it’s more than likely an interviewer will know someone somewhere else and word will spread.

Yes, it really happened
Many of you will think some of these things are obvious. While that is true, everything I’ve written here has happened. Some I’ve witnessed myself, some I’ve heard through managers at other companies, some I’ve learned through recruiters. As I mentioned, poor interviews spread easily. Your name is on that résumé, and it’s easy to get a reputation without even knowing it’s happening.

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月14日：开源日报第312期

14 1 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《前人的经验 flutter-go》
今日推荐英文原文：《Learning, Coding, & Freelancing as a Dad》

今日推荐开源项目：《前人的经验 flutter-go》传送门：GitHub链接
推荐理由：为使用 Flutter 的大家提供的助手。这个 app 可以作为使用 Flutter 的示例，包含常用组件的中文文档和演示。Flutter 是一个移动开发框架，想要详细了解的话可以看看这里（GitHub链接），它的 star 数已经证明了它是一个相当不错的框架了。当然了，虽然配合上中文文档食用更佳，不过还是鼓励大家提高自己的英语水平，毕竟直接看英文文档才是最快了解新技术的办法。
今日推荐英文原文：《Defeating the Scary Documentation Monster》作者：Kristiina Ritso
原文链接：https://medium.com/mobi-lab/defeating-the-scary-documentation-monster-5265596b4b92
推荐理由：写文档实际上并不是完全没用的事情，你永远不会知道你什么时候需要回来看看它的
Defeating the Scary Documentation Monster

“Hey! Can you write that end-user documentation about the app we’re developing?” — “ I’ll get to that when I have time.”
Ever had that kind of conversation and never actually ended up writing the damn thing because some other, higher priority task came along? Everything’s agile, moving fast and features get the focus. How can documentation bring value when it’s quite often considered waste?

In our lives we have all come to contact with some form of documentation, let it be technical requirements, API specifications, recipes, board game or furniture assembly manuals. We find them useful and reassuring, even if we will never read them more than once. One of the main points in agile software development is to produce software, not documentation. What happens when things go too extreme, and you end up in a situation where there’s no documentation at all or very little of it? Well, we were there.

Documentation can play a huge role. It can affect the developers when they need to return to a project that has been sitting on a shelf for years or onboard a new team member. It can be a significant risk for the client when the product has to be handed over, and they start maintaining it themselves. Without a proper set of minimum viable documentation, it can become more expensive than writing it in the first place. Sadly, when it was the right time to start, priorities laid on different aspects of the development process. Quite often it is the budget that sets the boundaries because the value is not always visible or arrives too late. So how can we make it valuable for everybody without putting a big hole in our budget?

Starting Steps: onboarding a team member
There are many projects in our development vault. Some of them well documented, some have a line or two written down in the README file, and some have information laying around in all sorts of communication channels. Writing documentation seemed to be like fighting a monster. Some took up the challenge only to find that it was not that scary. Others decided to let somebody else deal with it. We wanted to make it less intimidating and turn it into a natural part of the process. For that, we had to start from the beginning.

We first saw places for improvements when we had to onboard a new developer to the team. Our challenge was to find a way to communicate the development process as efficiently as possible and provide a source for the new person to come back to. We created a template for the team members to fill which listed all development related information and workflow of the team. This template helped the initial developers not to miss any vital information and gave the new team member a place to come back to when they needed it. Fortunately, a perfect situation occurred. Two projects exchanged developers. This gave us an excellent testing field for the template to validate the solution. The developers filled the document and carried out the onboarding process for each other. Instantly we could get feedback and revise the template. With a little effort and luck on our side, we already had a solid starting ground.

Okay, but this only solves one problem — having documentation for onboarding. We were still lacking documentation for smaller scale projects and a habit of creating it.

Moving forward
We had done our fair share of only-ifs and what-if’s, got burned from past mistakes and licked our wounds. Now it was time to take action so we could improve.

For larger systems and projects we have enough documentation. This is part of our process that starts with drafting architecture and analyzing requirements. For smaller scale projects, these phases are shorter and therefore do not always produce enough documentation.

From the onboarding template, we found a way to generate a starting point for the project’s ReadMe. There are many examples of ReadMe-s available, but we needed something that was custom made for our company’s processes. We started with defining the roles in the development phases. Mapping down all the parties helps to identify common information needed. Once we had them mapped, we also took a more in-depth look into what those parties are interested in. For example, there is no need for the designer to know all the technical constraints, but they are interested in where to find the application and whom to contact when they have questions. As we aimed to keep the information sufficient, but minimal, we filtered out the most critical aspects of those shared values.

We also needed to find a way to make it easily accessible and updatable. Without having a proper habit of writing documentation or keeping it up to date, it is hard to motivate oneself. We found it most comfortable to include it as part of a development task. Including documentation as part of the definition of done seemed the most effortless. It helps to create a habit and make it a natural part of a task’s lifecycle. It helps to keep the documentation process agile. With little effort, we have a way to keep the information up to date and relevant without producing waste.

After several sessions, we finally had a template to include into our projects that were structured and is not some scary Documentation Monster to fill giving us a stepping stone to improve even more and see the importance of documentation well before when it is actually needed.

Key takeaways
Like in the agile world, we are still moving with the currents and improving the process, but we are in a lot better place than a while ago. Without dismissing the principles of agile methodology, we got to a documentation process that is lean and effective. It keeps its value by being updated when there’s a need for it.

What we learned:
- Start writing handover documentation as early as possible
- When dealing with a small project, keep the documentation efficient and let it grow with the project.
- Keep writing documentation as part of issue’s definition of done rather than a separate task. This way you will have an agile documentation process
- Developing templates for certain types of documentation will make the process seem less scary.
Let us know in the comments section which documentation monsters have you faced and how did you tackle them?
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月13日：开源日报第311期

13 1 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《xswl dad-jokes》
今日推荐英文原文：《How Software Talks to Other Software: APIs Explained for Humans》

今日推荐开源项目：《xswl dad-jokes》传送门：GitHub链接
推荐理由：一个……非常有意思的笑话合集。这里面的笑话都是与编程有关的，而且正在不断持续更新中，兴许时常来看看它们调节一下生活的节奏也是不错的选择。
今日推荐英文原文：《How Software Talks to Other Software: APIs Explained for Humans》作者：Dana Hooshmand
原文链接：https://medium.com/@hoosh/how-software-talks-to-other-software-apis-explained-for-humans-72e9f9c44be4
推荐理由：简单的解释 API 到底是什么
How Software Talks to Other Software: APIs Explained for Humans
“Why does everyone keep saying APIs are important?” you say. “I thought I knew what they were, but now I’m not so sure.”

You’re not alone! Most people aren’t technical; but some make themselves seem technical by saying things like “APIs” and “protocol”. But even if you don’t code you can learn this too, and once you do, it’s like knowing the language of magic.

Spoiler: At the bottom, I’ll show how to use APIs without any code to do this very magic.

Don’t be scared. Here’s what APIs are.
An API is the way modern software communicates with other software, letting them work together just like we work together as humans.

Let’s consider the way we work as humans as a metaphor. There are two ways we communicate with each other: when we realise we NEED things and when something happens and we have to INFORM someone. Others too, because we’re not machines (well, most of us are not) and like to have jokey banter and occasionally airdrop memes to each other, but these are the transactional ways.

Here are some examples:
- “I need things”: “I am hiring some more staff next. How do I get them set up with laptops and company t-shirts and drink bottles? “You ask some people to do it, and they help you out.
- “I have to inform you of something”: Your boss asks you: “Every time you do an expense report, can you email (inform) me, so I don’t miss it?” Sure thing, you say.
APIs automate those ‘need’ and ‘inform’ situations.

There are two main kinds of APIs we use: REST APIs (aka RESTful ones, or ‘endpoints’), which wait around until you need something, and ‘triggers’ (also known as ‘webhooks’), which inform proactively

Example of a REST (‘need’) API: These are APIs that are waiting around to be asked something (RESTing, I think).

You go to Google Maps and click on ‘Home’. The app queries a series of APIs (who were waiting around to be asked… RESTing, I think) to find out
- From Google Maps: All the routing information and traffic times
- From Lyft/Uber: An estimate of the prices to get a ride
- From Yelp: Some well reviewed places to eat near home that are open
Example of a Trigger (‘inform’) API: These all involve a listener, which is sitting around waiting for it to be told something.

You pay for your coffee at some cafe using Square. Square says ‘yo this person just dropped $6 on a cappuccino’ to some survey software via a trigger. The survey software sends you an email asking you if it was worth listening to the barista’s edgy vinyl for 15 minutes after taking your money while he slowly worked through the queue.

Why APIs are important
When you find software that has a well-written API, you will know it will be easier and cheaper to use that software to build things, and that that software company is well-organized.
1. APIs make it easier to connect applications, saving time and money (developer costs). If we have to integrate software (like, for example, payroll, HR and procurement software), we want to make sure the developers planned on their software being easy to connect with other people’s software. This includes them thinking about security standards. There’s LOTS of ways of providing a secure API and authenticating, and this is super critical to a huge company. (If a company that holds your SSN has an API, you want to be really sure they’re not going to get hacked.)‌‌
2. Having a good API implies that the company is really structured and organized. A good API with good documentation is like meeting someone with really good filing and organization. It makes them seem trustworthy and un-chaotic. (Note to self: tidy desk before posting this.)
What API data looks like in practice
Good news! Modern software tries to use fairly human language, just with more structure around it. It looks like the following.

Note that you only need to know it looks like this and that it’s easy to read. You don’t need to know how to write it. There is some data in there, plus text and other stuff.
```
{ 
  "event_id": "12345", 
  "event_type": "form_response", 
  "response": 
  {
    "form_id": "lT4Z3j",
    "submitted_at": "2018-01-18T18:17:02Z",
    "definition": 
    { 
      "title": "Webhooks example",
      "fields": [ 
      { 
        "id": "DlXFaesGBpoF",
        "title": "Thanks, Dana! What's it like where you live? Tell us in a few sentences.",
        "type": "long_text" 
      }, {
        "id": "SMEUb7VJz92Q",
        "title": "If you're OK with our city management following up if they have further questions, please give us your email address.",
        "type": "email" 
      }, {...
```
The best part: How to use APIs to perform magic without code

There are three main ways: what engineers do (expensive; wait until two quarters from now), existing connections (convenient but limited, like Typeform automatically connects to Google Sheets), or cool things like Zapier and IFTTT.‌‌ I’ll focus on Zapier, though IFTTT and other apps do similar things.

Zapier is a piece of software that takes inputs, processes them and produces outputs.

Here are some examples of how I have used them at work and personally
- At work: Every time a visitor checks into a center, create a ticket for them in a queue management system, and send them an SMS afterwards with a follow-up survey. (This saved about 3 minutes per interaction, which for us, added up to 5,000 hours a month).
- Personally: Every time I create a new blog post, make a marketing post and put it on Twitter, Facebook, LinkedIn and email it to every subscriber. (This saves me about 15 minutes each time it runs)
- In between work and personal: Every day at 8am, send me a picture of a motorcycle with a countdown timer to my last day at work saying how many days were remaining.
I’ll write a follow-up post about some of the cooler things you can do via Zapier.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年1月12日：开源日报第310期

12 1 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《学习英语 An-English-Guide-for-Programmers》
今日推荐英文原文：《5 Reasons Software Engineers are Artists》

今日推荐开源项目：《学习英语 An-English-Guide-for-Programmers》传送门：GitHub链接
推荐理由：作者在辛苦备考雅思的过程中总结的学习英语的经验谈，主要是讲了自己的训练方法和自己用到的一些资源。不过这个项目最重要的就是从作者的经验中发现的一个简单道理：学习语言是没有近路弯路可以走的。只有去花费大量的时间才能够学好学熟，听说读写这四样都是需要花费相当的精力的，如果想要下决心学好英语的话最好做好觉悟。
今日推荐英文原文：《5 Reasons Software Engineers are Artists》作者：Ken Kao
原文链接：https://medium.com/@kenk616/5-reasons-software-engineers-are-artists-b14b0dd8d8eb
推荐理由：看起来软件工程师和艺术家有一些相近的地方——有些软件本身就像是一件艺术品
5 Reasons Software Engineers are Artists
Build software like Gaudí built the Sagrada Família

The Sagrada Família, still under construction. By Free Photos on Canva

Since I moved to New York from the Bay Area three years ago, I’ve been thinking about how great software engineers produce great work. Can the Silicon Valley mindset and approach be replicated elsewhere? This has led me to study some of the high-quality software engineering projects, such as Apache Spark, Tensorflow, and Ethereum. But as I was traveling in Barcelona last year, it struck me that the Sagrada Família may well be one of the best examples to learn from.

Here are five similarities I observed.

1. Give the artist creative space

If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. — Antoine de Saint-Exupéry, French poet
Basilica della Santa Casa in Loreto, Italy. By Massimo Roselli on Wikimedia

The Sagrada Família was originally conceived of by Josep Maria Bocabella, who, inspired by the Basilica della Santa Casa in Italy, wanted to build a cathedral in Spain. Gaudí was then given full autonomy over this project. He was not a task-taker, but an architect; an artist. Can you imagine if Bocabella were to dictate which type of wood, cut of stone, and shards of glass to use? Under such circumstances, Gaudí likely would have turned down the job, and we would have lost a world heritage site.

Software engineers are also not task-takers — we are problem solvers. We specialize in finding the best solution for a given problem. This is why tech companies like Google and Facebook don’t care about which programming languages you know: they look for problem-solving ability. They trust that their engineers will pick the right tools to solve the problem at hand, just as Gaudí was given full liberty to pursue his vision of the basilica.

On the contrary, I have often seen companies where sales or marketing largely decide on both what and how to build software. This operating model impedes those companies from realizing their full innovative potential because they are not tapping into the strengths of their builders. As Bill Campbell, former executive and coach at Apple, once said, “Empowered engineers are the single most important thing that you can have in a [tech] company.”

2. There is no single right way of doing art; it is an expression of the artist

There are no rules to creativity. — Laura Jaworski, American author & artist
When Gaudí took over as the lead architect of the Sagrada Família, he made many changes to the original Gothic design by incorporating natural shapes, oriental arts, and equilibrated systems. Some hints of the original Gothic style remain, but it is a far cry from other buildings built in that era.

Likewise, there isn’t a single right way to build software, just different trade-offs. Facebook is famous for having a single monolithic code repository. This ensures all projects and dependencies are compatible with each other. On the other hand, Amazon has a separate repository for each service, allowing faster iteration cycles because each service is run independently from each other.

Software also reflects its authors. Tensorflow, a machine learning framework open sourced by Google, captured hundreds of thousands of developers because of its usability, speed, code quality, and comprehensive documentation. These attributes directly tie back to Google’s core philosophies of focusing on users, emphasizing speed, and striving beyond greatness.

3. Inspiration comes from persistent routines

Talent is long patience, and originality an effort of will and of intense observation. — Gustav Flaubert, French novelist
One of Gaudí’s 3-D models used to evaluate the structural integrity of his designs.

People’s image of artists is often of lives of relaxing creativity. The reality is they develop a routine and consistently follow through. Pulitzer Prize winner, Maya Angelou, would get up at 5:30 a.m. every day and start writing at 7 a.m. for five or more hours. As Michelangelo once said, “If people knew how hard I worked to get my mastery, it wouldn’t seem so wonderful at all.”

Gaudí was no different. He originated the concept of the equilibrated system — buildings that could stand on their own without internal or external support. Because this new architectural style hadn’t been built before, no one knew if his designs would withstand the laws of physics. His solution was to build 3-D models and try hundreds of configurations. Many of his final designs were inspired by his experiments.

Likewise, in software engineering, you go to work every day and ̶w̶r̶i̶t̶e̶ ̶c̶o̶d̶e̶ ̶f̶o̶r̶ ̶a̶s̶s̶i̶g̶n̶e̶d̶ ̶t̶a̶s̶k̶s̶ design solutions to problems. With consistency, every so often you will have a stroke of inspiration that leads to outsized impact. For example, a group of engineers hacked at anti-fraud software for Paypal. This led Peter Thiel to realize that it could be applied to an issue he has long thought about: national security. From that realization, he co-founded Palantir, which has since grown into a 20-billion-dollar company.

4. Iterate with light-weight mechanisms before final implementation

Creativity requires cycling lots of ideas. The more you invest in your prototype and the closer to “final” it is, the harder it is to let go of a concept that’s not working. — David Kelley, founder of IDEO and Stanford University d.school
While persistence is necessary, one also has to be strategic. Gaudí chose to repeat his experiments on his 3-D model because it had a short iteration cycle. After deciding on a particular configuration, he would draw out the final specifications for people to build the physical architecture as he methodically moved on to the next part of the project.

Software engineering is no different. We start with an initial design. Then we build a prototype and iterate on it. After we settle on a solution, we finalize our code for release and move on to the next set of features.

I once had a project manager who insisted that we “get some code out” for the next phase of a project before requirements were gathered. His reason, besides to show progress, was that we “[were] going to have to refactor code anyway, so [we] might as well start writing code now.” I suggested that we hadn’t fully scoped out the next phase yet, so perhaps we should iterate on design while finalizing functional requirements. After some back-and-forth, we eventually agreed to start with design.

Imagine if one of Gaudí’s sponsors had said, “let’s start cutting stones and pile them up so we can show progress,” with no consideration of the basilica’s structural integrity. If any of the pieces were placed incorrectly — which likely would’ve happened without his models and experiments — it would have cost a lot more effort to revert those placements. Gaudí wisely chose to iterate with something easily modifiable — his 3-D models — before moving to physical construction, just as we do for building software.

5. Art is never finished

You can’t put a time limit on creativity. — Dr. Dre, American rapper & record producer
The yellow parts of the model reflect what has yet to be built. In 2015, it was estimated that 70% of the basilica was complete.

Leonardo Da Vinci once said, “Art is never finished, only abandoned.” When asked about the slow progress of the construction, Gaudí, a devout Catholic, responded, “My Client is not in a hurry.” When he passed away in 1926, less than 25% of the basilica was complete.

Although he was a perfectionist, he also knew when something was ready for general use. For example, when the elevation and altar sections of the Chapel of St. Joseph were completed in 1885, he opened it up for mass the next day. Since then, hundreds of millions have visited the basilica throughout its various construction stages.

Similarly, software is never truly complete. There are always more features to be built and more ways to serve users. It is critical to identify when something is ready to be released yet recognize that nothing is ever fully perfected. Case in point: even after Amazon took over online book sales, it continued to expand its offerings to improve user experience and is now the largest online retail company in the world.

Engineering and the arts are often seen as at opposite ends of the career spectrum. However, similarities may be more common than you think. If you find yourself slogging away at menial coding tasks every day, ask yourself: “Can I approach my tasks more holistically? Does my workplace provide an environment that has sufficient white space for me to color with my creativity?” If the answer is no, I leave you with a quote from Smallville: “You were meant for much more important things.”

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/