Suggestions
Ian Bicking
Professional Background
Ian Bicking is a talented software engineer based in Minneapolis, Minnesota, known for his impressive contributions to both Facebook Reality Labs and Mozilla. His career reflects a commitment to innovation and excellence in the field of software development, with a specific focus on prototyping and research in cutting-edge technologies. As a former staff engineering leader at Mozilla, he played a pivotal role in various projects, showcasing his ability to lead teams and drive meaningful results.
Bicking began his career as a Senior Programmer for Imaginary Landscape LLC, where he honed his skills in software development and began to shape his professional identity. He then transitioned to The Open Planning Project, where he took on the role of Senior Programmer, further solidifying his technical expertise.
At Mozilla, Bicking took on a series of increasingly responsible positions that underscored his leadership capabilities and proficiency in software engineering. Initially serving as a Software Developer in Mozilla Labs, he quickly progressed to roles such as Engineering Manager for Cloud Services and Hello, where he guided teams through complex projects and fostered an environment of collaboration and innovation. His tenure at Mozilla culminated in his role as a Staff Prototyping & Research Engineer, where he led initiatives that influenced the future of web technologies.
Currently, as a Research Engineer at Facebook Reality Labs, Bicking is at the forefront of technological advancement, working on projects that push the boundaries of augmented and virtual reality. His experience at Facebook ensures he is deeply entrenched in the current trends and developments within the software engineering landscape.
Education and Achievements
Ian Bicking possesses a solid educational foundation, having studied Mathematics and Computer Science at Earlham College, where he developed a robust analytical skill set crucial for his future endeavors in software engineering. He additionally pursued studies at Seth Godin's AltMBA, enhancing his leadership and management abilities, which proved valuable throughout his career.
Bicking also invested in his continuous learning by studying at Udacity, acquiring new skills and staying updated with the latest in technology and software development. His commitment to education reflects a lifelong dedication to personal and professional growth.
Achievements
Throughout his career, Ian Bicking has achieved significant milestones that underscore his expertise in software engineering and project management. At Mozilla, he successfully spearheaded the Firefox Screenshots project as Tech Lead, which not only improved user experience but also showcased the potential of developer-driven innovation. His technical leadership was key in developing products that resonate with millions of users worldwide.
His contributions continue to impact the realms of software engineering and technology, making him a sought-after talent in the industry. Bicking is also known for his collaborative approach, emphasizing the importance of teamwork in driving successful project outcomes. As a family man married to @potteryblog and a proud father, he balances his professional commitments with a rich personal life, inspiring those around him with his dedication both at home and in the workplace.
Highlights
My take on the Google AI image generator controversy, and bias in AI image generation in general:
When you ask for a generative creation (image or LLMs) you WANT the AI to fill in a ton of details. Some of those are fine: backgrounds, textures, expressions, etc. Some can intersect with societal issues like race or gender.
LLMs can be vague, using gender neutral pronouns and can avoid specifying more than was requested. But image generators must be concrete. They MUST fill in every detail. In both cases each creation is done independent of any future or past creation.
If you ask for a "mugshot of a criminal" then the image generator must choose a race. And it can't be "representative" because (a) that doesn't mean anything (representative of what?), and (b) it's making one image, not a distribution. There's no reason to choose a particular attribute 25% of the time; there is no "25% of the time" from its limited perspective.
When you let the image generator choose something like race you are asking it to do something it's not equipped to do.
One solution is to externalize these choices from the image generator. You can imagine adding a "race bit" to the input that says "if you have a character make it race X" and then roll some race dice for each generation. This is what it feels like Google did with its much-maligned image generator.
Another option is to give the choice to a better equipped AI. Dall-E does this by having GPT rewrite prompts. This still isn't good at distribution, but can use the LLM's superior knowledge to catch things like implied race given a historical instruction. This is less embarrassing, but if the race isn't specified it is still up to one of the AIs to make something up.
The last option, which I haven't seen, is to put this into the UX itself, not asking the AI to make the choice. That is, if you ask for a "mugshot of a criminal" then it could determine that (a) a person is being generated, (b) there's no explicit indication of race or gender, (c) there's no implied race or gender, and therefore the prompt is incomplete. In that case the system asks back: tell me more about the person in the image, until the above criteria is satisfied. Arguably this doesn't "remove bias" but instead moves bias from the AI back to the user. But because an unbiased generation is impossible (there is no neutral position) maybe that's good enough.
We reached an internal milestone with a #GPT-based content production tool I've been working on for some months at Brilliant.org
In the briefest terms the tool helps duplication and modify math practice problems for Brilliant. I should probably describe what we've done in full sometime, but for now I want to call out how important it has been to have a domain expert (Zandra Vinegar!) involved not just in collaboration or feedback, but in co-creation, something I think will be true for any serious LLM-based authoring tool.
We've all seen lots of examples of using GPT to create something of mediocre quality at very high speed. It's a cool trick, but certainly not what I want to work on, and Brilliant itself has a VERY high standard for its course material. The Content team at Brilliant does not make things easy for themselves!
GPT itself is fairly good at creating things of Normal Quality. It's been trained on LOTS of things of Normal Quality. The first issue is that it makes some mistakes, which can compound leaving you with something well below normal. But even if you address that, what if normal isn't good enough?
This is where you really need an engaged domain expert. Someone who can:
- Articulate their own creation process, which you'll try to replicate.
- Evaluate not just final results, but also intermediate results; these are intermediate forms of work that may previously have only been in people's heads.
- Work directly with the prompting process. I don't think working through other people is a tight enough loop, this person needs to put themselves into those prompts.
- Be involved in the overall pipeline design (at least at a discussion level); replicating mental processes is a good start, but only a start.
- Have strong opinions! You can't do this stuff quantitatively, it requires good taste, not a disinterested perspective.
Lastly, everyone involved has to come to the process optimistically. There's no best practices, no one knows exactly what the limits are, things go wrong all the time and it's not like a software bug, you can't just aspire to correctness.
