You don't become a better programmer by doing Project Euler like problems. Pick a real world project that's of interest to you and try to implement it. When starting out, it's not the worst idea to pick something that's been implemented quite a few times so that you can reference other people's work if you get stuck. You'll be surprised how much you can learn from implementing e.g. ls.
Also, you can contribute to open source.
Btw, this project I'm contributing to called AudioKit (if you are interested in audio stuff on Apple hw, you should definitely check it out) is looking for contributors
Totally agree. It's like how writing papers (to be graded by a teacher) about Shakespeare only makes you marginally a better writer, less so if you want to be a novelist or a journalist who appeals to mass audiences. Until you write real-world projects, in which the code has to be read (and edited) by real people, and which the output affects real people, all of the software engineering precepts (including the 2 hard problems in computer science) will remain abstract to you.
Let's not be too harsh. This is a programmer in a place where we have all been before - we must remember this.
William has looked back after 2 years learning. He's blown away and is showing those that are slogging it out, 2 years away from that point.
The author will learn that, actually, you can do this every 1 - 2 years and still get blown away. Even more shocking is looking at that newbie code at 4 years in.
Fact is there is clear improvement. He's on the right trajectory. He's just in the stage where you feel unstoppable and perhaps hasn't yet been humbled by a few bad projects.
He should be applauded and welcomed. He has put in the time, improved significantly in 2 years and is on the path away from mediocrity.
In the end, many programmers stop learning after Uni or at least outside of formal training. We are, here, part of a pack that practices continuous skill improvement out of love for our craft and it looks like we have a new member.
I appreciate the lesson trying to be taught here -- don't be intimidated by what you don't know, develop a plan, and practice -- but I don't think the author chose good examples.
For the LCM example, the second solution doesn't show any understanding of the underlying problem. The point of project Euler is to think about algorithms -- not to take advantage of "batteries included" features of programming language standard libraries.
For the duplicate counting problem, while the second answer is shorter, it's a bad solution. Just a few of the problems: it calls `split` many times instead of once; `count` can be called directly on a string; `chars` is the right way to get the characters of a string in Ruby; and finally the problem can be solved in 1-2 passes over the data using something like Ruby's `Enumerable#group_by` or Python's `itertools.groupby` rather than in a number of passes proportional to the length of the data -- O(n) rather than O(n^2).
What on earth does he mean by saying that "the reduce method [instead of inject] is performance friendly and a more "Ruby way" of doing things"? `reduce` is an alias for `inject`...
Based on the linked github page[1], it looks like that comment was an extrapolation from a guideline in Airbnb's Ruby Style Guide, where Airbnb prefers the use of `reduce` instead of `inject`:
- Prefer `reduce` over `inject`.
I haven't seen any other evidence to show reduce is more performance friendly.
Problem 2 is underspecified so both answers might be wrong. Should the output on the string "aaaabbbaa" be "a4b3a2" or "a6b3"? Or is that invalid input? I don't think you can reasonably answer the problem without an example like this.
He mentions he was asked to write the answer during an interview, so it's possible the problem was underspecified intentionally to test how the candidate explores the input space.
1) The popup at the bottom saying "Sign Up Now to Receive a Free Developer Career Cheat Sheet plus a Free Course to Help Get that First Coding Job!
Let's make that breakthrough together".
and
2) Zero to Launch is on his calendar.
The author of this post has paid thousands of dollars to learn how to market and sell a course on how to get a programming job.
Has someone ever said you can't improve as a programmer? I might live in a bubble of positivism, but I don't think I've ever heard that a programmer can't improve.
Is it just me or is his improved solution a possibly incorrect way to solve the second problem? With his solution "aabbcccaa" compresses to "a4b2c3", but I would expect that to compress to in "a2b2c3a2".
Am I misunderstanding the problem here? In the context of compression why would it just be about counting letters? Why wouldn't you just use a hash of character counts if that is all you care about? Don't you want to maintain the form of the string also so you can unpack the original value?
I've never used Ruby before, but I learned something interesting when Googling what I thought was a weakness in his preferred solution to the first problem: Apparently, in Ruby, integer types have two internal representations that are flexibly switched between as needed. One representation uses a fixed size (analogous to long/int64 in other languages) and the other representation, Bignum, has an arbitrary size (analogous to Java's BigDecimal). So the simple (1..n).reduce(:lcm) approach should work for n of arbitrary size, though I don't think it's the most efficient approach.
I'd love to see more on how he manages his "to learn" pile using Evernote. My current strategy is to let things I want to read live in open browser tabs until my browser crashes. Rinse & repeat.
I slightly prefer the 'worse' solution for the second problem, at least in terms of substance, not necessarily style. The trick the 'improved' version does with uniq seems a little hacky to me, somehow.
The first problem has a clear improvement.
I just checked ruby doc and 'reduce' and 'inject' seem to be synonyms, as far as I can tell.
Assuming this is a variant of RLE-style compression, the implementation is also wrong, if the input is `aabbcccddaa`, it will return "a4b2c3d2" instead of "a2b2cc3d2a2".
Of course you can also just find the biggest prime powers and multiply those. This immediately tells you that the smallest number divisible by all of 1,2,...,20 is 2^4·3^2·5·7·11·13·17.
This is somewhat more difficult to program, but definitely the more efficient way of doing it.
1. Write a blog post about your experience with X. Your description shall not be complete nor correct.
2. Wrap it around with a thesis on a random topic, which is semi-related to your experience, and which is by no means proven by your description.
3. ??
4. profit!