6 ms·

You underestimate the value of uniformity and group pressure. Everyone gets used to the one environment in the end. How did you pick up a programming language a

You underestimate the value of uniformity and group pressure. Everyone gets used to the one environment in the end. How did you pick up a programming language and editor in the first place? How did you pick up a new one? It was fine. If people are using different environments, people are still able to wank and bicker over differences in environment. By the way, it’s not just about code style and editor. By sharing the same environment, people can share build tools and other tools much more easily.

dbdjfjrjvebd 8y ago
Or they just leave.
ken 8y ago
> If people are using different environments, people are still able to wank and bicker over differences in environment. How far would you take it? Would you (like Steve Jobs) try to get everyone to dress the same, too?
- 0db532a0 8y ago
  There’s a reason behind uniform in many institutions.
  - ken 8y ago
    Interesting use of the passive voice! Yes, there is. Also common in places with uniforms: requirements for haircuts, nails, makeup/perfumes, daily inspections, etc. You didn't answer my question. As Wikipedia says: "Modern uniforms are most often worn by armed forces and paramilitary organizations such as police, emergency services, security guards, in some workplaces and schools and by inmates in prisons." One of these things is not like the others. Is running your professional software team like a paramilitary group or prison the only way you can get them to stop "bickering"? For people who are immature enough to bicker about any difference between individuals, when you enforce the standardization of one attribute, they just switch to something else.
    - 0db532a0 8y ago
      Wikipedia does not say that the above is an example of the passive voice. Passive voice requires past participle. "is" above is present continuous anyway. I don't think that running a software team like a paramilitary group is the only way to stop bickering, but some elements of how paramilitary groups are managed are very attractive in this context, and seem to have worked where I saw them applied. The employees of a lot of banks happen to wear suits, shirts and trousers, programmers included. I wouldn't discount the benefit of this purely because paramilitary organisations also happen to enforce a uniform.
    - naniwaduni 8y ago
      > Interesting use of the passive voice! http://www.lel.ed.ac.uk/~gpullum/passive_loathing.pdf http://www.lel.ed.ac.uk/~gpullum/passive_loathing.pdf esp 3 (25)
taeric 8y ago
You grossly underestimate our industry's ability to wank and bicker over everything anyway. You also overvalue uniformity. Or under value the antifragility of not caring how the code was created. The most fragile systems I have ever had the displeasure of being near, required a very specific build machine because the environment couldn't be replicated. In large, because the original development team did what you propose, and mandated all development happen using the same controlled environment.
- seabird 8y ago
  Hyper-standardized, pants-shittingly brittle build environments stemming from the mentality that the OP is suggesting is its own special sort of hell. It's "works on my machine" applied to a way bigger surface. Yes, a team obviously has to agree on obvious things such as language and build system. However, cornering yourself into such a tight environment leaves a lot of opportunities to have the rug get pulled out from under you. I currently work on a team that writes DAQ software in C++ for Windows. The developer has their choice in everything (editor, VCS front-end, debugging and profiling, etc.) as long as the build system runs, their code meets the team's code standards, and they're productive with it. We've found that we can basically close our eyes, point at a random target system, and odds are that our code base can be trivially ported to that target with minimal effort. That reality is possible because somebody has incidentally tested just about everything. At one point in the past, we had a pretty narrow/rigid build process, and it bit us in the ass and hamstrung more developers than it was worth.
  - 0db532a0 8y ago
    How did it bite you in the ass out of honest interest? I have not done commercial C++, so I would be interested to know.
    - seabird 8y ago
      We were hit with the reality that the software (and/or components of it) may need to be run on Linux, OSX, and other targets at some point in the near future. At the time, everything was done with a single IDE, a single compiler, with specific old versions of libraries, only targeting Windows, and with no expectation that it would ever have to be done any other way, even though we probably should have assumed that the day would come. It was always assumed that it would just work, but life comes at you fast when you actually have to do it. After weaning the project off of environment specific tools, the process has become a lot more like our initial assumption. C/C++ are unique in that build processes and integrating other people's code in them are inordinately hard problems in and of themselves. Different compilers will behave a little differently, different operating systems will behave a little differently, and some of the niceties that a certain IDE or tool provide you will behave a little differently, depending on the exact circumstances you're dealing with. The safe thing to do is make no environment assumptions, and try to make everything as portable between environments as possible. You need to have your focuses, but it's reassuring to know that you can jump ship if and when you need to.
the8472 8y ago
I never understand how people can even argue that uniform style is necessary, you have to dig into 3rd party code with different styles every day anyway. And imo autoformatters are too inflexible. Most default rules are ok when you don't make any effort about formatting at all but break down when you manually lay out things for improved readibility. E.g. when splitting arguments to one arg per line and parens on separate lines and the autoformatter will just go and squash them all together into single lines up to the line limit, except the lambda in the middle which will be broken out into a separate line. Or other fun things like that. Formatters which rearrange code by alphabetical sorting or sorting by visibility are even worse. They can introduce so much commit noise just because you change an identifier.
- 0db532a0 8y ago
  git diff -C can show rearrangements and renames.
  - the8472 8y ago
    it still pollutes the git blame, doesn't help with web views of code repos and causes more merge/rebase conflicts. the sorting causes more problems than its very questionable worth.
    - 0db532a0 8y ago
      Setting the git diff algorithm to patience or histogram would probably solve a lot of the merge issues. You’re right on the web views. It would be nice if they respected the algorithm setting from the git config.
      - the8472 8y ago
        In my experience the diff algorithms do nothing when one person moves the function and another edits it. The algos just fiddle around the margins of diff hunks.
RussianCow 8y ago
> You underestimate the value of uniformity and group pressure. I don't, because I've worked in both kinds of environments and have not seen any benefits to the system you propose. Uniform development machines doesn't automatically mean that you've solved all consistency problems. Also, I'm not sure what you mean by "build tools" specifically, but any software needed for a project to run should ideally live within a Vagrant VM (or Docker or whatever), so it should be self-contained and not require any installation of additional software. > How did you pick up a programming language and editor in the first place? How did you pick up a new one? It was fine. IME, it takes several months to really become fluent and productive in a new editor, and potentially longer for a new language (depending on previous experience, etc). So "it's fine" as long as you consider a multi-month learning curve "fine".
- z3t4 8y ago
  > IME, it takes several months to really become fluent and productive in a new editor I'm interested to know what editors you have switched to/from and why. Example, switched from emacs to vi because manager forced us to, etc.
  - RussianCow 8y ago
    I've tried many editors for various reasons, although I've never been forced to learn a new one for work. (The time I worked at a place where everyone used the same editor, it happened to be IntelliJ, with which I was already familiar.) The most difficult was when I switched to Vim fulltime to learn it. It took me about a year to really "grok" it and become productive. I've also done the same with Atom and VS Code, but those never felt as productive for me, so I gave up a month or two in. I keep coming back to IntelliJ, which is what I use now, because it fits so well with the way I work and I'm most productive with it.
- 0db532a0 8y ago
  Docker, Vagrant, build tools are all the same. They should just be uniform. Don't hire someone unexperienced in the uniform language. After that, one-time investment in assimilation to the uniform environment. That versus never-ending loss.

dbdjfjrjvebd 8y ago

Or they just leave.

ken 8y ago

> If people are using different environments, people are still able to wank and bicker over differences in environment. How far would you take it? Would you (like Steve Jobs) try to get everyone to dress the same, too?

0db532a0 8y ago
There’s a reason behind uniform in many institutions.
- ken 8y ago
  Interesting use of the passive voice! Yes, there is. Also common in places with uniforms: requirements for haircuts, nails, makeup/perfumes, daily inspections, etc. You didn't answer my question. As Wikipedia says: "Modern uniforms are most often worn by armed forces and paramilitary organizations such as police, emergency services, security guards, in some workplaces and schools and by inmates in prisons." One of these things is not like the others. Is running your professional software team like a paramilitary group or prison the only way you can get them to stop "bickering"? For people who are immature enough to bicker about any difference between individuals, when you enforce the standardization of one attribute, they just switch to something else.
  - 0db532a0 8y ago
    Wikipedia does not say that the above is an example of the passive voice. Passive voice requires past participle. "is" above is present continuous anyway. I don't think that running a software team like a paramilitary group is the only way to stop bickering, but some elements of how paramilitary groups are managed are very attractive in this context, and seem to have worked where I saw them applied. The employees of a lot of banks happen to wear suits, shirts and trousers, programmers included. I wouldn't discount the benefit of this purely because paramilitary organisations also happen to enforce a uniform.
  - naniwaduni 8y ago
    > Interesting use of the passive voice! http://www.lel.ed.ac.uk/~gpullum/passive_loathing.pdf http://www.lel.ed.ac.uk/~gpullum/passive_loathing.pdf esp 3 (25)

taeric 8y ago

You grossly underestimate our industry's ability to wank and bicker over everything anyway. You also overvalue uniformity. Or under value the antifragility of not caring how the code was created. The most fragile systems I have ever had the displeasure of being near, required a very specific build machine because the environment couldn't be replicated. In large, because the original development team did what you propose, and mandated all development happen using the same controlled environment.

seabird 8y ago
Hyper-standardized, pants-shittingly brittle build environments stemming from the mentality that the OP is suggesting is its own special sort of hell. It's "works on my machine" applied to a way bigger surface. Yes, a team obviously has to agree on obvious things such as language and build system. However, cornering yourself into such a tight environment leaves a lot of opportunities to have the rug get pulled out from under you. I currently work on a team that writes DAQ software in C++ for Windows. The developer has their choice in everything (editor, VCS front-end, debugging and profiling, etc.) as long as the build system runs, their code meets the team's code standards, and they're productive with it. We've found that we can basically close our eyes, point at a random target system, and odds are that our code base can be trivially ported to that target with minimal effort. That reality is possible because somebody has incidentally tested just about everything. At one point in the past, we had a pretty narrow/rigid build process, and it bit us in the ass and hamstrung more developers than it was worth.
- 0db532a0 8y ago
  How did it bite you in the ass out of honest interest? I have not done commercial C++, so I would be interested to know.
  - seabird 8y ago
    We were hit with the reality that the software (and/or components of it) may need to be run on Linux, OSX, and other targets at some point in the near future. At the time, everything was done with a single IDE, a single compiler, with specific old versions of libraries, only targeting Windows, and with no expectation that it would ever have to be done any other way, even though we probably should have assumed that the day would come. It was always assumed that it would just work, but life comes at you fast when you actually have to do it. After weaning the project off of environment specific tools, the process has become a lot more like our initial assumption. C/C++ are unique in that build processes and integrating other people's code in them are inordinately hard problems in and of themselves. Different compilers will behave a little differently, different operating systems will behave a little differently, and some of the niceties that a certain IDE or tool provide you will behave a little differently, depending on the exact circumstances you're dealing with. The safe thing to do is make no environment assumptions, and try to make everything as portable between environments as possible. You need to have your focuses, but it's reassuring to know that you can jump ship if and when you need to.

the8472 8y ago

I never understand how people can even argue that uniform style is necessary, you have to dig into 3rd party code with different styles every day anyway. And imo autoformatters are too inflexible. Most default rules are ok when you don't make any effort about formatting at all but break down when you manually lay out things for improved readibility. E.g. when splitting arguments to one arg per line and parens on separate lines and the autoformatter will just go and squash them all together into single lines up to the line limit, except the lambda in the middle which will be broken out into a separate line. Or other fun things like that. Formatters which rearrange code by alphabetical sorting or sorting by visibility are even worse. They can introduce so much commit noise just because you change an identifier.

0db532a0 8y ago
git diff -C can show rearrangements and renames.
- the8472 8y ago
  it still pollutes the git blame, doesn't help with web views of code repos and causes more merge/rebase conflicts. the sorting causes more problems than its very questionable worth.
  - 0db532a0 8y ago
    Setting the git diff algorithm to patience or histogram would probably solve a lot of the merge issues. You’re right on the web views. It would be nice if they respected the algorithm setting from the git config.
    - the8472 8y ago
      In my experience the diff algorithms do nothing when one person moves the function and another edits it. The algos just fiddle around the margins of diff hunks.

RussianCow 8y ago

> You underestimate the value of uniformity and group pressure. I don't, because I've worked in both kinds of environments and have not seen any benefits to the system you propose. Uniform development machines doesn't automatically mean that you've solved all consistency problems. Also, I'm not sure what you mean by "build tools" specifically, but any software needed for a project to run should ideally live within a Vagrant VM (or Docker or whatever), so it should be self-contained and not require any installation of additional software. > How did you pick up a programming language and editor in the first place? How did you pick up a new one? It was fine. IME, it takes several months to really become fluent and productive in a new editor, and potentially longer for a new language (depending on previous experience, etc). So "it's fine" as long as you consider a multi-month learning curve "fine".

z3t4 8y ago
> IME, it takes several months to really become fluent and productive in a new editor I'm interested to know what editors you have switched to/from and why. Example, switched from emacs to vi because manager forced us to, etc.
- RussianCow 8y ago
  I've tried many editors for various reasons, although I've never been forced to learn a new one for work. (The time I worked at a place where everyone used the same editor, it happened to be IntelliJ, with which I was already familiar.) The most difficult was when I switched to Vim fulltime to learn it. It took me about a year to really "grok" it and become productive. I've also done the same with Atom and VS Code, but those never felt as productive for me, so I gave up a month or two in. I keep coming back to IntelliJ, which is what I use now, because it fits so well with the way I work and I'm most productive with it.
0db532a0 8y ago
Docker, Vagrant, build tools are all the same. They should just be uniform. Don't hire someone unexperienced in the uniform language. After that, one-time investment in assimilation to the uniform environment. That versus never-ending loss.