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!
Leave a Reply