In 2021, Don't Learn a New Programming Language
sushantsrivastava.substack.comMy own concept is rather simpler I would say: apply the 80-20 rule; that is, 80% of your time, use the tool set you know best that get you paid and the remainder 20%, invest it in learning things that interest you.
Of course, when it's off or weekend days, feel free to swap the rule to 80% learning and 20% to anything else you must do.
Obviously it's just a suggestion, not a mandatory task, but hey; whatever works for you, isn't that right?
What’s important at the end of the day is to improve and not stagnate.
This wasn’t what I expected, the bit about formal specification languages was really (pleasantly) surprising. I happen to have been spending a ton of time recently writing TLA+ and Alloy as the author mentioned. It’s completely changed my perspective on testing, definitely.
But the really surprising thing is how much they affected how I think about software overall. You know, at work I’m busy trying to build things. But taking a step back to understand what computation really is has been so helpful for even the code I’m writing on a daily basis.
Specifically with Alloy, which has an awesome state viewer, you can use it as a tool for prototyping ideas really quickly. It does suck that you can’t take that and use it to test your actual code, but I have ideas there :)
Anyway, yea I can’t recommend those tools enough. I think specification will grow in popularity soon - and no that doesn’t mean specifying your whole program up front. It’s totally possible to spec a program out iteratively. The value is huge - we write user stories and have product docs somewhere which explain what it is we’re building, but they get completely discarded after building. Having a highly simplified description of what a piece of software is expected to do is invaluable, especially as members come and go on the team. Agreed. In 2021, we don’t need another programming language. We need to master the tools and processes that we have.
I've heard the "fox plus hedgehog" idea before, as having a "T-shaped skill set". You have a familiarity with a range of related topics (this is the cap of the T) and deep understanding of a few things (the stem of the T). The premise is that this means you provide valuable expertise (for the deep part). But the breadth of basic knowledge means you are also able to collaborate and delegate well.
I've found that having other languages than my workaday ones in my repertoire is a valuable part of the cap of the T -- although it's certainly not the only kind of thing that should be there.
Also learning a new language, that is in some way related to the stuff you already know, is way less of a time comittment.
Learn stuff when it makes sense.
Two and a half years ago I felt stuck working with only dynamic languages most of my career so I started learning Rust. Now I have an extremely powerful tool in my belt that solves problems that most dynamic languages cannot solve [adequately].
But I'm not going to learn yet another dynamic language if that won't make me any money or expose me to a new way of thinking, no. Nor will I relearn C++.
Furthermore, if I make a comeback to JS then I'll prefer to learn TypeScript and pick the most productive tools for it (Parcel struck me as mostly getting out of the way).
I get the overall sentiment of the article even if it expresses it rather poorly.
It has a good point, though; many of us the programmers are rather capricious and spoiled and get distracted by new shinies -- as opposed to learning several skills deeply and be then very useful to the business we're serving.
We easily forget that we do what we do for money.
> We easily forget that we do what we do for money.
That is good. I do not want to remember Java and Kotlin.
Might be worth a revisit actually. After having kept off it for years I did a small project in Java for an interview some time ago, and a larger one as a postdoc a year before that. Its latest features, especially functional interfaces, makes it very powerful in a specific niche: The middle lands of software that does have stringent performance requirements - low latency from microseconds upwards and/or throughput, but not necessarily needing a cluster larger than some dozens of nodes. In such cases it is more productive than fully compiled system programming languages, while being much more performant than dynamic languages. Functional interfaces are a perfect match to do data centric designs in it.
I work in Java and Kotlin still. I miss doing OCaml. I miss writing C. I am trying to keep my sanity by doing Erlang[1] (gonna be our server for various purposes and I did not want to use Go because I thought it would be a great opportunity to perfect Erlang) and reading old books on Forth. I am also reading "Fundamentals of Embedded Software: Where C and Assembly Meet". For the foreseeable future I will do more designing and reading than implementing, but I will be toying around of course; for example right now I am doing hot upgrades and release handling in Erlang so I will not hesitate much due to ignorance when the time comes. This is just a minor part of it, of course.
In any case, Java, and especially Kotlin are quite tolerable with IntelliJ. It is a great IDE for those two at least. Plus I get paid, which is also a motivator... :D
[1] Truth be told, it is difficult to keep that sanity because I dislike the OTP documentation. I am reading books instead. I already know what their "target_system" does anyway, I modified it a lot for my use case but I reverted it because I thought it would be more of a hassle in the end.
I invite you to learn Elixir instead. Plus the forum is extremely welcoming and there are very easily digestible and much more carefully crafted docs compared to Erlang.
Plus, macros (basically, generators of code). How can you say no to that?
Well, you always have a choice. I branched out of lucrative careers... 3 times so far (so I am on the 4th full switch). And I still make more money than before.
I lack connections because I did not care about money and such before the age of 25. :/ Of course I also lack qualifications. I only have my code repository, and I can talk about the projects I made for some clients. In any case, it is quite difficult because I have lots of anxiety. I feel like I would fail or would not know enough.
I am 40 and I started caring about career and repouation less than a year ago.
You will always have something that you don't know. Took me a loooong time to get over it. Try and short-circuit this struggle because it would otherwise never end.
I do not know how to. :/ I can work for clients because it is different than working for a company, but... not enough money and not stable enough, sadly.
I don't understand. You don't want to work for companies?
I would like to, but there are too many people and it gives me lots of anxiety just to even think about going for an interview, let alone working for them. :/ Just tried to say that it is much easier when there is one person I work for and talk to online and working from home, vs. working in groups or meeting lots and lots of people. I have social phobia, and I also fear that I am not good enough and I do not even try because of it, it holds me back. I even fear working in groups of strangers online. I really do not know what to do. So I suppose I have performance anxiety (I do not know if there is such a thing), and I have social phobia.
I also have anxiety about my health when I notice something out of the place, but that is a different sort of issue. I remember when outside there were construction workers and beneath me the floor moved and I almost had a panic attack because of it. At first I did not know it was caused by them, I thought something was happening to me. It got better when I realized it was just them.
As a start, we are currently living in the best time ever for remote work. You can apply, have interview, homework assignments etc., all from your home.
Doesn't that make it a little better?
I get what you mean with performance anxiety -- my last job kind of ended because I felt a severe impostor syndrome. But eventually it turned out it wasn't only that; I was forced into rituals and ways of work I didn't enjoy so the job couldn't possibly work. Realizing this instantly made me feel better.
unfortunately the tech industry doesnt work this way. i have switched programming languages and this got me to a much better financial and career position. so again it depends
I'd planned on learning Rust this year, this article did little to convince me otherwise.
After learning Rust 5-6 years ago, I haven't felt a need to learn anything else (before that I was learning / trying out a language or two a year).
Let this be a warning.
More concretely learn how to write specs in Gherkin/Cucumber and back them with TLA+ and Alloy before you code. Remember the speed of light (about 1 ns per foot) and annotate those specs with best case data travel latency.
Use holistic profiling like https://twitter.com/OptimyzeCloud/status/1351203905850519557
When you see performance issues then dig into your language stack and learn how to remediate them.