So is insulin. But at least in the US, it is expensive.
106 karma · joined April 6, 2020
Perhaps with wealthy country populations projected to fall dramatically we will finally be forced to find a way other than "growth" to value human endeavour. That would be the most likely path to a solution, I fear it will be rather painful.
Yes, generally I join teams and work as an engineer or sometimes as a team lead, so I'm talking to all the team members.
Most start up teams are composed of junior developers, often pretty smart people. Usually 5 or fewer years of experience. Many times these are people who have already accomplished stuff they didn't think they could do. So that generally means that yes they think pretty highly of themselves. To a degree it is quite justifiable, they tend to be very accomplished but in a narrow domain. Unfortunately they don't realize that their technical accomplishments in a specific field does not mean that they are experts everywhere. Their managers understand that these are smart people and assume again that this is therefore a good team.
Non start ups that I join are usually just plain dysfunctional.
> Also, did you run across any orgs where they basically refused to use a process like Agile, and instead just did ad-hoc coding, insisting that this was the best way since it worked just fine for them back when they were a 5-person startup?
Usually more the opposite. In my experience I come across teams that are sure they must not need any help because they follow all the rules in Scrum and have great code coverage metrics.
It is really common to see this kind of thing. I call it "the proxy endpoint fallacy". It can crop up anywhere that there is something that can be measured. In that example, it would be confusing adherence to Scrum with having a working SDLC or perhaps confusing code coverage metrics with the objective of having bug-free releases.
This isn't a software only fallacy. In politics, GDP is often confused with societal well-being. Always be wary of your metrics and change them as required to keep you tracking your actual goals.
Consider the classic statistic "most drivers think they are above average".
I posit that the same is true of software teams, almost every team will self-assess as above average, i.e. good. Those teams will then imagine that, being good, they build quality into the process and very little verification QA is done.
I have worked as a software consultant for 15 years now. I've worked with at least 40 separate software teams in that time. Every single team manager would pep talk with "this is the best team I've ever seen". Some of this is obviously blowing smoke to get people to work harder and feel good. But over the years I've had candid conversations with managers and realized that most of the time the genuinely think their team is really good, truly top 10-20%.
Here's the rub. Being a consultant, I'm almost always brought in by higher level management because something is going horribly wrong. The team can't deliver quickly. The software they deliver is bug ridden. They routinely deliver the wrong software (i.e. incorrect interpretation of requirements.)
Often times these problems are not only the fault of the development team, management has issues too. But in every single case, the development team is in dire straits. They have continuous integration sure, and unit tests, and nightly builds, and lots of green check marks. But the unit tests test that the test works. The stress tests have no reality based basis for expected load. The continuous integration system builds software but it can't be deployed in that form for x, y & z reasons, so production has a special build system, etc...
In 15 years I have never once encountered a team that would not benefit from a QA team doing boring, old school, black box manual testing. And the teams that most adamantly refuse to accept that reality are precisely those that think they are really top tier because they have 90+% unit test coverage, use agile and do nightly builds.
So, my question is, do you (I don't mean the specific "you" here, rather everyone should ask themselves this, all the time) think that most bad software teams know they are bad? Including the one you are part of? Would it really hurt to have some ye olde QA, just in case, you know, you are actually just average? :)
This behaviour isn't really all that uncommon. An obvious recent example would be Boeing with the 737 Max.
To save a few bucks they've thrown away a quality process that was best-in-class. Only cost a few billion a few years later...
Our implementation of capitalism rewards only short-term thinking, that is why this behaviour persists.
Not only do students come into university (and sometimes even into CS) not knowing what a file system is, many of them have a total lack of interest in learning what is perceived by them to be pointless.
I'd argue it is going to be pretty difficult to engage with any of those foundational topics if you aren't willing to engage with the basic metaphor of most operating systems, files and directories.
Would it be better to live in a world where Twitter (for example) existed because it is a useful thing and not because it might make lots of money?
Don't give companies that you don't think have earned your money your business.
The fifth episode is also on Youtube [2]. Does anyone have links for the others, I haven't been able to find any...
Edit, found the fourth [3] and sixth [4]
[1] https://en.wikipedia.org/wiki/Funny_Business_(TV_series)
[2] https://www.youtube.com/watch?v=bICuqEHWS8Q
What the article is asking, albeit obliquely is: how do we know that to be true?
It is very difficult to prove when definitions for intelligence and consciousness are fuzzy and not widely agreed upon.
It could be worse, they might be asking you to put it on a blockchain :P
B2C on the other hand is a different story. Every few months we have to roll out a new tenant in our system. Tenants are identified by B2C "applications". Every single time, the new application doesn't work. Every single time the fix involves editing the JSON spec, changing something random (like a "true" to a "false"), saving, and changing it right back again.
Doesn't exactly inspire confidence... we're planning a migration to AWS.
Also, try Googling for documentation related to "Microsoft Azure AD B2C". Almost every shred of internet wisdom is related to AD and not B2C. Even with Microsoft's own documentation you sometimes follow a link from a B2C API reference and find yourself in AD-only land and it isn't obvious. This makes the task of researching features and debugging infuriating.
First, Boeing doesn't prioritize safety anymore. Profit is the driving factor in their decision making. You can read about the issues they have assembling the 787 in South Carolina. It is so bad some airlines are refusing to take delivery unless the plane is validated by the assembly line in Washington.
Second, the FAA was caught being complacent with the 737 Max. It will take some time to fix that, but it is clear they don't want to make the same mistake. Also, the EASA is no longer just rubber stamping approvals following the FAA. Both agencies are combining to improve safety, which is highlighting the management problems at Boeing.
This kind of thing irks me when I read it. I don't understand why people think of microservices as an architecture pattern. To me they seem more like an implementation detail.
When it comes to concurrency and multi-threading, microservices mean you have different problems to worry about, not that they go away. I try to get people on my projects to imagine microservices as network function calls. If you diagram out how your data flows, how your concurrency works, you tend to see that a microservice is roughly a thread in a monolith. You gain not worrying much about mutexes or shared memory, but you lose on performance. Languages like Rust let you get close to having your cake and eating it too.
It is also a useful exercise for teams to consider "how big does my service need to get before microservices on Python scale better than a 64-core monolith in C/C++/Java/Rust?" Another good question, "if a monolith is stateless, does it scale as well as microservices?"
I've found this book (https://www.amazon.com/Mind-Illuminated-Meditation-Integrati...), at least the earlier stages to be quite helpful in regaining control of my thoughts.
Here's another way. As the worker, already working full-time, maybe you have better things to do with your life than working harder. Furthermore, the worker is probably thinking:
"If they want me to work more hours, why not pay me for more hours, including time-and-a-half overtime, per the law? Why offer a profit-share? Answer, mostly likely because the profit-share costs them less, and therefore, pays me less".
In that light, unless the factory management can explain how the extra hours they want people to work is likely to work out better for them then just getting paid for more hours, why should they accept?
> The evidence of people usually choosing to retire
The key word in that is "choosing". A huge number of people even in G7 countries comprise the working poor. They cannot, and likely will never be able to "choose" to retire. They work 40hrs/wk, often with two incomes and have no savings.
While we can debate the life choices of some of these people, it remains that working 40hrs/wk should not lead to an outcome where you can only just scrape by.
Instead of asking if some significant number of jobs will go unfilled because people are paid a poverty line level of income by the government, we should be asking:
"Why aren't we paying people who work 40hrs/wk a living wage?"
The decision not to work and live off of UBI is only attractive to people who are currently working many hours and earning about the same as what UBI is offering -- and that should give us pause.