I dont think this article stresses one point enough.
You only get to be "new" once, You only get to have a fresh perspective once. There is a reason that you're a bad judge of the "usablity" of your product. You already know how to use it. your numb to it's mistakes and flaws. New team members dont suffer from this!
The bigger lesson here is for the team, and its sadly between the lines! You can get a lot of insight based on what new people ask about, where they stumble and what they need real help with.
There is a reason that you're a bad judge of the "usablity" of your product. You already know how to use it. your numb to it's mistakes and flaws. New team members dont suffer from this!
One of the best things my company does is allow me to sit down on a chair next to the people who use my products as they use them.
I just sit there with a notebook and write things down, and talk to the users as they're using the product.
Once you start doing that, you understand that it doesn't matter how many terabytes of "telemetry" you gather, you will never understand how people use your product as well as actually speaking to them.
The tech industry really needs to get over its fear of other human beings.
Early in my work life I had a job on the UI side of things.
Watching people use your app behind a 2 way mirror was probably the most illuminating thing ever. Users from outside the tech bubble have a very different take from most of the HN set. It influences how the look at, use and think about applications.
You can watch 7 people DO the right thing and then tell you, out loud, that it sucks for the same reason. Every app is filled with problems like this. If you aren't testing with "inexperienced" end users you are likely missing a LOT!!
If you're yelling that they're using it wrong, you're doing something wrong.
This is exactly correct. The software should be adapted to the usage patterns of the users, not for developer ergonomics. If the two happen to align, that's great, but it's a rarity.
Yes, this, exactly.
Swizec recently wrote about "desire paths": https://swizec.com/blog/architecture-is-like-a-path-in-the-w...
Fully agree.
Early in my career, I ran these sessions.
This was even covered in our school. Test your program on your classmates, and then the rest of the school. This was way before smartphones though, it had to be in the computer rooms.
I wish all companies did this. Even better, record the experience.
It’s astounding how many UI developers never watch a real customer using their product. All UI is compromise, but you see a very different set of possible compromises when you watch someone (particularly a new user) use the product.
My favorite is the whole “let it be a user setting” compromise. If you don’t get the “correct” default, then a non-obvious user setting does nothing. And if you do get the default right, then you probably don’t need the setting.
Sometimes it's a "McNamara fallacy", where there's just too much emphasis/bias towards quantitative data.
I worked at a tiny self-funded startup once where we required new hires to update the documentation and processes to fix the problems they encountered during onboarding. That worked great with 12-15 people; not sure how it scales.
I worked at a MegaCorp, and we required all new hires to (1) teach the next hire our architecture, core user journeys, etc and (2) the new hire had to present their learnings to the team, standing with their (quiet) teacher.
Both of these steps were crucial. The presentation serves a ton of purposes, it ensures both the student and the teacher learn the material enough to present with a whiteboard, and the team can catch any mistakes or misunderstandings at a time when they'd have the most sympathy towards ignorance. It also is a good low-stakes way to force someone to present and get used to the team and talk to everyone in a formal setting. We also always ordered pizza + beer after too make it a "fun" (or at least casual) environment that wasn't too serious.
I tried to do this when I joined a new company. Problem was there were four other guys on the team, all of whom thought the correct process was different, not just from what was documented, but from each other's, and would go back and re-"correct" things after me.
I spent the whole 3.5 weeks I worked there starting fights and noped right back out.
We have done that at a few orgs that have scaled up to hundreds of engineers
I do this as a freelancer who onboards with new teams pretty regularly. I've only had positive feedback from sending PRs that fix or improve the documentation on my first days with a project.
You are only new once.
But I expect starting a journal like this, waiting for a list to grow, is also a great path to resensitizing oneself to all the potentially useful problems to solve.
Writing down something and then waiting is such an immediate, low effort/immediate reward (my list got longer!), but long-term high-payoff act, I think it can be easily relearned with a systematic practice like this.
I like the continuous separation of recognition and recording, from the downstream progression: Create a map (see), take time to study it (learn), form a party of the co-concerned (lead), before running off into the forrest.
Really comforting
I recently interviewed with a mega-big bank for a role that I 'got it'/I have the 20y of experience on the thing. I've talked to 4 people. I usually ask "what are the 3 things that you want to see me do/not do in the first 6 months" (among other questions. Person #3 said "don't ask to change things, observe for the first 12 months, and on the 13nth month raise your hand and speak up, not before".
I have been journaling like for (8 years). Both notebooks and Scrivener. I like Nat's journaling method. This way he avoids looking like a fool/jumping the gun, and he gives the time for things to unfold (or not).
This is exactly why i as a manger want to assign bigger projects on new hires. They have fresh eyes, and are not used to things we do just because we have always done them in a special way. It's interesting to see how they solve tasks, before they get used to the status quo.
I feel the same way. It's interesting how someone new to something tackle issues compared to yourself that has been doing things a certain way for so long. I've definitely picked up new skills just by watching less experienced developers use their own way to handle issues, and I make sure to let them know when they've inspired or led to my own gain in knowledge. I think it's a positive feedback loop that strengthens a team.
And then grab some people off the street to test your product. Let them play with your app. Treat them to lunch, interview them while eating :-)
You can get part way there with a sabbatical.
I recently took a 2 month break from work, and coming back I had plenty of these moments too.
Things that previously I thought were smooth weren't. Processes that I thought worked fine seemed to crumble. The overall application speed felt like treacle where previously I thought it was fine.
Sometimes a fresher perspective on the state of things is important, although unlike a new team member it's not doing me many favours pointing some of this stuff out.
Being a new team member is also an amazing opportunity for being able to speak freely about problems and point out that the emperor is nude.
It's not always the staleness of perspective that is the problem. Often it is your personal opinion (the perspective itself) that is both right and wrong.
I think the greatest mistake in software design is the pattern of structuring UI/UX around assumptions. Every assumption made in software design is a demand for the context that that software will be used. The reality is that context will always be fluid, and that it will often contradict itself. Free software can be liberated from its assumptions, but it requires redundant work for every unique contextualization.
https://en.wikipedia.org/wiki/Shoshin
But it's not us we just keep being let down by these new hires. I don't get it, how are they all stupid or lazy?
- Many a myopic org
I believe in the First 100 days phenomenon but I vigorously ignore any bullshit about fixing major tickets within n days of starting at a company. First of all many places I’ve worked were deluding themselves about the feasibility of doing this. Their onboarding process inhibited any such wishes when I started there.
I’ve been doing user studies on developers for more than a dozen years. It got a lot easier once screen sharing was more common. But letting new hires or devs with brand new machines twist a little when going through the setup docs and taking notes. Or doing similar when I’ve made a major change or introduced a new API to see what fresh eyes see that I did not (or in some cases, that which was true but no longer is).
If at all possible I task them with fixing the docs. First, as you say, they don’t have the Curse of Knowledge, so how they word it will reach down the ladder behind them. Second, if what they say is completely wrong, then I can correct the miscommunication easier when they’ve used their own words to repeat back what we discussed.
Making edits to the wiki is usually the first contribution I want to see from a new hire. Even if it’s just untangling a run on sentence.
Ease of onboarding and usability for new team members was very important during ZIRP when headcounts were exploding and people were changing jobs for 40% raises all the time. I'm not sure it's going to be such a useful optimization target going forward.
It ia true that everybody can fall into that trap. Becoming blind to weird quirks of your own product is the equivalent of a senior professor becoming blind to the fact that the stuff they need to explain is hard to fresh students.
The thing is, that not all people suck equally bad at this. A big part of it is to actually care and be empathic enough to put yourself into the shoes of the un-initiated. Two people who both have used the Bash shell a million times might have a completely different understanding of what makes it weird and unintuitive to someone starting out, even if both had trouble when they themselves did.
Looking at things with a fresh mind is a skill one can get better at, just like you can learn how to look at actual light and objects to draw what you see instead of drawing what your brain tells you you see. It is a hard thing to learn and it is something that can fail you even once you became somewhat decent at it, but every good educator needs that skill.
I think TFA is more stressing that this only "new" once perspective can lead you to exclaiming WTF a lot to all your new colleagues - thus giving the impression of being a loud complaining nuisance.
Instead, by writing it down and NOT expressing it just yet, you give yourself time to learn the lie of the land and why things are the way they are; to orient yourself in the workplace. And when you are comfortable, settled with accounts/permissions/authorisations, you have a nice list to move on.
The team is then more likely to think you are being helpful rather than a popup muppet exclaiming "WTF is that!" all the time.
A year ago, I got hired at this place that is, shall we say, less than stellar at teaching their new hires about their custom, specialized code framework.
Of course only new hires notice. Maybe only new hires who have been enough places to realize that it doesn't have to be this hard...