Is it normal that sometimes I can get things right where other times I just feel hard stuck

Does this happen to anyone?
I have been doing some basic data structure practice as well as js algo practice.

There are times that I can get things right, and it felt great to do so.
The other half of the time I cannot even guess my way through factorialize a number.

When we trying to solve an algo, where do we start?
I normally trying to lay things down in plain english, the try to convert it into code using loops, if else statement, and function.

Sometimes I am able to do so, while other time a simple while loop is where I got stuck.

Does anyone feel this way? I know we are talking only about the basics here… but combining those basics into functional code using a logic that can solve a problem isn’t easy…

also the other time I heard a podcast where someone say:

"you have no idea how little line of code every programmer write per hour, sometimes it is too little, but it only means that they are thinking about how to solve a problem. "

i "kind of " felt this way when I am learning… but then again couldn’t help but worried that at this pace when am I gonna do all the challenges and projects in freecodecamp curriculum… like tic tac toe game, using wikipedia’s API and such…


When I am programming sometimes things go fast and sometimes very slow… It depends on a lot of circumstances which are personal for everyone. My recommendation is that learn to deal with frustration, assume the fact that some days you gonna be brilliant and some others not. In my case, I program since 2009 and the sensation that you described never stop, but I learn to deal with it and finished liking it.

"you have no idea how little line of code every programmer write per hour, sometimes it is too little, but it only means that they are thinking about how to solve a problem. " This phrase is totally true; most time is used learning, re-learning, thinking and googleing. The velocity at what you write code or the amount of knowledge that you memorize doesn’t mean anything! Everything at it’s time. What really makes you a good or bad programmer is your capacity to deal with problems (think, search, learn, persistence, tolerance to the frustration).


I see. I think I will do some outdoor work out to adjust myself then!
I think it is really important to stay away from the computer screen in order to give yourself a bit of a “down time” so that next time when you come back, you will still feel energized.


1 Like

When you’re figuring out something ‘new’ to you, of course you’ll be slow.
Even experienced programmers will slow down in output if dealing with something new…

Just the other day, I came to a crawl when the program I’m writing using a new API (new to me) wasn’t working as documented. Most of my time was spent on re-reading the documentation (maybe I missed something), looking at example codes on the site (maybe they forgot to document something, or they have sample code that apply to what I’m doing), and then finally going to Github to read the actual source code of the project (and maybe I’ll discover something new), and reading the Github project issues (maybe it was a bug). — That’s a lot of time of me just “staring at the screen”, and not typing or doing anything.

In the end, all I had to do was type an additional 27 characters in my code to fix my problem!

If you average it out, that’s me typing 13 characters per hour. Heck! Chickens peck more than that per minute!

But it was a problem solved, and that 2 hours of reading and reviewing isn’t “lost time” either… deep learned a ton that I’ll be able to use later.

Programming is solving problems.
Programming is not the act of typing and producing code.
One can produce pages and pages of code but if it doesn’t solve the problem, it’s useless.


there are times, when everything is a breeze. and there are time when i feel like i’m trudging through tar.
sometimes i get hung up on the simplest things and have to ask the forums. other times, i’m the helper in the forums.
so, i’d say yes. what you are going through is normal.
we all stumbled, fell, tripped when learning to walk. but now it’s something we doing without thinking about it.

i was watching a Robert Cecil Martin video the other day. and one part of his talk was how the programmers (the thought workers) were never entering code into the computers (back in the day). they would write the logic (#2 pencil, punch cards, etc…) but there were specialized data entry folks who got to “use” the computers. nowadays, anyone who went through a 2nd grade typing class can walk into a temp agency and get a job doing data entry. so the problem solving can be done in pseudo-code, flowcharts, hieroglyphics, pig latin or pantomime. coding (translating into computer readable data) the solution is just knowing the language and its quirks.
side note: if you want to be a good programmer, it is highly recommended to read/watch/hear everything you can access from “Uncle Bob”.

1 Like

Yeah, depending on which decade… Back in the mainframe days.

Later on, there were also other people higher than programmers.

Disclosure: (my first software job was mainframe programming after leaving college).

They were called the “Systems Analyst” – they’re the go-between between the end-user/management/client, figuring out their business requirements are, and the best way to solve their problem, and between the programmers… the ones who would do the actual coding.

Yeah, the programmer would still have to do their own thinking, it’s not like the Systems Analyst tells them line-by-line what to type… but the programmer’s realm/responsibility is smaller in scope.

Versus the systems analyst, who may be looking at the bigger, company wide picture.

We, mainframe programmers don’t talk to the end user. The Systems Analyst does, and then the SA tell us the big picture and what we need to do.

Now, there were “Data Entry” people too… but it’s not programming. They’re lower than programmers in heirarchy. They may be responsible for batch entering just data into the computer (customer accounts, etc,) doing some back-filling. – again, depends on which decade. If you go earlier to the punch-card era, yeah the data entry operators may be the ones punching the cards, and not writing the program.

1 Like