Things that made you quit programming?

#1

I’ve started and stopped the LPTHW book on a few occasions. That generally sums up my technical life. I’ve got a knowledge base that’s 10 miles wide on a myriad of technical subjects, it’s just two inches deep in some places.

I generally learn what I need to know to solve a specific problem…then move onto the next problem which, more often than not, isn’t generally related to the last problem. I’m always learning and re-learning tech because there aren’t enough hours in the day.

If you’ve attempted to learn to code on more than one occasion, what made you quit?

If you came back and persevered…what did you do different?

My previous attempts were thwarted by a combination of frustration and competing interests, most notably work and family life. Truth be told though… it’s easy to get frustrated when a programming concept doesn’t immediately register or click…and then not push through the wall and blame it on work and family.

I’ve set up a morning routine this go around to try and eat the coding elephant one bite at a time. Having a forum and/or mentor to help push through those walls will be a difference maker for me this go round.

4 Likes
#2

Four thoughts:

  1. I did never quit. I think that’s because as a trained musician I am very familiar with the concept of practicing (and what to expect if you don’t). Practice is not the same as learning new things. It’s about repeating things you just learned until you can do them on your head. You just learned loops? Write a dozen of them every day for a week or two. That kind of thing.

  2. Programming can be the most frustrating experience in the world for everyone, from absolute newbie to senior developer (I think). You need to find your own ways to deal with that frustration. That is an invaluable skill not only in programming, and programming is a great opportunity to learn it. Tips: Set yourself small (as in reeeeallly tiny) goals, and tick them off one by one on a sheet of paper. If you’re stuck, stop! and think. I’m serious: stop! You can’t think before you stop doing the thing that doesn’t work. Make breaks. Do sport. Be aware of what you hope to gain with programming and if your expectations are realistic.

  3. Separate concepts and implementation. For a beginner, syntax and grammar are a huge source of frustration that keeps you from actually thinking about the interesting concepts behind that. I’d encourage everyone to start studying algorithms and data structures, also OOP concepts, in a language-agnostic way as soon as possible.

  4. Don’t do the journey alone. There are so many places to ask questions, some rather rough (stackoverflow), others more friendly (like here :slight_smile: , leetcode is also really nice when you’re a little advanced) Share your progress and projects (e.g. use the accountability sub forum here). Find friends to do pair-programming or little projects, such things. It becomes so much fun when you’re not doing it alone! Oh, and as soon as you feel ready, try to answer questions: you’ll learn A LOT!

5 Likes
#3

I think @florian made some really good points above. I can also say that I myself stuggle having patience when I don’t get a programming concept right away. However, I believe this is due to the fact that we have beliefs that we should be natural good at it and maybe that we unfairly compare ourselves to other people. Maybe we should just expect that it will take some time and practice to understand something and that there’s nothing wrong if nothing or little makes sense at first, because that means we can learn something new and become more knowledgeable. I hope this somehow helps! :slight_smile:

2 Likes
#4

I think these two points were the main reasons I threw up my hands during my first few forays into coding. Particularly syntax and grammar. I’d understand the teaching point conceptually but, when it came to implementation, syntax and grammar would always screw me up. I think the only way that issue can be resolved is … more practice.

@Noice20…absolutely helps. Thanks for the insights… :slightly_smiling_face:

3 Likes
#5

Yes, I’m afraid so. :wink: But do it the smart way: I bet there’s just a handful of errors that you make again and again. Make a list, then make a habit of scanning every line of code you write for those errors before you run it.

And do what @zedshaw repeats over and over: Break your own code. There’s no better way that I know of to get you up to speed with debugging.

1 Like
#6

So true! I struggl a lot with that too. To overthrow this you have to be really nice to yourself and develop the patience to work on a problem as long as it takes. Learn to not judge yourself, just hang on. Eventually, your problem will be solved, and you gained a lot of experience.

3 Likes
#7

Definitely agreed with this @DidierCH ! I think overall that is a reason for why we may give up and procrastinate on other things as well, because we have too high expectations and are not allowing ourselves to be beginners.

2 Likes
#8

Indeed. You guys might find this interesting. Totally different subject, totally the same problem.

1 Like
#9

Some comments from me to add to the mix:

Listen to people who know better. Zed and several other people I respect as programmers, said very similar things about beginning; stick to a text editor and terminal, create lots of small programs (no gui, extensive library imports, etc), write programs a line at a time - not in one go, read lots of other people’s code.

I have to admit that I didn’t always follow this advice. I wanted to use a Professional IDE (that I had no use for really) so spent a lot of time mucking about with Visual Studio. I also wanted to learn Ruby as its sounded cool, and I liked the whole ‘chunky bacon’ thing. But I didn’t really get that much of it as I went immediately to Rail and therefore wasn’t learning Ruby, but learning how to implement a Ruby MVC web framework. This was demotivating.

I was reaching for libraries all the time like Twython, to do specific things before I really understood the basics. Now I have a much better grasps, I’m finding moving to other languages considerably more easy.

I still find myself writing too much code at once. And I don’t have enough tests. But I am following the ‘practice’ of TDD in many things I write now because I got burnt. But this isn’t always easy. I also have a sign I wrote over my desk that says ‘refactor code OR tests, never both!’ as a permanent reminder :wink:

Everyone talks about a ‘click’ moment, when they start getting things. I’m trying to recall what and when mine was, but I can’t pin it down. I struggled with ‘self’ for ages, and I’m not sure why. I thought a tuple was always two immutable items for a while!?! Oh, and I didn’t get the difference between printing output and returning right at the beginning.

I think it’s about perseverance now. I’ve reached a stage where I can program and converse with programmers. That has achieved one goal in my professional life. I started using Vim initially for developer kudos, (if I truly admit it), but I actually really like it. I don’t use it exclusively, but find I bounce around between Vim, VSC, PyCharm and Brackets depending on what I am doing. This seems a good practice as I never know where I could be working and what toolset is in place.

But the biggest thing for me, was that I started the LCodeTHW with these guys as a process to help me recover from alcoholism. I’ve not mentioned that on here before, but at the beginning I was dealing with those personal issues as well as trying to learn a whole new discipline of programming. It’s clear to me now that changing how you think about things is mentally exhausting. Learning programming if you are not used to thinking in those terms was hard. But it helped me a lot to stay focused on something. That’s certainly why I didn’t give up in either pursuit.

7 Likes
#10

Wow…mad props on getting sober and thanks for sharing that. Really puts things into a whole new perspective. And thanks for the responses and insights on the forums. I’m sure I’ll be posting some less than efficient code in the foreseeable future. :smile: I was writing functions this morning to help memorize the truth tables in lesson 27. I got it working with what I know thus far, but I couldn’t help but think there had to be a more efficient way of doing it.

3 Likes
#11

Thank you for sharing @gpkesley. That remains me that we all have our struggles to fight. Wish you all the best. Didier

3 Likes
#13

Learning to program has been a really bumpy journey for me. Many reasons for this that apply in my case have already been mentioned by others here, and the general advice that I can give is the following: Try to stack the odds in your favour:

  • find a course, tutorial series, group project, whatever, something that gives you that bit of structured learning and external pressure that you wouldn’t otherwise have; set your own deadlines if there are none;
  • don’t tackle projects that are way beyond what you’re capable of;
  • common wisdom is to finish the projects that you start. My advice is to set a deadline, give it a good go, and then, if it is going nowhere, bin it, or shelve it for a while. Frustration is part of the learning process, but there is no need to get stuck (again, stack the odds in your favour!) ;
  • find what hinders you most - is it lack of ability to concentrate, lack of time, too many external distractions - and find a workaround/solution that improves the quality of your time spent coding
2 Likes
#14

I think for it was because I lack self discipline and I got bored with the repetitiveness of it plus I don’t have any clear projects to work on. Now I came back because I wanted to complete the book even if I don’t have much understanding and now I have more of an interest in open source projects even though working on that requires lots of programming knowledge. I also think I’m finding more joy in just learning as a journey and even if I don’t know where it will take me.