The desktop and the developer
May. 18th, 2014 10:53 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I was at the OpenStack Summit this week. The overwhelming majority of OpenStack deployments are Linux-based, yet the most popular laptop vendor (by a long way) at the conference was Apple. People are writing code with the intention of deploying it on Linux, but they're doing so under an entirely different OS.
But what's really interesting is the tools they're using to do so. When I looked over people's shoulders, I saw terminals and a web browser. They're not using Macs because their development tools require them, they're using Macs because of what else they get - an aesthetically pleasing OS, iTunes and what's easily the best trackpad hardware/driver combination on the market. These are people who work on the same laptop that they use at home. They'll use it when they're commuting, either for playing videos or for getting a head start so they can leave early. They use an Apple because they don't want to use different hardware for work and pleasure.
The developers I was surrounded by aren't the same developers you'd find at a technical conference 10 years ago. They grew up in an era that's become increasingly focused on user experience, and the idea of migrating to Linux because it's more tweakable is no longer appealing. People who spend their working day making use of free software (and in many cases even contributing or maintaining free software) won't run a free software OS because doing so would require them to compromise on things that they care about. Linux would give them the same terminals and web browser, but Linux's poorer multitouch handling is enough on its own to disrupt their workflow. Moving to Linux would slow them down.
But even if we fixed all those things, why would somebody migrate? The best we'd be offering is a comparable experience with the added freedom to modify more of their software. We can probably assume that this isn't a hugely compelling advantage, because otherwise it'd probably be enough to overcome some of the functional disparity. Perhaps we need to be looking at this differently.
When we've been talking about developer experience we've tended to talk about the experience of people who are writing software targeted at our desktops, not people who are incidentally using Linux to do their development. These people don't need better API documentation. They don't need a nicer IDE. They need a desktop environment that gives them access to the services that they use on a daily basis. Right now if someone opens an issue against one of their bugs, they'll get an email. They'll have to click through that in order to get to a webpage that lets them indicate that they've accepted the bug. If they know that the bug's already fixed in another branch, they'll probably need to switch to github in order to find the commit that contains the bug number that fixed it, switch back to their issue tracker and then paste that in and mark it as a duplicate. It's tedious. It's annoying. It's distracting.
If the desktop had built-in awareness of the issue tracker then they could be presented with relevant information and options without having to click through two separate applications. If git commits were locally indexed, the developer could find the relevant commit without having to move back to a web browser or open a new terminal to find the local checkout. A simple task that currently involves multiple context switches could be made significantly faster.
That's a simple example. The problem goes deeper. The use of web services for managing various parts of the development process removes the need for companies to maintain their own infrastructure, but in the process it tends to force developers to bounce between multiple websites that have different UIs and no straightforward means of sharing information. Time is lost to this. It makes developers unhappy.
A combination of improved desktop polish and spending effort on optimising developer workflows would stand a real chance of luring these developers away from OS X with the promise that they'd spend less time fighting web browsers, leaving them more time to get on with development. It would also help differentiate Linux from proprietary alternatives - Apple and Microsoft may spend significant amounts of effort on improving developer tooling, but they're mostly doing so for developers who are targeting their platforms. A desktop environment that made it easier to perform generic development would be a unique selling point.
I spoke to various people about this during the Summit, and it was heartening to hear that there are people who are already thinking about this and hoping to improve things. I'm looking forward to that, but I also hope that there'll be wider interest in figuring out how we can make things easier for developers without compromising other users. It seems like an interesting challenge.
But what's really interesting is the tools they're using to do so. When I looked over people's shoulders, I saw terminals and a web browser. They're not using Macs because their development tools require them, they're using Macs because of what else they get - an aesthetically pleasing OS, iTunes and what's easily the best trackpad hardware/driver combination on the market. These are people who work on the same laptop that they use at home. They'll use it when they're commuting, either for playing videos or for getting a head start so they can leave early. They use an Apple because they don't want to use different hardware for work and pleasure.
The developers I was surrounded by aren't the same developers you'd find at a technical conference 10 years ago. They grew up in an era that's become increasingly focused on user experience, and the idea of migrating to Linux because it's more tweakable is no longer appealing. People who spend their working day making use of free software (and in many cases even contributing or maintaining free software) won't run a free software OS because doing so would require them to compromise on things that they care about. Linux would give them the same terminals and web browser, but Linux's poorer multitouch handling is enough on its own to disrupt their workflow. Moving to Linux would slow them down.
But even if we fixed all those things, why would somebody migrate? The best we'd be offering is a comparable experience with the added freedom to modify more of their software. We can probably assume that this isn't a hugely compelling advantage, because otherwise it'd probably be enough to overcome some of the functional disparity. Perhaps we need to be looking at this differently.
When we've been talking about developer experience we've tended to talk about the experience of people who are writing software targeted at our desktops, not people who are incidentally using Linux to do their development. These people don't need better API documentation. They don't need a nicer IDE. They need a desktop environment that gives them access to the services that they use on a daily basis. Right now if someone opens an issue against one of their bugs, they'll get an email. They'll have to click through that in order to get to a webpage that lets them indicate that they've accepted the bug. If they know that the bug's already fixed in another branch, they'll probably need to switch to github in order to find the commit that contains the bug number that fixed it, switch back to their issue tracker and then paste that in and mark it as a duplicate. It's tedious. It's annoying. It's distracting.
If the desktop had built-in awareness of the issue tracker then they could be presented with relevant information and options without having to click through two separate applications. If git commits were locally indexed, the developer could find the relevant commit without having to move back to a web browser or open a new terminal to find the local checkout. A simple task that currently involves multiple context switches could be made significantly faster.
That's a simple example. The problem goes deeper. The use of web services for managing various parts of the development process removes the need for companies to maintain their own infrastructure, but in the process it tends to force developers to bounce between multiple websites that have different UIs and no straightforward means of sharing information. Time is lost to this. It makes developers unhappy.
A combination of improved desktop polish and spending effort on optimising developer workflows would stand a real chance of luring these developers away from OS X with the promise that they'd spend less time fighting web browsers, leaving them more time to get on with development. It would also help differentiate Linux from proprietary alternatives - Apple and Microsoft may spend significant amounts of effort on improving developer tooling, but they're mostly doing so for developers who are targeting their platforms. A desktop environment that made it easier to perform generic development would be a unique selling point.
I spoke to various people about this during the Summit, and it was heartening to hear that there are people who are already thinking about this and hoping to improve things. I'm looking forward to that, but I also hope that there'll be wider interest in figuring out how we can make things easier for developers without compromising other users. It seems like an interesting challenge.
Re: mac developer working with linux
Date: 2014-05-19 09:32 pm (UTC)> I can learn new tools.
It seems to me you are used to ^C and ^V for copy-pasting, and, illogically, you assume these are rational. It also proves, by extension, that you cannot use new tools, although you believe you do. UNIXes terminals uses ^* for, emh, process control. Conveniently, Mac's added the Cmd button -- whether that is rational is irrelevant -- to bypass this behavior and harmonize desktop and console.
Regarding the file:// schema, they are defined in RFC 1630 and 1738, and, so, complying applications would resolve them correctly. However, you are right, the default behavior should be to assume this schema when not specified, or, more simply, change the file browser you use so it does not add the file schema.
Point is, one cannot generalize and rant when there is lack of knowledge or dogmatism.
Personally I do not use a DE, but a WM (when I am not using a 80x25 terminal). I do not believe in the uniformity some you believe exist. Apple simply provides a foundation and proposes best practices around which developers can build and extend. Now the FOSS community is incapable to agree on what the API should be, nor what should be those best practices. Hence, groups build DEs, others build VMs, others target the console users. All is right and okay, usability is not an exact science. Find what suits you best, pick the tool needed for the job. If it integrates, nice, if not, nice... a tool does the job. ;)
P.S. If one cannot navigate to arbitrarily complex path with a tool, pick an axe.
Re: mac developer working with linux
Date: 2014-05-19 10:17 pm (UTC)I also have this irrational expectation that the dude who developed the terminal app should be smart enough to know that (regardless of internal representation on the clipboard) it is worthless to paste a URL into a bash shell.
Yea. In the past Six months, I've gone from zero knowledge of linux to debugging kernel drivers for embedded hardware, but I have no ability to learn tools. I have built a mac-based cross-compiler for PPC-linux, integrated it with xcode 5, set up a mechanism to build ext3 formatted SD cards on a mac, but I have no ability to learn tools. Let me tell you...anyone who can navigate, understand and modify that rats nest of old-school source code called "linux kernel" can learn whatever he wants. I just don't want to waste my time hacking a terminal app to get it work more rationally. I'll just buy apple's and spend my time doing productive instead.
With that reply, you show why linux will NEVER be competitive on the desktop. Its advocates generally don't see any need to do the things that need to be done to create an experience most people expect. Most of you have a hacker's mentality...not the mentality of a person who has to sell a product to average people.
Don't get me wrong...I have no problem with a hacker's mentality. It's perfectly fine...but it ain't gonna create a general purpose desktop that is worth having. It hasn't in how many years of trying?
Re: mac developer working with linux
Date: 2014-05-20 05:59 pm (UTC)I also have this irrational expectation that the dude who developed the terminal app should be smart enough to know that (regardless of internal representation on the clipboard) it is worthless to paste a URL into a bash shell.
ENDQUOTE
Really? I never want to "wget $pasted-URL" in my BASH shell?
You are being way too dogmatic about your specific, narrow use case being the only one that needs to be supported.
Re: mac developer working with linux
Date: 2014-05-20 11:04 pm (UTC)Anyway, to paste in most standard Linux terminals, select whatever text you wish to paste, then do shift+insert or middle click. This works in gui apps as well.
Also please do note that there are generally at least two clipboards in Linux systems -- the "selection clipboard" and the "ctrl+c" clipboard. To paste from the ctrl+c clipboard in a terminal you will have to press ctrl+shift+v, since, as stated above, ctrl+v is reserved for another function.
Re: mac developer working with linux
Date: 2014-05-23 12:49 pm (UTC)Consider the possibility that complaining about having to use a right click context menu and/or two-key keyboard shortcuts to paste, when everything in the OS consistently supports X11's middle click paste, makes you sound like the ignorant and uneducated troll you are.