Jon Bauman

Project update! My application tracking extension is now doing fuzzier matching and injecting new information into LinkedIn (and other sites) to keep me from doubling up on applications. Next up: local storage and bulk import/export operations...

12

2 Comments

Its about solving the problem, not 'having AI' in the system. This is from last March, but the Wave 1 vs. Wave 2 distinction does seem to be playing out. Less 'generate me content', more 'synthesize vast amounts of relevant data and aid in decisonmaking or signal extraction'. https://lnkd.in/ehFBFC32 They don't talk about multi-agent systems here, but looking forward to more startups with a focus on leveraging agentic design patterns (https://lnkd.in/ed5rMmFe) to streamline real world workflows.

4

1 Comment

UNCOMMON INTERVIEW ADVICE: Ditch the Training Wheels --- TL;DR: Stop relying on the training wheels—autocomplete IDEs, solving problems within the Leetcode environment, all of it. In other words, simulate the interview environment as closely as possible when you practice. --- Story time: Back in my freshman year, my roommate used Notepad(!) to code his programming assignments. To me, this seemed wildly inefficient. Notepad lacked all the features that make coding smoother. His reasoning was admirable though: he believed that doing so would train him to be a better programmer in the long run. Bro was lowkey cooking, but I couldn't see the vision. So I stuck with Eclipse (yes, first-year programmer—I know). Looking back, I realize I was wrong. Enter the Technical Interview. In many technical interviews today, you'll use tools that resemble Notepad more than a fully decked-out IDE. Interviewers are increasingly asking you to run your code live. That's when your weaknesses can become glaringly obvious. If you've been leaning on autocomplete and code completion, the interview will quickly expose you. Here are a few of my own hiccups: 👎🏾Forgetting Types: Is it str, string, or String? Don't remember. You're coding in Python, but interviewer uses Typescript so they can't help you either. 👎🏾OOP principles and return signatures—Should everything go in a class? Should I create an instance to access the method? Without your usual tools, even seasoned coders can stumble over simple things. This is even more relevant now, with tools like ChatGPT and Copilot. While they make you productive, the crutches can hurt you in interviews. Also, reading documentation. Be honest—you probably don't read documentation. You probably make use of the Google -> Stack Overflow -> copy-paste pipeline. But in an interview, you don’t have that luxury. The best you get is access to documentation. So, you’ve got two options: 1. Master the language inside out 2. Get comfortable with documentation Another Challenge: Debugging In real life, you can step through code with a debugger or use the ol' classic "change something and run it again". In interviews, though, you need a systematic approach: 1. Identify how the output differs from expectations. 2. Perform sanity checks: Misspelled variables? Off-by-one errors? 3. Develop hypotheses and test them systematically. Lastly, Verbalize Your Thought Process What’s intuitive to you isn't always clear to others. Practice explaining your logic as you code. I've improved by using the rubber duck method—explaining my code aloud or to an object. It helps clarify your thinking and makes it easier to articulate in an interview. In Summary: ⚙️ Rely less on tools when practicing. 📄 Learn to use documentation. 🧐 Develop systematic debugging skills. 🗣️ Verbalize your logic while coding. Long-form version here: https://lnkd.in/dsG4VHrv As always, have a productive week!🫡

32

1 Comment

📣 BIG NEWS - I’m looking for my next full-time role in open source community program management 📣 I often focus on glue work that enables OSS communities, so to share a bit more about what I’ve worked on — here are some places you might know me from: ✨ I ran the brand recognition and community trust building efforts at Deis, an early Kubernetes dev tooling start-up that was acquired by Microsoft in 2017, where I worked with Matt Butcher to create The Illustrated Children’s Guide to Kubernetes! ✨ Phippy becoming the mascot for CNCF? I helped orchestrate the donation and release of the original book and characters under CC-BY in the spirit of open source! I also started off my professional speaking journey by presenting the donation and new book - Phippy Goes To The Zoo - on the keynote stage at KubeCon + CloudNativeCon NA ’18 in Seattle. ✨ With Helm, the Kubernetes package manager, I’ve been there since the inception — from its debut at the first KubeCon in San Francisco, to planning the inaugural Helm Summit conference in Portland and then hopping the ocean to Amsterdam for our Helm Summit EU event, to helping launch Helm 3, I’ve been managing our developer community efforts since 2015. ✨ With the Microsoft acquisition of Deis, we were brought in to help turn around Microsoft’s open source reputation. With that objective in mind, I worked on the Cloud Native upstream team doing community management for 10+ open source projects including Helm, Brigade, Virtual Kubelet, Open Service Mesh, Porter, and more! Additionally, I helped consult other teams within Microsoft, including Akri and Dapr, on how to execute on open source community efforts. ✨ For the last 1.5+ years, I’ve been focused establishing Fermyon as a leading innovator in the emerging open source WebAssembly ecosystem. From building out and running our marketing calendar, to scaling out our conference presence, to guiding decisions on community interactions, I wore multiple hats on our team driving marketing deliverables, with a community-focused flavor. If your team (or anyone you know) needs help optimizing how you do OSS (whether it’s marketing, community management, or program management), please let me know! Intros and referrals would be much appreciated. In the mean time, check out my personal website for more details: www.karenchu.online Please & thank you!

181

11 Comments

Spell correction has always been a task of interest to search engines. Every company that does search, usually has a spell correction team. And, most of them are in pain :-). Since 1990, researches have hit this problem from several directions. Yet, this problem seems to interest industry and academia, alike. These days, we (search enthusiasts) seem to be more worried about spell correction tasks that are entity rich, such as music artist name, album name, etc, rather than traditional generic dictionary text search. So, what do you do, to attack this problem? If you are at Amazon, you were using a Noisy Channel method. It is a classic Bayesian model attempting to maximize the P(c)P(t|c) where c is the correction and t is the typo. This was first discussed in 1990! Nevermind. You would probably be shifting to a BART encoder-decoder transformer model, soon. This new model has achieved a significant A/B improvement over the legacy method in a variety of metrics (CTR, play rate, etc). Moreover, the issues related to scalability and multi-lingual entity names are now out of the window, thanks to big data technologies. This is true with the mapping world too! I guess, an address query is more likely to contain a person name than to contain a random dictionary word. An interesting read is at the latest SIGIR proceedings. See https://lnkd.in/gBQuRGXR

14

This is a fun blog post about first steps with Rust -- and what looks like a legitimately useful tool!

22

From IC engineer to C-Level exec, the most effective people I've worked with have one thing in common: they break down and decouple decisions. Optionality, trade-offs, last responsible moment, one-way and two-way door decisions, slicing, MVPs, proof of concepts etc. are all techniques they use for breaking decisions down and getting them made. The best engineers did this when working on code. Rather than trying to decide on all the functionality at once they'd be able to say "I can break this story down into smaller pieces of value that we can get released to users fast" or "we don't need to deliver this piece of functionality now, we can wait until we see how user's respond". The best architects, product managers and business leaders do the same thing. It's a real skill to decouple decisions. It's a real skill to be able to defer parts of a decision to next or later (or even never) to enable faster movement and lower risk. I have always been impressed when I witness it. Often it's obvious with hindsight and sometimes its completely out-of-the-box and you would have never have realised.

60

3 Comments

It's hard to choose the right code reviewers. I just read the research paper below, detailing persistent gender inequities in who reviews code. In short: examining code reviews at Google over one three month period, the authors found that women were sent about 25% fewer reviews than men. The number is closer to 16% when accounting for factors like whether the person is actively writing code or whether they kept their job for the entire period. Even shorter: Coders send women fewer code reviews than they send to men. In my experience, this is only one part of a general problem with assigning code reviewers. As a team lead, I typically wanted code reviewers to be assigned so that: 1) The code ends up getting a good review. Reviewing is a skill, and some people are better at it than others. A good review has to be gracious, provide both positive and constructive feedback, and have a reasonable turnaround time. You also want thoughtful - ideally diverse - ideas and feedback. 2) More than one person on the team understands the code. You need this so that code can be maintained when one person is unavailable. 3) The code reviews are evenly distributed through the team. The good reviewers are often in high demand. But they can get bogged down with too many reviews. And you don't get to be a good reviewer unless you get some practice first. Like I said, that's what I wanted. In reality, these goals can be hard to reconcile. If you have one person writing a subsystem, and you really want someone else on the team who understands that subsystem, then you often have to pick a single person to do all of the reviews. That makes it hard to distribute reviews evenly. If you have someone who is a relatively new hire, and you absolutely need the best review possible, you may not give that hire a lot of reviews. That makes even distribution hard. And that's not even counting the stresses of having to worry about this while you juggle product deadlines and complicated personalities! As a result, teams tend to fall into very bad review assignment habits. There's the TL who is overwhelmed because they try to do everyone's code reviews. There's the expert who has a week-long turnaround time, but you *absolutely* need their review. There's that one developer who needs to be reminded every single day that they have pending code reviews. The article suggests automated reviewer selection tools that apply round-robin strategies can help deal with bias problems. They absolutely can - but those strategies just can't account for the human aspects of the review. My take is that code review is a bit like bug assignment - you need to assign reviewers for project code as thoughtfully as you assign the project itself. It's not something that can completely be done by a given developer in a vacuum - but it's also not a problem that a tool can solve by itself. https://lnkd.in/gTDxAhpG

27

15 Comments

A new table-format comparison post is out. How do the table formats support the streaming ingestion of row-level operations (insert/update/delete), such as ingesting CDC streams? https://lnkd.in/dFDs4Ah3

36

Okay; whereas one of my recent posts was risking "news of the duh", this one is unequivocally in that category, but still worth repeating for the people (executives) in the back: https://lnkd.in/g6Vitp3b The details are also obvious, but still worth reading as well. RTO is good for pressuring people through office surveillance, and for managers who feel compelled to closely monitor and micromanage (and by extension, remote work often decreases the perceived value for managers who only justify their value through monitoring and micromanaging). RTO was also bad for typically disadvantaged or harassed groups, because of course it is. The approach that works best, of course, if not doing mandates, but evaluating costs and benefits objectively, allowing real input from the people affected, and if anything biasing to a flexible and hybrid approach. You know, like all the people (except for a small but influential subset of myopic, fearful, and desperately value-justifying executives) have been saying since employees started being forced to go back into offices.

1

It was hard, but we now have a primitive at Gadget that lets us do absolutely 0 downtime atomic changes to an application's structure or data under the hood, with 0 requests dropped. I call it "request catching" but it was inspired by this Braintree eng post I read long ago For stateless workloads like serverless functions, 0-downtime deploys are pretty easy. You stand up the new one next to the old one, use a load balancer to start sending requests to the new one, and slowly stop sending requests to the old one. But for stateful workloads, it's much harder. You can't just start a new Postgres and send some queries to the new one and some to the old one without lying to somebody about state. If you want to be consistent, there has to be one source of truth. Fancy DBs have quorums for this, but PG doesn't. If you want to be consistent, you're effectively forced to have some tiny-but-real window of downtime in between draining the old one and starting the new one. That said, there's nothing forcing you to return errors to clients while that is happening. If your infrastructure supports it, you can pause requests while this changeover is happening under the hood, and then resume them once it is over. Clients will notice a longer request that normal, but it will be served like normal and they'll be none the wiser! What's required to do this though is a deep deep integration between the load balancing infrastructure and the thing doing the database deploy under the hood. We've built this up using a distributed locking tool, where all requests start by taking out a shared lock. When we're ready to do the maintenance under the hood, the maintenance workflow takes out an exclusive lock, blocking all requests from proceeding. The workflow does the atomic change it needs to make knowing it has exclusive access which means nothing will change under its feet, and then releases the exclusive lock as fast as it can so those requests can proceed. As an optimization, we only check the lock on the request path if an app is marked as near a maintenance window. This is only possible because of Gadget's architecture where we bundle together the load balancer, the request processing layer, and the database access tier such that we can reliably intercept all requests and all database transactions and do this lock checking. Its these nasty, in-the-weeds details that make me so proud of Gadget -- we can do world-class engineering stuff under the hood on behalf of all our apps without them ever noticing. If you're interested in doing this on your stack some OSS tools have the primitives you need! We use nginx for our load balancer, Temporal for the reliable workflow execution and we're currently using postgres advisory locks for hte locking. I think the Braintree post has been lost to time after they got acquired, but @simonw has a great post on the subject here: https://lnkd.in/eZmiktGT

51

This is a great video about how our personal ideology impacts the way we process data and information. For me, it shows the importance of fighting against populism and "framing" in the media and teaching our children in critical thinking. https://lnkd.in/eXQdB4fR

2

My (not necessarily original) personal weekend thoughts on the Open Source Initiative's version 1.0 of the "Open Source" AI Definition. Special shout out to the Software Freedom Conservancy's position. Their write-up is much better than mine, but that's a very high bar I'd have to set for myself :-) https://lnkd.in/evRtz3BQ #OpenSource #OpenSourceAI #AI #LLMs #DigitalSovereignity

4

I was reading one of the 2 newsletters I follow - The Grappler's Diary on Substack - and the author (Chris Wojcik) pointed out one of those "well, yeah, of course" kind of ideas that made me stop and think for a bit. Wojcik pointed out that it takes more and more effort to reach higher levels of skill in jiu jitsu. This is of course true of any skill. I've certainly seen that with programming. The easiest and biggest leaps are at the beginning. Going from zero to your first working program is pretty easy. Becoming a true professional developer takes years. Continuous improvement takes introspection, feedback, seeking out training and education, and lots and lots of work. And the noticeable improvements these days are small: cleaner code, improved readability, and better organization. Little things that matter. And the more time I spend as a "programmer" the less I write code and the more time I spend on related things: technical design, code review, stakeholder relations, project management, and more. Just as you get more skilled in martial arts, the more time you spend teaching, coaching, and advising, and the less time you spend getting beat up by kids.

7

5 Comments

It seems that with C/C++ -> Rust, specifically, you could do this by comparing the output compiled code as one of your verifications of correctness for ML learning This is something that e.g. copilot doesn't do - but it'd be straightforward to do so when doing training The expectation would be that the compiled rust code should be equivalent to the compiled C code, i.e. the assembly should be semantically no different As the ML learns, it may end up doing some funky rust code simply to get that to match - but that's probably a good thing, as this is the part that would require some manual intervention & you'd at least be guaranteed equivalent behavior

1

> "Note that different people tend to be drawn to different ends of these trade-offs. For example, TPMs typically are drawn to the “control” side and prototyping engineers are typically drawn to the “autonomy” end. This means that people will have their ego attached to one end of the trade-off, making the debate — especially if it frames the question as a binary and not a trade-off — somewhat emotionally charged." Leading a team can be especially tricky when team members hold strong, opposing viewpoints. The key, at least in my opinion, lies in prioritising a collaborative approach that emphasizes small, iterative steps, regular evaluation, and a shared goal of creating value for users/customers, not winning internal debates.

4

One potentially really good use for AI (for the rich person who wants to contribute back to US society): a model which asks for someone's opinions on general topics, and then correlates that with all available data for election choices, and fills out a sample ballot for the person based on the data. Each item could have a "drill down" link, to explain the available trade-offs, and why the option was selected. Rationale: A lot of voting is inefficient (in terms of "selecting the best option per people's desired outcomes"), because voters are bad at correlating large amounts of data, and propaganda people are good at confusing people and misrepresenting causal actions. But ML models are good at the former, and if trained properly, effectively immune to the latter. My assumption is that most voters/people are generally well-meaning, and trying to do the "right thing" for the country, but that's increasingly difficult in today's world of disinformation and propaganda. An unbiased model which aligned suggested choices with desired outcomes and trade-offs, based on actual data, would be potentially tremendously beneficial for getting better outcomes from elections in general. Note: This would not be an easy problem to solve by any stretch... but it could be a really positive change, imho.

1