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.
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â.
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.
