the "problem has already been solved".
shivajikobardan needs some problems first.
Agreed. I perhaps worded myself badly, but I meant that choosing the data structures and algorithms, and finding the exact math (equations et cetera) needed, is at the heart of writing programs. When I create a program, I do not worry about what the code needs to do – because that becomes clear as the solution reveals itself –, but what kind of data structures and algorithms I need. Since each problem has many different solutions, finding a "good" one, an "efficient" one, is a general problem solution skill.
Thus, finding interesting problems to work on, and working out exactly how (and why choose that particular way) they are solved using programming, is the key.
Knowing a programming language is one step.
Knowing problem-solving methods and techniques, is more important; and in my opinion, is not discussed enough.
Which is why I suggested to learn about problem solving in general – which in itself is an art, I claim, and useful for all programming tasks.
Even as a kid, I personally liked descriptive geometry, especially the math of how 3D objects, surfaces, etc. can be visualised. That lead me to basic vector algebra, linear algebra, and unit quaternions (or bivectors, whichever you prefer) to describe orientations and rotations. I'm curious, but I learn things better when I need to apply them to do something.
Visual things are often "more fun" than non-visual things. So, working out how e.g. graphical user interfaces are properly implemented, and creating a program that interactively draws fractals, can be lots of fun. The math itself is simple, but the details can be frustrating, because every single pixel in the image has to be separately handled, and you probably need parallel programming (via threads or processes) to keep the user interface responsive while the image is still being generated.
I also like puzzles, and have used e.g. graph analysis to find solutions to puzzles. Graphs, trees, heaps, and disjoint set data structures have all been very useful to me. To help me visually see the data structures, my test programs save the structure in the
Graphviz DOT language (a text language describing graphs) that I then visualize with Graphviz tools, most often
dot.
Games are fun, too. I do believe my first self-designed one was a typical run-and-jump one on Commodore 64, of a runner trying to jump over a hurdle when the space bar was pressed, written in basic. Not too far from Flappy Bird, really. One can start with
Curses – or specifically
ncursesw, which is included in all Linux distributions, and available for all OSes – for text-mode graphics and interactive keyboard input, to make text-mode games like old Nethack. The w version refers to "wide", which means it uses wide characters and strings, and allows one to use basically all
Unicode glyphs in the text interface. In Linux, it works extremely well. Then, there are things like
SDL library, with which one can create "proper" games. UI toolkits like Qt, GTK+, TkInter, FLTK, and others provide a way to create proper graphical user interface programs in a portable fashion, not tied to a particular operating system like Windows, MacOS, or Linux.
I also like playing with sounds. One of my favourite programs on my first PC, a Hyundai 80286, was written in Borland Pascal, and used the internal speaker (a single-tone beeper!) on the computer to emulate the sound of a toilet flushing. I did not set out to create it, just happened on it by accident, then refined it. Later in life, as part of my computational materials physics background, I delved into molecular visualization and sonification (describing what happens in an atomic simulation by generating descriptive sounds).
Tools are always nice. One can never have too many tools. It is useful to know more than one programming language, so that one can implement a tool in the one that makes most sense. A while ago, as a result of a discussion here at EEVBlog, I created
this example FIR filter response analysis page, as an example of a self-contained HTML+CSS+JavaScript tool, that can be either hosted on the net, or saved to your local computer and used locally without any internet connection. It is a good example of choosing the proper tool (language/environment), as the entire thing is just 372 lines (most of which is the visual HTML and CSS stuff). It is not complete, though, as it was only an example of how such things could be done.
Understanding different programming paradigms is very important, though. For JavaScript on web pages, we use
event-driven programming, because that's how the Document Object Model, the "glue" between HTML and CSS visual description and JavaScript
works. Similarly with UI toolkits like Qt and Gtk+. But for SDL and Curses, we are fully in control, in imperative fashion, of the entire display and refresh loop; as is usual when creating games.
It is not good to specialize early on something. Working on wildly different things exposes you to more ideas, more models, more paradigms, and therefore more problem solving methods, which are definitely needed when you build your developer career. Every week, I still use several different programming languages – shell (my choice is usually Bash, but I do sometimes use Dash, a POSIX shell), awk, C, Python; others vary from week to week depending on what I'm working on – and every week, I learn more. I myself am still learning. One of the things I wish I had learned better early on, is to write better comments: I still need to work a lot on that.
Making errors is often the most interesting facet, if you take the time to find out what went wrong, and why. (I absolutely hate the "stick spaghetti to the wall, and see what sticks" attitude, when someone says that "this fixed it, but I don't know why". To me, it feels like reading a detective story that ends with somebody going to jail but no evidence presented that they were actually the perpetrator. Unsatisfying.) I suspect that the most interesting things I know, I learned by making errors. It is uncomfortable and sometimes painful to err, definitely, but it just makes the satisfaction of solving the problem or completing the work so much more rewarding in the end.
If your personal path is different, don't worry: most paths differ. Just enjoy every step of the way, because the path itself is the purpose and end goal. You are never "done" or "finished learning": there is always something new to discover, learn, invent, solve, or ask.
Oh, and apologies for the wall of text. My excessive verbosity is another thing I'm still working on.
Home
Help
Search
Login
Register
