OK, I just spent two hours searching for my wallet.
Why do I check the trash?
Why do I always have the sneaky suspicion that I put it in the freezer?
Why did I check the trash again?
Well, the mystery is solved. It was under my wife's pillow. Go figure.
Tuesday, March 8, 2011
Monday, March 7, 2011
On writing your own programming language
In about three days, you can push out your own programming if you are a master at recursion, understand parsers, understand tree transformations, and have a good grasp on the goals of programming.
Problematically, a programming language is a small thing. The next step is the tools and the platform. This will take about one to three years to build.
Now, once the platform is built, it will take about two to ten years to market it provided the right people pick it up. This how Ruby went from obscure to mainstream, and this is why I give DHH mad props since he put a huge surge into Ruby.
I had spent about 1.5 years working on my platform for my programming language, and I had shipped web properties on it. Then I killed it.
I killed it because I realized the world didn't need yet another shitty programming language. It was categorically shitty because I didn't build it to be marketable and the problem it was solving was kind of silly to the market place and my ability to support it.
Basically, the idea was to build a programming language around a statically typed schema and then provide a language integrated query language similar to SQL in such a way that it could automate scalability.
It's extremely intellectually satisfying problem to work on, but it was a poor use of my time. However, I believed (and still believe) that the problem is worthwhile. It was intoxicating to work with statically typed SQL with a statically typed schema and then solve the induced persistence problem with replication and automated infrastructure management tools.
Over all, the experience was wonderful. I recommend anyone capable or willing to start to write a programming language. Once it is built, then you will see a lifetime of work ahead of you since it will never be finished.
Lessons Learned.
Working on the problem lead ultimately to dealing with replication at a serious level. Replication is non-trivial, and the CAP theorem is a harsh mistress. It's very easy to get going and then the shit will hit the fan, and then you are screwed.
Building a taxonomy of how different patterns in SQL lead to different types of systems gives a greater appreciation and understanding of the NoSQL movement. I am fully confident that in the next five years, we will have some very interesting solutions that enable a agile database movement. The entire process also gave me insight into why SQL really does suck and is very limited.
I also built my own map reduce framework which gave me a greater understanding of how to solve problems with MapReduce. I basically did a differential on a "join space". I would use relations to build a "join space" by using joins and then map a function on the changes. This looked very similar to how you can do MapReduce in CouchDB, but mine sucked. Actually, mine was terrible in comparison.
I invented my own heroku like interface for launching back-ends. It's fairly easy with AWS to automate your entire infrastructure management. I'm kicking myself for now launching a product off of it. It's wicked cool to push a button and have three MySQL servers pop up and connect to each other. It's even more wicked cool to see shards re-balance and push data into the new servers.
I added closures to PHP in a way that enabled you to serialize the closure to Amazon's SimpleQueue. While it was only a true closure in memory, it was very neat to add asynchronous processing to PHP. A simple C + curl driver would launch and basically run the event loop in apache2.
Documenting a programming language's more esoteric features can be hard since you have to teach new ways of thinking. This is why I generally avoid a DSL in most production environments. Generally, the process of building the DSL will give you enough insight to make a rock solid library.
People really hate static typing, and if you want to build a statically typed programming language, then it is going to cost a lot of money. Most of the commercial used statically typed programming languages have companies behind them with deep pockets; I don't think this is a accident.
Problematically, a programming language is a small thing. The next step is the tools and the platform. This will take about one to three years to build.
Now, once the platform is built, it will take about two to ten years to market it provided the right people pick it up. This how Ruby went from obscure to mainstream, and this is why I give DHH mad props since he put a huge surge into Ruby.
I had spent about 1.5 years working on my platform for my programming language, and I had shipped web properties on it. Then I killed it.
I killed it because I realized the world didn't need yet another shitty programming language. It was categorically shitty because I didn't build it to be marketable and the problem it was solving was kind of silly to the market place and my ability to support it.
Basically, the idea was to build a programming language around a statically typed schema and then provide a language integrated query language similar to SQL in such a way that it could automate scalability.
It's extremely intellectually satisfying problem to work on, but it was a poor use of my time. However, I believed (and still believe) that the problem is worthwhile. It was intoxicating to work with statically typed SQL with a statically typed schema and then solve the induced persistence problem with replication and automated infrastructure management tools.
Over all, the experience was wonderful. I recommend anyone capable or willing to start to write a programming language. Once it is built, then you will see a lifetime of work ahead of you since it will never be finished.
Lessons Learned.
Working on the problem lead ultimately to dealing with replication at a serious level. Replication is non-trivial, and the CAP theorem is a harsh mistress. It's very easy to get going and then the shit will hit the fan, and then you are screwed.
Building a taxonomy of how different patterns in SQL lead to different types of systems gives a greater appreciation and understanding of the NoSQL movement. I am fully confident that in the next five years, we will have some very interesting solutions that enable a agile database movement. The entire process also gave me insight into why SQL really does suck and is very limited.
I also built my own map reduce framework which gave me a greater understanding of how to solve problems with MapReduce. I basically did a differential on a "join space". I would use relations to build a "join space" by using joins and then map a function on the changes. This looked very similar to how you can do MapReduce in CouchDB, but mine sucked. Actually, mine was terrible in comparison.
I invented my own heroku like interface for launching back-ends. It's fairly easy with AWS to automate your entire infrastructure management. I'm kicking myself for now launching a product off of it. It's wicked cool to push a button and have three MySQL servers pop up and connect to each other. It's even more wicked cool to see shards re-balance and push data into the new servers.
I added closures to PHP in a way that enabled you to serialize the closure to Amazon's SimpleQueue. While it was only a true closure in memory, it was very neat to add asynchronous processing to PHP. A simple C + curl driver would launch and basically run the event loop in apache2.
Documenting a programming language's more esoteric features can be hard since you have to teach new ways of thinking. This is why I generally avoid a DSL in most production environments. Generally, the process of building the DSL will give you enough insight to make a rock solid library.
People really hate static typing, and if you want to build a statically typed programming language, then it is going to cost a lot of money. Most of the commercial used statically typed programming languages have companies behind them with deep pockets; I don't think this is a accident.
Sunday, March 6, 2011
Working Hard versus Working Smart
Working smart is very hard, and most people don't do it. People will work hard doing smart things, but doing smart things hard is not working smart. Working smart requires being intelligent, effective, and efficient. Combine all three with good sleep, and you will win.
Increasing Intelligence
I believe intelligence increases over your lifetime provided you are pushing the boundaries of what you know and what you can do. If you do the same thing for 10 years, then you are not changing. However, if you spend the evening working on math puzzles and Wikipedia, then you are learning something and increasing something.
People like to have a fixed concept of intelligence as if you are born with it. This is a psychological defense of their own laziness since learning is painful for many people. I argue that intelligence is defined by the work you put into it.
Intelligence will ultimately define the level of work you can do.
Increasing Effectiveness
Spend time working on the right things rather than just spending time on work. Being effective is hard because there is temptation to work on other things that appear important.
In the land of start-ups, the key to being effective is to make sure the business state progresses every day. This means that the task you are working on must
(a) increase revenue
(b) enable the business side to iterate
(c) make a customer happy
(d) decrease costs
(e) find customers
If the task you are working on doesn't help any of these, then it probably isn't effective. Each organization or project has similar questions. I like to think of each task as a vector and the organization/project goal is another vector. Effectiveness is just maximizing the dot product between the two.
The key to being effective is to understand what the goals of what you are working on and how that relates to the sea of tasks in front of you.
Increasing Efficiency
This is the easiest to increase of all three. This is where you make a massive todo list and you just start grinding on it. I make multidimensional TODO lists and batch things together using a gray code of sorts. The key here is not to estimate the time per task and instead say each task should take about a minute, and then just go. This avoids Parkinson's Law. The key is that when things take longer than you expect is to take notes on the problem and then move on to the next item.
This is how I used to hack exams in college. It was easy to grind on all the easy questions whilst my mind thought more deeply about the hard problems.
The same is true for any workload. Get all the easy stuff done and then focus on the hard stuff. I try to load it up so I go to sleep for the hard stuff. I often just wake with answers and spend a couple of minutes writing the solutions out. Sleep is very effective for solving hard problems.
Sleep
I think our work schedules suffer from a severe problem in enabling creativity. We shouldn't work in the morning and then play in the evening. We should play in the morning and then work our ass of until we need sleep. Then, get to sleep as soon as possible.
When I was in hard-core start-up land, my schedule was 12 hours of work followed by 4 hours of sleep. This enabled me to solve gnarly problems all over the place. I would wake up with stunning solutions to problems.
Increasing Intelligence
I believe intelligence increases over your lifetime provided you are pushing the boundaries of what you know and what you can do. If you do the same thing for 10 years, then you are not changing. However, if you spend the evening working on math puzzles and Wikipedia, then you are learning something and increasing something.
People like to have a fixed concept of intelligence as if you are born with it. This is a psychological defense of their own laziness since learning is painful for many people. I argue that intelligence is defined by the work you put into it.
Intelligence will ultimately define the level of work you can do.
Increasing Effectiveness
Spend time working on the right things rather than just spending time on work. Being effective is hard because there is temptation to work on other things that appear important.
In the land of start-ups, the key to being effective is to make sure the business state progresses every day. This means that the task you are working on must
(a) increase revenue
(b) enable the business side to iterate
(c) make a customer happy
(d) decrease costs
(e) find customers
If the task you are working on doesn't help any of these, then it probably isn't effective. Each organization or project has similar questions. I like to think of each task as a vector and the organization/project goal is another vector. Effectiveness is just maximizing the dot product between the two.
The key to being effective is to understand what the goals of what you are working on and how that relates to the sea of tasks in front of you.
Increasing Efficiency
This is the easiest to increase of all three. This is where you make a massive todo list and you just start grinding on it. I make multidimensional TODO lists and batch things together using a gray code of sorts. The key here is not to estimate the time per task and instead say each task should take about a minute, and then just go. This avoids Parkinson's Law. The key is that when things take longer than you expect is to take notes on the problem and then move on to the next item.
This is how I used to hack exams in college. It was easy to grind on all the easy questions whilst my mind thought more deeply about the hard problems.
The same is true for any workload. Get all the easy stuff done and then focus on the hard stuff. I try to load it up so I go to sleep for the hard stuff. I often just wake with answers and spend a couple of minutes writing the solutions out. Sleep is very effective for solving hard problems.
Sleep
I think our work schedules suffer from a severe problem in enabling creativity. We shouldn't work in the morning and then play in the evening. We should play in the morning and then work our ass of until we need sleep. Then, get to sleep as soon as possible.
When I was in hard-core start-up land, my schedule was 12 hours of work followed by 4 hours of sleep. This enabled me to solve gnarly problems all over the place. I would wake up with stunning solutions to problems.
Saturday, March 5, 2011
On Learning Recursion
A question on quora got me thinking about how bad we computer scientists teach recursion.
I claim programmers work day to day in environments that use recursive thinking, so understanding recursion is very important stuff.
We can easily try to teach things like fractals, hanoi, fibonacci, tri-ominos, factorials, and more. These are all nice and beautiful mathematical facts/puzzles, but they are bullshit and I don't think they help teach recursion. I claim they are bullshit because they are too nice of results and they don't show any scaffolding involved in how they were constructed or why it is that way.
Recursion ultimately boils down to "If I can do something on something smaller and I can combine smaller things into the bigger result, then I can compute on things that are huge."
It is a powerful tool, and I think the best way to learn and master recursion is to write a programming language. When you understand how a programming language works, then I further claim you will produce a lot less bugs and have a greater understanding of what your code is doing.
Recursion is akin to mathematical induction in the form of structural induction. Problematically, if you take a computer science course, then you will start with the math. While this is great in theory, most people have a shaky and incomplete foundation in mathematics. So, the mathematical approach to teaching recursion isn't going to be a wild success. I claim that a good understanding of recursion enables people to be more effective in functional programming (and thus programming in general).
Having complained and made many wild claims, I started a github repo on teaching recursion by writing a simple computational language which I may extend in the future. For now, it provides a simple parser and an eval() function and how to use it to write a graphing calculator. Each branch in the repo is a stopping point with the master branch containing the final lesson. It has 3 lessons now which give me a warm fuzzy feeling on the inside.
Update: check out Structure and Interpretation of Computer Programs if you are serious about learning how to write a programming language. I'm just a hack when compared to the authors of that great book.
I claim programmers work day to day in environments that use recursive thinking, so understanding recursion is very important stuff.
We can easily try to teach things like fractals, hanoi, fibonacci, tri-ominos, factorials, and more. These are all nice and beautiful mathematical facts/puzzles, but they are bullshit and I don't think they help teach recursion. I claim they are bullshit because they are too nice of results and they don't show any scaffolding involved in how they were constructed or why it is that way.
Recursion ultimately boils down to "If I can do something on something smaller and I can combine smaller things into the bigger result, then I can compute on things that are huge."
It is a powerful tool, and I think the best way to learn and master recursion is to write a programming language. When you understand how a programming language works, then I further claim you will produce a lot less bugs and have a greater understanding of what your code is doing.
Recursion is akin to mathematical induction in the form of structural induction. Problematically, if you take a computer science course, then you will start with the math. While this is great in theory, most people have a shaky and incomplete foundation in mathematics. So, the mathematical approach to teaching recursion isn't going to be a wild success. I claim that a good understanding of recursion enables people to be more effective in functional programming (and thus programming in general).
Having complained and made many wild claims, I started a github repo on teaching recursion by writing a simple computational language which I may extend in the future. For now, it provides a simple parser and an eval() function and how to use it to write a graphing calculator. Each branch in the repo is a stopping point with the master branch containing the final lesson. It has 3 lessons now which give me a warm fuzzy feeling on the inside.
Update: check out Structure and Interpretation of Computer Programs if you are serious about learning how to write a programming language. I'm just a hack when compared to the authors of that great book.
Friday, March 4, 2011
Computing as a drug; me the addict
I think my profession is all about getting a high from solving puzzles.
I love puzzles, and I'm an addict. I once missed a week of courses because I discovered the 5 x 5 x 5 Rubik cube. My math professors didn't mind as they were very understanding to my needs, and I was fortunate to not be taking any humanities during that semester.
My current fix is on distributed computing, and I find it fascinating.
During college, I was interested in game engines as it focuses on performance. Performance is a great way to get high since you know the theoretical capabilities of your hardware, so how do you hit those numbers? How do you degrade quality to gain performance? How do optimize away computation? It is a performance junkie's dream problem.
When I did my start-up, I was obsessed with Scalability (when I should have spent more time marketing) and technical execution. Scalability problems (even if invented) are pure crack. The reason is that there is no upper bound. With the game engine, the bound was given by the video card (i.e. you win when it shuts off from too much heat).
Ultimately, distributed computing comes into play to solve the scalability problems. However, scalability isn't the crazy fun part. The crazy fun part is when you accept the fact that any part of your network may fail.
This is a cognitive fail for me since I expect and make the assumption that my machine just works. I write programs that execute a series of commands, it should always terminate. What happens if mother nature pre-terminates your program? Can it resume?
Once you figure out how to deal with fail, you have to scale. Once you figure out how to scale, you have to perform. Once it performs, you need to extend. Now, rinse and repeat. Maybe you need a big rewrite? Who knows.
This is why computing can be bad for you, it never ends. The complexity/puzzles just add up (which is excellent for my profession).
Now, there was going to be a point to this blog post, but I forgot.
I love puzzles, and I'm an addict. I once missed a week of courses because I discovered the 5 x 5 x 5 Rubik cube. My math professors didn't mind as they were very understanding to my needs, and I was fortunate to not be taking any humanities during that semester.
My current fix is on distributed computing, and I find it fascinating.
During college, I was interested in game engines as it focuses on performance. Performance is a great way to get high since you know the theoretical capabilities of your hardware, so how do you hit those numbers? How do you degrade quality to gain performance? How do optimize away computation? It is a performance junkie's dream problem.
When I did my start-up, I was obsessed with Scalability (when I should have spent more time marketing) and technical execution. Scalability problems (even if invented) are pure crack. The reason is that there is no upper bound. With the game engine, the bound was given by the video card (i.e. you win when it shuts off from too much heat).
Ultimately, distributed computing comes into play to solve the scalability problems. However, scalability isn't the crazy fun part. The crazy fun part is when you accept the fact that any part of your network may fail.
This is a cognitive fail for me since I expect and make the assumption that my machine just works. I write programs that execute a series of commands, it should always terminate. What happens if mother nature pre-terminates your program? Can it resume?
Once you figure out how to deal with fail, you have to scale. Once you figure out how to scale, you have to perform. Once it performs, you need to extend. Now, rinse and repeat. Maybe you need a big rewrite? Who knows.
This is why computing can be bad for you, it never ends. The complexity/puzzles just add up (which is excellent for my profession).
Now, there was going to be a point to this blog post, but I forgot.
Monday, February 28, 2011
Going Homeless and Living in the Computer Science Building
Story
Most of my friends know that during 2006 - 2007, I went homeless and lived in Nichols Hall at Kansas State University. Oddly enough, one of my friends at Kansas University went homeless too except he got caught after three weeks. I was homeless at K-state until I left graduate school (about a year).
At the time, I was both a graduate teaching assistant in Mathematics and a graduate research assistant in Computer Science. I had a full work-load, and I wanted to work more. I had a little cubicle in Cardwell Hall with other graduate students, and I had mine filled with books and my behemoth of a computer.
When I would retire for the evening, I would walk to Nichols and blow up my air-matress (had an automated pump) and lay my bones to rest.
In the morning, I would wake to the sound of students rushing about. I would head over to class and teach students some math and answer questions. After which, I walked or biked over to the Rec where I would take my shower (with a bunch of naked old guys).
Tip: old men are not shy and will wave/shake their cocks high and proud. Once, I was putting on my shoes and I got boxed in my two chatting old men. Too both my left and my right were two old cocks. While this was awkward, it did make me appreciate my youth and fearful of aging.. Eww.
After my shower, I would get on with my homework, my research, or my projects. Occasionally, a student would ask for help. I had the most hard-core office hours out of all professors and other GTAs. It was from 9am to 9pm. How can anyone not make those hours? Well, they didn't because they were lazy. However, one student did take my offer seriously and I mentored him from a D student to a B student where I gave him an A for effort. He then earned a righteous A in the next course. It is an awesome feeling to have actually helped another human being a serious setting as he was on the verge of dropping out; now, he is an electrical engineer doing amazing things.
Before I went homeless, I had stuff. I hate stuff as it just accumulates and then needs to be moved for no good reason. I developed an algorithm using a self-storage unit where I put everything into my unit and then would bring stuff I needed into my car. Beyond some books and clothes, I didn't need anything. After six months, I just started giving stuff away. Free 36" TV? it went to a gentleman by the name of Kyle. GameCube and a bunch of games? It went to a gentleman by the name of Brad. Salvation Army got about $4K of goods, and I sold $500 worth of stuff at a pawn shop. I kept my books, computer, and paperwork.
Having spent an entire semester homeless, I decided that it was stable. But then I decided to take the path of a start-up technology co-founder. So, I lived at our first office which was an apartment (that we kind of ran out of room). However, I was not on the lease, so I was technically still homeless.
I got my own apartment when I found my woman Effie (who is now my Wife).
Thoughts
All you need in life is an air-matress (which is optional if you tune your body to hard surfaces), food, a woman (or a man), two songs, and work. Sometimes, I would play, but play is just another form of work. A car is nice too.
I'm fortunate to find joy in Mathematics and Computing.
Sleeping outside is a lot of fun. Sleeping in my car was fun until my back started hurting. Sleeping on top of my car was very fun (again, until my back started hurting). Sleeping naked in a field is way awesome.
Blasting movies/music/video games in the Math building at odd hours is really fun. You can't do this at an apartment building.
When work ends naturally, taking time to smell the flowers and watch the world in motion is very relaxing. Going homeless enabled me to catch up on both my homework and my research, this gave me the time to go sit in the quad and watch the machinery of university and appreciate the groundskeepers.
Buying people lunch is fun.
Having plenty of time to enjoy campus is awesome.
Being able to be generous with your time to help other students is very fulfilling.
Final Observation and Why?
I was primarily using graduate school to prepare for an awesome career as a Professor/Super Developer/Ultimate Hacker. I was working really hard to become one because I reasoned that would be where I find happiness. Little did I realize that going homeless would make me happy and enable me to live in a way where I was rich in spirit.
Going this route enabled me to be selfless and find a new kind of joy. See, I changed when I knew that no matter what that I would be fine. I knew that I could be generous and helpful rather than hold on to what little I had. If you need lunch, then I will buy it. If you need a hug, then I will give you a hug.
This path in life changed me so much that it gave me a greater perspective and enabled me to find compassion. Compassion and selflessness didn't make sense to me since it seemed like I was voluntarily losing something. I saw life as a game where there are winners and there are losers, and I was competitive to a fault. Seeing the game, my goal was to win. The problem is that winning in every aspect of life is hard. What makes a person great at work can make them terrible in a social setting.
Professionally, I am a winner. Socially, i was inept.
If I had continued what I was doing, I was going to be alone because I was confusing the social and professional worlds.
Going homeless and surviving on less than $6K a year enabled me to realize that no matter what life threw at me, I would be fine. This meant that I could devalue the need to be a winner in the professional circuit. This gave me the flexibility to study the social aspects of life.
My fellow peers were delighted and noticed my mood and friendliness changed, and they became my friends. I was generous with my time which enabled me to ad-hoc mentor computer science students.
Fast forward to the present day, I'm married to a woman who inspires me every day with her compassion, empathy, and delicateness. She is the flower of my life, and I'm working hard to separate my professional work and my life with her.
The change I made in my life enabled me to go from some social inept nerd to a happily married man with an abundance of friends.
Most of my friends know that during 2006 - 2007, I went homeless and lived in Nichols Hall at Kansas State University. Oddly enough, one of my friends at Kansas University went homeless too except he got caught after three weeks. I was homeless at K-state until I left graduate school (about a year).
At the time, I was both a graduate teaching assistant in Mathematics and a graduate research assistant in Computer Science. I had a full work-load, and I wanted to work more. I had a little cubicle in Cardwell Hall with other graduate students, and I had mine filled with books and my behemoth of a computer.
When I would retire for the evening, I would walk to Nichols and blow up my air-matress (had an automated pump) and lay my bones to rest.
In the morning, I would wake to the sound of students rushing about. I would head over to class and teach students some math and answer questions. After which, I walked or biked over to the Rec where I would take my shower (with a bunch of naked old guys).
Tip: old men are not shy and will wave/shake their cocks high and proud. Once, I was putting on my shoes and I got boxed in my two chatting old men. Too both my left and my right were two old cocks. While this was awkward, it did make me appreciate my youth and fearful of aging.. Eww.
After my shower, I would get on with my homework, my research, or my projects. Occasionally, a student would ask for help. I had the most hard-core office hours out of all professors and other GTAs. It was from 9am to 9pm. How can anyone not make those hours? Well, they didn't because they were lazy. However, one student did take my offer seriously and I mentored him from a D student to a B student where I gave him an A for effort. He then earned a righteous A in the next course. It is an awesome feeling to have actually helped another human being a serious setting as he was on the verge of dropping out; now, he is an electrical engineer doing amazing things.
Before I went homeless, I had stuff. I hate stuff as it just accumulates and then needs to be moved for no good reason. I developed an algorithm using a self-storage unit where I put everything into my unit and then would bring stuff I needed into my car. Beyond some books and clothes, I didn't need anything. After six months, I just started giving stuff away. Free 36" TV? it went to a gentleman by the name of Kyle. GameCube and a bunch of games? It went to a gentleman by the name of Brad. Salvation Army got about $4K of goods, and I sold $500 worth of stuff at a pawn shop. I kept my books, computer, and paperwork.
Having spent an entire semester homeless, I decided that it was stable. But then I decided to take the path of a start-up technology co-founder. So, I lived at our first office which was an apartment (that we kind of ran out of room). However, I was not on the lease, so I was technically still homeless.
I got my own apartment when I found my woman Effie (who is now my Wife).
Thoughts
All you need in life is an air-matress (which is optional if you tune your body to hard surfaces), food, a woman (or a man), two songs, and work. Sometimes, I would play, but play is just another form of work. A car is nice too.
I'm fortunate to find joy in Mathematics and Computing.
Sleeping outside is a lot of fun. Sleeping in my car was fun until my back started hurting. Sleeping on top of my car was very fun (again, until my back started hurting). Sleeping naked in a field is way awesome.
Blasting movies/music/video games in the Math building at odd hours is really fun. You can't do this at an apartment building.
When work ends naturally, taking time to smell the flowers and watch the world in motion is very relaxing. Going homeless enabled me to catch up on both my homework and my research, this gave me the time to go sit in the quad and watch the machinery of university and appreciate the groundskeepers.
Buying people lunch is fun.
Having plenty of time to enjoy campus is awesome.
Being able to be generous with your time to help other students is very fulfilling.
Final Observation and Why?
I was primarily using graduate school to prepare for an awesome career as a Professor/Super Developer/Ultimate Hacker. I was working really hard to become one because I reasoned that would be where I find happiness. Little did I realize that going homeless would make me happy and enable me to live in a way where I was rich in spirit.
Going this route enabled me to be selfless and find a new kind of joy. See, I changed when I knew that no matter what that I would be fine. I knew that I could be generous and helpful rather than hold on to what little I had. If you need lunch, then I will buy it. If you need a hug, then I will give you a hug.
This path in life changed me so much that it gave me a greater perspective and enabled me to find compassion. Compassion and selflessness didn't make sense to me since it seemed like I was voluntarily losing something. I saw life as a game where there are winners and there are losers, and I was competitive to a fault. Seeing the game, my goal was to win. The problem is that winning in every aspect of life is hard. What makes a person great at work can make them terrible in a social setting.
Professionally, I am a winner. Socially, i was inept.
If I had continued what I was doing, I was going to be alone because I was confusing the social and professional worlds.
Going homeless and surviving on less than $6K a year enabled me to realize that no matter what life threw at me, I would be fine. This meant that I could devalue the need to be a winner in the professional circuit. This gave me the flexibility to study the social aspects of life.
My fellow peers were delighted and noticed my mood and friendliness changed, and they became my friends. I was generous with my time which enabled me to ad-hoc mentor computer science students.
Fast forward to the present day, I'm married to a woman who inspires me every day with her compassion, empathy, and delicateness. She is the flower of my life, and I'm working hard to separate my professional work and my life with her.
The change I made in my life enabled me to go from some social inept nerd to a happily married man with an abundance of friends.
Friday, February 25, 2011
What is Computer Science?
Is it an art? a math? a science? or engineering?
Well, strictly speaking. Everything is an art-form, so it is trivially an art.
There are mathematical models about computing and you can apply computers in math, so it is a branch of mathematics in both theoretical and applied aspects.
It induces complexity that can be studied and model. Problems can be studied in a pure fashion, and methodologies can be deployed to measure the unknown. It is a science. Debugging is 100% pure science along with good testing.
Is it engineering? Well. This is the tough one. By itself, it is not. It's too much art and not enough discipline. How many times can projects be rewritten? I see engineering as more of a way to overcome the limitations of reality. However, software and computing mostly have no limits except time and did it compile. Where as most other forms of engineering have limits like gravity, friction, heat, electromagnetic interference, collisions of matter, speed of light, and other limits. Recommend Reading: Why writing software is not like engineering.
Computing is very platonic and there are many ways to do things, so can computing be an engineering discipline?
This is where the role of the software architect comes into play. Take an expert programmer, give them a hat that says "software architect", and then task them with building an architecture that will enable a group of developers to build a business. At this moment, the software architect will cast the platonic world into the real world and introduce limits and constraints that enable the team to implement engineering methodologies.
This has some interesting consequences in industry. First, businesses diverge in their computing reality. Second, you see an order of magnitude increase in not-invented-here syndrome in software than other engineering fields. Finally, we will never agree on anything for long periods of time because it just keeps changing because we haven't come to agreement on "what is software engineering?". We haven't figured out a reality yet that makes enough of us happy.
Now, let's discuss how academics fucked up computer science education.
Well, strictly speaking. Everything is an art-form, so it is trivially an art.
There are mathematical models about computing and you can apply computers in math, so it is a branch of mathematics in both theoretical and applied aspects.
It induces complexity that can be studied and model. Problems can be studied in a pure fashion, and methodologies can be deployed to measure the unknown. It is a science. Debugging is 100% pure science along with good testing.
Is it engineering? Well. This is the tough one. By itself, it is not. It's too much art and not enough discipline. How many times can projects be rewritten? I see engineering as more of a way to overcome the limitations of reality. However, software and computing mostly have no limits except time and did it compile. Where as most other forms of engineering have limits like gravity, friction, heat, electromagnetic interference, collisions of matter, speed of light, and other limits. Recommend Reading: Why writing software is not like engineering.
Computing is very platonic and there are many ways to do things, so can computing be an engineering discipline?
This is where the role of the software architect comes into play. Take an expert programmer, give them a hat that says "software architect", and then task them with building an architecture that will enable a group of developers to build a business. At this moment, the software architect will cast the platonic world into the real world and introduce limits and constraints that enable the team to implement engineering methodologies.
This has some interesting consequences in industry. First, businesses diverge in their computing reality. Second, you see an order of magnitude increase in not-invented-here syndrome in software than other engineering fields. Finally, we will never agree on anything for long periods of time because it just keeps changing because we haven't come to agreement on "what is software engineering?". We haven't figured out a reality yet that makes enough of us happy.
Now, let's discuss how academics fucked up computer science education.
Subscribe to:
Posts (Atom)