Profile

Cover photo
Verified name
Ian Bicking
Works at Mozilla Corporation
Attended Earlham College
Lives in Minneapolis, Minnesota
9,178 followers|1,346,079 views
AboutPostsPhotosYouTube

Stream

Ian Bicking

Shared publicly  - 
 
Once it became clear that the web was the future, did the web get taken over by those it supplanted? We tried to clean up and replace the apps with the web, and lost our way... now the web begs to be an app platform and chases someone else's dream, and has lost track of the "web".
11
1
Ian Bicking's profile photoJeff Bailey's profile photoRohit Patnaik's profile photoPaolo Casciello's profile photo
3 comments
 
"And then someone invented a shitty little computer.  It had the screen resolution of a potato, the responsiveness of 1978 Honda Civic that's never been serviced, and the battery life of a Sony Discman in the hands of a teenager."

You know that's exactly what mainframe jockeys said about the Apple II, and the IBM PC right? 
Add a comment...

Ian Bicking

Shared publicly  - 
 
I'm somewhat pro-meeting, which maybe puts me at odds with the cultural norms of developers.

I think I realize some of the problem.  Meetings tend to be called by managers.  Managers have management goals.  Process, deadlines, coordination, etc.  The developer sits around in case they provide some important input on one of those topics, or to give status, or to commit to a deadline.  Nothing in that kind of meeting helps the developer's work.  And the developer tries their best to withhold, to protect their own work, but also to protect the project which actually needs that output.

In a developer-oriented meeting the topics would be decisions to make, architectural choices to consider, noting places of tension where a creative solution could be helpful.  In a developer meeting it is reasonable to take some time to look at code.  To do a bit of research – right in the meeting – to answer a question.  To brainstorm ideas.  If a problem is hard, it is reasonable that everyone go silent for a minute and ponder the problem.

In The New Science of Building Great Teams (https://hbr.org/2012/04/the-new-science-of-building-great-teams) they discuss some evidence-based observations about communication patterns.  In it they suggest that high levels of communication lead to more productivity.  By developer sensibilities, very high levels.  But mostly peer interactions – developers interacting with developers.

I'd really extend this to all the people engaged in making the product, design, user experience, user research, development, probably support and other roles.  In an ideal model there would be dozens of meetings, as different sets of these people came together to talk about what is relevant to those groups of people.  These meetings would not have clear and firm agendas, the product is the agenda, finding the agenda is some of the work of the meeting.

It's easy to blame management for the unproductive meetings.  We're calling these snooze-fest status meetings.  But I'd turn it around: professionals shouldn't depend on management to initiate meetings. Sure management can try; I try to setup meetings I think will be productive for other people.  The Standup is the quintessential example.  But we know where those so often end up: as yet another management-led status meeting.  And it's a form without a clear purpose.  Who should be in the standup?  What should we talk about? When those things are defined by management we get management-style answers.  Even better than trying to fix the standup, keep it from being necessary: make the meetings that help everyone do their work, where the topic is always execution and not prediction or planning or status.

With Project Managers and other professions focused on planning there is a danger that we defer to the specialists.  But everything needs to be planned.  The next line of code I write has to be planned. Developers have to be planners, every one of them.
The chemistry of high-performing groups is no longer a mystery.
7
1
Aaron Hamid's profile photoChris Lasher's profile photoJon Schull's profile photo
2 comments
 
The goal of meetings "where the topic is always execution and not prediction or planning or status" is detrimental. Developers should be involved in meetings for requirements gathering, feature prioritization, and business analysis, not just for implementation. If you don't involve developers here, your product will suffer, not to mention your developers' morale since you remove their autonomy in determining what work they will undertake.

Meetings are critical, the key is to have a strict definition for what constitutes a meeting, and avoid engagements that fail to meet that definition. In Bridging the Communication Gap, the authors explain two criteria that make an effective meeting:

1. A meeting must have an achievable outcome that, when met, indicates the meeting is over. For example, "In this meeting we will determine which feature to drop from the next release," is achievable, and ends immediately after the participants choose the feature to drop. An allotment of attendees' time is not sufficient to have a meeting; a "meeting" that ends at the top of the hour because that's when the room reservation expires is not a meeting.
 
2. A meeting must have the right attendees. A sure sign you have the wrong people in the room is attendees lose interest and get distracted. If this happens, you do not have a meeting. Stop immediately, identify the the parties that would actually be interested, and schedule the real meeting. Inviting attendees to your "meeting" on the chance that they could be involved is an anti-pattern. YAGNH (You ain't gonna need her/him). Schedule small, short meetings with 100% engagement, not long meetings with 100% attendance.

I recommend Bridging the Communication Gap for more detail. http://www.acceptancetesting.info/the-book/
Add a comment...

Ian Bicking

Shared publicly  - 
 
Impostor syndrome: unconscious bias directed right back at yourself?
2
Chris Lasher's profile photo
 
+Jacob Kaplan-Moss suggests, at least for software development, impostor syndrome stems from the assumption that skill has a bimodal distribution, where a more rational assumption should be a normal distribution. https://www.youtube.com/watch?v=hIJdFxYlEKE?t=12m10s
Add a comment...

Ian Bicking

Shared publicly  - 
 
I came upon this article, Bookmarklets are Deadhttps://medium.com/making-instapaper/bookmarklets-are-dead-d470d4bbb626

Basically noting that Content Security Policies block bookmarklets.  This is something I noticed when I tried to smash TogetherJS into GitHub. There aren't actually that many sites with CSP, but GitHub notably does have it enabled.

Re-enabling some of that functionality, maybe in a more accessible form, is one goal I have in PageShot (especially: http://www.ianbicking.org/blog/2015/04/product-journal-building-block.html)

PageShot definitely doesn't satisfy every bookmarklet need, but it would be good enough for Instapaper.  Specifically it doesn't allow the bookmarklet to interact with the content, but it can allow third parties to read the content as the user read it.  And it wouldn't be hard to imagine a third party adding value to the content in-place, which is something many bookmarklets do, they take content and make it more pleasant or interactive or otherwise improve on it.

But it also enforces a separation by making a copy of the content, so that every bookmarklet isn't almost by definition a XSS (maybe a happy helpful XSS, not an XSS attack, but it's still XSS).  This is a decrease in functionality, but in practice I suspect it is fine – because bookmarklets aren't sticky (every page navigation disables them), they aren't very good for adding functionality to a live page.  And fiddling with live pages is hard to maintain.  But remixing content? Twiddling with the DOM?  These are doable things.
… we just don’t know it yet.
2
2
Ade Oshineye's profile photoJürgen Christoffel's profile photo
Add a comment...

Ian Bicking

Shared publicly  - 
 
"Mullainathan begins by establishing the idea that your cognition is limited -- you can only think about a limited number of things at one time, and when the number of things you have to pay attention to goes beyond a certain threshold, you start making errors. Then he explains how poor people have a lot more things they have to pay attention to. In the UK, we make fun of politicians for being so out of touch that they don't know the price of a pint of milk -- but poor people have to keep track of the price of everything they require."
In an outstanding lecture at the London School of Economics, Macarthur "genius award" recipient Sendhil Mullainathan explains his research on the psychology of scarcity, a subject that he's also wr...
15
4
Gloria W's profile photoThys Meintjes's profile photoJustin Walters's profile photoSatchidanand Haridas's profile photo
 
One of the most interesting talks I've watched in a while. 
Add a comment...

Ian Bicking

Shared publicly  - 
 
Another blog post about PageShot, Community Participation

Are there people who might be interested in participating? What for? What would make it more valuable for you?
Generally at Mozilla we want to engage and activate our community to further what we do. Because all our work is open source, and we default to open on our planning, we have a lot of potential to include people in our work. But removing barriers to participation doesn't make participation happen ...
1
Ian Bicking's profile photoEd S's profile photo
4 comments
Ed S
 
Thanks Ian. I think combating web rot is the obvious use case for me: we have archive.org and archive.is but something more immediate and personal could be useful.
Add a comment...
In his circles
796 people
Have him in circles
9,178 people
Antoine Leclair's profile photo
Sebastjan Trepča's profile photo
Mauzy Law Firm's profile photo
Narayan Seva Sansthan's profile photo
livreiro 88's profile photo
Kiran Samudrala's profile photo
silvance odhiambo's profile photo
Jeremy McMillan's profile photo
T iny's profile photo

Ian Bicking

Shared publicly  - 
 
A thought on how to add a REPL to an app or service:

Your REPL starts by creating a persistent connection to the app or service.  Could be as simple as a login and a cookie jar, or could be a socket open to the app.  Then the REPL starts a bash subshell.  In that process there are new commands for all the different things the application supports.  You get a full language and a sort of scriptability, but you don't have to implement anything beyond exposing commands.

I realize in some sense the subshell is just a way-too-fancy context manager or try/finally for bash.  But the idea of starting a shell session seems vague in bash.  And it's the session that makes the script hang together as a command language.
1
1
Aaron Hamid's profile photoLes Orchard's profile photoLie Ryan's profile photohari jayaram's profile photo
3 comments
 
How would you secure this if anyone can run any commands? If only trusted person should use this, why not just use ssh?
Add a comment...

Ian Bicking

Shared publicly  - 
 
I think there might be some benefit in avoiding the term "users" and instead saying "user".  "Users" is an aggregate, while "user" is a person – somewhat mysterious, but still specific.  With "users" it's easy to think there is an average user, even though a meaningful description of a user based on the aggregate at best describes a plurality, not a majority, and perhaps a small plurality.

I haven't thought about this save for one small sentence I am writing right now, but in that one small sentence switching from "users" to "a user" helps me remind myself that I am speculating about a person's experience, not a abstraction's experience.
11
Ian Bicking's profile photoChris Lasher's profile photo
2 comments
 
Perhaps you're looking for a persona? https://youtu.be/ESOaDiv3lXA?t=27m18s
Add a comment...

Ian Bicking

Shared publicly  - 
 
What does it mean for an organization to be humble?  (Not modest, but humble.) 
1
Ian Bicking's profile photoDavid Metcalfe's profile photoDavid Groos's profile photo
4 comments
 
It's not just metaphorical thinking assigning personality traits to an organization. The synergy occurring within a human social network and that within a human's neural network are deeply analogous. The emergent properties of each are recognizably similar. I've seen this as a teacher over many years. And while the leadership is usually the main factor in this, strong personalities in the group have significant influence, too.
Add a comment...

Ian Bicking

Shared publicly  - 
 
I endorse this: build a monolith first, then decompose into microservices.

Another argument that +Martin Fowler doesn't make, but I would, is a kind of reverse Conway's Law: the architecture of the software will be reflected in the communication structures of the team.  When starting a project you don't want to let people or groups go off and work in isolation.  

In some sense the peeling off of microservices is a natural maturing of a project, where you think about new aspects of the project in relation to how they are different than how the project is currently.  But when starting a project there isn't the shared understanding of the existing product, and you need to actively build that shared understanding.
Going directly to a microservices architecture is risky, so consider building a monolithic system first. Split to microservices when, and if, you need it.
20
8
Yavar Naddaf's profile photoDobes Vandermeer's profile photoTodd Ford's profile photoDerek Hohls's profile photo
8 comments
 
/sub
Add a comment...

Ian Bicking

Shared publicly  - 
 
Seeing Through the Net, part 3 of 4; he reflects some on computation here...
3
Add a comment...

Ian Bicking

Shared publicly  - 
 
Is it worth it to use Express when writing for Node.js?  I'm allergic to frameworks, but that doesn't mean it's the right choice to let a weird ad hoc framework develop in my code.  And Node.js without a framework can be kind of brutalist.
1
Shannon Posniewski's profile photoJustin Abrahms's profile photoMark Rosenblitt-Janssen's profile photoStuart Langridge's profile photo
5 comments
 
Yeah, it's worth it. Don't bother writing your own ad hoc mini version of express, which you'll end up doing. :)
Add a comment...
People
In his circles
796 people
Have him in circles
9,178 people
Antoine Leclair's profile photo
Sebastjan Trepča's profile photo
Mauzy Law Firm's profile photo
Narayan Seva Sansthan's profile photo
livreiro 88's profile photo
Kiran Samudrala's profile photo
silvance odhiambo's profile photo
Jeremy McMillan's profile photo
T iny's profile photo
Work
Occupation
Computer Programmer
Employment
  • Mozilla Corporation
    present
  • Imaginary Landscape
  • The Open Planning Project
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Minneapolis, Minnesota
Previously
Minneapolis, Minnesota - Richmond, Indiana - Chicago, Illinois
Story
Introduction
I'm a programmer.  I work in Mozilla Labs, where we try to figure out new ideas for the web and browsers.

I've been doing open source programming since sometime in college.  All my actually important contributions (and many projects) have been in Python: Paste, WebOb, WebTest, pip, virtualenv, FormEncode, MiniMock, and a bunch of others, quite a few of which no one else ever cared about ;)

Since moving to Mozilla, and because of events in my personal life, I've stepped away from most of those old projects.  Hopefully it will leave room for new projects, but I also find myself in a period of reinvention, moving from server to client, from Python to Javascript, and frankly I'm just older.  I remain dedicated to free/open source software; and while that is practical and has been professionally rewarding, I am more motivated by the principle and politics of open source than the engineering.

I work remotely out of my home, in the Powderhorn neighborhood of Minneapolis.
Education
  • Earlham College
    Computer Science and Math, 1995 - 1998
  • South High School, Minneapolis, Minnesota
    1991 - 1995
Basic Information
Gender
Male
Apps with Google+ Sign-in
  • 1941
  • Project Default Service Account
  • Adventure Xpress
  • Infectonator Hot Chase
  • AdVenture Capitalist