It goes on to describe what counts as a claim, how to verify the claims, and how to respond. It responds to each claim with verified, unverified, or contradicted.
The skeptic agent has been the most high value thing I've added to the workflow.
169 karma · joined August 19, 2013
It goes on to describe what counts as a claim, how to verify the claims, and how to respond. It responds to each claim with verified, unverified, or contradicted.
The skeptic agent has been the most high value thing I've added to the workflow.
Every feature I build uses a skill that does the following:
1. Read a ticket and get context on the task. The ticket was probably written by another agent after a conversation with myself about what is happening/needs to happen, etc.
2. Plan the task, asking for clarification where needed
3. Pressure test the plan, and validate the plans logic (subagents)
4. Implement
5. Runtime/local validation
6. Post PR, review it using applicable agents (database, security, code, prose...)
7. Fix PR based on feedback
I generally get excellent results out of this process, and I cannot imagine trying to orchestrate this without a skill. But I also can imagine my workflow isn't tuned to be super usable for anyone else.
I think we're starting to see that across the entire industry. Leadership is easy when times are good. The job has gotten very hard.
1. Solid code reviews. Anyone of our developers can halt a code review for any reason. We require 3 approvers on each review. Sensitive areas require reviews from people familiar in that area. We also have tooling that allows us to generate amounts of test data in dev that is similar to prod loads. This helps us catch a lot of time bombs.
2. Feature toggles to decouple deploy of code from release of code. This allows us to test our code in production before turning it on for customers. It also allows us to slowly rollout a feature and watch how the code behaves. This also gives us a kill switch to turn off the code if it is bad.
3. An incredibly robust testing pipeline. It takes about 50 minutes from commit to production deployment. We can also deploy previous containers very quickly for situations that require it.
This doesn't solve all of our problems. Some changes cannot go behind feature toggles (DB migrations, dependency upgrades, etc). But we do pay a lot of attention to design and rollout plans for database migration changes and such.
All of these things come at an extra cost to us, but it allows us to move quickly when we need to. But we're in a lot better place than we were when we were trying to do weekly releases. We have a good mix of team experience (sr vs jr) - and have a lot of discipline in our software engineering practices. We still have problems like I said, but these strategies have greatly improved our ability to deliver software.
That's been my experience as well. When a manager says they try to "shield you from the bullshit" it's just a lack of transparency that leads me to making my own (often worse) assumptions.
It seems like none of this actually matters until we can solve that problem.
This is the key. Google wants to make sure your readers are getting their questions answered. SEO is constantly changing, but high quality and valuable content will always be king.
aka, exploiting the script loading behavior...
What happens when they start doing things you don't like?
Or what?
There's no one enforcing rules in this administration.
~4 hours from report to release.
There have been efforts recently to make the game safer for players, but the amount of concussions and injuries seen every season don't seem to be decreasing.
Can you make the game "more safe" without drastically changing the game? Any game played at this high of a speed, with this strong of players is going to have some inherent danger to it.
Do we just need to make the effects more widely known and understood by the players, maybe treat football like smoking with warnings printed on the outside of helmets? Anything less than that and you run the risk of not making your point.
Should I feel bad as a fan for watching football? Is it any worse than buying clothing made by child labor from a third world country?
But a google algorithm change could definitely crush his income.
A very short read, and quite interesting. It touches on a lot of the same points already made in this thread (people will game metrics, etc). The biggest argument that the book makes that is trying to set up a system to accomplish something will cause the system to do everything but accomplish its goal, which leads to the above quote. You can't set up a system to achieve a goal, only set up an environment that allows the goal to be achieved.
I use lastpass with a yubikey for 2fa and I feel safe enough. I briefly looked at other password managers when I was evaluating lastpass, but convenience won out for me. I haven't looked at moving out of lastpass, but 3 years ago no other password manager came close to the mobile and platform support that lastpass had.
I considered keeping my passwordDB local, but the inconvenience of needing it and not having it wasn't it worth it to me. Do I know I'm making a tradeoff? Yes.
I also have a nasty habit of setting things up on a local server and then never updating it. Instead I decided that lastpass was worth the $12/year so I wouldn't have to manage anything locally.
So while lastpass may not be perfect security, I'm a lot better off than I was three years ago when I used the same few passwords everywhere.
It also helps me share passwords with my wife, so that's nice.
It's not very fair to make these claims without knowing all of the details around the situation. Microservices CAN be a pain, but it might offset a greater pain of trying to coordinate a monolithic deployment. It depends on things like team size, budget, and technology available to you.
This is where I see the disconnect between employers and most developers. "Programming" isn't a job. Your employer doesn't pay you to write code. They pay you to solve problems. The good employers don't care what tools you use to solve the problem, just that you solved it. The bad employers will force you to use technologies and buzzwords that probably don't apply to your situation. You should be able to defend all of your decisions and have good reasons for them.
On the flip side, not everything you try will work - that doesn't mean that it's a bad option, just that it didn't work for your situation. You don't need to have a redundant low-priority memo system because you don't get enough value out of it to justify the overhead of maintaining it.