今日推荐开源项目：《Web-Dev-For-Beginners》
今日推荐英文原文：《The Best Engineering Advice I Ever Got: “I Don’t Really Care, Just Make it Work”》
今日推荐开源项目：《Web-Dev-For-Beginners》传送门：项目链接
推荐理由：这个项目是微软的 web 开发教程，包含了推荐的视频与文字教程，每一节课程都提供了课前与课后的问题与任务等等，而且教学内容是从编程语言的基础开始介绍的，也可以推荐给没有接触过编程的人，唯一需要的就是英语阅读能力了。
今日推荐英文原文：《The Best Engineering Advice I Ever Got: “I Don’t Really Care, Just Make it Work”》作者：Zack Shapiro
原文链接：https://medium.com/better-programming/the-best-engineering-advice-i-ever-got-i-dont-really-care-just-make-it-work-2e238f0cf908
推荐理由：不是需要学习的时候，就没必要太追求细节什么的了
The Best Engineering Advice I Ever Got: “I Don’t Really Care, Just Make it Work”
Stop lettings “shoulds,” academics, and random blog posts stop you and your team from shipping
I used to work under a very academic tech lead. When he wasn’t re-writing features that had been done for days or weeks to make them more perfect — from a code and file organization perspective — he was reading blog posts about design patterns and how things should be in your codebase.It had been three months since the date we were supposed to ship the first version of our app and we still didn’t have anything out. While the other members our of team were busy building and shipping features for v1, he was writing and rewriting, futzing with the file structure, and trying to get everything to be perfect. Eventually our CTO got wind of this as week after week would pass and the app still wasn’t out.
After the app shipped, our tech lead left the company, and I got promoted into his position. Then something weird happened:
My initial inclination was to continue the tradition. Not the rewriting, but the perfectionism.
Not long after, I was building a single sign on feature for our enterprise clients and I started waffling back and forth about the “best” way to write a very small function and where that should live. It was probably 5 lines, max.
Should it be a free function? Should it be in its own file or co-mingled with the other single sign on code?
Should it be a class with a single exposed function?
Since it was so small, could should I just attach it to another part of the single sign on work and not worry about it living on its own?
His mindset had become mine and I was paralyzed by decisions that had little-to-no real world consequence and made no difference to the people paying our company lots of money.
I walked over to our VP of Engineering to determine what the best thing was to do with this little function. I was prepared to have a similar discussion with him as I’d had countless times with our previous tech lead,
v
v Instead, the conversation was brief. His response, which forever changed how I worked and thought about code was,
“I don’t really care, just make it work.”I felt free.
I was the tech lead, after all! This was my team!
We’d all disliked the previous style of academic and blog post-driven perfectionism. Why was I continuing to worry about if our code matched how someone outside of our team said things should be done.
These trends change over time. Believe me, I’m the Editor of Better Programming ?. The blog post was helpful in theory but ultimately inconsequential to the business.
We just had to ship.
It changed how I led the team, from that conversation, onward.
“Make a note, let’s revisit it after we ship” became my go to line. We all knew what we had to do. We’d build the feature, QA it, fix any bugs, then call it done and move onto the next feature. Somewhere was that list, safely tucked away, things for us to revisit down the road.
After we shipped, nothing disastrous happened because our code wasn’t perfect.
The procrastination was fear, disguised. It took that short conversation with my VP to make me realize that.It’s absolutely okay to have agreed upon standards in your codebase and best practices for your team and for your company. If your team is moving slower because everyone on the team needs to have their code filtered into the particular style or preferences of a certain, strongly opinionated engineer, it’s going to take you a lot longer to ship everything.
So whether you’re learning to code and reading this or you’re deeper into your engineering career, spend more time getting things to work and less time obsessing about the shoulds of engineering.
Makes sure your code is secure, reliable, and relatively efficient. But remember: your code is most likely not (yet) operating at a scale where an inefficiency is going to cost your business significant money. So it doesn’t matter! Just make it work.
As you scale, you’ll rewrite that code to make it better. Revisit that after you ship.
It’s far more likely that your code not shipping is going to cost the business more instead.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
