Amazed by What I Know, Amazed More by What I Don't

[MrCromeDome]

My usual workload has recently lessened, allowing me to get back to work on a perl project I had started some time ago. It usually takes me a day or two to get back into the swing of things when I switch projects, so this time I decided to try something different. I decided to actually learn perl instead of just using it.

I've been a perl user/fan a little bit longer than I have been here on PerlMonks. And while I have received boundless information both here and on the web with regards to perl, I still felt as if I didn't know perl. So I went to Borders, picked up the LLama book, and started reading.

As I was going through the book, I was impressed by a number of things that I had already picked up on. I was much more impressed however by how much I didn't know. While I've always felt that one of my strengths as a programmer was my attention to detail, one of my weaknesses has definitely been not always picking the most efficient solution to the problem. As I look back over some of the code I've already written for this project, I find myself using new (to me) and better ways to do things, as some of what I had done was just plain, umm, wrong :P

Something I had forgotten (or had taken for granted, I'm not sure which) is that every day is a learning experience, that every day I know more than I did the day before. I just don't notice it as much with my usual programming languages/tools (C++, SQL, Powerbuilder) because the rate at which I learn is far less than my rate of learning perl (as I've accumulated a lot more information about those languages than I have about perl to date ;)

What am I getting at? That I think everyday we should be seeking new challenges and knowledge. To stop learning is to stop growing. And I feel that as long as one continues to learn that they will continue to be an effective programmer. As long as I continue to be fascinated by perl, I think that will be for some time to come :) And I hope to be able to give a little more back to a community that has been so good to me.

Thank you, Merlyn, for the excellent book, and for opening my eyes to a wider world of perl. Next time you find yourself in the Chicago area, I owe you a drink :)

MrCromeDome

Update: Meant Llama book, not Camel book. Thanks davorg for catching me ;)

[dragonchild]

I'm immediately put in mind of a Charlie Brown cartoon, when he's looking at a huge set of books with a long face. Marcie comes by and asks him "Why the long face?" His reply is "The more I learn, the more I know what I don't know."

I've always been amazed and heartened at the fact that there's so much about programming (and life!) that I don't know ... that I'll never know. If I knew everything, then life would just be boring! The joy is in the learning, not the knowing.

I commend you on the capability for self-reflection and the strength of character to know (and work to fix) where you're lacking. It's something that I know I have to re-learn every day (and for which I thank my fiancee for having the patience to handle!).

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[drewbie]

...As I was going through the book, I was impressed by a number of things that I had already picked up on. I was much more impressed however by how much I didn't know. While I've always felt that one of my strengths as a programmer was my attention to detail, one of my weaknesses has definitely been not always picking the most efficient solution to the problem. As I look back over some of the code I've already written for this project, I find myself using new (to me) and better ways to do things, as some of what I had done was just plain, umm, wrong :P

I think this paragraph says it all for me. I can pick things up very fast, but I'm always wondering if I did it the best way. But then usually it is fine, so I don't get the opportunity to go back and find the more efficient way.

Looking back at some code I wrote 1.5 yrs ago, I wonder what the heck I was thinking at the time! Experience plays such a huge role in programming because you figure what works and doesn't work. And more importantly, you know how to design something that you can come back to six months later and do maintenance on. :-)

Great writeup.

[one4k4]

...While I've always felt that one of my strengths as a programmer was my attention to detail, one of my weaknesses has definitely been not always picking the most efficient solution to the problem....

I've often felt the same way. And I wonder if it's common among people who have thrown themselves into the fire, so to speak, vs people how have learned before doing. I started programming with TI-Basic, and learned by copying, and playing really. Does somebody who reads everything before writing anything (of sorts) generally program in a more efficient manner? (Off the starting line... before any revies/code checks)

Curious,

_14k4 - [e-mail] (www.poorheart.com)

[dragonchild]

I would say that it's more that someone who has a structured foundation from which to pull tools programs more efficiently from the get-go.

Here's an analogy - anyone can go out and cook a meal. And, they can make modifications to that meal. Sometimes successfully and sometimes ... well, let's just say that the compost pile is sometimes higher than at other timess. However, someone who has a structured foundation in cooking, be it from a school or parents or significant experience, can make changes to known recipes easily. They also know what unspoken changes need to be made to keep a recipe successful. And, they do it faster.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[MrCromeDome]

Or having been thrown into the fire (as I have been from time to time) ;)

For the most part, I've had to do things before learning (if that's how I should say it). I find that for those things that I learn before I try to apply them (C++, in my case), I tend to take a much better approach to things, and that as a whole I produce higher quality work.

On the opposite end of the spectrum, things that I have to learn on my own (SQL, for example), I don't always take the wisest approach the first few times through. When we started writing the new version of our software here, we had all been used to reading through records one at a time from a flat-file scheme (legacy apps/platforms - gotta love em!). So when we first started using a real RDBMS, the first thing we did was use cursors to process rows in our tables one at a time. Little did we realize then how much better performance we'd get using set operations ;)

So, yeah, I think learning before doing makes a difference ;) Sometimes we don't get the luxury of doing so though.

MrCromeDome

[davorg]

If you've just bought a copy of the Camel with merlyn's name on it then I suggest you take it back and demand your money back - the 3rd edition (without merlyn) has been out for well over a year.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you don't talk about Perl club."

[runrig]

But I got it at a great price in the bargain bin :-)