They were really really bad at actually shipping products for a long time. I love all that ATG stuff: SK8, Dylan, all that blue-eyed object oriented optimism. But hundreds of man-years were put into all of that and Copland and Taligent, and they had nothing to show for it. Apple was so dysfunctional under Sculley and Spindler. People say Apple killed Hypercard but really what happened is people worked on it for years but it got bogged down in feature creep and focus switches, and they never get a functional version 3 out the door.
Tailwind requires you to learn CSS. It's not a framework, it just gives you access to the raw CSS primitives in a better way (IMO) than writing classes.
It does not. Tailwind requires you to learn tailwind which uses multiple different terms than what is in CSS (most of the times at least similar, but it is not the same). And it creates its own language to use more complex CSS features like [&_[not:(button)]]:bg-blue, this isn't CSS.
I'm still cleaning up after the unsupervised junior two years later.
To me, the definition of junior is someone who needs guidance. If you don't have a good process of defining tasks before they're worked on and real code review before things get merged, you are not set up to work with juniors, and hiring them is doing both yourself and them a huge disservice.
100% this; unfortunately also often seeing junior devs called staff after job hopping for 3 or 4 years never really learning anything.
Junior job titles are nearly as much of a mess as interviewing them.
Particularly in recent hot topics like AI the reality is you want both experienced and less-experienced devs. Most AI teams I see actually lack AI experience and keep falling for the same issues (like quickly getting to 80% working and thinking just a bit more data to 99.9%)
In the Company I work, I constantly find architects, senior and chief architects, who come directly from the university, without any real world experience… sooo nice to work with them
Yarh, I thought about this a lot when recently our electric cargo bike passed 10.000 kilometers. It is used, almost exclusively, to bring our son to school, 5km away.
This is a bit confusing to me because I am quite sure nearly everyone <10 YoE needs guidance one way or another. Similarly almost every dev needs real code review. Without code review everyone breaks things all the time.
Seems to me like "the unsupervised junior" isn't participating in the "Socratic method" the article discusses, but your experience does impugn the author's hypothesis that the burden of Junior Developers will drive out a better process ( as a forcing function) eg your "real code review" and "good process of defining tasks".
It might in a lot of places - if anybody even notices that there's a problem and if they then have the political capital to change it.
In this case, nobody really kept an eye on how things were being built, and the person was actually remarkably productive. I really don't have a bad word to say about them: they were given vague tasks and came back, for most of them, with working implementations. We're only a handful of people and everybody was busy elsewhere, but what little guidance and review we could offer was always accepted with much gratitude. They lasted about 18 months before moving to somewhere that offered more support, and I can't blame them at all.
What happened is predictable: things that ought to be in one place end up distributed in little pieces, and existing features got invasively modified to add new features even when that wasn't necessary. Poor separation of concerns, design patterns applied wrong, all of the stuff that over time adds up to a codebase that's hard to work with.
I think a lot of the refactoring we do would make a good book, actually, if any of us were the type to write about programming.
> I really don't have a bad word to say about them
...doesn't quite square with:
> I'm still cleaning up after the unsupervised junior two years later.
I can appreciate that misfactored code now helps "flatten the curve" and skirt under whatever deadlines you were respecting——even at the cost of a long tail of reactors——but its a shame that junior dev isn't around to learn from their mistakes, and also that they weren't paired with a more senior dev who could've coached them through those reactors at the time, enriching both the codebase and the human capital.
But if you're not reusing things as they are, at the site where you already have it, then you need a whole system to collect, clean, and sort it.
Additionally, the price of new materials does not include what it costs to get rid of them, nor does it typically include the cost of fixing what gets destroyed (like nature or human fertility) when its made or discarded.
Why constrain production to "painstakingly gluing back together" a broken bowl? And if reuse and recycling are desirable, why make bowls out of materials that are easily breakable and difficult to repair or recycle in the first place?
I think it's an interesting debate: what is this thing we've made? And what does its existence teach us about ourselves?
You're right that just going yes it is - no it isn't isn't so interesting, but this mainly stems from the fact that "intelligence" is a poorly defined, pre-scientific term. And really most times you're talking about about whether some X is a Y, you're not so much talking about X as about your definition of Y.
I think the thing is, with LLMs/Generative AI we see some aspects of ourselves, but not enough that we can accept that it is fully like us, hence the resistence. To me, the answer is clear: what is usually called intelligence is actually several different things, of which whatever it is an LLM does is one.
I once had Wolfgang Pauli's cousin use my checkstand at the grocery store. I noticed his last name because he wrote a check. When I asked if was "Pauli like the exclusion principle?" he got very excited and hung around for an hour just to chat.
