3 ms·

I'll take issue with this claim: "Work environments are a very personal thing. They exist to serve only one person: you. Me-me-me is a winning attitude when dea

I'll take issue with this claim: "Work environments are a very personal thing. They exist to serve only one person: you. Me-me-me is a winning attitude when dealing with your environment." I think it's considerably more important to have a (basically good) work environment in which your colleagues can sit down and use fluently than to have one that's absolutely optimized to your individual tastes.

wting 13y ago
Do you share workstations with your co-workers or do significant amounts of pair programming? I'm not sure why my work environment should be optimized for a <1% use case.
- aetherson 13y ago
  I do significant amounts of pair programming. But even more so, I don't think that your coworkers using your workstation should be a <1% use case even if you never pair. My contention is that: 1. Work environments -- including ones that don't formally pair -- should be highly collaborative. 2. It's typically massively less efficient to help someone past a block or communicate a new coding technique via telling them what to do rather than doing it. Much less anything even remotely iterative, where you need to, say, write some code, look at some output, and write some more code. 3. The difference between "a basically good development environment" and "a development environment that is specifically optimized for just specifically you" is actually quite small. There's no real need to sacrifice much of anything in order to get an environment optimized specifically for you.
wting 13y ago
Do you share workstations with your co-workers or do significant amounts of pair programming? I'm not sure why my work environment should be optimized for a <1% use case.
JackMorgan 13y ago
If you pair a majority of the time, sure, make a standardized workstation with your team. My team uses viemu in VS, which the rest of our office detests, but hey, we are the ones pairing 99% of the time. When I am not pairing for the majority, I setup my machine to my tastes, and simply install a "default" editor for the few times someone else actually needs to type on my machine. Emacs and IDEA both have good ways to revert everything to defaults temporarily. I do not believe, however, that a perfectly customized setup has only small gains. For example, consider two tools that I have never seen as defaults in any editor or IDE: rainbow parens/brackets and paredit mode. Rainbow parens just highlights pairs: http://stevelosh.com/media/images/blog/2010/09/rainbow.png http://stevelosh.com/media/images/blog/2010/09/rainbow.png And here is a short minute paredit mode explanation: http://www.youtube.com/watch?v=D6h5dFyyUX0 http://www.youtube.com/watch?v=D6h5dFyyUX0 When actually editing code, those two tools save me several hundred keystrokes an hour. And those are just the first two tools I thought to use as an example out of the entire toolbox that is emacs. If I was to now give up just those two tools, I would be sentencing myself to the mental equivalent of tying five pound weights to my legs for the marathon that is the rest of my programming career. Why would I intentionally require myself to type more keys per hour to do the same editing, rather than just learning a faster way to edit? This is, obviously, also my argument for learning the vim editing system (which I also use in emacs).
- aetherson 13y ago
  I'm not advocating accepting an editor or IDE default, I'm advocating a standardized environment for a company. If rainbow parens are super-useful, then they can be super-useful for everybody. And that's another thing that a standardized environment does: it gets techniques out there for the whole team. Because honestly I don't really believe that all that many people are truly getting their environments perfectly optimized for themselves. I think that most people in a shop where everyone does their own thing end up with high un-optimized environments. Good environments for all, that everyone can use is better than perfect environments for a few, and mediocre environments for most, plus lack of interoperability.
  - JackMorgan 13y ago
    I could see this for a small team _in the right circumstances_ but for a whole company? That seems difficult if you are larger than 20. Imagine the headache trying to get a tool approved for even a 100 person office. And who would approve it, the manager? I see the logic that says everyone should use the best, the problem is now you take the power from the individual who best knows his job and give it to some central person who might not understand people's needs as well.
    - aetherson 13y ago
      Pivotal Labs, for example, does it with much larger than 100 person offices. They've got a repository here ( https://github.com/pivotal-sprout/sprout https://github.com/pivotal-sprout/sprout ) with their recipes for setting up their workstations. They have 72 contributors to the repo, so I guess it's not just a centralized manager.
      - JackMorgan 13y ago
        Do they dictate things like emacs settings? I thought sprout was for stuff like ruby version and git configs.

wting 13y ago

Do you share workstations with your co-workers or do significant amounts of pair programming? I'm not sure why my work environment should be optimized for a <1% use case.

aetherson 13y ago
I do significant amounts of pair programming. But even more so, I don't think that your coworkers using your workstation should be a <1% use case even if you never pair. My contention is that: 1. Work environments -- including ones that don't formally pair -- should be highly collaborative. 2. It's typically massively less efficient to help someone past a block or communicate a new coding technique via telling them what to do rather than doing it. Much less anything even remotely iterative, where you need to, say, write some code, look at some output, and write some more code. 3. The difference between "a basically good development environment" and "a development environment that is specifically optimized for just specifically you" is actually quite small. There's no real need to sacrifice much of anything in order to get an environment optimized specifically for you.

wting 13y ago

Do you share workstations with your co-workers or do significant amounts of pair programming? I'm not sure why my work environment should be optimized for a <1% use case.

JackMorgan 13y ago

If you pair a majority of the time, sure, make a standardized workstation with your team. My team uses viemu in VS, which the rest of our office detests, but hey, we are the ones pairing 99% of the time. When I am not pairing for the majority, I setup my machine to my tastes, and simply install a "default" editor for the few times someone else actually needs to type on my machine. Emacs and IDEA both have good ways to revert everything to defaults temporarily. I do not believe, however, that a perfectly customized setup has only small gains. For example, consider two tools that I have never seen as defaults in any editor or IDE: rainbow parens/brackets and paredit mode. Rainbow parens just highlights pairs: http://stevelosh.com/media/images/blog/2010/09/rainbow.png http://stevelosh.com/media/images/blog/2010/09/rainbow.png And here is a short minute paredit mode explanation: http://www.youtube.com/watch?v=D6h5dFyyUX0 http://www.youtube.com/watch?v=D6h5dFyyUX0 When actually editing code, those two tools save me several hundred keystrokes an hour. And those are just the first two tools I thought to use as an example out of the entire toolbox that is emacs. If I was to now give up just those two tools, I would be sentencing myself to the mental equivalent of tying five pound weights to my legs for the marathon that is the rest of my programming career. Why would I intentionally require myself to type more keys per hour to do the same editing, rather than just learning a faster way to edit? This is, obviously, also my argument for learning the vim editing system (which I also use in emacs).

aetherson 13y ago
I'm not advocating accepting an editor or IDE default, I'm advocating a standardized environment for a company. If rainbow parens are super-useful, then they can be super-useful for everybody. And that's another thing that a standardized environment does: it gets techniques out there for the whole team. Because honestly I don't really believe that all that many people are truly getting their environments perfectly optimized for themselves. I think that most people in a shop where everyone does their own thing end up with high un-optimized environments. Good environments for all, that everyone can use is better than perfect environments for a few, and mediocre environments for most, plus lack of interoperability.
- JackMorgan 13y ago
  I could see this for a small team _in the right circumstances_ but for a whole company? That seems difficult if you are larger than 20. Imagine the headache trying to get a tool approved for even a 100 person office. And who would approve it, the manager? I see the logic that says everyone should use the best, the problem is now you take the power from the individual who best knows his job and give it to some central person who might not understand people's needs as well.
  - aetherson 13y ago
    Pivotal Labs, for example, does it with much larger than 100 person offices. They've got a repository here ( https://github.com/pivotal-sprout/sprout https://github.com/pivotal-sprout/sprout ) with their recipes for setting up their workstations. They have 72 contributors to the repo, so I guess it's not just a centralized manager.
    - JackMorgan 13y ago
      Do they dictate things like emacs settings? I thought sprout was for stuff like ruby version and git configs.