So there's a lot of stuff to catch up on mainly because I've been very busy. I switched jobs back in August and moved to Salt Lake City, Utah. I went back to being an Automation/tools engineer rather than doing linux driver development. Why? I'll go over that in another post as it deserves its own topic.
Currently, I'm mostly doing some heavy duty and advanced python (metaclasses, lots of decorators, import machinery hooks, and an asynchronous socket based message system), and pretty soon I'll be working on some C++ code as well. I've been working on some messaging frameworks too (MOM). And lastly, I'm still plugging away at some computer science fundamentals. I haven't touched my data structure project in awhile due to the business of moving and switching jobs, but I intend to get back on it.
In fact, I've been reinspired of late by reading a couple of books. The first is the classic SICP. Although I downloaded a pdf version, it's only the last few days I actually started reading it. I finally got to the part about Normal Order evaluation versus Applicative Order evaluation and I had never considered that before. In addition to the data structures project I have in C++, I figured I'd start working through the SICP problems and solve them either in Racket or Clojure.
While learning more about Scheme, I came across an interesting tutorial/book called "Write Yourself a Scheme in 48hours" which is a guide on how to make a scheme in haskell. I started reading that after finding Real World Haskell and Learn You a Haskell online. I just started getting into Haskell a few days ago, so the syntax is a little odd to me still. Nevertheless, I found it less confusing than 2 or 3 years ago while looking at it. Haskell seemed to come up a lot while I was reading different forums or blogs on Clojure as there seemed to be quite a few comparisons. I still don't quite understand Monads, but what I have seen so far is pretty interesting.
The idea of writing a Scheme in Haskell intrigued me more and more. It seems like there is no language with the set of features that I'd like:
While all of this stuff is fascinating, in the back of mind, there's a nagging little voice that keeps saying, "but is this going to help your career?". Even though all these topics are fascinating, I do sometimes wonder if I wouldn't be better off learning Ruby, Hadoop, some web skills or brushing off my Java. Afterall, that's what employers want. As I've heard many managers say, they want a candidate that can "hit the ground running". This is a sad and unfortunate failure of a corporate culture to think this way.
Literally the last day that I was working at LSI (my old company), I got an email from a recruiter at Google saying he would like to do an interview with me. I was tremendously flattered (not to mention mad at the universe for the quirk of fate that the opportunity didn't present itself a month earlier). About a week later, I got a similar offer for a job interview at Amazon and Facebook both. Although these opportunities were amazing, even had I still been searching for a job, I knew I was not ready for none of these technical giants.
I am not a bad software engineer, but I also believe I lack some strength in fundamentals. What do I mean by that? Software engineering is about more than knowing the intricacies of some programming language, or being a guru at some popular framework or library. IMHO, there's a vast gulf between being a programmer, and being an engineer. Programmers can churn out code. It can even be well thought out and planned code. But it takes a different mindset to know _how_ to tackle a problem in the most efficient and maintainable manner possible.
For example, what are the run time or space time constraints for some algorithm? Given the choice of using some data structure, how will multiple concurrent threads access that data structure? How do you deal with constantly changing inputs to a program, do you write a regex, a parser, or just rewrite your wrappers everytime?
There's a reason Computer Science majors study the basics of computation. In fact, while studying data structures and algorithm analysis is interesting and useful in the real world, there's still far more to it than that. For example, Graph Theory is heavily used to solve many problems, from version control systems to finding paths in a complex data structure. Perhaps it may seem a waste of time to learn about finite automatas, but without them, how do you build regular expressions?
Some might argue that the hard work has already been done. Just grab a PCRE library or some built in library or data structure in your language and do some real work. I've even heard some managers complain of a "research project" mentality. The essence being, if you're not coding, designing, scoping or documenting, you're not working (ie, there's no room for research). I've had quite a few engineers tell me I have a much different philosophy than they do about solving problems. My philosophy is that if I already know a way to solve some problem that would take one hour to implement, but I heard that there's another possible more elegant or more efficient way to solve the problem, but it would take one day to learn and implement, I'd much rather take the day to implement it in the more efficient or elegant way.
Now, the trick is, where's that cut off in terms of practicality/pragmatism and engineering elegance? Management would usually say it's better to implement the rough way first, and then improve it later. Afterall, that's the Agile mantra isn't it? Get something working first, and then make small modifications over time to improve it. The problem is, that is a false dichotomy. The truth is, you rarely have time to ever go back and improve upon a solution. So the old crufty but usable implementation is what stays forever more. As my mom and grandfather used to drill in me, "if you are going to do something, do it right the first time". But that doesn't mean you have to build some grand cathedral or not at all. You can still spend the extra time to learn the better algorithm but implement it in a simple style.
As a simple example, you might be tasked with searching for a value in some data structure. The simplest solution is to create an array and then just search element by element. Simple right? But why not store it in a binary search tree instead? Just a tiny bit more difficulty, but now instead of a O(n) search time, now you have O(log n) search time. A self-taught programmer might not have any clue about binary search trees (I know I didn't when I was teaching myself C++). For a more real world example, if you have a relatively complicated piece of a formally structured data, do you solve the problem with a regex or with some other parser? Take for example the typical example of the get long options in C (and its variants in other languages). In python for example, you might have "-f 10", "--foo 10" or "--foo=10" (and it might even have a default value so it may be missing entirely). So how do you come up with a way to verify all the command inputs are valid, or to programmatically come up with all of them?
There is perhaps a darker side to that nagging little voice in the back of my head that tells me I should be studying some popular web framework. On the one hand, I would eventually like to move back closer to my family in Florida. The problem is, Florida's job market is pretty much either as a web guy (back or front end), a database guy, or something in the military industrial complex. While none of those are particular bad, I don't have the skills in web or database technologies, and the military industrial complex is very fickle from what I have heard. The other insidious little aspect of this annoying voice is that learning frameworks and libraries is the easy part. From my experience, it just takes time and some practice to learn some framework. But learning the fundamentals of CS is _hard_. In fact, I've never been as challenged in my work career as I was in school. I've often found that an interesting conundrum. Why isn't work as hard as school?
So despite that little voice, I will continue on training my fundamentals. I remember many years ago, I was taking a class in Choy Lay Fut, a "modern" kung fu style that was amalgamated from several other styles during the mid 1800s. For two months, literally, all I did was stances; horse stance, bow stance, cat stance, etc. But I knew why the sifu was doing that. Without a solid foundation, it is easy for your opponent to take advantage of you. Everyone wants to get to the kicks and punches and blocks, but without a solid grounding, it's all useless. As another martial arts analogy, I remember while taking Aikido, we were all told to breathe in, relax and in a slightly low posture, the sensei would come by and gently push on the center of our sternum. It was easy to resist. He did this several times, and then one time, he very lightly tapped us on the forehead, and a feather weight touch to our sternum toppled us very easily. Lesson learned....your foundation is all important, and don't let anything distract your mind.
Currently, I'm mostly doing some heavy duty and advanced python (metaclasses, lots of decorators, import machinery hooks, and an asynchronous socket based message system), and pretty soon I'll be working on some C++ code as well. I've been working on some messaging frameworks too (MOM). And lastly, I'm still plugging away at some computer science fundamentals. I haven't touched my data structure project in awhile due to the business of moving and switching jobs, but I intend to get back on it.
In fact, I've been reinspired of late by reading a couple of books. The first is the classic SICP. Although I downloaded a pdf version, it's only the last few days I actually started reading it. I finally got to the part about Normal Order evaluation versus Applicative Order evaluation and I had never considered that before. In addition to the data structures project I have in C++, I figured I'd start working through the SICP problems and solve them either in Racket or Clojure.
While learning more about Scheme, I came across an interesting tutorial/book called "Write Yourself a Scheme in 48hours" which is a guide on how to make a scheme in haskell. I started reading that after finding Real World Haskell and Learn You a Haskell online. I just started getting into Haskell a few days ago, so the syntax is a little odd to me still. Nevertheless, I found it less confusing than 2 or 3 years ago while looking at it. Haskell seemed to come up a lot while I was reading different forums or blogs on Clojure as there seemed to be quite a few comparisons. I still don't quite understand Monads, but what I have seen so far is pretty interesting.
The idea of writing a Scheme in Haskell intrigued me more and more. It seems like there is no language with the set of features that I'd like:
- immutable data structures by default (not in Racket)
- "native" continuations (not in haskell or clojure)
- lazy evaluation by default (not in clojure, possible in Racket)
- STM implementation (AFAIK, not in Racket)
- lisp style macros and homoiconicity (not truly available in haskell)
- C(++) ABI compatibility (none with c++, hardest to do in clojure )
While all of this stuff is fascinating, in the back of mind, there's a nagging little voice that keeps saying, "but is this going to help your career?". Even though all these topics are fascinating, I do sometimes wonder if I wouldn't be better off learning Ruby, Hadoop, some web skills or brushing off my Java. Afterall, that's what employers want. As I've heard many managers say, they want a candidate that can "hit the ground running". This is a sad and unfortunate failure of a corporate culture to think this way.
Literally the last day that I was working at LSI (my old company), I got an email from a recruiter at Google saying he would like to do an interview with me. I was tremendously flattered (not to mention mad at the universe for the quirk of fate that the opportunity didn't present itself a month earlier). About a week later, I got a similar offer for a job interview at Amazon and Facebook both. Although these opportunities were amazing, even had I still been searching for a job, I knew I was not ready for none of these technical giants.
I am not a bad software engineer, but I also believe I lack some strength in fundamentals. What do I mean by that? Software engineering is about more than knowing the intricacies of some programming language, or being a guru at some popular framework or library. IMHO, there's a vast gulf between being a programmer, and being an engineer. Programmers can churn out code. It can even be well thought out and planned code. But it takes a different mindset to know _how_ to tackle a problem in the most efficient and maintainable manner possible.
For example, what are the run time or space time constraints for some algorithm? Given the choice of using some data structure, how will multiple concurrent threads access that data structure? How do you deal with constantly changing inputs to a program, do you write a regex, a parser, or just rewrite your wrappers everytime?
There's a reason Computer Science majors study the basics of computation. In fact, while studying data structures and algorithm analysis is interesting and useful in the real world, there's still far more to it than that. For example, Graph Theory is heavily used to solve many problems, from version control systems to finding paths in a complex data structure. Perhaps it may seem a waste of time to learn about finite automatas, but without them, how do you build regular expressions?
Some might argue that the hard work has already been done. Just grab a PCRE library or some built in library or data structure in your language and do some real work. I've even heard some managers complain of a "research project" mentality. The essence being, if you're not coding, designing, scoping or documenting, you're not working (ie, there's no room for research). I've had quite a few engineers tell me I have a much different philosophy than they do about solving problems. My philosophy is that if I already know a way to solve some problem that would take one hour to implement, but I heard that there's another possible more elegant or more efficient way to solve the problem, but it would take one day to learn and implement, I'd much rather take the day to implement it in the more efficient or elegant way.
Now, the trick is, where's that cut off in terms of practicality/pragmatism and engineering elegance? Management would usually say it's better to implement the rough way first, and then improve it later. Afterall, that's the Agile mantra isn't it? Get something working first, and then make small modifications over time to improve it. The problem is, that is a false dichotomy. The truth is, you rarely have time to ever go back and improve upon a solution. So the old crufty but usable implementation is what stays forever more. As my mom and grandfather used to drill in me, "if you are going to do something, do it right the first time". But that doesn't mean you have to build some grand cathedral or not at all. You can still spend the extra time to learn the better algorithm but implement it in a simple style.
As a simple example, you might be tasked with searching for a value in some data structure. The simplest solution is to create an array and then just search element by element. Simple right? But why not store it in a binary search tree instead? Just a tiny bit more difficulty, but now instead of a O(n) search time, now you have O(log n) search time. A self-taught programmer might not have any clue about binary search trees (I know I didn't when I was teaching myself C++). For a more real world example, if you have a relatively complicated piece of a formally structured data, do you solve the problem with a regex or with some other parser? Take for example the typical example of the get long options in C (and its variants in other languages). In python for example, you might have "-f 10", "--foo 10" or "--foo=10" (and it might even have a default value so it may be missing entirely). So how do you come up with a way to verify all the command inputs are valid, or to programmatically come up with all of them?
There is perhaps a darker side to that nagging little voice in the back of my head that tells me I should be studying some popular web framework. On the one hand, I would eventually like to move back closer to my family in Florida. The problem is, Florida's job market is pretty much either as a web guy (back or front end), a database guy, or something in the military industrial complex. While none of those are particular bad, I don't have the skills in web or database technologies, and the military industrial complex is very fickle from what I have heard. The other insidious little aspect of this annoying voice is that learning frameworks and libraries is the easy part. From my experience, it just takes time and some practice to learn some framework. But learning the fundamentals of CS is _hard_. In fact, I've never been as challenged in my work career as I was in school. I've often found that an interesting conundrum. Why isn't work as hard as school?
So despite that little voice, I will continue on training my fundamentals. I remember many years ago, I was taking a class in Choy Lay Fut, a "modern" kung fu style that was amalgamated from several other styles during the mid 1800s. For two months, literally, all I did was stances; horse stance, bow stance, cat stance, etc. But I knew why the sifu was doing that. Without a solid foundation, it is easy for your opponent to take advantage of you. Everyone wants to get to the kicks and punches and blocks, but without a solid grounding, it's all useless. As another martial arts analogy, I remember while taking Aikido, we were all told to breathe in, relax and in a slightly low posture, the sensei would come by and gently push on the center of our sternum. It was easy to resist. He did this several times, and then one time, he very lightly tapped us on the forehead, and a feather weight touch to our sternum toppled us very easily. Lesson learned....your foundation is all important, and don't let anything distract your mind.
Haskell has a native implementation of continuations :) https://wiki.haskell.org/Continuation
ReplyDelete