How did you pick up the art of solving real life problems? Can you shortcut the process?

Question

I have been coding on and off on C and to a certain extent on C++ since my college days(2003), but I never had the opportunity to work with a hard core programming responsibility, which could have taught me "industrial grade coding" better and what is needed really for solving real life problems. To me it looks like I had been coding naive codes, like linked lists, binary trees, and Dijkstra and Kruskal's Algos all these years.

Additionally I feel my academic experience just taught me the language not how to solve real life problems.

So my question is:

• So how did you pick up the art of solving real life problems?
• Any way to shortcut the process?
• Is it only my education or in general everyone coding education sucked big time?

• How often do you have to learn "new things" to solve a problem in a better way.

  For example, though I have used delegates and events for simple windows programming, but my current problem will require a much more in depth knowledge of it, plus I have forgotten most of it. So its as good as new for me. I will have to learn threaded programming and multicore programming. So it gives me an impression-"heck then what did I learn really all these years?"

Answer 1

I believe that participating to some C++ free software project with a living community will increase your skills.

I also think that learning a very different language (like Ocaml, Haskell, Common Lisp, Scheme, Clojure, Smalltalk) will change your way of thinking (even on plain C++ code).

And first-class books or courses like SICP could learn you a lot.

You could even consider writing some GCC extensions in MELT which you would find useful. (MELT is a high-level domain specific language, with a Lispy look, to extend the GCC compiler; I am the main author of MELT)

Answer 2

If you really intend to maximize the potential power of C++ then just concentrate on its core applications. Decide for yourself whether you want to utilize your skills in IT or like to do some serious computer science work.Remember whatever you have studied and learnt about programming would never go wasted!Also decide whether you are into writing low-level or system software or aiming for application software. Programming micro-controllers and embedded devices another area where you can also look into.

Visit the inventor's website and check it for yourself, what applications would interest you to look into further either for enhancement or criticism. Here is the link that may interest and can benefit your existing skills further: http://www2.research.att.com/~bs/applications.html

Also look into the potential advantages of other languages like Java for example and try to come up with an idea or product that can benefit you and others.

Answer 3

My advice: keep it simple. Approach every task by splitting it up into pieces and then combine those pieces together in an designed way. (ie design the pieces knowing they'll be working together).

For daily work, real-life problems are always a mixture of all kinds of things. Having problem getting your app to work, maybe its the code... but maybe its the OS, or the DB, or the network. Understanding the basics of all those things means you'll have a much better chance of finding and fixing the problem than if you were totally clueless about how those parts work. This does not mean you have to be an expert, just than you have some understanding. Over time these little bits together will become a much greater resource to you than you expect.

(eg. a real life problem that affected a previous company big time. Performance was bad, there was nothing wrong with the code, but all the devs working on it assumed there was, in the end the problem was shown to be a lack of correct indexes on the DB. Another company had performance problems too, we implemented caches, scoured the code, and determined in the end that it was MTS. Replaced that section with a fixed-config DCOM connection and problem was fixed).

Education v real-life. Yup, it's like that for everyone. I used to see graduates come out and start work with an attitude that they knew everything because they'd written 10,000 line project in their final year and they knew all there was to know. Dump them in front of our 10,000,000 line project and they suddenly realised education was simply a stepping stone to get to the bottom rung of real life work. Don't stress about it, just learn what you need as you go along. FSM knows that everything you know today will be obsoleted by idiots in our 'beloved' industry soon enough anyway.

Answer 4

C++ is older than Java and C#, but is still quite good for serious apps, especially desktop apps. If I can just pass along some of my experience (not limited to C++):

• There are lots of 3rd-party packages, controls, etc. These are two-edged swords. They can give you a lot of features and standardization. The downside is they can upgrade you into trouble (on the theory that you can easily recode your app), or the vendor can go up in smoke.

• OOP is also a two-edged sword. When you need it, it's great. OTOH if you just follow the "religion", you can end up with a monster albatross around your neck. People are encouraged to create more and more classes, intertwined with notifications, delegates, and every hot buzzword in the community. For any given application purpose, there are infinitely many possible code bases that will serve it. Some of them are optimal in maintainability, code size, performance, any dimension of importance. Many many more are wildly non-optimal, and the OOP "best practice", in my experience, leads people strongly toward the latter.

The people who build these tools are justifiably proud of their "power", and they expect that the users of the tools will share that respect and use them to best effect, i.e. sparingly. Unfortunately, the mindset of a tool user can be just the opposite. They may think "This thing is so great, I can use it here, there, and everywhere. Then I'll be really productive." See the disconnect? That's how monstrosities get built.

(As an extreme, and amusing, example, I heard a story once of a Cobol programmer who wrote a SORT (of a dataset) inside an inner loop, because it was "only a single line of code, so it must be fast".)

Answer 5

What you are feeling is pretty common and there are several questions like this around with good answers if you want to search, but to answer your questions:

So how did you pick up the art of solving real life problems?

Experience - What you have learned is not useless, you already know how to write a program to solve a specific problem. When coming from an educational environment you often have the basics of the problem taught to you right before you apply that knowledge. You now have to start researching and teaching yourself about the problem before you try to solve it. This becomes easier as you build your knowledge and can become second nature if you are solving problems in a similar domain all the time.

Any way to shortcut the process?

YES! A mentor of some kind can really cut down on the learning curve, a really good one can teach you not only good ways to solve the current types of problems you are facing, but also good habits and resources to solve any type of problem you are facing.

Is it only my education or in general everyone coding education sucked big time?

I think most employers expect to do extra training for people getting their first full-time programming job, I think most programmers getting their first programming job question their competency and wonder what the heck they spent all that money learning. :-) You'll come to realize how valuable it was in time.

How often do you have to learn "new things" to solve a problem in a better way.

You'll learn tools and tricks that will stick with you and serve you well, but you should always keep an eye and ear out for a better way to do something - read other people's code and other people's answers on the Stack Exchange sites. The programmers I respect most keep growing and keep looking for better ways to do things.

What did you learn all those years? You learned how to learn, how to think, how to tackle a problem, and some good foundation skills.

Answer 6

my advice is to climb the career ladder a little bit. I started out as a C++ dev in the gaming industry. At first it was a great job that got me started in the language, but pretty soon I realized I was capable of 200% of what the people around me were. So I shopped around, moved out of state, found a new industry, and came up to speed. There I took C++ to a new level. I bounced around a little since then, but I always took on new challenges. In reward, my pay has more than doubled since I started in 2006. But honestly I didn't do it for the money, I did it because I craved the challenge and worked hard at it.