You mention choosing between "growth" and "kicking back" - that seems to me to be the key question you need to answer. Do you want to be stretched, or take some less stressful "passive work"? Neither answer is bad, and only you can choose.
Once you know the answer to that, my "3 classes of managers" might help you pick a next step.
Good: These managers actively support you. They know how to play whatever games your company has evolved, will support you through tough times, and create growth opportunities that advance your goals (and theirs).
Useless but harmless: These managers are not actively "good", but they won't stop you serving yourself. You'll need to take matters into your own hands, but when you do, they'll support you. They normally know how to play the company games, and are sometimes "good" managers that have burned out or stretched themselves further than they have capacity for. Finding good mentors can help you leverage "Useless but harmless".
Useless and harmful: These managers aren't helping you, but then actively hinder your attempts to help yourself. They'll block your attempts to achieve things - even if they're good for the team. When you go to them for support that only they can provide (e.g. performance reviews), they won't really listen to your feedback.
Sounds like you're somewhere between "Harmless" and "Harmful", and you need to work out which one your situation is closer to. If you've got a "Useless but harmless", then you're fine. Work with them to generate the outcomes you want, trusting that - in general - they'll support you in "self-management". If they're not helping you and preventing you from helping yourself, then - despite being "nice" - they're probably harmful to your own goals (project and personal), and you _might_ want to consider other options.
A fair sized pause, sure. But if the argument is “Don’t throw it up unedited”, and what it provides me is bare bones generic/junior stuff, I’m not sure of the huge win at this point in time. The world wasn’t short of “Generic low grade copy” templates before LLMs. It just saves a few steps in the copy/paste.
I'm not an AI skeptic (this stuff will change the world), but I'm not as impressed as the author.
The primary problem, which seems common to LLMs asked to do this stuff, is "very high level output" - a content smoothie, with few features that are particularly specific to the prompt. The marketing campaign in the OP is so generic, you can `s/Saturn Parable/Any other educational product` and it's still "fine". Similarly the emails - there are 1 to 2 sentences that are product specific, and a bunch of fluff. If I paid a marketing agency for this, I'd be very disappointed.
The LLM isn't demonstrating much more than "Generic templating ability over a large range of templates" in this instance. Whilst that's probably 50% of the jobs in the world, such jobs were already at risk of someone searching for "Basic X template" and expanding the placeholders themselves. I think I could do a similar job in 30 minutes by doing exactly that.
LLM's main wins seem to be providing a single unified entry point to all the templates in the universe. It's a "Universal UI", rather than a "Content creator". I guess I shouldn't discount the value of such a thing, once we get the "Sometimes it just lies" problem under control.
The most interesting immediate thing here is the image generation - that's pretty good, and a big saving over scraping through stock images. I suspect the demise of stock image providers to be the first palpable win for generative AIs, if the copyright question doesn't bog this whole field down.
The Monty Hall problem continued to short circuit the “intuitive reasoning” part of my maths brain until I saw it explained as “Imagine there are a million goats and one car. You pick a door, Monty opens 999,998 doors. Should you switch?”, to which the answer is clearly “Of course” (you had a one in a million chance the first time). Then reduce from there.
This is a nice micro-tutorial, but it does not build you a production ready system. You don't seem to get backups, redundancy, automated updates, replicability, or anything else that most people would view as mandatory. It seems just show how to rapidly setup a one-off pet server?
You almost certainly don't need containers. Just use a PAAS (platform as a service). Heroku is the "go to" default, and will be worth much more than they charge. If you're worried about scaling, I've run off the shelve PAAS providers past 5000+ TPS without any issues.
If for some reason you can't use Heroku, you could try a hosted Cloudfoundry (https://run.pivotal.io). If you want something that hybridises PAAS-like behaviour with the big IAAS services, Amazon's Elastic Beanstalk isn't entirely awful. All these setups largely honour the PAAS haiku of "Here is my source code / Run it on the cloud for me / I do not care how" (https://twitter.com/sramji/status/599255828772716544?lang=en).
Don't waste your time on getting container orchestration going, or even containerising your app yet. For internal, low scaling, app-focused scenarios, you'd be mad to go down this road _unless_ your code has been broken into many discrete deployable artefacts _and_ you need to run them all on the same machine (either locally or in production).
You have an app. You want to run it. PAASes do _exactly_ this.
Edit: I see you're worried about costs. PAAS are pricier than the equivalent AWS instance when you consider raw compute, sure. However, factor in your time in creating the same level of redundancy, deployability and monitoring, I'd be shocked if Heroku wasn't an order of magnitude cheaper. Note that PWS Cloudfoundry will host you any 12 factor app for $21.60/GbRAM/month with no bandwidth limit you'll ever hit.
Is there any advantage in seeking visas for less trafficked parts of the US tech scene (e.g. not just SF, Seattle, etc)? Or is the location of the employer entirely divorced from the success rate?
Flyby comment: As someone who straddled academia and industry (but mostly research; never lectured), you have a unique advantage you should utilise: You've done both.
First, most of your students are not going to be academics. They're going into industry. Second, most academics don't have industry experience. They can't link, with the passion of personal stories, the knowledge in the lectures to the work their students will actually be doing.
You can. Use this; liven up the drier parts of the course with war stories. Give concrete context to the abstract. Give them the experience that only a teacher who's been in the trenches can offer.
Well sure. If you basically redefine Malware to be "Anything other than GPL software", then you're going to consider most software malware. That doesn't mean it's the definition of Malware that most (i.e. all) other people will use, and it doesn't really advance the discussion. It mostly continues to make GNU look like fringe lunatics.
Moreover, whilst I don't really object to hyperbole in pursuit of a crusade, I don't greatly appreciate this type of cross-talk. It's hard enough to keep family members free of actual malware without confusing them with comments like "iOS itself is malware".
Clarification: 18 containerised services can absolutely be the right choice. It’s just my experience says the trade off between the costs of maintaining that versus a smaller PAASed system rarely come out in favour of it.
I'll stand by my assertion that for 99% of users (maybe even 99.99%), Kubernetes offers entirely the wrong abstraction. They don't want to run a container, they want to run an application (Node, Go, Ruby, Python, Java, whatever). The prevailing mythology is you should "containerize" everything and give it to a container orchestrator to run, but why? They had one problem, "Run an app". Now they have two, "Run a container that runs an app" and "maintain a container". Just give the app to a PAAS, and go home early.
Most startups - most large companies - would be far better served with a real PAAS, rather than container orchestration. My encounters with container orchestrators is that ops teams spent inordinate amounts of time trying to bend them into a PAAS, rather than just starting with one. This is why I don't understand why this article lumps, e.g. Cloud Foundry in with K8S - they solve entirely different problems. My advice to almost every startup I speak to is "Just use Heroku; solve your business problems first".
The article also mentions it enables "new set of distributed primitives and runtime for creating distributed systems that spread across multiple processes and nodes". I'll throw out my other assertion, which I always though was axiomatic - you want your system to be the least distributed you can make it at all times. Distributed systems are harder to reason about, harder to write, and harder to maintain. They fail in strange ways, and are so hard to get right, I'd bet I can find a hidden problem in yours within an hour of starting code review. Most teams running a non-trivial distributed system are coasting on luck rather than skill. This is not a reflection on them - just an inherent problem with building distributed logic.
Computers are fast, and you are not Google. I've helped run multiple thousand TPS using Cloudfoundry, driving one of Europe's biggest retailers using just a few services. I'm now helping a startup unpick it's 18 "service" containerised system back to something that can actually be maintained.
TLDR; containers as production app deployment artefacts have, in the medium and long term, caused more problems than they've solved for almost every case I've seen.
No, I don't regret it. We picked it for our startup as we wanted a cross platform solution, that genuinely felt native (without the huge effort it takes to make a webapp feel that smooth), and that still gave us a chance to easily native code for certain features. Big wins:
- With a little effort, it genuinely feels native.
- The talent pool is much larger. We didn't hire React Native folk, just good JS people who picked it up quickly.
- Blending native code with JavaScript is easy.
- There are methods to perform app updates without going through the app store release processes of either platform (and waiting for end users to actually download the update).
- It moves quickly, so bugs are squashed pretty quickly, and features arrive at a fast clip.
There have been challenges:
- It moves quickly. Backwards compatibility is doesn't seem to be high on the maintainers priority list, so almost every update will break _something_. We instituted policies of never falling far behind the public release (to avoid needing huge changes at once), and using very few external components (which are often not kept up-to-date with RN).
- If your use cases are outside of the maintainers, there will be problems. The release process seems to be "Does it work for the contributors projects? Ship it". Things like Pod based builds broke for months because they just weren't tested.
- The JavaScript ecosystem is still insane. Our project has ended up with one of the most complex build processes I've worked with (and I've worked with autotools).
My key advice would be:
- Stick with their release cycle, and follow their processes. Don't colour outside the lines, or you will have pain.
- Don't include third party modules unless you have _no other choice_.
- Test on both iOS and Android regularly (i.e. continuously). Things that work well on one platform may be broken on the other.
Based on our outcomes, present me would happily tell past me I'm making a good call, as I'm confident we'd otherwise never have shipped two native-feel applications with 5 developers.
It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there.
With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see myself as happy to provide. Much as it was in the "Millennium bug" area, a lot of the effort in getting the business is PR spadework, but I've got 15-20 years of prep time to position myself suitably. I also hope to provide a slightly more useful service than many Millennium consultancies did at the time.
This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.
It seems to really hate profanity. `I love it` is 1% toxic. `I bloody love it.` 38%; `I fking love it` 95%. In many circles, the more profane are more congratulatory.
Once you know the answer to that, my "3 classes of managers" might help you pick a next step.
Good: These managers actively support you. They know how to play whatever games your company has evolved, will support you through tough times, and create growth opportunities that advance your goals (and theirs).
Useless but harmless: These managers are not actively "good", but they won't stop you serving yourself. You'll need to take matters into your own hands, but when you do, they'll support you. They normally know how to play the company games, and are sometimes "good" managers that have burned out or stretched themselves further than they have capacity for. Finding good mentors can help you leverage "Useless but harmless".
Useless and harmful: These managers aren't helping you, but then actively hinder your attempts to help yourself. They'll block your attempts to achieve things - even if they're good for the team. When you go to them for support that only they can provide (e.g. performance reviews), they won't really listen to your feedback.
Sounds like you're somewhere between "Harmless" and "Harmful", and you need to work out which one your situation is closer to. If you've got a "Useless but harmless", then you're fine. Work with them to generate the outcomes you want, trusting that - in general - they'll support you in "self-management". If they're not helping you and preventing you from helping yourself, then - despite being "nice" - they're probably harmful to your own goals (project and personal), and you _might_ want to consider other options.