12 ms·

How to rapidly improve at any programming language (2016)

468 points by jcubic 5y ago

black_13 5y ago
Being good at anything or anything in demand doesn’t translate into an income.
rStar 5y ago
i play guitar every morning in my free time. work is for work. you’re a good enough programmer already. enjoy yourself.
- redeux 5y ago
  For some coding is a craft and a job. Just as I would expect a professional musician to enjoy growing in their craft and learning from their peers, so do people in other areas of life, including programming.
  - _hilro 5y ago
    Do it on company time.
    - WJW 5y ago
      If you enjoy programming for its own sake, why not improve your skills in it both on and off company time?
      - JanisL 5y ago
        Depending on workload you will need to watch very carefully for burnout and other mental exhaustion issues if you do this.
- parafactual 5y ago
  Not all of us are professional programmers, and especially not all of us are only professional programmers.
  - autoliteInline 5y ago
    For me, programming for free would be painful at a cellular level. Better to learn the piano or how to do portrait art.
- teddyh 5y ago
  Programming constantly changes and evolves. Does your employer allow you to use your work time to read journals and educate yourself on modern developments? If not, you’d better do it in your own time if you want to avoid being stuck in the past.
  - tayo42 5y ago
    You read journals about programming? Like research papers?
  - Igelau 5y ago
    If your employer doesn't allot some time for you to do just that, ask them to, or find one that will.
- nkrisc 5y ago
  And my work is not programming so coding in the morning for me is the same as you playing guitar.
- schwartzworld 5y ago
  Eh, I was a hobbyist before being a pro. I love coding at home, I just won't do the same thing I do at work.
darkbatman 5y ago
If someone need my suggestion, here is what you do - try doing different sort of questions (multiple topics too) on leetcode from different topics may be just 20-30 in language you want to learn. Its different way but you will learn a lot of new libraries, ways to mutate objects, lists, all sort of data structures and new things really really fast.
- raman162 5y ago
  I've only done a few leet code questions but only in languages that I'm comfortable with. Even then, I've had similar experiences to the author mentions where I've gotten different perspective on how to approach certain problems.
- xondono 5y ago
  I’ve tried a lot of those, even contributed to exercism. I think it has it’s uses, but you can only extract value from those exercises once you know enough about a language. For me those exercises are more about developing muscle memory than really learning a language. OPs idea is good, but I think fails in the same way. I don’t think you’ll get much value out of reading PRs until you have certain familiarity. No amount of PRs will teach you what a monad is, you need to dive deep and conceptually understand the model(at least IMO).
- nostrademons 5y ago
  Leetcode is leetcode. It's its own skillset within software engineering, one you often need to get a job, but it bears pretty little resemblance to any of the skills you need to deliver working, functional software that solves a user's problem. Practicing it will help you get better at it, which may help you land a job where you can practice all the other skills, but don't confuse leetcode with proficiency in software development. Among other differences, leetcode teaches you little about reading large unfamiliar codebases; debugging; organizing large software-engineering projects; working in teams; teasing out actual requirements; making incremental progress; real-world performance (and the tools you need to identify bottlenecks); and most of the libraries and frameworks that are common industry knowledge.
  - 5y ago
raman162 5y ago
I never thought about reviewing existing open source project PRs to get better at a language. It seems so obvious considering it's similar to how I get ramped up with new projects. > 2. When you want to level up, start reading the diff, and review the code and changes yourself before reading the comments. > 3. Finally, when you start feeling more confident, start leaving those comments on new PRs so that the maintainer doesn’t have to. You’re starting to contribute to open source! The steps from two to three are pretty dramatic, I personally would replace step 3 with tackling an open issue related to code you reviewed before. I feel like to give feedback on a PR you need to be intimately familiar with the code, something you get from writing and/or making changes to it.
- wyclif 5y ago
  I thought about doing this, but the difficulty for me is finding the projects that are going to be optimal for learning the language.
rob74 5y ago
In the spirit of this, the Go project has a "common code review comments" document (https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki/CodeReviewComments) - topics that come up frequently when reviewing pull requests. Reading these can certainly help you get better at writing (idiomatic) Go...
deleted 5y ago
[deleted]
aloisdg 5y ago
My own take, to improve at any programming language, use them to build actual small project. The smaller the better. Something familiar. Something easy. A library to convert celsius to fahrenheit. A webapp to count the day until Halloween. This kind of useless-ish stuff. My last example is to add a state machine with xstate to a project fetching some data and formatting a nice output. Do I need a state machine? Not really, but it is a good way to learn it. btw, the goal of the project is to smooth attribution to stack overflow's answer. I just started it, sorry for any bug. the app: https://stacktribution.vercel.app/ https://stacktribution.vercel.app/ the code: https://github.com/aloisdg/Stacktribution https://github.com/aloisdg/Stacktribution
- ducharmdev 5y ago
  I did something similar to learn Go & gRPC. I had a python client for displaying a simple COVID-19 report with the option to export as CSV, and had a Go server that sent a request to a public API to collect the data for the report. Did I need gRPC or the Go server? Not really, but when you're learning something new, there's a certain psychological benefit to being able to finish something using the technology you're learning. That, and you can focus more on the learning part instead of getting sidetracked by the other details of a larger project.
- 2OEH8eoCRo0 5y ago
  This is basically what they say in SICP. Write programs. That's it. It could be small projects or it could be well-known puzzles you already know. Fibonacci- iterative and recursive, fizz buzz, sudoku puzzle solver, 8 queens, etc. Storytime: I would work at site when I worked in defense and do 15 hour days. I could sit there and monitor, as the job required, but I was also learning Perl for the job. I had no Internet so I spent all my time writing tools and reimplementing every programming puzzle that I could think of in Perl. In very short time I became the go-to "Perl" guy even though all the "toys" I made in spare time were "stupid and useless" according to coworkers.
- giovannibonetti 5y ago
  Instead of using a library for state machines, have you thought about trying a language [1] that does that in a type safe way, with a compiler that has your back if you forget to deal with a state? [1] https://elm-lang.org https://elm-lang.org
adamnemecek 5y ago
Also reading the source code for the standard library can be illuminating. Note that some languages have pretty subpar standard libraries. This might have changed but ~10 years ago the Ruby standard library really left some things to be desired. I don't recall the details but I wasn't a fan of parts of it. On the other hand, the Rust standard library is top notch.
- einpoklum 5y ago
  > Also reading the source code for the standard library can be illuminating. That's a lot more hit-and-miss. On one end of the spectrum, you have Java, where all of the lower-level, nitty-gritty work happens within the JVM anyway; and on the other end of the spectrum you have C++, where it's "turtles all the way down" almost, with lots of repetitiveness, ugly hacks to within the library to help the user avoid ugly hacks in their code, a big bunch of preprocessor macro definition checks for meeting innumerable compatibility requirements for different versions of the language standard on different platforms, and so on. Yes, you will learn from it, but it will be painful.
rafaelvasco 5y ago
Two things I did and always do: Code things that solve real problems you want to solve. The harder the problem, the better you'll get in the language and as a programmer in general. Second, look at existing open source, well written code that, again, solves a problem you're interested in. I always emphasize this: Things you're passionate about. That way you can master any language/framework. By master here, I mean you can code anything you want in the technology efficiently. Your final app will be: Easy to modify/enhance, easy to understand in terms of code. Memory and CPU efficient in terms of runtime.
- nonima 5y ago
  >Code things that solve real problems you want to solve. Everyone says that but I can't think of any real problems I personally have that I could solve using programming.
  - rafaelvasco 5y ago
    Nothing ? Maybe a website that you wanted to exist but there's nothing quite like it ? An app, a game... Its not only about solving problems exactly but about having a vision and wanting to turn it into reality.
tienthanh8490 5y ago
Nice advice. I always hear people suggest building some projects to learn the language, but I doubt if it's realistic given other constraints in life (I also tried it but the initial excitement wears off pretty quickly). In the end, knowledge can come from anywhere, we just have to find the right source.
zarzavat 5y ago
My hack to improve at a new programming language is to read its grammar. We instinctively try to learn programming languages the same way as we would a natural language, bottom up. But unlike natural languages, programming languages have complete grammars that can be read in a session. This will prime you with the right questions to ask ("WTF is an XYZ?"). Doesn't work for Clojure though :)
- wrycoder 5y ago
  Not really for Python, either.
  - d0mine 5y ago
    You can definitely read it https://docs.python.org/3/reference/grammar.html https://docs.python.org/3/reference/grammar.html Though I found it useful only to answer narrow specific questions.
- dgb23 5y ago
  For Clojure what helped me was starting to read the source. Typically core lib first and then the Java implementation of certain constructs. For me it helps tremendously to see how the sausage is made.
- toomanydoubts 5y ago
  Not sure if this is what you're talking about, but there's https://learnxinyminutes.com https://learnxinyminutes.com. It's really awesome when getting started with a new language. If you're an experienced programmer, you can get to a newbie-but-ready-to-write-some-code level after a 15 minute reading on a new language.
bradneuberg 5y ago
Does anyone know good open source projects that are using modern c++ (c++ 11 to 17 techniques) that I can study and possibly contribute to to get better at c++?
- ensiferum 5y ago
  Well since you asked...a 2D game engine https://github.com/ensisoft/gamestudio https://github.com/ensisoft/gamestudio
eyelidlessness 5y ago
The is a great suggestion. I’ve also learned a lot just from reading the already-merged code of projects I’m interested in, and stepping through git history to see how it evolved. I even frequently do this on my phone when I want time away from the desk. For instance I’ve been super interested in SolidJS[1] for months. I learned from reading the source that a lot of the work is done by its underlying dom-expressions[2] compiler. And in reading its source, I learned enough about JS AST transformation that, when I had a need to do some AST transforms of my own for work, I knew enough to confidently timebox a proof of concept to two hours (and actually finished the work in that time!). All from reading code casually on my phone. Sure, I front-loaded a lot of that work in my free time. But I did it because I was genuinely interested in the project I was learning from. 1: https://www.solidjs.com/ https://www.solidjs.com/ 2: https://github.com/ryansolid/dom-expressions https://github.com/ryansolid/dom-expressions
greggman3 5y ago
A lot of people seem to be saying "build a small project" and I'm not saying that doesn't work but...., but, something I've experienced a lot is that people stick to their old ways, myself included. As a C/C++ programmer I used to hate JavaScript (pre ES5). I didn't like it's function based scoping system. I didn't like it's prototype based class system. I loathed using it and wrote as little as possible, only enough to make a small WebGL demo or add a tiny feature to my blog. I was basically trying to use JavaScript as C/C++ and hating it. At some point though I flipped. I actually started using JavaScript and playing to its features. I embraced prototypical inheritance and all the ways it's more flexible than class based. I embraced JavaScript's dynamic typing using, where appropriate, the ability to easy wrap APIs, to write more generic and flexible code. I also really loved closures and building functions that closed over data, something that, at the time, C/C++ didn't have. I also really enjoyed that, at least in the browser, JavaScript is bundled with a lot of CROSS PLATFORM functionality (graphics, GPU access, audio, video, networking, UI) that pretty much no other language has and of course that I could share anything I made with just a link. Then ES5 to current shipped with better scoping, import, map/reduce, promises, async/await But, I bring this up because I still work with 30-40 people that, even in 2021, they work on the browser teams (Chromium, WebKit, Firefox) and yet none of them really know JavaScript. They all still have the same attitude that I had 15yrs ago. They avoid it as much as possible and they treat it like C/C++. Some of them have been doing this for 15+ years. They've written 1000s of even 10s of 1000s of lines of JavaScript to create tests for the features they're implementing but they still having really "learned the language".
- heavenlyblue 5y ago
  Have many front ends are actually written in vanilla JS? I thought that in many cases TypeScript is actually used instead.
  - nicoburns 5y ago
    A lot. TypeScript is becoming popular these days, but there are still a lot more projects being written in JavaScript than TypeScript.
  - 5y ago
zeroxfe 5y ago
I've always found that writing lots of code and reading a variety of real world code are the most effective ways to learn new languages. But I recently discovered coding livestreams, and the good ones are really amazing! It's really eye-opening (and sometimes fun) to watch experts talk through their thinking process, while deciding between language features or primitives, or while picking dependency libraries, observing their tooling and stacks, and watching them test and debug things. I'm learning Rust right now, which I think is a deep and complex language, and watching these streams have been incredibly useful.
- FragenAntworten 5y ago
  Likely intended as a reply to https://news.ycombinator.com/item?id=28577371 https://news.ycombinator.com/item?id=28577371
  - zeroxfe 5y ago
    Yes! I have no idea how I botched that!
  - dang 5y ago
    Moved thither. Thanks!
enduku 5y ago
In addition to wonderful responses already posted, I'd like to add one more: Learn Forth. Learn Lisp. Learn APL. No need to be good at these; just enough to learn their programming models. Imperative, functional, OOP, or any other, it doesn't matter. Learning the programming model in such languages changes the way you think. Then start with a language you wish to master. Start with a problem in mind. Always have a problem in mind. Try coding the thought on paper. Do the same with the target programming language. Though it appears as an idealistic procedure, it does serve its purpose and instills confidence in the learner like no other approach out there.
jamisteven 5y ago
This is precisely why I hate coding, even the articles about coding dont make sense to me.
- dennisy 5y ago
  I hate giraffes, even the articles about giraffes don’t make sense to me
- dwmbt 5y ago
  It's funny cause I feel the opposite way... I read endless amounts of articles that I don't understand, books that go way over my head, and even tutorials about things I'm completely unfamiliar with and somehow it's entertaining? I've started reading The Linux Programming Interface [1], thinking I was well versed, and realized how little I knew about my environment. It's sort of motivating knowing that I'll always be able to dive deeper into the rabbit hole? One pet peeve I do have is on forums dedicated to help people (i.e. Stackoverflow, Arch forum, etc), albeit a small percentage of users, seem to think that most basic things are "common" knowledge. I understand that we shouldn't handhold and leave people to do little to no work but the attitude certain responses have rub me the wrong way. People ask questions precisely because they are uninformed, why not point them to the documentation or at least in the right direction? [1] https://man7.org/tlpi/ https://man7.org/tlpi/
wefarrell 5y ago
As a first step I like solving basic problems on Exercism (but any other leetcode platform will probably work) and then working my way up to the more advanced ones. Then I like to read a thick, in-depth guide to the features of that language while continuing to work on increasingly harder problems. When I start actually using the language for work or other real-world problems I’ll read through the code of the libraries I’m using. I’ve used this approach to come in as a lead developer to unfamiliar languages and give meaningful feedback to developers who have worked in that language for 10+ years.
_skhan_ 5y ago
I feel like the approach the author laid out near the end is passive and would lead to one assuming they have retained some knowledge. At the most, it would help someone avoid a similar bug/mistake. A better approach would be to checkout the repo at a commit before the fix and try to replicate the solution in a short amount of time. You would then build context around what the contributor had to figure out and in the worst case you'll have a "gold standard" solution to fallback on (assuming the PR was successful).
- christophergs 5y ago
  This guy deliberate practices
- jcubic 5y ago
  I don't think it's good idea, because it will be wasted time. You can use your time to contribute to the project after reading some closed PR, try to use your knowledge to contribute. For me it's best advice how to start with Open Source, and be sure that your PR will be accepted. And as side effect you will learn a lot, but this is with any practice like with your idea, but you will make project better. Your idea is as worthless as doing LettCode or similar.
  - _skhan_ 5y ago
    How can it be wasted time if you're able to build context and a mental model of the repo? The whole point is to "rapidly improve at any programming language" right? Sure, you're not going to contribute net new code but you'll be primed and ready to contribute in the future while achieving your original goal. Whether or not this works, I don't know. But dismissing it as worthless is kind of a stretch and offensive. But thanks for your opinion.
ChrisMarshallNY 5y ago
I just feel that taking on projects I can't [yet] do, is the best way for me to improve. It bucks up my language skills, design skills, debugging skills, research skills, framework skills, etc. https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...
147 5y ago
Hey, author here. Surprised to see this on the front page of HN since I wrote it 5 years ago. I've always been fascinated with talent acquisition and skill development and would probably different recommendations today after having more experience and reading Ultralearning by Scott Young.
- mbrevoort 5y ago
  Would love to hear more about that. What was your biggest takeaway from Ultralearning?
- ryohkyo 5y ago
  What would you do differently today than the article?
  - 147 5y ago
    I'll probably go back and update the article at some point. Background on the book Ultralearning. It was written by Scott Young who went viral for doing his MIT challenge, to teach himself the MIT CS coursework within a small amount of time. I would expand on the post and focus on the concept of direct learning. That is, if you're not really practicing a skill in the way you're going to use it in an actual real life situation then it's less optimal. The example he gave in the book and I totally agree with is learning a language. People look to apps like Duolingo where you're working to recall vocabulary and language in a way that's much different than when speaking. This isn't to take anything away from doing drills wherein you focus on a specific subset of a skill, like say, free throws in basketball. The approach I discovered myself and outlined in this post is really a drill for doing code reviews in a language you're learning and learning idioms and patterns from the community. People don't usually look at these aspects because usually the advice is to build a project you're passionate about. I'm bad at finding side projects to build from the ground up that I'm "passionate" about. I have a couple of drills to work on coding more actively than reviewing code. I take an open source library that I'm interested in, take the tests and write the code to make the tests pass. Or vice-versa where you write the tests for a library. You can make this as big or small as you'd like. I'd start with either a function or a module that's interesting. This way you zero in on the coding aspect and you don't worry too much about designing the interface since it already has tests. It's also much more real world than doing leetcode algorithm problems. I was taking this approach when I was working on learning how the raft consensus protocol worked.
habibur 5y ago
First try it yourself. Then read how others did it. You will improve rapidly.
travisgriggs 5y ago
This seems great for language/library knowledge. As an experienced polyglot, the languages are not where I'm hitting the wall these days though. It's the tooling. I can learn new language basics faster than I can figure out the ecosystem/tooling. For example, my current conundrum is how to deploy an Elixir Phoenix/MQTT app. Writing the app was a fun curve to climb. And I could use techniques like described here to learn from others in the actual programming. But how to build an executable I can wrap in a systemd process running on a different machine? Those are actions people do, not expressed so much in code I can look at. The few blogs I can find on the subject are mired in deep CI toolchains. I want the blog that discusses the secret sauce to learn to acquire the knowledge to work the raft of ever evolving tools we have to work with now days. The "materials" (the languages) are the easy part now days. It's the massively automated complicated machinery we've built around the language of ideas that are my personal pain point of entry.
- derefr 5y ago
  The trick for tooling is usually to find the blog post where the newest major version of the tooling was announced. Such a blog post will almost always contain a demonstration of what idiomatic use of the tooling looks like now. (Because, if it didn’t, how would anyone get started using it?) This is also the domain of the more extensive language tutorials and/or “Learn X” books. Elixir’s website’s getting-started docs have a very good section on using Mix, for example, including `mix release`. (People tend to forget to re-check an ecosystem’s official getting-started docs as new tools are introduced into the ecosystem. I’d encourage everyone to give your favourite language’s docs a quick skim every year or two; something new might jump out at you!)
  - koolba 5y ago
    Or just wrap it in a container and pretend that all environments are the same as whatever flavor of Alpine / Debian / Ubuntu that you want it to be.
- jcubic 5y ago
  If you find some project that do this right and use tools you need, just ask the author to publish his knowledge. It will be beneficial to everyone not only you. Most people like to share their knowledge, and if you find that other person, just try to find another one. A year ago I've read article about the person that self-published a book (printed and ebook), here wrote an article how he do that and how he created it in markdown (very well written book about TypeScript in Polish), I've asked an year ago (when read that article) if can publish the code, he said that he was thinking about this. Recently he published how own blog system online on GitHub and wrote another article this time with link to GitHub. I still waiting for the book code.
lordnacho 5y ago
Here's what I do when learning a new language. I've written projects in C#, VB6, C++, Python, Rust, Kotlin, Java, Swift, Objective-C and a tiny bit of typescript. - First of all, find out what the typical toolchain is. What IDE do people tend to use? What compiler? How is package management done? These can be really complicated or super simple to answer. - Compile a Hello World and see that it runs. If it's reasonably specific and supported by a bigcorp, there's often extensive downloadable examples. Android and iOS for instance will tell you a lot in their tutorials. If there's a book, get the book and see how the author presents it, just skim it for key concepts, don't get bogged down in the cpp templates SFINAE explanation, it will only make sense once you have done some coding. - Find out how modules work in your language. Every language has this, and you need to know it before you can get anywhere, both reading and writing. - Note down keywords from the tutorial code. Recurring things you see, look them up. If you're doing Rust maybe you see `match, await, clone, some, and unwrap` quite often. If it's iOS maybe `controller`, or if it's Android maybe `fragment`. Google all these things. - Look for the libs that you need. If you need a websocket, look for that. Major frameworks will tend to have good examples in idiomatic style. You can't know all the libs you'll need, so just get the ones that are obvious. This will give you a better histogram of keywords and soon key concepts. - Start to code your actual thing you want to make. As you run into issues the errors will give you keywords. This will improve your knowledge as you google those as well. After a short time you will run into larger issues than syntax, and those issues will turn out to have been mentioned in the appropriate books.
einpoklum 5y ago
But don't only a few languages/frameworks/library collections have such a repository of "PR"s, with diffs and review comments and everything?
- Igelau 5y ago
  If it's worth learning right now it will.
voidnullnil 5y ago
This only works for so long until the devs get tired of spoonfeeding. More importantly: There shouldn't be subtle nuances in something like a web routing library which is _supposed_ to be trivial. Just the other day I had the experience of watching a grown man give a presentation on his beloved HTTP library, explaining fundamentals of asynchronous (TM) programming and syntax as if the audience does not understand their own programming language in 2021, after seeing the previous 500 LangX.FrameworkY.HTTPlibs. This shouldn't be a thing. We shouldn't be relearning basic shit every day. The problem aside from UNIX being a giant pile of garbage, and HTTP being utterly pointless (can you even name what problem is being solved when you create a new p2p application and make them talk HTTP to each other?), is that everyone keeps making their new languages and libs to "fix" one tiny issue, and they _always_ lack basic knowledge of the past 50 years of PL history, such as Standard ML which is better than whatever they just came up with.
bbertelsen 5y ago
I love this approach. I think looking at the FAQ for a programming language's tag is also an amazing way to dive into a programming language. Lots of detail, different approaches and people discussing best practices on even the simplest of programming tasks.
deleted 5y ago
[deleted]
ineedasername 5y ago
I learned that using the collection functions on strings in Clojure is much less performant... But it doesn’t have to be my PR. It can be anybody’s." This reveals a fundamental problem in coding. Best practices for performant code shouldn't require ad hoc digging into PR's, and as long as it does then we'll have code that is buggy & slow(er than necessary). Learning from others, in any field, will always be a valuable source of improvement, but it just doesn't seem that, in software dev, it results in laying down solid incremental increases in general knowledge that makes its way back into the education of future devs or current devs in a language new to them: If this was structural engineering, you'd have to have taken a "materials" course and learn all about different types of materials, their properties, load capacities, degradation profiles and how to evaluate new ones that come your way under the same criteria. Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics? This is on us to demand this, to standardize-- not languages themselves-- but the performance profiles & characteristics that we must know about in order to make a choice on which tool to use. And it shouldn't be that each user has to figure it out on their own, dig into PR's or whatever. Again, there will always be experiential learning. But too much is experiential right now.
- SmellTheGlove 5y ago
  > Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics? Up front, I don't disagree with you, but let me throw out a parallel benefit of your scenario here: For the most part, in software engineering, a building won't collapse if I'm fucking around with a language and doing sub-optimal things. If I need optimization, I probably know that going in, and would probably take the time to know exactly what language/features I should use. Since most software built today is pretty low risk/inconsequential if it fails, we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn. We can test our materials in production, whereas I hope the dude that built my office can't. Like, yeah, definitely don't do this with medical devices and airplanes, but with CRUD app of the day, I might learn something when people decide to use it all of a sudden and it grinds to a halt. I dunno, I should say I'm not a real software engineer in the first place and am open to being totally wrong here.
betwixthewires 5y ago
This is actually a great idea that I hadn't thought of. I've been trying to learn a new language for something important and it's been a bit much. I'm going to try this.
DoreenMichele 5y ago
This is potentially approachable advice for a total noob who can't really code: Just read the pull requests and comments in open source if you want to start learning. It's thought provoking and not what I expected. I'm used to hearing "If you want to learn, build something." That assumes some basic knowledge I simply don't have, so I haven't yet managed to pull it off.
deleted 5y ago
[deleted]
dudul 5y ago
"start reading them from the beginning. Just a few a morning for warmup while you drink your morning coffee and catch up on email." How do you read PRs while you catch up on emails? Not to discount the overall advice, but this statement is kind of weird.
e9 5y ago
When I need to learn new language I try to solve basic coding questions with minimum number of characters. You learn a ton about language this way pretty quickly.
stardenburden 5y ago
I can tell an anecdote from my own life to confirm this theory. My first PR at nixpkgs, I had to close because I didn't understand what the maintainers were complaining talking about, it was like they were speaking a different language. It was only one month later, after reading other PR reviews, talking on IRC and thinking about all of it, could I make sense of what they wanted from me. Since then I've started doing exactly what the author described: comment on other PRs with things that I was confronted with, and/or saw others be. By now I've gained enough knowledge to come up with own criticisms - indicating that I've learnt quite a lot.
1vuio0pswjnm7 5y ago
"1. Every morning, take your favorite open source library or one from a language you're learning, go to the closed PRs on Github and start reading them from the beginning." s/library.*learning/operating system/ s/on Github//
journey_16162 5y ago
For me working with different languages and seeing different codebases helped a lot. I have always been a solo dev, I have some 6 years of experience, including 3 years getting paid for it. However, up until 1 year ago, I knew only PHP and JavaScript - and I did not know about many good practices in either language - i.e. I did not even use a linting plugin, I was sloppy with git commits. Then one year ago I picked TypeScript for a long-term personal project. TypeScript is now my main language. - I was still working in PHP ocassionally (to get paid) - after using TypeScript and Eslint, I decided I at least need to use some linter in PHP. The linter had a very useful rule I did not not have in Eslint, rule that said: "This looks like commented out code". Thanks to this, my new TypeScript project is now not polluted with commented out comments all over the place. I'm not sure if I would have picked it up if not for this small detour. - I was used to describing what every function does, even if it was obvious just from the name of it. This is because it's a very common practice in some PHP projects - I presume this is probably because of lack of the type system, you have to use PHP doc to comment function parameters, and if you comment function parameters, you may want to add the description of the function anyway. Thankfully I took some detour, I wanted to learn a bit of C++. I looked at some codebases, particularly Chromium - and I was surprised to see how little comments it had, compared to say, WordPress (PHP). I immediately knew this is the right approach for me. I started dropping any obvious comments and not repeating myself and instead name variables / functions to be more descriptive. - I also looked a bit into Rust and saw how the language is using return results rather than exceptions. I compared both approaches and decided that it would be better if I used return results rather than exception, as Typescript has no way to annotate that a function throws and what it throws.
ipiz0618 5y ago
Contributing to open source is, to me, very similar to learning a language at work. The difference is that you seldom have the chance to learn a new language at work because you generally have to first be experienced with it. To me, I always learn the best when there's a necessity to ship my code. Side projects won't do, and I always revert to using my skills developed at work. Therefore, this sounds like a very good piece of advice to start with.
schwurb 5y ago
I came up with this trick (reviewing other PRs, after thinking how I would to it) to speed up learning technology at my working place where we don't have enough man power to do mentoring.

468 points by jcubic 5y ago

black_13 5y ago

Being good at anything or anything in demand doesn’t translate into an income.

rStar 5y ago

i play guitar every morning in my free time. work is for work. you’re a good enough programmer already. enjoy yourself.

redeux 5y ago
For some coding is a craft and a job. Just as I would expect a professional musician to enjoy growing in their craft and learning from their peers, so do people in other areas of life, including programming.
- _hilro 5y ago
  Do it on company time.
  - WJW 5y ago
    If you enjoy programming for its own sake, why not improve your skills in it both on and off company time?
    - JanisL 5y ago
      Depending on workload you will need to watch very carefully for burnout and other mental exhaustion issues if you do this.
parafactual 5y ago
Not all of us are professional programmers, and especially not all of us are only professional programmers.
- autoliteInline 5y ago
  For me, programming for free would be painful at a cellular level. Better to learn the piano or how to do portrait art.
teddyh 5y ago
Programming constantly changes and evolves. Does your employer allow you to use your work time to read journals and educate yourself on modern developments? If not, you’d better do it in your own time if you want to avoid being stuck in the past.
- tayo42 5y ago
  You read journals about programming? Like research papers?
- Igelau 5y ago
  If your employer doesn't allot some time for you to do just that, ask them to, or find one that will.
nkrisc 5y ago
And my work is not programming so coding in the morning for me is the same as you playing guitar.
schwartzworld 5y ago
Eh, I was a hobbyist before being a pro. I love coding at home, I just won't do the same thing I do at work.

darkbatman 5y ago

If someone need my suggestion, here is what you do - try doing different sort of questions (multiple topics too) on leetcode from different topics may be just 20-30 in language you want to learn. Its different way but you will learn a lot of new libraries, ways to mutate objects, lists, all sort of data structures and new things really really fast.

raman162 5y ago
I've only done a few leet code questions but only in languages that I'm comfortable with. Even then, I've had similar experiences to the author mentions where I've gotten different perspective on how to approach certain problems.
xondono 5y ago
I’ve tried a lot of those, even contributed to exercism. I think it has it’s uses, but you can only extract value from those exercises once you know enough about a language. For me those exercises are more about developing muscle memory than really learning a language. OPs idea is good, but I think fails in the same way. I don’t think you’ll get much value out of reading PRs until you have certain familiarity. No amount of PRs will teach you what a monad is, you need to dive deep and conceptually understand the model(at least IMO).
nostrademons 5y ago
Leetcode is leetcode. It's its own skillset within software engineering, one you often need to get a job, but it bears pretty little resemblance to any of the skills you need to deliver working, functional software that solves a user's problem. Practicing it will help you get better at it, which may help you land a job where you can practice all the other skills, but don't confuse leetcode with proficiency in software development. Among other differences, leetcode teaches you little about reading large unfamiliar codebases; debugging; organizing large software-engineering projects; working in teams; teasing out actual requirements; making incremental progress; real-world performance (and the tools you need to identify bottlenecks); and most of the libraries and frameworks that are common industry knowledge.
- 5y ago

raman162 5y ago

I never thought about reviewing existing open source project PRs to get better at a language. It seems so obvious considering it's similar to how I get ramped up with new projects. > 2. When you want to level up, start reading the diff, and review the code and changes yourself before reading the comments. > 3. Finally, when you start feeling more confident, start leaving those comments on new PRs so that the maintainer doesn’t have to. You’re starting to contribute to open source! The steps from two to three are pretty dramatic, I personally would replace step 3 with tackling an open issue related to code you reviewed before. I feel like to give feedback on a PR you need to be intimately familiar with the code, something you get from writing and/or making changes to it.

wyclif 5y ago
I thought about doing this, but the difficulty for me is finding the projects that are going to be optimal for learning the language.

rob74 5y ago

In the spirit of this, the Go project has a "common code review comments" document (https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki/CodeReviewComments) - topics that come up frequently when reviewing pull requests. Reading these can certainly help you get better at writing (idiomatic) Go...

deleted 5y ago

[deleted]

aloisdg 5y ago

My own take, to improve at any programming language, use them to build actual small project. The smaller the better. Something familiar. Something easy. A library to convert celsius to fahrenheit. A webapp to count the day until Halloween. This kind of useless-ish stuff. My last example is to add a state machine with xstate to a project fetching some data and formatting a nice output. Do I need a state machine? Not really, but it is a good way to learn it. btw, the goal of the project is to smooth attribution to stack overflow's answer. I just started it, sorry for any bug. the app: https://stacktribution.vercel.app/ https://stacktribution.vercel.app/ the code: https://github.com/aloisdg/Stacktribution https://github.com/aloisdg/Stacktribution

ducharmdev 5y ago
I did something similar to learn Go & gRPC. I had a python client for displaying a simple COVID-19 report with the option to export as CSV, and had a Go server that sent a request to a public API to collect the data for the report. Did I need gRPC or the Go server? Not really, but when you're learning something new, there's a certain psychological benefit to being able to finish something using the technology you're learning. That, and you can focus more on the learning part instead of getting sidetracked by the other details of a larger project.
2OEH8eoCRo0 5y ago
This is basically what they say in SICP. Write programs. That's it. It could be small projects or it could be well-known puzzles you already know. Fibonacci- iterative and recursive, fizz buzz, sudoku puzzle solver, 8 queens, etc. Storytime: I would work at site when I worked in defense and do 15 hour days. I could sit there and monitor, as the job required, but I was also learning Perl for the job. I had no Internet so I spent all my time writing tools and reimplementing every programming puzzle that I could think of in Perl. In very short time I became the go-to "Perl" guy even though all the "toys" I made in spare time were "stupid and useless" according to coworkers.
giovannibonetti 5y ago
Instead of using a library for state machines, have you thought about trying a language [1] that does that in a type safe way, with a compiler that has your back if you forget to deal with a state? [1] https://elm-lang.org https://elm-lang.org

adamnemecek 5y ago

Also reading the source code for the standard library can be illuminating. Note that some languages have pretty subpar standard libraries. This might have changed but ~10 years ago the Ruby standard library really left some things to be desired. I don't recall the details but I wasn't a fan of parts of it. On the other hand, the Rust standard library is top notch.

einpoklum 5y ago
> Also reading the source code for the standard library can be illuminating. That's a lot more hit-and-miss. On one end of the spectrum, you have Java, where all of the lower-level, nitty-gritty work happens within the JVM anyway; and on the other end of the spectrum you have C++, where it's "turtles all the way down" almost, with lots of repetitiveness, ugly hacks to within the library to help the user avoid ugly hacks in their code, a big bunch of preprocessor macro definition checks for meeting innumerable compatibility requirements for different versions of the language standard on different platforms, and so on. Yes, you will learn from it, but it will be painful.

rafaelvasco 5y ago

Two things I did and always do: Code things that solve real problems you want to solve. The harder the problem, the better you'll get in the language and as a programmer in general. Second, look at existing open source, well written code that, again, solves a problem you're interested in. I always emphasize this: Things you're passionate about. That way you can master any language/framework. By master here, I mean you can code anything you want in the technology efficiently. Your final app will be: Easy to modify/enhance, easy to understand in terms of code. Memory and CPU efficient in terms of runtime.

nonima 5y ago
>Code things that solve real problems you want to solve. Everyone says that but I can't think of any real problems I personally have that I could solve using programming.
- rafaelvasco 5y ago
  Nothing ? Maybe a website that you wanted to exist but there's nothing quite like it ? An app, a game... Its not only about solving problems exactly but about having a vision and wanting to turn it into reality.

tienthanh8490 5y ago

Nice advice. I always hear people suggest building some projects to learn the language, but I doubt if it's realistic given other constraints in life (I also tried it but the initial excitement wears off pretty quickly). In the end, knowledge can come from anywhere, we just have to find the right source.

zarzavat 5y ago

My hack to improve at a new programming language is to read its grammar. We instinctively try to learn programming languages the same way as we would a natural language, bottom up. But unlike natural languages, programming languages have complete grammars that can be read in a session. This will prime you with the right questions to ask ("WTF is an XYZ?"). Doesn't work for Clojure though :)

wrycoder 5y ago
Not really for Python, either.
- d0mine 5y ago
  You can definitely read it https://docs.python.org/3/reference/grammar.html https://docs.python.org/3/reference/grammar.html Though I found it useful only to answer narrow specific questions.
dgb23 5y ago
For Clojure what helped me was starting to read the source. Typically core lib first and then the Java implementation of certain constructs. For me it helps tremendously to see how the sausage is made.
toomanydoubts 5y ago
Not sure if this is what you're talking about, but there's https://learnxinyminutes.com https://learnxinyminutes.com. It's really awesome when getting started with a new language. If you're an experienced programmer, you can get to a newbie-but-ready-to-write-some-code level after a 15 minute reading on a new language.

bradneuberg 5y ago

Does anyone know good open source projects that are using modern c++ (c++ 11 to 17 techniques) that I can study and possibly contribute to to get better at c++?

ensiferum 5y ago
Well since you asked...a 2D game engine https://github.com/ensisoft/gamestudio https://github.com/ensisoft/gamestudio

eyelidlessness 5y ago

The is a great suggestion. I’ve also learned a lot just from reading the already-merged code of projects I’m interested in, and stepping through git history to see how it evolved. I even frequently do this on my phone when I want time away from the desk. For instance I’ve been super interested in SolidJS[1] for months. I learned from reading the source that a lot of the work is done by its underlying dom-expressions[2] compiler. And in reading its source, I learned enough about JS AST transformation that, when I had a need to do some AST transforms of my own for work, I knew enough to confidently timebox a proof of concept to two hours (and actually finished the work in that time!). All from reading code casually on my phone. Sure, I front-loaded a lot of that work in my free time. But I did it because I was genuinely interested in the project I was learning from. 1: https://www.solidjs.com/ https://www.solidjs.com/ 2: https://github.com/ryansolid/dom-expressions https://github.com/ryansolid/dom-expressions

greggman3 5y ago

A lot of people seem to be saying "build a small project" and I'm not saying that doesn't work but...., but, something I've experienced a lot is that people stick to their old ways, myself included. As a C/C++ programmer I used to hate JavaScript (pre ES5). I didn't like it's function based scoping system. I didn't like it's prototype based class system. I loathed using it and wrote as little as possible, only enough to make a small WebGL demo or add a tiny feature to my blog. I was basically trying to use JavaScript as C/C++ and hating it. At some point though I flipped. I actually started using JavaScript and playing to its features. I embraced prototypical inheritance and all the ways it's more flexible than class based. I embraced JavaScript's dynamic typing using, where appropriate, the ability to easy wrap APIs, to write more generic and flexible code. I also really loved closures and building functions that closed over data, something that, at the time, C/C++ didn't have. I also really enjoyed that, at least in the browser, JavaScript is bundled with a lot of CROSS PLATFORM functionality (graphics, GPU access, audio, video, networking, UI) that pretty much no other language has and of course that I could share anything I made with just a link. Then ES5 to current shipped with better scoping, import, map/reduce, promises, async/await But, I bring this up because I still work with 30-40 people that, even in 2021, they work on the browser teams (Chromium, WebKit, Firefox) and yet none of them really know JavaScript. They all still have the same attitude that I had 15yrs ago. They avoid it as much as possible and they treat it like C/C++. Some of them have been doing this for 15+ years. They've written 1000s of even 10s of 1000s of lines of JavaScript to create tests for the features they're implementing but they still having really "learned the language".

heavenlyblue 5y ago
Have many front ends are actually written in vanilla JS? I thought that in many cases TypeScript is actually used instead.
- nicoburns 5y ago
  A lot. TypeScript is becoming popular these days, but there are still a lot more projects being written in JavaScript than TypeScript.
- 5y ago

zeroxfe 5y ago

I've always found that writing lots of code and reading a variety of real world code are the most effective ways to learn new languages. But I recently discovered coding livestreams, and the good ones are really amazing! It's really eye-opening (and sometimes fun) to watch experts talk through their thinking process, while deciding between language features or primitives, or while picking dependency libraries, observing their tooling and stacks, and watching them test and debug things. I'm learning Rust right now, which I think is a deep and complex language, and watching these streams have been incredibly useful.

FragenAntworten 5y ago
Likely intended as a reply to https://news.ycombinator.com/item?id=28577371 https://news.ycombinator.com/item?id=28577371
- zeroxfe 5y ago
  Yes! I have no idea how I botched that!
- dang 5y ago
  Moved thither. Thanks!

enduku 5y ago

In addition to wonderful responses already posted, I'd like to add one more: Learn Forth. Learn Lisp. Learn APL. No need to be good at these; just enough to learn their programming models. Imperative, functional, OOP, or any other, it doesn't matter. Learning the programming model in such languages changes the way you think. Then start with a language you wish to master. Start with a problem in mind. Always have a problem in mind. Try coding the thought on paper. Do the same with the target programming language. Though it appears as an idealistic procedure, it does serve its purpose and instills confidence in the learner like no other approach out there.

jamisteven 5y ago

This is precisely why I hate coding, even the articles about coding dont make sense to me.

dennisy 5y ago
I hate giraffes, even the articles about giraffes don’t make sense to me
dwmbt 5y ago
It's funny cause I feel the opposite way... I read endless amounts of articles that I don't understand, books that go way over my head, and even tutorials about things I'm completely unfamiliar with and somehow it's entertaining? I've started reading The Linux Programming Interface [1], thinking I was well versed, and realized how little I knew about my environment. It's sort of motivating knowing that I'll always be able to dive deeper into the rabbit hole? One pet peeve I do have is on forums dedicated to help people (i.e. Stackoverflow, Arch forum, etc), albeit a small percentage of users, seem to think that most basic things are "common" knowledge. I understand that we shouldn't handhold and leave people to do little to no work but the attitude certain responses have rub me the wrong way. People ask questions precisely because they are uninformed, why not point them to the documentation or at least in the right direction? [1] https://man7.org/tlpi/ https://man7.org/tlpi/

wefarrell 5y ago

As a first step I like solving basic problems on Exercism (but any other leetcode platform will probably work) and then working my way up to the more advanced ones. Then I like to read a thick, in-depth guide to the features of that language while continuing to work on increasingly harder problems. When I start actually using the language for work or other real-world problems I’ll read through the code of the libraries I’m using. I’ve used this approach to come in as a lead developer to unfamiliar languages and give meaningful feedback to developers who have worked in that language for 10+ years.

_skhan_ 5y ago

I feel like the approach the author laid out near the end is passive and would lead to one assuming they have retained some knowledge. At the most, it would help someone avoid a similar bug/mistake. A better approach would be to checkout the repo at a commit before the fix and try to replicate the solution in a short amount of time. You would then build context around what the contributor had to figure out and in the worst case you'll have a "gold standard" solution to fallback on (assuming the PR was successful).

christophergs 5y ago
This guy deliberate practices
jcubic 5y ago
I don't think it's good idea, because it will be wasted time. You can use your time to contribute to the project after reading some closed PR, try to use your knowledge to contribute. For me it's best advice how to start with Open Source, and be sure that your PR will be accepted. And as side effect you will learn a lot, but this is with any practice like with your idea, but you will make project better. Your idea is as worthless as doing LettCode or similar.
- _skhan_ 5y ago
  How can it be wasted time if you're able to build context and a mental model of the repo? The whole point is to "rapidly improve at any programming language" right? Sure, you're not going to contribute net new code but you'll be primed and ready to contribute in the future while achieving your original goal. Whether or not this works, I don't know. But dismissing it as worthless is kind of a stretch and offensive. But thanks for your opinion.

ChrisMarshallNY 5y ago

I just feel that taking on projects I can't [yet] do, is the best way for me to improve. It bucks up my language skills, design skills, debugging skills, research skills, framework skills, etc. https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...

147 5y ago

Hey, author here. Surprised to see this on the front page of HN since I wrote it 5 years ago. I've always been fascinated with talent acquisition and skill development and would probably different recommendations today after having more experience and reading Ultralearning by Scott Young.

mbrevoort 5y ago
Would love to hear more about that. What was your biggest takeaway from Ultralearning?
ryohkyo 5y ago
What would you do differently today than the article?
- 147 5y ago
  I'll probably go back and update the article at some point. Background on the book Ultralearning. It was written by Scott Young who went viral for doing his MIT challenge, to teach himself the MIT CS coursework within a small amount of time. I would expand on the post and focus on the concept of direct learning. That is, if you're not really practicing a skill in the way you're going to use it in an actual real life situation then it's less optimal. The example he gave in the book and I totally agree with is learning a language. People look to apps like Duolingo where you're working to recall vocabulary and language in a way that's much different than when speaking. This isn't to take anything away from doing drills wherein you focus on a specific subset of a skill, like say, free throws in basketball. The approach I discovered myself and outlined in this post is really a drill for doing code reviews in a language you're learning and learning idioms and patterns from the community. People don't usually look at these aspects because usually the advice is to build a project you're passionate about. I'm bad at finding side projects to build from the ground up that I'm "passionate" about. I have a couple of drills to work on coding more actively than reviewing code. I take an open source library that I'm interested in, take the tests and write the code to make the tests pass. Or vice-versa where you write the tests for a library. You can make this as big or small as you'd like. I'd start with either a function or a module that's interesting. This way you zero in on the coding aspect and you don't worry too much about designing the interface since it already has tests. It's also much more real world than doing leetcode algorithm problems. I was taking this approach when I was working on learning how the raft consensus protocol worked.

habibur 5y ago

First try it yourself. Then read how others did it. You will improve rapidly.

travisgriggs 5y ago

This seems great for language/library knowledge. As an experienced polyglot, the languages are not where I'm hitting the wall these days though. It's the tooling. I can learn new language basics faster than I can figure out the ecosystem/tooling. For example, my current conundrum is how to deploy an Elixir Phoenix/MQTT app. Writing the app was a fun curve to climb. And I could use techniques like described here to learn from others in the actual programming. But how to build an executable I can wrap in a systemd process running on a different machine? Those are actions people do, not expressed so much in code I can look at. The few blogs I can find on the subject are mired in deep CI toolchains. I want the blog that discusses the secret sauce to learn to acquire the knowledge to work the raft of ever evolving tools we have to work with now days. The "materials" (the languages) are the easy part now days. It's the massively automated complicated machinery we've built around the language of ideas that are my personal pain point of entry.

derefr 5y ago
The trick for tooling is usually to find the blog post where the newest major version of the tooling was announced. Such a blog post will almost always contain a demonstration of what idiomatic use of the tooling looks like now. (Because, if it didn’t, how would anyone get started using it?) This is also the domain of the more extensive language tutorials and/or “Learn X” books. Elixir’s website’s getting-started docs have a very good section on using Mix, for example, including `mix release`. (People tend to forget to re-check an ecosystem’s official getting-started docs as new tools are introduced into the ecosystem. I’d encourage everyone to give your favourite language’s docs a quick skim every year or two; something new might jump out at you!)
- koolba 5y ago
  Or just wrap it in a container and pretend that all environments are the same as whatever flavor of Alpine / Debian / Ubuntu that you want it to be.
jcubic 5y ago
If you find some project that do this right and use tools you need, just ask the author to publish his knowledge. It will be beneficial to everyone not only you. Most people like to share their knowledge, and if you find that other person, just try to find another one. A year ago I've read article about the person that self-published a book (printed and ebook), here wrote an article how he do that and how he created it in markdown (very well written book about TypeScript in Polish), I've asked an year ago (when read that article) if can publish the code, he said that he was thinking about this. Recently he published how own blog system online on GitHub and wrote another article this time with link to GitHub. I still waiting for the book code.

lordnacho 5y ago

Here's what I do when learning a new language. I've written projects in C#, VB6, C++, Python, Rust, Kotlin, Java, Swift, Objective-C and a tiny bit of typescript. - First of all, find out what the typical toolchain is. What IDE do people tend to use? What compiler? How is package management done? These can be really complicated or super simple to answer. - Compile a Hello World and see that it runs. If it's reasonably specific and supported by a bigcorp, there's often extensive downloadable examples. Android and iOS for instance will tell you a lot in their tutorials. If there's a book, get the book and see how the author presents it, just skim it for key concepts, don't get bogged down in the cpp templates SFINAE explanation, it will only make sense once you have done some coding. - Find out how modules work in your language. Every language has this, and you need to know it before you can get anywhere, both reading and writing. - Note down keywords from the tutorial code. Recurring things you see, look them up. If you're doing Rust maybe you see `match, await, clone, some, and unwrap` quite often. If it's iOS maybe `controller`, or if it's Android maybe `fragment`. Google all these things. - Look for the libs that you need. If you need a websocket, look for that. Major frameworks will tend to have good examples in idiomatic style. You can't know all the libs you'll need, so just get the ones that are obvious. This will give you a better histogram of keywords and soon key concepts. - Start to code your actual thing you want to make. As you run into issues the errors will give you keywords. This will improve your knowledge as you google those as well. After a short time you will run into larger issues than syntax, and those issues will turn out to have been mentioned in the appropriate books.

einpoklum 5y ago

But don't only a few languages/frameworks/library collections have such a repository of "PR"s, with diffs and review comments and everything?

Igelau 5y ago
If it's worth learning right now it will.

voidnullnil 5y ago

This only works for so long until the devs get tired of spoonfeeding. More importantly: There shouldn't be subtle nuances in something like a web routing library which is _supposed_ to be trivial. Just the other day I had the experience of watching a grown man give a presentation on his beloved HTTP library, explaining fundamentals of asynchronous (TM) programming and syntax as if the audience does not understand their own programming language in 2021, after seeing the previous 500 LangX.FrameworkY.HTTPlibs. This shouldn't be a thing. We shouldn't be relearning basic shit every day. The problem aside from UNIX being a giant pile of garbage, and HTTP being utterly pointless (can you even name what problem is being solved when you create a new p2p application and make them talk HTTP to each other?), is that everyone keeps making their new languages and libs to "fix" one tiny issue, and they _always_ lack basic knowledge of the past 50 years of PL history, such as Standard ML which is better than whatever they just came up with.

bbertelsen 5y ago

I love this approach. I think looking at the FAQ for a programming language's tag is also an amazing way to dive into a programming language. Lots of detail, different approaches and people discussing best practices on even the simplest of programming tasks.

deleted 5y ago

[deleted]

ineedasername 5y ago

I learned that using the collection functions on strings in Clojure is much less performant... But it doesn’t have to be my PR. It can be anybody’s." This reveals a fundamental problem in coding. Best practices for performant code shouldn't require ad hoc digging into PR's, and as long as it does then we'll have code that is buggy & slow(er than necessary). Learning from others, in any field, will always be a valuable source of improvement, but it just doesn't seem that, in software dev, it results in laying down solid incremental increases in general knowledge that makes its way back into the education of future devs or current devs in a language new to them: If this was structural engineering, you'd have to have taken a "materials" course and learn all about different types of materials, their properties, load capacities, degradation profiles and how to evaluate new ones that come your way under the same criteria. Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics? This is on us to demand this, to standardize-- not languages themselves-- but the performance profiles & characteristics that we must know about in order to make a choice on which tool to use. And it shouldn't be that each user has to figure it out on their own, dig into PR's or whatever. Again, there will always be experiential learning. But too much is experiential right now.

SmellTheGlove 5y ago
> Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics? Up front, I don't disagree with you, but let me throw out a parallel benefit of your scenario here: For the most part, in software engineering, a building won't collapse if I'm fucking around with a language and doing sub-optimal things. If I need optimization, I probably know that going in, and would probably take the time to know exactly what language/features I should use. Since most software built today is pretty low risk/inconsequential if it fails, we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn. We can test our materials in production, whereas I hope the dude that built my office can't. Like, yeah, definitely don't do this with medical devices and airplanes, but with CRUD app of the day, I might learn something when people decide to use it all of a sudden and it grinds to a halt. I dunno, I should say I'm not a real software engineer in the first place and am open to being totally wrong here.

betwixthewires 5y ago

This is actually a great idea that I hadn't thought of. I've been trying to learn a new language for something important and it's been a bit much. I'm going to try this.

DoreenMichele 5y ago

This is potentially approachable advice for a total noob who can't really code: Just read the pull requests and comments in open source if you want to start learning. It's thought provoking and not what I expected. I'm used to hearing "If you want to learn, build something." That assumes some basic knowledge I simply don't have, so I haven't yet managed to pull it off.

deleted 5y ago

[deleted]

dudul 5y ago

"start reading them from the beginning. Just a few a morning for warmup while you drink your morning coffee and catch up on email." How do you read PRs while you catch up on emails? Not to discount the overall advice, but this statement is kind of weird.

e9 5y ago

When I need to learn new language I try to solve basic coding questions with minimum number of characters. You learn a ton about language this way pretty quickly.

stardenburden 5y ago

I can tell an anecdote from my own life to confirm this theory. My first PR at nixpkgs, I had to close because I didn't understand what the maintainers were complaining talking about, it was like they were speaking a different language. It was only one month later, after reading other PR reviews, talking on IRC and thinking about all of it, could I make sense of what they wanted from me. Since then I've started doing exactly what the author described: comment on other PRs with things that I was confronted with, and/or saw others be. By now I've gained enough knowledge to come up with own criticisms - indicating that I've learnt quite a lot.

1vuio0pswjnm7 5y ago

"1. Every morning, take your favorite open source library or one from a language you're learning, go to the closed PRs on Github and start reading them from the beginning." s/library.*learning/operating system/ s/on Github//

journey_16162 5y ago

For me working with different languages and seeing different codebases helped a lot. I have always been a solo dev, I have some 6 years of experience, including 3 years getting paid for it. However, up until 1 year ago, I knew only PHP and JavaScript - and I did not know about many good practices in either language - i.e. I did not even use a linting plugin, I was sloppy with git commits. Then one year ago I picked TypeScript for a long-term personal project. TypeScript is now my main language. - I was still working in PHP ocassionally (to get paid) - after using TypeScript and Eslint, I decided I at least need to use some linter in PHP. The linter had a very useful rule I did not not have in Eslint, rule that said: "This looks like commented out code". Thanks to this, my new TypeScript project is now not polluted with commented out comments all over the place. I'm not sure if I would have picked it up if not for this small detour. - I was used to describing what every function does, even if it was obvious just from the name of it. This is because it's a very common practice in some PHP projects - I presume this is probably because of lack of the type system, you have to use PHP doc to comment function parameters, and if you comment function parameters, you may want to add the description of the function anyway. Thankfully I took some detour, I wanted to learn a bit of C++. I looked at some codebases, particularly Chromium - and I was surprised to see how little comments it had, compared to say, WordPress (PHP). I immediately knew this is the right approach for me. I started dropping any obvious comments and not repeating myself and instead name variables / functions to be more descriptive. - I also looked a bit into Rust and saw how the language is using return results rather than exceptions. I compared both approaches and decided that it would be better if I used return results rather than exception, as Typescript has no way to annotate that a function throws and what it throws.

ipiz0618 5y ago

Contributing to open source is, to me, very similar to learning a language at work. The difference is that you seldom have the chance to learn a new language at work because you generally have to first be experienced with it. To me, I always learn the best when there's a necessity to ship my code. Side projects won't do, and I always revert to using my skills developed at work. Therefore, this sounds like a very good piece of advice to start with.

schwurb 5y ago

I came up with this trick (reviewing other PRs, after thinking how I would to it) to speed up learning technology at my working place where we don't have enough man power to do mentoring.