elementalest
Joined 12 years ago
Joined 12 years ago
If cheap labour is no longer possible/desirable, then near fully autonomous factories driven by next-gen AI and robotics becomes significantly more viable.
> RSEs should not be writing code for students doing PhD level projects in my opinion
So should a mechanical engineer PhD be designing and making all their own robot parts? Or should the shop engineer help them? The few mechanical engineer PhD's in robotics I know made a few early prototype test parts themselves with help from the shop engineer, but the shop engineer made and even helped design most of it, especially the final prototype.
> As you say, this is a great idea in principle. In reality I think that it's really difficult to make it work.
The point I'm making is that it does work and its proven to work very well (which is why the major industry labs do it). In my experience its Academia that doesn't like it. Anything which appears to take power/freedom away from scientists and gets in the road of their research is rejected. Though I think the core reason is (as other comments have mentioned), there is no incentive for Academia to make it work. The funny thing is that having a RSE working with them would actually help the scientists in the long run and allow them to focus more on the research because they wouldn't have to do everything themselves.
The scientist just wants to focus on their research and once they have a barely working proof of concept, hand it over to the engineer to figure the rest out. The engineer wants a well specified design and prototype that they can lightly refactor to clean up, scale up and turn into a product/tool.
The reality is that approach makes it way harder for both, though most often harder for the engineer as they are generally at the end of the chain in Academia and have little power. For example, the code or spec from the scientist is often terrible, so the engineer needs to start from scratch and keep going back to the scientist to spec out the design as they were not involved at any stage prior. They may even find edge cases or flaws the scientist had not considered that are fundamentally problematic to turning it into a viable product/tool.
This is why the big corporate/industry research labs often have high level RSE that are involved in the research process and get their names in papers (they sometimes have PhD's themselves). They are not optimising for the scientists time, but for the companies resources
So yes, it really is that simple and completely obvious.
[1] https://www.gunpolicy.org/firearms/compareyears/10/rate_of_a...
That linked source is for all massacres, most of which are not gun related and have < 6 deaths. Even if you include the 2002 Monash University shootings, its still 20 years.
If you look at [1], when the Australian gun laws came into effect, a year later the per capita number of gun related deaths halved. 25 years later and its halved again and the trend continues downwards. For reference the US numbers are here [2]. What is interesting is that when comparing the number of firearm possession per capita between the US and Australia, the US has roughly 10 times more guns [3]. Based on [1] and [2] the US has roughly 10 times the number of gun related deaths per capita. The reason why Australia has historically had less problems than the US with gun violence is that even at Australia's peak, it had 5 times fewer guns [4] than the US [5] did per capita.
[1] https://www.gunpolicy.org/firearms/compareyears/10/rate_of_a...
[2] https://www.gunpolicy.org/firearms/compareyears/194/rate_of_...
[3] https://www.gunpolicy.org/firearms/compare/10/rate_of_civili...
[4] https://www.gunpolicy.org/firearms/compareyears/10/rate_of_c...
[5] https://www.gunpolicy.org/firearms/compareyears/194/rate_of_...
By focusing on an encoder (at least initially) you can just support a subset of features that work well for you. Then focus on making a decoder that can at least play back videos from your encoder.
More people will find it useful to have an encoder that works all the time, rather than a decoder that only works on a subset of videos.
> We don't go about individually discovering why modular design is a good thing, or why at certain scales microservices are a better option. We do the research, talk to others, and figure out that the general consensus is a reasonable one that we can use.
> I think we need to do a better job at explaining why something is a bad idea to junior developers. Learn to see things from their perspective, and communicate in a way that relates to their experience rather than ours.
Not everyone learns the same. Some people may learn significantly faster and/or more effectively if they are allowed to make mistakes - to see/experience the difference. I think this a good approach for simple problems. However, if the problem is highly complex and time consuming, its not as practical as the time cost to redo, as the work is too high. Thats where you do the research and reading. It requires a balance.
I do agree with the rest of your comment though.