I keep a WTF notebook (2021)

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.

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.

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.

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.

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...

What about the tone bothers you? I've never read How to win friends and influence people. I thought the article is pretty well-written

You hit on the most interesting aspect from this. I will explain what I noticed and I’m interested in how this viewpoint lands.

First, the author is doing 101 new leadership stuff. I’ve done it, I’ve seen it done, there’s a science to it. I can distill the whole blog post into when taking over leading something (as an experienced IC, as a new manager, as an army officer, it’s all the same), take the first 30-90 days to not change anything, and just seek to understand how and more relevantly why things work. There are a mess of organization benefits to this, it would take more than a comment to explain why. But in short, ya this is how it’s done.

Second, engs have worked for awful managers, can’t often understand or exactly place why but they know their manager sucks. I can argue capably in thread about how often this difficult to explain “sh*ty manager” sense boils down to the manager not doing like tactically good leadership. In the same way as engineering is a taught skill, so is leading teams. Issue is only a few places teach it intentionally. Top of mind for me is the military, and senior exec training. There’s an actual science to it, full stop. You either get taught it by orgs that treat it this way, or you pick it up from a mentor who learned it somehow. Note - the author learned it this second way. This is really common.

Third, to work for good managers, you actually want to work for good leaders. Leadership is a tactical skill, the same way efficient lines of C++ are. Leadership tactical means tactically shaping and steering people to achieve a goal greater than the sum of the team’s individual parts. This full stop requires what in a certain light is what you point out - it’s a bit manipulative feeling. It’s using leadership methods to make people work together in a way that is effective. A lot of this is good EQ and stuff like the author maps out.

So, who do engs like working for? Often it’s working for technically inclined good people who go to bat for their team with external parties, shield their team from stupid stuff, resource the team to complete its goals, praise in public criticize in private, give good but not overly micromanaging guidance on where to steer things, recognizes and rewards performance, holds unperforners to a standard, and so on and so on?

Some examples of who knows how to do this but for the wrong reasons are people engs don’t like working for - to stereotype: charismatic jocks out of MBA programs who can know nothing about tech but know corp politics and deploy this stuff tactically.

Who do engs hate working for often - technical hires promoted into management and they hate/are bad at their jobs bc management != tech chops, as my above covered.

So, what that leaves is a scenario where teams are led by the occasional person that inherently knows good leadership chops, or more often it’s pissed off engineers who hate working for someone manipulative or incompetent.

To raise the collective industry odds that tech teams work for skilled and competent leaders, that leaves as the solution spelling out tactical leadership - how to do it, what it looks like, how people fit into it, like this blog does.

Pick your poison - more of the same, or good people who just need clear guidance learning from resources like this on how to run teams people want to work on? HN certainly complains to no end about the dynamic caused by not approaching leadership as a skill vs some nebulous thing people somehow know how to do.

Yeah, my first thought was "how often does this guy change jobs?"

Interesting take. Let's just say, one of these approaches sails through the promotion process, and one does not.

Not sure why this is bad?

Charge more.

You have to couple this with the strong ability to say no

The middle ground is learning how to be the helpful guy but also being able to say no when you don't have time. Not easy, but enforcing boundaries is an important skill.

I was that guy at my previous job, and had a much better experience.

For starters, at that company, I always fortunate to have a manager that had my back when it came to deflecting requests that didn't come from him or her. If a random person reached out to me with a request to do some non-trivial work that I either didn't have the bandwidth or interest to do, all I had to say was, "Sorry but I don't have the time to look into this right now. If you need this prioritized, please run it by my manager." 99 times of 100, my manager never heard from them.

The biggest upside to being the go-to guy for people across the department/company is that you get to collect acquaintances and contacts. It's a fun little micro-superpower. Extremely valuable when you need some bit of info from someone outside your team, or need someone to cut through some red tape to get something important done. It means I also have a modest network of people to hit up when I go looking for new opportunities. (This is how I have landed 100% of the jobs in my decade and a half of civilian employment.)

Removing technical debt and improving tooling is often a good way to add value. Sharpening your tools makes you work faster.

I've seen plenty of teams who didn't think they needed someone to evaluate what they're doing and just thought they needed someone churning out code.

If they'd had someone do the former, most of the time they'd not have needed the latter quite so much.

The existing team tends to be blind to stupid things they're doing. There's a period of time where the new guy sees things and thinks "wtf are you doing that for". Shout him down and you solve the annoyance problem and add him to the list of people who no longer notice the stupid things, or at least no longer try to fix the stupid things.

Maybe your team is only doing sensible things and all is perfect. Maybe you're blind to things that could be better. Heuristically, if you're writing software, it's not likely to be the first case.

My professional project moved to GitHub recently. It is terrible. The pull request / review system is borderline unusable. But already I can feel myself adopting clumsy workarounds and losing sight of how much better it should be.

This is essentially my note-taking strategy with Apple Notes and Notally (on Android). Life's too short to organize notes. I'd rather just jot down everything and rely on the reverse-chron and search to find stuff later.

The irony is that, while I know I have a treasure trove of amazing ideas, at my age I don't think I care enough to execute them like I would have in my 20s. Oh well!

I'm struggling to see how this relates to TFA. It sounds like you're talking about organizing your personal TODOs, whereas the article is about how to acclimate and communicate within a team.

I think you missed the point. This is about someone entering into a new team. Walking into a team day 1, knowing nothing, and telling everyone they’re doing it wrong, is a horrible way to start things off.

By watching and waiting a bit, it gives time to learn why the stupid things are stupid, what is actually being worked on, etc. This helps build trust in the team, because it shows the new person respects the team enough to take some time to learn how things are before trying to change it. I don’t trust anyone in a leadership role that starts changing things before taking the time to learn how and why things are currently done the way they are.

A guy on my team now takes your approach. He derails every meeting with the way things “should” be, and he is just saying what everyone already knows, he just lacks the understanding on why the problem is more difficult to fix than he realizes. If he would talk less and listen more, he might understand those things better and stop wasting everyone’s time.

Waiting a couple weeks makes sure you have enough context to usefully contribute with less stepping on toes.

If the author is anything like me, I get it.

I have 20 years of software engineering and infosec experience can fill a few hours talking about all the crazy risks I find in a day of looking around most any company I interact with.

The status quo for security in our industry is abysmally bad. Not washing hands while working in a hospital WTF bad, everywhere.

Bringing it all up as I go can burn everyone out on interacting with me or trusting me at all if I am not careful, because survivors bias is a hell of a drug.

Two weeks to collect information and context is about right. I just usually do it as a contract security auditor now and provide a detailed report at the end.

Interesting. Why do they want you to do it the old way? Or could you explain more? I've never worked somewhere like this, so curious as to why this would happen?

Don't call it 'bullshit.md', call it 'challenges and opportunities.md', s/fuck|shit|cunt// inside and organize a series of coaching sessions about how you fixed one of these and how can they help themselves fix these.

or, channel your inner complainer into your promo-seeking behaviors.

Totally agreed. I've always liked this concept, and TIL there's a good name!

Also, now I know there's a link! Sometimes you have a new hire or team member who's a little too eager to criticize and fix everything they see, and you need to sit them down and explain this strategy. Now thanks to Bennett, you can back it up with a link.

I'd caveat that while a "two week" waiting period might work well for Bennett as a senior engineer moving between similar-enough teams, a brand new hire or a junior dev might do better with a longer delay.

Yes, the people who set the priorities have to feel the pain in some way. If you as an employee want your boss to do something, you have to communicate it in a way that makes clear how the problem will affect what the boss cares about, not what you care about. Usually that means translating it into dollars or one of the boss's KPIs, like deployment frequency or support ticket volume.

Sometimes management doesn't prioritize problems because they're short-sighted or overwhelmed. But sometimes it's because they just don't understand how big a problem it really is, and the team fails to communicate it to them effectively.

For example, I've heard devs complain about how "the tests take too long." On one team I was on, a couple junior devs were complaining about this, but it turned out that "too long" meant five minutes. Could they be more efficient? Maybe, but getting that down to one minute would take a lot of work with no impact on our ability to develop and deploy multiple times per day. Once I showed them how to run their tests locally on just the files that changed, the problem was solved. But before that, they thought the problem was "technical debt," when really it was just a training issue. (Or, you know, a lack-of-ability-to-Google issue, but I'm trying to be generous.)

On another team, when I heard this complaint, the team explained that the full test suite took almost an hour, and flaky tests meant that they often had to rerun the tests or merge with failing tests. Needless to say, this had a clear impact on our ability to deliver rapidly with high quality, so this was something I prioritized.

Managers don't do the same work as you, so they don't feel the pain firsthand. And they're often not incentivized to care about the same things as you, at least on the same scale. As an IC, you tend to be focused on the next task at hand. The manager is thinking about their quarterly OKRs or whether the team is on track to meet their sprint commitment. If you want something to change, you have to connect the problems you have on the micro scale to the problems the manager cares about on the macro scale.

And if you can't do that, or your manager won't listen, then yeah: let the problems bubble up until the manager feels the pain, as long as it won't come back to bite you.

I like to be on teams for which, if new to the team, mostly you notice things being done sensibly (in context), and the 3 things you see that you don't understand, you can just ask about them, because everyone on the team just wants to work well together to achieve the genuine goals.

I've observed this kind of culture mostly at startups. Once places start to make a lot of money -- things become political.

So if you want to work at the highest paying jobs, you'll have to deal with politics. Because once they make enough money to afford you, the company also makes enough for savvy gatekeepers to entrench themselves in a core system and carve off a piece of that revenue for themselves.

With enough experience one usually can start to differentiate the actual hoo-why-oh-why WTFs from the oh-there's-subtle-complexity-here WTFs. The first are straight up failures, the second usually resolve themselves after steeping oneself in the environment. Still handy to note them down, regardless.

Well...I have found that we should be careful, when considering "solutions."

Here's my take on it: https://littlegreenviper.com/miscellany/problems-and-solutio...

Don't say you, say we.

https://thedailywtf.com/articles/Behavioral-Deficiencies-