zerkten

My cousin chose RAF and got some single-engine flight training. This was early-90s. I don't recall exactly how much of his private licence it helped with, but it was a fair bit.

There is another element at play: modern software product management. I think revenues at the main driver, but behind that is the modern PM philosophy of hypothesis-driven development. In my experience, the average outcome is incrementalism in the extreme.

PMs break every feature down as an experiment to try and measure the value. It often misses consideration of the whole product. Everyone is scared of taking a big bet because it's harder to measure and too risky because all of these small bets are seemingly safer.

What I'd argue for is better product leadership that recognizes these new modes of development are just a tool. However, many product teams have become cults of experimentation and I expect this is the case at Adobe. It pays off as long as people are renewing, but the product suffers.

I can't reply to the reply to this comment, but you raise a key point. While employers control the data, they don't use it like people seem to assume. Managers are not managing if they attempt to resolve conflicts by attempting to decipher private conversations.

There are many ways to resolve these problems without resorting to spying on messages. In an in-person situation with a conflict, there may be no record. We know methods to resolve these conflicts, so I don't understand why people go immediately to "employers control the data so they can just use it."

>> Then you need remote "telemetry", meaning access either to chat messages, email, tickets, etc. and a way to process it at scale (without reading everything) in order to defuse sticky situations based on partial infos or misunderstandings.

How is that specific to remote work? People in the same building have the same misunderstandings with the same tools. The way to fix it doesn't involve management spying on the communications and attempting to decipher them.

It doesn't seem to be that consistent, at least in the US. In the UK about 20 years ago it seemed that most universities had a networking course that would at least get someone to the point of being able to converse with a CCNA even if they went into much more academic detail. My uni ran optional UNIX-titled courses outside of the degree to ensure staff and students had access to some practical training. It touched on Linux networking too.

I'm now in the US and I find I'm horrified at the level of networking knowledge, but occasionally impressed at the level of knowledge on other topics. It's no consistent set of topics because there seems to much more flexibility. The UK is fairly rigid with electives.

I think that's a case where a good author has chosen the publisher for some reason. They are good enough to be published by someone else but went with Packt possibly because it was an easy onboarding.

They will take on literally anyone as an author. Authorship gets you kudos in the increasingly large segment of programmer influencers.

It doesn't seem that people actually learn those things in many cases. I encounter programmers fairly regularly who struggle to grasp CPU vs memory vs I/O trade-offs and have no mastery of tools for measuring them.

This is unfortunate because the tools can often be a cheat code. It's painful to see people fixate on one possible cause without going to fundamentals and making a proper assessment. These people all pass the traditional programming interview filters for algorithms.

I didn't read much of the site yet, but one way I might read your quote is as being against those who ripped the country apart after communism. I would guess that many young people see that as the last tragedy and not communism.

FWIW Yugoslavia was open to tourism during the Cold War. My father drove from the UK to Dubrovnik with a friend in the 60s. I retraced part of that trip about 5 years ago. I'd have seen more had this site and book been available, but I stumbled on a few of the places on their map.

Not on their map is Zeljava [1] which was an airbase with extensive underground tunnels under a mountain on the Bosnia/Croatia border. At the time, a few parts of it were cleared out with bits of spares amongst the debris. There is a UXO hazard away from worn pathways. This is highlighted by the mine signs. I think there have been a few accident since the war in the 90s, but inside there was a bigger risk from falling concrete (look up for blast door). Recent photos [2] show it has been cleaned up a lot.

[1] https://en.wikipedia.org/wiki/%C5%BDeljava_Air_Base [2] https://www.scmp.com/photos/today-photos/3238875/once-secret...

You can follow the GitHub link and see that the author works with Microsoft Intune (MDM) which confirms what you are writing here.

If it's an MSI-based installer, it's pretty easy to edit the MSI with Orca to remove the check. This is similar to how you'd get client software installs unblocked on Windows Server. In other cases, there are often ways to trick it, but it's contextual.

>> culture of underinvestment which the UK public sector has been undergoing for the past 15 years.

It's going on for much longer than that. It's hard to think of a time when there was investment. It's also hard to think of a time when the individuals and teams who could have prevented this would be given the respect that they deserve. This is a problem in the UK that extends beyond the UK public sector because a lot of the management in large organisations has some cultural similarities.

As a UK citizen living overseas, I would put problems like this down to more than just underfunding. One of these is the frequent challenge with "talkers" versus "doers" and the wrong people being promoted within the bureaucracy.

This is especially the case in government orgs and those close to them which are old and extremely bureaucratic. There are many good people in these organisations who should be paid more in many cases, but they are severely limited by the system.

I find it hard to see that this wasn't something expected by many in the know at multiple levels within the British Library. Now it's an even bigger mess that they are ill-equipped to respond to.

Nice concept. I don't like that open in new tab is broken though.

What happens when you work under a group of people who are satisfied at stage one of project X? You know you can iterate to get two stages further, but they want you to work on projects Y and Z. This is a very common situation where you, or even the whole development team has very little control.

Of course, management should be supportive of quality improvements, but their reality is either one where they are under genuine pressure to deliver projects X and Y to stage of quality through to not understanding or caring about quality.

My own experience is that individual programmers have vastly different ideas of quality is based on their experience and education. You can be struggling to get a team to improve and then you hire a somewhat normal individual with a very different background who makes a sizeable impact on quality and the culture of this in the team. I'm thinking specifically of someone who joined from aerospace, but I've seen it with finance backgrounds. I think the background matters less than the perspective and ability to hold people accountable (including yourself.)

Why use the Copilot name? It's confusing because you seem to have an agnostic product.

Do you still tend to answer questions? It feels like there is a drop in quality contributors too because they got invested, but have peers engaging in the behavior you describe as a questioner. They want to take kinder approaches, but that's never going to win over that power user segment.

I have a high reputation that unlocks privileges, but I rarely go back these days to answer questions. If I can snipe someone that's trying to shut down a question prematurely then that's kind of fun.

Create an issue at https://github.com/microsoft/generative-ai-for-beginners. There is a call to action for feedback and looks like at least one of the contributors are in education, so will probably take the feedback on board.

I look at it in the following way:

- Ruby and Rails are joined at the hip in a way that Python isn't. While Ruby is a general purpose language, it was only strongly adopted by web developers.

- Rails didn't have a competent deployment story initially. It was a pain to deploy and run mongrel relative to other platforms and this only seemed to get effort after the first RailsConf. The impact of this was primarily on enterprise developers who might have gotten adoption to a higher level.

- Speaking of the first RailsConf, DHH did everything possible to undermine potential advocates within the enterprise space where lots of Java refugees might have helped with adoption. ThoughtWorks backed Ruby and Rails, but there are quotes from Martin Fowler like:

"A couple of years ago I wrote about the impressions people had that the RubyPeople were notably more friendly than most software communities. Talking to people at RailsConf I got the message that that had changed for the worse. Both the ruby lists and particularly the rails lists had tended more towards the sad Internet mean. In his opening keynote Chad Fowler said that the rails community had a reputation as "a bunch of arrogant bastards" and I cringed as an, admittedly small, group raised a triumphant cheer." (https://martinfowler.com/bliki/RailsConf2007.html)

- The community was very anti-Windows which stifled adoption. The default developer machine now seems like a MBP, but it wasn't in 2007. Rails got lots of attention around the time of the Intel transition so this was a cool time to have a Mac. A PC was only usable for Rails work if you put Linux on it. Some people realized you needed better basic Windows support to run Rails for development, but it wasn't a priority. Again, this limited potential web adoption.

From this you can see a repeated pattern of mistakes which would have at least increased Rails use in the enterprise market. It was strongly adopted in startups and niches within enterprise that IT didn't control. There was no real reason to discourage this community of developers who found Rails a nice fit for what they were building.

Now Python:

- The Python community specifically targeted diversity and getting adoption in first programming classes in colleges. This was an active effort that accelerated things at least as much as use in data science. The fact that everyone was being taught Python as a first language even if they'd go the web route was a huge boon to cement it within the data science perspective.

- In the previous point I called out diversity because it was a key differentiator in getting it everywhere. Not everyone stayed in the community, but they stayed at a higher rate than Ruby. People will want to discount this because they feel it's political or woke, but it affects the TAM. I don't think you can substitute "friendly" because they knew that wasn't sufficient.

- Python has had stronger Windows support. The effort was inconsistent over time, but it existed and wasn't discouraged to the degree that it was for Ruby. Companies like Active State where popular long before Anaconda appeared on the scene.

- Packaging in Python is a disaster zone, but it's been good enough to get adoption.

- Google gave credibility to Python at a time when it was competing with Python. This swayed non-devs in decision-making roles to an extent. Importantly, Python hasn't been wed to one vendor. When Google dropped, other stepped into the fray. It seems MS are quite involved today.

- The transition from Python 2 to 3 is viewed as a misadventure by many. It did this and still won out. If you rewind to PyCon 2009/2010, the vision shared by Guido was for a long term transition with some degree of experimentation. People have forgotten, or joined late.

- Data scientists have taken over the Python community, but Django and Flask are still pretty sizeable communities. This diversity is a strength and the community is open to experimentation.

- Python performance doesn't suck much more than Ruby for the most part. If Python had disadvantages to a peer like Ruby, it may have had an impact. Instead, people inside the community complain and stay, or they peel off to Go/Rust/C#/Java/Kotlin (any faster platform) at a slower rate than you might expect. Yes, whole teams/apps drop it wholesale, but what matter is the overall number. I think this is more of a concern today (like packaging is) than it was in the key period of 2006-2012 when the battle was fought.

I think the first thing you need to do is get out of the programmer mindset. The problem you are solving may be closer to resolving the anxiety of leadership, or build confidence. In reality, the situation is complex and our responses may undermine confidence and drive anxiety at different rates with different stakeholders If you ask some folks from other fields to read the StackOverflow link you shared, they'd provide some insights that aren't fully explored.

I don't think you can get there with KPIs, but at the same time, you can't completely discard methods like these which have some level of credibility with other stakeholders. As evidenced by many conversations on this topic involving programmers, KPIs get completely thrown out, or worse, undermined. Insufficient time and effort is given to actually making the leap to something that might be useful sustainable. Hence, many places never break away from KPIs and the complaints keep coming.

Measurement without particular targets can be quite useful when the organization is open to sharing data without punitive responses. This gives you different axes to explore with regards performance so that you can shape your messaging around performance provided you can contextualize it.

EDIT: My personal philosophy on how strategy should work and be implemented is closer to that of Mintzberg (https://en.wikipedia.org/wiki/Henry_Mintzberg) than Porter.

Do managers actually like dashboards and KPIs? Not all managers report directly into the CEO, so suffer from the problems as much as their underlings.

Management want indicators of certainty and progress with the least effort possible. Superficially, dashboards composed of KPIs give them what they want. Good CEOs are unlikely to rely on these, but instead think of them as an alignment and investigative tool.

Each layer of the organisation aligns itself around some KPIs with lower levels often feeding upwards through the hierarchy. As you further down the hierarchy things get messier as they are further from the executives, may have less experience/skill with using tools like KPIs in the way the CEO wants, and there many more teams to align across with problems like duplication, etc.

The majority of engineers are at the bottom of the pyramid. Their management is coming from their own ranks with little support, so it's not a surprise there is misunderstanding and misuse. In programming, when the career ladder often involves stopping dev work and becoming a manager, it only makes things worse. When I see peers promoted into management, I always hope it's the ones that have capacity for leadership versus experience because they are going to be the ones that adapt KPIs to match the internal and external needs of the company.

It sounds like you have a dysfunctional organisation as much as KPIs are a problem. KPIs and everything around them have been studied to death in more than the last 40 years, so there should be few surprises around when they are useful or not. People and politics are the constant so we never get away from organisations like the one you describe.

I think that's a good point. Companies are likely going to try to neutralize this by saying that telemetry just being another kind of data that they can make safe by removing PII etc.

You don't understand the GDPR then. The focus is on controlling where data goes (not out of the EU), but your point is about telemetry in general. If you keep the data inside the EU and manage it in a way that's compliant with the GDPR then then that telemetry doesn't put you in jeopardy.

If you want to be protected for telemetry then you need to advocate for better legislation. Stating that something is covered by the GDPR ultimately masks the issue because it's not against the GDPR and you lose an opportunity to advocate for better legislation to reduce, or kill telemetry.

Did you consider the impact of missing out on preventative care?

Have you seen a dentist? The dental coverage from employers feels much more limited (except for preventative cleanings) and you can expect some not so fun problems if you miss so many cleanings.

Does Radio France generate revenues in other French-speaking countries with the same content? It feels like the BBC is trying to maximise revenue but expectations for consumers locally and overseas are going to be very different. Blocking loopholes hurts the local users more.

I don't follow the BBC's approaches to revenue generation that closely, but is part of this due to larger overseas audiences? I'm now living outside the UK, so I expect that I'm viewed differently as a user by the Beeb, as well as by TV licence payers. If access to content isn't controlled then it's harder to maximise the revenue.

BBC Sounds feels like it's part of that efforts, but I'd be interested to know more given how much family members complain about the costs of licencing and services relative to the quality.

Having been a Red Gate customer in 2005, I decided to take a look at their current offerings. Based on https://www.red-gate.com/products/ it seems like they have started to look at other database. The newest products seem to have support for at least 3-4 databases. They are maybe caught between rewriting a legacy product and building out the features in their successor products.

Does Google run other indexers for the purposes of catching cloaking? Are there other strategies that can be used? One of the problems of SO is that most of the valid content is out there and easily available without having to scrape the site which may mean penalizing for bad content is harder.

This can be true while it still keeping most criminals out. It's going to depend on the location and context. I'd say an analogy for this is engineer thinking versus economist thinking. My observation is that criminals prefer the latter. Rather than doubling down on engineering, they try to move to a more lucrative venture. Getting better at burgling houses doesn't change the upside as much as other crime.

In my suburban area, the biggest problem is unlocked doors on houses and cars. Despite this problem existing for many years, doors are still regularly left open. The criminals don't attempt to exploit the same neighborhood repeatedly. They pass through in waves and then go elsewhere before returning when everyone has let their guard down. When they attempt forced entry, or anything more than casual theft, they get a lot of attention and caught.

They could improve their takings by developing some lock picking skill, but it's also higher risk since they have to spend some more time on each target which increases the risk that an observer will actually notice them. I could easily imagine a dog walker ignoring someone entering a home through an unlocked door, or making it look like they are checking a door is locked when entry fails.