3 ms·

I had a similar experience with MSFT docs when working at Sun. The docs were not very good, and though they seemed somewhat redacted, it felt like in fact thei

I had a similar experience with MSFT docs when working at Sun. The docs were not very good, and though they seemed somewhat redacted, it felt like in fact their internal docs probably weren't much better.

m463 3y ago
Don't tall into that trap of thinking. Many years ago I knew an ex-microsoft engineer. Microsoft had poor interoperability with something, and I speculated that engineers in microsoft didn't know what 3rd parties were doing and accidentally broke things. He told me, "don't be naive - microsoft would have meetings saying 'how can we own this?'"
- throwaway-blaze 3y ago
  Not to cast doubt on your friend's story, I worked on both the SQL Server team and later on the Windows kernel team in the early 2000s (the bad years). I came from "outside" meaning I had already had a career at non-Microsoft-related companies (mostly startups using linux on the server). I was continually shocked at how _little_ the MSFT employees seemed to know about the industry, or how their customers used their own products. As an example, this was the era of the J2EE App Server. Almost none of the people I worked with knew what an App Server was, despite the #1 database in use by App Server customers being MSFT SQL Server.
  - m463 3y ago
    This was before that, early to mid 90's era
  - astrange 3y ago
    I still don't know what an app server is. Isn't that one of those things from the enterprise programming era where they'd get "architects" to design an "enterprise system" and it would come with twenty different things with names like "message bus" and "dependency injection" that no program in history has ever actually needed?
    - BlackFly 3y ago
      In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now. The two most common in my career were JBoss and Tomcat. Since Java packaged applications into Jars which could be run anywhere (up to environmental assumptions made by developers), you could simply scale up by sending these jars to the app servers to run. Actually, the Alibaba group was quite annoyed in the JCP that western members had given up on these aspects of the Java platform and were moving to support containerization. Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such. App servers standardize what it means to start an application which makes operating many applications much easier. Message buses were generally in memory or in process streaming brokers. Most of these have moved externally today via Kafka, RabbitMQ or cloud proprietary versions like SQS. Some people may lean on ZeroMQ to build similar behaviors when doing multiprocessing and some people may even do it in process if they like the api. Definitely very much part of large scale application development today although the terms of art have changed. Dependency injection is just a fancy name for polymorphism via fields in your struct, although if you have too much exposure to spring you will associate it with that plus an inversion of control on the actual injection part: that is, you will associate it with heavy use of annotations. If you have polymorphism with a switch (or chained ifs) on a parameter, you don't have dependency injection but if you have polymorphism by having different inplementations of a field of your struct then you are doing dependency injection. Very much part of good software design today, the annotation driven wiring possibly not so common outside of Java + Spring.
      - cryptonector 3y ago
        I think of dependency injection as a generalization of LD_PRELOAD, the point being that the "injection" is done via configuration that is external to the application's code.
        BlackFly 3y ago
        That's a good take, I hadn't really thought of that one before and I had certainly used LD_PRELOAD or some incarnation thereof (forgive my memory is was more than a decade ago) to swap out different implementations of the same API.
  - cryptonector 3y ago
    During the Ballmer era MSFT was famous for the lack of cooperation between and within teams. That's what you get when you use stack ranking to decide compensation.
- thaumasiotes 3y ago
  Microsoft's documentation for Microsoft's own technologies (as in, the C# libraries they provide) is terrible. What's the competitive advantage there?
  - tety 3y ago
    That is not true in my experience, Windows API is superbly documented and C# docs are of far higher quality than Java's
  - mafuy 3y ago
    The C# documentation was, at least in its initial years, very good. It even had working examples that demonstrated functions. Compare that to typical javadoc of its time.
    - matwood 3y ago
      MS documentation used to be amazing back when I programmed for Windows. It was one of the hardest parts of moving to Java for me.

m463 3y ago

Don't tall into that trap of thinking. Many years ago I knew an ex-microsoft engineer. Microsoft had poor interoperability with something, and I speculated that engineers in microsoft didn't know what 3rd parties were doing and accidentally broke things. He told me, "don't be naive - microsoft would have meetings saying 'how can we own this?'"

throwaway-blaze 3y ago
Not to cast doubt on your friend's story, I worked on both the SQL Server team and later on the Windows kernel team in the early 2000s (the bad years). I came from "outside" meaning I had already had a career at non-Microsoft-related companies (mostly startups using linux on the server). I was continually shocked at how _little_ the MSFT employees seemed to know about the industry, or how their customers used their own products. As an example, this was the era of the J2EE App Server. Almost none of the people I worked with knew what an App Server was, despite the #1 database in use by App Server customers being MSFT SQL Server.
- m463 3y ago
  This was before that, early to mid 90's era
- astrange 3y ago
  I still don't know what an app server is. Isn't that one of those things from the enterprise programming era where they'd get "architects" to design an "enterprise system" and it would come with twenty different things with names like "message bus" and "dependency injection" that no program in history has ever actually needed?
  - BlackFly 3y ago
    In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now. The two most common in my career were JBoss and Tomcat. Since Java packaged applications into Jars which could be run anywhere (up to environmental assumptions made by developers), you could simply scale up by sending these jars to the app servers to run. Actually, the Alibaba group was quite annoyed in the JCP that western members had given up on these aspects of the Java platform and were moving to support containerization. Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such. App servers standardize what it means to start an application which makes operating many applications much easier. Message buses were generally in memory or in process streaming brokers. Most of these have moved externally today via Kafka, RabbitMQ or cloud proprietary versions like SQS. Some people may lean on ZeroMQ to build similar behaviors when doing multiprocessing and some people may even do it in process if they like the api. Definitely very much part of large scale application development today although the terms of art have changed. Dependency injection is just a fancy name for polymorphism via fields in your struct, although if you have too much exposure to spring you will associate it with that plus an inversion of control on the actual injection part: that is, you will associate it with heavy use of annotations. If you have polymorphism with a switch (or chained ifs) on a parameter, you don't have dependency injection but if you have polymorphism by having different inplementations of a field of your struct then you are doing dependency injection. Very much part of good software design today, the annotation driven wiring possibly not so common outside of Java + Spring.
    - cryptonector 3y ago
      I think of dependency injection as a generalization of LD_PRELOAD, the point being that the "injection" is done via configuration that is external to the application's code.
      - BlackFly 3y ago
        That's a good take, I hadn't really thought of that one before and I had certainly used LD_PRELOAD or some incarnation thereof (forgive my memory is was more than a decade ago) to swap out different implementations of the same API.
- cryptonector 3y ago
  During the Ballmer era MSFT was famous for the lack of cooperation between and within teams. That's what you get when you use stack ranking to decide compensation.
thaumasiotes 3y ago
Microsoft's documentation for Microsoft's own technologies (as in, the C# libraries they provide) is terrible. What's the competitive advantage there?
- tety 3y ago
  That is not true in my experience, Windows API is superbly documented and C# docs are of far higher quality than Java's
- mafuy 3y ago
  The C# documentation was, at least in its initial years, very good. It even had working examples that demonstrated functions. Compare that to typical javadoc of its time.
  - matwood 3y ago
    MS documentation used to be amazing back when I programmed for Windows. It was one of the hardest parts of moving to Java for me.