Started reading this online book late last year, called Write Yourself a Scheme in 48 Hours after a recommendation from someone who was intermediate level of Haskell programming. I read the first chapter and then life (holiday season) got in the way. No way it only takes 48 hrs for the whole book. Maybe I’m on a different unit of scale, say of 48 hrs per section 
The person recommending the book was encouraging about the fact that one can learn to code in Haskell despite it being a difficult language to learn. This book was recommended for it’s brevity and code focused approach. The encouragement and engagement style tips were just what I needed to hear after being around more advanced folks who’ve had 12+ years of experience who forget what it’s like to be a beginner. I just heard about this language less than 3 years ago. Yes, learning to code in a niche language is a journey off to the edge of the world that requires grit but eventually your faith (and actions) becomes measurable progress, which then you will see that you’ve made it to the next level. In fact, related to the first post of this blog, the advice I get often for learning this language is to “just code”. The only way to get better is to spend time on the skill you’re building.
From Learning Curves (for different programming languages) 
Let’s step back for a moment and assess the big picture. I’ve heard in the past commentary on good vs bad Haskell programmer. I’m hazy on the details of why anyone would want to create division in such a small community of developers… well, I guess you’re going to come across individuals who like to measure things in any engineering communities. For sake of argument - It sound like the “good ones” tend to have a certain level of prolific-ness in outputting useful libraries. Quantity and usefulness are not the only metrics… for example a bad Haskell programmer isn’t necessarily less prolific, but rather disappointment towards an individual whether it’s the person not contributing the open source packages they created hype over (and letting perfectionist tendencies slow down the delivery), having packages less adoptable in comparison (bugs everywhere, broken dependencies, etc). How bad of a programmer can you be if you write code that compiles? These measuring scales are so subjective.
Regardless, let’s be kind and admit that anyone who has released a package on Hackage that’s widely used is amazing and generous. Contributions from the community is what grows the community. The Haskell ecosystem is a very small and in fact folks have advised me that if I’d like to continue to do data analysis type of work I’m better off in Python land because there’s actually packages available for various algorithms that I can bootstrap off of. Translation: you’ll face many setbacks. Never mind the fact that I also am still trying to understand this functional programming paradigm hearing that is like wow gee how very humbling and unwelcoming at the same time.
What I can say with more confidence on the topic of measuring programmer quality is the likeability metric, I’ve noticed that common behaviors of a like-able programmer include traits such as:
- Writes documentation and code examples of open sourced packages
- Provides access through IRC or mailing lists where package adopters can ask for support
- Writes in a readable code style
- doesn’t create excessive custom types (you’ve already a lot that come with Haskell.. strings, numbers, etc)
- uses variable names that are semantically intuitive
- modular code where each function does one thing
This list is more about human-to-human communication skills and transcends the actual programming language in question. There’s probably some ratio about code to teaching time somewhere on the internet. All I know is that learning new languages/frameworks is a form of literacy so that there are parallels in teaching kids to read/write in native tongue as well as learning to program.
Anyway I digress. Back to the book I was going to talk about… I revisited this book this week while procrastinating on the algorithm problem 
Want to spend time on haskell even if that algorithm wasn’t going to work itself out. I like how the author takes time to explain how the code samples work. It’d be cool if there were more hi-fidelity learning resources that offer interactivity or more special effects. I’m still on Chapter 2, which given that it’s been months seems slow but it is progress. I have a short attention span when it comes to reading programming books but despite that I can see that this time around, this chapter has been quicker to read through. It took less than 2 hours 
I hypothesize that it’s because of having gone through a Haskell Workshop last month and watching someone type and explain in person what’s going on. Now the read through is more of review than the initial trying to understand new concepts.
Oh, right. I forgot to announce that I wrote up notes from the workshop…
I published notes from the last Haskell Workshop to the NY-Haskell Blog.
I want to add a final section below, takeaways from reading this blog. I share stories from time to time but what can you do for your self-study? Here’s some advice.
Learning hard things
Here are my 2 cents on learning hard things. Hard things being that it might be topics that scare you, or skills that require you to step outside of your comfort zone.
- Make the time. Fully commit to learning and growing. This might be 5 minutes a day, or an hour a week.
- This is your dedicated time and you have to put it as top priority.
- Don’t expect results overnight.
- Figure out what makes you stick to your goals and keep it up (whether it’s organizing study groups, reading books, opening up the ghci repl, just do it!).
- You’re probably going to feel stressed on your journey. There are ways to de-stress such as keeping a personal journal, taking a walk, chatting with friends… your mileage may vary.
… and lastly, surround yourself with people who believe in you and support your dreams.