dbshapco

I feel like any argument that begins by asserting a dichotomy is almost certain to be circular and will proceed as if the dichotomy were a fact rather than an unproven hypothesis.

I don't believe there is a dichotomy, or even a spectrum of developers, but a complex landscape. Of course, that is also an bald assertion, but on a weaker claim, and no less valid than the original assertion.

That said, independent of assertions about developer classification, in my experience there is a clear connection between the quality of the software and the quality of the product, and I've often see evidence of poor quality software compromising the product and user experience. Poor quality leaks out. Remember BSOD? Maybe not.

I've become hesitant to unleash coding agents simply because the code base ends up looking like the victim of drive-by coding, littered with curious lambda functions, poor encapsulation, etc. The only thing I use coding agents for is exploratory and throwaway code, like one off scripts. I love coding agents for all the ancillary work, I protect the critical path like mamma bear her cubs.

Coding agents make all the second order work easier so I have more bandwidth to focus on the critical parts. Again, software is a landscape, but at least for my work I can't abdicate parts to a coding agent and "works" is an inadequate standard. I need bullet-proof and unfailingly correct.

Token generation definitely produces a certain stream-of-consciousness, Kerouac-as-programmer style. As long as I don't ever have to maintain or modify the code myself, am not concerned about cost control (especially in cloud environments where I am billed by compute cycles), I am fine with quick and dirty and done. I sigh when I see what should be a six line change in my head balloon to 300 lines of generated code, revert, and write the six lines myself. Would take longer to write the prompt to get the coding agent to fix it than fix it myself. It would grind away for several minutes and burn up an astonishing number of tokens for simple fixes.

Anything linguistic the coding agents do well. Want to rename a variable in 300 different source files? I mean, it is overkill to be running a 200B parameter model to avoid writing the sed script I might write otherwise, but who am I to turn my nose up at my work being subsidized by investors? I don't think that economic model will go on forever.

Any higher abstraction is being cargo-culted from language. This is where LLMs are weakest, because they don't understand abstraction or encapsulation, only the artifacts as expressed in language.

Outside of exploratory and throwaway code, I use inline prompting to precisely target and scope changes, and then identify the cleanup and refactoring required to bring the code to acceptable quality. Although I do a lot of cleanup by hand as well. Rather than tell the coding agent that a lambda function wrapping a one liner that is used in one place in the code is dumb, I'll just remove the lambda myself. The coding agent can't adopt and generalize lessons from code review comments the way a human software engineer can -- I am forced to burn tokens every single time to get it to dial back its insane love affair with lambda functions. Again, not a big deal while costs remain subsidized.

Operations and maintenance overhead in the type of software I've written through my career dominates over programming cost. Telecom, aerospace, e-commerce, etc. Systems are long lived. Outages are expensive. Regulatory compliance is a large factor. I've worked in shops with 70% cost overhead in operations. A $50K a month cloud compute bill can be reduced to $15K. There's usually some low hanging fruit and poor quality software doesn't account for all of this, but it is a significant fraction. Like a poorly written termination condition in a container that essentially was a busy wait burning thousands of dollars a month doing nothing (true story).

I am currently writing a trading system, and can't afford to hallucinate a bunch of bad trades. Like the developer landscape, the software landscape is complex and not uniform. So I will concede there are probably many types of software outside of my own experience that can be implemented largely by coding agents. Low consequence. Marginal operational overhead.

I might assert that coding agents forte is autogenerating technical debt, but then I am just being a wag. Less waggishly I would say use of coding agents is subject to engineering judgement, like any tool. Who is going to read that headline or give it a billion dollar valuation?

I'm agnostic, but ...

"And for this cause God shall send them strong delusion, that they should believe a lie: That they all might be damned who believed not the truth, but had pleasure in unrighteousness."

For a more modern take, paraphrasing Hannah Arendt.

“The ideal subject of totalitarian rule is not the convinced Nazi or the convinced Communist, but people for whom the distinction between fact and fiction, true and false, no longer exists.”

We live in a an age where for many media is reality, uncritical, unchecked. Press releases are about creating reality, not reporting it, they are about psychological manipulation, not information.

> As we've seen at a national scale: if you just lie lie lie enough it starts being treated like the truth.

This actually happened in reverse with the spread of social media dynamics to politics and major media. Twitter made Trump president, not the other way around.

* No LLMs were harmed in the making of this comment.

When I was in university I took a lot of courses in management science, which is basically a lot of applied psychology, and learned a lot of stuff like this.

Then I went out into industry and watched as all these principles about managing employees effectively were ignored, or at best received lip service.

It led me to the conclusion that actually effectively managing employees to motivate better performance wasn't a priority. Not in the top ten anyway.

Most corporations and therefore managers operate using resource extraction principles. How do I extract maximum labour from this resource at lowest cost?

The 'R' in HR always bothered me, and others judging by the companies that used nomenclature like 'talent' or 'people'.

However that was whitewash. Underneath the nomenclature resource extraction continued unimpeded.

The irony being that treating people like resources is counterproductive and hurts performance.

Companies extracted the illusion of more resources, more hours, while productivity largely plateaued or decreased.

Somehow corporations expected to hire smart people, smart enough to do an intellectually challenging and technical job, and not have them do the math that the additional pay for performance generally amortized lower than the hourly rate, and that by doing more employees were actually lowering their effective hourly rate -- i.e. discounting labour for the employer.

The wag in me would observe the reason companies were so eager to portray everyone as family is that's the only model where this is marginally acceptable. Family taking advantage of family, like a family farm. Working more hours to get paid less certainly doesn't work as a business model for the employees. They'd be better off with a second salaried job -- and there were apocryphal stories about employees doing actually that, hanging up a coat on the door hook, throwing a newspaper on their desk, then leaving to go to their other job.

This is all observational and anecdotal however, but over a three decade career with a dozen plus companies, some of them Fortune N (where 20 <= N <= 500) in both contractor, IC, senior leadership and C-level roles.

The power of narrative made personal. If we aren't plucked chickens we are storytellers. The venue and media have changed, from oral tradition around a fire to photons sliding down fibers and fingers dancing on keyboards.

Narrative is a powerful and primitive force for humans, how we've always sought to impose structure and sense on events, from history to religion, to the mundane everyday and the trip abroad. Our brains crave narrative and invent it in a vacuum or as the interstitial bond between disconnected random events.

We can now own our public narrative and mythologize a heroic and extraordinary existence divorced from banal reality of paying bills and waiting in queues and going to the washroom and changing lightbulbs. Only the highlight reel makes it to prime time.

Social media are campaigns to seize control of narrative, to bring structure and synthetize relationships, to make sense of the world.

Predates print and electronic media, predates recorded history, a paradigm shift through Mcluhan's lens (always preferred his precursor, Innis).

Fascinating on a meta level, this comment being an example of its own thesis.

<rant> Swiping felt like the death of dating apps. Dating has always been a numbers game (the more potential partners one interacts with and dates the higher the chances of forming successful relationships). Modern dating apps convert human relationships into catalog browsing, a simplified calculus of human affairs wired to a cash register.

All my LTR in IRL have started offline and with people I knew in some other IRL context. Online dating apps never led anywhere but the bedroom briefly then straight back on the app. That's just me, no knock on people who have formed successful relationships that started online. Or people who just want naked bedroom gymnastics. Or serial daters, or anyone for whom dating apps dynamics might actually work.

Would it be too cynical to posit dating app algorithms optimize around short term relationships to prevent customer churn? Users must be successful enough to continue subscribing to the platform but not so successful they cancel. Do we even get into OnlyFans 'creators' using dating apps as marketing channels (there are guides online instructing people how to do this, looking at you r/)? Is it too cynical to suggest that social media in general hijacked nascent online communities in the 90s in order to make the world safer for advertising? Anything grassroots and authentic was mowed down and paved over. It wasn't an online paradise, but it is now an virtual parking lot.

The major problem IMO is that the goals of the company (revenue) and the goals of the users (relationships) are misaligned. The companies are most successful when users are only marginally successful or given a proxy illusion of success, because that keeps the subscription revenue flowing. If two users meet and continue offline, bam, two users cancel (excluding poly folk). Companies exploit users' goals to bait them into subscriptions, trick them into surrendering private data, etc.

I feel this way about a lot of modern technology platforms. The goals of social media companies (adtech revenue) are misaligned with the users (community), so that these adtech nee social media companies are motivated to drive engagement even when there is a cost to online communities and society as a whole. Feeds of family and friends devolve into clickbait doomscrolls. Algorithms optimize on inciting rage, because rage drives engagement. It is a powerful emotion. Programmed by evolution us meatbags have our attention optimized towards potential threats. That rage spills offline into deeply divisive politics.

I've opted out of adtech. DuckDuckGo instead of Google. Last month I finally deleted my Facebook account after years of neglect. I'd only kept it to log on to third party sites but never actually used it for that even. I've started a broad retreat from much of the Internet and I don't think it is simple fatigue -- I've been online for over three decades. Monetization drives enshittification and it is has spread like a virus until most of the online landscape is infected. I feel that most sites and apps are only after my attention, my personal data, my money. 90% of the time if I want to look something up I go directly to Wikipedia instead of a search engine. I'm probably just going to pick Wikipedia anyway after I wade through all the ads and marginal sites in the search results. After all the paywalls. I use ChatGPT instead of searching for stuff like simple programming syntax -- sorry Stackoverflow, you were probably the least worst for years, but I'm relieved that AI is doing the work of grinding through dozens of pages to find a helpful answer.

I've subscribed to Coursera to fill the void so that if I am idle and pick up a device, instead of doomscrolling I'll learn something about machine learning. I've mercilessly cancelled most other online subscriptions, beating the lobster trap (easy in, hard out) and surprise renewals and the unsubscribe gauntlet (are you sure you want to cancel -- what about 90% off for the next 6 months?. I funnel that money into a monthly voluntary donation to Wikipedia.

I guess it comes down to ad tech burnout. Tired of monetization. Tired of algorithms optimizing on outcomes beneficial to corporations and even detrimental to me. I'm not seeking experiences online anymore, too many billboards in the way.

Writing this I realize my online experiences had devolved into a litany of crappy marketing tactics. It's almost funny that the first thing a lot of companies seem to think about with generative AI is automating customer service with chatbots, saving money by having less authentic engagement with customers. Predictable and perfect. It's also hilarious that all the content scrapers are screaming about genAI scraping their scraped content. It's the online content ouboros eating it's own AI generated tail.

This is what happens when we seek to monetize all human experience. We need new algorithms, new metrics, new gods, another drink ... </rant> #adtech #corporatesurveillance #monetization #trollingisthenewmarketing #notabot

The Internet has become a carrier signal for advertising.

Anyone actually recommend the book from which the article is taken? I also tried to read the wa v. ga blog post on the site to get a further sense of the author's approach, but the server returns an out of memory error (from a blog post?!).

I've been in Tokyo now 18 months, took private lessons twice costing about $2,000, and feel I learned 10 words. That's $200/word. I joke with people I stopped taking lessons because learning Kanji would bankrupt me. Japanese just doesn't stick in my older and very Western brain. It doesn't help that my office does business in English and one can get by in Tokyo with minimal Japanese and a lot of pointing and gesturing. The glacial progress becomes discouraging.

I tried Rosetta Stone. It takes the same phrasebook approach as the first textbook I was given, Nihongo Fun & Easy, which was neither. The textbook at least had short sidebar discussions of grammar and somewhat useful phrases. I had no idea where I'd get to use the phrase "The children are swimming," that Rosetta offers.

The 8020 article was the first discussion of particles that actually made sense. When I'd asked teachers about particles before the answer was usually something like "Don't worry about that yet, just memorize the phrases." If the remainder of the book is in the same vein I'd pay twice the asking price. I flipped through parts of Nihongo Fun & Easy after reading this article and it suddenly made much more sense. I wasn't staring at a list of phrases I was supposed to memorize and slowly reverse engineer the language, but could deconstruct the basic sentences.

It's much easier for me to learn construction, and use the break down of other sentences to construct my own, even if the rules fail sometimes and lead me to construct sentences no native speaker would utter. That's the other 80% of language idiosyncrasies that takes time.

I don't expect to be fluent in Japanese any time soon, however moving past "sumimasen kore onegeihshimasu" while pointing at a menu item would be awesome.

Emotionally and quite illogically.

You can take the kid out of the ghetto but you can't take the ghetto out of the man.

I think it is the feeling that you can't mess up that this references and which persists.

My past was a single mother, deadbeat dad, welfare and food banks.

Now I have a comfortable six-figure income and have been employed for over two decades.

I still feel like I'm one bad break away from being on the streets.

If you have five architects in a room, you'll get six opposing opinions on architecture.

1) Culture must evolve with other elements of the company and at certain stages of growth and transition a company may need to intentionally hire to provoke and shape cultural change. Your change agents will be getting flak from many directions and your role may be to cover them and defend their advances.

2) This sounds like entrenching the status quo, risking stagnation. Every company I've ever worked at had some enshrined and virtually unassailable principles and practices. Celebrate the heretics and iconoclasts. It takes a strong internal center to speak out against groupthink and cultural norms. Make thoughtful challenge to the principles a principle (i.e. it cannot be a notwithstanding clause that supports blanket circumvention of other principles). Institutionalize periodic reviews.

3) The company and culture may change out from under some employees. An amicable and blameless split is best, including not blaming yourself. And every new hire constitutes some risk. So much hiring practice aims to minimize that risk without measuring or understanding the cost. It's easy to see and feel the effects of a bad hire, almost impossible to perceive the lost opportunity of a false negative.

Sometimes failure was not avoidable and there are no lessons to be learned to avoid similar situations in the future. Move on quickly, don't dwell.

4) Sounds like the Wobegon Corporation. Supporting cultural evolution is tough, often evolutionary and glacial rather than revolutionary and seismic. Your star performers in a micro-organization may be ineffective at the next level of scale because success then requires a different set of skills. Objective evaluation, effective performance and career management are tough problems made more so in a transitional company.

The culture that supported the company's previous stage needs to adapt for the next. Cultural change requires both people changing and changes in people. Elements of a company's culture will not scale. In organizations of which I've been part recently I've been promoting organizational Agility (capitalization intentional) in which Agile practices are applied to processes and structures, which adapt in response to internal and external forces. Cultural lock in retards progress.

WRT OP, these changes are necessary to support the company's current and continued growth, and I would avoid ascribing sinister intent. The company is changing in ways that don't match your personal work style, in which case it may be time to ask if you can adapt to this new reality (which may mean changing role or function within the company, rather than simply letting momentum carry you forward in your existing position) or look for a different company better aligned with your sweet spot (and do so in a way that is a positive experience on all sides, and don't wait to the point where you are acting out of frustration).

Change means new opportunities, possibilities to be teased out of your current situation. If a role exists or can be created that better suits your strengths, have a conversation with your manager and propose some changes, even as an experiment, "What if we tried ....", with an agreement to meet on a set time frame and evaluate results and pivot or course correct.

Vancouver spends too much time in movies masquerading as an American city to ever be iconic.

https://en.wikipedia.org/wiki/List_of_filming_locations_in_t...

With the current exchange rate we'll have another wave of movies pretending Canadian cities are American cities.

Shame, because aside from real estate prices, Vancouver is a jewel.

DE has meaning outside of Microsoft. I recognize it, and am not in Microsoft's orbit.

Generally it's one step above Senior Principal Engineer and considered an executive position.

That said, tech titles have not normalized as much as executive titles. The general progression I've witnessed is (with managerial level set):

- Engineer - Senior Engineer (Team Leader) - Principal Engineer (Manager) - Senior Principal Engineer (Senior Manager) - Distinguished Engineer (Director) - C[TI]O (C-Level)

Oddly there's no level set to [AS]VP positions. Engineering tolerates less hierarchy.

Also DE (and all tech ladder positions) are a recognition of sphere of influence over technical acumen as follows:

- Engineer (own work) - Senior Engineer (team) - Principal Engineer (department) - Senior Principal Engineer (corporation) - Distinguished Engineer (industry sector) - C[TI]O (corporation and broader industry)

YMMV

Yes, wear your opponents out, Thunderbolt.

It only takes getting up one more time than they knock you down.

The title is provocative (it's a numbered list, and a rant!) but the author would have been better served with "Seven Ways to Make Agile Better", for no other reason than taking a positive slant. Agile can be built on, its not necessary to tear it down to the foundations first. The article wasn't helpful or illuminating and full of strawmen -- the author is attacking their own definitions of Agile.

Full disclosure, I'm well in to my forties. I can pass for thirtysomething (a reference probably only fortysomethings will get) and once was mistaken for latetwentysomething by someone who was bad at guessing ages, good at flattery, or some of both. But please read the following with full consideration of the biases of age, from which youth is wonderfully immune.

Agile is essentially about shortening feedback cycles. The problem with waterfall was that work products were reviewed when 'complete', when change costs were high and commitments large. Decompose the work products into smaller chunks (backlog items and tasks) and review more frequently -- Sprints (every N weeks), standups (daily), pair programming (realtime). Every work product in a waterfall cycle, not just code, can be decomposed into smaller tasks -- design documents etc. can be constructed iteratively and incrementally, in parallel or sequentially (the latter meaning you can overlay Agile on top of waterfall) with tight and layered feedback cycles.

There are many artifacts, but dwelling on their structure and nature without reference to their essential role leads to superficial criticisms.

When something is broken in Agile always return to the fundamental question of how well the feedback cycle is working and how to fix it. Sprint reviews not providing value? Are they being used for feedback or have they become demo days? Has the standup become a daily status report?

This seems to weaken the captcha for bots, since a simple Google search for (for instance) 'do you know we are going' completes the sentence. No need to defeat the obsfucated OCR test.

If the goal is to keep out some idiots (since these tests will admit 33-50% of idiots who can at least complete the OCR test but answer the question randomly) but permit moderately sophisticated bots, mission accomplished.

Providing more context to the captcha solution in general strikes me as helping the bots, even if it confounds idiots.

Large parts of the Internet are simply a media clearinghouse, used to transmit and store information between parties with little value add beyond providing interfaces. Who controls the media and how it is structured, and how it addresses its audience, is usually the interesting part. Throw in some aggregators (which mine and organize the clearinghouses), some with search indices, and online shopping and I think we've this thing covered.

EMail (SMTP), Usenet (NNTP), Web {Forums|Blogs|CMS|etc} (HTTP). All made from the same stuff. But the interesting part of a book isn't usually that it's made of paper, nor is it interesting to compare two books on that basis.

Joel's abstaction is ironic considering it comes from the person who criticized architecture astronauts for excessive abstraction.

My experience is the opposite.

The simplest solution is harder and takes longer.

I think easiest or quickest is what is really meant in this formulation, but rarely do either of these result in simplest. I start with the former and strive to iterate towards the latter, because the former starts cheaper but ends up more expensive in the long run.

Simplification is an optimization.

Seattle.

An example from my code:

  /// - parse an HTTP input stream as XML
  ///   - requires a progressive parser (currently xpat, which is distributed with
  ///   Apache)
  ///   - the XML in turn is mapped to database operations, and the results
  ///   of the database operations used to create the HTTP response

In this specific case, the dashboard-page function is actually sequencing operations, not performing them (except for 5, and I'd wonder why that couldn't be moved to a separate function), and can be described as such:

  // - control the login sequence
  function login_sequence() {
    var user  = verify_login
    if (!user) {
       user = login();
    }
    var providers = collect_providers(user);
    var profiles = collect_profiles(user);
    var account_info = collect_account_info(user);
    load_templates(user);
    display_templates(providers, profiles, account_info);
  }

(Forgive the guess at what your code might look like.)

State may be passed between called functions, and used in control decisions, but state should not be grossly manipulated in sequencing functions (I do find with this style of programming that at high levels the state passed around tends to be large 'context' objects, rather than granular arguments encountered at lower levels). What I would NOT want to see in such a hypothetical login function is ALL the actual lower level code to do the login, collect the data, etc., so that essential higher order detail is obscured by the lower level operations.

A function's API comments do not need to repeat the purpose of called functions.

As I come up with API comments last, I usually think about them in reverse -- it's not 'I need to think of the single purpose of this function before writing it', but 'what single purpose did this function end up serving?'. Not being able to think of a decent answer for the latter is a possible symptom of sub-optimal decomposition. Then again, cutting blocks of code and pasting them into their own functions has become an instinct rather than conscious decision for me, so I'm effectively anticipating writing the 'single purpose' API comments.

At a certain level of detail I don't need to know the minutae of login, just that there is some black box function that controls the lower level details. And if I need to know the details, I break open the function and follow its call flow (or look at the autogenerated call graph in the doxygen docs or similar).

Having read a lot of feral code, I find the major indicator of quality is the static navigability of the code base (i.e. can I find my way around just by reading the code in an editor, without resorting to debuggers or autogenerated documentation), and having a level of detail structure, akin to the zoom feature on Google maps, is one method of achieving navigability (and partially the value of OO techniques). So it's okay to have functions/methods that simply sequence or aggregate calls to lower levels, and to describe them as such.

It was mentioned elsewhere on the thread that debuggers are useful tools in understanding a code base -- and I do often find myself setting breakpoints on code because it's near impossible to understand how particular functions get invoked by just reading the code. Then examining the call stack at the breakpoint I see that event loop called the network code invoked some code to read a database, which called into some code to instantiate widgets, which called back into the database code, which called the code that calculates order totals and tax, which called the widget code again to update those fields, all of which goes 30+ levels deep.

. . . and one of the plenty of good reasons being producing API documentation automatically via javadoc, doxygen, etc. Having the API documentation source and code live together is a big win. It's easier to maintain the inline documentation so it doesn't go stale. I hate being forced to go read code when I just want to use an API (I'm looking at you, Dojo :-/ ).

One of the first things I'll do encountering a feral code base is run an automatic documentation generator over it, even if there are no API comments, because many will produce at least some level of documentation from pure code, including cross references, a type index, call graphs, type diagrams, etc. This can be especially helpful when the code is poorly organized, and trying to trace simple program flow in an editor means navigating a dozen modules manually. Doxygen, for instance, will produce hyperlinked program listing, so that I can use a browser in a natural fashion to navigate the code structure and program flow. The browser can maintain virtually unlimited context, whereas my brain loses track of where I am once I'm seven levels deep in function call nesting.

Some IDEs and UML tools also are capable of reverse engineering documentation from the code base. The Togethersoft tools used to be excellent at grinding through code (and may still be, but I haven't used them in years).

RE'ed documentation of feral code can reveal how well (or more frequently poorly) the code base is structured, and identify key areas for architectural or design refactoring (if that luxury is possible).

In writing my own code, I decompose until each function or method has a single purpose (f() does X, not X & Y & Z!), and therefore the API documentation suffices to document the code itself. Rarely do I write a comment inside the body of a function or method. That happens when I re-visit the code, and discover that it's operation is non-obvious. The non-obvious stuff tends to be the tricky stuff it took some time to get right, and so it doesn't get mucked around with, and such internal comments rarely go stale.

I wait until re-visiting the code because authorial bias (my code effectively become's someone else's after several weeks, sometimes faster :-) ) obscures what is and is not obvious. I used to over-comment from a tendency to perform a mini-brain dump in comments -- but the knowledge required to WRITE the code (this is what I was thinking at the moment) is no reliable indicator of that required to READ the code (this is what _you_ need to know).

(I've theorized that having someone else comment the code from the start, just like having an unbiased tester, could make for better comments -- wherein the commenter is also necessarily a code reviewer as well. I've never gotten any of the places I've worked to agree to 'cross-commenting' as a standard practise, but most love worthless, perfunctory desk-checks prior to check in.)

To avoid comment churn, and because I refactor aggressively when creating brand new code, writing API comments is the LAST step in coding.

Finally, I developed a habit of writing comments exclusively in point form, because context switching from programming constructs to proper English grammar broke my flow. The point form comments feel like a miniature brain dump, whereas otherwise I'd pause to think about how to put the information into a proper sentence, and then make nice paragraphs, and suddenly I'd be channeling me from 7th grade compsition class. It's also easier to scan and digest comments as point form notes.

That's what I do, and I leave it at that, because telling someone else how to code is like telling them how to raise their children.

tl;dr version

- at least write API comments, pls

- doc generators (and other tools) sometimes are a great way to RE docs for feral code

- write comments in point form

- write API comments as the FINAL step in coding

- try to remove authorial bias from comment writing

At least nobody is making movies and songs about Twitter. Endless references in popular media, yes. Songs and movies, no.

"Breaker, breaker, looks like we got ourselves a convoy."

It all depends what books you read -- say if you just read programming books and no theory, which tends to be drier and less interesting because the pseudo-code examples, if the book even has them, won't compile directly.

Which is what university does. Picks the books. Then tests to see if you really read and understood the material. Plus you can go to lectures if you like to have the prof explain what's in the textbook with notes and examples on the blackboard.

I have a degree but low tolerance for the academic environment (nothing wrong with it, just doesn't suit my personality).

That said, I think I've met a few self-taught programmers during my career that read the wrong books, or more correctly never read the right books (since wrong books are just an opportunity cost). Some are great technicians but will never be engineers. Some have massive blindspots in their knowledge.

Some of the textbooks I read in university I would have never read on my own. So university forced me to read them via degree requirements. Not knowing some of that stuff would have been a handicap at times.

So there's university education for you in a nutshell: forcing you to read books you didn't want to so you'll know a few things you otherwise wouldn't have. Totally worth the four years and big bucks.

"[S]pecifically target candidates rather than to post a job ad. I would suggest targeting a company you think has great people[.]"

Like Rapleaf? Or was 'everyone but us' implied?

"There is not that much different between a dancer in a strip club and a startup or huge multinational corporation."

That's right. It's almost freakish how our inventory management system is exactly like pole dancing.