How can I understand if programming is for me?

Question

I am with the complication of having to choose a career, I am 17 years old and I see that programming is giving a lot of work in Argentina but some concepts confuse me, I just read this https://aprendelo.org/que-estudiar-para-ser-programador/ but I do not know if it is for me, I did a tutorial on YouTube on how to make a calculator in JavaScript and I feel that there are things that are very in the air when they talk about loops and indexes, I feel that I cannot imagine some things that seem to be easy for everyone when they talk.

so I would like to know if there is any programming language that does not have a high level of abstraction, at the moment I am starting with html and CSS, I am going to add JavaScript because from what the tutorial says it is something that is in high demand and can help me to get a job, is it ok or am I wasting my time?

Thanks.

Answer 1

Firstly, html/css are not programming languages though they are languages. Javascript is a programming language but JS/Web is far from being the best entry into CS — the area is in so much flux that what's hot today becomes passe next year. (Tnx Qiulang for that ref!) And so coming to anything with even moderate stability and lastingness is next to impossible.

And as your link indicates there are other areas to get into

• Mobile apps (Android/IOS)
• IOT
• ML
• Crypto and Blockchain
• Cloud
• Dozens other areas which are hot; that is to say where the jobs are

But where the jobs are and what gets you a job, especially a well-paid one, are far from being the same thing. That latter is usually called CS or principles of programming or software engineering... and other names (with nuanced distinctions).

I'll stick to Programming-focused CS

Mindset needed for CS

• Causality Oriented
• Value Neutral
• Mathematical

The last can be expanded again to Math, Engineering/technology and Language (linguistics).

Let me elaborate on each of these:

Causality oriented

For a programmer, causality oriented thinking is a very basic requirement. Its a bit easier if we start with the debugging process. You've done something. Its not working as desired. How do you go about correcting the fault. For that you've to follow a causal chain backwards: Z was unsatisfactory, Y causes/preceded Z. Is Y ok? If not from Y to ... All the way back to the start C,B,A (the start if necessary)

So clearly debugging is about following backward causality. But even designing and programming is about causality. E.W. Dijkstra showed that it is backward causality driven backward leading to seeming forward flow. See

The very first COBOL program I wrote — about a 100 lines — gave me 300 errors! I was quite shaken. I fortunately discovered that I had forgotten an important mantra called PROCEDURE DIVISION. Many of my classmates were less fortunate. I remember one that was particularly scarred by the editor vi, the only available editor then. He exemplified what one wag has said about vi, that it's a program that either beeps or corrupts the file. For one who understands vi this is a joke but for the noob it can be traumatic! If he had understood a single word that defines vi — modal — and spent half an hour understanding how modality defines vi's behavior, his trauma would have vanished. Instead he chose to (try to) learn it by rote — i.e. non-causally — and found it traumatic.

This comes to the next point:

Neutrality

When you are given an error by a mechanical system do you get upset? Offended? Terrorized?

It's amusing when it's someone else in a movie. It's not when it's you. And its a choice. Machines don't think, they don't choose, they don't intend. We do these things — or at least should! When you are a computer scientist, you don't stop being a human being. So you of course have your thoughts, values, intentions. But you must keep them to yourself, and not impose them on inanimate objects! Easier said than done since we all know of being in the position of the man in the video above!

One of the challenges I face as a programming teacher is to convince students to Read the error message! For example in Python when you get an error you'll usually get (a) the error (exception name) (b) the file/line where it occurred (c) a trace of the preceding events — the causal chain — that led to that "event".

If you read these details you can start following the causal chain backwards and locate and correct the problem. But if you are freaked out by the error as though someone scolded you, you'll never get there. To not get freaked out you need to be neutral. And curious/interested.

Personal (controversial?) opinion

I believe you need to have an autistic streak to be a good programmer. Of course literally this is not true ... there are obviously many good programmers who are not autistic. But I conjecture that they are good because they're bimodal — i.e. they work in autist-mode when dealing with machines and human/empathic mode when dealing with human (and other) beings. You don't have to become Dr. Spock and use nothing but rationality everywhere. What is non-negotiable is that you use pure rationality when dealing with machines.

Mathematics

Dijkstra, an idiosyncratic but great CS-ist and CS teacher, punchily made the case that CS should be approached and taught as though it's a branch of pure formal math. See CACM for his view and the subsequent heated discussion. While this is not exactly my opinion, I do believe that math is more central to CS than most practitioners/teachers believe. My own view is more nuanced:

Three legs of CS

Classic accounts of (theoretical) CS are often based around the 3 pillars of CS: (a) Automata (machines) (b) Languages (c) Computation.

These 3 areas have 3 characteristic and quite contrasting modes of approach. CS-ists need to be fine with all three.

Briefly

• Computation is math and is essentially about the infinite.
• Machines are finite and is where the engineering/technology considerations lie.
• Languages link the above two and is, for any programmer, the center-point where the action happens.

A programmer needs to be fine with all these modes of thinking.

Answer 2

I've found out a few quick shortcuts to answer this. What I'm about to say is not a complete answer, but I've found it to be so common with everyone I've worked with and all of my friends in the "programming" field that I think it's a good heuristic to determine early whether your chances of liking programming are high.

If you enjoy optimizing things, get irritated with repetition and wanted to do something to automate it away, enjoy games like factorio, and have at least a little bit of fun doing math and solving problems, then there's a reasonable chance that you will like it. My hypothesis here is that the things that give the dopamine rush which programming does tends to be present in what I listed. Obviously this is a far from exclusive list, so YMMV.

Programming seems hard at first but that's because it requires spending a few weeks (or more) seeing solutions to a variety of things before you learn how to map a problem onto something being solved by a computer.

says it is something that is in high demand and can help me to get a job, is it ok or am I wasting my time?

I think pursuing programming just because it is in high demand is a mistake for many reasons. The field is also quite demanding at times and I would hate to be in this field if I didn't love it as much as I do. Start doing it out of curiosity, and if you find yourself hooked, then consider it a career move.

Answer 3

How do you decided if programming is for you? Have some fun with it.

Pick up your phone, laptop or tablet and look for games that have programming as a mechanic. Two favorites of mine are Cargobot (iPad) and Human Resource Machine (iOS and Steam). If you have fun solving the puzzles you might be ready for the next step.

Download an IDE that is easy to understand in a language the is fun to use. I would suggest Thonny.org which will install Python for you.

Now that you have a fun language and an easy to use system, the trick is to keep it fun. The way I keep it fun is to try to solve some problem, write a game, or draw a picture. Keep it small so you aren't overwhelmed. If you do a search on "Python Turtle Example" or "Python Turtle Game" you will find a bunch of straight forward examples. At the beginning, skip any example if you see the keywords "self" or "class". Those are related to objects and classes and are too much for a newbie.

Once you find an example that you think you can follow, don't just copy and paste it. Type it in by hand. The process of typing in the commands one at a time will internalize the process, and help the ideas sink in. If you come to anything you don't understand don't let it go. Search the net for an explanation. Don't know what "def" means... search "python def". Never seen "for" used like that... search "python for loop". Don't understand why every program has import at the top... search "python import".

The trick to knowing if you are cut out for programming is how you dealt with frustration you encountered during your exploration. If you found confusion as an opportunity to learn new things... if you were comfortable with not knowing all of the answers... if after fighting a block for two days and finally finding the answer you burst into hysterical laughter and ran to show your friends... well... then programming might be right for you.

Answer 4

Only you can decide if programming is for you, but I'll try to offer a bit of context for making the call.

The TL;DR is that:

• It's normal to feel intimidated, that everyone is better than you, or frustrated by syntax or concepts. This is pretty much the universal state of affairs. Initial frustration doesn't necessarily mean your medium or long-term outcomes will be poor.
• If one area of programming doesn't interest you or a project is too difficult, it's OK to set it aside and try something else (including things other than programming). Learning doesn't have to be all-or-nothing.
• Stick to easier (but sufficiently challenging) projects, keeping in mind that almost everything winds up needing more effort than it seems.

---

First of all, programming is difficult. There are endless unforeseeable frustrations in store, and it'll always seem much more complex than it should. Part of learning to program, in my experience, is coming to expect and enjoy the difficulties and failures as much as the apps you'll build. The feeling of overcoming the challenges makes it fun for me. For other people, the product is more fun than the process. This can vary from project to project and over time.

That's not to say some things won't be easy, but those are usually the surprises rather than the common cases. The question is whether the time, energy and opportunity cost of learning to program is worth it over any alternative ways to spend your resources.

It's critical to have the motivation to want to do it in spite of the inevitable frustrations. For a lot of beginners I've worked with, the initial learning curve is too steep and they move on to other things that interest them more. There's just not enough payoff for the effort for them. They wanted to make a Minecraft but only wound up with a console-based calculator after weeks of effort. That's fine.

I've seen students initially struggle mightily with the most minor of syntax issues and appear to be on the verge of quitting, later to move on to successful programming careers. I've seen other students who seem to be learning rapidly and excelling, only to lose interest and quit (possibly temporarily). It's easy to think that initial hurdles and frustrations are indicators of a lack of aptitude, but I'm not sure if it's a strong predictor of long-term results. The key factor seems to be the urge from within to put effort and time into it, and that's not something you can force (but it can be nurtured).

For starters, I suggest picking easy, education-focused languages like Scratch and focusing on simple tasks that are challenging but not insurmountable. Try basic programming challenges on sites like Kattis or Codewars (disclosure: I work for Codewars). Working with peers, a tutor or taking a class makes it easier to get yourself over the initial hurdles. Grab beginner-level books in areas of interest and work through them. Keeping it simple and building a solid foundation is a key way to avoiding feeling overwhelmed to the point of quitting.

If you embark on a project or technology that seems out of your comfort/interest zone, it's OK to set it aside and either revisit it later or abandon it entirely. I've dropped classes and set countless projects aside, putting the concepts on a "to learn" list. Later, I've found that I was able to finish some of these projects once the right opportunity came along, although the "to learn" list is ever-expanding since programming is an extremely broad field. There's no way to learn everything, so deciding where to focus energy is a key skill to develop. It's hard to know what one's interests might be initially, so don't be afraid to experiment.

I feel that I can not imagine some things that seem to be easy for everyone when they talk.

Feeling like everyone else isn't struggling but you are can be a sign of impostor syndrome. I've dealt with it during my programming career. I'm not sure I have much concrete advice other than to suggest that it's widespread and likely that others feel much the same as you. Sometimes you're the most knowledgeable in the group and sometimes you're the least. It's good to pursue both scenarios regularly and be comfortable with both. Even when you may feel the least skilled, there are ideas and perspectives you can offer a project or a team; try to find them. Sometimes, just being another person to contribute makes your skills and time valuable, and that's OK too in some projects.

If other things interest you more than programming, it's OK to pursue those. Whatever time you did spend on programming won't be wasted, since computer and problem-solving skills translate to pretty much any other area of life you wind up in. Learning programming doesn't have to be all-or-nothing and is highly multi-disciplinary.

For example, knowing a bit of JavaScript and having some familiarity with the browser console can help you diagnose and fix problems with many websites, like broken modals. You can write simple userscripts or bookmarklets to avoid repetitive tasks or make a website more usable. Being able to write basic HTML and CSS can help you make or customize a blog or personal page and get your ideas on the internet. Practical books like Automate the Boring Stuff with Python are great ways to pick up enough scripting skills to manipulate spreadsheets, rename files in bulk, pull data off the internet programmatically and other tasks that will come in handy if you use computers often. I find it empowering to be able to control the thing we spend a good chunk of our lives on, even in a small capacity. Learning a bit about operating systems, mobile app development, smart phone technology or networking is useful due to their ubiquity. At the very least, you'll enhance your appreciation of the technology.