Transforming theoretical knowledge into practical knowledge

Question

I have got good grades and ~ 10 years of professional embedded s/w development. However I have come to realize that and also been pointed out in performance appraisals that although I have good theoretical knowledge and have even read lots of programming books - Code complete, pragmatic programmer etc.. , my hands on practical knowledge is weak and I am unable to translate my theoretical ability into practical expertise. I need to figure out a plan on how to do this. Any ideas in this regard? EDIT : I take too long in understanding specs and in developing code and and miss some aspects in development particularly domain knowledge.

Answer 1

The simple truth is that in order to gain practical programming experience, you have to actually program.

While theoretical knowledge is great in guiding you toward solid, efficient and proven solutions, many facets of programming cannot be learned from a book (and I believe this to be true for any craft). There are no shortcuts. A master violinist has inevitably done over 10,000 hours of dedicated practice; a master chef has spent over 10,000 hours in the kitchen; to become a master programmer, you probably have to spend over 10,000 hours writing code.

If you want to be good at anything, exercise. Write code, lots of it, and try to keep it challenging at all times - aim at a difficulty just at the top of your reach. If you do the same thing over and over, the benefit will rapidly decrease after the first few rounds, so aim for (partially) unknown terrain with every new project. BTW, it is OK to not finish most of your projects: once you feel there's nothing more to learn for you on this particular project, leave it and start a new one - just keep in mind that actually finishing a project is a crucial skill, and you will need to learn it at some point.

Additionally:

• Read other people's code (open source projects are a great way to find suitable code). You don't need to read the entire linux kernel code top-to-bottom; rather, pick one aspect of one program that you find particularly interesting ("I wonder how they did this"), and try to answer your questions from the original sources.
• Fix other people's bugs. You may not be in a situation to do this, but if you are, finding and fixing bugs in code you didn't write is a great way to dive deeply into an unknown codebase, and you learn an incredible lot from it.
• Revisit your own code from a few months back. See if you can still make sense of it (if you can't, ask yourself how you should have written the code back then, and try to bake this into rules-of-thumb for yourself). Think about how you would solve the same problem now, with all the knowledge you have acquired in the meantime.
• Read books and blogs about how top programmers think about and approach programming.
• Learn more than one programming language (but be sure to be somewhat fluent in your first language before tackling another). Ideally, you should cover a broad range of idioms with the languages you learn: low level to high level, various paradigms (imperative / structured programming, object-oriented, functional, etc.), dynamically typed vs. statically typed, strongly-typed vs. weakly-typed, etc.

Keep one thing in mind, though: There is no replacement for actually doing the thing you want to learn, so program. A lot.

Answer 2

Practical knowledge is really just another way of saying 'experience'.

There's only one way to get experience, and that's why experiencing things - working, writing code, starting and completing projects.

Also keep in mind the old question

Is that 10 years experience, or is it 1 year experience 10 times over?

In other words, if you keep 'experiencing' the same things then you aren't gaining any new experience.

Answer 3

I take too long in understanding specs and in developing code and and miss some aspects in development particularly domain knowledge.

Someone else must be gathering specs which leaves you out of the loop on understanding the domain. You need to take some time to have people teach you about what they do and why they do it. I've been asked to do some software training, but I'm also taking time to learn more about the domain. This will help both sides when it comes to new feature requests. Looking over a user's shoulder and asking questions is beneficial as well. Ask to read other documentation like office manuals or literature in the area. Read the websites your users read.

As much as you may not be interested in the domain information, you'll need to force yourself to learn it or suffer the consequences in your reviews.

Answer 4

If you have studied for a long amount of time without actually practicing programming you've missed out a great part. The best and best way to learn is not theoretically, but practically. Most programmers you will ask "What is a good way of learning X language?" they will tell you to write some code in it.

If you've never written code but learned theory you should try to put into practice what you've learned as soon as possible, get a compiler or an IDE for the respective language and get to work.

As long as you know some theory you should be alright, but if you still find that you are lacking many things so far, you should start from scratch and learn that language WHILE practicing it. Recap what you've learned, expressions, basics, systems, structures, etc and write them in code. The best way of learning practical programming is by actually doing it.

Answer 5

There is an old joke: "How do you get to Carnegie Hall?"... "Practice".

Pick a programming language you want to work with and go here:

http://projecteuler.net/

Write programs to solve the puzzles... and practice.