Blog Archives
Circular Piracy
Game developer, Greenheart Games, created a game about creating games called Game Dev Tycoon. It’s a familiar game genre, a sort of “Sims” about being a software game developer. I haven’t played it, but it seems cool.
But what I thought was really cool? What they did to make a point about piracy:
In a curious social experiment, the developer deliberately uploaded a full, cracked version of its game to the most popular torrent trackers. The cracked version is nearly identical to the real thing except for one detail. As players spend a few hours playing and growing their own game dev company, they will start to see the following message, styled like any other in-game message:
“Boss, it seems that while many players play our new game, they steal it by downloading a cracked version rather than buying it legally. If players don’t buy the games they like, we will sooner or later go bankrupt.”
Slowly, the player’s in-game funds will dwindle, and every new game that they create has a high chance to be pirated until they eventually go bankrupt. There is no way to fight it, in an ironic twist, players of the cracked version of the game are doomed to constant failure due to rampant piracy.
I thought that was pretty clever. It’s an old argument and issue for sure, but I like that because they granted the realities of the game they were making and that they were making a game, they had an avenue to make a point and they chose to make that point. So why make that point? From their own website:
Game Dev Tycoon was created by two brothers. They invested all their savings to start a company and develop the game. They truly enjoy tycoon and simulation games and after seeing many of the new social and pay-to-play games where buying coins is more important than good gameplay, they wanted to bring some true simulation games back. Their motto is less social, less ville, more game and they believed that there is a market for real simulation games but as independent game developers it’s difficult to survive and the reason why so many companies create pay-to-play or coin-driven games are because they make more money with them.
If you like the look of Game Dev Tycoon and you want to see more games like these then you should really think about buying a legal copy of the game. The price of the game is reasonable (7.99USD), you get legal copies for Mac, Windows and Linux, free service updates and you can even install the game on a couple of your personal computers.
If you don’t care about all of this and just want to get a cracked and illegal version then we can’t do anything about that, but if years down the track you wonder why there are no games like these anymore and all you get to play is pay-to-play and social games designed to suck money out of your pockets then the reason will stare back at you in the mirror.
I’ve been writing software for 20-some years. I complete understand. I mean, I dealt with piracy before Napster and torrents. I do sympathize with any artist and person that wishes to make their living on “digital data”, be it software, music, movies, books, whatever — something that’s easy to copy and distribute. I sympathize because that’s how I earn my living and feed my family! I don’t sympathize with the way “Big Media” has gone about trying to enforce things because I learned long ago that pirates will always pirate and good people eventually will pay up, so long as they understand and are given reasonable terms. Since I have limited resources (time, money, energy), I can either work to make my product better or fight the people that I’ll never win over anyways; so why not please those willing to be my customers? Draconian DRM that hampers and just pisses off your legit customers isn’t the right way to go (witness: SimCity 2013′s rollout).
What it really takes to improve this situation is for the public to be educated.
The Klug brothers are right: if you want good things, you have to support those willing to make good things. If you like games like this, support them so they can keep making these things that you like. It’s pretty simple. It doesn’t matter if it’s your favorite music artist, movie studio, game developer, book author… whomever and whatever. These people have worked hard to produce something, something that you now enjoy and has made your life better. Is it fair for you to take and not give anything in return? Would you appreciate someone doing this with the fruits of your labor? Is the way we should get people to pay by forcing them with ugly DRM and shitty experiences (think about this next time you try to play a Blu-Ray and are forced to sit through FBI Warnings)? is that high quality? is that how you want things to be in life? Or would you rather be willing participant in the process and support those that make your life better?
Which way do you want it?
A developer’s life – in pictures
A friend passed along a website collecting a series of animated GIF’s that chronicle the life of a developer.
Apparently the GIF’s originally came from TheCodingLove and les_joies_du_code()
It’s like my life… in animated GIF format. 
Realizing your potential, as a developer
Maybe that I’m a graybeard programmer means I’ve finally realized my potential as a programmer.
I’m reading this list of “10 Reasons Why You’re Failing to Realize Your Potential as a Developer“, and I’m just nodding my head the whole time. I’m going to add my own comments to the author’s “10 reasons”, so you should read the original article first.
1. You’re too afraid of failure to learn new tools / languages / frameworks.
I’m not sure it’s fear of failure as to why people don’t want to learn other stuff. It may be as simple as having a comfort zone and wanting to stay there. It may be that they have a cushy job and want to keep it (maybe fear of losing job). There may be business reasons.
He’s right tho, that people are afraid of throwing away all those years of investment in X. The reality is, you are and you aren’t. You may well throw out a specific set of languages or frameworks, but so what? After you’ve learned enough languages, another is “just another language”. After you’ve learned enough frameworks, it’s “just another framework”. A lot of the concepts and approaches carry over, and it’s those things that matter more. You have a larger set of experience to draw from to solve a problem, to create an architecture, to see a flaw or a risk before it becomes too costly. Those things are far more important than you silly language wars.
It’s good to learn more languages, to learn more frameworks. The more you know, the more cool stuff you can do, and ultimately the more valuable you can be. That said, be sure to acquire depth in those areas. Having a list of languages a mile long doesn’t mean much if you can’t actually be useful in those languages can can’t speak to the depth of what they offer.
2. You won’t push your commits until the feature is “done.” (It’s never done!)
I think this is “fear of what others think” or “fear of judgment” or “fear of criticism”. That people won’t think you’re a god, or that you’re stupid for how you’ve done things. This is a reasonable fear. We’re human, we have egos. The geek and programmer are held up as some sort of wicked smart superman and the exception is taken to be the rule. It also doesn’t help that there’s often someone on the team that doesn’t know the meaning of the word “tact” or even “polite” when looking at someone else’s code. We basically always think the guy before us was a moron and can’t believe they wrote such stupid code!
Screw it.
You will write stupid code. You will write imperfect code. Your code will have bugs. You are human. You are learning. You will do the best you can at the time you can with what resources you have. I find this is where comments are useful because they can expose the hidden “why” behind something. Maybe you have to write an ugly hack, but at least the comment can explain why you had to do it (because we had to ship right now else lose a multi-million dollar contract and the company would have closed up and none of this would have mattered then). It may not excuse the choice of hack, but at least it becomes understandable.
Just commit, often and early. In the long run it will suit you better because you’ll need to roll back or have a good checkpoint, so your workflow is better served by doing that. And in the end it really doesn’t matter WHEN you commit your code, because we’re always going to think it’s wrong and wonder what moron wrote it. 
3. You know just enough to be dangerous.
I’ll just say you need to read and understand, before you do.
Sometimes you have to “do” in order to fully understand. If so, take time on the side to write a small project that allows you to fully explore and come to understand it. Often tho, a little sample project isn’t enough and you just have to drop it into the larger more complex context to really grok it. But then this goes back to #2, where you should commit often and early, so we can follow what happened and unwind it when something bad happens.
4. Analysis paralysis.
This is a tough one, and one that only comes with time and experience. Plus, it’s different for each person.
You cannot sit there and analyze all day, but you must analyze and research some. If you don’t understand what you’re doing, then you only know enough to be dangerous and we come back to point #3. Or you risk going in half-baked and everything gets fucked worse than before.
But you also cannot sit there and just analyze it to death. Sometimes you just have to dive in. But then it goes back to #2. Commit often. Heck, make a branch, maybe a branch of that branch, whatever you have to do. Sometimes getting in there and poking at it is the only way.
There’s a balance to be had, and ultimately you just have to find it. Never lose sight of the fact you have to ship, because you need to make money, because you need to get paid and pay bills and such. So if nothing else, let that be a motivator to keep going, just don’t rush it.
5. You don’t invest in your tools or development process.
This is a pretty good one.
I’ll just add that scripting has been one of the things that has helped me. Eventually I’ll recognize a task that I perform often (enough) and takes (enough) time. I’ll also see the task is one that tends to be the same thing over and over, or maybe almost the same with just some small variation of input. That sounds like a perfect candidate for automation! So maybe it takes me a day or two to come up with a script or other mechanism to automate it. Fine. But now it’s a simple execution of the script and viola, the thing is done. Or the thing can churn in the background without my tending to it, and I can go tend to other things. In the end, I get more done in less time.
How does the saying go? “Efficiency is intelligent laziness.”
6. You’re too embarrassed to ask for help.
Don’t be. You don’t know it all.
On the same token, don’t be an asshole when someone comes to you for help. If someone comes to you for help, they are in need and believed you to be the best person to aid them. Help them, and don’t be a dick about it. And yes, that includes things like LMGTFY, or just saying “RTFM” or “did you use the search feature” or other shit like that. There are ways to help people become more self-sufficient, but being condescending isn’t one of them.
7. You don’t know how to make it easy for other programmers to work with your code.
Your code will outlive you. As well, once you have written code, it will have to be maintained… often by you, and chances are 6 months from now you won’t remember what the hell you were thinking when you wrote it.
Write clear code, clean code. Yes sometimes architectures have to be obtuse or complex. So document them. Explain them to others. Be sure to share the knowledge.
8. You don’t know how to read someone else’s code (or don’t want to.)
This goes back to #7, that you should make it easier for people to read your code. In fact, it goes back to #2, because you should be pushing your code to others and soliciting their feedback. Code review is good.
Granted, we shouldn’t get hung up on coding styles and coding standards, because someone’s will always be different from yours. So you need to learn how to read their “dialect” and forge ahead.
9. You can’t code from the end-user’s point of view (you think too small.)
This this this, so very much THIS.
We must always remember who we are coding this for. When I write a script (#5), I’m usually writing it for myself so if it’s quick and dirty, that’s fine. So long as I can make it go that’s all that matters. If it fails along the way, that’s OK because I can fix it. But if I was to make that same “automated task solution” work for someone else, I’d probably have to make it cleaner, clearer, I might have to put a GUI on it, make it more robust in the face of failure, etc.. It’s the same basic solution, but because of the audience the specifics and the end product are different.
We do not reside in an ivory tower. We must realize that we are generally not the audience and our take on things isn’t often the way it should be done. It was one then when I worked for Metrowerks, being a developer writing tools for developers, so often we could use our assumptions and biases and turn out the right features and approaches. But when I wrote Spring Cleaning and was writing an app to make life easier for non-tech-savvy people, that affected everything and directed how even things as simple as error messages must be written.
But also, don’t let this get you arrogant. I often hear that the customer doesn’t know what they want and so we must give it to them. Actually, customers often do understand what they want, but they have a hard time articulating what they want and may not know how to articulate it. But often they will know it when they see it. Thus it becomes OUR job not as a programmer but as a designer, as an architect, to learn how to draw this out of the end user. To step back, to see the larger trends, the directions, and the problems faced by our end users and then see how we can solve them to give them a solution that not only gives them what they want but in a way that’s better than they expected.
This isn’t easy, and it’s nothing a novice can do. But it’s a position for the novice to strive for.
10. You aren’t able to judge the business value of any programming task.
I will never forget Doug D.. Doug was a manager I had early on in my career. I was this idealistic programmer that enjoyed my ivory tower. I wanted to write perfect code, and do great things as a programmer. Doug helped me realize that while that’s all good, there’s business to think about. It’s simple. Money has to be made. There has to be money to pay my salary, to keep the lights on, to pay my salary, to put Mountain Dew in the fridge, to pay my salary, to keep the business floating so we can keep our ivory tower alive and going to even bother with any of this code. If there’s no money, none of this stuff matters and our ivory tower of ideal programming goes away. So you have to look at the business side of things. You have to keep perspective. And sometimes yes, you have to not do something, you have to leave some task, adjust priorities, or even sometimes take a hack approach instead of a clean architecture. There’s just realities of business. Many times it may lead to ugly things that are more painful to recover from down the road, but that’s life… at least you stuck around long enough to have that longer road instead of having to pull up stakes miles and years back to find a new home.
Nothing will be perfect. We have to find balance and constantly juggle priorities.
Just don’t forget to grow and have fun along the way.
Smart guns? Dumb idea.
So, Jeremy Shane thinks the solution to the problem is to “make guns smart”: (h/t Shawn)
While the debate rages on, it’s worth thinking out of the box for a moment. What if we could design guns to be smarter and safer — with hardware and software? The right technology could neutralize the killing capability of an assault weapon, even in a madman’s hands.
After reading Mr. Shane’s article, I’m not sure how much he knows about guns or software, but it comes off like he doesn’t know much. I’m a firearms instructor and have been a software developer for over 20 years, so I know a few things about both realms. Given that, while I applaud Mr. Shane’s imagination, I can say his ideas are best left to the imagination, as realization of them will not lead to the end goals he desires.
The root of the problem is that guns are “dumb.” Pull the trigger and they discharge bullets mindlessly, regardless of who is doing the aiming or where they are aimed. Guns should “know” not to fire in schools, churches, hospitals or malls. They should sense when they are being aimed at a child, or at a person when no other guns are nearby.
Most useful tools are dumb. We don’t have “smart” hammers, smart screwdrivers, smart knives, smart binoculars, smart blenders, smart cars… well, granted some things are starting to try to move that way, but most things understand that those “smart” devices can really only operate in dumb environments. No computer can process information as fast and as well as the human brain, can make the “instant” decisions that sometimes are necessary. The “touchier” the environment, the more humans are still needed. Even with all the safety technology being brought into cars, we still haven’t eliminated the driver because there are just some things the car cannot do and only a human can.
Should guns “know” not to fire into schools or churches or hospitals or malls? I don’t know… what if there’s an active shooter in a school or church or mall (since that’s where most such events have happened)? Wouldn’t you want the good guys to have guns that can work in those environments?
They should sense being aimed at a child. How would that work? Define “child”, as some sort of optical device would perceive them? I mean, I know some young teenagers that are larger than adults, some adults that cast child-like silhouettes. Mr. Shane also says “Sensory data can be used by built-in software to disable firing if the gun is pointed at a child or someone holding a child.”. Or someone holding a child… So a gun shouldn’t be functional if pointed at the person kidnapping your child?
You see, these are subjective decisions. How exactly can software make the sort of decision necessary? And even if it can, it takes time, time that may not be present as a horrible event is unfolding.
If you wish to have software attempt to make these subjective decisions, we have to remember that software is imperfect. It’s written by humans — who are imperfect — and software has bugs. It may not be robust enough. It may not be sound enough. It may hold bias of the programmer. I mean, for all my care and concern at writing bug-free code in my decades of programming, it’s impossible to write bug-free code. Do you want YOUR bug to be responsible for someone’s death? That it might not fire when you need it to fire, or that it fires when you don’t want it to fire? And then, who bears the responsibility for such a mistake?
Couldn’t gun software be hacked? Perhaps, but the risk can be reduced by open-sourcing code, requiring software patch downloads, and notifying gun makers or law enforcement if software is disabled. Open-sourcing code is not foolproof, but it will build a community of lawful gun owners and code writers who value safety and Second Amendment rights. Enabling two-way communication between guns and their original makers will help guns to be tracked beyond the initial sale, putting greater long-term responsibility on gun makers.
Nice thought, but open source code is still not bug-free and still can have horrible things happen. And there’s nothing here to address “software hacks”, but boy… what about viruses? what about social engineering? hardware hacks (I mean, why not just disassemble the gun and disable or replace the mechanism)? It’s not like DRM has really stopped piracy. It’s not like iPhone’s don’t keep getting jailbroken. There’s so many other things that can happen and be made to go wrong, to bypass, or to even force malfunctions. Wouldn’t it just be dandy if some virus was let loose that caused all these guns to rapidly empty their magazines at some coordinated time of day… all around the world… *shudder*.
There have been groups that have attempted such “smart guns”, and all have failed. Not only because the system itself doesn’t really work out, but because no one is willing to buy said “smart” systems. There’s no police nor military group that would want to buy such a thing, because they operate in environments where you may need to shoot multiple rounds in a school at a person holding a child. They understand these “smart” systems are anything but, and are too risky and prone to failure, and not worth risking their lives over. So you may say, only sell “dumb guns” to police and military. Realize then that still means such guns would be in circulation, and thus bad people will still get a hold of them. Of course, if you know anything about weapons fashioned and found in prisons, bad people will get weapons without your “smart restrictions” if they really want them. Even if somehow that’s all there is, there are going to be other “dumb” ways to cause mass destruction; look at Timothy McVeigh. So all these “smart” weapons would do is abridge and hamper law-abiding good citizens. Why do you want to do that?
You see, a well-made gun is actually a very simple mechanical system; it’s a simple machine. Once you start to add all of these things on it, start trying to add GPS, sensory data, target discernment, you start making for a massively complex system. And with any complex system, it starts to become… well… complex. Difficult. And prone to mistakes.
If truly you value life, should it be held to a system that can be massively complex and prone to mistakes? For all your attribution to car technology, Mr. Shane, consider how many recalls happen every year. A car is a massively complex system, and while it may work most of the time, you know all too well that cars break down and fail us. Thankfully most of the time car breakdowns don’t have life hanging in the balance. But when good guys need their guns, for certain lives are hanging in the balance — do we really want the risk of breakdown when preserving life is most critical?
It’s a nice thought, but technology cannot save us. Fixing our cultural and social norms and behaviors is at the root of solving this problem.
Thanx, Mom & Dad
The other morning I was thinking that being a programmer was probably where I was headed all along in my life…. and thankfully Apple has remained around that whole time too, since that’s where it started.
I remember being sent to a week-long “computer camp” one summer at Brownell-Talbot. We learned BASIC on Apple II+’s. I kept the 4 books as my “reference bibles” for many years of my youth… carrying them around with me all the time, reading them. I recall being befuddled by GOSUB routines.
I remember when we got an Apple IIe for Christmas, with 2 5.25″ disk drives, and a 64K expansion card! Top of the line stuff there… and of course, I pulled out my BASIC books. One day Dad took us to a software sales “convention” in some hotel conference room where they sold this “shareware” stuff. I recall pulling out my BASIC knowledge and hacking the games. I didn’t know how to write a full game myself, but I did like modifying the existing ones. Heck, I recall kids at school giving me obviously pirated/hacked versions of games — I didn’t understand what it was I was getting, but I thought it was cool to see how someone had inserted their own name into the game’s intro screens.
I remember going to my Dad’s office and while he worked he sent me over to this one desk to occupy my time. This desk had a Mac on it. I was so fascinated by this MacPaint thing.
I remember needing my own computer in college, being tired and frustrated by the limitations put on me from sharing or borrowing. Dad bought me a Mac IIvx (I should have gotten the Centris 650!). I found a copy of THINK C for sale at the college bookstore, and with a Dave Mark book in hand I started down the road in earnest.
So I was looking back at just how much my parents supported and enabled my efforts… and well….
Thanx, Mom & Dad.
What we (programmers) want
I’ve poked at computers for decades… yes, I’m dating and aging myself.
And programming always appealed to me. I guess it’s been my craft, my calling. I’ve had opportunities to move into management, but I refuse because I know what I’m good at and what I love (and that I don’t like being a paper-pusher). For example, right now I’m working on one of the more challenging programming tasks I’ve dealt with in a very long time. It’s very complex, very complicated, very frustrating. But because it’s such a huge challenge (and will be a HUGE win when I pull it off), I’m happy to let it engulf me. Part of my poor sleep this past week has been due to Daylight Saving Time throwing me off, but also because the moment I wake up my brain churns on this problem because well… it’s just what I find exciting. Geek that I am.
Over my years, over my jobs, my bosses, my companies, the projects and groups… I’ve learned what I want and don’t want. Geeks do tick differently, and we aren’t satisfied by the same things a lot of other officer workers are. It’s welcome when the company and bosses get it, and frustrating when those that “run you” don’t get it. I don’t expect people to bend to my way of being, but I can say if you can understand folks better, you tend to get further.
This article by Michael O’Church about “What Programmers Want” is insightful and pretty spot-on about us.
If you have to manage geeks or interact with them, take the time to read it and gain some insight into us.
Or if you just want to understand us geeks a little better, it’s worth your time too.
Senior Engineer
John Allspaw writes “On Being a Senior Engineer“.
In my long career, I’ve met lots of people with the title “senior engineer”. We’d joke and call them “señior engineer” because it was all too often thrown around as some title of arrogance or tenure, but was about as meaningful as a “perfect attendance” award – sure it’s great that you showed up and have been here a while, but that didn’t mean you knew anything.
Or were mature enough.
So with that, I’ve often cast off the title because it’s tended to be meaningless, maybe useful for business cards or at most on your résumé. But John’s article gives a perspective that the title is meaningful, if applied to someone who actually fits the role.
Of course for it to truly be meaningful, the title needs to be properly applied over the course of a career, not just because you’re the lone coder at some startup you and your other 20-something-year-old friends put together over beers one evening fresh out of college.
In the end, it’s just a title. It doesn’t really matter. But the merits and qualities of a senior engineer, as John lays out, are what really matters and what are worth striving to be.
We don’t need no stinkin’ comments – yes you do
If you haven’t guessed, I like to write.
Some think I like to talk. No, not necessarily. But get me on the right topic, and I can go on.
Programmers are a funny bunch. They’ll write pages and pages of code, but they won’t say a whole lot. It tends to happen frequently with regards to comments.
Comments are blubs of text within code that don’t have much to do directly with the code, but tell us something about the code.
Comments help us understand.
Comments are also the subject of religious wars.
Some believe comments are evil and shouldn’t exist. I’ve seen a lot of course code that is devoid of comments. I generally assume the programmer is lazy or in a hurry when this happens. They might come back to say code should be self-documenting, but then I see the quality of their code is such that it doesn’t document much of anything.
To me, the trouble with self-documenting code is… what if the code is wrong? Comments (and perhaps design or API documentation written prior to the writing of code) provide a level of redundancy, because they provide the general overview, the abstract notion, the description of the promise of what is to happen. If the code jives, great. If it doesn’t, then we know there’s a problem. Can comments be wrong? Sure. But we tend to grok wrong comments better than wrong code, because it might be possible the code is right even if it looks wrong to us. What helps us determine that? You guessed it, comments.
See, comments are about the “why” of the code. We cannot tell WHY the code from the code; we cannot derive the reasons for the way the code is from the code itself. Once you write code, it will forever have to be maintained, so you need to think of the future maintainers — likely yourself 6 months from now, and yes you will have forgotten more than you expected. Do yourself a favor and comment your code.
I worked on a large software project many years ago. It was a huge beast of a mess of code. One day I went digging around after a memory problem and found a complete mess. See, every bit of memory you allocate, every resource you create, it must have a distinct owner. We have to know who made this mess so it can be cleaned up when we’re done. As I dug through the code, it became evident whomever wrote the original code played fast and loose with the ownership and numerous people assumed ownership over the memory but never rightly transferred that ownership. It created a massive mess, and in the end I determined there was no real safe way to properly clean things up. It was horrible.
Consequently, I wrote a lengthy diatribe in the code (comments) explaining the mess. It was pages long, because it was that ugly of a mess. I figured after all the crazy I went through, future folks ought to know about it so they could beware. Well… I left the company some months later, and then later on the product was sold to another company. I was at Apple’s WWDC (back in the old days) and came across a representative of the new company. When he saw my name his eyes got really wide and he said “YOU!!”. He started laughing. Seems they had come across my epic comment block and had a great laugh reading it, calling over everyone in the office to see it. He said I was a legend in their office for having written it. It was most amusing.
What spurred this walk down memory lane?
Over at AltDev is an article The Elements of Comment Style. It talks about the value of comments and the different types of comments. I never gave much thought to the types of comments — it’s just comments, there to explain what code itself cannot explain. But the article provides good reason for comments, and links to writings of others, like Knuth and Raskin, as to why comments are good (and wouldn’t those guys know).
In all my years of programming I’ve gone back and forth and refined my approach to comments. Do I think we need to have copious levels of documentation? Well, sure that’d be nice and ideal, but it’s tough to do that because comments and documentation also have to be maintained. There isn’t always time. And that, depends upon the scope of the project. I’m sure if I was writing some system for the .gov I’d be documenting everything to the Nth degree. But working in the mobile app space, sometimes you have to move faster than is healthy and there isn’t always time for formal comments. Maybe the best I can do is a couple lines at the start of a function to give the basics of what it does then “self-document” what are legal parameters by having a lot of asserts of the parameters at the start of the function, which do provide documentation and also a level of code robustness. But that approach only works when we have full access to the code; writing an opaque library/SDK would require a different approach. So there’s always trade-offs and balances to be found, depending upon context.
I haven’t written a multi-page comment since that one.
And if nothing else?
A year since we’ve said goodbye
A friend pointed me to the Apple website, because 1 year ago today, Steve Jobs passed away. Apple changed their home page today to post a video (linked here, but no idea how long this link will remain, or if it’ll move to a more permanent home eventually), a tribute and remembrance of Steve Jobs.
Yeah… it choked me up a bit.
I didn’t know Steve at all, but my first computer was an Apple //e, and the day I saw a Mac… it changed my life. I’ve spent over 20 years writing Mac and now iOS software professionally, so yeah… Apple has a place in my life.
At the end of the video you hear Steve say:
It’s technology married with liberal arts, married with the humanities, that yields us the result that makes our heart sing.
That’s what people tend to not get.
Sure, iPhone is behind Android in a lot of respects. In fact, in many respects Mac has been behind the PC/Windows. But in many other respects, Apple has completely lead the way in both the desktop Mac and mobile iPhone world (and let’s not forget the music iPod world either). And the biggest leader is Apple make products people want to have, that people yearn to have. Who lines up for the midnight release of any product? What other customers find opening the box to be a religious experience? that a product, a service, a brand creates such intense devotion… to plastic and silicon?
There’s an aesthetic.
I see Android devices all day at my day job, and I just can’t like them. Same with Windows vs. Mac. Oh sure, I can totally appreciate the technology going into them, both the hardware and the OS. I think there’s actually a lot of cool stuff about Android as an OS. But it just doesn’t sing to me. It doesn’t move me. I don’t look at it as a joy that I like to look at for hours every day, which is what I have to do. If I have to stare at something for a long time, I like it to be pleasing to the eyes (like my wife), and somehow stir my soul (like my wife).
To some people, they don’t care. These things don’t matter to them. And that’s OK. To some it’s pure utilitarian, or they don’t know any different or don’t care. And that’s fine. That’s them.
Me?
Well, speaking of Steve… if you consider his background with typography and how that influenced the development of Mac. Just the other day I read about a new programmer’s font, the article mentioned a few, I downloaded and tried them out, and settled on Source Code Pro. It’s a beautiful font. It’s a lot nicer on the eyes, and when you’re staring at code all day long well… the shape and placement and count of pixels really starts to matter. And you probably don’t realize it, until you start to care and do something about it… like change it. But there’s the joy of Apple. They spend so much time fussing and caring about every little pixel, every little detail. The intent? To just work. In some respects, it should be remarkable; “Any sufficiently advanced technology is indistinguishable from magic.” But really in most respects it should be unremarkable. It should just work, it should not get in our way, it should not impede the flow of our work, it should enable and empower us… and we don’t really notice nor understand why. And even something as simple as a font can do this. Does that matter? Yes it does. And Steve knew that. Many people don’t know, don’t care, or aren’t aware… and that’s fine for them.
Not me.
Happy Programmer’s Day
Happy Programmer’s Day to my fellow programmers!
Oh wait… you mean it was yesterday? Ah that’s right… leap year. So that means this is an “off-by-one” error. How appropriate.
