Eric Elliot asked a question in his tweet: What is the hardest thing about learning to code?. Excellent question. Like last time this time I also have collected all interesting answers from that tweet:

  • the terrible culture of judgement and name-calling that you find yourself thrust into
  • learning is fun. The hard part is to stay motivated after learning.
  • gaining the experience need to become a good developer and then naming and cache invalidation…
  • getting past your own problems. “I can’t figure this out” “everyone else is smarter” etc
  • learning to learn smart. Order is important. Mentors help. On your own you may feel overwhelmed.
  • also the willingness to accept that maybe 20 years of best practice has been terrible.
  • finding a job that will pay you and train you on how to code
  • Compilation and runtime errors with cryptic messages that you have no idea how to fix.
  • Knowing how to balance productivity with a bearable learning curve. E.g finding work that grows you w/o breaking you.
  • Dealing with your emotions. You have to battle self doubt and failure every day.
  • knowing what to learn, and what to ignore.
  • learning how to make actual software after learning how to code.
  • learn a language is easy. Learning where to use and how to wire everything up is hard.
  • Figuring out how to express your problems so that the terms match stack overflow questions.
  • learning “how to learn”. Absolutely necessary and the only constant I’ve yet to experience.
  • When yesterday you felt like you could create *anything*, and today Hello World feels like a challenge.
  • grasping technical implementation details without losing sight of the problems you set out to solve.
  • Finding a mentor.
  • Understanding the runtime.
  • staying patient, developing the right temperament
  • Insecurities; while writing toy problems, and learning basic syntax for months. I felt I wasn’t solving “real” problems.
  • not enough time, or in the other words “I have a problem with focus”.
  • thinking that learning has a “completed” state
  • working with others
  • Always feeling like you don’t know enough.
  • understanding how it actually works under the hood
  • a roadmap
  • the impostor syndrome. Good reads about it: “I’m an Impostor”, “I’m a phony. Are you?”
  • knowing which languages to study and frameworks to research. So many things are unnecessary or a waste of time
  • unlearn the bad habits…
  • knowing when to stop
  • Learning to be patient with yourself.
  • realizing your code sucks.
  • Deciding what to build.
  • for me it was understanding the ‘space’ where code executes. Like, make a variable where, exactly?
  • know which is the next step (when you’re self learning kind)
  • reading other people’s code
  • in 2015, with JS, shitty documentation & ever changing frameworks
  • everything is constantly changing and becoming outdated
  • effective debugging
  • getting it right when there are so many ways to do it wrong
  • Learning when to not code.
  • the mathematics and algorithms if you want to do something interesting
  • Knowing that even if you have no idea what to do next, that is OK. I started coding at 9, still felt impostor syndrome at 22.
  • having to do real, actual work and not focusing 100% on learning
  • Knowing where to start, how to start and not bring overwhelmed by it all.
  • I’d say realising how simple it is, and then how to build great things with those simple things.
  • Naming stuff.
  • Feeling angry at yourself, because you can’t find some solution. Thinking that everyone else knows more than you.
  • Being persevering and humble, after the 40th error message.
  • coming to terms with the fact that it never ends, and that what you learn today is often wrong tomorrow.
  • tabs vs. spaces
  • how to debug. And by that I mean how to mentally break the issue down and investigate.
  • determination and patience.
  • The fundamental change of our creative approach needed to design your code effectively.
  • getting past “right” and “best” to be able to ever get to “right” and “best”
  • Finding the time and the right balance with work and family. I want to learn and do so much, but struggle to find the time
  • getting older and not being able to keep as much stuff in brain
  • reading documentation that presumes a level of knowledge beyond your own
  • The step from beginner to intermediate. There a lots of tuts for beginner and advanced topics, but not much info in between
  • ending lines with semicolons instead of periods. seriously, who thought that up? or maybe pthreads. with recursion. either/or.
  • Millions of opinions on best practices!
  • Finding valuable resources. Easy ones are crap/old/etc. The good ones are so hard to follow sometimes. Good+Easy is hidden!
  • debugging techniques and visualizing output
  • clarification, a lack of knowledge of debugging techniques and how to visualize output
  • Realizing that when there’s More Than One Way To Do Something, you need to pick one way and just do the thing.
  • fortitude, because when the first time I don’t know what I’m writing yet, but I know it’s going to compile to Javascript.
  • keeping going through the confusion
  • finding a good mentor who is willing to sacrifice their time for you. IMO the only way to get to the top fast these days.
  • Realizing that application design is half the work when making something. Not graphics, but code and interaction.
  • figuring out essential vs nice-to-have skills
  • understanding pragmatism and “what tool fits what problem”
  • various answers depending on how you learn I think.
  • Pessimistic senior developers trying to put down new ideas.
  • figuring out how to ask the right questions.
  • stern advice against “anti-patterns” without demonstrating failure cases.
  • prematurely refactored code. Separating concerns within examples too small for it to make sense just causes confusion.
  • not knowing what to focus on i.e ember,react,vue,angular etc. Also, trying to learn the “best” language == time wasted…
  • Staying focused. There’s always something new and shiny but I’ve found that taking a depth first approach to learning pays off
  • making code work is easy, learning to make it testable and maintainable much harder. Tdd and small composable functions help
  • keep the code simple and reduce its complexity in a continuous way.
  • turning that code into something meaningful. And finding people who care to talk about it in minute detail.
  • knowing what order to learn concepts in and accepting that you must write awful code before you write good code.
  • being disciplined enough to get the repetition that you need
  • knowing how to parse through the heaps of information & resources on the Internet on your own.
  • keeping up with evolving best practices without chasing every bandwagon
  • multitude of bad practices online (in the case of JS), having to know what/how to filter bad tuts
  • not being discouraged by the scope of projects you want to build, or by how far ahead other programmers are
  • breaking everything down step by step
  • That no matter what you create, there are always trade offs.
  • Being patient with myself and keeping up to date.
  • understanding how pieces work together. There are lots of “do this” tutorials and not many “this is how/why this works”
  • dealing with self-doubt.
  • see the bigger picture
  • persevering through the inevitable confusion and frustration until you start to gain some understanding.
  • Once introductory level is past things get tough. No more direction and having to figure out on its own best.
  • trying to understand existing badly written or unnecessarily complex code.
  • in this era it’s most definitely getting carried away with scalability
  • internalise the default case / exception pattern
  • having enough time to practice. Because theory is essential, but one must learn from his own mistakes.
  • bridging the gap between theory and hands-on!
  • changing between different languanges.
  • i’ve always struggled (or been obsessed) with modularization, SoC, etc.
  • Not knowing how to code
  • setting up a project
  • memorizing routines
  • architecture
  • learning how to decompose big problems into successively smaller problems. Then keeping the smaller solutions tightly focused.
  • People who use words like “simple” and “just” when explaining coding.
  • implementation of algorithms
  • naming stuff
  • flow roadmap
  • tons of information and constantly updating, sometimes hard to stay focus!

Comments

You can leave a response, or trackback from your own site.

Before you add comment see for rules.

Leave a Reply

Your email address will not be published. Required fields are marked *

0z6d1h