今日推薦開源項目：《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/
