開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《強行遍曆法 SocialEngineeringDictionaryGenerator》
今日推薦英文原文:《Software Development Culture Is Too Positive — and It Might Hurt Us》
開源日報第1028期:《強行遍曆法 SocialEngineeringDictionaryGenerator》
今日推薦開源項目:《強行遍曆法 SocialEngineeringDictionaryGenerator》傳送門:項目鏈接
推薦理由:這個項目通過將個人信息進行各種排列組合來生成可能的密碼序列,再算上常用的弱密碼錶,沒準裡面就能猜中一個正確密碼。如果自己使用的密碼也在這些計算得出的可能性中的話,最好還是早點換密碼吧,使用隨機生成的密碼再怎麼說也比有跡可循的密碼要更安全一些。
今日推薦英文原文:《Software Development Culture Is Too Positive — and It Might Hurt Us》作者:Albert Kozłowski
原文鏈接:https://medium.com/better-programming/software-development-culture-is-too-positive-and-it-might-hurt-us-3ed24ac592d8
推薦理由:開發者熱愛編程,但沒有必要一直追求新事物或者把精力放在編程上,適合才是最好的

Software Development Culture Is Too Positive — and It Might Hurt Us

Anything that looks too optimistic comes with a hidden cost

It feels weird to write about something being too positive. However, I have started noticing that many software development problems might be caused by people being too positive and passionate. Let me explain.

Burnout

Isn』t it weird that so many young people are already feeling burnt out after a few years of work? I keep meeting people who need a break after just their first year or two. I』ve also experienced burnout myself (twice even). The first time, I had to take a six-month break. The second time, which was very recent, I needed a full year off before I could come back to programming.

This year, I』ve spent a lot of time with people outside tech and noticed one thing: We don』t complain much about our work. We complain about bad bosses and bad projects, but not about coding itself. We take passion for granted. Surprised? Go through job offers. Passion is often one of the must-haves listed on them. We are expected to love our job, and even more, we are expected to make programming the center of our universes.

But what about the people who do not love programming and still do their job all the same? Try to identify yourself as one of those among your colleagues or on Twitter, and you will immediately be dismissed as being a bad developer. However, is that really the case? People who do their job and try something different after working hours can be amazing programmers too. Not everyone needs to come home and work on side projects, create blog posts and YouTube videos about coding, and read programming books for fun.

I have been one of those people trying to work through all my spare time. For many years, I felt guilty if I didn』t spend all my waking time chasing some imaginary productivity goal — and guess where that landed me?

Shiny New Things

Another aspect that is heavily biased against negative feedback is following new trends originating from FAANG companies. Try to speak up against SOA or Docker. Try to propose using an older, more mature language and SSR. It』s similar to having a passion for work. People immediately conclude that you are not a good developer, as you are 「blocking the progress.」 Not everyone is running thousands of microservices like Uber and not every company needs K8S. However, it』s hard not to get on board — or at least pretend to be on board. How many organizations fail to migrate to React or Angular and are left with a code base split between the old 「bad」 code that was working and the new code that developers are still fighting to make work?

This recent article shows the reality in many organizations:I Almost Got Fired for Choosing React in Our Enterprise App(https://medium.com/better-programming/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c)

Best Practices

When I was a Technical Lead, I often heard the phrase 「because it is a good practice.」 I would then ask further questions and often noticed that the person didn』t quite understand the solution. It was my litmus test to know when to dig deeper.

How many of these 「universal」 best practices aren』t really universal? DRY (Don』t Repeat Yourself) is often said in the same sentence as KISS (Keep It Simple Stupid), yet they are often mutually exclusive practices. 「Simple」 means no unnecessary abstractions, yet starting with DRY code leads exactly to premature abstractions.

I personally use the rule of 3X:

「We have the delusion of reuse. Don』t feel bad. It』s an endemic disease among software developers. An occupational hazard, really.

It is three times as difficult to build reusable components as single-use components, and A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.」 — Coding Horror
Obviously, I don』t treat it as a maxim. It』s more of a rule of thumb than good practice. But even here, we are getting to the same problem. People who dare suggest using singleton or any other hated anti-patterns are perceived as less than stellar developers.

Summary

The expectation that real software developers, hackers, and geeks are defined by their vocation feels like being in some sort of RPG game. Your trade will forever define you, and once you choose this path, there is no way back.

We, as developers, are expected to love programming. But why? The simple truth is that it is good for employers. How many horror stories have come out of game dev? Yet many young people dream about working in the gaming industry only to be replaced by another batch of young, naive people after a few years.

We need to normalize people not 「loving」 to code, and we need to normalize having a healthy work-life balance in tech. We need people to be more open about their opinions, even if they are against the moment』s hype.

Don』t get me wrong, I really like being a software developer and I like programming. However, I am not sure if I love it being the center of my universe anymore.

I want to try other things, and that is absolutely OK.
下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/