5 ms·

There's real opportunity here for Github and I hope they take it. Why is the basic workflow of the modern-day programmer split over multiple tools and over mul

by lhnz 13y ago

There's real opportunity here for Github and I hope they take it. Why is the basic workflow of the modern-day programmer split over multiple tools and over multiple systems? Aspects of Github could be modularised and added to the editor while still keeping the underlying tool simple and this could change our user experience for the better. Imagine flipping through your pull requests in the text editor and then seeing your friends comments and code reviews appear on top. Imagine an issue being created on Github and the file(s) referenced instantly glowing. This opens doors to thinking about the engineering workflow in a new holistic manner.

techpeace 13y ago
IDEs, while they have fallen out of favor somewhat in the web development community, offer such a "holistic" development experience already - complete with deep integration into GitHub, in some instances.
- lhnz 13y ago
  I think you miss the point. Being modularised allows the basic user experience to be kept very simple. It does not need to grow into something like an IDE. Hell, according to Packages [0] even tools like find-and-replace have been modularised so I do not think it follows that Github would carelessly decide to create a big ball of mud! And additionally this tool has removed barriers that previously existed before. Since it was created by Github they will be able to expose APIs to create features which are currently not possible. Likewise the UI being implemented with WebKit means that the user interface can tightly represent what a user is used to seeing at different stages of their development process. You might have read "The Design of Everyday Things" [1] before. There are certain elements which you need to control to create a good user experience: (1) discoverability, (2) feedback, (3) the conceptual model, (4) affordances, (5) signifiers, and (6) mappings. Without ease in changing the UI, and the possibility that Github will have self-interest in exposing extra APIs, it would be a lot more difficult to control for each of these. It's just an opportunity to try new ideas. I'm not suggesting that this would be preferable to everybody. [0] http://atom.io/packages http://atom.io/packages [1] http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0465067107 http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d...
  - basicallydan 13y ago
    > Since it was created by Github they will be able to expose APIs to create features which are currently not possible. You're probably right, but even if this is not the case, they will at least hopefully have a better understanding of how to use the APIs well, given how often they work on and with their own APIs.
  - HelloNurse 13y ago
    "Being modularised allows the basic user experience to be kept very simple." The basic user experience does not exist; or rather it is trivially basic in any text editor. What's important is the advanced user experience, and it simply doesn't exist yet. For instance, Python support amounts to syntax highlighting; nothing compared to python-mode and elpy in Emacs, or PyDev in Eclipse. There's also a large gap between the promise of "Full-featured, right out of the box" and offering fundamental functionality like settings-view and command-palette as extension packages. What Atom has to offer, currently, is a bloated abuse of web technology with little appeal beyond Javascript hipsters. This project has years of hard work ahead to begin competing with Emacs and Vim in some niches; hard work that isn't going to happen because it's proprietary software, and contributors will prefer the open source text editors.
theboywho 13y ago
Why is seeing your friends comments and code reviews in the text editor any better than seeing them in the browser? Are we becoming this lazy? or this busy?
- ibrahima 13y ago
  Potentially fewer context switches and interruptions? I know for me the browser is a potential landmine of distraction, it might be handy to be able to limit that.
  - kbenson 13y ago
    I think somewhere along the way we lost sight what context switching really is. Just because you put a different activity in the same tool doesn't mean there's not a context switch when you move to that activity. Do you really think there's not a context switch when you change from writing and thinking about your own code to reviewing pull requests and comments? There may be benefits to integrating extra functionality, but let's not imagine there's no cost to changing your mode of operation just because it's in the same tool.
- basicallydan 13y ago
  Minimising context switching is a big part of improving programmer productivity, as I'm sure you're aware. This may not seem like much, but large increases in productivity can be achieved through small increases building up; every little helps. Plus, it's cool.
  - theboywho 13y ago
    I think you confused context switching with app switching. Yes having Github activity in the text editor means less app switching, but you are still context switching; from writing code to reading comment, which is the real productivity killer. Why not just add gmail to that text editor while we're at it and save ourselves some time?
- rjzzleep 13y ago
  i see people saying less context switches. but isn't this the exact opposite? it's way more context switches? isn't this the same as having our mails popup up notifications every so often or your gmail aggregating twitter and Facebook, because people thought it would make them more productive
beefsack 13y ago
My hope is that the core of Atom isn't so bloated with GitHub integration and that integration is optionally available through the plugin management system. I'm of the type who prefers to use the text editor just for code and other tools for source control and project management.
- lhnz 13y ago
  >> that integration is optionally available through the plugin management system Given that even find-and-replace [0] exists as a module I think you have nothing to worry about. [0] http://atom.io/packages/find-and-replace http://atom.io/packages/find-and-replace
curun1r 13y ago
> There's real opportunity here for Github and I hope they take it. I think the philosophy here is that there is a real opportunity and they hope that you take it (or someone in the community). They're creating a highly-hackable editor and their API allows access to everything you've asked for. They're going to build a ton of add-ons too, but they want the community to build a lot of this stuff. The most creative product team in the world can't match millions of developers solving their own problems, so rather than try to build the perfect product for everyone, they're building the most flexible product for everyone to mold into what they need.
jcromartie 13y ago
> Why is the basic workflow of the modern-day programmer split over multiple tools and over multiple systems? I disagree that this is a problem. Replace "programmer" with any other profession, and you'll see it's universally silly.
SSpeicher 13y ago
> Aspects of Github could be modularised and added to the editor while still keeping the underlying tool simple and this could change our user experience for the better. This is essentially what we've done with some Rational tools (such as Team Concert) using by defining a set of loose-coupled RESTful capabilities for tool-based integrated, called OSLC http://open-services.net http://open-services.net It has the nice quality, if adopted, as being able to link to you own issue tracker hosted elsewhere (bugzilla, jira, etc), CI, end-user need management, etc. Atom has some limitations, I could see where OSLC and ActivityStreams would be a bit more interesting.

by lhnz 13y ago

techpeace 13y ago

IDEs, while they have fallen out of favor somewhat in the web development community, offer such a "holistic" development experience already - complete with deep integration into GitHub, in some instances.

lhnz 13y ago
I think you miss the point. Being modularised allows the basic user experience to be kept very simple. It does not need to grow into something like an IDE. Hell, according to Packages [0] even tools like find-and-replace have been modularised so I do not think it follows that Github would carelessly decide to create a big ball of mud! And additionally this tool has removed barriers that previously existed before. Since it was created by Github they will be able to expose APIs to create features which are currently not possible. Likewise the UI being implemented with WebKit means that the user interface can tightly represent what a user is used to seeing at different stages of their development process. You might have read "The Design of Everyday Things" [1] before. There are certain elements which you need to control to create a good user experience: (1) discoverability, (2) feedback, (3) the conceptual model, (4) affordances, (5) signifiers, and (6) mappings. Without ease in changing the UI, and the possibility that Github will have self-interest in exposing extra APIs, it would be a lot more difficult to control for each of these. It's just an opportunity to try new ideas. I'm not suggesting that this would be preferable to everybody. [0] http://atom.io/packages http://atom.io/packages [1] http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0465067107 http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d...
- basicallydan 13y ago
  > Since it was created by Github they will be able to expose APIs to create features which are currently not possible. You're probably right, but even if this is not the case, they will at least hopefully have a better understanding of how to use the APIs well, given how often they work on and with their own APIs.
- HelloNurse 13y ago
  "Being modularised allows the basic user experience to be kept very simple." The basic user experience does not exist; or rather it is trivially basic in any text editor. What's important is the advanced user experience, and it simply doesn't exist yet. For instance, Python support amounts to syntax highlighting; nothing compared to python-mode and elpy in Emacs, or PyDev in Eclipse. There's also a large gap between the promise of "Full-featured, right out of the box" and offering fundamental functionality like settings-view and command-palette as extension packages. What Atom has to offer, currently, is a bloated abuse of web technology with little appeal beyond Javascript hipsters. This project has years of hard work ahead to begin competing with Emacs and Vim in some niches; hard work that isn't going to happen because it's proprietary software, and contributors will prefer the open source text editors.

theboywho 13y ago

Why is seeing your friends comments and code reviews in the text editor any better than seeing them in the browser? Are we becoming this lazy? or this busy?

ibrahima 13y ago
Potentially fewer context switches and interruptions? I know for me the browser is a potential landmine of distraction, it might be handy to be able to limit that.
- kbenson 13y ago
  I think somewhere along the way we lost sight what context switching really is. Just because you put a different activity in the same tool doesn't mean there's not a context switch when you move to that activity. Do you really think there's not a context switch when you change from writing and thinking about your own code to reviewing pull requests and comments? There may be benefits to integrating extra functionality, but let's not imagine there's no cost to changing your mode of operation just because it's in the same tool.
basicallydan 13y ago
Minimising context switching is a big part of improving programmer productivity, as I'm sure you're aware. This may not seem like much, but large increases in productivity can be achieved through small increases building up; every little helps. Plus, it's cool.
- theboywho 13y ago
  I think you confused context switching with app switching. Yes having Github activity in the text editor means less app switching, but you are still context switching; from writing code to reading comment, which is the real productivity killer. Why not just add gmail to that text editor while we're at it and save ourselves some time?
rjzzleep 13y ago
i see people saying less context switches. but isn't this the exact opposite? it's way more context switches? isn't this the same as having our mails popup up notifications every so often or your gmail aggregating twitter and Facebook, because people thought it would make them more productive

beefsack 13y ago

My hope is that the core of Atom isn't so bloated with GitHub integration and that integration is optionally available through the plugin management system. I'm of the type who prefers to use the text editor just for code and other tools for source control and project management.

lhnz 13y ago
>> that integration is optionally available through the plugin management system Given that even find-and-replace [0] exists as a module I think you have nothing to worry about. [0] http://atom.io/packages/find-and-replace http://atom.io/packages/find-and-replace

curun1r 13y ago

> There's real opportunity here for Github and I hope they take it. I think the philosophy here is that there is a real opportunity and they hope that you take it (or someone in the community). They're creating a highly-hackable editor and their API allows access to everything you've asked for. They're going to build a ton of add-ons too, but they want the community to build a lot of this stuff. The most creative product team in the world can't match millions of developers solving their own problems, so rather than try to build the perfect product for everyone, they're building the most flexible product for everyone to mold into what they need.

jcromartie 13y ago

> Why is the basic workflow of the modern-day programmer split over multiple tools and over multiple systems? I disagree that this is a problem. Replace "programmer" with any other profession, and you'll see it's universally silly.

SSpeicher 13y ago

> Aspects of Github could be modularised and added to the editor while still keeping the underlying tool simple and this could change our user experience for the better. This is essentially what we've done with some Rational tools (such as Team Concert) using by defining a set of loose-coupled RESTful capabilities for tool-based integrated, called OSLC http://open-services.net http://open-services.net It has the nice quality, if adopted, as being able to link to you own issue tracker hosted elsewhere (bugzilla, jira, etc), CI, end-user need management, etc. Atom has some limitations, I could see where OSLC and ActivityStreams would be a bit more interesting.