Sadly 99% of the code that's written nowadays can be directly thrown away. I propose another challenge: Learn the actual meaningful stuff. E.g. how to code in lisp. Really learn it. You will never code lisp in your job. Promised. But in almost every task you will find that you reuse what you learned.
Or learn the architecture of git. How many people write bullshit around git because they don't understand that git can already do 100x of what their shell script or UI tool or plugin can do....
Don't waste your time with what is hip and instead learn how things really work. Real things. Don't learn the latest javascript framework, but learn the difference between class based inheritance and prototypal inheritance. Don't learn the hippest UI IDE, learn vim or emacs. Really learn it, e.g. how to solve almost all problems in vim without any plugins.
And one last point about "read all the content your team created". Not sure how big your teams are, but in many companies that's impossible. If you spend 12h of reading 7 days a week you can't read all the content that is created in that week. But you know that the cool_library that replaces the AwesomeLibrary is just as bad at solving the problem and both actually don't even know what the problem is.
Wouldn't that apply to git? You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning. Life is too short to spend learning the internals of one version control system.
This idea of "Don't waste time on X focus on more valuable Y" has no real end. Don't waste your non-work time on learning computing related stuff and instead spend time on social connections and physical fitness first. Pays off way more than emacs, git, vim, lisp, or programming paradigms. See how easy it is to make such pronouncements?
> You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning.
You absolutely cannot.
Even if we pretend that Mercurial is simply outright better than Git, there's a lot of value in learning Git specifically, as it's what most development teams use. Employers value proficiency in Git. If you mention your Mercurial proficiency in an interview, it's likely to be scored up as cute but irrelevant.
If you always work alone, sure, Mercurial might work great for you, but the real value of these version-control systems is in enabling teams to work effectively. Most teams these days use Git, so you need to know Git.
(Of course, if your team does use Mercurial, you'd better become proficient in Mercurial.)
> Life is too short to spend learning the internals of one version control system.
I agree that learning the intimate internals of Git's codebase isn't something that's likely to pay off in the day job, but short of that, Git's 'useful skill-ceiling' is pretty high.
> Don't waste your non-work time on learning computing related stuff and instead spend time on social connections and physical fitness first.
Depends on your working situation. If your work offers no opportunity to learn new skills, and you don't want your CV to get stale, you have little choice.
>there's a lot of value in learning Git specifically, as it's what most development teams use. Employers value proficiency in Git. If you mention your Mercurial proficiency in an interview, it's likely to be scored up as cute but irrelevant.
Given that the person I was responding to was advocating not spending time on things for the reason that employers are looking for them, and is advocating things almost no workplace uses, I find your comment strange. Perhaps you should be responding to the comment I'm responding to?
>Depends on your working situation. If your work offers no opportunity to learn new skills, and you don't want your CV to get stale, you have little choice.
You do have a choice, and you made your choice. In the US, in this era, SW professionals are near the top when it comes to freedom to change jobs and change locations. When I know several people who make half of what I do, are relatively unskilled, and have to work much longer hours than I do, who made a very clear choice in favor of physical fitness and social relations, I am not going to claim I don't have a choice.
Having said that, this is all orthogonal to my point, which was how easy it is to make (reasonable) lists of things one should focus on that are almost exclusive to one another.
After programming for 50 years and having a successful career, I’m not really going to need serious git skills. I still write code, all the time, but it’s for fun and personal projects.
Yes Mercurial is easier to use than git, and really fossil is even better for me, someone that works solo. However git is what I use. I know that if I am going to help someone with source code control (like my daughter who is studying CS) git is what they will need help with. Personal use of git is to me the only way to ensure that I can give pertinent help.
> Wouldn't that apply to git? You can probably get 90-95% of the benefit of git using mercurial with a fraction of the effort in learning. Life is too short to spend learning the internals of one version control system.
I haven't used mercurial much, but it seems like you would have to understand the same amount about the core data structures to do something in mercurial as with git [0]. The really simple activities you do day to day don't require any deep knowledge. And when you want to do more complicated things you have to know what you are doing.
Its similar to writing simple C++ programs vs complex ones. You may not need to understand smart pointers to write small programs, but understanding smart pointers or at least the concepts behind them is critical to write large programs.
[0]: There are minor differences between the two that probably make git harder to pick up. Among them being the staging area, and rather obtuse UI. However, the market effects of git are hard to ignore.
Social connections and physical health are also such multipliers, just as vim or git or lisp. If you have been asocial and unhealthy in the past and now were able to change you will also experience this increase in output, e.g. because you can suddenly ask others for help and can focus for longer periods of time. Maybe you will even come into less situations where you use git and vim and programming languages, because others also value your ability to focus and your connections more than your ability to produce code. Then it paid of even more to focus on these multipliers. Great.
That doesn't mean either of the other multipliers are not multipliers though. They are just more topic-focussed instead of generally applicable.
And no, mercurial can't do more than 5% of what git can. That's just a fact. Just like you probably wouldn't waste time explaining a flat earther why the earth is round I won't explain this to you. If you are smart (and I assume so from your comment) you will go out and fact check that by yourself from the assumption that you just might be mistaken and maybe this random dude on the net might've been correct.
Hope I'm right in that assumption. Then you'll have an awesome time of a lot of WOWs ahead of you. Enjoy it.
And if not, there's not much lost. Some humans will fly to Mars even if some others believe the Earth is a disk.
One thing that life tought me is that you can be the best dev in the company but still your boss is going to give the promotion to one of his buddies he likes.
Personal connections and social engineering is 10times as important as your actual skills.
Its unfortunate looking at current state of the world, but thats how it simply is. And I understand some may not agree with it, but please look around yourself and tell me Im wrong..
While it's nice you're agreeing with me, I did not suggest it as a way to improve your career, and my advice stands even if it has no chance of helping your career.
>If you are smart (and I assume so from your comment) you will go out and fact check that
Exactly how do I fact check this? Most Google searches give two types of results: Either pro git or meh they're mostly the same. Virtually every pro git page has basic facts wrong about mercurial and are criticizing the mercurial of a decade or longer ago(0) The very few exceptions cover use cases that really do fall into the 5% category.
And I assume you meant 95% and not 5% that you wrote. If you really did mean the latter I suspect you know little of mercurial.
(0) Branches are a classic example. Although I do think git has slightly better branch handling pretty much most pages criticizing mercurial branches expose their ignorance of beaching in mercurial
I'd argue they got it right: when 95% of projects use Git, then why learn anything else? I think the last time I used Mercurial was almost a decade ago at this point, and I don't know of any major project that uses it (outside of Mozilla, who has most of their newer projects are on GitHub, and OpenJDK, which maintains a GitHub mirror).
That is ignoring my point with a deflection. This isn’t 1999 with Linux as a (relative) newcomer and on the upswing, the adoption rate has clearly dropped over time. I did miss the fact that Facebook uses Mercurial internally, but their public-facing repos are all on Github (including, ironically, their re-implementation of Mercurial, Mononoke). Open Source software doesn’t exist in a vacuum, it needs a community to support it and use it.
All sorts, but I believe it was born out of frustration at unnecessary complexity arising from standard enterprise development.
Hickey’s choice of hosting it on the JVM was ingenious, gives access to one of the largest most battle tested ecosystems in modern day enterprise engineering.
It’s much more versatile these days with the likes of ClojureScript, it’s being used in anything from real-time multimedia projects to SPA JavaScript work.
Basically anything other than operating systems. I've been working on an optimizing compiler for spreadsheets, and an event sourcing system with a WebSocket gateway in my current work.
Great to read that. I also know one other person who writes Clojure professionally. Gives clojure to some of who hoped for people to get this opportunity at some point.
There are also rock stars, but that doesn't mean we should give advise that anyone could become a rock star. Those who will become rock stars will become it anyway even if you tell them they won't.
I code in lisp for work everyday! This is a bad promise, but I agree lisp is amazing. I've recently been learning to love macros and reading let over lambda is fantastic!
While I agree in principle, this is a nice way to quickly become unemployed.
We live in a hype oriented industry, where momentum and programmer enthusiasm (free man hours or work) and not technical merits predict whether a given technology will thrive or not.
> Don't learn the hippest UI IDE, learn vim or emacs.
This jars. Why not recommend really learning Cocoa and AppleScript or VB for Applications? Or really dig into Smalltalk's code browser? vi and emacs have a long track record, and I still use both because I sank the time in to learn them years ago, but I wouldn't recommend them as fundamentally changing someone's view of computing.
Or learn the architecture of git. How many people write bullshit around git because they don't understand that git can already do 100x of what their shell script or UI tool or plugin can do....
Don't waste your time with what is hip and instead learn how things really work. Real things. Don't learn the latest javascript framework, but learn the difference between class based inheritance and prototypal inheritance. Don't learn the hippest UI IDE, learn vim or emacs. Really learn it, e.g. how to solve almost all problems in vim without any plugins.
And one last point about "read all the content your team created". Not sure how big your teams are, but in many companies that's impossible. If you spend 12h of reading 7 days a week you can't read all the content that is created in that week. But you know that the cool_library that replaces the AwesomeLibrary is just as bad at solving the problem and both actually don't even know what the problem is.