+972 52-548-6969
As to the methods there may be a million, but principles are few
I run across the following quote a while ago, and I found it quite interesting.
“As to the methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”
- Ralph Waldo Emerson (1803-1882)
I have been programming, in one form or another, for about fifteen years, but I can put my finger on the precise moment in which I moved from a mere dabbler to a professional. That was in 1999, and I decided that I had enough of toying with Pascal, VB6 & Java Applets. It was the height of the bubble, and I wanted to learn just enough to be able to get a job doing something that I enjoyed. I had about a year opened to me, and I registered myself to a C/C++ course in a local college.
In hindsight, that was one of the best things that I have ever done. That course taught me C and pointers, and then C++ and OO. I also introduced me to concepts that I have been using ever since. Admittedly, I don’t want to look at any of my code from that time period, but that is probably a good thing :-) The most important part of the course was that it taught me how computers work, by introducing C first and forcing me to write my own implementation of any system call that I wanted to make.
I studied programming in High School as well, and I distinctly remember being utterly and completely baffled by strange things like dynamic memory and pointers. I mean, why don’t you just allocate a bigger array. During that course I actually grasped pointers for the first time, and even looking back over the last couple of weeks, a lot of my performance work recently is directly based on things that I learned there.
After completing that course, I got several books to help me understand the fundamentals better. Operating Systems Design and Implementation, Modern Operating Systems and Operating System Concepts to understand how an operating system works, not just a single program. Win32 System Programming, which I read mainly to understand the environment in which I was working and Windows Sockets Network Programming, from which I learned the basic concepts of networking.
The common thread throughout all of them is that initially I focused on understanding the technical environment in which I was working, getting to understand how things are working at a very low level. And while it may appear that understand those low level details would be nice in terms of general education but have little relevance to where I am spending most of my time, that is quite inaccurate. The recently built serialization system built for the profiler was heavily influenced from my reading of the OS books, for example.
For that matter, other good books are Practical File System Design, talking about the BeOS file system, which I found utterly fascinating or Virtual Machine Design and Implementation C/C++ which is a horrible book, but one that gave me the confidence to do a lot of things, since I saw how trivially simple it was to build such things.
Coming back to the quote in the beginning of this post, understanding the underlying principles has allowed me to do approach a new technology with the confidence that I understand how it must work, because I understand the environment in which it works. Oh, there are a lot of details that you need to get, but once you have the conceptual model of a technology in mind, it is so much easier to get to grips with it.
Interestingly enough, I only got to software design books at a much later stage, and even today, I find the low level details quite fascinating, when I can get new material in a subject that is interesting to me.
Comments
I agree about understanding the low-level fundamentals, as well as the context of work. That is why I prefer hiring people with engineering degrees (as opposed to self-taught developers for example). (I'm also a bit of an elitist).
I find that engineers, especially electrical engineers, have a very good grasp of the fundamentals (besides problem solving), and have a more rounded and diverse education.
I agree, the fundamental are so important especially once you reach a certain level. Since you are such a smart guy I think you should take up on a functional language... Maybe extremely robust system are build on top of them. Because they require a totally different set of thinking they can open you up to many different possibilities...
Joshua,
I am self taught :-)
Firefly,
Checkout my Erlang & CouchDB posts
Sure, but you're exceptional. You have the initiative to find out the things you don't know. (I concede that any non-engineer with that trait would likely exhibit the same).
Anyway, my post is a generalisation, but I still think it's a valid point.
Actually, since you took that C/C++ course, would you still consider yourself self-taught? :)
A single course doesn't make a developer. It gave me a good grasp of the basics, but I learned a lot on my own
Fair enough.
Then let me rather say that I find qualified engineers come with the grasp of fundamentals already, i.e. they have to do a lot less self-learning to gain that information.
I guess essentially I mean that knowing someone has an engineering degree is a reasonable yardstick, and is a good indicator of someone having that fundamental knowledge, as opposed to assessing it during an interview etc.
Joshua, no degree can indicate that someone has or not problem solving skills and the will to learn new things...
Question I have is, if Java/C#/F# can replace the C/C++ route in 2010 to help grasp principles?
@Joshua I disagree with you. Degree badge proves nothing. It's all about ones will and ability to learn.
@Ayende Thanks for inspiration.
@ Arnis, it proves the abilities of one to put up with a lot of craps :)))
Even though I program against frameworks at a higher level, I am always interested in the low level details of how things work, like protocols for example.
Up until now it has served me well, because once in a while you run into a problem, where you actually need to know how things actually work, instead of only knowing how to use the high level framework.
It also helps me understanding new frameworks faster, since I already understand the basics of what they are trying to wrap.
This discussion on degrees reminds me the old adage "No one ever got fired for buying IBM".
Anyway I was wondering where your knowledge came, now I've my answer :)
In my experience a good engineering school will teach you the fundamentals. It will not make you a good developer but will provide the potential to be one.
@Arnis L.
True. But not having a badge gets your resume thrown in the trash when they make the first cut during these difficult times. There are simply too many badged people, and many with a "post graduate badge."
The "badge" is exactly what Joshua Lewis states, a marker that signifies some degree of competence. That's why we license people such as real estate brokers, accountants, lawyers, doctors, pest control people, and the list goes on forever.
Getting licensed - errrr badged - is simply a manner to state to those you present yourself to, that you have mastered a certain level of skill as testified to by the "badger."
Sounds like your talking about the law of leaky abstractions. Sometimes its useful to know what is going on with the system that you are dealing with www.joelonsoftware.com/.../LeakyAbstractions.html
Consider me chagrined.
I agree completely that having a degree is often no indication of competence.
When I consider things like networking, von Neumann machine architecture and even data structures etc, I think that (electrical) engineering degrees at least expose you to those kind of things, whereas non-engineers can not be guaranteed to know about such things.
It is true that being exposed to these things is also no guarantee that the person was listening in class that day (I qualified with many of that kind of person).
I believe it is also true that even the above-average developer does not necessarily need to know about these low-level issues to do well in his everyday job. That's why we have garbage collected languages, 'automatic capacity' data structures like generic Lists, serialisation etc.
Comment preview