I read The Cuckoo's Egg only a few years ago (in my 30s) and it's an absolute delight. Easy to understand if you do any sort of linux administration, and really demonstrates how lax things were and how far we've come in terms of cyber security.
Yep. I've found that the ticket or tech debt isn't important until it becomes on fire and must be fixed ASAP. It doesn't matter that the possibility for the bug to happen has existed for 2 years, the organization doesn't find the investment worth it until it's burning down the house.
which seems like such a blatant failure of leadership. If I had 1000 ways that I could invest $1000 at a 20% return this year and like 5% recurring[1], why not hire 2-3 engineers get them done and keep the extra $200k plus have a better future?
The most compelling argument was opportunity cost against features (eg the time spent on feature work would return 100% per year or whatever seems enticing) ... That seemed to me to only suggest we should do _both_ (get more capital in the market if required)
[1]: some amount of recurring makes sense so long as things like customer retention, brand value, maintenance costs are factored in
Having dealt with all of these in production, I can tell you the strategies I've used to combat these things:
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.
Out of curiosity, how many devs does your org have? I think a lot of the disagreements here come from people at orgs with 3 developers talking to people at orgs with 30,000.
> I've worked at a lot of places like this, and I'm continually surprised people enjoy it.
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.
Wall of text incoming; I was trying to explore why I agreed with you and the parent post wholeheartedly while still finding some value in the "shield from the bullshit" concept, if perhaps not how it's commonly applied.
So I'm in an interesting position to comment on this, as a dev trying to transition into management. I've ALWAYS been on the full-transparency side as a dev, but have often had to defend that position to other managers and bosses, with the justification that I might scare the devs or distract them or have them focusing on things that aren't their core goal.
There's definitely a kernel of truth in that, but I've found most of the "grey area" is less ambiguous in practice; (e.g. don't be a rumor mill, don't get people worked up, realize there may be a proper time and place) and more importantly, _devs usually know most of what I would tell them._ They're not idiots. They have people they talk to, and they overhear things, they usually know how the games are played at some level and have some intuition that "something is happening." And by trying to hide this, and not being a partner and helper in wading through it/building confidence, you erode trust. So in terms of the "what's going on in the team" bullshit I'm pretty open, even if it's a bunch of political infighting and misaligned incentives, at least so the dev can understand the landscape and make sense of it.
The bullshit that I DO however think you can shield a dev from is the "Symptoms" of the above. Help balance out individuals playing favorites, individuals being biased against a certain dev, help a dev see if turmoil is coming and how they might navigate it, help a dev understand where motivations are pointed so they can avoid socio-political pitfalls, or optimize the decisions they make to drive their career to be responsive to the ecosystem they're in.
I believe one can be transparent enough to let a dev know WHAT is going on, but still provide them an ally and shield against potential negative impacts of it.
Lack of transparency is just bad communication. I see "shield you from the bullshit" not as bad communication.
I look at it more like this: The customer has an emergency and needs something ASAP. A bad manager will pass this bullshit straight to his team, including the "Oh my god this thing is going to blow up if you can't get it done by Friday!!!!",
A great manager however, will first figure out if this is a real emergency or not, how much it will cost, etc. (S)he will take into account who is currently working on what, what the priorities are, etc. Then will present a realistic solution to the customer/management: "Look, this we can do, this we cannot do".
In this situation, as a team member, work comes in as usual, and you probably were allowed to put an estimate on it. No "Help the world is going to end if this isn't done, DROP EVERYTHING!!!".
I've worked for multiple managers that fall in either bucket, and I had cases where something needed to be finished by Friday, because the customer needed it on Monday. Asking a week later after deadline: "Did it work?" "The customer hasn't tested it or put in production yet".
Great managers however, have great communication skills. Maybe a better wording is that they are able to filter the bullshit from the rest.
And when something bad happens because of this rushed code, they'll tell you, "you have to do more testing", make sure quality is not compromised. "We can do automated tests, we can do them as long as it doesn't eat up developer time".
Makes me think that in a consultancy business, everything hinges on getting the customer to fund your development properly. Ask too much and you'll lose the contract to a competitor.
I once read an account of someone that took Ibuprofen on an empty stomach and burned a hole in their stomach lining. Since then I always eat something first.
I disagree. If the wishes of the electorate were unambiguously publicly available, then it would be much more obvious when elected representatives are not serving them.
Right now we're reliant on things like polls or the FCC's farcical comment system, which can easily be gamed.
There are two basic primary levers in US politics. Money. Votes. That's pretty much it.
If you are able to organize a consistent voting bloc that reliably votes the way you promote, and that bloc swamps all money-based efforts to sway them in any other direction, your voice carries more weight than the money. Period.
Even more terrifying to career politicians is the ability to organize so many voters that you can successfully mount a recall and force the recall on demand; in the US, recall power only rises from local to state level, but does not hold at the federal level, though.
The trick is to continue as that voice, and not step into the ring to play politician. Thus far, no one who was able to organize votes has been able to resist that siren call. That's why vanity is listed as one of the sins. This is also why money steadily overtakes voting power on a long enough time span.
> There are two basic primary levers in US politics. Money. Votes. That's pretty much it.
There's at least three: money, votes, and committed foot soldiers (it's easy to think the laaf two are the same, but they don't overlap more than any other pair—whilw commanding votes and commanding people that will work for the cause (and thus move money and other votes) are loosely correlated, they aren't the same thing. One of the particular values form which religious communities are targeted as such is that they often command foot soldiers at a level beyond what is true of groups that deliver similar committed votes.
> You have to really provide valuable, quality content for organic SEO
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.
The thing is, in WordPress, it's not uncommon to end up with a public URL that takes a few seconds to generate if it uses a few plugins or multiple queries on a low-end server. This is really just demonstrating that apache/nginx fall over at some point (usually what goes away first is the MySQL connection).
