今日推荐开源项目：《黑历史大扫除 DeleteFB》
今日推荐英文原文：《On Specialism vs. Generalism》
今日推荐开源项目：《黑历史大扫除 DeleteFB》传送门：GitHub链接
推荐理由：今天你终于要开始工作了，你决定给公司里的同事们留下个可靠的好印象，然后你很快注意到了自己用了很久的那个脸书帐号——里面有些东西你自己看了都想掘地三尺把自己埋掉，更何况新同事，那会让他们对你印象崩坏的。这个项目就能够帮你清扫账户里你写过的一切而不需要删除你的账户，虽然脸书可能已经把它们都已经备份了，但是不管怎样，最起码你不需要担心有人看到那些黑历史了。
今日推荐英文原文：《On Specialism vs. Generalism》作者：Bryan Irace
原文链接：https://medium.com/better-programming/on-specialism-vs-generalism-and-not-being-an-ios-engineer-anymore-ed5fa65ed76e
推荐理由：专家与多面手同样重要——一个在某个方面拥有丰富的知识，而另一个则拥有更广泛的视野。
On Specialism vs. Generalism
Dealing with “not being an iOS engineer anymore”
“You’re basically not going to be an iOS engineer anymore?”When my good friend Soroush asked this upon hearing that I had taken a new job at Stripe, I doubt he thought very much about how it’d be received. However, it really threw me for a loop. I didn’t exactly consider myself to be undergoing a career change, but was I? It’s true that I’m not going to be developing for iOS in my new role, but I hadn’t always worked in this capacity at previous jobs either. Did spending the better part of five years focused on iOS make me an “iOS engineer”? If so, when exactly did I become one and when did I subsequently cease to be? Is the designation based on one’s actual day-to-day or describing the work being primarily sought out and anticipated?
When you work as a software engineer long enough, it’s highly likely that you’ll end up having to decide whether or not to specialize in a particular sub-discipline or work in a broader role with general knowledge spanning several disciplines. There’s no right or wrong decision here, and it’s really not a strict dichotomy anyway.
While programmers can undeniably be either specialists or generalists, there’s a whole lot of grey in the middle. As opposed to inherently being a specialist, it’s also very common to specialize over a period of time. Perhaps this is a subtle difference, but I think it’s one worth teasing apart; one can act in a specialist capacity when the situation dictates — and I presume that effectively every “generalist” does, from time to time — without self-identifying as such for the long haul.
There isn’t a right answer because one isn’t better than the other, but also because many teams should contain both specialists and generalists in order to perform their best work. The best products are often brought to fruition through a combination of generalist thinking and specialist expertise.
Specialists with the domain knowledge necessary to build best-in-breed software that takes full advantage of the platform being built for are tremendous assets to any team. Given how advanced platforms have become, it’d be near impossible to have a firm grasp on all the details without having first dedicated yourself to fundamentally understanding a particular platform’s intricacies.
At the same time, specialists run the risk of “only having a hammer,” and as such, having every possible project “look like a nail.” With only one tool in your belt — a deep but relatively narrow area of expertise — it’s easy to inadvertently build an app that really should’ve been a website or vice versa. Or to have a great idea that you can’t quite realize, despite your excitement, due to it requiring both frontend and backend work. Said idea might be exactly the provocation that can prompt one who has historically specialized to start branching out a bit. But after having done so, are they still “a frontend developer” or “a backend developer”? Clearly, such labels start to lose their significance as we tear down the boundaries defining what we’re able to do, and perhaps more importantly, what we’re interested in doing.
In the Twitter, Slack, and GitHub circles that modern software developers often travel in, it’s easy for a discrepancy to form between how one is best known vs. how they actually view themselves. Tumblr was quite popular during the time that I led iOS development there, which gave me the opportunity to write and speak about the work that we were doing, and even release some of it as open source. These slide decks and blog posts neglected to mention that I was actually hired to be a web developer and only moved over to iOS as needs arose, subsequently parking myself there for the next few years. I built Rails backends and React frontends at my next job, but at an early-stage company with a much smaller platform, where we primarily worked heads-down without much outward-facing evangelism for our technology.
I’m not unique in this regard. One of the best mobile developers from my time at Tumblr has since switched over to the web. Another, a specialist in animations, gestures, and UI performance, is now a designer. Acting as a specialist at a high-profile company can cement your status as such well after you’ve stopped working in that capacity, it’s crucial not to let outside perception prevent you from shaping your career however you see fit.
In August 2014, I gave a talk entitled Don’t be “an Objective-C” or “a Swift Developer” to a room full of new programmers who were learning how to build iOS applications at the Flatiron School. The Swift programming language had been unveiled only two months prior, and reactions amongst iOS developers were divisive, to say the least. Many felt as though it was finally time for a modern language to replace Objective-C, and that such a change was long overdue, while others didn’t believe that Objective-C needed fixing, and would’ve preferred if Apple’s resources and the focus of its community were directed elsewhere. My goal was to try and convince these new engineers that they shouldn’t aspire to land in one camp or the other, but rather to learn the underlying, transferrable programming concepts, and to expose themselves to many different ways of concretely building software. Without understanding what’s out there, how can one make an informed decision as to how they should spend their time? Even if you decide to put down roots in a single community, how can you avoid perceiving the way that that community has historically operated as being the way that it should be going forward?
I feel like I could give this same talk today to a set of engineers and simply replace “Objective-C and Swift” with “frontend and backend” or “mobile and web.” The idea is the same — technologies move fast and careers are long, and while you may enjoy being a specialist or a generalist for some time, you never really know when your situation could change and when circumstances may warrant otherwise. Or, when you might simply feel like trying something new.
When I write Ruby, it’s painfully obvious to me that I don’t know Ruby to nearly the same extent that I know Swift. On some days, this makes me sad, but it just as often makes me feel empowered. Perhaps I’ll decide to spend the time needed to achieve Ruby mastery, or maybe I’ll end up retreating back to Swift at some point in the future. More realistically, I’ll get slightly better at the former and slightly worse at the latter and come to peace with that, just in time to shift towards learning something different altogether. In any case, how others describe what I do, and more importantly, how I view it myself, remains a fluid work in progress.
I don’t expect this to change, and this I am at peace with.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
