6 ms·

>. A big thing about the transition to tech is that you possibly start communicating with people who don’t really know what a vector space is. Be ready to have

>. A big thing about the transition to tech is that you possibly start communicating with people who don’t really know what a vector space is. Be ready to have those conversations. Honestly ask yourself if you’re OK with having those conversations. This is so snobbish. What here is even think about ?

pmiller2 10y ago
It's not snobbish at all. The CS/developer version is "someone who doesn't know what static typing is," or, maybe even "someone who doesn't know what computers are and are not capable of."
cottonseed 10y ago
This is the wrong comparison. Read the second footnote. An intern is a developer in training. The post is talking about mathematicians (who spent a decade or more learning a highly technical field) going to work in an environment where, largely, their peers, boss and consumers of their work do not know, have no interest in and and will never learn the most basic concepts of their field.
- pavlov 10y ago
  I suspect the majority of programmers work in that kind of environments...? The startups and Googles of this world are the exception when it comes to employer tech-savviness.
  - Stasis5001 10y ago
    When you get a PhD, you mainly only take classes in your department for the whole time, whereas in undergrad you still have classes in other fields. This usually extends beyond coworkers into friend circles too. This isn't math specific, but more generally to grad school. Second, programmers at companies almost never work in isolation from other programmers, and in most open office environments are close enough they could touch another one from their desk. On the other hand, a startup with five to ten engineers may be hiring you as their first data scientist, and bigger companies may be putting you on an embedded team, with the nearest data scientist a hallway or floor away. And this isn't a big deal in terms of teamwork, but most data scientists don't have a PhD in mathematics, so if you find higher level mathematical ideas and notation to be the most efficient way for you to think about a problem, your colleagues may not. That's also not a math specific thing though -- an economist, statistician, mathematician, computer scientist, physicist, etc. are all going to have slightly different ways they think about things internally.
  - cottonseed 10y ago
    The advice is for mathematicians who largely don't.
madenine 10y ago
The accompanying footnote helps. His audience is academics - who up until this point have been mostly in and around other mathematicians. Its important to ask yourself, "are you OK with having to sell/explain your work to people who aren't versed in even the basics of what you do?" Obviously that isn't all data science jobs, but in my experience most of my colleagues have to evangelize their work within their organization to some level.
wwweston 10y ago
With just about any kind of speciality, you spend time developing your specialized knowledge and you learn to speak the language surrounding it as part of a facility for concisely navigating (hopefully) precisely in (potentially) complex web of ideas. When you interface with non-specialists, you can't rely on the shared specialized vocabulary. This means you have to do a lot of work to distill which insights are key and figure out how to communicate them (along with supporting ideas) to an audience whose highest insight resolution is going to be varying and who may each bring their own language to the table. So on top of building your problem domain model, you're going to have to build a model of how the people you're working with can understand it. And you will have to do this over and over. You can be snobby about that, and say that it's soooo hard being so much smarter in your specialized field than non-specialists are, but you don't have to be snobby to realize that this is a dimension of the work that you might not enjoy or may even not be cut out for. And of course, you don't have to be a mathematician to have experienced this. It's certainly sufficient, but not necessary. If you've been a developer in a company that has non-dev coworkers and you've never hit this turbulent boundary, you've either been remarkably well insulated, or you're so remarkably natural at that kind of job that you definitely should be doing it. :)
deleted 10y ago
[deleted]

pmiller2 10y ago

It's not snobbish at all. The CS/developer version is "someone who doesn't know what static typing is," or, maybe even "someone who doesn't know what computers are and are not capable of."

cottonseed 10y ago

This is the wrong comparison. Read the second footnote. An intern is a developer in training. The post is talking about mathematicians (who spent a decade or more learning a highly technical field) going to work in an environment where, largely, their peers, boss and consumers of their work do not know, have no interest in and and will never learn the most basic concepts of their field.

pavlov 10y ago
I suspect the majority of programmers work in that kind of environments...? The startups and Googles of this world are the exception when it comes to employer tech-savviness.
- Stasis5001 10y ago
  When you get a PhD, you mainly only take classes in your department for the whole time, whereas in undergrad you still have classes in other fields. This usually extends beyond coworkers into friend circles too. This isn't math specific, but more generally to grad school. Second, programmers at companies almost never work in isolation from other programmers, and in most open office environments are close enough they could touch another one from their desk. On the other hand, a startup with five to ten engineers may be hiring you as their first data scientist, and bigger companies may be putting you on an embedded team, with the nearest data scientist a hallway or floor away. And this isn't a big deal in terms of teamwork, but most data scientists don't have a PhD in mathematics, so if you find higher level mathematical ideas and notation to be the most efficient way for you to think about a problem, your colleagues may not. That's also not a math specific thing though -- an economist, statistician, mathematician, computer scientist, physicist, etc. are all going to have slightly different ways they think about things internally.
- cottonseed 10y ago
  The advice is for mathematicians who largely don't.

madenine 10y ago

The accompanying footnote helps. His audience is academics - who up until this point have been mostly in and around other mathematicians. Its important to ask yourself, "are you OK with having to sell/explain your work to people who aren't versed in even the basics of what you do?" Obviously that isn't all data science jobs, but in my experience most of my colleagues have to evangelize their work within their organization to some level.

wwweston 10y ago

With just about any kind of speciality, you spend time developing your specialized knowledge and you learn to speak the language surrounding it as part of a facility for concisely navigating (hopefully) precisely in (potentially) complex web of ideas. When you interface with non-specialists, you can't rely on the shared specialized vocabulary. This means you have to do a lot of work to distill which insights are key and figure out how to communicate them (along with supporting ideas) to an audience whose highest insight resolution is going to be varying and who may each bring their own language to the table. So on top of building your problem domain model, you're going to have to build a model of how the people you're working with can understand it. And you will have to do this over and over. You can be snobby about that, and say that it's soooo hard being so much smarter in your specialized field than non-specialists are, but you don't have to be snobby to realize that this is a dimension of the work that you might not enjoy or may even not be cut out for. And of course, you don't have to be a mathematician to have experienced this. It's certainly sufficient, but not necessary. If you've been a developer in a company that has non-dev coworkers and you've never hit this turbulent boundary, you've either been remarkably well insulated, or you're so remarkably natural at that kind of job that you definitely should be doing it. :)

deleted 10y ago

[deleted]