The first is that a technical solution can be trained on _ALL_ medical data and have access to it all in the moment. It is difficult to assume a doctor could also achieve this.

The second is that for medical cases understanding the sum of all symptoms and the patients vitals would lead to an accurate diagnosis a majority of the time. AI/ML is entirely about pattern recognition, when you combine this with point one, you end up with a system that can quickly diagnose a large portion of patients in extremely short timeframes.

On a different note, I think we can leave the ad-hominem attacks at home please.

If you ask it to do something laborious like review a bunch of websites for specific content it will constantly give up, providing you information on how you can continue the process yourself to save time. Its maddening.

With the speed this can generate its solutions, you could have it loop through attempting the solution, feeding itself the output (including any errors found), and going again until it builds the "correct" solution.

Why spend time being good at something you don't care about being good at any more?

It is purely a personality thing however for me I would like to continue moving up the career ladder and you rarely see CTOs, VpEng rolling up their sleeves and sifting through CloudWatch logs. I want my focus to be on working the skills associated with those roles.

As a people manager that works with many incredibly capable engineers that are aspiring to be managers, I share with them this advice, 'excellent engineers compound their value by making other engineers excellent. It's far more difficult to do that when you are writing code.'

These assets are horizontally and vertically scalable based off skills, quality, or performance required. An efficiently designed AI architecture I believe could do the same. Its not mixture-of-experts as you aren't necessarily asking each model simultaneously but designing and/or having the system intelligently decide when it has completed its task and where the output should travel next.

Think of a platform where you had 'visual design' models, 'coding' models, 'requirements' models, 'testing' models, all wired together. The coding models you incorporate are trained specifically for the languages you use, testing the same. All interchangeable / modularized as your business evolves.

You feed in your required outcome at the front of your 'team' and it funnels through each 'member' before being spit out the other end.

I have yet to see anyone openly discussing this architecture pattern so if anyone could point me in that direction I would thoroughly appreciate it.

I was ignorant enough to try and jump straight in to his videos and despite him recommending I watch his preceeding videos I incorrectly assumed I could figure it out as I went. There is verbiage in there that you simply must know to get the most out of it. After giving up, going away and filling in the gaps though some other learnings, I went back and his videos become (understandably) massively more valueable for me.

I would strongly recommend anyone else wanting to learn neural networks that they learn from my mistake.

Perhaps the only benefit would be extra computational power yet I would struggle to understand the benefit of jumping from 500 million to 5 billion with such short timeframes.

When you WFH that changes ('aint nobody watching your screen but you) but the underlying problem still remains. The team are not working towards a clear goal that they understand and want to achieve. When you provide that, the team will always contribute effectively because its interesting and importantly allows them to feel like their work means something.

WFH productivity is not the problem. Managers providing worthy work is.

Working as a IC you often have a backlog of work provided by someone else where it is their job to prioritise and structure that work for you. Moving into a management role it becomes your job to find and prioritise your own tasks.

It is very easy to feel like you aren't contributing or completing productive work as your workload and goals are now completely self defined.

With a larger company you will typically find they have already hired specialists to handle very specific tasks. You can always do some things but more often than not the rigor of corporate structure says "If you need anything done in dev ops, please speak to _Bob_ and he will sort it out".

Jumping from the challenge of constantly adapting to different tasks to being there to only do a single 'role' can be quite jarring.

Code Heroes are a small mobile app company based in Brisbane focusing on mobile application development for medium to large companies. We are currently actively looking for experienced developers that have hands on experience with Flutter (Dart), or those with mobile app development history and a willingness to learn.

The job is full-time and onsite with a 6 hour workday. We are located the CBD of Brisbane.

For further information: https://www.codeheroes.com.au/jobs

That is not to say that finding those experienced in Dart in south east Queensland has been particularly easy!

Our stack: Flutter / Dart, Xamarin / C#, Firebase, JavaScript

Code Heroes are a mobile app company based in Brisbane focusing on mobile application development for medium to large companies. We are currently actively looking for experienced developers that have hands on experience with Flutter (Dart), or those with mobile app development history and a willingness to learn.

Our benefits include a 6-hour work day and for the perfect candidate we can help with you on visa requirements.

The job is full-time and onsite, located in the CBD of Brisbane.

For further information: https://www.codeheroes.com.au/jobs

For me I assign them a fully refined task to create something and go through the full end to end process with them. It will allow them in the future when hitting a road-block at any step of the process to go back to this code, ask themselves "what did I do here which was right" and try to apply it to their current work.

Under the surface I couldn't help but note that the lack of internal advertisement of what would be a very desirable role must have annoyed several other senior members. Additionally, it segregated a team of developers off to work on 'cool' things while the other half is left working on legacy projects.

I would agree with my companies perspective that something like this was necessary however as the author notes, the lack of involvement outside of C-level discussions was quite surprising and is likely going to backfire.

I was fortunate enough to try the v1 of hololens when a Microsoft representative bought it into my work, the tech was amazing but the FOV was far less than I anticipated. From what I can recall it was akin to looking through a tissue-box sized area roughly 1 foot from your face.