Ask HN: Does anyone WANT to build client software anymore?
29 comments
The problem with finding really great hackers who want to do client-side coding is that a huge percentage of the work required to implement such apps is boring crap: compatibility testing, look-and-feel review, installer authoring, and collection of client configurations from issue reports. You can implement more features in less time when you deliver thin-client solutions.
Also, the knowledge required to deploy apps to each of your target platforms are fairly different, and tend to be developed to the exclusion of each other. A great Mac OS software engineer is unlikely to know Windows inside and out, and a Windows guru isn't likely to know or care much about Linux. Linux folks are, well, an altogether different bunch.
Also, the knowledge required to deploy apps to each of your target platforms are fairly different, and tend to be developed to the exclusion of each other. A great Mac OS software engineer is unlikely to know Windows inside and out, and a Windows guru isn't likely to know or care much about Linux. Linux folks are, well, an altogether different bunch.
A huge percentage of the work required to implement web apps is boring crap: browser testing, working around bugs for quirks in different browsers, look and feel review, screwing around with stuff in five different languages / formats just to do something trivial (i.e. Javascript, CSS, HTML, Python, SQL) ...
I really don't think there are many web developers that can pound out an interactive web GUI with the speed that I can bang out a cross-platform desktop app with a reasonable toolkit. There's a natural bias here towards web apps since this is a web-app community, but there are a lot of great developers out there that like working on desktop stuff.
@webwright -- feel free to contact me. I know a lot of people from the KDE world that do cross-platform apps; I could try to put you in touch with some people.
I really don't think there are many web developers that can pound out an interactive web GUI with the speed that I can bang out a cross-platform desktop app with a reasonable toolkit. There's a natural bias here towards web apps since this is a web-app community, but there are a lot of great developers out there that like working on desktop stuff.
@webwright -- feel free to contact me. I know a lot of people from the KDE world that do cross-platform apps; I could try to put you in touch with some people.
You're right, of course; doing full-stack development, no matter the target platform, involves a lot of unsexy busywork. Browser incompatibilities are an issue as well, and there are certainly a number of layers of technology beneath any finished application.
That being said, I don't think it's fair to argue that desktop apps are easier to develop, test, and deploy than their online counterparts. Furthermore, information-sharing features that are trivial to implement via the web can be rather more complicated to build into a desktop tool.
That being said, I don't think it's fair to argue that desktop apps are easier to develop, test, and deploy than their online counterparts. Furthermore, information-sharing features that are trivial to implement via the web can be rather more complicated to build into a desktop tool.
Both metaphors definitely have their advantages. There are things that are trivial in one setting that are painful in the other. I'm not trying to argue for one or the other being altogether better; I think that's really context and user specific and as I've said before, I definitely think it's easier to build a business around web technologies.
To tie this back to the original topic: great desktop hackers can throw together desktop apps quickly, and know the quirks for developing cross platform (just like great web hackers know browser quirks). In contrast to most of the crowd here, I'm pretty darn good at desktop (and server / systems) programming, and mediocre at web programming, so I just see the other side of the coin.
To tie this back to the original topic: great desktop hackers can throw together desktop apps quickly, and know the quirks for developing cross platform (just like great web hackers know browser quirks). In contrast to most of the crowd here, I'm pretty darn good at desktop (and server / systems) programming, and mediocre at web programming, so I just see the other side of the coin.
@op: Have you considered hiring someone who develops AIR applications for the client software? I'd imagine AIR developers are more in the YC-Hacker-mold because the boring things mentioned above are abstracted by the runtime.
All except the look-and-feel bit. Mac users want apps to have the Mac look-and-feel, though perhaps Windows and Linux users aren't as adamant about it, so maybe a Mac-ish look-and-feel can be the common denominator. Also many users wouldn't want to install the AIR runtime.
The idea often appeals to me but I quickly get turned off by the practical realities involved, particularly when getting the app to both look reasonable and work on several platforms.
That said, I've been thinking about XUL/Firefox addons for some simple configuration things.
That said, I've been thinking about XUL/Firefox addons for some simple configuration things.
> I've been thinking about XUL/Firefox addons
If you value your sanity, put the XUL handbook down and step away slowly. Of the handful of completely failed software projects I've worked on, most have involved XUL and the Mozilla runtime stack in some major way.
The complexity of XUL isn't worth it for the payoff, IMHO. Stick with something simple like Shoes or Tk, or go for Qt or WxWindows if you need a rich widget set. Don't let the fact that XUL looks kind of like HTML mislead you into thinking it'll be easy to build on and deploy.
If you value your sanity, put the XUL handbook down and step away slowly. Of the handful of completely failed software projects I've worked on, most have involved XUL and the Mozilla runtime stack in some major way.
The complexity of XUL isn't worth it for the payoff, IMHO. Stick with something simple like Shoes or Tk, or go for Qt or WxWindows if you need a rich widget set. Don't let the fact that XUL looks kind of like HTML mislead you into thinking it'll be easy to build on and deploy.
In that case it's worth plunking down the cash for a Qt license (or going Open Source). It really is the best framework for doing cross-platform native-ish development.
http://www.trolltech.com/
http://www.trolltech.com/
I got into programming via the games route, and until pretty recently, that meant to-the-metal C, C++ and the libraries close to the system. (and when I started to teach myself to program, I hadn't heard of the internet) I've always tried to stay on top with other tech as well though, including the web, and now that I've given up game programming, my consulting work is about 50% client-side (C/Win32, C/UNIX, C++/MFC, .NET, Java - you name it) and 50% web-based. I enjoy both.
I guess the web is what's hot right now (and that's hardly going to change so quickly) so it's what attracts the freshest talent. I don't think there's anything fundamental about web technology that will attract "YC style hackers". I also don't think the desktop is dead just yet.
I suppose it's therefore no surprise that my own pet project is a kind of web/client hybrid that you'll be able to use either via a browser or run locally. (although some of the more complex graphical UI is pretty tricky to do in a browser, so we'll have to see what happens)
I'm probably in the wrong country to help you out directly, but I suspect there are plenty of people out there that fit your requirements. I don't hang out there, but you could check the Joel on Software boards/jobs, I understand that's frequented by Windows folk.
EDIT: this post seems to make me sound old. I'm 24, so typical YCer age, as far as I can tell.
I guess the web is what's hot right now (and that's hardly going to change so quickly) so it's what attracts the freshest talent. I don't think there's anything fundamental about web technology that will attract "YC style hackers". I also don't think the desktop is dead just yet.
I suppose it's therefore no surprise that my own pet project is a kind of web/client hybrid that you'll be able to use either via a browser or run locally. (although some of the more complex graphical UI is pretty tricky to do in a browser, so we'll have to see what happens)
I'm probably in the wrong country to help you out directly, but I suspect there are plenty of people out there that fit your requirements. I don't hang out there, but you could check the Joel on Software boards/jobs, I understand that's frequented by Windows folk.
EDIT: this post seems to make me sound old. I'm 24, so typical YCer age, as far as I can tell.
i come from a somewhat similar background (i'm 23).
to add on: this is why i'm very happy with .NET. the overlap between web apps in ASP.NET and client based apps is large. no mac or linux, obviously. recently i've started building a small windows app again, and i've been so pleased by how quickly and smoothly it's been - even though it's been years since i've worked on a windows app.
when i first saw this post title - i instantly thought in my head, hey - doesn't rescuetime do that?! i absolutely love their product. i'd work for them in a heartbeat if my skillz were better.
i don't think client-based apps are dying, at all. if anything, rescuetime is showing that they are on the rebound. good work, guys.
to add on: this is why i'm very happy with .NET. the overlap between web apps in ASP.NET and client based apps is large. no mac or linux, obviously. recently i've started building a small windows app again, and i've been so pleased by how quickly and smoothly it's been - even though it's been years since i've worked on a windows app.
when i first saw this post title - i instantly thought in my head, hey - doesn't rescuetime do that?! i absolutely love their product. i'd work for them in a heartbeat if my skillz were better.
i don't think client-based apps are dying, at all. if anything, rescuetime is showing that they are on the rebound. good work, guys.
I think you're suffering from a virtuous circle or Catch-22 depending on your viewpoint. This site (and others) have made out that everything is going to be a web app, so lots of people want to work on web apps and then if all the smart are working on web apps then web apps look like the place to be.
I'd like it as long as it was Mac.
To elaborate, the pool of people willing to pay for Linux client software isn't large enough. The pool of people willing to pay for Windows software is large enough, but I don't enjoy writing C#/.NET or MFC. And as importantly, it is hard to stick out as an indie in that environment.
So, the time invested to learn these technologies isn't worthwhile.
On the mac, you have a user base which is used to paying for software, and it is growing. And although no environment is perfect, I do enjoy writing Objective C and Cocoa.
To elaborate, the pool of people willing to pay for Linux client software isn't large enough. The pool of people willing to pay for Windows software is large enough, but I don't enjoy writing C#/.NET or MFC. And as importantly, it is hard to stick out as an indie in that environment.
So, the time invested to learn these technologies isn't worthwhile.
On the mac, you have a user base which is used to paying for software, and it is growing. And although no environment is perfect, I do enjoy writing Objective C and Cocoa.
Personally, I love client stuff way more than web stuff. Web stuff is just so limited in what can be done, and client stuff totally gives you freedom...
But that's not the truth. I've been doing desktop stuff for years so it comes naturally to me, whereas web stuff is new. The people you are meeting here grew up with web stuff, not with desktop stuff.
But that's not the truth. I've been doing desktop stuff for years so it comes naturally to me, whereas web stuff is new. The people you are meeting here grew up with web stuff, not with desktop stuff.
Sure.
It's just another marketing/sales numbers-based decision. If I had an app that targeted MS Office apps, for instance, I wouldn't have a bit of a problem writing it on the client.
I'd take it a step further. If I had an app that took a minute to load the first time over the web, I'd seriously consider just targeting the client and getting more bang for the buck.
The reason some folks stay on the web is that people don't want to wait to use anything. If you can show them a working app they can play with in under 5 seconds, your click-through and sales go up. You can't do that with client apps.
Nothing special about web or client, it's all just a numbers decision (or at least, it should be)
It's just another marketing/sales numbers-based decision. If I had an app that targeted MS Office apps, for instance, I wouldn't have a bit of a problem writing it on the client.
I'd take it a step further. If I had an app that took a minute to load the first time over the web, I'd seriously consider just targeting the client and getting more bang for the buck.
The reason some folks stay on the web is that people don't want to wait to use anything. If you can show them a working app they can play with in under 5 seconds, your click-through and sales go up. You can't do that with client apps.
Nothing special about web or client, it's all just a numbers decision (or at least, it should be)
I have a number of years experience working with Tcl, and also a bit of Tk, which fits the bill nicely for that kind of thing.
However... yeah, doing client apps is not "where it's at" compared to web apps. I never thought I would say that. Web apps were, once upon a time, sort of ugly and boring compared to all the cool stuff you could do with 'real' apps. But with things like Rails, and the ability to easily deploy new versions, the world has changed, and web apps are "where it's at", in a lot of ways.
If you're interested in using Tcl and Tk, I could send out a few feelers to that community. Lots of them aren't really in the YC 'demographic' (older, families, etc...), but some of them are pretty sharp coders.
However... yeah, doing client apps is not "where it's at" compared to web apps. I never thought I would say that. Web apps were, once upon a time, sort of ugly and boring compared to all the cool stuff you could do with 'real' apps. But with things like Rails, and the ability to easily deploy new versions, the world has changed, and web apps are "where it's at", in a lot of ways.
If you're interested in using Tcl and Tk, I could send out a few feelers to that community. Lots of them aren't really in the YC 'demographic' (older, families, etc...), but some of them are pretty sharp coders.
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work.
The same is true about web interfaces, of course, but they at least have hype behind them, and therefore they're picked up by trendy young coders. Plus, there's the challenge -- or, IMO, endless pain -- of actually making it work across multiple browsers.
There is certainly an art to making a good, usable interface, but it's not a typical programmer's challenge, and writing a UI by hand is simply a pain in the ass. It sucks to do the stupid connections and packing if you don't have a drag and drop layout tool. And once you have that, you start leaving the programmer's domain, and into the designer's domain.
Note, I'm only talking about interfaces. The logic behind them can be anything, but it's the same logic with a web or desktop frontend.
I think it's just that once the shine wore off of the "hey, I can make buttons!" thing, the highly motivated programmers realized that UI design wasn't something that they wanted to focus on -- it's better left to designers (in theory at least -- im reality it's probably left to lowly grunt programmers) who can make the UI with drag and drop GUI builders, leaving them to work on interesting technical challenges. Making a GUI tends to be incidental to the core of the problem. I suspect that if it wasn't for the shine factor in web apps, it would have the exact same sort of apathy that you see in most programmers about desktop GUIs.
The same is true about web interfaces, of course, but they at least have hype behind them, and therefore they're picked up by trendy young coders. Plus, there's the challenge -- or, IMO, endless pain -- of actually making it work across multiple browsers.
There is certainly an art to making a good, usable interface, but it's not a typical programmer's challenge, and writing a UI by hand is simply a pain in the ass. It sucks to do the stupid connections and packing if you don't have a drag and drop layout tool. And once you have that, you start leaving the programmer's domain, and into the designer's domain.
Note, I'm only talking about interfaces. The logic behind them can be anything, but it's the same logic with a web or desktop frontend.
I think it's just that once the shine wore off of the "hey, I can make buttons!" thing, the highly motivated programmers realized that UI design wasn't something that they wanted to focus on -- it's better left to designers (in theory at least -- im reality it's probably left to lowly grunt programmers) who can make the UI with drag and drop GUI builders, leaving them to work on interesting technical challenges. Making a GUI tends to be incidental to the core of the problem. I suspect that if it wasn't for the shine factor in web apps, it would have the exact same sort of apathy that you see in most programmers about desktop GUIs.
"GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work."
Oh, so very wrong. Yes, technically, the mechanics of making a GUI are not hard, but it's much like good technical writing. Deciding what goes where, what goes in, what stays, out; these are hard choices. Just look at almost any random shareware VB app. Fugly.
Oh, so very wrong. Yes, technically, the mechanics of making a GUI are not hard, but it's much like good technical writing. Deciding what goes where, what goes in, what stays, out; these are hard choices. Just look at almost any random shareware VB app. Fugly.
Agreed. My secret shame is that I love tinkering with GUI and trying new things. I have a deep dissatisfaction for most GUI apps out there, and I take a lot of time when I write my apps to try and get it right.
Most coders simply aren't meticulous enough when it comes to interfaces. "Slap a button on the window" or "just throw an item in the menu" without thought are not usable solutions.
This is especially problematic in client-side software where marketing is only interested in bullet-point features. The accessibility and workflow behind these features tend to be suspect at best, downright unusable at worst.
I wish more coders would be interested in these things. The people I talk to about interfaces are either disinterested hackers who'd rather work on backend code, or artists with no conceptual grasp of the technical underpinnings of GUI. Ugh.
Most coders simply aren't meticulous enough when it comes to interfaces. "Slap a button on the window" or "just throw an item in the menu" without thought are not usable solutions.
This is especially problematic in client-side software where marketing is only interested in bullet-point features. The accessibility and workflow behind these features tend to be suspect at best, downright unusable at worst.
I wish more coders would be interested in these things. The people I talk to about interfaces are either disinterested hackers who'd rather work on backend code, or artists with no conceptual grasp of the technical underpinnings of GUI. Ugh.
I was talking from a coding point of view, since the post was asking about finding people to code a GUI. The challenge of designing a good UI is usually swamped by the need to write swaths of dumb code if you're actually coding GUIs. Design work is in a domain of it's own.
I would say that unless you're making command line programs or AI the most important part of an application is the GUI. It is all your customers see, and if it doesn't work nothing else matters much.
It's not unimportant. It's just menial and trivial when done in code. Yes, there's an art to it, but that's not a technical challenge in the programming domain. The outside veneer is important, but it's not interesting to work on from a technical viewpoint. And furthermore, it's best left to UI experts to design -- any sane GUI designer makes it easy enough for 90% of the UI to be done by drag and drop. (Yep. No sane GUI designers that I've seen yet exist for web apps,partly because there's no standard GUI toolkit.)
It's not like mechanical engineers spend the majority of their time deciding on the trim and positioning of internals which compose the interface to the car. Instead they collaborate with the designers the constraints on the interior layout, and then they leave the interface details to the designers, while working on the drivetrain, suspension, frame, and so on.
The point I'm making isn't that GUIs are unimportant. The point is that GUIs are uninteresting if you are looking for a technically challenging problem to solve with code. This lack of challenge can be compounded today with the trend towards designers providing specs to programmers, and then leaving the programmers to implement it, as the creative element is reduced.
It's not like mechanical engineers spend the majority of their time deciding on the trim and positioning of internals which compose the interface to the car. Instead they collaborate with the designers the constraints on the interior layout, and then they leave the interface details to the designers, while working on the drivetrain, suspension, frame, and so on.
The point I'm making isn't that GUIs are unimportant. The point is that GUIs are uninteresting if you are looking for a technically challenging problem to solve with code. This lack of challenge can be compounded today with the trend towards designers providing specs to programmers, and then leaving the programmers to implement it, as the creative element is reduced.
> For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work... [t]he same is true about web interfaces...
I wish it were true for web interfaces... something like balsamiq.com, but it would output html (or haml, etc.) instead of xml.
I wish it were true for web interfaces... something like balsamiq.com, but it would output html (or haml, etc.) instead of xml.
visual studio does that for web interfaces
i've done both (although my client-based experience is now a little old-ish). i've worked on client-based stuff (c++ mostly) and done your standard web app dev work (rails, php, java, etc.).
the turning point for me, where i decided that i wanted to focus more on web dev type things, was in a UI and software engineering class i took in college. we had to build a c/c++ program to process and display some data graphically, with a nice gui interface.
learning about, creating, and working with a modest GUI was painful and time consuming, to say the least. everyone struggled, and what took my group (4ish people) weeks in c/c++ and MFC would've taken me hours with html/javascript. the productivity difference and learning curve totally turned me off of client-based app work.
having said all of that, i acknowledge that i didn't do work in .net or in a java framework, and i know that the situation is currently much better than it used to be. i'm not claiming that one is better than the other, just explaining why i turned my focus away from client-based apps. i'd love to return to them, just haven't had the need or time to do so.
also, full disclosure, i dropped rescuetime an email about employment a while ago :)
the turning point for me, where i decided that i wanted to focus more on web dev type things, was in a UI and software engineering class i took in college. we had to build a c/c++ program to process and display some data graphically, with a nice gui interface.
learning about, creating, and working with a modest GUI was painful and time consuming, to say the least. everyone struggled, and what took my group (4ish people) weeks in c/c++ and MFC would've taken me hours with html/javascript. the productivity difference and learning curve totally turned me off of client-based app work.
having said all of that, i acknowledge that i didn't do work in .net or in a java framework, and i know that the situation is currently much better than it used to be. i'm not claiming that one is better than the other, just explaining why i turned my focus away from client-based apps. i'd love to return to them, just haven't had the need or time to do so.
also, full disclosure, i dropped rescuetime an email about employment a while ago :)
My advice: hire a sharp game programmer, specifically one who has worked on tools and has 1-5 years in the game industry. The pay is not that great for game programmers in that range of experience, so they can handle a startup salary. And they are typically enthusiastic and experienced in the right areas you want.
Many such programmers are burned out or just laid off, so they will consider working outside of games, but you have to bait them a little so they know you're not a corporate dullard. I would suggest a job listing with some game-programmer keywords or even sneaking onto CreativeHeads or Gamasutra.
I say this not in an exploitative mode, but because that was my profile when I jumped from games into a job as a 2000-era dot-com client software programmer. They specifically mentioned that they were looking for console programming experience because there were several former game programmers there who understood this dynamic. And I was quite happy with the time I spent there.
Many such programmers are burned out or just laid off, so they will consider working outside of games, but you have to bait them a little so they know you're not a corporate dullard. I would suggest a job listing with some game-programmer keywords or even sneaking onto CreativeHeads or Gamasutra.
I say this not in an exploitative mode, but because that was my profile when I jumped from games into a job as a 2000-era dot-com client software programmer. They specifically mentioned that they were looking for console programming experience because there were several former game programmers there who understood this dynamic. And I was quite happy with the time I spent there.
I personally don't mind writing client software. I'm still in school, and I honestly don't have a huge amount of experience, but efficiency is really appealing to me. Web programming is fun when using Django or Rails. The code is beautiful, and it provides a great way to innovate. However, when I sit back and think about all the extra nonsense that is going on under the hood of a web app I start to get slightly frustrated. I'm not saying that I can fix this or even that it isn't the best way for the web to be built. It's just that there is something cool to me about building a brilliantly efficient client side app. I'm not going to say that I enjoy optimizing assembly, but there is definitely something satisfying to me about creating a really efficient and secure application.
I'm not planning on making a career out of client software, but I do enjoy it at times. I strongly prefer writing web apps, but I also hack away at OpenGL and C++ occasionally in my spare time.
I'm not planning on making a career out of client software, but I do enjoy it at times. I strongly prefer writing web apps, but I also hack away at OpenGL and C++ occasionally in my spare time.
Writing clients is fun; writing cross-platform clients even moreso. Each platform has its own design philosophy, and I find it engaging learning each platform's intricacies, and coming to understand the psychology behind each platform's demographic.
I believe the greatest measure of an application is the user's productivity, and I believe most of that productivity is inherent in the design of the user interface. The users of each platform have different expectations of their user interface, however, so I believe it's my duty when developing cross-platform applications to be mindful of these expectations.
The work may seem unglamorous to most programmers, but if you can't get the human half of the interface right, any gains on the computer half of the interface are moot. That being said, I think most YC hackers do have an appreciation for this logic, it's just that client software is overkill for their requirements.
I believe the greatest measure of an application is the user's productivity, and I believe most of that productivity is inherent in the design of the user interface. The users of each platform have different expectations of their user interface, however, so I believe it's my duty when developing cross-platform applications to be mindful of these expectations.
The work may seem unglamorous to most programmers, but if you can't get the human half of the interface right, any gains on the computer half of the interface are moot. That being said, I think most YC hackers do have an appreciation for this logic, it's just that client software is overkill for their requirements.
I wrote one for AT&T that got deployed to ~1M PCs and lost my luster for client apps when Microsoft released Vista & XP SP2, both of which resulted in months of patch work just to get things working again before we could focus on newness again.
I'm sure some day I'll love Client Apps again, maybe when Microsoft isn't killing the little guy.
I'm sure some day I'll love Client Apps again, maybe when Microsoft isn't killing the little guy.
My company, Happy Camper Studios, builds cross-platform client apps using JRuby, Swing, and Monkeybars. We like it. :)
Try doing few usability studies with client-side software (I'm really talking Windows apps) and you'll see how much pushback you'll get. Consumers just hate installing apps. They absolutely loathe it. Everyone seems to be afraid of viruses and software. Now, this can be overcome to a degree if you're a huge company and have a well-known brand name that people trust and you can also overcome it by targeting a specific segment of the market that are computer knowledgeable and are willing to trust you. I'm not sure but I think that Firefox addons have less push-back than regular apps (just a guess, have no data).
So in short, make sure you do several usability studies with people who fit your market segment.
So in short, make sure you do several usability studies with people who fit your market segment.
I currently work on a project that has some similar technical goals to RescueTime. The OS-level work is what sucks. I don't mind working on GUIs, especially when it means applying the polish that really makes an app shine for users. That sort of stuff I can get into...
As a matter of fact, I fixed the Status Item icons for RescueTime (to match the standard icon style) just the other day because the ones that came with it bugged me!
Here you go!
http://djork.net/rescue/RescueTimeMenu_off.png
http://djork.net/rescue/RescueTimeMenu_on.png
As a matter of fact, I fixed the Status Item icons for RescueTime (to match the standard icon style) just the other day because the ones that came with it bugged me!
Here you go!
http://djork.net/rescue/RescueTimeMenu_off.png
http://djork.net/rescue/RescueTimeMenu_on.png
I've written a shareware app with a good GUI. I am not interested in working on it or any desktop app. Xobni is the only YC company I've heard of where the primary product or solution is a desktop app, so I think YCombinator also prefers web based apps.
By the way, I've always wondered--is there a feature in your product that monitors how often you mention RescueTime on news.YC and elsewhere? If there's not, or if it's not automated, you should add it. That way at the end of the day, you could see how often you've namedropped your product (as a measure of success). I'm only half-kidding. :)
By the way, I've always wondered--is there a feature in your product that monitors how often you mention RescueTime on news.YC and elsewhere? If there's not, or if it's not automated, you should add it. That way at the end of the day, you could see how often you've namedropped your product (as a measure of success). I'm only half-kidding. :)
http://www.google.com/search?q=site%3Anews.ycombinator.com+%...
http://www.google.com/search?q=site%3Anews.ycombinator.com+r...
Looks like 66 of the 481 pages with the word RescueTime somewhere on them have my username somewhere on the page. I imagine many of those are assorted duplicate views of the same comment and many more are threads where one person mentioned RT and I responded.
Feel free to sort thru the times that I've mentioned RescueTime to see if I meet your obviously high standards for contributing to the community.
Being a troll and finishing with a ":)" doesn't really make it okay.
:)
http://www.google.com/search?q=site%3Anews.ycombinator.com+r...
Looks like 66 of the 481 pages with the word RescueTime somewhere on them have my username somewhere on the page. I imagine many of those are assorted duplicate views of the same comment and many more are threads where one person mentioned RT and I responded.
Feel free to sort thru the times that I've mentioned RescueTime to see if I meet your obviously high standards for contributing to the community.
Being a troll and finishing with a ":)" doesn't really make it okay.
:)
Respectfully, I'm not going to go through your comments; I'm just going by what I remember reading over the past year. (By the way, I don't think that mentioning your company as often as possible is necessarily a bad thing, as I had alluded to in the parent post.) If you think that's a reasonable measure, though, go through my comments and find where I have ever been a troll before calling me that. I'd expected more from long time posters. Maybe you'll even find a congratulations post to some of your company's announcements (I'm not sure if I did in this case, but that's what I typically write.) To rephrase my question, have you ever considered having the app track how often one mention a certain keyword in their posts, as you are already tracking their browsing history? That way, you could say at the end of the week--"I mentioned RescueTime 20% more than last week." Of course, it wouldn't necessarily all be in one post in one day on News.YC--maybe in blogs, or gmail, and maybe once on average per html form post. Isn't that a cool idea? Thanks.
Hrm-- seemed and felt mean-spirited to me (your comment)-- I guess my sarcasm detector went off when it shouldn't. I apologize!
I think YC tends to attract people who want to innovate... but who associates desktop software with innovation anymore? That's so 1983. Younger guys have never "wasted" the time to develop the requisite skill-set and older guys haven't bothered to keep up their chops.
Besides, anybody who actually goes to MSDN conferences and hacks the windows API is probably on the corporate dole and would never be so dumb as to try starving/start-up.
On the upside, if everyone around here was still obsessing over client software, somebody might have beat RescueTime to the punch! :)
Besides, anybody who actually goes to MSDN conferences and hacks the windows API is probably on the corporate dole and would never be so dumb as to try starving/start-up.
On the upside, if everyone around here was still obsessing over client software, somebody might have beat RescueTime to the punch! :)
Heh- true 'nuff! If we could do what we do using only web software, we would. It seems that apps like Quicksilver (Mac), Enso (Windows), Firefox, etc., are still pretty darn innovative. But the agility that the web affords is pretty darn addictive.
I think within your post right here lies a lot of the problem. There needs to be a really compelling to write something as desktop software instead of as a web app, so most people don't even bother to learn how to write desktop software in the first place.
Absolutely, the paradigm of 'client-software' is becoming ambiguous for most of the web people. 'Porting' an existing web app to a 'client software' is a very trivial work, thanks to stuff like XULRunner.
Are you looking for one person to do the Mac, PC, and Linux desktop clients? That would explain why you haven't found anyone yet. People tend to become good at developing for only one of those platforms.
I can (and do) both web and Mac programming, but don't live near Seattle. Of the 2, I prefer Mac programming.
I can't speak for Windows or Linux client development, but most of the Mac developers I know are running (or want to start running) their own indie Mac software shops. So you might want to find some quality Mac software contractors (I know a few).
I can (and do) both web and Mac programming, but don't live near Seattle. Of the 2, I prefer Mac programming.
I can't speak for Windows or Linux client development, but most of the Mac developers I know are running (or want to start running) their own indie Mac software shops. So you might want to find some quality Mac software contractors (I know a few).
I'll try throw something in the mix, there is a matter of fashion. Back in the 90's C++ win32/MFC development was the highly regraded, I guess I should note that VB6.0 was very in demand as well, The technology and the market trends have changes so also the developers.
I for one don't like to write web applications (mainly because the technology fragmentation), and I prefer to use client application whenever I can.
Having say that I can't see myself writing Win32 API as a day job in the near future, for all the reasons mentioned above.
I for one don't like to write web applications (mainly because the technology fragmentation), and I prefer to use client application whenever I can.
Having say that I can't see myself writing Win32 API as a day job in the near future, for all the reasons mentioned above.
I still write C code and GUIs for stuff, but doing it in PHP,SQL,Perl is just so much quicker and easier for things that my C programming is not as frequent as it used to be and my C skills are getting stale. I'm not in need of a client-side app as much anymore nowadays, the browsers are so capable that it's not as necessary to do heavy client-side apps much. I'm not discrediting client-side apps, it's just that the demand isn't as high anymore.
I'd rather code web-apps than Win-API apps. I'd rather code OSX apps than web apps. But mostly, I'd rather live in a tent than become a multi platform installer/GUI porting expert. There are enough more interesting (or less painful) jobs around for the people who are good enough to do a good job of that. But you might be able to pick up a former banking coder now, and those guys are mostly pre-demoralized :)
I think client software is seeing a revival with mobile platforms like the iPhone OSX and Android. Right now the best experience in those devices is delivered by native client apps. Script languages like Flash and a browser with a larger screen enables rich web applications and thus reduces the need to write a native app for platforms like Windows.
webwright, haven't seen your job ad, but I guess its not that challenging for a real "client" hacker to become attracted. Personally, I wouldn't bother applying because I see no future for myself as a "desktop" fanatic at your company - don't take it seriously, I do and love web apps too!
I was looking for a job a couple of years ago, doing precisely that, in wxWidgets. And everybody seemed to hate C++ and love Java and related 'new' languages.
Right now, I'm working full time doing PHP and I want to keep the job stability even with that slow language, so sorry, too late.
Right now, I'm working full time doing PHP and I want to keep the job stability even with that slow language, so sorry, too late.
I actually really like building client software. And web software. And services. And agents/bots. And scripting engines.
Yes, those people exist, it's just not trendy to write lower-level OS-specific software these days. Maybe it never will be again.
Yes, those people exist, it's just not trendy to write lower-level OS-specific software these days. Maybe it never will be again.
Compiled, non cross platform, download-only, "client software"... no.
Cross platform, deployable on the web or any OS desktop, or mobile phones (with new generation browsers)... yes.
But we had to write an entire framework first ;)
Cross platform, deployable on the web or any OS desktop, or mobile phones (with new generation browsers)... yes.
But we had to write an entire framework first ;)
in Lisp?
Just out of curiosity, what do you see as "the YC hacker mold"?
If you want to write to MFC, which I'm sure would make the most sense, then that's probably your problem.
You actually have something against MFC? You realise that MFC is a pretty thin wrapper around the Windows API, right?
Well, I do actually hate the WORD/DWORD stuff in MFC/Win32.
And I like wxWidgets. So, sue me.
And I like wxWidgets. So, sue me.
WORD, DWORD has little to do with MFC. It has a lot more to do with Win32. You know that one of the main criteria of MFC is backwards compatibility - what's your idea as to how to solve that problem?
At the same time, we've been looking for a hacker to help us with the (installable Mac, PC, and hopefully Linux) RescueTime client (as well as other startup duties, ranging from our API to helping with product strategy). We've looking at local Seattle folks as well as remote people in nearby timezones.
We have some good candidates, but I've been struck by how FEW fit the YC hacker mold...
So, out of curiosity-- does the idea of writing client software appeal to anyone in the Hacker News demographic? This isn't a plea for candidates-- I'm more curious if people find the idea of writing client software appealing anymore.