Maybe German software engineers have to use sex boxes a lot?
313 karma · joined January 2, 2020
The internet has only really been with us for a few decades, and yet has completely transformed the fabric of humanity, acting as a bizarre and extreme lens upon existing human traits.
At some point, logically, there has to be sufficient reaction to bring us back in line with what we came from. The "winner take all" effects from the internet are just too extreme to be feasibly sustained.
You can't have a happy society with such extreme gaps between rich tech people and everyone else living in tents or off what they choose to spend their money on. You can't have a happy society where the top 5% of beautiful men are paying people to schedule their calendar of tinder lays while other guys buy thot bathwater, or where the top 5% of women get all the attention and the rest wonder where their prince charming is who's been denied them from all this as they sadly pass 30 alone.
The fact is, a huge amount of bad has come from the internet. A seriously huge amount. And the opportunity cost of all that capital that went into enraged politics on twitter and inanity on facebook, that could've gone into medical research... At least we got Musk from it I guess.
It's a strange feeling. Being an active participant and facilitator in something that is clearly not naturally aligned with human happiness, only human progress. In the end, what choice do we have. This is our natural aptitude, and succeeding in it can mean the difference between living paycheck to paycheck and becoming financially free. So we're going to do it. We have little choice. But we can't say any of it is fundamentally good. At best we're peddlers of the neutral and inevitable.
The idea is that devs and large companies have a tendency to constantly move away from tried and tested concepts not because the juice is genuinely worth the squeeze, but because doing so forces the devs "in their dust" back into learning mode and out of productivity mode, thereby maintaining or creating leadership over them (i.e. you force them into playing catchup -- catchup to your new "hot" thing).
Case in point with this article: an attempt to declare that a tried and tested and widely used concept is now outdated, and they know the "right way" we should be doing it.
This paradigm is important from a dev management perspective, in that there must be an element of actively suppressing this in a dev organisation.
E.g. having approved tech lists so you don't have another half dozen js frameworks inserted over the next 12 months, requiring permission to stray outside standard paradigms, and compartmentalizing experimental time from production time.
Otherwise your dev output drops through the floor.
MVC is fine. Its a basic concept that aligns with the underlying hardware: model - memory, view - screen, controller - cpu. It ain't broke, don't let your devs fix it.
Even places like this maintain a certain form of discourse by threats of bans.
And one man succeeding in shady dealings hurts few. But the state succeeding in boundless detention puts everyone in peril. He may have some power, but there is no more powerful an entity than the state.
There's a basic rule of war: slow slow, fast fast. You slowly and quietly gather your forces and telegraph nothing, and when the moment comes, you unleash it all at once and unrelentingly. That's what they should've done. Not made a move until they had the evidence to put him away.
The fact they couldn't do crap for months on end just broadcasts to the world: "we don't actually have any evidence to convict him on".
Nothing's sacred in this world, not even habeas corpus, because no one can be arsed reading history -- it was never a matter of anyone forgetting it.
Children in Japan are taught at a young age to turn in even small found items, like a single small denomination coin, to the police station.
This bakes into them the sense that "that's what you do with found items" and coupled with the fact the police will return it to them if no one collects it, bakes in a sense of trust of the police at an early age.
Factoring in people held in US because they can't make bail, also diminished some of the "held without trial" margin. But this is fundamentally a bigger problem in Japan, as it has now embarrassed the country on the world stage due to the Ghosn case.
A state that holds people just becauss it doesn't like them, rather than due to evidence of breaking its laws, relegates them to the same league as the North Koreas of the world. Profoundly embarrassing for a first world country and a major step backwards in reputation.
And that was on Slack.
The guy just hated them, so that was my idea and made him happy.
And I don't disagree with that. Sticking rigidly to one true cadence of one true meeting is a religious ritual we can do without.
If a 1:1 adds anything to your team, it indicates defects. Everyone should be raising issues as they come up and have a close enough working relationship with their boss that a cyclical meeting adds nothing.
And most of those questions are weak: bosses annoy and lose respect of their subordinates when they go all "facilitator" and "servant leader". A leader guides, they don't ask subordinates to tell them how to do their jobs. There are plenty of traditional ways to glean improvement information than appearing weak by asking "how can I be a better boss".
But seriously, buy gold.
Code is closer to a craft like carpentry than a pure knowledge job. There aren't any rules, only heuristics, and it takes time to hone your skills (not "learn" them).
The biggest limiter in this is the excessive tendency for flat hierarchies in dev. It flies in the face of the apprentice - journeyman - master system that has always naturally structured the delivery and learning of craftsmanship.
The fact that you'll barely be using the algorithms if at all doesn't matter. They use that for interviewing specifically because it's hard, and it screens for intelligence, problem solving speed, knowledge, and even how fast you learn (since everyone's got to learn the same algorithm question prep).
The end goal for them is that all their workers are at a minimum screened for the ability to grind at and break through difficult and esoteric problems, which are the biggest time sinks and therefore biggest limiters on the progress of the business.
The end beneficial owners of a business have limited power over it. They exert weak control remotely. Usually this amounts to no more than "hire someone to run the business, reward him based on profits" (and sometimes barely even that).
That person, the CEO, also has limited control. He only has so much energy and time in a day.
Meanwhile, parasitism is the norm. The easiest way to get a promotion is to simply do less work and do more of what you want. Spending all day in meetings sounding important, going on junkets, playing around with new tech for fun, puttering around with emails instead of impactful work, etc. Then you're getting the same pay for less work.
Therefore it requires constant pressure from the top to retain alignment of the staff with profitability. How effective the CEO and his team is in suppressing politics, suppressing friendship based (vs meritocratic) promotions, suppressing false work / lazing (meetings & makework etc), will always hit a limit. It's just as much an area of ongoing development as anything else in business -- how to maintain the productivity of small teams as the organization grows and vice becomes harder to suppress.
So I think this is more likely the cause than people being promoted to the point of incompetence -- the organization grows to the limit of its leader's ability.
Whether you should have separate project managers and whether you should have a flat hierarchy shouldn't be connected.
As far as PMs go: from long experience, I've yet to witness a good one. I'd say at least 80% of devs are productive assets -- i.e. their work moves the project forward. Maybe 20% of PMs are. In well over half the cases, the team would be more productive, happier, and effective if you simply fired the PM. Others might scrape by with a break even.
As far as flat hierarchy goes: that's anarchy, and anarchy is conflated with chaos for a good reason. You can read a codebase and detect within 5 minutes if it was written by a flat hierarchy team. I'll take a foul mouthed Linus tyrant at the top over a flat hierarchy any day.
The problem is that due to the nature of the job of PMs (supervising & giving orders & planning work etc), they're naturally superordinate in role, no matter how many times you call them a "servant" or "facilitator". But they're also the least qualified types to lead devs. They know nothing about development, and most of what they naturally tend to do to exert control and carry out their role results in purely damaging effects.
As I see it, the only effective solution is: (a) train devs how to manage -- since that's much easier than teaching managers how to dev, (b) establish clear hierachy but with everyone subject to rules (basically replicating how states work).
I'm never one to turn my nose up at the division of labour rule, but I don't believe PM is ever truly labour that can be divided out without interfering with another rule: the wise should lead. PM is too close to a "boss" concept to be separable labour. I.e. it's never truly horizontal, but vertical. Which is why I'll never hire or create such a role, and instead train the best devs to move beyond just typing code and move towards "conductors of the code being typed".
Company, firm, and business have specific meanings.
Given BBC is UK based, a company would mean a separate legal entity to its members (a 'corporation' in US).
A firm means a group of people in business together, either a company of more than one member or a general partnership.
And a business is the true catch-all.
I doubt these businesses going back hundreds of years are incorporated entities. Back in the day those took an act of the state to form. The first KK in the country (Inc. equivalent for those in US, or Ltd. for UK) was only formed in 1873.
And I doubt businesses have been general partnerships continuously for hundreds of years -- since these desolve automatically when the membership changes e.g. by a death.
Especially to journalists, these details should matter.
But for the people this is good advice for, worrying about diversification is out of scope. Get 1 year's USD in the bank before that.
The problem is, the tech is hot because google etc do it, and they're using it to solve problems light years from what yours might be.
The results are absurdly engineered monstrosities. Simple blog sites with 10 different frameworks in them, running on some absurdly complex cloud infrastructure.
Normally you need a senior dev with a sense of pragmatism above them all to smack down any attempts to straitjacket the coding below/around them.
I use PHP a lot, simply because there's so much of it out there (lots of work), and one of the firsts thing I often do when taking on a project from another vendor is rip out any "no space at the end of the line" linting garbage and the like. As always in life, it's not about swinging for one side (vomitcode) or the other (anal styleguides), but achieving balance.