今日推薦開源項目：《Sexy terminals-are-sexy》
今日推薦英文原文：《Keep your Ego away from coding》
今日推薦開源項目：《Sexy terminals-are-sexy》傳送門：GitHub鏈接
推薦理由：為命令行愛好者準備的資源合集——包括用得上的工具插件以及一些仿命令行的模擬器。相對於命令行來說，初心者似乎更偏向圖形界面，但是熟練使用命令行的生產力並不會輸給圖形界面——最明顯的一點就是你不需要把注意力從鍵盤和屏幕上移開轉向滑鼠，而諸如使用資料庫的時候命令行甚至比圖形界面更為優秀，因此學會熟練的操作命令行可以說是增強生產力的必要選擇。
今日推薦英文原文：《Keep your Ego away from coding》作者：Davide de Paolis
原文鏈接：https://hackernoon.com/keep-your-ego-away-from-coding-749b41cfc57d
推薦理由：實際效率比感覺更重要——所以別在一些差不多的選項上浪費所有人的時間，直接拿出數據證明更有效
Keep your Ego away from coding
Have you ever been in a meeting where two — or more — devs were arguing about — mostly — irrelevant technical issues?Have you ever felt upset after a colleague rejected your Pull Request or criticized your solution during a Code Design session?
How many endless heated threads have you read in blog posts or StackOverflow questions over this or that better approach?
If you have been a developer for enough time, you will definitely have experienced all of the above.
Why? Why are we — as developers — so attached to our code? Why do we have this incessant need to prove ourselves right?
- Ava or Mocha?
- React or Vue?
- Webpack or Parcel
- Express or Hapi?
- Visual Studio or Intellij IDEA (or VIM)?
- AWS SAM or Serverless framework?
Some solutions must definitely be evaluated before starting a new project, but this evaluation must be based on data, on the requirements from the client and on the possible limitations from the tool, not on personal preferences or taste.
Of course previous experience can be decisive in the choice, as costs are ( using IntelliJ requires a license while Visual studio does not; having a team learn a new stack requires time and therefore money)
Only because you know a tool better does not mean that tool is better than others on the market.
In the end, the client, or the user does not care if the Web app was built with the latest coolest js tech stack or in .net as long as it works, is fast and it is looking good.
The problem you solve is more important than the code you write
Over the years I got more and more detached from some tech decisions. Especially the minor ones regarding which linter, test framework or bundler. The battle is mostly based on opinions.It is always conservatives vs hyped — as long as it works and I am good at it, stick to it versus newer is always better.
I like to try new things and I love to learn always some stuff, but we also have to deliver and we cannot always switch framework, language at every project — wasting time, energy and money.
This is not that I don』t have discussions over technical topics. I do. Some of them can also become quite heated. But it is never about who is right or wrong.
Actually, I very like to be proven wrong, because that means that I was making a mistake, or that I could simply do something better and learn something.
In the end it does not matter who is right, what matter is that the solution is right, whoever it belongs. and it does not even have to be the BEST one.
The point is:
- opinions do not matter unless supported by facts and data
- best is the enemy of good and often what you (and ultimately — the client) need is not the optimal solution, but a solution that suits the requirements and the time/money constraints.
The discussion is about the code — the technology and the solution, not about you. it´s not about how cool you are, how expert you are.
Leave your ego aside, detach emotionally from your creature, embrace change, accept critics, learn from every experience.
Emotionally detach from your code.
Being emotionally detached from your code does not mean become sloppy or uninterested in what you do. Don´t emotionally detach from your work.Focus on the outcome.
If you put too much pride in your code poetry, if you think your implementation it´s the only possible solution and that is perfect and therefore you are a good developer and a smart person, of course you will fell attacked — personally attacked if someone criticizes it, or suggests something different. Let alone how you could feel if you are clearly proven wrong.
If you remain humble and leave ego out of your code, you might just incur into some frustration :
damn, why didn』t I realize that issue? why did that solution not popped in my mind? I feel ashamed that I have wasted hours or weeks of work, it´s a bit annoying that I have to rework the same stuff over..
We all went through this. It is OK.
Conversations are not competitions.
Just because someone else is right doesn』t mean that you are wrong. An opinion that differs from yours is not an attack on your rightness.
Sometimes the solution proposed is actually the right one and the best, but it could be advisable to choose a less optimal one if it respects the requisites and way less effort.
On this matter I changed my mind a lot over the years.
Before I was one of those devs always fighting for the best design, it had to have all the right design patterns in place, dependency injection, interfaces, it had to be future proof and flexible for future implementations and changes in requirements.
Then I saw that those further implementations never came or that despite all the complexity and the flexibility, the new requirements often managed to break the design anyway.
So I slowly moved away from that stance, and embraced a simpler — not easier — approach. Flexible but more focused on what must be now, not on what could be.
As a good software engineer I try to anticipate issues of course, but I am not obsessing anymore on writing everything super abstract to be ready for future changes.
Focus on delivering value, not on proving that you are the best
Fundamentalism is never good, it is not in religion and it is not in tech. Flexibility is more important. You gotta know the rules, and you gotta know when to break them.Always remember that code can be modified, code can be improved, code can be deleted.
You cannot know everything, there is always something you can or have to learn, you are not perfect, there will always be someone better than you. ( and if not. maybe you are in the wrong team, probably you should move on, you should never be the smartest person in the room)
All this is OK. All this does not lower you. On the contrary, it must be seen as something positive and challenging.
- Write code with pride but with humility.
- Put all your passion in your work, but leave your ego out.
- Be great but be grateful.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
