delimiter

AI, LLMs, and What Is Worth My Attention

2024-03-04T00:00:00Z

"True counterculture is always offline." —Daftsocial

Is AI a bubble? It certainly feels like the bubbles of yore, all of which had in common a viable technology that took center stage (e-commerce, peer-to-peer, Web 2.0, social media, crypto), a number of companies trying to conjure a market into existence, and scores of investors seeking to catch the next wave.

Most of these bubbles didn't really pop so much as slowly deflate without causing a industry crash on the scale of the dotcom bust of 2001. Of these, I feel like we collectively dodged an asteroid in crypto, which gave us the courtesy of losing steam before it could be jammed into every facet of daily life. That could have been bad!

Which is exactly what AI feels like now. It's got those vibes.

But I also feel like there's something there there. I'm interested in the technology, even if don't feel the need to delve into gritty details yet^[1]. I tend to "lazy-load my learning" and that's worked for me over a 25-year career^[2] It's always useful to be able to have a conversation about something that's transforming your industry! Or destroying it, maybe!

What do I think, anyway? Probably nothing that others haven't already said, but it's nice to write it down:

The NLP capabilities are astounding and I agree that no one seems to care very much about this! Ever since I first typed "hello" into my Commodore VIC-20 and got ?SYNTAX ERROR? in return I've been wondering if we'll ever really be able to say "Computer! Analyze atmosphere!" with Picardian authority and be understood.
Accuracy is going to be key to successful adoption. I think LLMs will get a lot more accurate, but the non-zero chance of hallucination is going to constrain where they can be used safely.
Which is why I think there will be an interesting market for APIs that shunt requests away to specialized subsystems. Let the LLM do the talking, not make decisions.
Get ready for a lot more very public humiliations as companies race to prematurely integrate AI into their offerings. I hope someone doesn't die as a result.
Efforts to integrate tone and facial expression into NLP are probably already underway. There's so much more that goes into human communication.
Chatbots are boring and hackable.
Seriously, how can you trust tech that can be subverted by telling it to ignore its programming?
None of the above concerns will stop the FOMO. Get ready for more and more companies offering up their (possibly your) data to AI in exchange for income to offset falling advertising revenue. They won't be able to resist. Everyone from Wikipedia to Urban Dictionary to Everything² is fighting an internal battle, probably.
We should prepare for a future court decision declaring AI web scraping legal, due to some concepts of common public good and "to foster creativity" much like Fair Use but maybe without compulsory licensing like we have in the US with music.
I haven't even touched on image generators! Slurping up original art from blogs and webcomics to feed your AI feels like an even grosser ethical violation than text. That said, if these tools are to exist, they are best deployed by the hands of artists.

Finally, I wonder how these models will stay relevant? So much cool stuff happens completely offline. I wonder if LLMs will always be a few years behind certain trends because they'll have to wait for someone to write about them.

Here's a decent "jargon-free" explainer for LLMs. There are many others. ↩︎
I mean, I'm a front-end person. Also, I'm kind of bad at math? ↩︎

Links: Technical Debt

2024-01-19T00:00:00Z

Today's prototype is tomorrow's legacy code. - me, probably.

Some of these via an intriguing Mastodon thread:

Simple Product Management Tricks

"Timeboxing is powerful because it approaches estimation from a different direction. Instead of 'how long will X take?', timeboxing asks questions like, 'what can we do in two weeks?'"

Tech debt metaphor maximalism:

"Tech debt, in its simplest form, is the time you didn't spend making tasks more efficient. When you think of it that way, it's obvious that zero tech debt is a silly choice."

Understanding the risk profile of your technical debt

"If we think of the time and effort to make changes to the codebase as the interest rate, we align to the notion of risk. If it takes a lot of time, a lot of effort, manual steps, etc., then it's also riskier and more error-prone. Remember: interest rates are an expression of risk."

3 Kinds of Good Tech Debt

"This mental model has helped me avoid spending foolishly and paying in maintenance for a system I couldn’t afford, and it’s given me a way to see opportunities to use tech debt intentionally. Here are a few cases where taking on tech debt helped my projects succeed."

Quantifying Technical Debt

"Having a discussion about technical debt is a luxury. Being able to talk about technical debt implies success. You cannot immediately blow up the product in question because people are using it and paying for it."

Catching Up With The Web

2024-01-16T00:00:00Z

It's weird and exciting to be writing again but it certainly feels like my blogging muscles have become weak and flabby from disuse. So think of these early posts here as me doing a lot of planks and crunches before committing to push-ups.

I'm probably not going to be writing many tutorials or deep-dives. I'll be deferring that to others with the time and inclination. If there's code here, it'll probably be in service of teaching myself something new and sharing it.

You Kids And Your Toys #

Have you ever looked a modern toys and felt burning jealousy? When I was young a toy dinosaur was a solid block of molded plastic. If it was multicolored, you were lucky. Today's dinosaur toys walk, roar, are multi-articulated, and some come with battle damage.

Being inside a Big Tech Company for a few years is a great way to lose sight of what's happening outside the citadel walls. Staying on top of this stuff is part of the job, but when the job focuses primarily on shipping it's common to stick with what you have that's already working. If this is you, don't feel bad. Some of the most senior devs I've worked with aren't leveraging "new" web technologies, including things that have been supported for years in most browsers, for various reasons.

I've been playing catch-up and there are a lot of really fun toys to check out.

Things I'm excited about:

Web components! #

Web components have been around for a few years but seem to be having a moment. This is probably the development I'm most excited about. Custom markup that extends existing HTML elements, which can be backed by JavaScript to add additional functionality.

I'm so on board with this. I always thought of jQuery as an excellent tool for progressive enhancement, but it wasn't often used that way, to the point where whole applications relied on jQuery to work at all. I've written a lot jQuery and React (like, a lot) and I far prefer the pattern of squeezing as much functionality our of markup and CSS as possible, then adding functionality with JavaScript after the page loads. jQuery made this easy, but it didn't enforce composability or reuse, and you needed to drag a full version of jQuery around.

Web components seem an ideal compromise, because they are JS-enhanced markup. Write the base component's minimal functionality with HTML and CSS, then decorate it with vanilla JavaScript and standardized browser APIs. Or you can throw caution overboard and write the whole component as JS, and use the custom element attributes as props. If you can resist the siren call of npm install you can pretty much reuse your component anywhere, with zero third-party dependencies!

I can't wait to try this out. I have so many ideas.

CSS advances! #

Where to begin? Container queries! Nesting without SASS! A mature CSS Grid, with subgrid on the way. Tons of pseudo-classes! Including :has() which is damn near magical.

Non-React JS frameworks! #

There are SO many. Vue, Svelte, Preact, Solid, Astro and more. Some of these have been around long enough to be mature alternatives to the React ecosystem.

JavaScript modules! #

Native JS dependency management without the toolchain. If you've been using Babel or Webpack for a few years you might not even realize that most Chromium and Webkit browsers support this now.

There's more that I could list but these are top-of-mind at the moment.

Stop Trying To Get Hired And Start Becoming Someone People Want To Work With

2024-01-04T00:00:00Z

The title of this post is paraphrased dating advice and I believe it's applicable.

I wrote the previous post in 2018 in response to a pattern I was seeing in interview loops. Candidates would generally do well, but when it came time for Q&A, they'd ask safe, sometimes deferential questions that were unlikely to reveal anything useful. It seemed like a squandered opportunity to engage with the interviewer as a peer.

Nonetheless I received some polite feedback on that original post, indicating that survivor bias and imposter syndrome are still robustly represented in the industry. Which is okay. This stuff is hard.

I've had some follow-up thoughts in draft mode for years, and the launch of this new blog seems like an ideal time to address a few concerns. I mean, I've been interviewing software dev candidates^[1] for a little over two decades, so what do I know?

"I don't feel comfortable asking these questions" #

I think you'd be surprised at what interviewers can and are willing to share.

Remember, you're trying to start a conversation, not perform corporate espionage^[2]. It's perfectly reasonable to want to know if you're going to be spending your time solving problems or putting out fires.

If you're worried about non-disclosure, just say that! "I'd like to hear a little bit about your tech stack, if that's permitted," or "if this topic is confidential, we can talk about something else." Any experienced interviewer should know where the line is.

That said, respect that line. Be interested, not nosy.

Oh, and if you're anxious that you'll offend your interviewer by asking these types of questions, let me just say you can't do any worse than candidates who ask softball questions or no questions at all.^[3]

"I'm new. How can I ask these questions if I haven't experienced them myself?" #

You don't need deep experience to have a conversation between peers, and you don't need to have solved any of these issues yourself. In fact, think twice before offering solutions. They should hire you for that!

By flipping the script, you're getting valuable insight into how the team or company operates. Just be sure you're actively listening and look for opportunities to ask follow-up questions. Maybe you've never had a job with an oncall rotation. Great! You're about to hear about what it's like here. Maybe you haven't had to gather requirements on your own. Awesome! You're about to hear how they do that here.

You're not doing anything different than your interviewers are by asking STAR-style questions. You're just leaving out that "tell me about a time when—" part.

And if your interviewer does ask about your own experience, you can always say something like "I haven't experienced that situation yet myself, so I'm interested how it's done here."

All of that said, you should probably work on having opinions. More on that in future post.

"I don't think I can keep a conversation going" #

Please don't be mad, but I don't believe you.

Why? Because you're in tech, and tech folk LOVE to talk. They have opinions. You've never debated the merits of some language or framework or Linux flavor with your classmates? You've never spent a team lunch discussing how to deal with some gnarly legacy code? Server vs. client-side rendering? "ɡɪf" vs. "jɪf"?

One of my teams spent part of an afternoon talking about whether one should ever put comments in their code.

You can do this because you've already done this. Take advantage of this energy! Leverage the addictive properties of tech discourse!

Now you've found some common ground. You're no longer the candidate who crammed on CS fundamentals all weekend vs. the interviewer who hasn't thought about topological sorting since their own interview and is preoccupied with why the server cluster needs restarted every day at noon. Now you're compatriots, fellow travelers — peers, even!

By asking questions that imply you're interested in discussing and solving problems, you're signaling that you're not just keen to get a job, but you're someone they should want to work with.

And to return to the dating analogy: how do you know when a date is going well? Flowing, engaging conversation.

Mostly front-end, sometimes full-stack. Although it's tough to be only front-end these days, especially if you want any say in things like data contracts and APIs. ↩︎
A super-secret stealth-mode startup might balk at answering in detail. But then, they may not have actually built anything significant yet (and if they have, it could be bootstrapped with hot glue and duct tape). ↩︎
And if you're around long enough, you're guaranteed to encounter folks that radiate some truly toxic vibes. Better to discover this now before you accept an offer. ↩︎

How To Be More Interesting During A Technical Interview

2023-12-21T00:00:00Z

Originally written in 2018, revised for 2023, a year notable for Big Tech layoffs and industry disruption.

“Do you have any questions for me before we wrap up?”

This your chance to make a lasting impression on your interviewer. It’s an opportunity to show your prospective employer you're interested in solving real problems, not just in getting a job. That you care about the humans at the opposite end of the tech stack.

It’s also a chance to learn something about how your prospective employer operates. Maybe there’s a pain point you can help address, or a process gap you can help fill. Maybe you’ll see some patterns that indicate how happy — or miserable — you’ll be if you accept an offer.

After 20 years of interviewing candidates, the ones I remembered were the ones who tried to engage me in a conversation about things I cared about. Below are some conversation starters I jotted down from memory. Feel free to use them, and create your own.

What’s your worst day like here? How do you manage it?

If you could change one thing about your tech stack, what would it be? What’s blocking you from implementing this change?

What are some common pain points for your customers? Are you working towards solving them? Why or why not?

How do you respond to customer complaints? Do you have a system for customer-reported issues? How has that been working for you?

How does your team handle requests for new features? Do you have a process?

How do you evaluate new technology for use? What are your criteria for adoption?

I see from your source code/press release/company blog that you’ve adopted [a particular technology]. What decisions led you to that adoption? How successful has it been?

Tell me about your deployment methodology. Are you able to do continuous deployment? If so, how? If not, what is your release schedule like and what determines it?

How does your team handle code reviews? Do you have standards or criteria for reviews?

When was the last time your company or team had to migrate to a new tech stack? How did you approach this? Would you do anything differently now?

What’s one thing someone would need to know to be successful here?