It's subtle, but I think the use of "senior" rather than "Senior" in the article is an attempt to distinguish the concept of being a senior engineer from the title of Senior Engineer. The article is focused on actually being senior, not playing title games. I'd take it further and use the term "leader" instead of "senior engineer".
Leaders reduce ambiguity, so others can operate with more clarity. The ambiguity involved can be in many different domains. It can be focused on product and tech, as in the article. Another example is ambiguity around people and organizational structure, which is more common in management roles, where some in management are more effective leaders than others. It can be around finding ways for people to understand why they might want a product, which is more common in sales and marketing roles. And so on.
A few years ago, I moved from San Francisco to a rural area. Smelling weed in SF was not at all unusual. One summer night in the rural area, I smelled it coming through open windows for the first time. I wondered which house it was coming from and how it still smelled so strong after traveling a hundred feet or more. Then I spotted the actual skunk in our yard.
The "over" deserves a lot of emphasis. To this day, I save my code at least once per line that I type because of the daily (sometimes hourly) full machine crashes I experienced in the 80s and 90s.
It's a little early to say that "Python is shipping" anything related to this. The PEP is still in draft status and it may be modified (as it was three hours ago) or even rejected. The article says it is likely to be accepted, but that has not happened yet. That also means there is time to comment on the PEP in the discussion it links to if you'd like.
> The idea of a linear hierarchy in languages is the true flatlander mindset.
100% this. I think you can replace "languages" in that sentence with many things (employee levels is another big one that is relevant to this forum - employee value comes in many, many shapes). Reducing complicated things to one dimension can be a useful shortcut in a pinch, but it's rarely the best way to make complicated choices among things.
I've seen too much of the same. It strikes me that the pattern you describe also matches a lot of AI generated code I see, especially when it's big chunks of generated code. Are we automating this problem and going all-in on the long term costs?
100% yes. The most dangerous developers you’ll ever work with are the tactical tornadoes who crap out extraordinary amounts of code that mostly implements the exact feature that product asked them for with zero thought given to any other concerns.
AI makes these types of developers much more dangerous because they will accept anything the AI generates tha looks like it works, and they’re experienced at pushing nonsense through code reviews.
AI also provides more of a “productivity” boost to these types of developers because unlike everyone else they actually spend the majority of their time typing code.
This was the case before AI tho, people were copying coding patterns from companies randomly even without understanding. I mean there was an interview with some DoorDash architect that literally stated that whatever their architecture was just fad chasing at that moment.
Every company I've ever worked at (from ISPs to health insurance to finance) every organize was just copying the fad of something else.
At the time I felt like it was because that was "the best way" but it was more likely do to engineers not having the freedom to actually explore good solutions. The made up constraints imposed by organizations against their workers are rarely for the benefit of the company.
It's not a surprise to see this being the case, most companies on the planet are ran like centrally planned dictatorships with the results being obvious in retrospect.
XML and JSON only started about 5 years apart (1996 vs. 2001). I think XML's adoption was more broad more quickly, so the gap felt a bit longer than that (XML was a core part of my jobs from 1998-2007 and JSON ever since). I think more of what makes XML look so much older is the fact that so many new projects have been picking JSON over XML for 10-20 years now, and that's why younger folks have seen much more JSON than XML.
My software engineering career started long before either, and I have used both extensively. While I don't think that it makes sense for most well established projects to switch, just as rewrites often don't make sense, I would almost always pick JSON for new projects. Your points are valid, but one part of the ergonomics that you didn't mention is that it's so much easier for humans to read and write JSON, thereby speeding up development, debugging, testing, etc.
Self-driving cars also require us human drivers to learn new defensive-driving skills.
A month or two back, I was driving down a steep one-way, three-lane street in SF, late on a rainy night. I saw a Waymo stopped at the left curb and I moved to the from the left lane to the center lane in case it started to pull out into the left lane. There were no cars in front of it or behind it, so I was shocked to see it quickly leave the curb at about a 45 degree angle, as if it were pulling out of a tight spot with a car parked just in front of it, but much faster. If I saw a human driver doing that, it would almost certainly mean they are trying to get all the way across the street immediately. If it was doing that, there is no way I could stop in time on the wet downhill. I tried, but that just made steering difficult as my anti-lock brakes struggled to find any traction at all. Then, just as quickly, it straightened out in the left lane. I'm glad I was the only other car around.
One element of defensive driving is thinking about how to avoid surprising other drivers. When will self-driving cars' defensive driving rise to that level? Waymo certainly wasn't there in that situation on that night.
All the school buses near where I live (Sierra Nevada mountains in California) have these - it's cool to watch them lower and start spinning.
But chains aren't enough in some common situations around here that locals, including school bus drivers, know well. When we get a good size snow storm (multiple feet) and the sun comes out a day or two later, thick ice forms on the sections of road that the sun hits - snow melt runs across the road during the day and freezes at night, getting thicker and smoother each day. When that happens on our steeper inclines, chains on AWD/4WD vehicles are not enough to get up those inclines or to stop on the way down them. Locals know where those spots are and take other routes in those situations. It's hard for me to imagine autonomous vehicles having such local information in remote areas like this anytime soon.
reply