10 shares of Amazon, and 10 shares of Sony, so far. Hooray for legal gambling.
I got asked tonight, in a critical tone, "why do you smile so much?" and I was thinking what a great problem to have. I smile too much. I'll try to be sadder and less expressive. :-P
I take issue with the entire "Work/life" balance ethos. It implies that work is a dreadful thing. It's always said with sympathy if someone has to "take their work home with them".
When I was in highschool I wanted to be a newspaper journalist. When I graduated from college I wanted to be a school teacher. But at this point programming has clearly won out as my lifelong career.
At first I was seduced by Tweener's method of making all tweening activity global class functions. After all why would you want two tweens on any singular parameter at the same time anyway? By making class functions, it's easy to prevent it from happening. But upon reflection I think a Tween deserves to be a separate entity that stands on it's own. Robert Penners foundational Programming Flash advocated a Tween be a separate object as well.
There's really not much code in Tweener. It's no insurmountable task to just reproduce...
I much prefer the method devised by adobe for it's Flex 2 mx.effect classes.
But they only work on UIComponents and subclasses, which are flex components, basically. So, for example, mx.effects.Move doesn't work on a Sprite. Pity...there's no reason it shouldn't, from what I see.
I can reimplement most of what I want from their already great design, only to be used with Sprites. That's my plan. No need to reinvent the great architecture. Just a need to implement with Sprites...I'll reuse everything I can, like the built in easing classes and the Tween() class (internally).
By peeling tweens off of Sprites and letting them stand as first class object citizens, we allow ourselves to reuse the same tween on several objects. We can also alter small parts of a tween and apply, over and over, to the same or different Sprites. (We could actually Tween the values of the Tween! boggling!...haha). Also a standalone object like mx.effects.Move incorporates methods like pause(), reverse(), playInReverse() (sorta), and many others that aren't handled as elegantly with Tweener's global function system.
Say I want to slide a button to the right on rollover, and back to the left on roll off. I can instantiate one Tween and then just play it forward and backwards. With each rollover/rolloff, I can reuse the same object I only made once. If I call Tweener.addTween() i'm throwing one-offs each time.
There's also a major design flaw in Tweener as I see it. All it's tween callbacks remain old-school actionscript 2.0 style. You explicitly define singular functions for each different callback....DUDE, where's the EventDispatcher love? AS3.0 loves EventDispatchers and you should too....they are super flexible and they really help design the interaction of objects that must be aware of each other's current state. Plus their functionality is built in! just grab and reuse.
fleh. </rant>
I've always harped on the importance of good developers. I know this is clearly a biased view, I myself being a developer, but nonetheless I remain steadfast that it is absolutely true. You just about can't overpay for a good programmer. It'd be hard. The companies that recruit the best talent, that fight the hardest for the best developers, are also the most successful companies.
The knowledge worker is more important than ever and grows more important all the time. It's amazing not every company has already picked up on this...but the companies out ahead, leading the way, already recognize it.
So given this fact, I was surprised by yegge's latest post that Google programmers are essentially interchangeable. People can switch teams at almost any point without wailing and suffering. They require a specific set of languages, and documentation, that diminish the otherwise irreplaceable nature of any one programmer.
It took me a bit of thought to coincide these two seemingly disparate facts. 1) Google pays tons of money for developers. 2) Google treats them as interchangeable and intentionally reduces their individual value to the company.
I started reflecting upon this when a particular employee left our company recently. She was a great programmer to start with, but made herself magnitudes more valuable to our company by contributing SO MUCH to some of our most important frameworks.
A software company needs great programmers. And if you have extremely complex software, a brilliant one is definitely worth 375k/year. Once a company has invested so much in a person, it's the natural response to give them lots of control over lots of important code. But the problem is the company doesn't guard against the inevitable result of becoming hopelessly desperately dependent upon a single person. In video-game development post-mortems , just like everywhere, one of the biggest contributions to failure is "lead" developers quitting or even just going on vacation!
The insidiousness of this problem is that the greater the developer the more natural the tendency for their code and architecture to infiltrate every nook of your code base.
It's an odd contradiction, but I think companies should recognize the enormous value of great developers, and yet simultaneously fight to prevent them from growing even more enormously valuable over time.
If you have a webserver that's critical to your business, you'd be dumb not to have at LEAST one backup ready to go immediately should the first fail. And that's when webservers can have 99.9% uptimes! In a lot of large software companies your lead developer is easily as important as that webserver (apples and oranges, I know), but the company doesn't make the same attempt to have a "backup".
I'm not saying every project needs developer redundancy, but frameworks and products that aren't one-off probably do. The real company win to "pair programming" is not speed or code quality. I think the best of the pair could probably do better on both accounts all on her own. But the goal at this juncture is avoiding catastrophe by having a backup. The more important the venture, the more backups there should be.
It is an unusual result to say that more successful companies a) pay more for employees b) devalue them more once they are hired. I think it also runs counterintuitive to the sensibilities of more traditional "architects" or "engineers" in other fields, because most software lives and breathes for much longer than other architected or engineered structures. When engineering a bridge or architecting a skyscraper, there's not going to be a version 1.1. And if there is a version 2.0, the maker of version 1.0 will probably be long retired. It wouldn't matter anyway though, because 2.0 would be a complete rewrite...since new bridges and new skyscrapers are not normally built as some sort of scaffolding on top of the original 1.0 (maybe it's happened I don't know...)
So when constructing things in the physical world, generally speaking, you do not really NEED to retain the achitect/engineer after your product has shipped, because it will not be undergoing continuous refinement. Not so with software, where your entire structure is made out of easily-refined thought-stuff. The process of refinement happens frequently and almost endlessly. Software can grow organically for a decade or longer, constantly piling on more logic and processes.
Whereas Joel Spolsky thought recursion and pointers were the measure of eliteness when it came to computer programmers, Steve Yegge has chosen to be more specific, saying the real key is compilers . I think I agree with Joel more that the fundamental theories are the key. Steve puts too much emphasis on one facet of many in the realm of computer science application. I took the compilers class and I understand compilers, but there's a lot of other CS out there that doesn't necessarily use compilers which still requires very good programming.
In any case, one thing they can agree on is abusive insults towards Java and Web 2.0...they are, after all, both very smart guys. ;o) From Yegge,
Designing an effective undergrad CS degree is hard. It's no wonder so many ivy-league schools have more or less given up and turned into Java Certification shops.If you're a conscientious CS student, you'll at least take OS and AI. You may come out without knowing exactly how compilers work, which is unfortunate, but there will be many problem domains in which you can deliver at least as much value as all the other people just like you. That's something to feel good about, or at least as good as everyone else feels at any rate.
Go team.
Most programmers these days, sadly, just want the degree. They don't care what they learn. They want a degree so they can get a job so they can pay the bills.
Most programmers gravitate towards a set of courses that can best be described as the olive-garden of computer science: the places where dumb programmers go to learn smart programmer stuff.
I hesitate to name these courses explicitly. I wouldn't be agile enough to dodge the game of graphic bloodshed aimed at me by animated, project-managing, object-oriented engineers using Java and Web 2.0 technologies to roast me via user interfaces designed rationally through teamwork and modern software methodologies. I'd become a case study in the ethics of software and its impact on our culture.
Simulation programming is what got me into Flash and keeps me into Flash. A lot of people work with Flash without ever actually doing any sim programming with it. Actionscript 2.0 was hacky and full of frustrating issues. I was considering the leap to Processing, but Actionscript 3.0 really whips the llamas ass.
Let me say a few things about the coolness and value of simulation programming. First it is cool because your code is not "explicitly" directing the operation of everything that happens in your program. Results are "random" and often quite unexpected. You don't write code to orchestrate every little thing. Instead you establish some groundrules and then say "go" and see what happens. It's quite amusing. If god is a clockworker that built the universe as a series of physical laws and then pushed "go" I can certainly relate. The universe is an ultimately cool simulation.
Secondly simulations and understanding how to build them provide insight into how to build recursive and search oriented algorithms. Simulations force you to break up your scenario into smaller similar chunks, then just define the differences between each chunk, parameterize those differences, and voila. A recursive search routine over a grid space, for example, actually shares a lot of the same properties. You are defining each "step" of your search from node to node over edges. You don't write code to try and define every single step, ad infinitum (which I see a lot from amateur interviewee's), but rather you write generic code that says what's going to happen at each step, and then you call that code over and over.
Pretty much always, there are lots of elements of your simulation that you will want to look "realistic", which means basically, to imitate real life. The best way to do that is often to reuse many of the same concepts used by physicists when trying to solve and model the real world...just reapply in simulation form. For starters, 3 incredibly important foundational concepts for the motion-based simulations I'll be discussing are "acceleration", "velocity", and "position". And for the math underlying all 3....we need vectors.
So for this post I'm going to start with my Vector class. This is a new endeavor and still a work in progress and I invite comments should any programmer happen to actually read this. You can get a copy of the full code file here: Vector
It supports it's own event dispatching, it's static events are shown at the top. It's public methods include add(), subtract(), normalize(), invert(), dotProduct(). It also has getters/setters for distance,length,x,y.
That's all I've got time for a.t.m. I need to work on this ;o)
If you are developing anything from scratch, or maintaining anything relatively small, in Flash 8 or below, then please smack yourself.
I think we can all agree that code almost always ends up lasting longer than people anticipate. I still read stats that some 80% of production corporate code remains in COBOL or Fortran and other such craziness.
I also doubt there's any arguing at this point that flash 9 has reached at least 90% market penetration. This link shows 84% back in March, growing from only 55% in December '06. That's an incredible growth rate and it'd be impressive if since March it hadn't crept over 90.
Given that we know that code ends up lasting and hanging around longer than people anticipate, and flash 9 is being adopted at astonishing rates, continuing to generate code in Actionscript 2.0 at this point in time is not wise.
Flash 9 .swfs can be generated with only .as files and a command line compiler. No binary files are needed. So finally Flash can actually be incorporated into build cycles, placed in ant files, etc.
Actionscript 3.0 is also just a much much nicer language. No more hacks. Finally done right. The VM for it will be the background of Ecmascript 4.0, and has also been donated to mozilla to be synchronously developed as the VM for it's Javascript engine! (Link here).
I've been playing with Actionscript 3.0 using the free Flex 2 SDK. It is so sweeeet.
Check this out:
It's using a grid-based detection system for speed, but I've intentionally set the grid huge. Each one of those drawn lines represents a distance and "repellant" calculation per frame...no way could I have gotten that out of AS 2.0...
