I would really love to pick your brains on this. Did you do anything special with Frigate to do the stream processing ( hardware offloading etc? ) or was it simply plug and play.
There exists a plethora of real world coding challenges that are beyond typical boilerplate code that ChatGPT has in my experience been able to produce entirely acceptable working solutions for.
The skill of the engineering manager is indeed finding tasks that continue to be rewarding, challenging, fun as the developer progresses.
> There exists a plethora of real world coding challenges that are beyond typical boilerplate code that ChatGPT has in my experience been able to produce entirely acceptable working solutions for.
I'm delighted to hear that! But that doesn't really counter my argument, which is that if a task can be done by an LLM it wasn't a good fit for a junior anyway. Being able to just fling basic tasks over the wall to GPT is great, and should free up time for non-junior devs -- but since those tasks wouldn't have helped grow the junior devs in the first place it doesn't really affect them or their trajectory. Unless you were just using them to churn through drudgework in the first place, in which case I guess great, you can just purge them from your org at no net loss since they'd have burned out soon enough anyway.
If anything I'd turn the thesis of your title on its head: should engineering leads be worried that AI will take away the last bits of code they should have still been writing?
A master crafts person in any field can not become an expert without years of practice and repetition.
Should we therefore always just outsource tasks because the work could do be done faster? does that mean that the experience of doing something that could be done by someone else is less valuable?
ChatGPT could likely answer every leetcode question going? Does that mean there's zero value in a human attempting to answer these questions?
That's grandstanding and dodging my argument, which is that you shouldn't be giving LLM-suitable tasks to juniors anyway. They should get first pass at the interesting, complex work -- first in digestible bites, then with greater scope and independence as they become less junior. Is years of practice required to achieve non-junior skill? Sure, but years of copy-pasta-ing boilerplate (or otherwise writing gruntwork code that could be generated by GPT) won't count toward that time & experience.
Give your juniors real, interesting work and keep the GPT-level tasks away from them, and they'll actually improve.
> Does that mean there's zero value in a human attempting to answer these questions?
Your hiring process may vary, but mine sure says "yep, zero value in leetcode."
Are you saying that chatgpt wouldn't be able to achieve the digestible bites you're talking of? In which case, at what point do they become digestible? Is that not dependent on the skill of the person doing the digesting? and up to the engineering lead to determine?
I have never once stated that the work the juniors are doing isn't real or interesting, that's an assumption you've made, and I'm trying to state the contrary?
They could easily still use standalone puppet to handle the config management for individual container images. I currently do this with salt-minion. It reduces the burden on the Dockerfile itself, and lets you embrace a declarative configuration state at build time.
It definitely seems like the wrong approach to me to have puppet manage your base images. They're not VM's, they shouldn't have multiple services, they shouldn't require any complex configuration management, they should just be the minimum requirements to support your application's local runtime dependencies, and that's it.
From previous experience migrating from a puppet setup to one that used containers, puppet's vestigial use case ends up being to get the orchestration control plane itself setup (ie. kubernetes, networking configs, etc) and that's about it.
There's nothing inherently about Puppet that means it has to manage multi-service "whole OS"-like installations. It can just as easily be put to the task of a Dockerfile: install dependencies and deployables for a single application. Its robust ability to manage things like user accounts, packages, scheduled jobs (e.g. for alerting, though you would have to install at least a second service for this: _crond) and the like makes it vastly superior to Dockerfile shell scripts for complex tasks.
Think of puppet more like a way of simplifying your Dockerfiles to have fewer crazy shell commands in total, rather than hiding the craziness in layers and hoping it all composes properly. If you do use lots of layers, Puppet can make your life much easier, since it can be better at detecting previous layers' changes and working around them (think redundant package install commands. Even the no-op "already installed!" command takes time; if you're installing hundreds of packages--many people are, for better or worse--that can eat up build time).
Puppet isn't a VM provisioner; it can also be used as a replacement for large parts of your Dockerfile, or a better autoconf to set up the environment/deps for your application to run in.
The point about layer complexity is a great one I didn't even consider. Your "config" step is no longer a mish mash of dozens COPY/RUN/etc directives (resulting in N new intermediate image layers), it just results in a single atomic layer where you run the Puppet bootstrap.
Obviously you could accomplish this with shell scripts as well to constrain your config step into one docker RUN directive, but I prefer the declarative state approach to the imperative one in this case.
1) I think you missed my point entirely here, I probably didn't do a good job of explaining it. I was trying to say that you run Puppet once at build time to bootstrap the configuration for the image, that's it. You could even uninstall it at the last build step if you want to reduce final image size. The primary distinction here is declarative vs imperative configuration management.
2) The one process-per-container dogma isn't necessarily the only way to run a successful docker stack. For example, I don't see anything wrong with using supervisor to manage whatever process you're running in your container.
This introduces a dependency on which pod runs on which host, unless you have puppet write the config for every service to every host.
People tend to use Puppet less to configure their applications as they move into containers, as a configuration change can just be made by rolling out a new image.
Judging from their other infrastructure talks its far more likely they are shipping the application in a container to Apache Aurora, and having the process managed by Mesos.
I can't remember if all their services are now running on Mesos, but I'd bet their newer ones are.
I don't think ones better than the other per say. It's just different.
I've been in meetings in a room full of people knowing that absolutely no one wants to be there, and no one really knows what they're doing there.
I've been online talking one to one with someone and completely not understood what they were talking about.
Both have pros and cons and the appropriate medium can be chosen based on the situation that's needed.
I'd argue it's a very rare event that a lot of people really need to be in a room together to communicate; when they do a lot more pre-room preparation needs happen than I normally see. ;)
You could send emails to FB users directly to their facebook email (don't know whether this exists anymore). In 99% these emails were relayed directly to the users mailbox (probably with the added benefit of coming from the facebook.com domain).
Many reported this, but it was not eligible for bug bounty, it was a feature according to FB, even though it circumvented their pay 1$ to deliver your message to someone you are not friend with.
Emails sent to a user's Facebook email address goes to their messages (FB Messenger) mailbox, but they may receive a notification via their personal email.
I've already seen that in Facebook ads, with people selling niche and probably auto generated products to me (my favorite was a shirt that says "I still miss Darius Milhaud"
I'm using debug logging ( that isn't deleted ) more and more as I code. It's useful not only for solving the current problem you're experiencing but also helps the next person understand what the code is/isn't doing, adding to its self documenting nature.
Debuggers are great, but the knowledge gained by using them to solve a problem is completely lost once that close button has been pressed.
Also if I'm having to use a debugger to work out what's going on, usually it's a good sign my code is overly complicated...
I'm assuming you get a lot of support financially from your partner / have a big runway? I can't imagine living on £9k a year without such? How do you survive?
edit: I Worry this comment comes across the wrong way. I've been desperate to do a startup for years, but the financial aspect of it has always scared me. I was told at a Hacker News meetup that I probably don't have the entrepreneurial spirit, which the more I think about it, the more I agree with. I'm curious as to how your mindset works :)
We both contribute equally, and we live in Madrid where cost of living is relatively low. Two people living together can live on £9K / year here no problem (that's about 1000 euros / month each). That said, I do have savings that I've been eating into.
I've never felt the need for lots of money to be happy. What I really value is being able to do interesting work that I'm proud of. So I'm very motivated to make money to the extent that it provides freedom to work on interesting things. And perhaps even to contract people to help out. I guess that's a philosophy shared by many of the people here.
> What I really value is being able to do interesting work that I'm proud of. So I'm very motivated to make money to the extent that it provides freedom to work on interesting things.
I couldn't agree more. I'm in the same ramen profitable situation (very similar amount). I love the challenges the product throws at me. Money is indeed just a means to be able to work on those.
For those who don't agree: the average person has about 60-ish years in his/her life where he/she is able to decide what they do with their time? Why postpone doing things that interest you?
Purely anecdotal I know, but since giving up my job in the city and going freelance I have indeed spent far less time drinking and far more time exercising.
A quick one after work was far too common. I buckled far too easily to peer pressure and conformity. After all it's the done thing to do right? A crap day at work is solved by a pint (or three) after? And a good day at work... well that could be considerably more ;)
The reduction in hours has allowed me to do activities which overall make me happier and less inclined to drink.
I now do a lot of running and bodyweight fitness. Drinking decreases my performance in those two activities and so I tend not to drink as I get far greater happiness from dropping a second in my minutes per mile than I do from having three pints during the week.
